Datan visualisointi Grafanalla

  • Viestiketjun aloittaja Viestiketjun aloittaja fraatti
  • Aloituspäivämäärä Aloituspäivämäärä
^
Pari kappaletta on Rockpi 4B4A ja toinen B malli, molemmissa käytän armbian dedian softaa https://www.armbian.com/ , tietysti muokattuna omiin tarpeisiin, original softa toimii myös ihan hyvin https://wiki.radxa.com/Rockpi4
Ehkä pienemmällä vaivalla kuin raspissa lähtee m-bus, modbus, paho, mqtt, docker pelaamaan, menevät ihan perus debian ohjeiden mukaan busteriin. sitävastoin raspiin on taasen paremmat ja monipuolisemmat ohjeet jos ongelmia on mutta ne pääpiirteissään sopivat myös rockiin
Vähänkään linuxia osaavalle softapuoli ei ole ongelma

Nuo bananapit on paljon haasteelisempia ainakin minulle, Bananapi m3 ei oikein toimivaa ole löytynyt samoin nyt vasta sain pcduino 3nano 'n toimimaan kunnolla, bananapi m1 on taasen vakaa ja luotettava
En käytä missään noissa desktop imageja
 
Raspi ja muistikortti ja virtalähde taasen ketjussa mainittiin, niin sopinee tähän hieman kommentoida
Kaatumiset ja sekoamiset ja muut epämääräiset selvittämättömät oireilut johtuvat useasti virransaannista
SD kortin syyksikin nuo useasti menevät vaikka syy on esim pieni mikrokatkos virransaannissa

Minulla on tällähetkellä muusta käytöstä vapaana olevia akkuja muutama sata ampertuntia, vähintään 60ah akku on aina kiinni, minkä kautta kaikki virta tulee kauempaa 4x6m² kaapelilla vanhaan ryhmäkeskukseen, oli jo sopivasti hieman kalustettukin
Kaikki lädöt menevät kuvassa näkyvien autopuolen sulakkeiden läpi
Buck convertereilla teen halutut jännitteet, m-bus 42V, 5V, 24V, 3,2V ja 12V laitteet suoraan sulakkeen läpi kun käyttämäni ei tarvitse regulointia sen kummemmin, saunan, turva ym ledvalot vastuksen läpi.
Tuolla pärjää pidemmänkin sähkökatkoksen mutta ei se ole sitä varten vaan lyhyitä varten, jos suurempi katko tulisi niin sitten diesel käyntiin
Pikku seinälatureita tuolla korvataan useita, akku latautuu päivisin paneleilla 30A laturilla mikä ohjautuu valon mukaan, joulu-tammikuussa oli aina päällä

Toistan vielä, tuossa kuvan ryhmiksessä ei ole yli 42V jännitteitä, vaikka tuo loppupää on mmj

IMG_20200525_212843.jpg
 
Noista loggailuistani vielä, minulle ei riittäisi alle kuukauden tarkka data jos ongelmia haluaisin selvitellä. Pitää sen loggailla lomienkin ajan, ei noita aina olla vahtimassa.

Levytilaa nykyään riittää hyvin eikä muutama miljoona riviä vielä ole paljon jos tilan tarvetta ainoastaan katsotaan. Toki on niinkin, että kovin monta vuotta sitä tarkkaa dataa ei tarvitse säilöä. Pari vuotta olisi kuitenkin ns. "kiva". Pidemmältä aikaväliltä riittäisi joku kerta-minuutissa tyyppinen säilöntä.
 
repomies sanoi:
Levytilaa nykyään riittää hyvin eikä muutama miljoona riviä vielä ole paljon jos tilan tarvetta ainoastaan katsotaan
Klikkaa laajentaaksesi...

Eise ole edes raspissa - mutta jos relaatiokannasta joutuu etsimään full table scanillä niin se kestää sen minkä datan läpiluku kestää - niin ei vaan pidä tehdä, mutta ei jossain kotiautomaatiosoftassa ole tämmöisiä optimoitu.
 
