Älykäs koti: veden ja sähkön kulutuksen kartoitus Home Assistantissa

Joka kerta kun saan maksun sähköstä ja vedestä, ihmettelen - kuluttaako perheeni todella niin paljon? No, kyllä, kylpyhuoneessa on lattialämmitys ja kattila, mutta ne eivät aina toimi palomiehinä. Näytämme myös säästävän vettä (vaikka pidämme myös roiskumisesta kylpyhuoneessa). Muutama vuosi sitten jo kytketyt vesimittarit и sähkö älykkään kotiin, mutta tähän asiat jumissa. Kädet ovat saavuttaneet kulutuksen analysoinnin vasta nyt, mistä itse asiassa tämä artikkeli kertoo.

Vaihdoin äskettäin Home Assistantiin älykodin järjestelmänäni. Yksi syistä oli vain kyky järjestää suuren tietomäärän kerääminen ja mahdollisuus rakentaa kätevästi erilaisia ​​​​kaavioita.

Tässä artikkelissa kuvatut tiedot eivät ole uusia, kaikki nämä asiat eri kastikkeiden alla on jo kuvattu Internetissä. Mutta jokainen artikkeli kuvaa pääsääntöisesti vain yhtä lähestymistapaa tai näkökohtaa. Minun piti vertailla kaikkia näitä lähestymistapoja ja valita itse sopivin. Artikkeli ei vieläkään tarjoa tyhjentävää tietoa tiedonkeruusta, mutta on eräänlainen tiivistelmä siitä, miten tein sen. Joten rakentava kritiikki ja parannusehdotukset ovat tervetulleita.

Ongelma

Joten tämän päivän harjoituksen tavoitteena on saada kauniit kaaviot veden ja sähkön kulutuksesta:

• Tunti 2 päivän ajan
• Päivittäin 2 viikon ajan
• (valinnainen) viikoittain ja kuukausittain

Tässä on joitain vaikeuksia:

• Vakiokaaviokomponentit ovat yleensä melko huonoja. Parhaimmillaan voit rakentaa viivakaavion pisteiden mukaan.

  Jos etsit hyvin, voit löytää kolmannen osapuolen komponentteja, jotka laajentavat vakiokaavion ominaisuuksia. Kotiavustajalle periaatteessa hyvä ja kaunis komponentti mini-grafiikkakortti, mutta se on myös jonkin verran rajoitettu:

  • Pylväskaavion parametrien asettaminen suurilla väliajoilla on vaikeaa (palkin leveys asetetaan tunnin murto-osissa, mikä tarkoittaa, että tunnin pitemmät intervallit asetetaan murto-osina)
  • Et voi lisätä eri kokonaisuuksia yhteen kuvaajaan (esimerkiksi lämpötilaa ja kosteutta tai yhdistää pylväsdiagrammia viivan kanssa)
• Sen lisäksi, että kotiavustaja käyttää oletusarvoisesti alkeellisinta SQLite-tietokantaa (ja minä, yleismies, en hallitse MySQL:n tai Postgresin asennusta), tietoja ei tallenneta parhaalla mahdollisella tavalla. Joten esimerkiksi jokaisella parametrin pienimmänkin digitaalisen parametrin muutoksella tietokantaan kirjoitetaan valtava noin kilotavun kokoinen json.

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

  Minulla on melko vähän antureita (lämpötila-antureita joka huoneessa, vesi- ja sähkömittarit), ja jotkut myös tuottavat melko paljon dataa. Joten esimerkiksi vain SDM220 sähkömittari tuottaa noin tusina arvoa 10-15 sekunnin välein, ja sellaisia ​​​​mittareita haluaisin asentaa 8. Ja siellä on koko joukko parametreja, jotka lasketaan muiden antureiden perusteella. Että. kaikki nämä arvot voivat helposti kasvattaa tietokantaa 100-200 Mt päivässä. Viikossa järjestelmä tuskin heittelee ja kääntyy, ja kuukaudessa flash-tikku kuolee (jos kyseessä on tyypillinen kotiavustajan asennus Raspberry PI:hen), eikä koko vuoden tietojen tallentamisesta voi puhua. .

