🥇Nutika kodu: Koostame vee ja elektritarbimise graafikud Home Assistant'is

I am always surprised every time I receive the bill for electricity and water — does my family really consume that much? Well, yes, there is a heated floor and a boiler in the bathroom, but they don't run constantly. We also seem to save water (although we do enjoy splashing around in the bath). A few years ago, I already connected the water meters ja electricity to the smart home system, but that’s where the progress stopped. I only got around to analyzing consumption now, which is what this article is about.

Recently, I switched to Home Assistant as my smart home system. One of the reasons was precisely the opportunity to collect a large amount of data with the ability to conveniently create various types of graphs.

The information described in this article is not new; all these things have already been discussed on the Internet under different guises. However, each article usually focuses on just one approach or aspect. It was up to me to compare all these approaches and choose the most suitable one. The article still doesn’t provide exhaustive information on data collection, but serves as a kind of summary of how I did it. So constructive criticism and suggestions for improvement are welcome.

Ülesande seadmine

So, the purpose of today’s exercise is to get nice graphs of water and electricity consumption:

Hourly for 2 days
Daily for 2 weeks
(optionally) weekly and monthly

We face some difficulties in this:

The standard graph components are usually quite poor. At best, you can create a line graph from points.
If you search well, you can find third-party components that extend the capabilities of the standard graph. For Home Assistant, the component mini-graph-cardis relatively good and attractive, but it is also somewhat limited:
- It's challenging to set parameters for a bar graph over large intervals (the width of the bars is set in fractions of an hour, meaning intervals longer than an hour will be set in decimal numbers)
- You cannot add different entities to one graph (for example, temperature and humidity, or combine a bar graph with a line)

Lisaks sellele, et home assistant kasutab vaikimisi kõige primitiivsemat andmebaasi SQLite (ja mina, oskamatu, ei suutnud MySQL või Postgresit installida), on andmed salvestatud ka mitte kõige optimaalsemalt. Näiteks iga väikese digitaalse parameetri muutmise korral salvestatakse andmebaasi hiiglaslik json, mille suurus on umbes kilobait.

{"entity_id": "sensor.water_cold_hourly", "old_state": {"entity_id": "sensor.water_cold_hourly", "state": "3", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:05:06.897604+00:00", "last_updated": "2020-02-23T19:05:06.897604+00:00", "context": {"id": "aafc8ca305ba4e49ad4c97f0eddd8893", "parent_id": null, "user_id": null}}, "new_state": {"entity_id": "sensor.water_cold_hourly", "state": "4", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:11:11.251545+00:00", "last_updated": "2020-02-23T19:11:11.251545+00:00", "context": {"id": "0de64b8af6f14bb9a419dcf3b200ef56", "parent_id": null, "user_id": null}}}

Mul on üsna palju andureid (temperatuuriandurid igas toas, vee- ja elektri arvestid), ning mõned neist genereerivad ka piisavalt palju andmeid. Näiteks vaid elektriarvesti SDM220 genereerib umbes kümme väärtust iga 10-15 sekundi tagant, ja ma soovin paigaldada selliseid arvesti umbes 8. Lisaks on terve partii parameetreid, mis arvutatakse teiste andurite põhjal. Seega võivad kõik need väärtused kergesti muuta andmebaasi 100-200 MB võrra iga päev. Nädala pärast hakkab süsteem vaevalt töötama ja kuu aja pärast sureb mälupulk (tüüpilise home assistant paigaldamise korral Raspberry PI-l), rääkimata andmete säilitamisest aasta jooksul.

