Elke keer as ek ’n betaling vir elektrisiteit en water ontvang, is ek verbaas – verbruik my gesin werklik so baie? Wel, ja, die badkamer het 'n verhitte vloer en 'n ketel, maar hulle brand nie heeltyd vure nie. Dit lyk of ons ook water bespaar (alhoewel ons ook graag in die badkamer rondploeter). 'n Paar jaar gelede het ek al и na 'n slim huis, maar dit is waar dinge vasgeval het. Ons het nou eers begin om verbruik te ontleed, dit is waaroor hierdie artikel eintlik gaan.
Ek het onlangs oorgeskakel na Home Assistant as my slimhuisstelsel. Een van die redes was juis die geleentheid om die versameling van 'n groot hoeveelheid data te organiseer met die vermoë om verskeie tipes grafieke gerieflik te konstrueer.
Die inligting wat in hierdie artikel beskryf word, is nie nuut nie; al hierdie dinge onder verskillende souse is reeds op die internet beskryf. Maar elke artikel beskryf gewoonlik net een benadering of aspek. Ek moes al hierdie benaderings vergelyk en self die geskikste een kies. Die artikel verskaf steeds nie omvattende inligting oor data-insameling nie, maar is 'n soort opsomming van hoe ek dit gedoen het. Opbouende kritiek en voorstelle vir verbetering is dus welkom.
Probleemstelling
Die doel van vandag se oefening is dus om pragtige grafieke van water- en elektrisiteitsverbruik te kry:
- Uurliks vir 2 dae
- Daagliks vir 2 weke
- (opsioneel) weekliks en maandeliks
Daar is 'n paar probleme hiermee:
- Standaard grafiek komponente is gewoonlik redelik swak. Op sy beste kan jy punt vir punt 'n lyngrafiek bou.
As jy hard genoeg kyk, kan jy derdeparty-komponente vind wat die vermoëns van die standaardkaart uitbrei. Vir 'n huisassistent is dit in beginsel 'n goeie en pragtige komponent , maar dit is ook ietwat beperk:
- Dit is moeilik om die parameters van 'n staafgrafiek oor groot intervalle te stel (die breedte van die staaf word in breuke van 'n uur gestel, wat beteken dat intervalle langer as 'n uur in breukgetalle gestel sal word)
- Jy kan nie verskillende entiteite by een grafiek voeg nie (byvoorbeeld temperatuur en humiditeit, of 'n staafgrafiek met 'n lyn kombineer)
- Nie net gebruik huisassistent by verstek die mees primitiewe SQLite-databasis nie (en ek, 'n nutsman, kon nie die installering van MySQL of Postgres hanteer nie), maar die data word nie op die mees optimale manier gestoor nie. So, byvoorbeeld, elke keer as jy selfs die kleinste digitale parameter van 'n parameter verander, word 'n groot json van ongeveer 'n kilogreep groot na die databasis geskryf
{"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}}}Ek het nogal baie sensors (temperatuursensors in elke kamer, water- en elektrisiteitsmeters), en sommige genereer ook nogal baie data. Byvoorbeeld, die SDM220 elektrisiteitsmeter alleen genereer ongeveer 'n dosyn waardes elke 10-15 sekondes, en ek wil graag ongeveer 8 sulke meters installeer. Daar is ook 'n hele klomp parameters wat op grond van ander sensors bereken word. Daardie. al hierdie waardes kan die databasis maklik met 100-200 MB daagliks opblaas. Oor 'n week sal die stelsel skaars beweeg, en oor 'n maand sal die flash drive doodgaan (in die geval van 'n tipiese huisassistent-installasie op 'n Raspberry PI), en die stoor van data vir 'n hele jaar is nie ter sprake nie.
- As jy gelukkig is, kan jou meter self verbruik tel. Jy kan enige tyd na die meter draai en vra hoe laat die opgehoopte verbruikswaarde is. As 'n reël bied alle elektrisiteitsmeters wat 'n digitale koppelvlak (RS232/RS485/Modbus/Zigbee) het hierdie geleentheid.
Dit is erger as die toestel bloot een of ander oombliklike parameter kan meet (byvoorbeeld, oombliklike krag of stroom), of bloot elke X watt-uur of liter pulse kan genereer. Dan moet jy dink oor hoe en waarmee om dit te integreer en waar om waarde op te bou. Daar is 'n risiko om die volgende verslag om enige rede te mis, en die akkuraatheid van die stelsel as geheel laat vrae ontstaan. U kan dit natuurlik aan 'n slimhuisstelsel soos 'n huisassistent toevertrou, maar niemand het die punt oor die aantal rekords in die databasis gekanselleer nie, en dit sal nie moontlik wees om sensors meer as een keer per sekonde te poll nie (a beperking van die huisassistent-argitektuur).
Benadering 1
Kom ons kyk eers wat huisassistent uit die boks verskaf. Die meting van verbruik oor 'n tydperk is 'n uiters gesogte funksionaliteit. Natuurlik is dit lank gelede geïmplementeer in die vorm van 'n gespesialiseerde komponent - utility_meter.
Die essensie van die komponent is dat dit intern 'n veranderlike stroom_opgehoopte_waarde skep en dit na 'n bepaalde tydperk (uur/week/maand) terugstel. Die komponent self monitor die insetveranderlike (die waarde van een of ander sensor), onderskryf homself by veranderinge in die waarde - jy kry net die finale resultaat. Hierdie ding word in net 'n paar reëls in die konfigurasielêer beskryf
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Hier is sensor.water_meter_cold die huidige meterwaarde in liter wat ek ontvang deur mqtt. Die ontwerp skep 2 nuwe sensors water_cold_hour_um en water_cold_day_um, wat uurlikse en daaglikse lesings ophoop en dit na nul terugstel nadat die tydperk verstryk het. Hier is 'n grafiek van die uurlikse battery vir 'n halwe dag.
Die kode vir uurlikse en daaglikse kaarte vir lovelace-UI lyk soos volg:
- 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
Eintlik lê die probleem met hierdie benadering in hierdie algoritme. Soos ek reeds genoem het, word vir elke insetwaarde (huidige meterlesing vir elke volgende liter) 1kb rekords in die databasis gegenereer. Elke nutsmeter genereer ook 'n nuwe waarde, wat ook by die basis gevoeg word. As ek uurlikse/daaglikse/weeklikse/maandelikse lesings, en vir verskeie waterstygers, wil insamel en 'n pak elektriese meters wil byvoeg, sal dit baie data wees. Wel, meer presies, daar is nie baie data nie, maar aangesien die huisassistent 'n klomp onnodige inligting na die databasis skryf, sal die grootte van die databasis met rasse skrede groei. Ek is bang om selfs die grootte van die basis vir weeklikse en maandelikse kaarte te skat.
Daarbenewens los die nutsmeter op sigself nie die probleem op nie. Die grafiek van die waardes wat deur die nutsmeter geproduseer word, is 'n eentonig toenemende funksie wat elke uur na 0 teruggestel word. Ons benodig 'n verbruikskaart wat vir die gebruiker verstaanbaar is, wat wys hoeveel liter gedurende die tydperk verbruik is. Die standaard geskiedenis-grafiek komponent kan dit nie doen nie, maar die mini-grafiek-kaart eksterne komponent kan ons help.
Dit is die kaartkode vir 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'Benewens standaardinstellings soos sensornaam, grafiektipe, kleur (ek het nie van die standaard oranje gehou nie), is dit belangrik om op 3 instellings te let:
- group_by:hour — die grafiek sal gegenereer word met die stawe in lyn met die begin van die uur
- punte_per_uur: 1 - een maat vir elke uur
- En die belangrikste, aggregate_func: max - neem die maksimum waarde binne elke uur. Dit is hierdie parameter wat die saagtandgrafiek in stawe verander
Moenie aandag gee aan die ry kolomme aan die linkerkant nie - dit is die standaardgedrag van die komponent as daar geen data is nie. Maar daar was geen data nie - ek het net 'n paar uur gelede data-insameling van nutsmeters aangeskakel net ter wille van hierdie artikel (ek sal my huidige benadering 'n bietjie laer beskryf).
In hierdie prent wou ek wys dat die datavertoning soms selfs werk en dat die stawe eintlik die korrekte waardes weerspieël. Maar dit is nie al nie. Om een of ander rede vertoon die geselekteerde kolom vir die tydperk van 11 tot 12 vm. 19 liter, hoewel ons op die tandgrafiek 'n bietjie hoër vir dieselfde tydperk vanaf dieselfde sensor sien ons verbruik van 62 liter. Of daar is 'n gogga of die hande is krom. Maar ek verstaan steeds nie hoekom die data aan die regterkant afgebreek het nie - verbruik daar was normaal, wat ook sigbaar is op die tandgrafiek.
Oor die algemeen kon ek nie die aanneemlikheid van hierdie benadering bereik nie – die grafiek toon amper altyd een of ander dwaalleer.
Soortgelyke kode vir die dagsensor.
- 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'
Neem asseblief kennis dat die group_by parameter op interval gestel is, en die points_per_hour parameter reël alles. En daarin lê nog 'n probleem met hierdie komponent - points_per_hour werk goed op kaarte van 'n uur of minder, maar dit suig op groter intervalle. So om een kolom in een dag te kry, moes ek die waarde 1/24=0.04166666 invoer. Ek praat nie eers van weeklikse en maandelikse kaarte nie.
Benadering 2
Terwyl ek nog steeds die huisassistent verstaan, het ek op hierdie video afgekom:
'n Vriend versamel verbruiksdata van verskeie tipes Xiaomi-sokke. Sy taak is 'n bietjie eenvoudiger - vertoon bloot die verbruikswaarde vir vandag, gister en vir die maand. Geen skedules word vereis nie.
Kom ons laat besprekings oor handmatige integrasie van oombliklike kragwaardes tersyde - ek het reeds hierbo geskryf oor die "akkuraatheid" van hierdie benadering. Dit is nie duidelik hoekom hy nie die opgehoopte verbruikswaardes, wat reeds deur dieselfde afsetpunt ingesamel word, gebruik het nie. Na my mening sal integrasie binne die hardeware beter werk.
Uit die video sal ons die idee neem om verbruik oor 'n tydperk handmatig te tel. Die ou tel net die waardes vir vandag en gister, maar ons sal verder gaan en probeer om 'n grafiek te teken. Die kern van die voorgestelde metode in my geval is soos volg.
Kom ons skep 'n veranderlike waarde_aan_die_begin_van_uur, waarin ons die huidige meterlesings sal aanteken
Deur die timer te gebruik, bereken ons aan die einde van die uur (of aan die begin van die volgende) die verskil tussen die huidige lesing en die een wat aan die begin van die uur gestoor is. Hierdie verskil sal die verbruik vir die huidige uur wees - ons sal die waarde in die sensor stoor, en in die toekoms sal ons 'n grafiek bou gebaseer op hierdie waarde.
Jy moet ook die waarde_by_begin_of_hour veranderlike "terugstel" deur die huidige tellerwaarde daar te skryf.
Dit alles kan deur die huisassistent self gedoen word.
Jy sal 'n bietjie meer kode moet skryf as in die vorige benadering. Laat ons eers dieselfde "veranderlikes" skep. Uit die boks het ons nie die "veranderlike" entiteit nie, maar ons kan die dienste van die mqtt-makelaar gebruik. Ons sal waardes daarheen stuur met die retain=true-vlag - dit sal die waarde in die makelaar stoor, en dit kan enige tyd daaruit getrek word, selfs wanneer die huisassistent herlaai word. Ek het op een slag uurlikse en daaglikse tellers gemaak.
- 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 die magie gebeur in die outomatisering, wat onderskeidelik elke uur en elke aand loop.
- 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: trueBeide outomatisering voer 2 aksies uit:
- Bereken die waarde vir 'n interval as die verskil tussen die begin- en eindwaardes
- Dateer die basiswaarde op vir die volgende interval
Die konstruksie van grafieke in hierdie geval word opgelos deur die gewone geskiedenis-grafiek:
- 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_dayDit lyk so:
In beginsel is dit reeds wat nodig is. Die voordeel van hierdie metode is dat die data een keer per interval gegenereer word. Dié. slegs 24 rekords per dag vir 'n uurlikse grafiek.
Ongelukkig los dit steeds nie die algemene probleem van 'n groeiende basis op nie. As ek 'n maandelikse verbruiksgrafiek wil hê, sal ek data vir ten minste 'n jaar moet stoor. En aangesien huisassistent slegs een stoortydperkinstelling vir die hele databasis verskaf, beteken dit dat ALLE data in die stelsel vir 'n hele jaar gestoor moet word. Byvoorbeeld, in 'n jaar verbruik ek 200 kubieke meter water, wat beteken dat dit 200000 XNUMX inskrywings in die databasis beteken. En as jy ander sensors in ag neem, word die figuur oor die algemeen onwelvoeglik.
Benadering 3
Gelukkig het slim mense reeds hierdie probleem opgelos deur die InfluxDB-databasis te skryf. Hierdie databasis is spesiaal geoptimaliseer vir die stoor van tydgebaseerde data en is ideaal vir die stoor van waardes van verskillende sensors. Die stelsel bied ook 'n SQL-agtige navraagtaal waarmee u waardes uit die databasis kan onttrek en dan op verskillende maniere saamvoeg. Laastens kan verskillende data vir verskillende tye gestoor word. Byvoorbeeld, lesings wat gereeld verander, soos temperatuur of humiditeit, kan vir net 'n paar weke gestoor word, terwyl daaglikse waterverbruiklesings vir 'n hele jaar gestoor kan word.
Benewens InfluxDB, het slim mense ook Grafana uitgevind, 'n stelsel om grafieke te teken gebaseer op data van InfluxDB. Grafana kan verskillende tipes grafieke teken, dit in detail aanpas, en, bowenal, hierdie grafieke kan op die lovelace-UI-tuisassistent “geprop” word.
Word inspireer и . Die artikels beskryf in detail die proses om InfluxDB en Grafana te installeer en aan die huisassistent te koppel. Ek sal daarop fokus om my spesifieke probleem op te los.
Dus, eerstens, laat ons begin om die tellerwaarde in influxDB by te voeg. 'n Stukkie van die huisassistent-konfigurasie (in hierdie voorbeeld sal ek pret hê met nie net koue nie, maar ook warm water):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldKom ons deaktiveer die stoor van dieselfde data in die interne huisassistent-databasis om dit nie weer op te blaas nie:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldKom ons gaan nou na die InfluxDB-konsole en stel ons databasis in. U moet veral opstel hoe lank sekere data gestoor sal word. Dit word gereguleer deur die sg. behoudbeleid - dit is soortgelyk aan databasisse binne 'n hoofdatabasis, met elke interne databasis wat sy eie instellings het. By verstek word alle data in 'n retensiebeleid genaamd outogen gestoor; hierdie data sal vir 'n week gestoor word. Ek wil graag hê dat die uurlikse data vir 'n maand gehou moet word, die weeklikse data vir 'n jaar gehou word, en die maandelikse data moet nooit uitgevee word nie. Kom ons skep die toepaslike retensiebeleid
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 1Trouens, die belangrikste truuk is data-aggregasie deur deurlopende navraag te gebruik. Dit is 'n meganisme wat outomaties 'n navraag met gespesifiseerde intervalle laat loop, die data vir hierdie navraag saamvoeg en die resultaat by 'n nuwe waarde voeg. Kom ons kyk na 'n voorbeeld (ek skryf in 'n kolom vir leesbaarheid, maar in werklikheid moes ek hierdie opdrag in een reël invoer)
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)
ENDHierdie opdrag:
- Skep 'n deurlopende navraag genaamd cq_water_cold_hourly in die tuisassistent-databasis
- Die versoek sal elke uur uitgevoer word (tyd(1h))
- Die versoek sal alle data van die meting se huisassistent.autogen.l (liters) krap, insluitend koue en warmwaterlesings
- Die saamgevoegde data sal volgens entity_id gegroepeer word, wat ons aparte waardes vir koue en warm water sal gee
- Aangesien die literteller 'n monotoon toenemende volgorde binne elke uur is, sal dit nodig wees om die maksimum waarde te neem, dus sal aggregasie uitgevoer word deur die funksie max(waarde)
- Die nuwe waarde sal na huisassistent.month.water_meter_hour geskryf word, waar maand die naam van die retensiepolis met 'n retensietydperk van een maand is. Verder sal data oor koue en warm water in afsonderlike rekords versprei word met die ooreenstemmende entity_id en waarde in die waardeveld
Snags of wanneer niemand tuis is nie, is daar geen waterverbruik nie, en daarom is daar geen nuwe inskrywings in homeassistant.autogen.l nie. Om ontbrekende waardes in gereelde navrae te vermy, kan u vul (vorige) gebruik. Dit sal InfluxDB dwing om die waarde van die laaste uur te gebruik.
Ongelukkig het deurlopende navraag 'n eienaardigheid: die vul (vorige) truuk werk nie en rekords word eenvoudig nie geskep nie. Verder, dit is 'n soort van onoorkomelike probleem wat . Ons sal hierdie probleem later hanteer, maar laat vul(vorige) in die deurlopende navraag wees - dit meng nie in nie.
Kom ons kyk wat gebeur het (natuurlik moet jy 'n paar uur wag):
> 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
Let daarop dat die waardes in die databasis in UTC gestoor word, so hierdie lys verskil met 3 uur - die 7am-waardes in die InfluxDB-uitset stem ooreen met die 10am-waardes in die grafieke hierbo. Let ook daarop dat daar tussen 2 en 5 vm. eenvoudig geen rekords is nie - dit is dieselfde kenmerk van deurlopende navraag.
Soos u kan sien, is die saamgestelde waarde ook 'n eentonig toenemende volgorde, slegs inskrywings kom minder gereeld voor - een keer per uur. Maar dit is nie 'n probleem nie - ons kan nog 'n navraag skryf wat die korrekte data vir die grafiek sal ophaal.
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)Ek sal ontsyfer:
- Van die homeassistant.month.water_meter_hour databasis sal ons data onttrek vir entity_id='water_meter_cold' vir die laaste dag (tyd >= nou() -24h).
- Soos ek reeds genoem het, kan sommige inskrywings ontbreek in die huisassistent.month.water_meter_hour volgorde. Ons sal hierdie data herskep deur 'n navraag met GROUP BY time(1h) uit te voer. Hierdie tydvul (vorige) sal werk soos verwag, wat die ontbrekende data genereer (die funksie sal die vorige waarde neem)
- Die belangrikste ding in hierdie versoek is die verskilfunksie, wat die verskil tussen uurpunte sal bereken. Dit werk nie op sy eie nie en vereis 'n samevoegingsfunksie. Laat dit die max() wees wat voorheen gebruik is.
Die uitvoeringsresultaat lyk so
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 72Van 2 tot 5 vm (UTC) was daar geen verbruik nie. Nietemin sal die navraag dieselfde verbruikswaarde terugstuur danksy vul (vorige), en die verskilfunksie sal hierdie waarde van homself aftrek en die uitset sal 0 wees, wat presies is wat vereis word.
Al wat oorbly is om 'n grafiek te bou. Om dit te doen, maak Grafana oop, maak 'n bestaande (of skep 'n nuwe) dashboard oop en skep 'n nuwe paneel. Die grafiekinstellings sal so wees.
Ek sal koue- en warmwaterdata op dieselfde grafiek vertoon. Die versoek is presies dieselfde as wat ek hierbo beskryf het.
Vertoonparameters word soos volg gestel. Vir my sal dit 'n grafiek met lyne wees, wat in stappe (trappe) gaan. Ek sal die Stack parameter hieronder verduidelik. Daar is nog 'n paar vertoonopsies hieronder, maar dit is nie so interessant nie.
Om die resulterende grafiek by die huisassistent te voeg, moet jy:
- verlaat die grafiekredigeringsmodus. Om een of ander rede word die korrekte grafiekdelinginstellings slegs vanaf die kontroleskermbladsy aangebied
- Klik op die driehoek langs die grafieknaam en kies deel uit die kieslys
- Gaan na die insluit-oortjie in die venster wat oopmaak
- Ontmerk die huidige tydreeks - ons sal die tydreeks via URL stel
- Kies die vereiste onderwerp. In my geval is dit lig
- Kopieer die resulterende URL na die lovelace-UI-instellingskaart
- 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"
Neem asseblief kennis dat die tydsbestek (laaste 2 dae) hier gestel word, en nie in die kontroleskerminstellings nie.
Die grafiek lyk so. Ek het die afgelope 2 dae nie warm water gebruik nie, so slegs die kouewatergrafiek word geteken.
Ek het nog nie self besluit van watter grafiek ek beter hou nie, 'n lynstap of regte stawe. Daarom gee ek bloot 'n voorbeeld van 'n daaglikse verbruikskaart, net hierdie keer in stawe. Navrae word soortgelyk aan dié wat hierbo beskryf is saamgestel. Die vertoonopsies is:
Hierdie grafiek lyk so:
So oor die Stack parameter. In hierdie grafiek word 'n kolom koue water bo-op 'n kolom warm water geteken. Die totale hoogte stem ooreen met die totale verbruik van koue en warm water vir die tydperk.
Alle grafieke wat gewys word, is dinamies. Jy kan jou muis oor die punt van belang hou en die besonderhede en waarde op 'n spesifieke punt sien.
Ongelukkig was daar 'n paar vlieg in die salf. Op 'n staafgrafiek (anders as 'n grafiek met staplyne), is die middel van die staaf nie in die middel van die dag nie, maar om 00:00. Dié. die linker helfte van die kolom word in die plek van die vorige dag geteken. Dus is die grafieke vir Saterdag en Sondag effens aan die linkerkant van die blouerige sone geteken. Totdat ek uitgevind het hoe om dit te verslaan.
Nog 'n probleem is die onvermoë om met maandelikse tussenposes behoorlik te werk. Die feit is dat die lengte van die uur/dag/week vas is, maar die lengte van die maand verskil elke keer. InfluxDB kan slegs met gelyke intervalle werk. Tot dusver was my brein genoeg om 'n vaste interval van 30 dae te stel. Ja, die grafiek sal 'n bietjie deur die jaar sweef en die stawe sal nie presies ooreenstem met die maande nie. Maar aangesien ek in hierdie ding belangstel bloot as 'n vertoonmeter, is ek ok daarmee.
Ek sien ten minste twee oplossings:
- Gee op met maandelikse kaarte en beperk jouself tot weeklikse. 52 weeklikse kroeë vir die jaar lyk redelik goed
- Beskou maandelikse verbruik self as metode nr. 2, en gebruik grafana slegs vir pragtige grafieke. Dit sal nogal 'n akkurate oplossing wees. Jy kan selfs grafieke vir die afgelope jaar oorlê vir vergelyking - grafana kan dit ook doen.
Gevolgtrekking
Ek weet nie hoekom nie, maar ek is versot op hierdie soort grafieke. Hulle wys dat die lewe in volle swang is en alles verander. Gister was daar baie, vandag is daar min, môre sal dit iets anders wees. Al wat oorbly, is om saam met huishoudelike lede oor die onderwerp van verbruik te werk. Maar selfs met huidige aptyt, verander net 'n groot en onverstaanbare syfer op die betaalstrokie reeds in 'n redelik verstaanbare prentjie van verbruik.
Ten spyte van my byna 20 jaar lange loopbaan as programmeerder, het ek feitlik geen kontak met databasisse gehad nie. Daarom het die installering van 'n eksterne databasis soos iets so onduidelik en onverstaanbaar gelyk. Het alles verander - dit het geblyk dat die heg van 'n geskikte instrument met 'n paar klik gedoen word, en met 'n gespesialiseerde hulpmiddel word die taak om kaarte te teken 'n bietjie makliker.
In die titel het ek elektrisiteitsverbruik genoem. Ongelukkig kan ek op die oomblik geen grafieke verskaf nie. Een SDM120 meter het vir my gesterf, en die ander is foutief wanneer dit via Modbus verkry word. Dit raak egter geensins die onderwerp van hierdie artikel nie – die grafieke sal op dieselfde manier as vir water saamgestel word.
In hierdie artikel het ek die benaderings aangebied wat ek self probeer het. Daar is sekerlik ander maniere om data-insameling en visualisering te organiseer waarvan ek nie weet nie. Vertel my daarvan in die kommentaar, ek sal baie belangstel. Ek sal bly wees vir konstruktiewe kritiek en nuwe idees. Ek hoop die materiaal wat aangebied word, sal ook iemand help.
Bron: will.com