VesA sanoi:
Eise ole edes raspissa - mutta jos relaatiokannasta joutuu etsimään full table scanillä niin se kestää sen minkä datan läpiluku kestää - niin ei vaan pidä tehdä, mutta ei jossain kotiautomaatiosoftassa ole tämmöisiä optimoitu
Klikkaa laajentaaksesi...

Tavanomaisen talouden tavanomainen automaatiokanta on niin pieni, ettei millään optimoinnilla ole mitään väliä. Mulla on domo pörrännyt 6-7 vuotta ja niin se vaan koko kanta istuu raspisda ramdiskillä.Sieltä se pari kertaa päivässä backupataan verkkoon.
 
pamppu sanoi:
Tavanomaisen talouden tavanomainen automaatiokanta on niin pieni, ettei millään optimoinnilla ole mitään väliä. Mulla on domo pörrännyt 6-7 vuotta ja niin se vaan koko kanta istuu raspisda ramdiskillä.Sieltä se pari kertaa päivässä backupataan verkkoon.
Klikkaa laajentaaksesi...

Jos puhut Domoticzista, ja sen omista historiadatoista, niin eivät ehkä ole vertailukelpoisia vaikkapa repomiehen sekuntitason keruudataan. Domoticz ei tallenna keruutasoa lainkaan, lyhin aggregointi on 5 minuutin tasolle ainakin lämpötiladatassa. Sitäkin tallennetaan vain kolme päivää, sitten hypätäänkin jo vuorokausitason aggregointiin. Eihän tuolla tapaa kantaan jää kuin mitättömän pieni rahtunen keruudatasta, jos sitä vertaa siihen, että tallennetaan sekunnin keruuvälillä joka ainoa näyte.
 
tet sanoi:
Jos puhut Domoticzista, ja sen omista historiadatoista, niin eivät ehkä ole vertailukelpoisia vaikkapa repomiehen sekuntitason keruudataan. Domoticz ei tallenna keruutasoa lainkaan, lyhin aggregointi on 5 minuutin tasolle ainakin lämpötiladatassa. Sitäkin tallennetaan vain kolme päivää, sitten hypätäänkin jo vuorokausitason aggregointiin. Eihän tuolla tapaa kantaan jää kuin mitättömän pieni rahtunen keruudatasta, jos sitä vertaa siihen, että tallennetaan sekunnin keruuvälillä joka ainoa näyte.
Klikkaa laajentaaksesi...

RRD, Graphite jne käyttävät tuota aggrekoivaa kehäpuskurointia. Virittelin itse aikoinaan RRD:n puskureita vähän isommiksi onewiredatalle. Aikasarjakannat, vaikka prometheus tai influxdb käyttävät tyypillisesti delta-delta tallennusta joka toimii tasavälisellä näytteenotolla hyvin. Ajattelin tuossa laittaa kymmenen vuoden datat influxdb:n uumeniin raspiin ihan kokeeksi, saas nähdä saanko aikaiseski.
 
tet sanoi:
Jos puhut Domoticzista, ja sen omista historiadatoista, niin eivät ehkä ole vertailukelpoisia vaikkapa repomiehen sekuntitason keruudataan
Klikkaa laajentaaksesi...

Juuei, mutta kun optimoinneista puhutaan, niin tuo on se tavanomainen. 10 vuoden data mahtuu muistiin heittämällä. Ei ole mitään todellista tarvetta hautoa vuositolkulla sekuntitason dataa kotisysteemeistä. Kotiin sekoitettuja järjestelmiä ei siis kannata yksinkertaisesti edes yrittää optimoida sellaiseen.
 
pamppu sanoi:
Juuei, mutta kun optimoinneista puhutaan, niin tuo on se tavanomainen. 10 vuoden data mahtuu muistiin heittämällä. Ei ole mitään todellista tarvetta hautoa vuositolkulla sekuntitason dataa kotisysteemeistä. Kotiin sekoitettuja järjestelmiä ei siis kannata yksinkertaisesti edes yrittää optimoida sellaiseen.
Klikkaa laajentaaksesi...

