Filtteröinti käyttöön

Aloittaja weatherc, lauantai, 02.06.2018, 16:10

« edellinen - seuraava »

0 Jäsenet ja 1 Vieras katselee tätä aihetta.

einari

#10
Pitäisköhän kysyä sieltä Ranskan päästä porsaanrei'istä ja niiden käytöstä? olisiko se pig hole...  ;D

Tein empiiristä (mitähän sekin oikein on) tutkimusta vielä iistä hakujutuista koska haluan hieman  laittaa niille ihmeteltävää..
hain toisilla tunnuksilla rain-ehdolla ja toisella sillä perusjutulla.. aluksi näytti hyvältä, mutta sitten tuli outo hyppäys. vastausajoissa..
piteni 5 min toiseen suuntaan ja lyheni toiseen enemmän..
tuossa taulukkoa.. vein sen exelitä pdf:si utta tuolla systeemillä pisin hakuväli oli 23 min... lyhin 7 min..
voi olla että se on oma vika.. hakuaika venyi ehkä liian pitkäksi seitsemän kieppeillä...


weatherc

Sehän se tuossa se kummajainen onkin ettei ole mitään määrättyä minuuttia/eja jolloin tulisi tuoretta dataa vaan ne vaihtelee tunnista toiseen. Ainut vähän edes sinneppäin on pikkasen tasan jälkeen. Tämän oon itsekkin huomannut.
Se mikä myös kummastuttaa on se että joiltakin asemilta näyttää tulevan suht tuoretta ihan suht tasaisesti pitkin tuntia 30 min cachesta huolimatta (koska ovat näkösällä filtteristä huolimatta) ja joltain taas ei.

EWN:än kartan/taulukon ikäfiltteri on muuten 20 min, ei 15 min mitä muistin eilen.

teutari

Lainaus käyttäjältä: weatherc - sunnuntai, 03.06.2018, 15:00
Lainaus käyttäjältä: einari - sunnuntai, 03.06.2018, 12:28
tein testin.. aamulla jouduin keskeyttämään kun tuli yllättävää menoa..
hain niitä time_utc aikoja 2 eri tunnuksella ja temperature, rain ja wind-hauilla ja sain aikoja jotka olivat 5-20 minuuttia toisistaan.. kyseessä oli minun 1-aseman lpt-arvojen timestamp.. ne vaihtelivat tällä systeemillä mutta jos hakee vuorotellen kahdella acces_token.. eli käyttäjätunnuksella vaikkapa 15 minuutin välein niin kerta siellä näyttäisi dataa olevan, niin voisi saada pelkällä perushaulla  aikaa lhennettyä puoleen?

Siinä on vaan yksi mutta. Yleensä tuollaiset porsaanreiät tukitaan jos niitä alkaa käyttämään, tyyliin yksi access_token/ip-numero.

Firmiskin on kerran revitty auki mutta sekin tukittiin... mitä tuolta FAQ:sta lukee niin aikamoista hulapaloota/rukoilemista sen päivitys on.  ::)

https://forum.netatmo.com/viewtopic.php?f=10&t=2359&start=790

einari

#13
Asiaa vielä kokemusperäisesti tutkittuani tulin siihen johtopäätökseen että nimenomaan se liian pitkä hakuväli aiheutti sen muutoksen vastauksissa, rain hyppäsi yhden haun ylitse, jos olisin hakenut sen 19.11 niinkuin tarkoitus oli eikä 19.17 olisi se väli ollut 16 min.. etc. siinä on myös jossain vaiheessa edessä vastaava hyppäys jollei pysty ajoittamaan noin puoleenväliin hakua, eli jos ensimmäisellä haulla saa ajaksi vaikkapa 10.01 niin seuraavan voi tehdä 12.31 tai 10.32.. eli siis (10.16.. )10.47.. 11.18.. etc..  koska näytäisi olevan noin 30 min +-1 milloin voi hakea..

Lainaus käyttäjältä: teutari - maanantai, 04.06.2018, 07:41
Firmiskin on kerran revitty auki mutta sekin tukittiin... mitä tuolta FAQ:sta lukee niin aikamoista hulapaloota/rukoilemista sen päivitys on.  ::)

Siinähän se...jollei automaattipäivitys toimi ..
https://www.netatmo.com/en-US/helpcenter/security/2/how-do-firmware-updates-work/316

ongelma on yleensä käyttäjän vika, kun ei osata poistaa asennusohjelmia koneelta ja netatmon pääpurkista.. niin ei takuulla firmware päivity..vaan käyttää vanhaa... pitää lähteä puhtaalta pöydältä niinkuin monesti atk-asioissa valitettavasti joutuu tekemään :)
tai  sitten olla yhteyksissä ylempiin tahoihin, mitä pomompi sitä parempi... toisaalta, ei se kovin helppoa ole muidenkaan merkkien kanssa, mitä olen täällä havainnut ;D

Laitoin sille Prashanthille lisää mailia.. olisikohan pitänyt käyttää loop sanaa piglet sijasta >>

I did a test with two IDs to search, ID A> Rain and B> Temp. That way cache gets data for 15 min. interval, but if the search interval is not 31-32 min. length / condition, then the result will change, I will put it in pdf-file.

My point is that at least my aspect of the cache will be updated about 29-31 min. interval, sometimes takes longer.

