Smarthus: Vi bygger grafer over vann- og strømforbruk i Home Assistant

Hver gang jeg mottar betaling for strøm og vann, blir jeg overrasket – bruker familien min virkelig så mye? Vel, ja, badet har et oppvarmet gulv og en kjele, men de brenner ikke hele tiden. Vi ser også ut til å spare vann (selv om vi også liker å plaske rundt på badet). For flere år siden har jeg allerede tilkoblede vannmålere и elektrisitet til et smart hjem, men det var der ting satt seg fast. Vi har først nå kommet oss i gang med å analysere forbruket, det er det denne artikkelen faktisk handler om.

Jeg byttet nylig til Home Assistant som mitt smarthussystem. En av grunnene var nettopp muligheten til å organisere innsamlingen av en stor mengde data med muligheten til enkelt å konstruere ulike typer grafer.

Informasjonen beskrevet i denne artikkelen er ikke ny; alle disse tingene under forskjellige sauser har allerede blitt beskrevet på Internett. Men hver artikkel beskriver vanligvis bare én tilnærming eller aspekt. Jeg måtte sammenligne alle disse tilnærmingene og velge den best egnede selv. Artikkelen gir fortsatt ikke utfyllende informasjon om datainnsamling, men er en slags oppsummering av hvordan jeg gjorde det. Så konstruktiv kritikk og forslag til forbedringer mottas med takk.

Formulering av problemet

Så målet med dagens øvelse er å få vakre grafer over vann- og strømforbruk:

• Hver time i 2 dager
• Daglig i 2 uker
• (valgfritt) ukentlig og månedlig

Det er noen vanskeligheter med dette:

• Standard kartkomponenter er vanligvis ganske dårlige. I beste fall kan du bygge en linjegraf punkt for punkt.

  Hvis du ser godt nok etter, kan du finne tredjepartskomponenter som utvider funksjonene til standarddiagrammet. For en hjemmeassistent er dette i prinsippet en god og vakker komponent minigrafkort, men det er også noe begrenset:

  • Det er vanskelig å angi parametrene til et stolpediagram over store intervaller (bredden på stolpen settes i brøkdeler av en time, noe som betyr at intervaller lengre enn en time vil bli satt i brøktall)
  • Du kan ikke legge til forskjellige enheter i én graf (for eksempel temperatur og fuktighet, eller kombinere et søylediagram med en linje)
• Ikke bare bruker hjemmeassistent som standard den mest primitive SQLite-databasen (og jeg, en altmuligmann, klarte ikke å installere MySQL eller Postgres), men dataene lagres ikke på den mest optimale måten. Så, for eksempel, hver gang du endrer selv den minste digitale parameteren til en parameter, skrives en stor json på omtrent en kilobyte til databasen

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

  Jeg har ganske mange sensorer (temperatursensorer i hvert rom, vann- og strømmålere), og noen genererer også ganske mye data. For eksempel genererer strømmåleren SDM220 alene omtrent et dusin verdier hvert 10.-15. sekund, og jeg vil gjerne installere omtrent 8 slike målere. Det er også en hel haug med parametere som beregnes basert på andre sensorer. At. alle disse verdiene kan enkelt blåse opp databasen med 100-200 MB daglig. Om en uke vil systemet knapt bevege seg, og om en måned vil flash-stasjonen dø (i tilfelle av en typisk hjemmeassistentinstallasjon på en Raspberry PI), og lagring av data i et helt år er uaktuelt.

• Hvis du er heldig, kan måleren telle forbruket selv. Du kan når som helst henvende deg til måleren og spørre når den akkumulerte forbruksverdien er. Som regel gir alle strømmålere som har digitalt grensesnitt (RS232/RS485/Modbus/Zigbee) denne muligheten.

  Det er verre hvis enheten bare kan måle en momentan parameter (for eksempel øyeblikkelig kraft eller strøm), eller ganske enkelt generere pulser hver X watt-time eller liter. Deretter må du tenke på hvordan og med hva du skal integrere det og hvor du skal samle verdi. Det er en risiko for å gå glipp av neste rapport uansett årsak, og nøyaktigheten av systemet som helhet reiser spørsmål. Du kan selvfølgelig overlate alt dette til et smarthjemsystem som hjemmeassistent, men ingen har kansellert punktet om antall poster i databasen, og det vil ikke være mulig å polle sensorer mer enn én gang i sekundet (a begrensning av hjemmeassistentarkitekturen).

Tilnærming 1

Først, la oss se hva hjemmeassistent gir ut av esken. Å måle forbruk over en periode er en svært ettertraktet funksjonalitet. Selvfølgelig ble det implementert for lenge siden i form av en spesialisert komponent - utility_meter.

