Datan visualisointi Grafanalla

[korsteeni]

No miltäs ne kippurat nyt näyttää?

just vertailin, kun samat värit ja ristikot laittaa niin ei siinä eroa ole millä ne on tehty
aloin kattelee miten nuo nettisivulle laitetaan

 

[korsteeni]

ei näitä grafanan graafeja kait pysty kotisivulla käyttämäänkään tyyliin d3js
puhelinpoikien metkuja

 

[korsteeni]

onko kellää tuo grafanan share embed käytössä, olen .ini'iin tehnyt muutokset muttei vaan tärppää
kun ottaa sen osoitteen niin toimii mutta embed eikä iframe ei toimi

 

[noble]

Talologgerin ja mysql:n vaihto mielessä node-rediin ja influxdb:hen.

Leikin tuolla node-redillä ja tietojen lähettäminen onnistui influxdb 1.x:ssä. Ja tietty grafanalla.

Mitä eroa tuolla Influxdb 2.0:lla on tuohon 1.x?
InfluxQL tietokanta vaihtuu fluxiksi... Hyöty? Ja saako tuota Raspberryllä pyörimään?

 

[VesA]

Talologgerin ja mysql:n vaihto mielessä node-rediin ja influxdb:hen.

Leikin tuolla node-redillä ja tietojen lähettäminen onnistui influxdb 1.x:ssä. Ja tietty grafanalla.

Mitä eroa tuolla Influxdb 2.0:lla on tuohon 1.x?
InfluxQL tietokanta vaihtuu fluxiksi... Hyöty? Ja saako tuota Raspberryllä pyörimään?

Kyllä se pyörii 4GB raspi4:lla ainakin ihan liukkaasti, tosin minulla on siinä USB3-ssd datalevynä. Tärkein ero versioissa - varsinkin Raspin kanssa - on se että vanhemmissa versioissa aikalaila luotetaan siihen että muistia riittää ja kanta koittaa ladata heti käynnistyksessä hirmusti - ja jos ei mahdu niin käy kehnosti. Uudemmissa versioissa voi valita ja oletukset ovat muutenkin erilaiset.

Influxdb on tilankäytöltään vähän arvaamaton - se on optimoitu säännöllisesti päivittyville aikasarjoille joissa data ei paljon muutu - kuten vaikka levytila - se tallettelee delttoja, ei itse arvoja, mutta jos nakuttaa vaikka ulkolämpötilaa 5min välein se on juurikin sitä mihin tuo on tehty.

 

[puuteknikko]

Tuuppasin Froniuksen tuottamaa dataa MariaDB:n alla pyörivään mysql-kantaan ja otin käppyräksi Grafanaan. Skripti lukee dataa Froniukselta viiden sekunnin välein, joten tunnissa tulee reilut 710 riviä dataa riippuen, miten pitkään kysely ja tallennus vie aikaa.

Vastaan tuli ihmeellinen ongelma. Jos asetan Grafanassa kaavion tarkkuudeksi Relative timellä "now-4h", ei Grafana suostu näyttämään kuin tunnin verran arvoja. Sama toki silloinkin jos pidän tuon oletuksena ja muutan kaikkien käppyröiden resoluution.

Esim. tälle kyselylle tulee noin 711-712 riviä tuloksia, vaikka pitäisi olla tietysti nelinkertainen määrä. Mielestäni nuo aikaleimat on oikein, siinä on 4h. Sql-kannassa timestamp-kenttä on tyyppiä Datetime ja arvot sisällä UTC-aikaa ilman mitään aikavyöhykettä (mallia vvvv-kk-pp tt:mm:ss).

SELECT
  Timestamp AS "time",
  Total_consumption AS "Consumption",
  PV_output AS "PV Output"
FROM measurements
WHERE
  Timestamp BETWEEN FROM_UNIXTIME(1632498219) AND FROM_UNIXTIME(1632512619)
ORDER BY Timestamp

Onko kenelläkään ideoita, mitä pitäisi tutkia seuraavaksi?

 

[tet]

^ Mitä mahdat tarkoittaa tuolla asetan Grafanassa kaavion tarkkuudeksi Relative timellä "now-4h", voitko tarkentaa? Siis laitat alkuajaksi tuon, vai loppuajaksi? Muuallehan tuollainen notaatio ei taida kelvata, kuin alku- ja loppuaikaan.

 

[puuteknikko]