• Jos olet onnekas, mittarisi voi itse laskea kulutuksen. Voit milloin tahansa ottaa yhteyttä mittariin ja kysyä, mihin aikaan kertynyt kulutusarvo on. Pääsääntöisesti kaikki sähkömittarit, joissa on digitaalinen liitäntä (RS232/RS485/Modbus/Zigbee), tarjoavat tällaisen mahdollisuuden.

  Pahempaa on, jos laite voi yksinkertaisesti mitata jonkin hetkellisen parametrin (esimerkiksi hetkellisen tehon tai virran) tai yksinkertaisesti tuottaa pulsseja X wattitunnin tai litran välein. Sitten on mietittävä, miten ja mihin se integroidaan ja mihin arvoa kertyy. On olemassa vaara, että seuraava raportti jää jostain syystä väliin, ja järjestelmän tarkkuus kokonaisuutena herättää kysymyksiä. Voit tietysti uskoa tämän kaiken älykkään kodin järjestelmän, kuten kotiavustajan, tehtäväksi, mutta kukaan ei ole poistanut kohtaa tietokannan merkintöjen määrästä, eivätkä kyselytunnistimet useammin kuin kerran sekunnissa toimi (rajoitus kotiavustajan arkkitehtuuri).

Lähestymistapa 1

Katsotaanpa ensin, mikä kotiavustaja toimitetaan pakkauksesta. Kulutuksen mittaaminen ajanjaksolla on erittäin kysytty toiminto. Tietenkin se toteutettiin kauan sitten erikoiskomponenttina - utility_meter.

Komponentin ydin on, että se käynnistää nykyisen_akkumuloitu_arvo-muuttujan sisällä ja nollaa sen tietyn ajanjakson (tunti/viikko/kuukausi) jälkeen. Komponentti itse tarkkailee saapuvaa muuttujaa (jonkin anturin arvoa), tilaa itse arvon muutokset - saat vain valmiin tuloksen. Tämä asia on kuvattu vain muutamalla rivillä asetustiedostossa

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

Tässä sensor.water_meter_cold on mittarin nykyinen arvo litroina, jonka saan suoraan raudasta tekijä: mqtt. Suunnittelu luo 2 uutta anturia water_cold_hour_um ja water_cold_day_um, jotka keräävät tunti- ja päivälukemat ja nollaavat ne tietyn ajan kuluttua. Tässä on kaavio akun tuntimäärästä puolen päivän ajalta.

Lovelace-UI:n tunti- ja päiväkaaviokoodi näyttää tältä:

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

Itse asiassa tämän lähestymistavan ongelma piilee tässä algoritmissa. Kuten jo mainitsin, jokaiselle saapuvalle arvolle (jokaisen seuraavan litran nykyinen mittarin lukema) luodaan tietokantaan 1 kb tietue. Jokainen käyttömittari luo myös uuden arvon, joka myös lisätään kantaan. Jos haluan kerätä tunti-/päivä-/viikko-/kuukausilukemat, kyllä, useasta veden nousuputkesta ja jopa lisätä pakkauksen sähkömittareita, tästä tulee paljon dataa. No, tarkemmin sanottuna dataa ei ole paljon, mutta koska kotiavustaja kirjoittaa tietokantaan joukon tarpeettomia tietoja, tietokannan koko kasvaa harppauksin. Pelkään jopa arvioida viikko- ja kuukausikaavioiden pohjan kokoa.

