Nutika kodu: Joonistame vee ja elektri tarbimise graafikud Home Assistantis

I am always surprised when I receive the bill for electricity and water — does my family really use that much? Sure, the bathroom has underfloor heating and a boiler, but they're not working all the time. We seem to save water too (though we do enjoy splashing around in the bath). A few years ago, I already installed water meters ja electricity to the smart home system, but I just got stuck on that. I’ve only now gotten around to analyzing consumption, which is basically what this article is about.

Recently, I switched to Home Assistant as my smart home system. One reason was the ability to collect a lot of data with a convenient way to create various graphs.

The information described in this article is not new; all these things have already been discussed online in various forms. However, each article usually covers only one approach or aspect. I had to compare all these methods and choose the most suitable one myself. The article still doesn’t provide exhaustive information on data collection but serves as a summary of how I did it. Therefore, constructive criticism and suggestions for improvement are welcome.

Ülesande seadmine

So, the goal 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

In this process, we face some challenges:

• Standard graph components are usually rather limited. At best, you can create a line graph based on points.

  If you search well, you can find third-party components that expand the capabilities of the standard graph. For Home Assistant, the component mini-graph-cardis quite decent and visually appealing, but it also has some limitations:

  • It’s difficult to set parameters for bar graphs over large intervals (the bar width is set in fractions of an hour, which means intervals longer than an hour need fractional numbers)
  • You cannot add different entities to one graph (for example, combining temperature and humidity, or merging a bar graph with a line graph)
