Viedā māja: ūdens un elektrības patēriņa uzskaite mājas palīgā

Katru reizi, kad saņemu maksājumu par elektrību un ūdeni, aizdomājos - vai tiešām mana ģimene patērē tik daudz? Nu jā, vannas istabā ir apsildāmā grīda un apkures katls, bet tie nestrādā kā ugunsdzēsēji visu laiku. Šķiet, ka taupām arī ūdeni (lai gan mums patīk arī plunčāties vannas istabā). Pirms dažiem gadiem es jau pieslēgti ūdens skaitītāji и elektrība uz gudru māju, taču šeit viss iestrēga. Līdz patēriņa analīzei rokas ir nonākušas tikai tagad, par ko patiesībā arī ir šis raksts.

Es nesen pārgāju uz Mājas palīgu kā savu viedās mājas sistēmu. Viens no iemesliem bija tikai iespēja organizēt liela apjoma datu vākšanu ar iespēju ērti konstruēt dažāda veida grafikus.

Šajā rakstā aprakstītā informācija nav jauna, visas šīs lietas zem dažādām mērcēm jau ir aprakstītas internetā. Bet katrs raksts, kā likums, apraksta tikai vienu pieeju vai aspektu. Nācās visas šīs pieejas salīdzināt un pašam izvēlēties piemērotāko. Raksts joprojām nesniedz izsmeļošu informāciju par datu vākšanu, bet ir sava veida kopsavilkums par to, kā es to izdarīju. Tāpēc tiek gaidīta konstruktīva kritika un uzlabojumu ieteikumi.

Problēmas paziņojums

Tātad, šodienas vingrinājuma mērķis ir iegūt skaistus ūdens un elektrības patēriņa grafikus:

• Reizi stundā 2 dienas
• Katru dienu 2 nedēļas
• (pēc izvēles) katru nedēļu un mēnesi

Šajā sakarā ir dažas grūtības:

• Standarta diagrammas komponenti mēdz būt diezgan slikti. Labākajā gadījumā līniju diagrammu var izveidot pēc punktiem.

  Ja labi meklējat, varat atrast trešo pušu komponentus, kas paplašina standarta diagrammas iespējas. Mājas palīgam principā laba un skaista sastāvdaļa mini grafikas karte, taču tas ir arī nedaudz ierobežots:

  • Ir grūti iestatīt joslu diagrammas parametrus lielos intervālos (joslas platums ir iestatīts stundas daļās, kas nozīmē, ka intervāli, kas garāki par stundu, tiks iestatīti daļskaitļos)
  • Vienai diagrammai nevar pievienot dažādas entītijas (piemēram, temperatūru un mitrumu vai apvienot joslu diagrammu ar līniju).
• Mājas palīgs ne tikai pēc noklusējuma izmanto primitīvāko SQLite datu bāzi (un es, palīgstrādnieks, nepārvaldīju MySQL vai Postgres instalēšanu), dati netiek glabāti optimālākajā veidā. Tā, piemēram, ar katru pat mazākā parametra digitālā parametra maiņu datu bāzē tiek ierakstīts milzīgs aptuveni kilobaita lielums.

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

  Man ir diezgan daudz sensoru (temperatūras sensori katrā istabā, ūdens un elektrības skaitītāji), un daži arī ģenerē diezgan daudz datu. Piemēram, tikai elektrības skaitītājs SDM220 ik pēc 10-15 sekundēm ģenerē apmēram duci vērtību, un es gribētu uzstādīt 8 šādus skaitītājus. Un ir arī vesela virkne parametru, kas tiek aprēķināti, pamatojoties uz citiem sensoriem. Tas. visas šīs vērtības var viegli palielināt datubāzi par 100-200 MB dienā. Pēc nedēļas sistēma tik tikko mētāsies un griezīsies, un pēc mēneša zibatmiņas disks nomirs (parastas mājas palīga instalēšanas gadījumā uz Raspberry PI), un par datu glabāšanu veselu gadu nevar būt ne runas. .