Lisäksi sähkömittari itsessään ei ratkaise ongelmaa. Hyötymittarin kuvaaja on monotonisesti kasvava funktio, joka nollautuu joka tunti. Tarvitsemme myös käyttäjäystävällisen kulutusaikataulun, kuinka monta litraa kauden aikana syötiin. Tavallinen historiakaaviokomponentti ei tee tätä, mutta ulkoinen minigrafiikkakorttikomponentti voi auttaa meitä.

Tämä on lovelace-UI:n korttikoodi:

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Hourly water consumption aggregated by utility meter"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Vakioasetusten, kuten anturin nimen, kaavion tyypin, värin (en pitänyt tavallisesta oranssista), lisäksi on tärkeää huomioida kolme asetusta:

• group_by:hour - kaavio luodaan sarakkeilla, jotka on kohdistettu tunnin alkuun
• points_per_hour: 1 - yksi palkki tunnissa
• Ja mikä tärkeintä, aggregate_func: max on ottaa suurin arvo kunkin tunnin sisällä. Tämä parametri muuttaa sahakaavion pylväiksi.

Älä kiinnitä huomiota vasemmalla olevaan sarakeriviin - tämä on komponentin normaali käyttäytyminen, jos tietoja ei ole. Mutta tietoja ei ollut - otin tiedonkeruun käyttöön hyötymittarilla vain pari tuntia sitten vain tämän artikkelin vuoksi (kuvaan nykyistä lähestymistapaani hieman alempana).

Tässä kuvassa halusin näyttää, että joskus datanäyttö jopa toimii ja palkit todella heijastavat oikeita arvoja. Mutta siinä ei vielä kaikki. Jostain syystä korostettu sarake ajanjaksolle klo 11-12 näyttää 19 litraa, vaikka hammaskäyrästössä näkyy hieman korkeampi samalle ajanjaksolle samasta anturista kuluva 62 litraa. Joko bugi tai kädet ovat vinossa. Mutta en edelleenkään ymmärrä, miksi oikeanpuoleiset tiedot katkesivat - siellä kulutus oli normaalia, mikä näkyy myös hampaisesta kaaviosta.

Yleensä en onnistunut saavuttamaan tämän lähestymistavan uskottavuutta - kaaviossa näkyy melkein aina jonkinlaista harhaoppia.

Samanlainen koodi päiväanturille.

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Daily water consumption aggregated by utility meter"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Huomaa, että group_by-parametri on asetettu intervalliin ja point_per_hour-parametri hallitsee kaikkea. Ja tämä on toinen tämän komponentin ongelma - pisteet_tuntia kohden toimii hyvin tunnin tai alle kaavioissa, mutta ällöttävästi suuremmilla aikaväleillä. Joten saadakseni yhden sarakkeen yhdessä päivässä minun piti syöttää arvo 1/24=0.04166666. En puhu viikko- ja kuukausikaavioista.

Lähestymistapa 2

Kun vielä selvittelin kotiavustajaa, törmäsin tähän videoon:

Toveri kerää kulutustietoja useista Xiaomi-pistorasioista. Hänen tehtävänsä on hieman yksinkertaisempi - näytä vain kulutuksen arvo tänään, eilen ja kuukaudelta. Kaavioita ei tarvita.

Jätetään sivuun argumentit hetkellisten tehoarvojen manuaalisesta integroinnista - kirjoitin jo edellä tämän lähestymistavan "tarkkuudesta". Ei ole selvää, miksi hän ei käyttänyt kertyneitä kulutusarvoja, jotka jo kerätään samasta toimipisteestä. Mielestäni integrointi rautapalan sisällä toimii paremmin.

Videosta otamme ajatuksen kulutuksen manuaalisesta laskemisesta ajanjaksolle. Miehelle huomioidaan vain tämän päivän ja eilisen arvot, mutta mennään pidemmälle ja yritetään piirtää kaavio. Ehdotetun menetelmän ydin minun tapauksessani on seuraava.