Essensen av komponenten er at den internt lager en variabel strøm_akkumulert_verdi og tilbakestiller den etter en spesifisert periode (time/uke/måned). Selve komponenten overvåker inngangsvariabelen (verdien til en sensor), abonnerer på endringer i verdien - du får bare det ferdige resultatet. Denne tingen er beskrevet på bare noen få linjer i konfigurasjonsfilen

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

Her er sensor.water_meter_cold gjeldende målerverdi i liter som jeg mottar direkte fra jernstykket av mqtt. Designet skaper 2 nye sensorer water_cold_hour_um og water_cold_day_um, som akkumulerer time- og daglige målinger, og tilbakestiller dem til null etter at perioden er utløpt. Her er en graf over timebatteriet for en halv dag.

Koden for time- og daglige diagrammer for lovelace-UI ser slik ut:

      - 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

Faktisk ligger problemet med denne tilnærmingen i denne algoritmen. Som jeg allerede har nevnt, for hver inngangsverdi (gjeldende måleravlesning for hver neste liter) genereres 1kb med poster i databasen. Hver nyttemåler genererer også en ny verdi, som også legges til basen. Hvis jeg ønsker å samle time/daglig/ukentlig/månedlig målinger, og for flere vannstigere, og legge til en pakke elektriske målere, blir det mye data. Vel, mer presist er det ikke mye data, men siden hjemmeassistenten skriver en haug med unødvendig informasjon til databasen, vil størrelsen på databasen vokse med stormskritt. Jeg er redd for å anslå størrelsen på basen for ukentlige og månedlige diagrammer.

I tillegg løser ikke verktøymåleren i seg selv problemet. Grafen over verdiene produsert av nyttemåleren er en monotont økende funksjon som tilbakestilles til 0 hver time. Vi trenger et forbruksdiagram som er forståelig for brukeren, som viser hvor mange liter som ble forbrukt i perioden. Standard historie-graf-komponenten kan ikke gjøre dette, men den eksterne mini-graf-kort-komponenten kan hjelpe oss.

Dette er kortkoden for lovelace-UI:

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

I tillegg til standardinnstillinger som sensornavn, graftype, farge (jeg likte ikke standard oransje), er det viktig å merke seg 3 innstillinger:

• group_by:hour — grafen vil bli generert med søylene på linje med begynnelsen av timen
• points_per_hour: 1 - en bar for hver time
• Og viktigst av alt, aggregate_func: max – ta maksimalverdien innen hver time. Det er denne parameteren som gjør sagtanngrafen til stolper

Ikke vær oppmerksom på raden med kolonner til venstre - dette er standardoppførselen til komponenten hvis det ikke er data. Men det var ingen data - jeg satte nettopp på datainnsamling for verktøymålere for et par timer siden bare for denne artikkelens skyld (jeg vil beskrive min nåværende tilnærming litt lavere).

I dette bildet ønsket jeg å vise at noen ganger fungerer datavisningen til og med, og søylene gjenspeiler faktisk de riktige verdiene. Men det er ikke alt. Av en eller annen grunn viser den valgte kolonnen for perioden fra kl. 11 til 12 19 liter, selv om vi på den tannaktige grafen litt høyere for samme periode fra samme sensor ser forbruket på 62 liter. Enten er det en feil eller så er hendene skjeve. Men jeg forstår fortsatt ikke hvorfor dataene til høyre brøt av - forbruket der var normalt, noe som også er synlig fra den tannige grafen.

Generelt klarte jeg ikke å oppnå plausibiliteten til denne tilnærmingen - grafen viser nesten alltid en slags kjetteri.

Lignende kode for dagtidssensoren.

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

Vær oppmerksom på at group_by-parameteren er satt til intervall, og parameteren points_per_hour styrer alt. Og der ligger et annet problem med denne komponenten - points_per_hour fungerer bra på diagrammer på en time eller mindre, men det suger på større intervaller. Så for å få én kolonne på en dag, måtte jeg angi verdien 1/24=0.04166666. Jeg snakker ikke engang om ukentlige og månedlige diagrammer.

Tilnærming 2

Mens jeg fortsatt forstod hjemmeassistenten, kom jeg over denne videoen:

En venn samler inn forbruksdata fra flere typer Xiaomi-stikkontakter. Oppgaven hans er litt enklere - bare vis forbruksverdien for i dag, i går og for måneden. Ingen tidsplaner kreves.