No itse asiassa kyllä ja ei - yhtenä ajatuksena tuossa influxdbjutussa olisi nimenomaan vanhojen, 'tarkkojen' datojen vertaaminen nykyisiin. Aikoinaan pidin MLp:n päällä Vaillantin huoltosoftaa ajelevaa vanhaa läppäriä joka talletti satoja asioita / rivi cvs-filuun. Ei nyt sekunnin välein, mutta vuosikausia kutakuinkin yhteen menoon. Voisi sieltä nähdä onko vaikka tevin toiminta muuttunut tms. anomaliaa tullut vuosien varrella.
 
pamppu sanoi:
Juuei, mutta kun optimoinneista puhutaan, niin tuo on se tavanomainen. 10 vuoden data mahtuu muistiin heittämällä. Ei ole mitään todellista tarvetta hautoa vuositolkulla sekuntitason dataa kotisysteemeistä. Kotiin sekoitettuja järjestelmiä ei siis kannata yksinkertaisesti edes yrittää optimoida sellaiseen.
Klikkaa laajentaaksesi...

Kuten tuossa jo tulikin esille, niin vianselvitykseen tuollainen tarkka historiadata on aika kätevää. Mutta noin yleisesti juu, ei ole tarvetta kotona moiselle. Itse painiskelen töissä kohtuullisen kokoisen prosessiteollisuuden laitoksen historiatietokannan kanssa, ja sielläkin keruutaso on vain kaksi vuotta, sitä pidemmät historiat ovat aggregoituja. Dataa kerätään pääosin 10 sekunnin välein, osasta sekunnin välein. Mutta tuotakaan keruudataa ei yleensä lykätä kantaan ihan sellaisenaan, vaan pakattuna. Eli se ei ole tasavälistä, vaan tallennetaan vain kulmapisteet silloin kun datan trendi kääntyy.
 
TaloLogger näyttäis tarjoavan valmiina PostgreSQL, sama näyttää olevan grafanan valikossa tarjolla, en kylläkään ymmärrä näistä, olisiko tuo käyttökelpoinen kanta vs sqlite
 
korsteeni sanoi:
TaloLogger näyttäis tarjoavan valmiina PostgreSQL, sama näyttää olevan grafanan valikossa tarjolla, en kylläkään ymmärrä näistä, olisiko tuo käyttökelpoinen kanta vs sqlite
Klikkaa laajentaaksesi...

Postgresql on ns oikea tietokanta josta on kaupallinenkin versio - eli jos alkaa tökkiä niin vähän netissä opiskelemalla sitä saa tuunattua toimimaan paremmin - sqlite on sitten kevyempää tavaraa jolle ei välttämättä kovin paljon mahda. Possulle on tämmöisiä juttuja: https://grisha.org/blog/2015/09/23/storing-time-series-in-postgresql-efficiently/ - Grafana toimii parhaiten timeserieskantojen kanssa.
 
:oops: Ei ole Grafana projekti paljoa edistyny, sentään HA on tullut laitettua pyörimään Synologyyn :cool:
En tiiä mihin aika menee, ehkä se on vähän niin että mielenkiinto ei ole tarpeeksi suurta laittaa vaihdetta päälle.
 
Täällä varmaan on tietokantaosaajia jotka suoraan pystyvät sanomaan voiko sqlitestä postgres tietokantaa käyttää niin että siihen vielä logittaa dataa lisää. näin .dump' ista tehty kanta kun ei huoli enää dataa vaan herjaa tyyliin
26.01.2021 17:41:06: POSTGREDB: ERROR: Error in database operation, SQL: INSERT INTO talolog (time) VALUES (TO_TIMESTAMP(1611675600))

kun teen tyhjän tablen niin siihen akaa logittamaan mutta siihen ei taas huoli vanhaa dataa