• Ja jums paveicas, jūsu skaitītājs pats var uzskaitīt patēriņu. Jūs jebkurā laikā varat sazināties ar skaitītāju un jautāt, cikos ir uzkrātā patēriņa vērtība. Parasti šādu iespēju nodrošina visi elektrības skaitītāji, kuriem ir digitālais interfeiss (RS232/RS485/Modbus/Zigbee).

  Sliktāk, ja ierīce var vienkārši izmērīt kādu momentāno parametru (piemēram, momentāno jaudu vai strāvu) vai vienkārši ģenerēt impulsus ik pēc X vatstundām vai litriem. Tad jādomā, kā un ar ko to integrēt un kur uzkrāt vērtību. Pastāv risks jebkura iemesla dēļ nokavēt nākamo ziņojumu, un visas sistēmas precizitāte rada jautājumus. To visu, protams, varat uzticēt viedās mājas sistēmai, piemēram, mājas asistentam, taču neviens nav atcēlis punktu par ierakstu skaitu datu bāzē, un aptaujas sensori biežāk nekā reizi sekundē nedarbosies (ierobežojums mājas palīga arhitektūra).

1. pieeja

Vispirms apskatīsim, kāds mājas palīgs tiek nodrošināts no komplektācijas. Patēriņa mērīšana noteiktā laika posmā ir ļoti pieprasīta funkcija. Protams, tas tika ieviests jau sen kā specializēts komponents - utility_meter.

Komponenta būtība ir tāda, ka tas palaiž iekšā mainīgo pašreizējo_uzkrāto_vērtību un atiestata to pēc noteikta perioda (stunda/nedēļa/mēnesis). Komponents pats uzrauga ienākošo mainīgo (kaut kāda veida sensora vērtību), parakstās uz pašas vērtības izmaiņām - jūs vienkārši iegūstat gatavo rezultātu. Šī lieta ir aprakstīta tikai dažās rindās konfigurācijas failā

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

Šeit sensor.water_meter_cold ir pašreizējā skaitītāja vērtība litros, ko es saņemu tieši no gludekļa ar mqtt. Dizains rada 2 jaunus sensorus water_cold_hour_um un water_cold_day_um, kas uzkrāj stundas un dienas rādījumus, atiestatot tos uz nulli pēc perioda. Šeit ir grafiks par stundas akumulatora uzlādi pusi dienas.

Lovelace-UI stundu un dienas diagrammas kods izskatās šādi:

      - 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

Faktiski šajā algoritmā slēpjas šīs pieejas problēma. Kā jau minēju, katrai ienākošajai vērtībai (pašreizējais skaitītāja rādījums katram nākamajam litram) datu bāzē tiek ģenerēts 1kb ieraksta. Katrs komunālo pakalpojumu skaitītājs ģenerē arī jaunu vērtību, kas arī tiek pievienota bāzei. Ja vēlos savākt stundas/dienas/nedēļas/mēneša rādījumus, jā, vairākiem ūdens stāvvadiem un pat pievienot elektrisko skaitītāju paku, tas būs daudz datu. Nu, precīzāk, datu nav daudz, bet, tā kā mājas palīgs datubāzē ieraksta kaudzi nevajadzīgas informācijas, datu bāzes apjoms pieaugs par lēcieniem. Es pat baidos novērtēt bāzes lielumu nedēļas un mēneša diagrammām.

Turklāt pats komunālo pakalpojumu skaitītājs problēmu neatrisina. Komunālo pakalpojumu skaitītāja diagramma ir monotoni pieaugoša funkcija, kas katru stundu tiek atiestatīta uz 0. Vajag arī lietotājam draudzīgu patēriņa grafiku, cik litru periodā apēsts. Standarta vēstures diagrammas komponents to nedara, bet ārējais mini grafikas kartes komponents var mums palīdzēt.

Šis ir lovelace-UI kartes kods:

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

Papildus standarta iestatījumiem, piemēram, sensora nosaukumam, diagrammas veidam, krāsai (man nepatika standarta oranžā krāsa), šeit ir svarīgi atzīmēt 3 iestatījumus:

• group_by:hour — diagramma tiks ģenerēta ar kolonnām, kas līdzinātas stundas sākumam
• punkti_stundā: 1 — viena josla stundā
• Un pats galvenais, aggregate_func: max ir katras stundas laikā izmantot maksimālo vērtību. Tas ir šis parametrs, kas pārvērš zāģa zoba diagrammu joslās.

Nepievērsiet uzmanību kolonnu rindai kreisajā pusē - tā ir komponenta standarta uzvedība, ja nav datu. Bet datu nebija - datu vākšanu, izmantojot komunālo pakalpojumu skaitītāju, ieslēdzu tikai pirms pāris stundām tikai šī raksta labad (savu pašreizējo pieeju aprakstīšu nedaudz zemāk).