La oss legge bort diskusjoner om manuell integrasjon av øyeblikkelige kraftverdier - jeg skrev allerede ovenfor om "nøyaktigheten" til denne tilnærmingen. Det er ikke klart hvorfor han ikke brukte de akkumulerte forbruksverdiene, som allerede er samlet inn av samme utsalgssted. Etter min mening vil integrering inne i maskinvaren fungere bedre.

Fra videoen tar vi ideen om å telle forbruk manuelt over en periode. Fyren teller bare verdiene for i dag og i går, men vi vil gå videre og prøve å tegne en graf. Essensen av den foreslåtte metoden i mitt tilfelle er som følger.

La oss lage en variabel verdi_ved_begynnelsen_av_timen, der vi registrerer gjeldende måleravlesninger
Ved å bruke tidtakeren, ved slutten av timen (eller i begynnelsen av neste) beregner vi forskjellen mellom gjeldende avlesning og den som er lagret ved begynnelsen av timen. Denne forskjellen vil være forbruket for den aktuelle timen - vi vil lagre verdien i sensoren, og i fremtiden vil vi bygge en graf basert på denne verdien.
Du må også "tilbakestille" variabelen value_at_beginning_of_hour ved å skrive gjeldende tellerverdi der.

Alt dette kan gjøres gjennom hjemmeassistenten selv.

Du må skrive litt mer kode enn i forrige tilnærming. Først, la oss lage de samme "variablene". Ut av boksen har vi ikke den "variable" enheten, men vi kan bruke tjenestene til mqtt-megleren. Vi vil sende verdier dit med retain=true-flagget - dette vil lagre verdien inne i megleren, og den kan trekkes ut derfra når som helst, selv når hjemmeassistenten startes på nytt. Jeg lagde time- og dagligtellere på en gang.

- 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

All magien skjer i automatiseringen, som går henholdsvis hver time og hver natt.

- 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

Begge automatiseringer utfører 2 handlinger:

• Beregn verdien for et intervall som forskjellen mellom start- og sluttverdier
• Oppdater grunnverdien for neste intervall

Konstruksjonen av grafer i dette tilfellet løses av den vanlige historiegrafen:

      - 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

Det ser slik ut:

I prinsippet er dette allerede det som trengs. Fordelen med denne metoden er at dataene genereres én gang per intervall. De. bare 24 poster per dag for et timediagram.

Dessverre løser dette fortsatt ikke det generelle problemet med en voksende base. Hvis jeg vil ha en månedlig forbruksgraf, må jeg lagre data i minst ett år. Og siden hjemmeassistent kun gir én innstilling for lagringsvarighet for hele databasen, betyr dette at ALLE data i systemet må lagres i et helt år. For eksempel, på et år forbruker jeg 200 kubikkmeter vann, noe som betyr at dette betyr 200000 XNUMX oppføringer i databasen. Og hvis du tar hensyn til andre sensorer, blir figuren generelt uanstendig.

Tilnærming 3

Heldigvis har smarte mennesker allerede løst dette problemet ved å skrive InfluxDB-databasen. Denne databasen er spesielt optimalisert for lagring av tidsbaserte data og er ideell for lagring av verdier til forskjellige sensorer. Systemet har også et SQL-lignende spørrespråk som lar deg trekke ut verdier fra databasen og deretter aggregere dem på ulike måter. Til slutt kan forskjellige data lagres til forskjellige tider. For eksempel kan hyppige endringer som temperatur eller fuktighet lagres i bare et par uker, mens avlesninger av daglig vannforbruk kan lagres i et helt år.

Foruten InfluxDB, oppfant smarte mennesker også Grafana, et system for å tegne grafer basert på data fra InfluxDB. Grafana kan tegne forskjellige typer grafer, tilpasse dem i detalj, og viktigst av alt, disse grafene kan "plugges" til lovelace-UI hjemmeassistenten.

Bli inspirert her и her. Artiklene beskriver i detalj prosessen med å installere og koble InfluxDB og Grafana til hjemmeassistenten. Jeg vil fokusere på å løse mitt spesifikke problem.

Så, først av alt, la oss begynne å legge til tellerverdien i influxDB. En del av hjemmeassistentkonfigurasjonen (i dette eksemplet vil jeg ha det gøy med ikke bare kaldt, men også varmt vann):

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

La oss deaktivere lagring av de samme dataene i den interne hjemmeassistentdatabasen for ikke å blåse den opp igjen:

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

