Hver gang jeg modtager en betaling for el og vand, tænker jeg – forbruger min familie virkelig såååå meget? Nå, ja, der er gulvvarme og kedel på badeværelset, men de fungerer ikke som brandmænd hele tiden. Vi ser også ud til at spare på vandet (selvom vi også godt kan lide at plaske på badeværelset). For et par år siden har jeg allerede и til et smart hjem, men det var her, tingene satte sig fast. Hænderne er først nået til analysen af forbruget nu, hvilket i virkeligheden er, hvad denne artikel handler om.
Jeg skiftede for nylig til Home Assistant som mit smart home-system. En af grundene var netop muligheden for at organisere indsamlingen af en stor mængde data med mulighed for bekvem konstruktion af forskellige slags grafer.
Oplysningerne beskrevet i denne artikel er ikke nye, alle disse ting under forskellige saucer er allerede blevet beskrevet på internettet. Men hver artikel beskriver som regel kun én tilgang eller aspekt. Jeg var nødt til at sammenligne alle disse tilgange og selv vælge den bedst egnede. Artiklen giver stadig ikke udtømmende information om dataindsamling, men er en slags opsummering af, hvordan jeg gjorde det. Så konstruktiv kritik og forslag til forbedringer modtages gerne.
Formulering af problemet
Så målet med dagens øvelse er at få smukke grafer over vand- og elforbrug:
- Hver time i 2 dage
- Dagligt i 2 uger
- (valgfrit) ugentligt og månedligt
Der er nogle vanskeligheder i dette:
- Standarddiagramkomponenterne har en tendens til at være ret dårlige. I bedste fald kan du bygge en linjegraf efter punkter.
Hvis du søger godt, kan du finde tredjepartskomponenter, der udvider standarddiagrammets muligheder. Til hjemmeassistent i princippet en god og smuk komponent , men det er også noget begrænset:
- Det er vanskeligt at indstille søjlediagrammets parametre med store intervaller (bredden af søjlen er sat i brøkdele af en time, hvilket betyder, at intervaller længere end en time vil blive sat i brøktal)
- Du kan ikke tilføje forskellige entiteter til én graf (f.eks. temperatur og fugtighed eller kombinere et søjlediagram med en linje)
- Ikke nok med at hjemmeassistenten bruger den mest primitive SQLite-database som standard (og jeg, handyman, mestrede ikke installationen af MySQL eller Postgres), dataene bliver ikke lagret på den mest optimale måde. Så for eksempel, med hver ændring af hver selv den mindste digitale parameter af en parameter, skrives en enorm json på omkring en kilobyte i størrelse 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 en del sensorer (temperatursensorer i alle rum, vand- og elmålere), og nogle genererer også ret meget data. For eksempel genererer kun SDM220 elmåleren omkring et dusin værdier hvert 10.-15. sekund, og jeg vil gerne installere 8 sådanne målere. Og der er også en hel masse parametre, der beregnes ud fra andre sensorer. At. alle disse værdier kan nemt puste databasen op med 100-200 MB dagligt. Om en uge vil systemet næppe kaste og dreje, og om en måned dør flashdrevet (i tilfælde af en typisk installation af hjemmeassistent på raspberry PI), og der kan ikke være tale om at gemme data i et helt år .
- Hvis du er heldig, kan din måler selv tælle forbruget. Du kan til enhver tid kontakte måleren og spørge, hvad klokken er den akkumulerede forbrugsværdi. Som regel giver alle elmålere, der har digitalt interface (RS232/RS485/Modbus/Zigbee), en sådan mulighed.
Værre, hvis enheden blot kan måle en øjeblikkelig parameter (f.eks. øjeblikkelig effekt eller strøm), eller blot generere pulser hver X watt-time eller liter. Så skal du tænke over, hvordan og med hvad du skal integrere det, og hvor du kan akkumulere værdi. Der er risiko for at gå glip af den næste rapport af en eller anden grund, og nøjagtigheden af systemet som helhed rejser spørgsmål. Du kan selvfølgelig overlade alt dette til et smart home-system som hjemmeassistent, men ingen har annulleret punktet om antallet af poster i databasen, og pollingsensorer mere end én gang i sekundet vil ikke fungere (en begrænsning af hjemmeassistentarkitektur).
tilgang 1
Lad os først se, hvilken hjemmeassistent der leveres ud af kassen. Måling af forbrug over en periode er en meget efterspurgt funktionalitet. Selvfølgelig blev det implementeret for længe siden som en specialiseret komponent - utility_meter.
Essensen af komponenten er, at den starter variablen current_accumulated_value inde og nulstiller den efter en specificeret periode (time/uge/måned). Komponenten selv overvåger den indkommende variabel (værdien af en slags sensor), abonnerer på ændringer i selve værdien - du får bare det færdige resultat. Denne ting er beskrevet i nogle få linjer i konfigurationsfilen
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 den aktuelle værdi af måleren i liter, som jeg får af mqtt. Designet skaber 2 nye sensorer water_cold_hour_um og water_cold_day_um, som akkumulerer time- og daglige aflæsninger og nulstiller dem efter en periode. Her er en graf over timebatteriet for en halv dag.
Den timelige og daglige diagramkode for lovelace-UI ser sådan ud:
- 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 tilgang i denne algoritme. Som jeg allerede har nævnt, for hver indgående værdi (den aktuelle måleraflæsning for hver næste liter), genereres 1kb af en post i databasen. Hver brugsmåler genererer også en ny værdi, som også lægges til basen. Hvis jeg vil indsamle time/daglig/ugentlig/månedlig aflæsning, ja, for flere vandstigere, og endda tilføje en pakke elmålere, vil det være en masse data. Nå, mere præcist er der ikke meget data, men da hjemmeassistenten skriver en masse unødvendig information til databasen, vil størrelsen af databasen vokse med stormskridt. Jeg er endda bange for at anslå størrelsen af basen for ugentlige og månedlige diagrammer.
Derudover løser selve brugsmåleren ikke problemet. Brugsmålerplotten er en monotont stigende funktion, der nulstilles til 0 hver time. Vi har også brug for en brugervenlig forbrugsplan, hvor mange liter der blev spist i perioden. Standardhistorie-graf-komponenten gør ikke dette, men den eksterne mini-graf-kort-komponent kan hjælpe os.
Dette er kortkoden til 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'Ud over standardindstillingerne som sensornavn, graftype, farve (jeg kunne ikke lide standardorange), er det vigtigt at bemærke 3 indstillinger her:
- group_by:hour - diagrammet vil blive genereret med kolonner justeret til begyndelsen af timen
- points_per_hour: 1 - en bar i timen
- Og vigtigst af alt, aggregate_func: max er at tage den maksimale værdi inden for hver time. Det er denne parameter, der gør savtandsdiagrammet til søjler.
Vær ikke opmærksom på rækken af kolonner til venstre - dette er standardadfærden for komponenten, hvis der ikke er nogen data. Men der var ingen data - jeg tændte kun for dataindsamling ved hjælp af brugsmåleren for et par timer siden bare for denne artikels skyld (jeg vil beskrive min nuværende tilgang lidt lavere).
På dette billede ville jeg vise, at nogle gange fungerer datavisningen endda, og søjlerne afspejler virkelig de korrekte værdier. Men det er ikke alt. Af en eller anden grund viser den fremhævede kolonne for perioden fra kl. 11 til kl. 12 19 liter, selvom vi på den tandede graf lidt højere for samme periode fra den samme sensor ser et forbrug på 62 liter. Enten en fejl eller hænder er skæve. Men jeg forstår stadig ikke, hvorfor dataene til højre gik i stykker - forbruget der var normalt, hvilket også er synligt fra den tandede graf.
Generelt lykkedes det mig ikke at opnå plausibiliteten af denne tilgang - grafen viser næsten altid en form for kætteri.
Lignende kode for dagsensoren.
- 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'
Bemærk venligst, at parameteren group_by er indstillet til interval, og parameteren points_per_hour styrer alt. Og dette er et andet problem med denne komponent - points_per_hour fungerer godt på diagrammer på en time eller mindre, men modbydeligt med større intervaller. Så for at få én kolonne på én dag, skulle jeg indtaste værdien 1/24=0.04166666. Jeg taler ikke om ugentlige og månedlige diagrammer.
tilgang 2
Mens jeg stadig fandt ud af hjemmeassistenten, stødte jeg på denne video:
Kammeraten indsamler forbrugsdata fra flere typer Xiaomi-stik. Hans opgave er lidt enklere - bare vis værdien af forbruget for i dag, i går og for måneden. Ingen diagrammer påkrævet.
Lad os se bort fra argumenterne om den manuelle integration af øjeblikkelige effektværdier - jeg skrev allerede om "nøjagtigheden" af denne tilgang ovenfor. Det er ikke klart, hvorfor han ikke har brugt de akkumulerede forbrugsværdier, som allerede er indsamlet af samme forretning. Efter min mening vil integration inde i jernstykket fungere bedre.
Fra videoen tager vi ideen om manuelt at tælle forbruget i en periode. For en mand er det kun værdierne for i dag og i går, der tages i betragtning, men vi vil gå videre og prøve at tegne en graf. Essensen af den foreslåede metode i mit tilfælde er som følger.
Vi vil oprette en variabel værdi_ved_begyndelsen_af_timen, hvori vi vil skrive de aktuelle tælleraflæsninger
Ifølge timeren ved slutningen af timen (eller i begyndelsen af den næste), beregner vi forskellen mellem den aktuelle aflæsning og den, der er gemt i begyndelsen af timen. Denne forskel vil være forbruget for den aktuelle time - vi gemmer værdien til sensoren, og i fremtiden vil vi bygge en graf baseret på denne værdi.
Du skal også "nulstille" variablen value_at_beginning_of_hour ved at skrive den aktuelle værdi af tælleren der.
Alt dette kan klares godt igennem ... ved hjælp af hjemmeassistenten selv.
Du bliver nødt til at skrive lidt mere kode end i den tidligere tilgang. Lad os starte med disse "variabler". Ud af boksen har vi ikke den "variable" enhed, men du kan bruge tjenesterne fra en mqtt-mægler. Vi sender værdier dertil med retain=true flag - dette gemmer værdien inde i mægleren, og den kan trækkes ud til enhver tid, også når hjemmeassistenten genstartes. Jeg lavede time- og dagligtællere på én 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: lAl magien sker i automatikken, som kører henholdsvis hver time og hver nat.
- 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: trueBegge automatiseringer gør 2 ting:
- Beregn værdien pr. interval som forskellen mellem start- og slutværdien
- Opdater basisværdien for det næste interval
Konstruktionen af grafer i dette tilfælde løses ved den sædvanlige historie-graf:
- 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_dayDet ser sådan ud:
I princippet er det allerede det, du har brug for. Fordelen ved denne metode er, at dataene genereres én gang pr. interval. De der. i alt 24 poster om dagen for timediagrammet.
Desværre løser dette stadig ikke det generelle problem med en voksende base. Hvis jeg vil have en månedlig forbrugsgraf, skal jeg opbevare data i mindst et år. Og da hjemmeassistent kun giver én indstilling for lagringsvarighed for hele databasen, betyder det, at ALLE data i systemet skal opbevares i et helt år. For eksempel forbruger jeg på et år 200 kubikmeter vand, hvilket betyder 200000 poster i databasen. Og hvis du tager andre sensorer i betragtning, bliver figuren generelt uanstændig.
tilgang 3
Heldigvis har smarte mennesker allerede løst dette problem ved at skrive InfluxDB-databasen. Denne database er specielt optimeret til lagring af tidsbaserede data og er ideel til lagring af værdier af forskellige sensorer. Systemet giver også et SQL-lignende forespørgselssprog, der giver dig mulighed for at udtrække værdier fra databasen og derefter aggregere dem på forskellige måder. Endelig kan forskellige data gemmes til forskellige tidspunkter. For eksempel kan hyppigt skiftende aflæsninger såsom temperatur eller luftfugtighed kun gemmes i et par uger, mens daglige aflæsninger af vandforbrug kan gemmes i et helt år.
Udover InfluxDB opfandt smarte mennesker også Grafana, et system til at tegne grafer fra data fra InfluxDB. Grafana kan tegne forskellige typer diagrammer, tilpasse dem i detaljer, og vigtigst af alt kan disse diagrammer "plugges" til lovelace-UI-hjemmeassistenten.
Bliv inspireret и . Artiklerne beskriver i detaljer processen med at installere og forbinde InfluxDB og Grafana til hjemmeassistent. Jeg vil fokusere på at løse mit specifikke problem.
Så lad os først og fremmest begynde at tilføje tællerværdien i influxDB. Et stykke af hjemmeassistentens konfiguration (i dette eksempel vil jeg have det sjovt ikke kun med koldt, men også med varmt vand):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldLad os deaktivere lagring af de samme data i hjemmeassistentens interne database for ikke at puste det op igen:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldLad os nu gå til InfluxDB-konsollen og opsætte vores database. Især skal du konfigurere, hvor længe visse data vil blive gemt. Dette er reguleret af den såkaldte. opbevaringspolitik - dette svarer til databaser inde i hoveddatabasen, hvor hver interne database har sine egne indstillinger. Som standard føjes alle data til opbevaringspolitikken kaldet autogen, disse data vil blive gemt i en uge. Jeg vil gerne have, at timedata gemmes i en måned, ugentlige data i et år og at månedlige data aldrig bliver slettet overhovedet. Vi vil skabe passende opbevaringspolitikker
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 1Nu er det vigtigste trick faktisk dataaggregering ved hjælp af kontinuerlig forespørgsel. Dette er en mekanisme, der automatisk starter en forespørgsel med bestemte intervaller, samler dataene for denne forespørgsel og tilføjer resultatet til en ny værdi. Lad os se på et eksempel (jeg skriver i en kolonne for læsbarhed, men i virkeligheden var jeg nødt til at indtaste denne kommando på én 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)
ENDDenne kommando:
- Opretter en kontinuerlig forespørgsel med navnet cq_water_cold_hourly i hjemmeassistentdatabasen
- Forespørgslen vil blive udført hver time (tid(1t))
- Forespørgslen vil trække alle data ud fra measurement'a homeassistant.autogen.l (liter), inklusive aflæsninger af koldt og varmt vand
- Aggregerede data vil blive grupperet efter entity_id, som vil skabe separate værdier for koldt og varmt vand.
- Da litertælleren er en monotont stigende sekvens inden for hver time, bliver du nødt til at tage den maksimale værdi, så aggregeringen vil blive udført af max(værdi)-funktionen
- Den nye værdi vil blive skrevet til homeassistant.month.water_meter_hour, hvor måned er navnet på opbevaringspolitikken med en opbevaringsperiode på en måned. Desuden vil data om koldt og varmt vand blive spredt i separate poster med det tilsvarende entity_id og værdien i værdifeltet
Om natten eller når ingen er hjemme, er der intet vandforbrug, og følgelig er der heller ingen nye rekorder i homeassistant.autogen.l. For at undgå manglende værdier i normale forespørgsler kan du bruge fill(previous). Dette vil tvinge InfluxDB til at bruge den seneste timeværdi.
Desværre har kontinuerlig forespørgsel en særegenhed: fill(forrige) tricket virker ikke, og poster oprettes simpelthen ikke. Desuden er dette en form for uoverkommeligt problem, som . Vi vil behandle dette problem senere, og lader udfylde(forrige) i kontinuerlig forespørgsel være der - det forstyrrer ikke.
Lad os tjekke, hvad der skete (du skal selvfølgelig 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
Bemærk, at værdierne i databasen er gemt i UTC, så denne liste adskiller sig med 3 timer - 7:10-værdierne i InfluxDB-outputtet matcher 2:5-værdierne i diagrammerne ovenfor. Bemærk også, at mellem XNUMX og XNUMX om morgenen er der ganske enkelt ingen poster - dette er selve træk ved kontinuerlig forespørgsel.
Som du kan se, er den aggregerede værdi også en monotont stigende sekvens, kun indtastningerne er sjældnere - en gang i timen. Men dette er ikke et problem - vi kan skrive en anden forespørgsel, der vil udtrække de korrekte data til diagrammet.
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 vil tyde:
- Fra homeassistant.month.water_meter_hour-databasen trækker vi data for entity_id='water_meter_cold' for den sidste dag (tid >= nu() -24 timer).
- Som jeg nævnte, kan der mangle nogle poster i sekvensen homeassistant.month.water_meter_hour. Vi vil genskabe disse data ved at køre forespørgslen med GROUP BY time(1t). Denne gang vil fill(previous) fungere korrekt og generere de manglende data (funktionen tager den forrige værdi)
- Det vigtigste i denne forespørgsel er differencefunktionen, som vil beregne forskellen mellem timemærkerne. I sig selv virker det ikke og kræver en aggregeringsfunktion. Lad dette være max() brugt før.
Udførelsesresultatet ser således ud
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 72Fra kl. 2 til kl. 5 (UTC) var der intet forbrug. Ikke desto mindre vil forespørgslen returnere den samme forbrugsværdi takket være fill(previous), og differencefunktionen vil trække denne værdi fra sig selv og få 0 ved output, som faktisk er påkrævet.
Det eneste tilbage at gøre er at bygge en graf. For at gøre dette skal du åbne Grafana, åbne et eksisterende (eller oprette et nyt) dashboard, oprette et nyt panel. Kortindstillingerne vil være som følger.
Jeg vil vise koldt- og varmtvandsdata på den samme graf. Anmodningen er nøjagtig den samme som jeg beskrev ovenfor.
Displayparametre indstilles som følger. For mig vil det være en graf med linjer (linjer), som går i trin (trapper). Stakparameteren vil blive forklaret nedenfor. Der er et par flere visningsmuligheder nedenfor, men de er ikke så interessante.
For at tilføje den resulterende graf til hjemmeassistent skal du:
- afslutte diagramredigeringstilstanden. Af en eller anden grund tilbydes de korrekte diagramdelingsindstillinger kun fra dashboard-siden
- Klik på trekanten ved siden af diagramnavnet, vælg del i menuen
- I det vindue, der åbnes, skal du gå til fanen Embed
- Fjern markeringen i det aktuelle tidsinterval - vi indstiller tidsintervallet via URL
- Vælg det ønskede emne. I mit tilfælde er det let
- Kopiér den resulterende URL til lovelace-UI-indstillingskortet
- 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"
Bemærk venligst, at tidsintervallet (sidste 2 dage) er indstillet her, og ikke i dashboard-indstillingerne.
Diagrammet ser sådan ud. Jeg har ikke brugt varmt vand de sidste 2 dage, så der er kun tegnet en graf over koldt vand.
Jeg har ikke selv besluttet, hvilket diagram jeg bedst kan lide, en trinlinje eller rigtige søjler. Derfor vil jeg blot give et eksempel på en daglig forbrugsplan, kun denne gang i stænger. Forespørgsler opbygges på samme måde som beskrevet ovenfor. Visningsmulighederne er:
Dette diagram ser således ud:
Altså om stak-parameteren. I denne graf er en koldtvandsstang tegnet oven på en varm bjælke. Den samlede højde svarer til det samlede forbrug af koldt og varmt vand for perioden.
Alle viste grafer er dynamiske. Du kan flytte musen hen over interessepunktet og se detaljerne og værdien på et bestemt punkt.
Desværre var det ikke uden et par flue i salven. På et søjlediagram (i modsætning til grafen med trinlinjer) er midten af søjlen ikke midt på dagen, men klokken 00:00. De der. venstre halvdel af søjlen er trukket i stedet for den foregående dag. Så søkortene for lørdag og søndag er tegnet lidt til venstre for den blålige zone. Indtil jeg fandt ud af, hvordan jeg vinder den.
Et andet problem er manglende evne til at arbejde korrekt med månedlige intervaller. Faktum er, at længden af timen/dagen/ugen er fast, men månedens længde er forskellig hver gang. InfluxDB kan kun arbejde med lige intervaller. Indtil videre har mine hjerner været nok til at sætte et fast interval på 30 dage. Ja, diagrammet vil flyde lidt i løbet af året, og søjlerne vil ikke nøjagtigt svare til månederne. Men da denne ting er interessant for mig bare som displaymåler, er jeg ok med dette.
Jeg ser mindst to løsninger:
- At score på månedlige diagrammer og begrænse dig til ugentlige. 52 ugentlige barer på et år ser ret godt ud
- Betragt selve det månedlige forbrug som metode nr. 2, og brug kun grafanaen til smukke grafer. Det er en ret præcis løsning. Du kan endda overlejre diagrammer for det seneste år til sammenligning - grafana kan gøre det.
Konklusion
Jeg ved ikke hvorfor, men jeg elsker den slags diagrammer. De viser, at livet er i fuld gang, og alt er under forandring. I går var der meget, i dag er der lidt, i morgen kommer der noget andet. Det er tilbage at arbejde med husholdningerne om emnet forbrug. Men selv med nuværende appetit er bare et stort og uforståeligt tal i regningen allerede ved at blive til et nogenlunde forståeligt billede af forbruget.
På trods af min næsten 20-årige karriere som programmør, kom jeg praktisk talt ikke ind i databaser. Derfor virkede det at installere en ekstern database som noget så abstrut og uforståeligt. Alting har ændret sig - det viste sig, at skruning af et passende værktøj sker med et par klik, og med et specialiseret værktøj bliver opgaven med at plotte lidt lettere.
I titlen nævnte jeg elforbruget. Desværre kan jeg i øjeblikket ikke levere nogen graf. Den ene SDM120 meter er død, og den anden er buggy, når den tilgås via Modbus. Dette påvirker dog ikke emnet for denne artikel på nogen måde - graferne vil blive bygget på samme måde som for vand.
I denne artikel har jeg givet de tilgange, som jeg selv har prøvet. Der er helt sikkert nogle andre måder at organisere indsamling og visualisering af data på, som jeg ikke kender til. Fortæl mig om det i kommentarerne, jeg vil være meget interesseret. Jeg vil være glad for konstruktiv kritik og nye ideer. Jeg håber, at ovenstående materiale også vil hjælpe nogen.
Kilde: www.habr.com