^ Mitä mahdat tarkoittaa tuolla asetan Grafanassa kaavion tarkkuudeksi Relative timellä "now-4h", voitko tarkentaa? Siis laitat alkuajaksi tuon, vai loppuajaksi? Muuallehan tuollainen notaatio ei taida kelvata, kuin alku- ja loppuaikaan.

Käytännössä siis kun käytän oletuksena 12h näyttöä kaikille graafeille, halusin tuolle yksinään edellisen 4h aikavälin.

Jotenkin tuo poimii aina 3h lyhyemmän aikavälin graafiin kuin mitä määrittelen. Esimerkkikuvassa on 7h aikaväli, mutta dataa on saatu 4h edestä. Tuosta voisi päätellä, että aikavyöhykkeellä on jotain tekemistä asian kanssa. Grafana käyttää oletuksena Suomen aikavyöhykettä ja data on tosiaan UTC-timestampeilla mysql-kannassa. Olin vaan jostain lukenut, että UTC on järkevin valinta jos tietoa käytetään eri paikoissa.

 

[VesA]

Olin vaan jostain lukenut, että UTC on järkevin valinta jos tietoa käytetään eri paikoissa.

ennenkaikkea kippurat eivät käyttäydy kummasti kesä-talviaikaan vaihdettaessa.

Organization preferences | Grafana documentation

Organization preferences Grafana preferences are basic settings. They control the Grafana UI theme, home dashboard, time zone, and so on. Preferences are sometimes confusing because they can be set at four different levels, listed from highest level to lowest:

grafana.com

 

[puuteknikko]

Ongelma ratkesi, yön yli nukuttua oli taas ajatus kirkkaampi ja jaksoi haeskella lisää tietoa.

Grafanan data source-asetuksissa on muistettava asettaa "Session timezone" samaksi kuin aikavyöhyke, jonka mukaan tiedot on tallennettu kantaan. Luulin, että tuo liittyy siihen, mihin muotoon tiedot käännetään Grafanan päässä. Laitoin tuohon +0:00 niin näyttää tiedot oikein. Testasin ensin vaihtaa MariaDB:n palvelimen aikavyöhykkeen +0:00:ksi, mutta sillä ei ollut vaikutusta.

 

[korsteeni]

nyt tuli oikosulku korvien väliin, kuinka tuon aikaleiman saa lyhyemmäksi? siis pisteen jälkeen nuo 9 mumeroa pois

2022-05-28T04:52:09.212102915Z battery_voltage 49
2022-05-28T05:02:09.086276229Z battery_voltage 48
2022-05-28T05:12:08.767546691Z battery_voltage 47
2022-05-28T05:22:08.718902819Z battery_voltage 48
2022-05-28T05:52:11.405208767Z battery_voltage 49
2022-05-28T06:02:08.353373628Z battery_voltage 49
2022-05-28T06:12:08.576320543Z battery_voltage 48

tällä kyselen
influx -precision rfc3339
SELECT * FROM "LogData" WHERE "device"='battery_voltage' AND time >= '2022-05-28T00:00:00Z' AND time <= now()

eipä tuo muuta mutta komentorivillä kun jotain kattelee

 

[tet]

^ Vähän huonosti muistan enää Influxin juttuja, kun olen siitä siirtymässä pois omissa virityksissä. Mutta arvaan, että et mitenkään, ainakaan jälkikäteen. Jos tallennusvaiheessa valitset aikaleiman tarkkuudeksi vaikkapa sekunnin, ehkäpä se sitten antaa uloskin sekunnin tarkkuudella?

 

[fraatti]

Jahas, herätetään täällä ketjua henkiin taas.

Mites tälläinen homma saadaan hoitoon eli jos dataa ei ole valitulta ajanjaksolta, niin silloin jää käyrän alku piirtämättä. Käytössä Influxdb. Saako tuota mitenkään hakemaan viimeisintä arvoa? Muuten valittuna on fill previous.

 

[fraatti]

Kokeilen googlea, deepseekkiä ja chatgtp:tä ja tämän kummempaa ratkaisua en löytänyt ylläolevaan. Tämä ei ole täydellinen, mutta pelaa siis niin että kunhan aikavalinta on pidempi kuin ylhäällä oleva aikarajaus niin homma pelaa. Tietty edellyttää että dataa löytyy kauempaa.

AND $timeFilter siis korvataan....

.....Näillä... AND time >= now() - 200h AND time <= now() Ajan voi arpoa itse sopivaksi.

 

[fraatti]

