Netatmot EWN:ään

[weatherc]

On, on. Tässä on just se heidän API:n perusongelma, vastaukseen tulee minkälaisia asemia tahansa hakuehdoista riippumatta. Joukossa myös asemia joilla ei ole ehdon mukaista härpäkettä ja jopa sellaisia joilla vain ilmanpaine. Kerran nimittäin tutkailin asiaa kun ihmettelin että miksi raakana oli useampi sata asemaa mutta "hyväksyttäviä" oli vain jokunen kymmen. Osa noista sadoista asemista on myös sellaisia joissa pelkästään lämpötila. Sillä hakuehdolla voi vaikka pyyhkiä takapuolta, yhtä suuri on vaikutus. Sen lisäksi näyttää valitsevan randomilla että mikäkin asema milloinkin tulee siihen dataan.
Zoomitason vaihto vaikkapa 4 => 5 ei muuta tätä vaan hakuehdon vastaisen "sonnan" määrä vaan kasvaa samassa suhteessa, eikä se mitenkään paranna haluttujen asemien datan saantia. Itse asiassa mutu on päinvastainen eli että mitä pienempi zoomitaso sitä "parempaa" on data.

[einari]

Niinpä, jos zoomaan kartalla niin periaatteessa näkyvä alue on pienempi, mutta tarkempi.. ja on enemmän asemia ja enemmän virheellisiä tietoja.. Jos ajatellaan että otan alueen 23.20/23.40 ja 63.20/63.50, se pitää sisällään minun asemani ja data tulee joka hakukerta.. sen 30 min välein/ehto.. mutta jos zoomaa tasolle vaikkapa 4 niin data ei tule joka hakukerta jostain syystä..  siksipä ehdotin sitä tiilien pilkkomista.. tai suomen osalta jakoa pystysuunnassa.. että hakualue olisi pienempi... zoomitasoon nähden vähän niinkuin käänteisesti.
Jos tiili on vaikkapa 10x10 astetta niin hakisi 5x10 astetta. eli tavallaan tiili puolittuisi ja hakualue puolittuisi...

tätä asiaa on hieman vaikea ajatella... mutta kokeilemallahan se selviää... 

[einari]

Jalostan vähän tuota 1000 asemaa, kun puhutaan outdoor stations... niin lämpötilayksikkö on 1. sade 2 ja tuuli 3. >eli periaatteessa jos kaikissa olisi härpäkkeet niin siitä tulisi 1024/3 = noin 340 asemaa, käytännössä noin 400-500 asemaa / tiili joista voi saada vastauksen..

Siitä oli jossain että pitää huomioida että samassa sisäyksikön tiedoissa on muitakin mittauksia.. smart home.api/getmeasure jonne on siirretty se getpublicdatassa mainittu lisähakuehtoja saa thermostatdatasta... sieltä löytyi seuraavaa >>
Maximum number of measurements (default and max are 1024) > limit kohdasta...

saat varmaan selville montako asemaa pukkaa näihin 66.6°E>> tiiliin...  sanotaan että jos yli 400 niin alkaa ehkä selittymään syy näihin ongelmiin..  selittäisi tyhjät asematkin kai..   
mitä tulee mainitsemaasi seikkaan että on vain humidity.. ei muuta, olettamani on se kyseisessä asemassa on epänormaali lpt ja haussa filtterinä true.. eikä ole härpäkkeitä.. tulee siis humidityllä vain humidity

Kovin suurta kokemusta ei ole nykyisistä tietokannoista, eikä liioin kyselyistä, Noissa tuotannonohjausjärjestelmissä pääosassa oli ODBC/SQL ja Paradox... joiden kanssa olen ollut tekemisissä mutta olettaisin että raakadatan haussa voisi käyttää jotain suodattimia?

Mainitsit aikoinaan että netatmon data pitäisi olla Nxing-palvelimilla.. niinhän se onkin...  katselin jotain hakukoodeja vaikkei ne minulle tässä vaiheessa .. mutta seuraavassa javasysteemissä oli mielestäni jotain järjestely ja erotusjuttuja... voin olla taas väärässä
jostain riviltä 250 public shared datasta...

https://github.com/lost-carrier/netatmo-api/blob/master/src/main/java/losty/netatmo/NetatmoHttpClient.java

