Uutiset:

Ei uusia uutisia.

Main Menu

Projekti tilastot

Aloittaja weatherc, keskiviikko, 17.04.2019, 21:20

« edellinen - seuraava »

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

khyron

Lainaus käyttäjältä: weatherc - lauantai, 20.04.2019, 12:38
Lainaus käyttäjältä: khyron - lauantai, 20.04.2019, 12:29
Yhdistettyyn tauluun ei tarvitse, eikä kannata, tehdä generoitua avainta koska asema ja aika on uniikki.

Totta mutta erilillisinä sarakkeina (ID sekä Time) noita tulee monta samalaista eikä uniikki silloin toimi. (Kts kuva)

Lainaus käyttäjältä: khyron - lauantai, 20.04.2019, 12:29
Taulun rakenteen muutos on monimutkaisempi operaatio jos sama muutos pitää tehdä useaan paikkaan.

Tavallaan ehkä, mutta kun on valmis häkkyrä sitä varten että plärää taulukot läpi niin suht helppoahan se on tehdä. Toisaalta, jättimäisen taulukon muuttaminen voi kestää ikuisuuden ja se on todennäköisesti lukittuna koko tuon ajan (ja hyvässä lytyssä kaataa koko myslin). Toki kovin paljoa muutoksiahan tuohon ei koskaan tule muuta kun siivousta vanhat datat ulos...

Jos aseman id on uniikki ja aikaleiman pitää olla aseman sisällä uniikki ni eihän noi yhdessä voi olla muuta kuin uniikki.

Ja kaikkee voi toki scriptata, mut sen järkevyys on vähän kyseenalaista jos vois käyttää valmista.

Lainaus käyttäjältä: weatherc - lauantai, 20.04.2019, 15:07
Yks hyvä kysymys on tietty myös se, että mikä typpi tuollaiselle isolle taulukolle, MyIsam vai InnoDB? InnoDB on ainakin isompi kooltaan. Tässä tietty haetaan lähinnä hyvää suorituskykyä, ei niinkään pienintä kokoa.
Kun jotain stackoverflow:ta ym tutkailee niin vastaus riippuu ihan vastaajasta.

Innodb, myisam on lähinnä historian painolastia, ei tue transaktioita tai viiteavaimia.

Ennemmin pohtisin mikä kanta olisi parempi, esim postgresql tukee brin-indeksejä jotka vie vähemmän tilaa ja sopii esim. Aikasarjoille hyvin. Tai sitten joku aikasarjajoihin erikoistunut kanta niinkuin influxdata. Tai timescaledb laajennus postgresqllään.

weatherc

LainaaJos aseman id on uniikki ja aikaleiman pitää olla aseman sisällä uniikki ni eihän noi yhdessä voi olla muuta kuin uniikki.

On, ja sehän oli koko ajan se ajatuskin että id + aikaleima = uniikki. Mysli ei vaan ensin suostunut asettaa niitä sarakkeita nippuna uniikiksi koska oli valmiiksi duplikaatteja koska parhammillaan/pahimmillaan saman Netatmon datat tulee 5:ssä eri haussa. 
Mutta, nyt näyttää toimivan ok tuo keruu Netatmojen osalta (muut pws:ät ja laitokset eivät ole ongelma tässä mielessä). Näyttää myös tulevan ihan kohtalaisen hyvin dataa per tunti kun antaa tuupata käppyrädataa joka kierroksella (5 kierrosta/tunti).

einari

Lainaus käyttäjältä: weatherc - sunnuntai, 21.04.2019, 12:39
On, ja sehän oli koko ajan se ajatuskin että id + aikaleima = uniikki. Mysli ei vaan ensin suostunut asettaa niitä sarakkeita nippuna uniikiksi koska oli valmiiksi duplikaatteja koska parhammillaan/pahimmillaan saman Netatmon datat tulee 5:ssä eri haussa. 
Mutta, nyt näyttää toimivan ok tuo keruu Netatmojen osalta (muut pws:ät ja laitokset eivät ole ongelma tässä mielessä). Näyttää myös tulevan ihan kohtalaisen hyvin dataa per tunti kun antaa tuupata käppyrädataa joka kierroksella (5 kierrosta/tunti).

Tuossahan on kyse siitä että kun bulkkina haetaan, ei voi saada vain sitä mitä haluaa..  ;D