La oss nå gå til InfluxDB-konsollen og konfigurere databasen vår. Spesielt må du konfigurere hvor lenge visse data skal lagres. Dette er regulert av den såkalte. retensjonspolicy - dette ligner på databaser i en hoveddatabase, med hver interne database med sine egne innstillinger. Som standard lagres alle data i en oppbevaringspolicy kalt autogen; disse dataene vil bli lagret i en uke. Jeg vil at timedataene skal oppbevares i en måned, de ukentlige dataene skal lagres i et år, og de månedlige dataene aldri blir slettet. La oss lage den riktige oppbevaringspolitikken

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å er faktisk hovedtrikset dataaggregering ved hjelp av kontinuerlig spørring. Dette er en mekanisme som automatisk kjører en spørring med angitte intervaller, samler dataene for denne spørringen og legger resultatet til en ny verdi. La oss se på et eksempel (jeg skriver i en kolonne for lesbarhet, men i virkeligheten måtte jeg skrive inn denne kommandoen på en linje)

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

Denne kommandoen:

• Oppretter en kontinuerlig spørring kalt cq_water_cold_hourly i hjemmeassistentdatabasen
• Forespørselen vil bli utført hver time (tid(1t))
• Forespørselen vil skrape alle data fra målingens homeassistant.autogen.l (liter), inkludert avlesninger for kaldt og varmt vann
• De aggregerte dataene vil bli gruppert etter entity_id, som vil gi oss separate verdier for kaldt og varmt vann
• Siden litertelleren er en monotont økende sekvens innen hver time, vil det være nødvendig å ta maksimumsverdien, så aggregering vil bli utført av funksjonen max(verdi)
• Den nye verdien vil bli skrevet til homeassistant.month.water_meter_hour, der måned er navnet på oppbevaringspolicyen med en oppbevaringsperiode på én måned. Dessuten vil data om kaldt og varmt vann bli spredt i separate poster med tilsvarende entity_id og verdi i verdifeltet

Om natten eller når ingen er hjemme er det ikke vannforbruk, og derfor er det ingen nye oppføringer i hjemmeassistent.autogen.l. For å unngå manglende verdier i vanlige spørringer, kan du bruke fill(previous). Dette vil tvinge InfluxDB til å bruke verdien av den siste timen.

Dessverre har kontinuerlig spørring en særegenhet: fill(forrige)-trikset fungerer ikke og poster blir rett og slett ikke opprettet. Dessuten er dette en slags uoverkommelig problem har vært diskutert i flere år nå. Vi skal håndtere dette problemet senere, men la fill(previous) være i den kontinuerlige spørringen - det forstyrrer ikke.

La oss sjekke hva som skjedde (selvfølgelig må du vente et par timer):

> 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

Merk at verdiene i databasen er lagret i UTC, så denne listen avviker med 3 timer - 7am-verdiene i InfluxDB-utgangen tilsvarer 10am-verdiene i grafene ovenfor. Vær også oppmerksom på at mellom kl. 2 og 5 er det rett og slett ingen poster - dette er den samme funksjonen for kontinuerlig spørring.

Som du kan se, er den aggregerte verdien også en monotont økende sekvens, bare oppføringer forekommer sjeldnere - en gang i timen. Men dette er ikke et problem - vi kan skrive en annen spørring som vil hente riktige data for grafen.

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)

Jeg skal tyde:

• Fra homeassistant.month.water_meter_hour-databasen vil vi trekke ut data for entity_id='water_meter_cold' for den siste dagen (tid >= nå() -24t).
• Som jeg allerede har nevnt, kan noen oppføringer mangle i sekvensen for hjemmeassistent.month.water_meter_hour. Vi vil gjenskape disse dataene ved å kjøre en spørring med GROUP BY time(1t). Denne tidsfyllingen (forrige) vil fungere som forventet, og generere de manglende dataene (funksjonen vil ta den forrige verdien)
• Det viktigste i denne forespørselen er differansefunksjonen, som vil beregne forskjellen mellom timemerker. Det fungerer ikke alene og krever en aggregeringsfunksjon. La dette være max() brukt før.

Utførelsesresultatet ser slik ut

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

Fra 2 til 5 am (UTC) var det ikke noe forbruk. Likevel vil spørringen returnere den samme forbruksverdien takket være fill(previous), og differansefunksjonen vil trekke denne verdien fra seg selv og utgangen blir 0, som er nøyaktig det som kreves.

Alt som gjenstår er å lage en graf. For å gjøre dette, åpne Grafana, åpne et eksisterende (eller opprett et nytt) dashbord og lag et nytt panel. Kartinnstillingene vil være slik.

Jeg vil vise kaldt- og varmtvannsdata på samme graf. Forespørselen er nøyaktig den samme som jeg beskrev ovenfor.

Displayparametere stilles inn som følger. For meg blir det en graf med linjer, som går i trinn (trapper). Jeg vil forklare Stack-parameteren nedenfor. Det er et par flere visningsalternativer nedenfor, men de er ikke så interessante.