Šajā attēlā es gribēju parādīt, ka dažreiz datu displejs pat darbojas, un joslas patiešām atspoguļo pareizās vērtības. Bet tas vēl nav viss. Nez kāpēc iezīmētajā kolonnā laika posmam no 11:12 līdz 19:62 ir redzami XNUMX litri, lai gan zobainajā grafikā par to pašu periodu no tā paša sensora redzams XNUMX litru patēriņš. Vai nu blaktis, vai rokas ir šķības. Bet es joprojām nesaprotu, kāpēc labās puses dati nolūza - patēriņš tur bija normāls, kas redzams arī no zobainā grafika.

Kopumā man neizdevās panākt šīs pieejas ticamību - grafikā gandrīz vienmēr ir redzama kāda ķecerība.

Līdzīgs kods dienas sensoram.

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

Lūdzu, ņemiet vērā, ka parametrs group_by ir iestatīts uz intervālu, un parametrs points_per_hour nosaka visu. Un šī ir vēl viena šī komponenta problēma - punkti_stundā labi darbojas stundu vai mazāku grafiku diagrammās, bet pretīgi ar lielākiem intervāliem. Tātad, lai vienā dienā iegūtu vienu kolonnu, man bija jāievada vērtība 1/24=0.04166666. Es nerunāju par nedēļas un mēneša diagrammām.

2. pieeja

Joprojām izdomājot mājas palīgu, es uzgāju šo video:

Biedrs vāc patēriņa datus no vairāku veidu Xiaomi rozetēm. Viņa uzdevums ir nedaudz vienkāršāks - vienkārši parādiet patēriņa vērtību šodienai, vakardienai un mēnesim. Nav nepieciešamas diagrammas.

Atstāsim malā argumentus par momentānās jaudas vērtību manuālu integrāciju - par šīs pieejas “precizitāti” es jau rakstīju iepriekš. Nav skaidrs, kāpēc viņš neizmantoja uzkrātās patēriņa vērtības, kuras jau savāc viena un tā pati tirdzniecības vieta. Manuprāt, integrācija dzelzs gabala iekšienē darbosies labāk.

No videoklipa mēs ņemsim vērā ideju par patēriņa manuālu skaitīšanu noteiktā periodā. Vīrietim tiek ņemtas vērā tikai šodienas un vakardienas vērtības, bet mēs iesim tālāk un mēģināsim uzzīmēt grafiku. Piedāvātās metodes būtība manā gadījumā ir šāda.

Mēs izveidosim mainīgo value_at_the_beginning_of_hour, kurā ierakstīsim pašreizējos skaitītāja rādījumus
Saskaņā ar taimeri stundas beigās (vai nākamās sākumā) mēs aprēķinām starpību starp pašreizējo un stundas sākumā saglabāto rādījumu. Šī starpība būs pašreizējās stundas patēriņš - mēs saglabāsim vērtību sensorā, un nākotnē mēs veidosim grafiku, pamatojoties uz šo vērtību.
Tāpat ir “jāatiestata” mainīgais value_at_beginning_of_hour, ierakstot tur pašreizējo skaitītāja vērtību.

To visu var izdarīt caur labi ... ar paša mājas palīga palīdzību.

Jums būs jāraksta nedaudz vairāk koda nekā iepriekšējā pieejā. Sāksim ar šiem "mainīgajiem". No kastes mums nav “mainīgās” entītijas, taču jūs varat izmantot mqtt brokera pakalpojumus. Mēs tur nosūtīsim vērtības ar reten=true karogu - tas saglabās vērtību brokera iekšpusē, un to var izņemt jebkurā laikā, pat ja mājas palīgs ir pārstartēts. Uztaisīju stundu un dienas skaitītājus uzreiz.

- 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

Visa burvība notiek automatizācijā, kas darbojas attiecīgi katru stundu un katru nakti.

- 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

Abas automatizācijas veic 2 lietas:

• Aprēķiniet vērtību katram intervālam kā starpību starp sākuma un beigu vērtību
• Atjauniniet nākamā intervāla bāzes vērtību

Grafiku uzbūve šajā gadījumā tiek atrisināta ar parasto vēstures grafiku:

      - 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

Tas izskatās šādi:

Principā tas jau ir tas, kas tev vajadzīgs. Šīs metodes priekšrocība ir tāda, ka dati tiek ģenerēti vienu reizi intervālā. Tie. kopā 24 ieraksti dienā stundu diagrammai.