ilmeisestikään noista ei voi yhtä kantaa tehdä
 
Tuo postgres.log näyttääkin ihan muuta
ERROR: duplicate key value violates unique constraint "talolog_pkey"
DETAIL: Key (id)=(32) already exists.
STATEMENT: INSERT INTO talolog (time) VALUES (TO_TIMESTAMP(1611676800))
 
No sitten tuo on selvä homma. Sun pitää vaihtaa vanhan kannan avaimet. Jos avainten ei tarvi olla järjestyksessä niin lisää tekstieditorilla vaikka 99999999 jokaisen vanhan ID alkuun.
 
Kiitos, id ongelma ratkesi
time ongelma ei vielä, tästä onkin enempi netissä juuri postgresql osalta, minullakin antaa perl herjan ja sain asennettua vasta kun muutin localiksi en_US.UTF-8

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US.UTF-8",
LC_ALL = "fi_FI.UTF-8",
LC_MESSAGES = "en_US.UTF-8",
LANG = "fi_FI.UTF-8"

pitää muutella vielä noita josko jollain lähtisi
 
Kyllä se lähti, muutin kaikki "en_US.UTF-8" ja talolog_id_seq suurin luku niin lähti tulille
99999999 ei tässä kohin toiminut kun heitti yhä tuplia

vinkkinä vielä että kun sqlitestä ajaa .csv tiedoston, niin siitä pitää poistaa se tyhjä viimeinen rivi ennenkuin dumppaa se postgres kantaan
nuo aikaleimat kannattaa myös harmonisoida
 
Viimeksi muokannut moderaattori:
ongelma ratkesi
 

Liitetiedostot

  • grafana.png
    grafana.png
    467,4 KB · Lukukerrat: 246
Viimeksi muokannut moderaattori:
tällaista se ilkeääkin herjata

influxdb.exceptions.InfluxDBClientError: 400: {"error":"partial write: field type conflict: input field \"value\" on measurement \"solax\" is type integer, already exists as type float dropped=7"}

mutta tällä rimpsulla menee x1 solaxin data influxiin
************
#!/usr/bin/python

import requests
import time
import sys
import json
from influxdb import InfluxDBClient

client = InfluxDBClient('localhost', 8086, '', '', 'talo')
url = "http://192.168.1.134/api/realTimeData.htm"
r = requests.get(url)
x1 = r.text
def main():
str = x1.decode("utf-8")
str = str.replace(",,", ",0,")
str = str.replace(",,", ",0,")
data = json.loads(str)

vals = {}
vals['PV1 Current'] = data['Data'][0]
vals['PV2 Current'] = data['Data'][1]
vals['PV1 Voltage'] = data['Data'][2]
vals['PV2 Voltage'] = data['Data'][3]
vals['Grid Current'] = data['Data'][4]
vals['Grid Voltage'] = data['Data'][5]
vals['Grid Power'] = data['Data'][6]
vals['Inner Temp'] = data['Data'][7]
vals['Solar Today'] = data['Data'][8]
vals['Solar Total'] = data['Data'][9]
vals['Feed In Power'] = data['Data'][10]
vals['PV1 Power'] = data['Data'][11]
vals['PV2 Power'] = data['Data'][12]
vals['Solar Total 2'] = data['Data'][19]
vals['Energy to Grid'] = data['Data'][41]
vals['Energy from Grid'] = data['Data'][42]
vals['Grid Frequency'] = data['Data'][50]
vals['Status'] = data['Data'][67]
# print(vals)

json_body = []
for key, value in vals.items():

json_body.append(
{
"measurement": "solax",
"tags": {
"device": key
},
"fields": {
"value": value
}
})

client.create_database('talo')
# print("Write points: {0}".format(json_body))
client.write_points(json_body)

if __name__ == "__main__":
main()
*********************
ei varmastikaan mikään tyylipuhdas, sinnepäinkään, mutta tuntus toimivan
 