Luomme muuttujan value_at_the_beginning_of_hour, johon kirjoitamme nykyiset laskurin lukemat
Ajastimen mukaan tunnin lopussa (tai seuraavan alussa) laskemme eron nykyisen ja tunnin alussa tallennetun lukeman välillä. Tämä ero on kuluvan tunnin kulutus - tallennamme arvon anturiin, ja tulevaisuudessa rakennamme kaavion tämän arvon perusteella.
Sinun on myös "nollattava" muuttuja value_at_beginning_of_hour kirjoittamalla siihen laskurin nykyinen arvo.

Kaikki tämä voidaan tehdä hyvin ... itse kotiavustajan avulla.

Sinun on kirjoitettava hieman enemmän koodia kuin edellisessä lähestymistavassa. Aloitetaan näistä "muuttujista". Paketissa meillä ei ole "muuttuvaa" entiteettiä, mutta voit käyttää mqtt-välittäjän palveluita. Lähetämme arvot sinne reten=true-lipulla - tämä säästää arvon välittäjän sisällä, ja se voidaan vetää pois milloin tahansa, vaikka kotiavustaja käynnistetään uudelleen. Tein tunti- ja päivälaskurit kerralla.

- 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

Kaikki taika tapahtuu automaatiossa, joka toimii joka tunti ja joka yö, vastaavasti.

- 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

Molemmat automaatit tekevät 2 asiaa:

• Laske arvo intervallia kohden alku- ja loppuarvon erotuksena
• Päivitä seuraavan aikavälin perusarvo

Graafeiden rakentaminen tässä tapauksessa ratkaistaan ​​tavallisella historiakaaviolla:

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

Näyttää siltä:

Periaatteessa tämä on jo se, mitä tarvitset. Tämän menetelmän etuna on, että tiedot luodaan kerran intervallia kohden. Nuo. yhteensä 24 merkintää päivässä tuntikaavioon.

Valitettavasti tämä ei vieläkään ratkaise kasvavan pohjan yleistä ongelmaa. Jos haluan kuukausittaisen kulutuskaavion, minun on säilytettävä tietoja vähintään vuoden ajan. Ja koska kotiavustaja tarjoaa vain yhden tallennusaikaasetuksen koko tietokannalle, tämä tarkoittaa, että KAIKKI järjestelmän tiedot on säilytettävä koko vuoden ajan. Esimerkiksi vuodessa kulutan 200 kuutiometriä vettä, mikä tarkoittaa 200000 XNUMX merkintää tietokannassa. Ja jos otat huomioon muut anturit, kuvasta tulee yleensä säädytön.

Lähestymistapa 3

Onneksi älykkäät ihmiset ovat jo ratkaisseet tämän ongelman kirjoittamalla InfluxDB-tietokannan. Tämä tietokanta on erityisesti optimoitu aikapohjaisen tiedon tallentamiseen ja sopii erinomaisesti eri antureiden arvojen tallentamiseen. Järjestelmä tarjoaa myös SQL:n kaltaisen kyselykielen, jonka avulla voit poimia arvoja tietokannasta ja sitten yhdistää ne eri tavoilla. Lopuksi eri dataa voidaan tallentaa eri aikoina. Esimerkiksi usein vaihtuvia lukemia, kuten lämpötilaa tai kosteutta, voidaan säilyttää vain pari viikkoa, kun taas päivittäiset vedenkulutuslukemat säilyvät koko vuoden ajan.

InfluxDB:n lisäksi älykkäät ihmiset keksivät myös Grafanan, järjestelmän kaavioiden piirtämiseen InfluxDB:n tiedoista. Grafana voi piirtää erityyppisiä kaavioita, muokata niitä yksityiskohtaisesti, ja mikä tärkeintä, nämä kaaviot voidaan "kytkeä" lovelace-UI-kotiavustajaan.

inspiroitua täällä и täällä. Artikkeleissa kuvataan yksityiskohtaisesti InfluxDB:n ja Grafanan asennus ja yhdistäminen kotiavustajaan. Keskityn erityisongelmani ratkaisemiseen.