Mainitsin aiemmin että voisi tehdä sellaisen yksilöidyn keruun.. toki haku tapahtuisi samoin kaikista tunnuksensa antaneilta..
helpoin tapa kai olisi että tekee sellaisen apin sinne joka hakee ja hakee hyväksynnän netatmolta.. tuon sivun mukaisesti
https://dev.netatmo.com/en-US/resources/technical/reference/smarthomeapi

Liimiiteissä ei pitäisi olla ongelmaa, varsinkaan kun hakee sen 10 min. välein ja vain outdoor-datan..
https://dev.netatmo.com/en-US/resources/technical/guides/ratelimits

Vaikea arvioida miten moni liittyisi jos laittaa ewn:n sivuille ohjeet ja linkin sellaiselle kirjautumissivulle jossa tunnus annetaan.. (kuva metewaren appiin)
Sen datanhan voi ohjata erilliseen tietokantaan... kuin tuon publicin...  ja tietysti vaatimukset että asema on oikeaoppisesti asemoitu ;D

Katsoin muistin verestämiseksi tuota Hamiltonin Wd-sivua, siellä ei ole erikseen kirjautumissivua vaan jää näkyviin sinne ohjelman asetuksiin..

Tarkoitan sitä että ewn:ssä voisi olla paremmat netatmot ja sellaiset vähemmän paremmat eri osiossa ::)

Edit// pitäisiköhän niille esittää tuollaista vähän simppelimpää algoritmia, niillä taitaa ola liian vaikeaksi tehty se 8)

einari

Ilmeisesti vain tuo enterprise.api tarvitsee sen luvan.. eli tilauksen, suunnattu yrityksille.. eihän ewn ole yritys ;D

eli pitää vain olla keino millä ne acces_tokenit saa jokaiselle asemalle joka haluaisi sitä parempaa dataa ilman katkoksia.. ja jos ja kun sellaisia sattuisi tulemaan niin sieltä saa ne  puuttuvat palaset...  niiltä osin kuin moduulit kerää ja tallentaa, sekä lähettää omaan, asemakohtaiseen tiedostoon 8)

weatherc

Miksi tehdä asia monimutkaiseksi kun eräskin asema pohjanmaan suunnalta näyttää tuuppaavan dataa kiltisti 5 krt/tunnissa? ;)

LainaaLiimiiteissä ei pitäisi olla ongelmaa, varsinkaan kun hakee sen 10 min. välein ja vain outdoor-datan..
Mitenhän oli einarin sisälukutaidon kanssa? 2000 hakua tunnissa yksitellen haettuna ei ole mitään. 6 krt stunnissa, 5 anturia niin tuohon mahtuisi kokonaiset 66 asemaa. SMHI:n ja MET.no:n asemien datat haetaan tuolla tapaa, yks haku per asema per anturi ja hakuja taitaa olla sen reilut 10k per kierros..

Sitäpaitsi sulta unohtuu yksi seikka, aika mitä hakuun menisi. Ei mitään mahista saada dataa haettu vaikkapa 10 min välein tuolla tapaa kun alle 20 hakuakin tahtoo viedä sen 5 minuuttia, ranskisten purkit kun eivät vastaile mitään kovin nopeasti...

einari

#25
Kyllä einarin sisälukutaito on kohdillaan... siinähän seisoo että jos alle 100 asemaa niin 2000 pyyntöä tunnissa...  ja vaikkapa 90 asemaa tekee 540 pyyntöä tunnissa...

jos yli 100.. niin 20x asemien määrä.. eli jos vaikka 500 niin 10k pyyntöä tunnissa mahdollista

sitten, yksi asema ei vie 30 hakua tunnissa.. vaan tasan 6 jos 10 min välein...  se kun tuo getstationdata antaa kerralla kaikki arvot..
Get the last measures from all the devices of one user with the Getstationsdata method.

eli kuvat kertovat enemmän.. pyyntö-nimisessä kuvassa on vain että lue asema.. eli read_station
ja tällaisen vastauksen saa kuten kuvassa read_station luetellaan..

sitten siihen hakuaikaan.. nehän voi olla siinä yhdessä haussa kerrallaan nuo asemat.... luulisin.. niiden yksilöintitieto on vain se aseman pääyksikön id..... (tai paikkahan on jokaisella eri)

Edit//
Se  bulk-haku koskee ilmesesti vain sitä Enterprise.apia >>
With Netatmo Smart Home API, you can access your users' station measurements (indoor and outdoor).
With Netatmo Enterprise API, you can access bulk data from your users' Weather Stations.

kai sitä ei sittenkään sen kummemminenterpriseen  lupaa pyydellä kunhan ehtojen mukaan menee..
https://dev.netatmo.com/resources/technical/guides/developerguidelines