Diemžēl tas joprojām neatrisina vispārējo augošās bāzes problēmu. Ja gribu ikmēneša patēriņa grafiku, dati būs jāglabā vismaz gadu. Un tā kā mājas palīgs nodrošina tikai vienu glabāšanas ilguma iestatījumu visai datubāzei, tas nozīmē, ka VISI sistēmā esošie dati būs jāglabā veselu gadu. Piemēram, gadā es patērēju 200 kubikmetrus ūdens, kas nozīmē 200000 XNUMX ierakstu datubāzē. Un, ja ņem vērā citus sensorus, tad skaitlis kopumā kļūst nepiedienīgs.

3. pieeja

Par laimi, gudri cilvēki šo problēmu jau ir atrisinājuši, uzrakstot InfluxDB datu bāzi. Šī datu bāze ir īpaši optimizēta laika datu glabāšanai un ir ideāli piemērota dažādu sensoru vērtību glabāšanai. Sistēma nodrošina arī SQL līdzīgu vaicājumu valodu, kas ļauj iegūt vērtības no datu bāzes un pēc tam apkopot tās dažādos veidos. Visbeidzot, dažādus datus var saglabāt dažādiem laikiem. Piemēram, bieži mainīgos rādījumus, piemēram, temperatūru vai mitrumu, var uzglabāt tikai pāris nedēļas, savukārt ikdienas ūdens patēriņa rādījumus var uzglabāt veselu gadu.

Papildus InfluxDB gudri cilvēki izgudroja arī Grafana, sistēmu grafiku zīmēšanai no InfluxDB datiem. Grafana var uzzīmēt dažāda veida diagrammas, tās detalizēti pielāgot, un, pats galvenais, šīs diagrammas var “pieslēgt” mājas palīgam lovelace-UI.

būt iedvesmotam šeit и šeit. Rakstos ir sīki aprakstīts InfluxDB un Grafana instalēšanas un savienošanas process ar mājas palīgu. Es koncentrēšos uz savas konkrētās problēmas risināšanu.

Tātad, pirmkārt, sāksim pievienot skaitītāja vērtību influxDB. Mājas palīga konfigurācijas gabals (šajā piemērā es izklaidēšos ne tikai ar aukstu, bet arī ar karstu ūdeni):

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

Izslēgsim to pašu datu saglabāšanu mājas palīga iekšējā datu bāzē, lai tos vēlreiz neuzpūstu:

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

Tagad pāriesim uz InfluxDB konsoli un iestatīsim datu bāzi. Jo īpaši jums ir jākonfigurē, cik ilgi noteikti dati tiks saglabāti. To regulē t.s. saglabāšanas politika — tā ir līdzīga datu bāzēm galvenajā datu bāzē, un katrai iekšējai datubāzei ir savi iestatījumi. Pēc noklusējuma visi dati tiek pievienoti saglabāšanas politikai, ko sauc par autogēnu, šie dati tiks glabāti nedēļu. Es vēlos, lai stundas dati tiktu glabāti mēnesi, nedēļas dati gadu un mēneša dati vispār netiktu dzēsti. Mēs izveidosim atbilstošas ​​saglabāšanas politikas

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

Tagad faktiski galvenais triks ir datu apkopošana, izmantojot nepārtrauktu vaicājumu. Šis ir mehānisms, kas automātiski palaiž vaicājumu noteiktos intervālos, apkopo šī vaicājuma datus un pievieno rezultātu jaunai vērtībai. Apskatīsim piemēru (lasāmības labad es rakstu kolonnā, bet patiesībā man bija jāievada šī komanda vienā rindā)

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

Šī komanda:

• Homessistant datu bāzē izveido nepārtrauktu vaicājumu ar nosaukumu cq_water_cold_hourly
• Vaicājums tiks izpildīts katru stundu (laiks(1h))
• Vaicājums izvilks visus datus no mērījuma'a homeassistant.autogen.l (litri), tostarp aukstā un karstā ūdens rādījumus.
• Apkopotie dati tiks grupēti pēc entity_id, kas izveidos atsevišķas aukstā un karstā ūdens vērtības.
• Tā kā litru skaitītājs ir monotoni pieaugoša secība katras stundas laikā, jums būs jāņem maksimālā vērtība, tāpēc apkopošanu veiks funkcija max(value)
• Jaunā vērtība tiks rakstīta uz homeassistant.month.water_meter_hour, kur mēnesis ir saglabāšanas politikas nosaukums ar vienu mēnesi ilgu saglabāšanas periodu. Turklāt dati par auksto un karsto ūdeni tiks izkaisīti atsevišķos ierakstos ar atbilstošo entity_id un vērtību vērtības laukā.