Kuinkas tässä tehdään sellainen graafi että siinä on useampia eri datoja esillä samaan aikaan? Pikaisella ronkkimiselle moinen ei onnistunut.

 

[puuteknikko]

Kuinkas tässä tehdään sellainen graafi että siinä on useampia eri datoja esillä samaan aikaan? Pikaisella ronkkimiselle moinen ei onnistunut.

Sinne pitää luoda useampi kysely samalle graafille. Oliko ne nyt merkitty A, B jne. Eri kyselyillä voi olla eri tietolähteet. Itsellä on useampikin graafi, joissa on sekä InfluxDB:n että MySQL-kannan tietoja.

 

[fraatti]

Sinne pitää luoda useampi kysely samalle graafille. Oliko ne nyt merkitty A, B jne. Eri kyselyillä voi olla eri tietolähteet. Itsellä on useampikin graafi, joissa on sekä InfluxDB:n että MySQL-kannan tietoja.

Kyselyitä ei ole kuin yhdestä tietokannasta, mutta ajatuksena olisi ollut saada nuo molemmat graafit samaan paneliin.

Field override taitaa olla tuohon ratkaisu. Vieläkun keksisi että miten siihen saa yhdistettyä useamman queryn yhden sijaan.

 

[wannabe]

/\ tosta klikaten nii jo pääsee uutta käppyrää väsäämään.

 

[fraatti]

Näytä liitetiedosto 104589
/\ tosta klikaten nii jo pääsee uutta käppyrää väsäämään.

Joo, kyllä queryt(kyselyt) tietokannasta ovat tuttuja jossain määrin.

Tarkoituksena oli siis esittää kahda eri tietoa samassa graafissa. Tässä tapauksessa lämpötilaa ja binaarista tietoa että onko joku asia päällä vai ei. Nämä tiedot eivät tuolloin sovi samalla akselille.

Kunhan kaikella datalle on queryt tehtyinä, niin tuolta oikealta löytyy tuo override. Sillä saa toisenmoisia käppyröitä tuohon päälle. Valitsemalla saa yksittäisiä datoja esitettyä, mutta en keksinyt miten yhdellä override:llä pysytyisi visualisoimaan esim kaikki binaariset arvot yhdelllä kertaa niin ettei jokaista tarvi muotoilla erikseen.

Homeassistantti oli tallennellut binaariset/boolean arvot numeroina. Kun ne muutti joko boolean tai other datatyypiksi, niin se jälkeen override:llä sai muokattua kaikkien kolmen queryn visualisointia yhdellä kerralla.

Jos datatyypiksi vaihtaa boolean, niin sitten saa tuollaisia on/off värityksiä tuonne pohjalle. En taida kuitenkaan itse välittää tuosta.

Tuollaisia on-off tietoja on aivan mahdoton esittää järkevästi, ellei aikaa haulle muuta aikaisemmin mainitulla tavalla. Muuten graafista jää piirtymättä aina vasemmalta jotain ja graafista saa aivan eri kuvan kuin mikä on todellisuus.

 

[fraatti]

Jossain vaiheessa kokeilin suorittaa tuolla Grafanassa jotain laskutoimituksia. Ne ei olleet mitään kovin suuria menestyksiä ja päänvaivaa ilmeisesti aiheutti se että aikaleimoissa oli heittoa keskenään. Pikaisella googletuksella interpoloinnilla voisi saada jotain aikaiseksi, mutta vaikutti aikas hankalalle.

Jos nyt ajatellaan vaikka että haluaisi erotella että tekeekö mlp käyttövettä vai lämmitysvettä niin nämä asiat selviävät kahdesta 0/1 anturista(kompressori ja käyttövesi). Taitaa olla helmpompi tehdä template Homeassitanttiin joka tallentaa nämä suoraan tietokantaan?

Tuota tietoa voi sitten käyttää vaikka erottelemaan että koska kone jauhaa käyttövettä ja koska lämmitystä ja kaippa niistä voi laskeskella käyntiaika % tai mitä nyt sitten keksiikään.

 

[fraatti]

Raapullaan tähän, jos vaikka sattuisi joskus olemaan avuksi jollekin...

Tosinaan jos aikasarjoissa on eri aikaleimat, niin matemaattiset operaatiot eivät onnistu. Tuo antaa tuollaisen herjan silloin. Laskutoimitus kylläkin tehdään siitä huolimatta. Kyllästyin sitten tuon rassaamiseen.

Ratkaisu on sitten tehdä laskutoimitus jo Home Assistantissa