Viimeksi muokannut moderaattori:
Se varmaan runttaa tuon koko hoidon yhteen kenttään 'vals' ja toiseen kenttään 'data' arvoksi - siihen tulee yksi kerros liikaa eikä influxdb tiedä mitä tekisi sen rakenteen kanssa kun sitä ei voi laittaa yhtenä numerona. Tuota 'data' dictionarya jonka avaimen 'Data' arvona on ilmeisesti yksi numerolista ei muutenkaan voi runtata sinne - joka numerolla pitää olla Influxdblle oma nimi niinkuin uossa "Grid Power" "Grid Power": data['Data'][6]. Eli "measurement": "solax", "tags": vals, "fields": .. saattaisi jopa pelata, mutta datan kanssa saa jumpata enemmän.
 
en nyt tiedä kui tämä on nerokkaampi, tekee rivejä pirusti verrattuna yhdentaulun sqlite tai psql
kuvan mukaista herjaa alkoi heittämään, kuuklaamalla syy on kun 'value' on float oletuksena ja siinhen tulee sekä kokonais että murtolukuja, tai olen ymmärtänyt väärin, toimii kuitenkin
 

Liitetiedostot

  • influx.jpg
    influx.jpg
    123,6 KB · Lukukerrat: 233
korsteeni sanoi:
en nyt tiedä kui tämä on nerokkaampi, tekee rivejä pirusti verrattuna yhdentaulun sqlite tai psql
Klikkaa laajentaaksesi...
no siinä kaksi juttua joista nyt sitten on iloa tai ei..

- kun siellä ei ole tauluja tuonne voi tuupata kaikenlaista ilman että kantaan tarvitsee enää koskea, koneita voi laittaa lisää ja datat ovat samantien kuvissa jos tagit on tehty sopivasti. Eli se on kätevä kaikenlaisessa monitoroinnissa kun juuri mitään ei tarvitse konffata siihen kannan päähän.

- se ymmärtää noiden aikasarjojen päälle ja tekee niihin sopivia asioita - en kyllä ole katsonut mitä se oletuksena tekee. Noin periaatteessa se osaa esmes delta-delta koodauksen. Eli kun tavallisessa kannassa on kenttä ja sillä sama koko riippumatta siitä mitä sinne laitetaan - niin tuo osaa tehdä niin että kun peräkkäin tulee 100000 ja 100001 se tallettaa sinne vaan 1. tämä kahdessa portaassa - siinä säästyy tilaa jos on salillinen koneita tuuppaamassa jotain CPU-käyttöä sekunnin välein.
 
Ainiin - minun keräykseni oli osittain rikki tuossa vähän aikaa kun laiskuuttani käytin multicast dns:ää - joka linuxissa asuu avahi-daemonissa. stop-start demonille sai taas homman rullaamaan, mutta meni kyllä aikaa ihmetellessä - grafana ei saanut yhteyttä datasourceen ( mutta ei valittanutkaan mitään ) ja osa keräyskoneista sai influxdb-yhteyden, osa ei. Täytyy konffailla tuo homma pelaamaan hostifiuilla.
 
ei näköjään pääse muokkailemaan aiempia joten
näin asensin psql busteriin

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
apt-get update
apt-get -y install postgresql

# service postgresql initdb
# systemctl enable postgresql
# systemctl start postgresqlS
ps -ef | grep postgres

pqadmin'illa helppo hallita

ja samaan busteriin influxdb

apt install -y gnupg2 curl wget
wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add -
echo "deb https://repos.influxdata.com/debian buster stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

apt update
apt install -y influxdb
systemctl enable --now influxdb

influx
CREATE DATABASE talo
SHOW DATABASES
USE talo
jne

ja nyt sitten se "helppo" grafana, kolmella klickauksella kuulemma kauniit kuvat
www.circuits.dk

How to install Grafana+InfluxDB on the Raspberry Pi - Circuits.dk