Naktī vai tad, kad neviena nav mājās, nav ūdens patēriņa, un attiecīgi arī homeassistant.autogen.l nav jaunu rekordu. Lai izvairītos no trūkstošām vērtībām parastajos vaicājumos, varat izmantot aizpildījumu (iepriekšējais). Tas liks InfluxDB izmantot pēdējo stundu vērtību.

Diemžēl nepārtrauktam vaicājumam ir sava īpatnība: aizpildīšanas (iepriekšējais) triks nedarbojas, un ieraksti vienkārši netiek izveidoti. Turklāt šī ir sava veida nepārvarama problēma, kas tiek apspriests vairāk nekā gadu. Mēs šo problēmu risināsim vēlāk un ļaujiet aizpildīt(iepriekšējais) nepārtrauktajā vaicājumā - tas netraucē.

Pārbaudīsim, kas notika (protams, jums jāpagaida pāris stundas):

> 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

Ņemiet vērā, ka datu bāzē esošās vērtības tiek glabātas UTC, tāpēc šis saraksts atšķiras par 3 stundām - 7:10 vērtības InfluxDB izvadē atbilst 2:5 vērtībām iepriekš redzamajās diagrammās. Ņemiet vērā arī to, ka no pulksten XNUMX līdz XNUMX no rīta vienkārši nav ierakstu - tā ir nepārtrauktas vaicājuma iezīme.

Kā redzams, arī apkopotā vērtība ir monotoni pieaugoša secība, tikai ieraksti notiek retāk - reizi stundā. Bet tā nav problēma - mēs varam uzrakstīt citu vaicājumu, kas izgūs pareizos datus diagrammai.

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)

Es atšifrēšu:

• No datu bāzes homeassistant.month.water_meter_hour mēs iegūsim datus par entity_id='water_meter_cold' par pēdējo dienu (laiks >= tagad() -24h).
• Kā jau minēju, secībā homeassistant.month.water_meter_hour var trūkt daži ieraksti. Mēs atjaunosim šos datus, izpildot vaicājumu ar GROUP BY time(1h). Šoreiz aizpildīšana (iepriekšējais) darbosies pareizi, ģenerējot trūkstošos datus (funkcija izmantos iepriekšējo vērtību)
• Pats svarīgākais šajā vaicājumā ir starpības funkcija, kas aprēķinās starpību starp stundu atzīmēm. Pats par sevi tas nedarbojas un prasa apkopošanas funkciju. Lai tas ir iepriekš izmantotais max().

Izpildes rezultāts izskatās šādi

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

No pulksten 2 līdz 5 (UTC) nebija patēriņa. Neskatoties uz to, vaicājums atgriezīs to pašu patēriņa vērtību, pateicoties fill(previous), un atšķirības funkcija atņems šo vērtību no sevis un izvadā iegūs 0, kas faktiski ir nepieciešama.

Vienīgais, kas jādara, ir izveidot grafiku. Lai to izdarītu, atveriet Grafana, atveriet kādu esošu (vai izveidojiet jaunu) informācijas paneli, izveidojiet jaunu paneli. Diagrammas iestatījumi būs šādi.

Aukstā un karstā ūdens datus parādīšu tajā pašā grafikā. Pieprasījums ir tieši tāds pats kā es aprakstīju iepriekš.

Displeja parametri tiek iestatīti šādi. Man tas būs grafiks ar līnijām (līnijām), kas iet pa soļiem (kāpnēm). Stack parametrs tiks paskaidrots tālāk. Zemāk ir vēl pāris displeja opcijas, taču tās nav tik interesantas.

Lai pievienotu iegūto grafiku mājas palīgam, jums ir nepieciešams:

• iziet no diagrammas rediģēšanas režīma. Kādu iemeslu dēļ pareizi diagrammu koplietošanas iestatījumi tiek piedāvāti tikai informācijas paneļa lapā
• Noklikšķiniet uz trīsstūra blakus diagrammas nosaukumam, izvēlnē atlasiet koplietot
• Atvērtajā logā dodieties uz iegulšanas cilni
• Noņemiet atzīmi no pašreizējā laika diapazona — mēs iestatīsim laika diapazonu, izmantojot URL
• Izvēlieties vajadzīgo tēmu. Manā gadījumā tas ir viegls
• Kopējiet iegūto URL lovelace-UI iestatījumu kartītē

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

Lūdzu, ņemiet vērā, ka laika diapazons (pēdējās 2 dienas) ir iestatīts šeit, nevis informācijas paneļa iestatījumos.