weatherc

Lainaasiinähän seisoo että jos alle 100 asemaa niin 2000 pyyntöä tunnissa...  ja vaikkapa 90 asemaa tekee 540 pyyntöä tunnissa...
jos yli 100.. niin 20x asemien määrä.. eli jos vaikka 500 niin 10k pyyntöä tunnissa mahdollista

Ei limiiteissä ole asemien lukumäärästä kyse vaan users = todennäköisesti ip-numero tai tuo auth token joka täytyy ensin hakea, eli ewn:n purkilta saa juuri tuon 2000 hakua tunnissa, ei enempää.
Koska nuo limiitit ovat designattu user-perusteiseksi niin se on lähinnä appi-tyyliseksi tarkoitettu. Noilla limiiteillä nimeomaan halutaan estää EWN-tyylisten systeemien data-haun yksitellen.

LainaaThe user limit is here to prevent one user from disabling your app ability to call Netatmo APIs.
As this limit is quite high, reaching it usually means that your app makes too many API calls and you should use a few design tricks to reduce the number of calls made.

einari

Kun mainitsin asemat.. niin oletuksena on että jos haetaan sillä aseman id:llä niin yhdellä käyttäjällä on silloin 1 asema... eli station/user..
eihän se sitä miksikään muuta.. kumpi termi on kyseessä...   se kuitenkin lienee oikein että sillä 6 haulla/ tunti/käyttäjä..tai asema, selvinnee.. mahdollisuushan olisi 20 hakuun/käyttäjä/tunti.. rajassa varaa kun on termostaatteja ja sun muita.. samaisella 20 se limiitti kasvaa kun yli sata käyttäjää.. /luvan antaneita/

Mitä se 2000 raja pitää sisällään ewn:n suhteen..  laskin että äsken oli 600-700 asemaa tuoreella datalla.. kaikki kun ruksaili niin reilu tuhat.. ?
Harmi, jos ewn:n suhteen ei ole tilaa testata...   mutta jos niin voin antaa käyttöön mitä tarvitaan...  :D



weatherc

Lainaus käyttäjältä: einari - maanantai, 22.04.2019, 19:09
Kun mainitsin asemat.. niin oletuksena on että jos haetaan sillä aseman id:llä niin yhdellä käyttäjällä on silloin 1 asema... eli station/user..
eihän se sitä miksikään muuta.. kumpi termi on kyseessä...   se kuitenkin lienee oikein että sillä 6 haulla/ tunti/käyttäjä..tai asema, selvinnee.. mahdollisuushan olisi 20 hakuun/käyttäjä/tunti.. rajassa varaa kun on termostaatteja ja sun muita.. samaisella 20 se limiitti kasvaa kun yli sata käyttäjää.. /luvan antaneita/

Mitä se 2000 raja pitää sisällään ewn:n suhteen..  laskin että äsken oli 600-700 asemaa tuoreella datalla.. kaikki kun ruksaili niin reilu tuhat.. ?
Harmi, jos ewn:n suhteen ei ole tilaa testata...   mutta jos niin voin antaa käyttöön mitä tarvitaan...  :D

Jokaiseen hakuunhan tarvittan tuo auth token eli veikkaan että se kerryyttää myös limiittilaskuria. Tuo aúthihan haetaan client_id ja client_secretin kanssa. Tämän lisäksi jäänee ip-numero josta se haetaan heidään logeihin. Ei tarvi olla kummallinen insjenjööri, edes ranskalainen sellainen, että alkaisi valot vilkumaan punaista jos samasta ip-numerosta (dediltä) alkaisi tulemaan hakuja kasapäin eri auth tokeneilla...

einari

#29
Hakuhan suoritetaan sitten viimekädessä sovelluksen.. eli apin tekijän auth tokenilla... kun tehdään se smart home- tai enterprise-apista.
muilta käyttäjiltähän on acces_token ja refres_token joilla valtuutus hoidetaan.. ilmeisesti antavat jonkin määräajan, milloin pitää käyttöoikeus uusia.. se on huono puoli..   Mainitsemani Hamilton tietänee asiasta enemmän.. kun WD:lle antaa netatmon tunnuksen ja salasanan.. eli sähköpostiosoitteen ja neatmon salasanan (siis sinne netatmon accountiin kirjaudutaan sähköpostios)

wd:ltä sitten näkyy netatmon setupissa third party apps- osiossa että wd käyttää tietojani smart home apilla... ;D
siellä on myös smartmixin ja netatmo support..