Kui sul on vedanud, siis su arvesti oskab ise seda tarbimist lugeda. Sa saad igal hetkel pöörduda arvesti poole ja küsida, mis kell on akumuleeritud tarbimise väärtus. Üldjuhul pakuvad kõik elektriarvestid, millel on digitaalne liidese (RS232/RS485/Modbus/Zigbee), sellist võimalust.
Halvem, kui seade suudab lihtsalt mõõta mõningast kohest parameetrit (näiteks kohest võimsust või voolu) või lihtsalt genereerida impulsse iga X vatundi või liitri järel. Siis tuleb mõelda, kuidas ja millega seda integreerida ning kus väärtust koguda. On oht, et mõni aruanne jääb ikka vahele mingil põhjusel ja süsteemi täpsuse üle on küsimusi. Muidugi võib kogu selle ülesande usaldada nutika kodu süsteemile nagu home assistant, kuid andmebaasi salvestuste hulk on üks asi, mis kedagi ei vabasta, ja andurite küsitlemine sagedamini kui kord sekundis ei õnnestu (home assistanti arhitektuurist tingitud piirang).

Lähenemine 1

Käivitusel vaatame, mida home assistant pakub. Tarbimise mõõtmine perioodil on üsna nõutud funktsionaalsus. Kindlasti on see juba ammu realiseeritud spetsialiseeritud komponendina - utility_meter.

Komponendi põhimõte on selles, et see loob sees tekundi muutuja tekkinud_akkumuleeritud_väärtus, ja nullib selle määratud perioodi (tund/nädal/kuu) lõppedes. Komponent jälgib ise sisenevat muutujat (mõne anduri väärtust), kirjutab end ise väärtuse muutustele alla - te saate lihtsalt valmis tulemuse. Selle kirjeldamine nõuab vaid mõnda rida konfiguratsioonifailis.

utility_meter:
  water_cold_hour_um:
    source: sensor.water_meter_cold
    cycle: hourly
  water_cold_day_um:
    source: sensor.water_meter_cold
    cycle: daily

Siin on sensor.water_meter_cold praegune väärtus mõõturis liitrites, mille ma olen saanud otse rauast mqtt kaudu. Konstruktsioon loob 2 uut andurit water_cold_hour_um ja water_cold_day_um, mis koguvad tunni- ja päevaseid näitajaid, nullides need perioodi lõppedes. Siin on graafik tunni akumulaatori poolest päevast.

Tunni- ja päevagraafiku kood lovelace-UI jaoks näeb välja selline:

      - type: history-graph
        title: 'Tunni veetarbimine varside kasutamisega'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Päevane veetarbimine varside kasutamisega'
        hours_to_show: 360
        entities:
          - sensor.water_day

Tegelikult on selle algoritmi probleem just selles. Nagu ma juba mainisin, genereeritakse iga sisendi väärtuse (praegune arvesti näit kwh kohta) jaoks andmebaasi 1 kB kirje. Iga utiliidi arvesti genereerib samuti uue väärtuse, mis ka salvestatakse andmebaasi. Kui ma tahan koguda tunniseid/päevaste/nädalaste/kuuliste näite, ja lisaks veel mitmeid veesüsteeme ning hunniku elektriarvestit, siis andmeid tuleb väga palju. Tõenäoliselt ei ole need andmed nii tõsised, aga kuna kodu assistent salvestab andmebaasi palju üleliigset teavet, siis andmebaasi suurus kasvab nagu pärmitaigen. Kardan isegi nende nädalaste ja kuiste graafikute andmebaasi suurust hinnata.

Lisaks ei lahenda utiliidi arvesti iseenesest seatud ülesannet. Arvesti, mille väärtused genereerib utiliidi arvesti, on monotoonselt kasvav funktsioon, mis nullitakse igal tunnil. Meile on vajalik kasutajale arusaadav tarbimise graafik, näidates, kui palju liitreid on perioodi jooksul tarbitud. Standardne koostisosa ajaloograaf ei oska seda teha, kuid abi saab välisest komponendist mini-graph-card.

See on lovelace-UI kaartide kood:

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Tunnine veetarbimise kokkuvõte utiliidi arvesti järgi"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Lisaks standardsetele seadistustele, nagu sensori nimi, graafiku tüüp, värv (tavaline oranž ei meeldinud), on oluline märkida kolm seadistust:

group_by: hour — graafik genereeritakse, ritta seades tükid tunni alguse järgi
points_per_hour: 1 — üks tükike igal tunnil
Ja kõige olulisem, aggregate_func: max — võtta iga tunni jooksul maksimaalne väärtus. Just see parameeter muudab saagide graafiku tükikesteks.