• Not to mention that Home Assistant, by default, uses the most primitive SQLite database (and I, unfortunately, didn’t manage to install MySQL or Postgres), so the data is not stored in the most optimal way. For instance, every time even the smallest digital parameter changes, a large JSON payload of about a kilobyte is recorded in the database.

  {"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}}}

  I have quite a few sensors (temperature sensors in each room, water and electricity meters), and some even generate a lot of data. For instance, the SDM220 electricity meter generates about a dozen values every 10-15 seconds, and I would like to install about 8 of these meters. Moreover, there’s a whole bunch of parameters calculated based on other sensors. Thus, all these values could easily inflate the database by 100-200 MB daily. After a week, the system will be sluggish, and after a month, the flash drive will die (in a typical Home Assistant installation on a Raspberry Pi), and storing data for an entire year is out of the question.

• If you’re lucky, your meter can count consumption by itself. You can inquire at any time and ask the meter for the accumulated consumption value. Generally, all electricity meters that have a digital interface (RS232/RS485/Modbus/Zigbee) offer this capability.

  Halvem, kui seade suudab lihtsalt mõõta mingit hetkeparameetrit (näiteks hetke võimsust või voolu), või lihtsalt genereerida impulsse iga X vat-tunni või liitri kohta. Siis tuleb mõelda, kuidas ja millega seda integreerida ning kus väärtust koguda. On oht, et jääb järgmine aruanne mingil põhjusel saamata, ja kogu süsteemi täpsus tekitab küsimusi. Muidugi võib selle kõik usaldada nutika kodu süsteemile, nagu home assistant, kuid andmebaasi salvestuste arvu punkt ei ole kehtetuks muutunud, ja andurite küsitlemine tihedamini kui kord sekundis pole võimalik (home assistant'i arhitektuuri piirang).

Lähenemine 1

Alustame vaatamisest, mida home assistant väidetavalt pakub. Tarbimise mõõtmine ajavahemiku jooksul on väga nõutud funktsionaalsus. Loomulikult on see juba ammu rakendatud spetsialiseeritud komponendina - utility_meter.

Komponendi olemus seisneb selles, et see loob muutuja current_accumulated_value, ja nulleb seda määratud ajaperioodi (tund/nädal/kuu) lõppedes. Komponent jälgib sissetulevat muutujat (näiteks mingi anduri väärtus) ja registreerib muutused - te lihtsalt saate valmis tulemuse. Selle seadistamine vajab vaid mõningaid ridasid 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, mis on hetke väärtus, mida ma saan otse seadme kaudul mqtt. Konstruktsioon loob 2 uut andurit water_cold_hour_um ja water_cold_day_um, mis koguvad tunni ja päevas näitajaid, nulledes need ajaperioodi lõppedes. Siin on tunni akumulaatori graafik poole päeva jooksul.

Tunni ja päevagraafikute kood lovelace-UI jaoks on järgmine:

      - type: history-graph
        title: 'Tunni veetarbimine muutuja põhjal'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Päeva veetarbimine muutuja põhjal'
        hours_to_show: 360
        entities:
          - sensor.water_day

Tegelikult peitub probleem sellises lähenemises selle algoritmi sees. Nagu ma juba mainisin, genereeritakse iga sissetuleva väärtuse (hetke näitaja iga järgmise liitri jaoks) puhul 1 kB andmebaasi kirjeid. Iga utility meter genereerib samuti uue väärtuse, mis minnes andmebaasi. Kui ma tahan koguda tunni/päeva/nädala/kuu näitajaid, ja samaaegselt mitmest veepunktist, pluss veel hulga elektriarvestite lisada - siis on see väga palju andmeid. No, täpsemalt öeldes pole andmeid palju, kuid kuna home assistant kirjutab andmebaasi hunniku liigset teavet, siis andmebaasi suurus kasvab nagu pärmitaigen. Pelgalt nädalate ja kuude graafikute suuruse arvutamine on jube.

Lisaks sellele ei lahenda utility meter ise seatud ülesannet. Utility meter'i välja andev graafik on monotoniliselt kasvava funktsiooni graafik, mis nulledakse iga tunni lõpus. Me vajame kasutajale arusaadavat tarbimise graafikut, et näha, kui palju liitreid on ajavahemiku jooksul tarbitud. Tavaline history-graph komponent seda teha ei oska, kuid me saame kasutada välist komponenti mini-graph-card.

See on kood tehiskaardile lovelace-UI jaoks:

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Tunni veetarbimine, koondatud utility meter'i järgi"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

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

• group_by:hour — graafik genereeritakse tundide alguse järgi
• points_per_hour: 1 — üks graafik iga tunni kohta
• Ja kõige olulisem, aggregate_func: max — võtke maksimaalne väärtus igas tunnis. Just see parameeter muudab hammasratta graafiku tulpadeks.

Vasaku ääre rida tulpade puhul ärge pöörake tähelepanu - see on komponendi standardne käitumine, kui andmeid pole. Ja andmeid polnudki - ma lülitasin utility meter andmete kogumise sisse alles paar tundi tagasi ainult selle artikli jaoks (oma praeguse lähenemise tutvustan allpool).

Sellel pildil soovisin näidata, et mõnikord toimib andmete kuvamine, ja tulbad peegeldavad tõesti õigeid väärtusi. Ainult et mitte kõik. Märgitud tulbi ajavahemikus 11-12 hommikul näitab kahjuks 19 liitrit, kuigi hammastega graafikul näeme, et sellelt samalt andurilt on sel perioodil tarbimine 62 liitrit. Olgu see siis bug või vale. Ja miks andmed paremal poole katkestusid, pole ma veel aru saanud - seal oli tarbimine normaalne, nagu samuti on näha hammastega graafikust.

Üldiselt ei saanud ma selle lähenemise usaldusväärsuse saavutada - graafik näitab peaaegu alati mingit jama.

Sarnane kood päevase anduri jaoks.

      - 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 kogutud utiliidi järgi"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Pange tähele, et rippmenüü parameeter group_by on seatud väärtuseks interval, ja kõik sõltub parameetrist points_per_hour. See on ka teine probleem, millega see komponent silmitsi seisab — points_per_hour töötab hästi tunnigraafikute korral, kuid kehvasti pikemate ajavahemike puhul. Seetõttu, et saada üks veerg ühe päeva kohta, pidin kirjutama väärtuse 1/24=0.04166666. Ma räägin juba nädalaste ja kuiste graafikute kohta.

Lähenemine 2

Veel uurides home assistanti, sattusin sellele videole:

Sõber kogub andmeid mitmesuguste Xiaomi pistikute tarbimise kohta. Tema ülesanne on lihtsam — lihtsalt kuvada tarbimise väärtused täna, eile ja kuu jooksul. Graafikuid ei nõuta.

Jätame kõrvale arutlused, mis puudutavad hetkevõimsuse käsitsi integreerimist — selle lähenemise „täpsusest” olen juba eespool kirjutanud. Pole selge, miks ta ei kasuta kogunenud tarbimise väärtusi, mis on juba sama pistiku poolt kogutud. Minu arvates töötaks integreerimine seadme sees paremini.

Videost võtame idee tarbimise käsitsi arvestamisest ajavahemiku jooksul. Mees arvutab ainult täna ja eile saadud väärtusi, kuid me liigume edasi ja proovime joonistada graafiku. Pakutud meetodi sisu minu puhul seisneb järgnevates etappides.

Loome muutuja väärtus_alguses_tunnis, kuhu salvestame arvesti praegused näidud.
Kellaaegade jooksul (või järgmise tunni alguses) arvutame erinevuse praeguste näitude ja alguses salvestatud näitude vahel. See erinevus on hetketarbimine — salvestame selle väärtuse sensorisse ja tulevikus kasutame selle abil graafiku koostamiseks.
Peame ka „nullima” muutuja väärtus_alguses_tunnis, salvestades sinna arvesti praeguse väärtuse.

Kõike seda saab teha home assistandi enda tööriistade kaudu.

Koodi tuleb kirjutada veidi rohkem, kui eelnevas lähenemises. Esiteks, loome need „muutujad”. Vaikimisi meil ei ole ”muutuja” olemust, kuid võime kasutada mqtt brokki teenuseid. Saame sinna saata väärtusi, kinnitades retain=true — see hoiab väärtuse brokkis ning saame seda igal ajal sealt kätte, isegi home assistanti taaskäivitamisel. Tehtud on kohe tunnised 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

Kõik maagia toimub automatiseerimises, mis käivitatakse iga tunni ja iga öö.

- 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 automatiseerimised teevad 2 toimingut:

• Arvutavad vahemaa väärtuse intervalli alguse ja lõppväärtuse vahel
• Uuendavad põhiväärtuse järgmise intervalli jaoks

Graafikute koostamine toimub tavaliselt history-graph: i kaudu:

      - type: history-graph
        title: 'Tunni veetarbimine muutuja põhjal'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Päeva veetarbimine muutuja põhjal'
        hours_to_show: 360
        entities:
          - sensor.water_day

Näeb välja nii:

Põhimõtteliselt on see juba see, mis on vajalik. Selle meetodi eelis on see, et andmed genereeritakse ainult ühe korra intervalli jooksul. T. e. kokku 24 kirjet ööpäevas tunnigraafiku jaoks.

Kahjuks ei lahenda see siiski probleemi kasvava andmebaasi osas. Kui soovin kuu tarbimise graafikut, pean andmeid salvestama vähemalt aasta. Ja kuna home assistant pakub ainult ühte säilitamise seadistust kogu andmebaasi jaoks, tähendab see, et KÕIK andmed süsteemis tuleb hoida terve aasta. Näiteks, kui aastas tarbin 200 kuupsentimeetrit vett, tähendab see 200000 kirjet andmebaasis. Ja kui arvestada ka teisi sensoreid, muutub number üldiselt täiesti sobimatuks.

Lähenemine 3

Õnneks on nutikad inimesed juba selle probleemi lahendanud, luues InfluxDB andmebaasi. See andmebaas on spetsiaalselt optimeeritud ajapõhiste andmete salvestamiseks ja sobib ideaalselt erinevate sensorite väärtuste hoidmiseks. Süsteem pakub ka SQL-laadset päringukeelt, mis võimaldab andmebaasist väärtusi välja noppida ja seejärel neid mitmel viisil agregatsioonida. Lõpuks on erinevad andmed võimalik salvestada erineva aja jooksul. Näiteks kiiresti muutuvad näidud, nagu temperatuur või niiskus, saab hoida ainult paar nädalat, samas kui päevased vee tarbimise näidud saavad püsida aasta.

Lisaks InfluxDB-le on nutikad inimesed välja loonud ka Grafana - süsteemi, mis võimaldab graafikute joonistamist InfluxDB-st pärit andmetest. Grafana suudab joonistada erinevaid graafikute tüüpe, neid detailideni kohandada ning mis kõige tähtsam, neid graafikuid saab "paigaldada" lovelace-UI home assistant’isse.

Inspireerima siin ja siin. Artiklites on detailselt kirjeldatud InfluxDB ja Grafana installimise ja ühendamise protsessi home assistant’iga. Mina keskendun oma konkreetse ülesande lahendamisele.

Nii et esmalt hakkame salvestama arvesti väärtust InfluxDB-sse. Juhend home assistandi konfiguratsiooni (selles näites lähen ma mängima 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äivitame sama andmete salvestamise home assistandi sisemisesse andmebaasi, et mitte seda tarbetult paisutada:

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

Liigume nüüd InfluxDB konsooli ja seadistame oma andmebaasi. Eelkõige tuleb määrata, kui kaua teatud andmeid hoitakse. Seda reguleerib nn retention policy - see on sarnane andmebaasidele põhjaandmebaasi sees, kus igal sisemisel andmebaasil on oma seaded. Vaikimisi salvestatakse kõik andmed retention policy alla nimega autogen, mis hoiustatakse nädal. Soovin, et tunnised andmed säilitaksid kuu, nädalased - aasta, ja kuuandmed ei kustutataks 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, põhimõtteliselt, peamine nipp - andmete agregatsioon continuous query abil. See on mehhanism, mis käivitab päringu automaatselt teatud ajavahemike järel, agregatsioonandmed selle päringu põhjal ja salvestab tulemuse uue väärtusena. Vaatame näidet (kirjutan veeru kaupa parema loetavuse nimel, kuid tegelikult pidi ma selle käsu sisestama ühes reas).

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 toob kõik andmed homeassistant.autogen.l (liitrid) mõõtmisest, sealhulgas külma ja sooja vee näidud.
• Agregeeritud andmed rühmitatakse entity_id järgi, luues meile eraldi väärtused külma ja sooja vee jaoks.
• Kuna liitri arvesti on monotoonselt kasvav järjestus, tuleb iga tunni jooksul võtta maksimaalne väärtus, mistõttu aggregatsioon viiakse läbi funktsiooni max(value) abil.
• Uus väärtus salvestatakse homeassistant.month.water_meter_hour, kus month on retention policy nimi kuu pikkuse säilitamise tasuta. Külma ja sooja vee andmed jagunevad erinevatesse kirjetesse vastava entity_id ja väärtusega väljal value.

Öösel või kui kedagi kodus ei ole, ei ole vee tarbimist, seega ei teki uusi kirjeid homeassistant.autogen.l. Et vältida väärtuste kadumist tavapärastes päringutes, võib kasutada fill(previous). See sunnib InfluxDB-d kasutama eelmise tunni väärtust.

Kahjuks on continuous query-l üks eripära: fill(previous) nipp ei tööta ja kirjed ei luge. See on mingi ületamatu probleem, mis on juba aastaid arutlusel. Selle probleemiga tegeleme hiljem, kuid fill(previous) continuous query-s jätku jääb – see ei häiri.

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 väärtused andmebaasis salvestatakse UTC-s, seega erinevad need nimekirjas kolme tunni võrra — kell 7 hommikul InfluxDB-s kuvatud väärtused vastavad kell 10 hommikul ülaltoodud graafikutele. Samuti pange tähele, et kella 2 ja 5 vahel pole kirjeid — see on see, mis iseloomustab continuous query'd.

Nagu näete, on koondatud väärtus samuti monotoniliselt kasvav järjestus, kuid kirjed on harvem — korra tunni kohta. Kuid see pole probleem — saame kirjutada veel ühe küsimuse, mis toob õiged andmed graafikule.

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:

• Käime andmebaasist homeassistant.month.water_meter_hour välja andmed entity_id='water_meter_cold' jaoks viimase 24 tunni jooksul (time >= now() -24h).
• Kuna olen juba maininud, et homeassistant.month.water_meter_hour järjestuses võivad mõned kirjed puududa. Need andmed genereerime uuesti, käivitades päringu GROUP BY time(1h). Seekord fill(previous) töötab nii nagu peab, genereerides puuduvad andmed (funktsioon võtab eelmise väärtuse).
• Selle päringu kõige olulisem osa on funktsioon difference, mis arvutab tunni markide vahelise erinevuse. Üksinda ei toimi see ja vajab agregatsioonifunktsiooni. Olgu selleks max(), mida oleme varem kasutanud.

Tulemuse täitmine 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

Kella 2 ja 5 vahel (UTC) ei olnud tarbimist. Siiski tagastab päring sama tarbimise väärtuse tänu fill(previous), ja funktsioon difference lahutab selle iseendast, mille tulemusena saame 0, mis tegelikult on vajalik.

Jõuame viimase sammuni — graafiku joonistamine. Selleks avame Grafana, avame mõne olemasoleva (või loome uue) armatuurlaua, loome uue paneeli. Graafiku seaded on järgmised.

Kavatsen kuvada andmeid külma ja sooja vee kohta ühel graafikul. Päring on täpselt selline, nagu ma eespool kirjeldasin.

Kuvamise parameetrid on seadistatud nii. Mul on see joon graafikuna (lines), mis kulgeb astmeliselt (stairs). Parameeter Stack, selgitan natuke hiljem. Seal on veel mõni kuvamise parameeter, kuid need pole nii huvitavad.

Kuidas lisada saadud graafik home assistant'i:

• välja minna graafiku redigeerimisrežiimist. Mikski pärast pakutakse õiged graafikute jagamise seaded ainult armatuurlaua lehelt.
• Klõpsake kolmnurgale graafiku nime kõrval, valige menüüst jagada.
• Avalt avanevas aknas minge sakkile embed.
• Tühjendage ruut current time range — ajavahemiku määrame URL-i kaudu.
• Valige vajalik teema. Minu puhul on see light.
• Kopeerige saadud URL lovelace-UI seadete 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 just siin, mitte armatuurlauda seadetes.

Graafik näeb välja nii. Sooja vett ma viimase kahe päeva jooksul ei kasutanud, seetõttu joonistatakse ainult külma vee graafik.

Nii et ei suutnud ma otsustada, milline graafik mulle rohkem meeldib, astmelise joonega või päris tulpadega. Seetõttu toome lihtsalt näite päevagraafikust, seekord ainult tulpadega. Päringud tehakse sarnasel viisil nagu eespool kirjeldatud. Kuvamise parameetrid on sellised:

See graafik näeb välja nii:

Nii et rääkides parameetrist Stack. Sellel graafikul joonistatakse külma vee tulp sooja vee tulba peale. Üldine kõrgus vastab külma ja sooja vee tarbimise kogusummale ajavahemikul.

Kõik näidatud graafikud on dünaamilised. Saate hiirega huvipakkuva punkti peale liikuda ja vaadata üksikasju ja väärtust konkreetses punktis.

Kahjuks ei ole ilma paarikese tõrva. Tulpade graafikul (erinevalt astmelisest joonegraafikust) on tulba keskmine punkt mitte keskpäeval, vaid kell 00:00. St tulba vasak pool joonistatakse eelmise päeva kohale. Nii et laupäeva ja pühapäeva graafikud on joonistatud veidi vasakule sinise ala suhtes. Praeguseks ei ole mul veel lahendust.

Teine probleem seisneb selles, et kuu intervallidega on keeruline õigesti töötada. Asi on selles, et tunni/päeva/nädala pikkus on fikseeritud, kuid kuu pikkus on iga kord erinev. InfluxDB saab töötada ainult ühtsete intervallidega. Seni on mu mõtlemine piirdunud fikseeritud 30-päevase intervalliga. Jah, graafik aastate lõikes veidi moonutab ja baarid ei ühti täiesti täpselt kuudega. Kuid kuna see asi huvitab mind lihtsalt näitajana, siis ma lepin sellega.

Näen vähemalt kahte lahendust:

• Jätta kuu graafikud kõrvale ja piirduda nädalastega. 52 nädalast baari aastas näeb täiesti hea välja.
• Kuu tarbimist arvestada teise meetodina ja Grafanat kasutada vaid ilusate graafikute jaoks. See osutub täiesti täpseks lahenduseks. Võib isegi eelmisel aastal graafikud katsetada — Grafana oskab ka seda.

Kokkuvõte

Ei tea, miks, aga ma naudin sellist tüüpi graafikuid. Need näitavad, et elu pulbitseb ja kõik muutub. Eile oli palju, täna vähe, homme on kuidagi veel. Peab veel pereliikmetega tarbimise teemal rääkima. Kuid isegi praeguste isudega muutub lihtsalt suur ja arusaamatu number arvel piisavalt arusaadavaks tarbimise pildiks.

Hoolimata pea 20-aastasest programmeerimise karjäärist ei ole ma andmebaasidega praktiliselt kokku puutunud. Seetõttu tundus välise andmebaasi seadistamine millegi sellise, mis on keeruline ja arusaamatu. Kõik muutis ülespool mainitud artikkel — selgus, et sobiva tööriista ühendamine toimub paaris klõpsus, ja spetsialiseeritud tööriistaga muutub graafikute loomise ülesanne veidi lihtsamaks.

Pealkirjas mainisin elektritarbimist. Kahjuks ei saa ma hetkel esitada ühtegi graafikut. Üks SDM120 mõõtur on mul läbi kukkunud, ja teine jamab Modbusi kaudu ühenduse võttes. Kuid see ei mõjuta kuidagi selle artikli sisu — graafikud ehitatakse samamoodi, nagu veega.

Selles artiklis olen läbi viinud need lähenemisviisid, mida olen ise proovinud. Kindlasti on veel mingeid andmete kogumise ja visualiseerimise organiseerimise viise, millest ma ei tea. Rääkige mulle sellest kommentaarides, see oleks mulle väga huvitav. Olen avatud konstruktiivsele kriitikale ja uutele ideedele. Loodan, et esitatud materjal aitab ka kedagi.

Allikas: habr.com