InfluxDB is an easy to use open-source time series database developed by InfluxData. It is written i
www.circuits.dk www.circuits.dk

edit
root@rockpi-4a:~# service grafana-server start
Failed to start grafana-server.service: Unit grafana-server.service not found.

pienen jumppailun jälkeen meni, ehkä buster/rockpi ei ollut ihan suoraan yhteensopiva raspin ohjeisiin
aika nopeesti se ensimmäinen kuva sieltä tuli
joku minua 60v nuorempi kännyköitä ikänsä räplännyt milleniaali saattaa varmaan byggata jonkun valmiin motonetin vermermee tai sipaton tai jonkun niistä sadoista saada nopeammin pilveen....no se siitä

talologgerhan on kaksi osainen tavallaan, se grafiikkapuolihan toimii täysin erillään ja voi korvata vaikka grafanalla jos niistä epäselvistä hämäristä graafeista pitää, no samat värithän saa muihinkin
talologger logittaa suoraan postressiin ja grafana taasen tukee sitä.....kokeilin ja toimii

kokeilen, kun sopivaa aikaa joskus talologgeria influxiin, se tuntuu nyt muutaman tunnin käpistelyn jälkeen aika joustavalle ja mielenkiintoiselle
 
Viimeksi muokannut moderaattori:
nyt menee taloLoggerista ~100 riviä/laaki influxdb kantaan, ei ainakaan alussa ahista kun sekunnin murto-osilla menee
 
Viimeksi muokannut moderaattori:
voiko tätä influxdb kantaa katsella/selailla/hallita jollain? samoin kuin postqressia pqadminilla tms. vai ainoastaan riviltä käskettynä
 
korsteeni sanoi:
voiko tätä influxdb kantaa katsella/selailla/hallita jollain? samoin kuin postqressia pqadminilla tms. vai ainoastaan riviltä käskettynä
Klikkaa laajentaaksesi...
Itse influxdbstä se on poistettu, mutta riippuen vähän tarkoituksesta ja alustasta kyllä niitä on.. influxdb gui -haulla löytyy erihenkisiä. En ole kokeillut, mutta kyllähän se tuunaamishetki vielä tulee. Grafanan kantaan jo vaihdoin datasourcen.. kun oli niitä dns-sotkuja.
 
toinen seikka hieman askarruttaa, kun nämä menee tyyliin "allekkain" ja rivejä tulee, niin jos ne laittaisi vierekäin kuten yhden taulun kanta? tulisi yhdellä timestampilla koko rivi = 100 riviä vähenpi joka työntö
nyt menee tyyliin näin

1613498525958217406 tvoc 1153
1613498525958217406 valoisuus 0
1613498525958217406 varaaja1 88
1613498525958217406 varaaja2 86
1613498525958217406 varaaja3 80
1613498525958217406 varaaja4 63
1613498525958217406 varaaja5 53
1613498525958217406 varaaja6 43
1613498525958217406 varaaja7 40
1613498525958217406 varaaja8 36
1613498525958217406 varaaja_pinta 20
1613498525958217406 varaajaerotus -1
1613498525958217406 varaajakulutus -1
1613498525958217406 varaajakwh 156
1613498525958217406 varaajapaine 0
1613498525958217406 varasto -5
1613498525958217406 veranta -7
1613498525958217406 vi_pa_et_me 38
1613498525958217406 virtaus 471
 
VesA sanoi:
Itse influxdbstä se on poistettu, mutta riippuen vähän tarkoituksesta ja alustasta kyllä niitä on.. influxdb gui -haulla löytyy erihenkisiä. En ole kokeillut, mutta kyllähän se tuunaamishetki vielä tulee. Grafanan kantaan jo vaihdoin datasourcen.. kun oli niitä dns-sotkuja.
Klikkaa laajentaaksesi...
ensimmäinen osuma Time Series Admin ajaa hyvin tarpeen, näkee että hanskaa
 