Vasakpoolsete tükikeste rida ärge tähelepanu pöörake — see on komponendi standardne käitumine, kui andmeid ei ole. Ja andmeid tõepoolest ei olnud — lülitasin andmete kogumise utiliidi arvesti järgi sisse vaid paar tundi tagasi ainult selle artikli jaoks (oma praegusest lähenemisest räägin veidi hiljem).

Selle pildil tahtsin näidata, et mõnikord andmete kuvamine isegi töötab ja veergud peegeldavad tõepoolest õigeid väärtusi. Ainult et need ei ole kaugeltki kõik õiged. Toodud veerg ajavahemiku 11 kuni 12 hommikul näitab mingil põhjusel 19 liitrit, kuigi hambuline graafik veidi kõrgemal näitab sama perioodi jooksul sama sensoriga tarbimist 62 liitrit. Kas tegemist on veaga või on tegu halva töötlusega. Ja miks andmed paremal pool kadusid, ei ole ma veel aru saanud – seal oli tarbimine normaalne, mis on samuti nähtav hambulisel graafikul.

Ühesõnaga, selle lähenemise usutavust mulle saavutada ei õnnestunud – graafik näitab peaaegu alati mingit jama.

Sarnane kood päevaksensorile.

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Päevane veetarbimine utiliidimõõtjate kaupa"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Pange tähele, et parameeter group_by on seadistatud väärtusele interval ja kõik punktid per tund sõltuvad sellest. Ja selles peitub veel üks selle komponendi probleem – points_per_hour töötab hästi graafikute puhul, mis on ühe tunni või vähem, kuid on kohutav pikemate ajavahemike korral. Nii tuli ühe päeva jaoks saada üks veerg, peab sisestama väärtuse 1/24=0.04166666. Ma ei räägi isegi nädalaste ja igakuiste graafikute kohta.

Lähtekoht 2

Veel olles kodu assistendi kallal uurimas, sattusin sellele videole:

Sõber kogub andmeid tarbimise kohta mitmest erinevast Xiaomi pistikust. Tema ülesanne on veidi lihtsam – lihtsalt kuvada tarbimise väärtus täna, eile ja kuu jooksul. Graafikuid pole vaja.

Jätame kõrvale arutlused käsitsi integreerimise kohta hetketegevuse väärtustest – olen juba eespool kirjutanud sellise lähenemise "täpsusest". Pole selge, miks ta ei kasutanud akumuleeritud tarbimisandmeid, mis juba samalt pistikult kogutakse. Minu arvates töötab integreerimine seadmest paremini.

Videost võtame idee käsitsi tarbimise arvestamise perioodi jooksul. Mehe puhul arvestatakse ainult täna ja eile, kuid meie läheme kaugemale ja proovime joonistada graafiku. Esitatud meetodi olemus minu juhul on järgmine.

Loome muutuja väärtus_alguses_tunnis, kuhu salvestame praegused arvesti näidud.
Iga tunni lõpus (või järgmise tunni alguses) arvutame praeguse näidu ja tunni alguses salvestatud näidu vahelise erinevuse. See erinevus on praeguse tunni tarbimine — salvestame väärtuse sensorisse ja tulevikus kasutame seda väärtust graafiku koostamiseks.
Samuti tuleb "nullida" muutuja väärtus_alguses_tundi, kirjutades sinna praeguse arvesti väärtuse.

Kõike seda saab teha läbi home assistant'i enda vahendite.

Koodi tuleb kirjutada natuke rohkem kui eelmises lähenemises. Alustuseks loome need "muutujad". Meil ei ole vaikimisi olemas "muutuja" olemasolu, kuid saame kasutada mqtt vahendajat. Saame sinna saata väärtuseid retain=true lipuga — see salvestab väärtuse vahendajas ja selle saab igal ajal sealt kätte, isegi home assistant'i taaskäivitamisel. Tehtud on kohe tunni ja päevased arvestid.

- platform: mqtt
  state_topic: "test/water/hour"
  name: water_hour
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/hour_begin"
  name: water_hour_begin
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day"
  name: water_day
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day_begin"
  name: water_day_begin
  unit_of_measurement: l