Diagramma izskatās šādi. Pēdējās 2 dienas neesmu lietojis karsto ūdeni, tāpēc tiek uzzīmēts tikai aukstā ūdens grafiks.

Es pats neesmu izlēmis, kura diagramma man patīk vislabāk, soļu līnija vai īstas joslas. Tāpēc es vienkārši došu piemēru par ikdienas patēriņa grafiku, tikai šoreiz bāros. Vaicājumi tiek veidoti tādā pašā veidā, kā aprakstīts iepriekš. Displeja opcijas ir šādas:

Šī diagramma izskatās šādi:

Tātad, par Stack parametru. Šajā diagrammā aukstā ūdens josla ir uzzīmēta virs karstās joslas. Kopējais augstums atbilst kopējam aukstā un karstā ūdens patēriņam attiecīgajā periodā.

Visas parādītās diagrammas ir dinamiskas. Varat pārvietot peli virs interesējošā punkta un skatīt detalizētu informāciju un vērtību konkrētā punktā.

Diemžēl neiztika arī bez pāris mušām. Joslu diagrammā (atšķirībā no diagrammas ar soļu līnijām) joslas vidus atrodas nevis dienas vidū, bet gan pulksten 00:00. Tie. iepriekšējās dienas vietā tiek novilkta joslas kreisā puse. Tātad sestdienas un svētdienas diagrammas ir novilktas nedaudz pa kreisi no zilganas zonas. Līdz brīdim, kad es sapratu, kā to uzvarēt.

Vēl viena problēma ir nespēja pareizi strādāt ar ikmēneša intervāliem. Fakts ir tāds, ka stundas / dienas / nedēļas garums ir fiksēts, bet mēneša garums katru reizi ir atšķirīgs. InfluxDB var darboties tikai ar vienādiem intervāliem. Līdz šim manas smadzenes ir bijušas pietiekami, lai iestatītu fiksētu 30 dienu intervālu. Jā, gada laikā grafiks nedaudz peldēs un stabiņi precīzi neatbildīs mēnešiem. Bet, tā kā šī lieta man ir interesanta tikai kā displeja mērītājs, es ar to esmu ok.

Es redzu vismaz divus risinājumus:

• Lai gūtu punktus mēneša diagrammās un ierobežotu sevi ar iknedēļas diagrammām. 52 iknedēļas batoniņi gadā izskatās diezgan labi
• Apsveriet pašu ikmēneša patēriņu kā metodi Nr. 2 un izmantojiet grafānu tikai skaistiem grafikiem. Tas ir diezgan precīzs risinājums. Salīdzinājumam varat pat pārklāt diagrammas par iepriekšējo gadu — to var izdarīt grafana.

Secinājums

Es nezinu, kāpēc, bet man patīk šāda veida diagrammas. Tie parāda, ka dzīve rit pilnā sparā un viss mainās. Vakar bija daudz, šodien maz, rīt būs kas cits. Atliek strādāt ar mājsaimniecībām par patēriņa tēmu. Bet pat ar pašreizējām apetītēm tikai liels un nesaprotams skaitlis rēķinā jau pārvēršas par diezgan saprotamu patēriņa ainu.

Neskatoties uz gandrīz 20 gadus ilgo programmētāja karjeru, ar datu bāzēm praktiski nekrustojos. Tāpēc ārējas datu bāzes instalēšana šķita kaut kas tik neskaidrs un nesaprotams. Viss ir mainījies iepriekš minētais raksts - izrādījās, ka piemērota instrumenta pieskrūvēšana tiek veikta pāris klikšķu laikā, un ar specializētu rīku zīmēšanas uzdevums kļūst nedaudz vieglāks.

Virsrakstā minēju elektrības patēriņu. Diemžēl šobrīd nevaru sniegt nekādas diagrammas. Viens SDM120 skaitītājs ir miris, bet otrs ir buggy, kad tam piekļūst, izmantojot Modbus. Taču tas nekādi neietekmē šī raksta tēmu – grafiki tiks veidoti tāpat kā ūdenim.

Šajā rakstā es sniedzu tās pieejas, kuras esmu izmēģinājis pats. Protams, ir daži citi veidi, kā organizēt datu vākšanu un vizualizāciju, par kuriem es nezinu. Pastāsti man par to komentāros, man būs ļoti interesanti. Priecāšos par konstruktīvu kritiku un jaunām idejām. Ceru, ka kādam noderēs arī iepriekš minētais materiāls.

Avots: www.habr.com