Samalla tietty selvisi että valmistaja on pihistänyt pilvipalvelussaan datansiirrossa. Ilmeisesti vain muuttunut data siirretään ja siirtoon vaadittava muutos on sitten 1-0.1 astetta, parametrista riippuen. Aikas perseestä. Tuon näkee noista liuoksen lämpötiloista hyvin. Toinen päivittyy 0.1 asteen portaissa ja toinen 0.5 asteen.

 

[puuteknikko]

Itsekin olen todennut Grafanassa tehtävän laskennan usein turhan hankalaksi, tai sitten se ei onnistu, joten kaikki laskenta tehdään tiedonkeruuvaiheessa ja tallennetaan SQL-kantaan valmiiksi laskettuna. Alkuperäiset luvut on toki nekin tallennettu, joten korjauslaskentaa voi tehdä jos huomaa virheitä. Muutaman kerran on saanut laskea taulun läpi korjauksia, onneksi AI-ratkaisut tekaisee kyselyt näppärästi

 

[Hegsa]

Grafanan kanssa jos haluaa tehdä yhtään enempää jälkikäsittelyä suosittelen vahvati Apache EChartsia/Business Chartsia. Aikoinaan tuo tuli asennettua kumulatiivisten energiakuvaajien tekoon, mutta pienellä pätkällä koodia tuolla saa tehtyä kaikkea muutakiin hyödyllistä mihin perus-Grafana ei suoraant taivu.

 

[fraatti]

Grafanan kanssa jos haluaa tehdä yhtään enempää jälkikäsittelyä suosittelen vahvati Apache EChartsia/Business Chartsia. Aikoinaan tuo tuli asennettua kumulatiivisten energiakuvaajien tekoon, mutta pienellä pätkällä koodia tuolla saa tehtyä kaikkea muutakiin hyödyllistä mihin perus-Grafana ei suoraant taivu.

Taitaa kyllä mennä multa yli hilseen tuollainen.


Tekisi mieli tietää että paljonko kone käy tunteja missäkin lämpötilassa ja paljonko se huilii. Tälläiset numeeriset arvot viimeiseltä 7 vrk:lta sai helposti tehtyä. Tässä lämmityksen ja käyttöveden tunnit ovat vielä pielessä, koska sensorit lämmitykselle ja käyttövedelle ovat vielä niin tuoreita. Yllättävän yksinkertaisesti nuo kuitenkin syntyivät.

Onnistuukos tuo niin että ne olisi tuossa päivittäin keskilämpötilan mukaan jossain graafissa? Ajatuksena olisi vähän kattella pörssisähköohjausta silmälläpitäen että paljonko koneelle pitää antaa käyntiaikaa päivittäin, jotta tölli pysyy lämpöisenä. Toki tuo pörssisähköohjaus sotkee, mutta ehkä siitä voisi saada jotain selvää kuitenkin....

 

[repomies]

^Kuulostaa siltä että haluat jonkinlaisia histogrammeja datasta.

Homeassistantin tietokanta taisi olla joku TSDB. Jos sen voisi korvata Prometheuksella, tai jos se jotenkin muuten tarjoaisi PromQL-tuen, niin sitten saisit histogrammit ulos aika helposti.

Metric types | Prometheus

Prometheus project documentation for Metric types

prometheus.io

 

[fraatti]

^Kuulostaa siltä että haluat jonkinlaisia histogrammeja datasta.

Homeassistantin tietokanta taisi olla joku TSDB. Jos sen voisi korvata Prometheuksella, tai jos se jotenkin muuten tarjoaisi PromQL-tuen, niin sitten saisit histogrammit ulos aika helposti.

Metric types | Prometheus

Prometheus project documentation for Metric types

prometheus.io

Joo, ei tuosta mun kyselystä tullutkaan mitään. Kaippa tuo aikasarja aiheuttaa ongelmia. Lukemat näyttivät kohtuulisen järkeville, mutta ei ne silti pitäneet paikkaansa. Kaippa tuohon jotain helpperiä pitää koittaa virittää HA:n puolelle. Täytyy nyt koittaa pärjätä tuon InfluxDB:n kanssa.

Jännä kuinka epäloogisesti tämäkin käyttäytyi

{{ is_state('binary_sensor.cu401b_g_dhw_charging', 'on') and is_state('binary_sensor.cu401b_g_compressor', 'on') | bool  }}

ilman tuota bool osuutta. Se palautti välillä arvon 0.5.