Kogu maagia toimub automaatikas, mis käivitub iga tunni ja iga öö jooksul vastavalt.

- id: water_new_hour
  alias: water_new_hour
  initial_state: true
  trigger:
    - platform: time_pattern
      minutes: 0
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/hour"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_hour_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/hour_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

- id: water_new_day
  alias: water_new_day
  initial_state: true
  trigger:
    - platform: time
      at: "00:00:00"
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/day"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_day_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/day_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

Mõlemad automaatikad täidavad 2 toimingut:

Arvutavad intervalli väärtuse alg- ja lõppväärtuse vahe.
Uuendavad baasväärtuse järgmiseks intervalliks.

Graafikute koostamine lahendatakse antud juhul tavalise history-graphiga:

      - type: history-graph
        title: 'Tunni veetarbimine varside kasutamisega'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Päevane veetarbimine varside kasutamisega'
        hours_to_show: 360
        entities:
          - sensor.water_day

See näeb välja nii:

Põhimõtteliselt on see juba see, mida on vaja. Selle meetodi plussiks on see, et andmeid genereeritakse üks kord intervalli jooksul. St, päeva jooksul ainult 24 salvestust tunnigraafiku jaoks.

Kahjuks ei lahenda see liikvele paisuva baasi üldprobleemi. Kui ma soovin kuupõhist tarbimist, tuleb mul andmeid hoida vähemalt aasta. Ja kuna home assistant pakub ainult ühte salvestusaja seadet kogu andmebaasi jaoks, tähendab see, et KÕIK andmed süsteemis tuleb hoida terve aasta. Näiteks tarbin ma aastas 200 kuupmeetrit vett, mis tähendab 200000 kirjet andmebaasis. Ja kui arvestada ka muid sensoreid, muutub number äärmiselt suureks.

Lähenemine 3

Õnneks on nutikad inimesed selle probleemi juba lahendanud, kirjutades andmebaasi InfluxDB. See andmebaas on spetsiaalselt optimeeritud ajapõhiste andmete salvestamiseks ja sobib ideaalselt erinevate sensorite väärtuste hoidmiseks. Süsteem pakub ka SQL-sarnast päringukeelt, mis võimaldab andmebaasist väärtusi välja kaevata ja seejärel neid erinevatel viisidel kokku koondada. Lõpuks on erinevaid andmeid võimalik hoida erinevat aega. Näiteks kiiresti muutuvaid näitajaid, nagu temperatuur või niiskus, võib hoida vaid paar nädalat, samas kui päevaseid veetarbimise näitajaid võib hoida terve aasta.

Peale InfluxDB on nutikad inimesed leiutanud ka Grafana — süsteemi, mis joonistab graafikuid InfluxDB andmete põhjal. Grafana oskab joonistada erinevat tüüpi graafikuid, neid detailselt kohandada ja, mis kõige tähtsam, neid graafikuid saab "paigaldada" home assistant'i lovelace-UI-le.

Inspireerib siit ja siit. Artiklites on detailselt kirjeldatud InfluxDB ja Grafana paigaldamise ja ühendamise protsessi home assistant'iga. Ma keskendun enda konkreetse ülesande lahendamisele.

Nii et alustame kohe, hoides arvesti väärtust influxDB-s. Home assistant'i konfiguratsiooni lõik (selles näites ka mängin mitte ainult külma vaid ka sooja veega):

influxdb:
  host: localhost
  max_retries: 3
  default_measurement: state
  database: homeassistant
  include:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Kätkeme nende samade andmete salvestamist home assistant'i sisemisse andmebaasi, et mitte seda liigse koormuse alla suruda:

recorder:
  purge_keep_days: 10
  purge_interval: 1
  exclude:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Lähme nüüd InfluxDB konsooli ja seadistame meie andmebaasi. Eriti tuleb seadistada, kui kaua hoitakse erinevaid andmeid. Seda reguleerib nn retention policy — see on sarnane andmebaasidele põhjaandmebaasis, kus igal sisseehitatud andmebaasil on oma seadistused. Vaikimisi salvestatakse kõik andmed retention policy all nimega autogen, need andmed hoitakse nädala. Tahaksin, et tunnipõhised andmed hoitaks kuu aega, nädalased — aasta, ja kuupõhised andmed ei eemaldataks kunagi. Loome vastavad retention policy.