Joten ensinnäkin aloitetaan laskurin arvon lisääminen influxDB:hen. Osa kotiavustajan kokoonpanosta (tässä esimerkissä pidän hauskaa paitsi kylmän, myös kuuman veden kanssa):

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

Poistetaan samojen tietojen tallentaminen kotiavustajan sisäiseen tietokantaan, jotta se ei paisuisi uudelleen:

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

Siirrytään nyt InfluxDB-konsoliin ja määritetään tietokanta. Erityisesti sinun on määritettävä, kuinka kauan tiettyjä tietoja säilytetään. Tätä säätelee ns. säilytyskäytäntö - tämä on samanlainen kuin päätietokannan sisällä olevat tietokannat, ja jokaisella sisäisellä tietokannalla on omat asetukset. Oletuksena kaikki tiedot lisätään säilytyskäytäntöön nimeltä autogen, näitä tietoja säilytetään viikon ajan. Haluaisin, että tuntitietoja säilytetään kuukauden ajan, viikkotietoja vuoden ajan ja kuukausittaisia ​​tietoja ei koskaan poisteta ollenkaan. Luomme asianmukaiset säilytyskäytännöt

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

Nyt itse asiassa tärkein temppu on tietojen yhdistäminen jatkuvalla kyselyllä. Tämä on mekanismi, joka käynnistää kyselyn automaattisesti tietyin väliajoin, kokoaa tämän kyselyn tiedot ja lisää tuloksen uuteen arvoon. Katsotaanpa esimerkkiä (kirjoitan sarakkeeseen luettavuuden vuoksi, mutta todellisuudessa minun piti kirjoittaa tämä komento yhdelle riville)

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

Tämä komento:

• Luo jatkuvan kyselyn nimeltä cq_water_cold_hourly kotiavustajan tietokantaan
• Kysely suoritetaan tunnin välein (aika(1h))
• Kysely poimii kaikki tiedot mittauksesta homeassistant.autogen.l (litraa), mukaan lukien kylmän ja kuuman veden lukemat
• Aggregoidut tiedot ryhmitellään entity_id:n mukaan, mikä luo erilliset arvot kylmälle ja kuumalle vedelle.
• Koska litralaskuri on monotonisesti kasvava sarja jokaisen tunnin sisällä, sinun on otettava maksimiarvo, joten aggregoinnin suorittaa max(value) -funktio
• Uusi arvo kirjoitetaan kohtaan homeassistant.month.water_meter_hour, jossa kuukausi on säilytyskäytännön nimi, jonka säilytysaika on yksi kuukausi. Lisäksi kylmän ja kuuman veden tiedot hajallaan erillisiin tietueisiin, joissa on vastaava entity_id ja arvo arvokentässä

Yöllä tai kun ketään ei ole kotona, vettä ei kuluta, eikä myöskään homeassistant.autogen.l:ssä ole uusia ennätyksiä. Voit välttää puuttuvien arvojen puuttumisen normaaleissa kyselyissä käyttämällä täyttöä (edellinen). Tämä pakottaa InfluxDB:n käyttämään viimeisen tunnin arvoa.

Valitettavasti jatkuvalla kyselyllä on erikoisuus: täyttö (edellinen) -temppu ei toimi ja tietueita ei yksinkertaisesti luoda. Lisäksi tämä on eräänlainen ylitsepääsemätön ongelma, joka on keskusteltu yli vuoden ajan. Käsittelemme tämän ongelman myöhemmin ja annamme jatkuvan kyselyn fill(previous) olla paikalla - se ei häiritse.

Katsotaan mitä tapahtui (tietenkin sinun on odotettava pari tuntia):

> 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