For å legge til det resulterende diagrammet til hjemmeassistenten må du:

• gå ut av diagramredigeringsmodus. Av en eller annen grunn tilbys de riktige diagramdelingsinnstillingene kun fra dashbordsiden
• Klikk på trekanten ved siden av diagramnavnet og velg del fra menyen
• Gå til innebygd-fanen i vinduet som åpnes
• Fjern merket for gjeldende tidsperiode - vi vil angi tidsintervallet via URL
• Velg ønsket emne. I mitt tilfelle er det lett
• Kopier den resulterende URL-en til lovelace-UI-innstillingskortet

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

Vær oppmerksom på at tidsrommet (siste 2 dager) angis her, og ikke i dashbordinnstillingene.

Grafen ser slik ut. Jeg har ikke brukt varmt vann de siste 2 dagene, så kun kaldtvannsgrafen er tegnet.

Jeg har fortsatt ikke bestemt meg for hvilken graf jeg liker best, et linjetrinn eller ekte søyler. Derfor vil jeg bare gi et eksempel på et daglig forbruksdiagram, bare denne gangen i søyler. Spørringene er konstruert på samme måte som de som er beskrevet ovenfor. Visningsalternativene er:

Denne grafen ser slik ut:

Så om Stack-parameteren. I denne grafen er en kolonne med kaldt vann tegnet på toppen av en kolonne med varmt vann. Totalhøyden tilsvarer det totale forbruket av kaldt og varmt vann for perioden.

Alle grafene som vises er dynamiske. Du kan holde musen over punktet av interesse og se detaljene og verdien på et bestemt punkt.

Dessverre var det et par flue i salven. På et stolpediagram (i motsetning til et diagram med trinnlinjer), er ikke midten av stolpen midt på dagen, men klokken 00:00. De. venstre halvdel av kolonnen er trukket i stedet for dagen før. Så grafene for lørdag og søndag er tegnet litt til venstre for den blålige sonen. Helt til jeg fant ut hvordan jeg skulle beseire den.

Et annet problem er manglende evne til å jobbe riktig med månedlige intervaller. Faktum er at lengden på timen/dagen/uken er fast, men lengden på måneden er forskjellig hver gang. InfluxDB kan bare fungere med like intervaller. Så langt har hjernen min vært nok til å sette et fast intervall på 30 dager. Ja, grafen vil flyte litt utover året og søylene vil ikke samsvare nøyaktig med månedene. Men siden jeg er interessert i denne tingen bare som en skjermmåler, er jeg ok med den.

Jeg ser minst to løsninger:

• Gi opp månedlige diagrammer og begrens deg til ukentlige. 52 ukentlige barer for året ser ganske bra ut
• Vurder selve månedlige forbruket som metode nr. 2, og bruk grafana kun for vakre grafer. Det vil være en ganske nøyaktig løsning. Du kan til og med overlegge grafer for det siste året for sammenligning - grafana kan også gjøre det.

Konklusjon

Jeg vet ikke hvorfor, men jeg er besatt av denne typen grafer. De viser at livet er i full gang og alt er i endring. I går var det mye, i dag er det lite, i morgen blir det noe annet. Det gjenstår bare å samarbeide med husstandsmedlemmer om temaet forbruk. Men selv med dagens appetitt, er bare et stort og uforståelig tall på betalingsseddelen allerede i ferd med å bli et ganske forståelig bilde av forbruket.

Til tross for min nesten 20 år lange karriere som programmerer, hadde jeg praktisk talt ingen kontakt med databaser. Derfor virket det å installere en ekstern database som noe så abstrut og uforståelig. Endret alt over artikkelen — det viste seg at det å feste et passende verktøy gjøres med et par klikk, og med et spesialverktøy blir oppgaven med å plotte diagrammer litt enklere.

I tittelen nevnte jeg strømforbruk. Dessverre kan jeg for øyeblikket ikke gi noen grafer. Den ene SDM120-meteren døde for meg, og den andre er glitchy når den åpnes via Modbus. Dette påvirker imidlertid ikke emnet for denne artikkelen på noen måte - grafene vil bli konstruert på samme måte som for vann.

I denne artikkelen presenterte jeg tilnærmingene jeg prøvde selv. Det er sikkert noen andre måter å organisere datainnsamling og visualisering på som jeg ikke vet om. Fortell meg om det i kommentarene, jeg vil være veldig interessert. Jeg vil være glad for konstruktiv kritikk og nye ideer. Jeg håper materialet som presenteres også vil hjelpe noen.

Kilde: www.habr.com