Edit// mietin tuolla mainituista tuplakoordinaateista...  joskus aikaisemmin törmäsin yhteen viritelmätekeleeseen olikohan se condradin jutuissa.. jossa oli jotain sellaista..  en muista enää kovin hyvin mutta oli tuplat ja jälkimmäisessä oli arvo +0.2 tyyliin, mitä sitten sillä haetaan on minulle vähintään hebreaa

[weatherc]

mitä tulee mainitsemaasi seikkaan että on vain humidity.. ei muuta, olettamani on se kyseisessä asemassa on epänormaali lpt ja haussa filtterinä true.. eikä ole härpäkkeitä.. tulee siis humidityllä vain humidity

Viikon naurut ja ongelman ydin. Tai oikeastaan se että heidän required-parametrillä ei ole mitään merkitystä tulevaan dataan vaan esimerkkinä, humidity-haulla tulee asemia jossa pelkästään ilmanpaine, ei mitään muita härpäkkeitä/arvoja.

[quote
saat varmaan selville montako asemaa pukkaa näihin 66.6°E>> tiiliin...  sanotaan että jos yli 400 niin alkaa ehkä selittymään syy näihin ongelmiin..  selittäisi tyhjät asematkin kai..[/quote]

No, jos asemia on 48 niin härpäkkeitä saa olla 20+ per asema että "1000 modules" täyttyisi.....
Tuo 1000 moduulia on muuten naurettavan pieni määrä varsinkin jos se menee moduulimäärän mukaan eli tuuli+lpt+sade = 3 moduulia.

Koita Einari ymmärtää että niin kauan kun heidän API syöttää mitä sattuu eikä suodata dataa hakuun annetulla tavalla niin kauan on palloittelu hyödytöntä. API:n (ja datan) peruspilari kun on toimiva API joka tekee mitä sille käsketään, esim. jos required on wind, pitää myös jokaisella asemalla joka vastauksessa olla se tuulivispeli.
Ja jos sanotaan että datan cache on 30 min, niin pitää 31 min päästä saada ulos tuoretta dataa (tietty edellyttäen että sitä on saatavilla), eikä miten sattuu kuten nyt, ensim toimii ok 2 tuntia, sitten tulee seuraava tuore data 2 tunnin päästä. EWN:än kanta ei tiedä milloin se data on päivitetty, eli onko saman ikäistä dataa päivitetty useampikin kierros vai onko asema puuttunut kokonaan datasta, koska kantaan menee vain asemalta saatu tuorein aikaleima ei päivitysajankohtaa.

Ja koska - kuten Netatmon vastauksessa oli - API:a ei ole tehty tällaista varten vaan ykisttäisen pienen haun tekemiseen, eikä Netatmolla ole mitään kiinnostusta korjata viat, niin on myöskään turha odottaa mitään parannusta "datan laadussa". Pikemmin voisi ajatella että käyttävät käänteistä psykologiaa, eli data on vapaata juu mutta datan laatu on surkeaa eli käytännössä hyödytöntä jos haluaa tehdä uskottavan kartan heidän datastaan, niin silloin "ei kukaan" tai harva myöskään niin tekee.
Sama asia on ranskisten MeteoFrancen avoimessa datassa, on avointa juu aivan kuten FMI:llä ja kuten EU määrää, mutta kaista on todella hidasta ja tukkoista eli yhden filun haku kestää ikuisuuden - jos edes suostuu latautumaan. Kunnon kaistaa ja sujuvaa latausta myydään sitten rekkalastillisella €uroja....

Niin, sillä raakadatalla tarkoitin sitä että mitä se API:lta saatu json-filu sisältää, eli se data mitä EWN:än häkkyrä pureskelee.

[einari]

Se on hyvä se että on jotain ilon aihetta näin harmaina aikoina... sanotaan että nauru pidentää ikää... mutta voi se lyhentääkkin sitä jos siihen tukehtuu esim. nauraessaan ruoka suussa

Sanotaan myös että metsä vastaa niinkuin huudetaan... sitä tässä ajan takaa että huudetaanko oikeasti vai kuiskaillaanko vain...
Lähinnä iloksenne pohdiskelen asioita ja tuon julki näitä päätelmiäni, oli ne sitten oikeita tai vääriä.. mieltä askarruttaviin kysymyksiinhän ei saa vastausta muuta kuin asioita pyörittelemällä...  moni asia olisi ratkaisematta jäänyt aikoinaan jollei niitä olisi pyöritelty... esim. arkhimeedeen laki, Einsteinin suhteellisuusteoria, newtonin painovoimalaki jonka tuo einstein myöhemmin korjasi.. ja monia monia muita

Kyllä einari jotain ymmärtää.. vaikka annat ymmärtää ettei ymmärtäisi...
[quote
Koita Einari ymmärtää että niin kauan kun heidän API syöttää mitä sattuu eikä suodata dataa hakuun annetulla tavalla niin kauan on palloittelu hyödytöntä. API:n (ja datan) peruspilari kun on toimiva API joka tekee mitä sille käsketään, esim. jos required on wind, pitää myös jokaisella asemalla joka vastauksessa olla se tuulivispeli.
Ja jos sanotaan että datan cache on 30 min, niin pitää 31 min päästä saada ulos tuoretta dataa (tietty edellyttäen että sitä on saatavilla), eikä miten sattuu kuten nyt, ensim toimii ok 2 tuntia, sitten tulee seuraava tuore data 2 tunnin päästä. EWN:än kanta ei tiedä milloin se data on päivitetty, eli onko saman ikäistä dataa päivitetty useampikin kierros vai onko asema puuttunut kokonaan datasta, koska kantaan menee vain asemalta saatu tuorein aikaleima ei päivitysajankohtaa.
[/quote]

Toisaalta tuntuu siltä ettet sinä weatherc ymmärrä mitä haen takaa...  jotenka sanon hieman selvemmin sen (ja kysyn kun tiedät enemmän noista hakujutuista)

Lähden liikkeelle helpommasta päästä joka on ollut jo aiemmin mielessä..
66.6°N>> data päivittyy  suomen osalta lähes täydellisesti, poikkeus on kilpisjärvi.. mutta sehän on ilmeisesti norjan tiilessä..
Kun katsoin illalla ewn:n pohjoista vaihtoehtoa ja kaikkea dataa.. ja nyt viimeisintä hakua joka on ilmeisessti rain (06.40) oli pohjoisesssa sen 66.6 yläpuolella asemia jotka oli päivittynyt 06.20 viimeksi, mutta niissä ei ole sademittaria.. loput joissa ei ollut tuoretta dataa olikin kyseisen viivan alapuolella toisessa tiilessä..

Sitten kun katsoo alemmaksi.. eli keskiosaa, niin illalla oli noin 6 % päivittymättömiä.. nyt kun katsoi niin 7-10 % riippuen mihin aikaan vetää rajan (6.20 vai 6.25) Eteläosassa taas 40 - 50%.. tokihan pitää huomioida se ettei niissä kaikissa ole sademittaria..

Tästä voisi päätellä että mitä enemmän asemia haussa on niin sitä  huonommin päivittyy ilmeisesti juuri sen rajan takia...

Näin omasta ja suomen näkökulmasta ei sinänsä ole väliä minkä kokoisia alueita /esim. norja, ruotsi, tai muu eurooppa/ hakee, vaikka tasolla 3.. tai 2.  kunhan suomen osalta haetaan riittävän pieniä.. jotta saadaan sopivasti asemia..

Toisena palaan siihen Apin hakuun.. Kuinka suuri merkitys on, vaiko onko merkitystä laisinkaan, millä sen hakee, Javalla, Pythonilla vai Html:llä, ja voiko hakua "manipuloida" ?

Tuosta seuraavasta en tiedä, käytetäänkö (voiko) noita hakuscriptissä.. mitä oli mainittu yhdellä ruottalaisella sivulla..
The data is returned as JSON. I use the JSONGetElement and JSONListValues functions to extract the values I want. In the sample file included I have extracted the most common values, but there are more values you might find interesting. In that case you need to create more fields in the presentation table and add more script steps to extract the values in the Get weather data script.

Ei vaivuta synkkyyteen vaan olkaamme optimisteja...  pessimisti sanoo että huonosti seisoo.. optimisti taas että hyvin riippuu.. siinä on vissi ero

Edit// Taisin muistaa väärin kun vastasin siihen humidityhakuun..
Lähden nyt liikkeelle siitä mitä sanoin aiemmin noista home coach ja air care-asemista.. niissähän on sisäyksikkö ja jossa paikkatieto ja kyseinen pressure..  // sitten kun tehdään haku sieltä tietokannasta.. niin annetaan alue joilta haetaan.. oletukseni on että se aseman paikatieto tulee ensimmäiseksi, niin varsinaiset sääasemat kuin nämä vain sisäkäyttöön tarkoitetutkin ovat listassa.. sitten kun raksutellaan niihin tietoja on tuo pressure niissä jokaisesssa vaikkei muuta olisikaan ja pukkaa sen muiden mukana ihmeteltäväksi..
siksipä kyselenkin voiko jo apin haussa näitä karsia...

[einari]

Mietin  tuossa katsellessani weathermappia..  ja pohtiessani hakuehtoja..  että taitaa mainitsemasi sonta tulla humidityllä suurimmaksi osaksi..

Jos ajatellaan hieman eri lailla koko hakuprosesssia ja jätetään  kylmästi koko hum/temp haku pois ja haetaaan vain rain/wind ehdoilla vaikkapa 16 min välein eli 32 min/ehto. tai sitten 40 min/ehto jos kierto on mielestäsi helpompi..  oletaisin että ei tulisi niitä parin tunnin katkoksia juurikaan.. lapin osalta voisi jättää 3 ehdon kierto jos se on helppo toteuttaa..  tämä siis sillä nelostasolla...

tokikin siellä tulisi niitä pressure yms. tyhjiä vastauksia.. ja ne joutuisi siivoamaan pois. Noita tuuli ja sadehärpäkkeitä on aika runsaasti joten voisi olla kokeilun arvoinen juttu... 

tuon suomen alemman tiilen voisi ainakin puolittaa...

[weatherc]

Tuo eilinen ei ollut mitenkään pahalla kirjoitettu.

Ymmärrän hyvin mitä ajat takaa mutta kun se API ei toimi niin kun ajattelet. Se on jo nähty että pienentämällä tiilien kokoa ei paranna datan laatua mitenkään, päivastoin. Sinne tulee vain enemmän niitä "sonta"-asemia eikä ne mitä haetaan tule yhtään sen varmemmin vaan yhtä hakuammuntaa se on silloinkin.
Eli puolittmalla eteläsuomen tiilen (joka ei ole etelä-suomen tiili vaan reilusti sen ulkopuolellakin) ei auta asiaa mitenkään, yhtä hakuammuntaa se vastaus on silloinkin.
Ainut joka tohon oikeasti auttaa on hakea data tasolla jossa aina ja varmasti tulee kaikki asemat. Mutta silloin puhutaan tasoista tyyliin 12+. Silloin olisi hakuja satojatuhansia per kierros (tason 4 olevaan 2 tileen menee 131000 tason 12 tiiltä)...Aikaakin yhteen kierrokseen menisi tunteja.

Asemien lukumäärä 4-tason vastauksessa on itse asiassa aika sopeva, kunhan se data olisi vakaata eli samat asemat saisi dataa aina.

Niin, voihan sen humdityn jättää pois mutta silloin tippuu pois myös kasa asemia listalta jotka eivät tule muuta kun humidityllä, muistaakseni mm yks enontekiölaäinen. Tämä siis vaikka sillä on kaikki härpättimet.

Toisena palaan siihen Apin hakuun.. Kuinka suuri merkitys on, vaiko onko merkitystä laisinkaan, millä sen hakee, Javalla, Pythonilla vai Html:llä, ja voiko hakua "manipuloida" ?

Ei, samalaisen http-kyselyn sinne serverille ne kaikki tekevät...

The data is returned as JSON. I use the JSONGetElement and JSONListValues functions to extract the values I want. In the sample file included I have extracted the most common values, but there are more values you might find interesting. In that case you need to create more fields in the presentation table and add more script steps to extract the values in the Get weather data script.

Tuolla ei ole mitään merkitystä, tuo kun vain kertoo mitä sille datalle tehdään sen jälkeen kun se on saatu....

[einari]

Ei kai se ihan noin suoraviivaisessti yksi yhteen mene.. enkä nyt oletakkaan että tiheästi asemia sisältävät maat otettaisiin siihen mukaan..

Tarkastellaan nyt vain tätä kotomaata.. ja baltiaa.. suomen osalta se kahteen osaan jako tai zoomin nosto 5 voisi lisätä asemia lpt/hum > vajaan 2 x ja baltian osalta vähemmän, Jos lapin jättää ennalleen kun toimii ok.. niin.. taasen wind/rain haku vastaavasti liki puolittaisi asemien määrän.. sadehärpäkkeitä on nyt enemmän, mutta kun tulee talvi päälle saattaa niistä jokin osa mennä telakalle.. ei siinä mitään jos tyytyvät nostamaan sen sisälle pattereineen.. ehkä ei sekään vaikka ottavat patteritkin pois, kunhan eivät poista asennusta sisäyksiköstä.. onhan se siellä vaikkei toimikkaan.. luulisin.

Kumpaakohan Enontekiön asemaa tarkoitat.. Kilpisjärvi häipyy ajoittain .. liekö nettiongelmia ja Hetassa ei ole ainakaan nyt sademittaria.. eikä ollut weathermapissa kummassakaan ennenkuin klikkasi aseman auki

Onko se sitten niin että jos luo oman apin jossa oman aseman tunnukset niin voi hakea sitten niillä netistä löytyvillä java ja python-ohjeilla vähän erilailla siitä omasta apista?

olisiko helpompaa tässä vaiheessaa heittää ne minun aseman koordinaatit sinne hakuun mukaan omana alueena ja katsoa miten sitä dataa alkaa tulemaan, ja miettiä rauhassa tätä asiaa.. (jotta ainakin minä olisin tyytyväinen ) se ei haitanne vaikka on jo siinä isommassa tiilessä mukana...

[weatherc]

Pohjoismaat + pohjoinen Venäjä tulee 2 sivuttaistiilessä, 0-22.5°E ja 22.5-45°E.  Etelä-pohjois-suunnaassa on etelärajat 66.6°N ja 55.7°N. Tuo on miten 4 taso karttatiili jakaa sen. Eli Suomen osalta suunnilleen Uusikarlepyy-Turku-linja sekä Käsivarressa Karesuannon kohdalla on jako länsi-itä-suunnassa ja Napapiirillä etelä-pohjoissuunnassa.

(Asemalukumäärä ei ole module-määrä vaan asemien/eri sijantien määrä Netatmolta tulevassa datassa)
66.6°N ja 0°E: 175 asemaa
66.6°N ja 22.5°E: 48 asemaa
55.7°N ja 0°E: 1225 asemaa
55.7°N ja 22.5°E: 308 asemaa
Nuo asemien lukumäärät ovat suht vakiot, hakuehdoista riippumatta.

Eli "suomen eteläisessä tiilessä" saisi olla keskimäärin yli 3 moduulia per asema että tuo netatmon docissa oleva "up to" 1000 moduulin raja täyttyisi. Näin ei kuitenkaan ole vaan ehkä puolella asemista on 3 moduulia (lpt + sade + tuuli).
Eli se datan satunnaisuus on ihan jostain muusta kiinni kun että 1000 moduulin raja paukkusi.
Toisaalta jos tuo raja olisi olikeesti käytössä/toiminnassa ei dataankaan tulisi yli 1000 asemaa niinkuin nyt tulee...Eli sekään ei toimi...

Kumpaakohan Enontekiön asemaa tarkoitat.. Kilpisjärvi häipyy ajoittain .. liekö nettiongelmia ja Hetassa ei ole ainakaan nyt sademittaria.. eikä ollut weathermapissa kummassakaan ennenkuin klikkasi aseman auki

Muistaakseni Hetta.

Onko se sitten niin että jos luo oman apin jossa oman aseman tunnukset niin voi hakea sitten niillä netistä löytyvillä java ja python-ohjeilla vähän erilailla siitä omasta apista?

Ei. Ei sillä "omalla apilla" ja getpublicdatalla ole mitään eroa tavassa millä dataa haetaan. "Oma api" tarkoittaa sitä että on oltava access_token haku-urlissa. Tällä pystyvät seuraamaan tekemäsi hakujen määrää yms. Sekä osoitat että sulla on "lupa" hakea dataa.

[weatherc]

einari, Evijärven ympärystössä käytössä ruutu joka vastaa zoomitasoa 8. Vopitpi seurata että onko datan tulo yhtään vakaampaa....