Huomaa, että tietokannan arvot tallennetaan UTC-muodossa, joten tämä luettelo eroaa 3 tunnilla - InfluxDB-tulosteen kello 7-arvot vastaavat yllä olevien kaavioiden kello 10-arvoja. Huomaa myös, että kello 2 ja 5 välillä aamulla ei yksinkertaisesti ole tietueita - tämä on jatkuvan kyselyn ominaisuus.

Kuten näette, aggregoitu arvo on myös monotonisesti kasvava sekvenssi, vain merkinnät ovat harvempia - kerran tunnissa. Mutta tämä ei ole ongelma - voimme kirjoittaa toisen kyselyn, joka poimii oikeat tiedot kaaviota varten.

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)

tulkitsen:

• Homeassistant.month.water_meter_hour-tietokannasta haemme tiedot entity_id='water_meter_cold' viimeiseltä päivältä (aika >= nyt() -24h).
• Kuten mainitsin, jotkut merkinnät saattavat puuttua sekvenssistä homeassistant.month.water_meter_hour. Luomme nämä tiedot uudelleen suorittamalla kyselyn GROUP BY time(1h). Tällä kertaa täyttö (edellinen) toimii oikein ja tuottaa puuttuvat tiedot (funktio ottaa edellisen arvon)
• Tärkeintä tässä kyselyssä on erofunktio, joka laskee tuntimerkkien välisen eron. Se ei itsessään toimi ja vaatii yhdistämistoiminnon. Olkoon tämä aiemmin käytetty max().

Toteutustulos näyttää tältä

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

Klo 2–5 (UTC) ei ollut kulutusta. Siitä huolimatta kysely palauttaa saman kulutusarvon fill(previous) -toiminnon ansiosta, ja erofunktio vähentää tämän arvon itsestään ja saa 0:n lähdössä, mikä itse asiassa vaaditaan.

Ainoa asia, joka on jäljellä, on rakentaa kaavio. Voit tehdä tämän avaamalla Grafanan, avaamalla jonkin olemassa olevan (tai luomalla uuden) kojelaudan, luomalla uuden paneelin. Kaavion asetukset ovat seuraavat.

Näytän kylmän ja kuuman veden tiedot samassa kaaviossa. Pyyntö on täsmälleen sama kuin edellä kuvailin.

Näyttöparametrit asetetaan seuraavasti. Minulle se on kaavio viivoilla (rivillä), joka kulkee portaissa (portaat). Pinoparametri selitetään alla. Alla on pari muuta näyttövaihtoehtoa, mutta ne eivät ole niin mielenkiintoisia.

Voit lisätä tuloksena olevan kaavion kotiavustajaan:

• poistu kaavion muokkaustilasta. Jostain syystä oikeat kaavion jakamisasetukset tarjotaan vain kojelautasivulta
• Napsauta kaavion nimen vieressä olevaa kolmiota ja valitse valikosta jako
• Siirry avautuvassa ikkunassa upotusvälilehdelle
• Poista nykyinen aikaväli - asetamme aikavälin URL-osoitteen kautta
• Valitse haluamasi aihe. Minun tapauksessani se on kevyt
• Kopioi tuloksena oleva URL-osoite lovelace-UI-asetuskorttiin

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

Huomaa, että aikaväli (viimeiset 2 päivää) asetetaan tässä, ei kojelaudan asetuksissa.

Kaavio näyttää tältä. En ole käyttänyt kuumaa vettä viimeisen 2 päivän aikana, joten piirretään vain kaavio kylmästä vedestä.

En ole itse päättänyt, mistä kaaviosta pidän eniten, askelviivasta vai oikeista baareista. Siksi annan vain esimerkin päivittäisestä kulutusaikataulusta, tällä kertaa vain baareissa. Kyselyt rakennetaan samalla tavalla kuin edellä on kuvattu. Näyttövaihtoehdot ovat:

Tämä kaavio näyttää tältä:

Siis pinoparametrista. Tässä kaaviossa kylmän veden palkki on piirretty kuuman palkin päälle. Kokonaiskorkeus vastaa kylmän ja kuuman veden kokonaiskulutusta ajanjaksolla.

Kaikki esitetyt kaaviot ovat dynaamisia. Voit siirtää hiiren kohdepisteen päälle ja nähdä tietyn kohdan yksityiskohdat ja arvon.

Valitettavasti se ei mennyt ilman paria kärpästä. Pylväskaaviossa (toisin kuin kaaviossa, jossa on askelviivat) pylvään keskikohta ei ole keskellä päivää, vaan kello 00:00. Nuo. palkin vasen puolisko piirretään edellisen päivän tilalle. Joten lauantain ja sunnuntain kaaviot on piirretty hieman sinertävän vyöhykkeen vasemmalle puolelle. Kunnes keksin kuinka voittaa.

Toinen ongelma on kyvyttömyys työskennellä oikein kuukausittain. Tosiasia on, että tunnin / päivän / viikon pituus on kiinteä, mutta kuukauden pituus on joka kerta erilainen. InfluxDB voi toimia vain yhtäläisin väliajoin. Toistaiseksi aivoni ovat riittäneet asettamaan kiinteän 30 päivän välin. Kyllä, kaavio kelluu hieman vuoden aikana ja pylväät eivät täsmää vastaa kuukausia. Mutta koska tämä asia kiinnostaa minua vain näyttömittarina, olen ok.

Näen ainakin kaksi ratkaisua:

• Voit tehdä pisteet kuukausikaavioissa ja rajoittaa itsesi viikoittaisiin kaavioihin. 52 viikoittaista patukkaa vuodessa näyttää aika hyvältä
• Pidä itse kuukausittaista kulutusta menetelmänä nro 2 ja käytä grafanaa vain kauniisiin kaavioihin. Se on aika tarkka ratkaisu. Voit jopa peittää kaavioita kuluneelta vuodelta vertailua varten - grafana pystyy siihen.

Johtopäätös

En tiedä miksi, mutta rakastan tällaisia ​​kaavioita. Ne osoittavat, että elämä on täydessä vauhdissa ja kaikki muuttuu. Eilen oli paljon, tänään vähän, huomenna on jotain muuta. Jäljelle jää työskentely kotitalouksien kanssa kulutuksen parissa. Mutta tämänhetkiselläkin ruokahalulla jo pelkkä iso ja käsittämätön luku laskussa on muuttumassa jo varsin ymmärrettäväksi kulutuksesta.

Huolimatta lähes 20-vuotisesta ohjelmoijaurastani, en käytännössä ollut tietokantojen risteyksessä. Siksi ulkoisen tietokannan asentaminen tuntui jotenkin niin vaikeaselkoiselta ja käsittämättömältä. Kaikki on muuttunut yllä oleva artikkeli - kävi ilmi, että sopivan työkalun ruuvaaminen onnistuu parilla napsautuksella ja erikoistyökalulla piirtäminen helpottuu hieman.

Otsikossa mainitsin sähkön kulutuksen. Valitettavasti en voi tällä hetkellä tarjota mitään kaaviota. Yksi SDM120-mittari on kuollut, ja toinen on buginen, kun sitä käytetään Modbusin kautta. Tämä ei kuitenkaan vaikuta tämän artikkelin aiheeseen millään tavalla - kaaviot rakennetaan samalla tavalla kuin vesi.

Tässä artikkelissa olen antanut ne lähestymistavat, joita olen itse kokeillut. Varmasti on muitakin tapoja järjestää tiedon kerääminen ja visualisointi, joista en tiedä. Kerro siitä minulle kommenteissa, olen erittäin kiinnostunut. Otan mielelläni vastaan ​​rakentavaa kritiikkiä ja uusia ideoita. Toivon, että yllä oleva materiaali auttaa myös jotakuta.

Lähde: will.com