CREATE RETENTION POLICY "month" ON "homeassistant" DURATION 30d REPLICATION 1
CREATE RETENTION POLICY "year" ON "homeassistant" DURATION 52w REPLICATION 1
CREATE RETENTION POLICY "infinite" ON "homeassistant" DURATION INF REPLICATION 1

Nüüd, tegelikult, peamine trikk — andmete agregatsioon continuous query kaudu. See on mehhanism, mis automaatselt käivitab päringu teatud ajavahemike järel, agregatsiooni tulemuse salvestab uutesse väärtustesse. Vaatame näidet (kirjutan vertikaalselt, et oleks lihtsam lugeda, kuid tegelikult pidin selle käsu sisestama ühel real).

CREATE CONTINUOUS QUERY cq_water_hourly ON homeassistant 
BEGIN 
  SELECT max(value) AS value 
  INTO homeassistant.month.water_meter_hour 
  FROM homeassistant.autogen.l 
  GROUP BY time(1h), entity_id fill(previous) 
END

See käsk:

Loob continuous query nimega cq_water_cold_hourly andmebaasis homeassistant.
Päringut teostatakse iga tunni järel (time(1h)).
Päring kogub kõik andmed mõõtmisest homeassistant.autogen.l (liitrid), sealhulgas külma ja sooja vee näidud.
Agregatsiooni tulemused grupeeritakse entity_id järgi, mis loob meile eraldi väärtused külma ja sooja vee jaoks.
Kuna liitrite arvesti on monotoonselt kasvav järjestus, tuleb igas tunnis võtta maksimaalne väärtus, seetõttu teostatakse agregatsioon max(value) funktsiooni abil.
Uus väärtus salvestatakse homeassistant.month.water_meter_hour, kus month on retention policy nimi, mille säilitamise aeg on kuu. Külma ja sooja vee andmed jaotatakse eraldi kirjetesse koos vastava entity_id ja väärtusega väljades.

Öösel või kui kedagi kodus ei ole, pole veetarbimist ja seetõttu pole uusi kirjeid homeassistant.autogen.l-is samuti. Olgugi, et tavalistes päringutes pole väärtuste puudumise vältimiseks soovitatav kasutada fill(previous). See paneb InfluxDB kasutama eelneva tunni väärtust.

Kahjuks on continuous query'l üks omadus: trick fill(previous) ei toimi ja kirjed lihtsalt ei genereerita. See on mingi ületamatu probleem, mida on arutatud juba aastaid. Selle probleemiga tegeleme hiljem, seesama fill(previous) continuous query's võib jääda, see ei sega.

Kontrollime, mis välja tuli (loomulikult tuleb oodata paar tundi):

> select * from homeassistant.month.water_meter_hour group by entity_id
...
name: water_meter_hour
tags: entity_id=water_meter_cold
time                 value
----                 -----
...
2020-03-08T01:00:00Z 370511
2020-03-08T02:00:00Z 370513
2020-03-08T05:00:00Z 370527
2020-03-08T06:00:00Z 370605
2020-03-08T07:00:00Z 370635
2020-03-08T08:00:00Z 370699
2020-03-08T09:00:00Z 370761
2020-03-08T10:00:00Z 370767
2020-03-08T11:00:00Z 370810
2020-03-08T12:00:00Z 370818
2020-03-08T13:00:00Z 370827
2020-03-08T14:00:00Z 370849
2020-03-08T15:00:00Z 370921

Pange tähele, et andmed salvestatakse andmebaasis UTC ajas, seega erinevad need selles nimekirjas 3 tunni võrra — kell 7 hommikul InfluxDB väljundis vastavad väärtused 10 hommikul ülaltoodud graafikutes. Samuti pange tähele, et kell 2 ja 5 hommikul pole kirjeid — see on see sama omadus continuous query's.