Cache does not update for 10 min. interval, but at odd intervals ...

Ewn put the maps and tables into a timeline, only 20 min. newer data is displayed, followed by the fact that most of the netatmos dumped, but there are some where, despite the cache, the data is updated frequently enough and remains visible.

Conclusion; getpubligdata cache works like it does, and not exactly as it should. Also sets stations to unequal situations.

There is also a question as to whether two IDs can retrieve data if you do not get cache to work in a sensible way or throw out if the same ip address. (piglet hole) :-)

It would be desirable for one search to give 10-15 minutes. interval (or 20 min.) last data .....

weatherc

Lainaus käyttäjältä: teutari - maanantai, 04.06.2018, 07:41

Firmiskin on kerran revitty auki mutta sekin tukittiin... mitä tuolta FAQ:sta lukee niin aikamoista hulapaloota/rukoilemista sen päivitys on.  ::)

https://forum.netatmo.com/viewtopic.php?f=10&t=2359&start=790

Siis mitä? Se puskee jatkuvasti nettiin dataa eikä osaa edes firmistä päivittää ilman PC:tä? Anna mun nauraa. Oikeasti.  :D
Toisaalta, jos firmistä pitää jatkuvasti laastaroida päivityksillä niin se kertoo enemmän mitä reikäjuustoa se on...

einari

Lainaus käyttäjältä: weatherc - maanantai, 04.06.2018, 09:36
Siis mitä? Se puskee jatkuvasti nettiin dataa eikä osaa edes firmistä päivittää ilman PC:tä? Anna mun nauraa. Oikeasti.  :D
Toisaalta, jos firmistä pitää jatkuvasti laastaroida päivityksillä niin se kertoo enemmän mitä reikäjuustoa se on...

Käsittääkseni tuo ongelma koskee enempi ilman pc:tä asennettuja purkkeja, pääosaa näyttelee iphonet ja androidit.. iphonesta minulla ei ole kokemuksia mutta ainakin googlen android puskee päivityksiä oikein olan takaa, käyttäjät tuskastuvat ja ottavat ne pois päältä.. siitä se soppa syntyy vaikka purkkiin päivittyisikin firmware.. ei puhelimeen...  sitten riitelevät keskenään....  mitä tulee reikäjuustoon, mitä isommat reiät.. sen parempaa, ainakin edam... ;D

teutari


Kun se meni näihin juustoihin niin juustohan pierettää joten ei koskaan tiedä millainen paukku sieltä maailmalle putkahtaa mutta onhan siinä hyvätkin puolensa sehän kertoo vaan hyvistä bakteereista. ;D

einari

Jatkoin tutkimuksia, voi sillä samalla access_tokenilla hakea vuorotellen vaikka sillä 20 min välillä, weatherc varmaan osaa rakentaa sellaisen silmukan joka sen tekisi, itse hain 15 minuutin välein/ehto (temperature/rain) ja sain vastaukset aina joko/tai per ehto noin 30 min. välein,sen cachen sallimissa rajoissa, tuossahan tulee 40 min. /ehto, eli oletettavasti tämä hakusysteemi antaa tuoreempia vastauksia kuin nykytilanne...  se miten ne suhteutuu toisiinsa on kysymysmerkki, voi tulla lyhyitäkin päivitysvälejä tai jopa yli sen 20 min... mutta kuitenkin huomattavasti alle puoli tuntia ja luultavasti puolittaisi ainakin  nykyisen 40-50 min.  asiahan on nyt weatherc:n käsissä kunnes saadaan toimivampi api.  ;D

noista firmware-päivityksistä vielä sen verran että varmaankin koskee muita tuotteita enemmän kuin sääasemia.. kuten kameroita, termostaatteja, hälyttimiä yms krääsää mitä on sääasemien rinnalle tullut...

weatherc

Lainaus käyttäjältä: einari - maanantai, 04.06.2018, 18:33
Jatkoin tutkimuksia, voi sillä samalla access_tokenilla hakea vuorotellen vaikka sillä 20 min välillä, weatherc varmaan osaa rakentaa sellaisen silmukan joka sen tekisi, itse hain 15 minuutin välein/ehto (temperature/rain) ja sain vastaukset aina joko/tai per ehto noin 30 min. välein,sen cachen sallimissa rajoissa, tuossahan tulee 40 min. /ehto, eli oletettavasti tämä hakusysteemi antaa tuoreempia vastauksia kuin nykytilanne...  se miten ne suhteutuu toisiinsa on kysymysmerkki, voi tulla lyhyitäkin päivitysvälejä tai jopa yli sen 20 min... mutta kuitenkin huomattavasti alle puoli tuntia ja luultavasti puolittaisi ainakin  nykyisen 40-50 min.  asiahan on nyt weatherc:n käsissä kunnes saadaan toimivampi api.  ;D

Sellanen on kyllä aika simpplei tehdä että joka toinen olisi nykyisellä ehdolla ja joka toinen rain-ehdolla. Aina voidaan kokeilla, ei se ainakaan pahenna tilannetta.
Tuota access_tokenia en lähtis sorkkimaan koska sehän on tavallaan käyttäjän tunniste. Koska EWN:än haut ovat säännöölliset niin se olisi myös helposti nähtävissä että esim joka toinen haku tulisi eri tokenilla jolloin helposti kävisi niin että koko ip olisi bannissa...

einari