korsteeni sanoi:
toinen seikka hieman askarruttaa, kun nämä menee tyyliin "allekkain" ja rivejä tulee, niin jos ne laittaisi vierekäin kuten yhden taulun kanta? tulisi yhdellä timestampilla koko rivi = 100 riviä vähenpi joka työntö
nyt menee tyyliin näin

1613498525958217406 tvoc 1153
1613498525958217406 valoisuus 0
1613498525958217406 varaaja1 88
1613498525958217406 varaaja2 86
1613498525958217406 varaaja3 80
1613498525958217406 varaaja4 63
1613498525958217406 varaaja5 53
1613498525958217406 varaaja6 43
1613498525958217406 varaaja7 40
1613498525958217406 varaaja8 36
1613498525958217406 varaaja_pinta 20
1613498525958217406 varaajaerotus -1
1613498525958217406 varaajakulutus -1
1613498525958217406 varaajakwh 156
1613498525958217406 varaajapaine 0
1613498525958217406 varasto -5
1613498525958217406 veranta -7
1613498525958217406 vi_pa_et_me 38
1613498525958217406 virtaus 471
Klikkaa laajentaaksesi...
Onkohan missään kuvattu mitä se tuolle datalle lopulta tekee kun se talletetaan. Veikkaan ettei se talleta noista merkeistä mitään sellaisenaan - vaan tuo teksti on vaan ihmiselle tarkoitettu alias joka on kannassa ehkä vaan kerran, kuinkin rivin datasarja on jonain oman pötkönään ja aikaleimallekin on keksitty jotain ovelaa. Täytyy joku päivä tutkia sitä kantaa jollain dumpilla.
 
VesA sanoi:
Onkohan missään kuvattu mitä se tuolle datalle lopulta tekee kun se talletetaan. Veikkaan ettei se talleta noista merkeistä mitään sellaisenaan - vaan tuo teksti on vaan ihmiselle tarkoitettu alias joka on kannassa ehkä vaan kerran, kuinkin rivin datasarja on jonain oman pötkönään ja aikaleimallekin on keksitty jotain ovelaa. Täytyy joku päivä tutkia sitä kantaa jollain dumpilla.
Klikkaa laajentaaksesi...
jos se käytännössä menee niinkuin se on influxin first step osiossa selostettu, niin sen vaikutelman saa että kirjoitus tavoilla olisi eroa mutta näin tietokantaa tuntemattomattomana rakenne saattaapi ollakin ja varmaan onkin ettei samaa tagia sinne kuitenkaan miljoonia kertoja kirjoiteta vaan on jollain tapaa pakattuna/linkitettynä siellä kannassa ja saattaa olla muuttuvalla datalla samoin. tietokannan kokoa vertailemalla saisi ehkä jotain osviittaa.......sqlitessä on suuri vaikutus, esim raspissa ratkaiseva
 
Jos kannan koko huolettaa niin tuonnehan voi kytkeä päälle datan downsamplingin, ettei vanhaa aineistoa enää säilötä yhtä suurella tarkkuudella kuin tuoretta. Katselin tuossa omaa dataa vuoden takaa ja näyttää olevan kymmenen sekunnin tarkkuudella tiedot tallennettuna. Puoli minuuttia tai minuuttikin riittäisi hyvin jos tarkoitus on vaan nähdä summittaisia arvoja tai trendejä.
 
korsteeni sanoi:
toinen seikka hieman askarruttaa, kun nämä menee tyyliin "allekkain" ja rivejä tulee, niin jos ne laittaisi vierekäin kuten yhden taulun kanta? tulisi yhdellä timestampilla koko rivi = 100 riviä vähenpi joka työntö
nyt menee tyyliin näin

1613498525958217406 tvoc 1153
1613498525958217406 valoisuus 0
...
Klikkaa laajentaaksesi...
Siis minkä softan läpi sinä dataa työnnät, ei ainakaan suoraan influxiin? Eihän se tuollaista formaattia huoli. Vai onko siihen tullut line protocol -formaatin lisäksi joku muukin, jossa datan voi syöttää? Normaali line format on ihan eri näköistä: ensin on mittaus, sitten tagit ja fieldit, ja aikaleima rivin lopussa.
 