Nagu näete, on agrgeeritud väärtus samuti monotoonselt kasvav jada, ainult et kirjed tulevad harvem — kord tunnis. Kuid see ei ole probleem — saame kirjutada veel ühe päringu, mis toob graafiku jaoks õiged andmed.

SELECT difference(max(value)) 
FROM homeassistant.month.water_meter_hour 
WHERE entity_id='water_meter_cold' and time >= now() -24h 
GROUP BY time(1h), entity_id 
fill(previous)

Selgitan:

Andmebaasist homeassistant.month.water_meter_hour tõmbame välja andmed entity_id='water_meter_cold' kohta viimase 24 tunni jooksul (time >= now() -24h).
Nagu varem mainisin, võivad homeassistant.month.water_meter_hour jadas puududa mõned kirjed. Need andmed genereerime uuesti, käivitades päringu GROUP BY time(1h). Seekord töötab fill(previous) nagu peab, genereerides puuduvad andmed (funktsioon võtab eelneva väärtuse)
Selle päringu kõige olulisem osa on funktsioon difference, mis arvutab erinevuse tunni märkmete vahel. Ise ei tööta ta ja vajab agregatsiooni funktsiooni. Olgu selleks max(), mida oleme varem kasutanud.

Täidise tulemus näeb välja selline

name: water_meter_hour
tags: entity_id=water_meter_cold
time                 difference
----                 ----------
...
2020-03-08T02:00:00Z 2
2020-03-08T03:00:00Z 0
2020-03-08T04:00:00Z 0
2020-03-08T05:00:00Z 14
2020-03-08T06:00:00Z 78
2020-03-08T07:00:00Z 30
2020-03-08T08:00:00Z 64
2020-03-08T09:00:00Z 62
2020-03-08T10:00:00Z 6
2020-03-08T11:00:00Z 43
2020-03-08T12:00:00Z 8
2020-03-08T13:00:00Z 9
2020-03-08T14:00:00Z 22
2020-03-08T15:00:00Z 72

Kell 2 kuni 5 hommikul (UTC) tarbimist ei olnud. Siiski tagastab päring sama tarbimise väärtuse tänu fill(previous) funktsiooni kasutamisele, ja funktsioon difference lahutab selle väärtuse iseendast, saades lõpuks 0, mis ongi vajalik.

Jäänud on vaid väike asi — ehitada graafik. Selleks avame Grafana, avame mõne olemasoleva (või loome uue) armatuurlauad, loome uue paneeli. Graafiku seadistused on järgmised.

Kannan esitlema andmeid külma ja kuuma vee kohta ühel graafikul. Päring on täpselt selline nagu ma ülal kirjeldasin.

Kuva seadistused määratakse nii. Mul on see graafik joontega (lines), mis läheb astmetena (stairs). Parameetrit Stack selgitan veidi allpool. Seal on veel mõned kuvamise parameetrid, kuid need pole nii huvitavad.

Et lisada saadud graafik home assistentisse, tuleb:

välja minna graafiku redigeerimisrežiimist. Mikski pärast pakutakse graafikute jagamise õigeid seadistusi ainult armatuurlaua lehelt.
Klõpsake kolmnurgal graafiku nime kõrval, menüüs valige share.
Avanenud aknas minema vahekaardile embed.
Eemaldage märkeruut current time range — ajavahemiku määrame URL-i kaudu.
Valige vajalik teema. Minu puhul on see light.
Kopeerige saadud URL lovelace-UI seadistuste kaardile.

      - type: iframe
        id: graf_water_hourly
        url: "http://192.168.10.200:3000/d-solo/rZARemQWk/water?orgId=1&panelId=2&from=now-2d&to=now&theme=light"

Pange tähele, et ajavahemik (viimased 2 päeva) määratakse siinkohal, mitte armatuurlaua seadistustes.

Graafik näeb välja selline. Kuuma vett ei ole ma viimase kahe päeva jooksul kasutanud, seega joonistatakse ainult külma vee graafik.

Ma pole endiselt otsustanud, milline graafik mulle rohkem meeldib, astmejoon või reaalsete sambad. Seega toon lihtsalt näite päevagraafikust, ainult sellel korral sambadega. Päringud koostatakse sarnaselt ülaltoodud kirjeldatule. Kuvamise parameetrid on järgmised:

See graafik näeb välja selline:

Nii et nüüd parameetrist Stack. Sellel graafikul joonistatakse külma vee sammas kuuma vee samba peale. Kokkuvõttes kõrgus vastab ühe perioodi kokkuvõtlikule tarbimisele külma ja kuuma vee osas.

Kõik näidatud graafikud on dünaamilised. Sobrav süsteemile huvitava punkti kohale ja vaadake detaile ja väärtust konkreetses punktis.

Kahjuks ei saanud paar tilka tõrva vältida. Veergude graafikul (erinevalt astmeliselt joonistatud graafikust) asub veeru keskmine mitte keset ööd, vaid kell 00:00. St. vasak pool veerust on joonistatud eelmine päev. Nii on laupäeva ja pühapäeva graafikud joonistatud veidi vasakule sinakas tsoonist. Praegu ei ole ma leidnud viisi, kuidas seda lahendada.

Teine probleem on seostatav kuude intervallide korrektse töötlemisega. Asi on selles, et tunni/päeva/nädala pikkus on fikseeritud, kuid kuu pikkus on iga kord erinev. InfluxDB suudab töötada ainult ühtsete intervallidega. Praegu suudab mu aju seadistada fikseeritud intervalli 30 päeva. Jah, graafik aasta jooksul muutub veidi ebatäpseks ja veerud ei vasta täpselt kuudele. Kuid kuna see teema huvitab mind lihtsalt näidikuna, siis olen sellega rahul.

Näen vähemalt kahte lahendust:

Jätta kuu graafikud tähelepanuta ja piirduda nädalastega. 52 nädalast veergu aastas näeb päris hästi välja.
Nädalase tarbimise arvestamine teise viisina ning Grafanat kasutada ainult ilusti graafikute jaoks. Tulemuseks saab olema üsna täpne lahendus. Võib isegi panna eelmisel aastal graafikud kokku, et võrrelda — Grafana suudab ka seda.

Kokkuvõte

Ma ei tea, miks, aga mulle meeldivad sellised graafikud. Need näitavad, et elu pulbitseb ja kõik muutub. Eile oli palju, täna vähe, homme tuleb midagi muud. On jäänud rääkida pereliikmetega nende tarbimise teemast. Kuid isegi praeguste harrastuste juures muutub lihtsalt suur ja arusaamatu number arvel juba üsna arusaadavaks tarbimispildiks.

Hoolimata peaaegu 20-aastasest programmeerija karjäärist ei olnud ma andmebaasidega praktiliselt kokku puutunud. Seetõttu tundus välise andmebaasi seadistamine midagi väga keerulist ja arusaamatut. eelnevalt mainitud artikkel — selgus, et sobiva tööriista külge keeramine toimub paari klõpsuga ning spetsialiseeritud tööriista abil muutub graafikute loomise ülesanne veidi lihtsamaks.

Pealkirjas mainisin elektritarbimist. Kahjuks ei saa ma hetkel tuua ühtegi graafikut. Üks SDM120 arvesti on mu jaoks katkenud ja teine käitub Modbus'i kutsumise korral ebatavaliselt. Siiski ei mõjuta see artikkel teemat — graafikuid saab koostada samamoodi kui vee puhul.

Selles artiklis olen välja toonud lähenemisviisid, mida olen ise proovinud. Kindlasti on olemas veel mõni andmete kogumise ja visualiseerimise meetod, millest ma ei tea. Jagage minuga kommentaarides, mul oleks väga huvitav kuulda. Olen avatud konstruktiivsele kriitikale ja uutele ideedele. Loodan, et antud materjal aitab kedagi.

Allikas: habr.com

Nutika kodu: Joonistame veetarve ja elektri grafiike Home Assistantis

Ülesande seadmine

Lähenemine 1

Lähtekoht 2

Lähenemine 3

Kokkuvõte