tet sanoi:
Siis minkä softan läpi sinä dataa työnnät, ei ainakaan suoraan influxiin? Eihän se tuollaista formaattia huoli. Vai onko siihen tullut line protocol -formaatin lisäksi joku muukin, jossa datan voi syöttää? Normaali line format on ihan eri näköistä: ensin on mittaus, sitten tagit ja fieldit, ja aikaleima rivin lopussa.
Klikkaa laajentaaksesi...
tämä on ihan suoraan influxista noudettua, komentorivilltä, influxin peruskäskyillä

tällä sen sinne survon, parannukset koodiin tervetulleita, ei varmasti kovinkaan oikeaoppista

def main():
json_body = []
for key in mydata.keys():
val = mydata[key]
try:
val = int(val)
except ValueError:
try:
val = float(val)
except ValueError:
pass

json_body.append(
{
"measurement": "LogData",
"tags": {
"device": key
},
"fields": {
"value": val
}
})

client.create_database('talo')
print("Write points: {0}".format(json_body))
client.write_points(json_body)

if __name__ == "__main__":
main()
 
korsteeni sanoi:
json_body.append(
{
"measurement": "LogData",
"tags": {
"device": key
},
"fields": {
"value": val
}
})
Klikkaa laajentaaksesi...
No nyt näyttää jo line protocol -formaatilta. Näemmä data kirjoitetaan ilman aikaleimaa, eli kanta itse antaa datalle aikaleiman kirjoitushetken mukaan. Se, miten data tulee ulos sitä hakiessa, tuskin kertoo mitään itse kannan rakenteesta. Ei tuota minusta oikein mitenkään muuten voi kirjoittaa, tuolla lailla mittaus kerrallaan se laitetaan. Toki tuota voi käyttää useammalla tapaa, riippuu miten tuota "mittausta" käsittelee. Itselläni mittauksia ovat esim. analogiadata, binääridata, laskurit jne., eli on vain muutama mittaus. Sitten mittausten alle laitan eri datat tageina. Eli esimerkiksi eri lämpötila-antureiden tiedot menevät kaikki samaan "mittaukseen" (measurement) influxin kannalta, mutta jokaisella datapisteellä on tagi "meas" jonka arvo kertoo mistä anturista on kyse. Fieldejä on muistaakseni vain yksi, "value", johon tulee mittausarvo. Voisihan sinne laittaa jotain kelpoisuustietoja ym. omiin fieldeihin, mutta muistaakseni en ole mitään laittanut. Tageja ja fieldejä voi lisäillä vaikka jälkikäteen, kun ne menevät joka mittapisteen mukana kantaan. Mutta tuo tapa, että käyttääkö esim. joka anturille oman measurementin, vai laittaako ne tageina, pitää toki valita ihan alussa, ja sen muuttaminen kesken kaiken on aika hankalaa ellei mahdotonta.
 
sieltähän ne grafanalla influxista kuvat tulee kuin postqressistakin
jos vain pelkkää linecharttia niin samassa ajassa minulta käy d3js kanssa
kauniita tehtäessä kyllä aikaa kysyy ainakin näin alkuun,,,, tulipahan kokeiltua

ensimmäinen grafana ja toinen, tuo punainen on sama lähdetiedosto d3js tehty, jostain syystä tää saitin ohjelma muokkaa ne epäteräviksi
 

Liitetiedostot

  • graf1.png
    graf1.png
    223 KB · Lukukerrat: 208
  • graf2.png
    graf2.png
    111,1 KB · Lukukerrat: 210
Viimeksi muokannut moderaattori:
Sinun täytyy kirjautua sisään tai rekisteröityä voidaksesi vastata viestiin.
Takaisin
Ylös Bottom