Elke kear as ik in betelling foar elektrisiteit en wetter krij, freegje ik my ôf - verbruikt myn famylje echt safolle? No ja, der is in ferwaarme flier en in boiler yn 'e badkeamer, mar se wurkje net altyd as brânwacht. Wy lykje ek wetter te besparjen (hoewol't wy ek graach yn 'e badkeamer spatte). In pear jier lyn ik al и nei in tûk hûs, mar dit is wêr't dingen hingje. De hannen hawwe de analyze fan konsumpsje pas no berikt, wat, yn feite, is wêr't dit artikel oer giet.
Ik skeakele koartlyn oer nei Home Assistant as myn smart home systeem. Ien fan 'e redenen wie gewoan de mooglikheid om de kolleksje fan in grutte hoemannichte gegevens te organisearjen mei de mooglikheid fan handige konstruksje fan ferskate soarten grafiken.
De ynformaasje beskreaun yn dit artikel is net nij, al dizze dingen ûnder ferskate sauzen binne al beskreaun op it ynternet. Mar elk artikel, as regel, beskriuwt mar ien oanpak of aspekt. Ik moast al dizze oanpak fergelykje en sels de meast geskikte kieze. It artikel jout noch gjin útputtende ynformaasje oer gegevenssammeling, mar is in soarte fan gearfetting fan hoe't ik it die. Opbouwende krityk en suggestjes foar ferbettering binne dus wolkom.
Probleemintwurding
Dat, it doel fan 'e oefening fan hjoed is om prachtige grafiken te krijen fan wetter- en elektrisiteitsferbrûk:
- Oeren foar 2 dagen
- Deistich foar 2 wiken
- (opsjoneel) wyklikse en moanlikse
D'r binne wat swierrichheden yn dit:
- De komponinten fan 'e standertkaart binne neigeraden frij min te wêzen. Op it bêste kinne jo in linegrafyk bouwe troch punten.
As jo goed sykje, kinne jo komponinten fan tredden fine dy't de mooglikheden fan 'e standertkaart útwreidzje. Foar home assistint, yn prinsipe, in goede en moaie komponint , mar it is ek wat beheind:
- It is lestich om de parameters fan 'e staafdiagram yn grutte yntervallen yn te stellen (de breedte fan' e balke wurdt ynsteld yn fraksjes fan in oere, wat betsjut dat yntervallen langer dan in oere wurde ynsteld yn fraksjenûmers)
- Jo kinne gjin ferskate entiteiten tafoegje oan ien grafyk (bygelyks temperatuer en fochtigens, of kombinearje in staafgrafyk mei in line)
- Net allinich brûkt de thúsassistent standert de meast primitive SQLite-database (en ik, de handyman, behearske de ynstallaasje fan MySQL of Postgres net), de gegevens wurde net op 'e meast optimale manier opslein. Sa, bygelyks, mei elke feroaring fan elk sels de lytste digitale parameter fan in parameter, wurdt in enoarme json oer in kilobyte yn grutte skreaun nei de databank
{"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}}}Ik haw nochal in pear sensoren (temperatuer sensoren yn elke keamer, wetter en elektrisiteit meter), en guon generearje ek nochal in soad gegevens. Bygelyks, allinich de elektrisiteitsmeter SDM220 genereart elke 10-15 sekonden sawat in tsiental wearden, en ik soe 8 sokke meters wolle ynstallearje. En d'r is ek in hiele bosk parameters dy't wurde berekkene op basis fan oare sensoren. Dat. al dizze wearden kinne de database maklik mei 100-200 MB deistich opblaze. Yn in wike sil it systeem amper draaie, en yn in moanne sil de flash drive stjerre (yn it gefal fan in typyske ynstallaasje fan hûsassistint op raspberry PI), en der kin gjin sprake wêze fan it bewarjen fan gegevens foar in heule jier .
- As jo gelok hawwe, kin jo meter sels konsumpsje telle. Jo kinne op elk momint kontakt opnimme mei de meter en freegje hoe let de opboude konsumpsjewearde is. As regel jouwe alle elektrisiteitsmeters dy't in digitale ynterface hawwe (RS232 / RS485 / Modbus / Zigbee) sa'n kâns.
Slimmer, as it apparaat kin gewoan mjitte wat instantane parameter (bygelyks, instantaneous macht of stroom), of gewoan generearje pulses elke X watt-oeren of liter. Dan moatte jo tinke oer hoe en mei wat te yntegrearjen en wêr te sammeljen wearde. D'r is in risiko dat it folgjende rapport om hokker reden dan ek mist, en de krektens fan it systeem as gehiel ropt fragen op. Jo kinne dit alles fansels tafertrouwe oan in tûk thússysteem lykas thúsassistent, mar gjinien hat it punt oer it oantal yngongen yn 'e databank annulearre, en pollingsensors sille mear dan ien kear in sekonde net wurkje (in beheining fan 'e home assistint arsjitektuer).
Oanpak 1
Litte wy earst sjen hokker thúsassistent út 'e doaze wurdt levere. It mjitten fan konsumpsje oer in perioade is in tige frege funksjonaliteit. Fansels is it in lange tiid lyn ymplementearre as in spesjalisearre komponint - utility_meter.
De essinsje fan de komponint is dat it begjint de current_accumulated_value fariabele binnen en reset it nei in oantsjutte perioade (oere / wike / moanne). De komponint sels kontrolearret de ynkommende fariabele (de wearde fan in soarte fan sensor), abonnearret op feroaringen yn 'e wearde sels - jo krije gewoan it klear resultaat. Dit ding wurdt beskreaun yn mar in pear rigels yn it konfiguraasjetriem
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Hjir sensor.water_meter_cold is de hjoeddeiske wearde fan de meter yn liters dat ik krij troch mqtt. It ûntwerp makket 2 nije sensors water_cold_hour_um en water_cold_day_um, dy't oere en deistige lêzingen sammelje, en se nei in perioade weromsette nei nul. Hjir is in grafyk fan 'e oere batterij foar in heale dei.
De oere en deistige diagramkoade foar lovelace-UI sjocht der sa út:
- 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
Eins leit yn dit algoritme it probleem fan dizze oanpak. Lykas ik al neamde, foar elke ynkommende wearde (de aktuele meterlêzing foar elke folgjende liter), wurdt 1kb fan in rekord yn 'e databank generearre. Elke nutsmeter genereart ek in nije wearde, dy't ek tafoege wurdt oan 'e basis. As ik oeren / deistich / wykliks / moanlikse lêzings sammelje wol, ja, foar ferskate wetterriders, en sels in pak elektryske meters tafoegje, sil dit in protte gegevens wêze. No, krekter, d'r is net folle gegevens, mar om't de thúsassistint in boskje oerstallige ynformaasje skriuwt yn 'e databank, sil de grutte fan' e databank mei sprongen en grinzen groeie. Ik bin sels bang om de grutte fan 'e basis te skatten foar wyklikse en moanlikse charts.
Derneist lost de nutsmeter sels it probleem net op. De nutmeterplot is in monotoanysk tanimmende funksje dy't elk oere weromset nei 0. Wy hawwe ek in brûkerfreonlik konsumpsjeskema nedich, hoefolle liters yn de perioade iten binne. De standert skiednis-grafyk komponint docht dit net, mar de eksterne mini-grafyk-kaart komponint kin helpe ús.
Dit is de kaartkoade foar 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'Neist de standertynstellingen lykas de sensornamme, grafyktype, kleur (ik hâldde net fan de standert oranje), is it wichtich om hjir 3 ynstellings op te merken:
- group_by:hour - de grafyk sil oanmakke wurde mei kolommen ôfstimd op it begjin fan 'e oere
- points_per_hour: 1 - ien bar per oere
- En it wichtichste, aggregate_func: max is om de maksimale wearde binnen elk oere te nimmen. It is dizze parameter dy't de sawtooth-kaart yn bars feroaret.
Net betelje omtinken oan de rige kolommen oan de linkerkant - dit is it standert gedrach fan de komponint as der gjin gegevens. Mar d'r wiene gjin gegevens - ik haw it sammeljen fan gegevens allinich in pear oeren lyn ynskeakele mei de utility meter, krekt om 'e wille fan dit artikel (ik sil myn hjoeddeistige oanpak in bytsje leger beskriuwe).
Op dizze foto woe ik sjen litte dat soms de gegevenswerjefte sels wurket, en de balken reflektearje echt de juste wearden. Mar dat is net alles. Om ien of oare reden toant de markearre kolom foar de perioade fan 11 oant 12 oere 19 liter, hoewol op 'e toskegrafyk in bytsje heger foar deselde perioade fan deselde sensor sjogge wy konsumpsje fan 62 liter. Of in bug of hannen binne krom. Mar ik begryp noch net wêrom't de gegevens oan 'e rjochter ôfbrekke - it konsumpsje dêr wie normaal, dat is ek sichtber út' e toskegrafyk.
Yn 't algemien slagge it my net om de plausibiliteit fan dizze oanpak te berikken - de grafyk lit hast altyd in soarte fan ketterij sjen.
Similar koade foar de dei sensor.
- 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'
Tink derom dat de parameter group_by is ynsteld op ynterval, en de parameter points_per_hour regelt alles. En dit is in oar probleem mei dizze komponint - points_per_hour wurket goed op charts fan in oere of minder, mar disgustingly op gruttere yntervallen. Dus om ien kolom yn ien dei te krijen, moast ik de wearde 1/24=0.04166666 ynfiere. Ik haw it net oer wyklikse en moanlikse charts.
Oanpak 2
Wylst ik de thúsassistent noch útfine, kaam ik dizze fideo tsjin:
De kameraad sammelt konsumpsjegegevens fan ferskate soarten Xiaomi-sockets. Syn taak is in bytsje ienfâldiger - gewoan werjaan de wearde fan konsumpsje foar hjoed, juster en foar de moanne. Gjin charts nedich.
Litte wy de arguminten oer de manuele yntegraasje fan instantane krêftwearden ferlitte - ik skreau al oer de "krektens" fan dizze oanpak hjirboppe. It is net dúdlik wêrom't hy net brûkte de opboude konsumpsjewearden, dy't al sammele wurde troch deselde outlet. Neffens my sil yntegraasje binnen it stik izer better wurkje.
Fan 'e fideo sille wy it idee nimme om konsumpsje foar in perioade manueel te tellen. Foar in man wurde allinich de wearden foar hjoed en foar juster beskôge, mar wy sille fierder gean en besykje in grafyk te tekenjen. De essinsje fan 'e foarstelde metoade yn myn gefal is as folget.
Wy sille in fariabele wearde_by_the_beginning_of_hour meitsje, wêryn wy de hjoeddeistige tellerlêzingen sille skriuwe
Neffens de timer oan 'e ein fan' e oere (of oan it begjin fan 'e folgjende), berekkenje wy it ferskil tusken de aktuele lêzing en de opslein oan it begjin fan 'e oere. Dit ferskil sil it konsumpsje wêze foar it aktuele oere - wy sille de wearde op 'e sensor bewarje, en yn' e takomst sille wy in grafyk bouwe op basis fan dizze wearde.
Jo moatte ek de fariabele value_at_beginning_of_hour "weromsette" troch dêr de aktuele wearde fan 'e teller te skriuwen.
Dit alles kin troch goed ... troch middel fan de húsassistint sels.
Jo sille in bytsje mear koade moatte skriuwe dan yn 'e foarige oanpak. Litte wy begjinne mei dizze "fariabelen". Ut it fak, wy hawwe net de "fariabele" entiteit, mar jo kinne gebrûk meitsje fan de tsjinsten fan in mqtt makelder. Wy sille dêr wearden stjoere mei de retain=true flagge - dit sil de wearde yn 'e makelder bewarje, en it kin op elk momint útlutsen wurde, sels as de thúsassistent opnij is opstart. Ik makke oere en deistige tellers yn ien kear.
- 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: lAlle magy bart yn 'e automatisearring, dy't respektivelik elk oere en elke nacht rint.
- 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 automatisaasjes dogge 2 dingen:
- Berekkenje de wearde per ynterval as it ferskil tusken de begjin- en einwearde
- Update de basiswearde foar it folgjende ynterval
De konstruksje fan grafiken yn dit gefal wurdt oplost troch de gewoane skiednisgrafyk:
- 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_dayIt sjocht der sa út:
Yn prinsipe is dit al wat jo nedich hawwe. It foardiel fan dizze metoade is dat de gegevens ien kear per ynterval generearre wurde. Dy. yn totaal 24 yngongen per dei foar de oere chart.
Spitigernôch lost dit it algemiene probleem fan in groeiende basis noch net op. As ik in moanlikse konsumpsjegrafyk wol, sil ik gegevens op syn minst in jier moatte opslaan. En om't thúsassistint mar ien ynstelling foar opslachduur leveret foar de folsleine databank, betsjut dit dat ALLE gegevens yn it systeem in heule jier opslein wurde moatte. Bygelyks, yn in jier ferbrûk ik 200 kubike meter wetter, dat betsjut 200000 ynstjoerings yn 'e databank. En as jo rekken hâlde mei oare sensoren, dan wurdt it figuer algemien ûnfatsoenlik.
Oanpak 3
Gelokkich hawwe tûke minsken dit probleem al oplost troch de InfluxDB-database te skriuwen. Dizze databank is spesjaal optimalisearre foar it opslaan fan tiid-basearre gegevens en is ideaal foar it opslaan fan wearden fan ferskate sensors. It systeem leveret ek in SQL-like query-taal wêrmei jo wearden út 'e databank kinne ekstrahearje en se dan op ferskate manieren aggregearje. Uteinlik kinne ferskate gegevens wurde opslein foar ferskate tiden. Sa kinne faak feroarjende lêzings lykas temperatuer of fochtigens mar in pear wiken wurde opslein, wylst deistige lêzingen fan wetterferbrûk in hiel jier opslein wurde kinne.
Neist InfluxDB hawwe tûke minsken ek Grafana útfûn, in systeem foar it tekenjen fan grafiken út gegevens fan InfluxDB. Grafana kin ferskate soarten charts tekenje, se yn detail oanpasse, en, it wichtichste, kinne dizze charts wurde "plugged" yn 'e lovelace-UI-hûsassistint.
wurde ynspirearre и . De artikels beskriuwe yn detail it proses fan it ynstallearjen en ferbinen fan InfluxDB en Grafana nei hûsassistent. Ik sil rjochtsje op it oplossen fan myn spesifike probleem.
Dat, lit ús earst begjinne mei it tafoegjen fan de tellerwearde yn influxDB. In stik fan 'e konfiguraasje fan' e thúsassistent (yn dit foarbyld sil ik wille hawwe net allinich mei kâld, mar ek mei hyt wetter):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldLitte wy it bewarjen fan deselde gegevens yn 'e ynterne database fan' e thúsassistent útsette om it net nochris op te blazen:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldLitte wy no nei de InfluxDB-konsole gean en ús database ynstelle. Benammen moatte jo ynstelle hoe lang bepaalde gegevens wurde opslein. Dit wurdt regele troch de saneamde. retinsjebelied - dit is gelyk oan databases binnen de haaddatabase, mei elke ynterne database mei eigen ynstellings. Standert wurde alle gegevens tafoege oan it behâldbelied neamd autogen, dizze gegevens wurde in wike opslein. Ik wol graach dat oerengegevens foar in moanne wurde opslein, wyklikse gegevens foar in jier, en moanlikse gegevens hielendal net wiske wurde. Wy sille passend retinsjebelied meitsje
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 1No, yn feite, de wichtichste trúk is gegevens aggregaasje mei help fan trochgeande query. Dit is in meganisme dat automatysk in query op spesifisearre yntervallen lanseart, de gegevens foar dizze query aggregearret en it resultaat taheakket oan in nije wearde. Litte wy nei in foarbyld sjen (ik skriuw yn in kolom foar lêsberens, mar yn werklikheid moast ik dit kommando op ien rigel ynfiere)
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)
ENDDit kommando:
- Makket in trochgeande query mei de namme cq_water_cold_hourly yn 'e homeassistant-database
- De query sil elk oere wurde útfierd (tiid (1h))
- De query sil lûke út alle gegevens út measurement'a homeassistant.autogen.l (liters), ynklusyf lêzingen fan kâld en hyt wetter
- Aggregearre gegevens sille wurde groepeare troch entity_id, dy't aparte wearden sille meitsje foar kâld en hyt wetter.
- Sûnt de teller fan liters in monotoanysk tanimmende folchoarder binnen elk oere is, moatte jo de maksimale wearde nimme, sadat de aggregaasje wurdt útfierd troch de max (wearde) funksje
- De nije wearde wurdt skreaun nei homeassistant.month.water_meter_hour dêr't moanne de namme is fan it behâldbelied mei in behâldperioade fan ien moanne. Boppedat sille gegevens oer kâld en hyt wetter wurde ferspraat yn aparte records mei de oerienkommende entity_id en de wearde yn it weardefjild
Nachts of as der gjinien thús is, is der gjin wetterferbrûk, en dus ek gjin nije rekords yn homeassistant.autogen.l. Om ûntbrekkende wearden yn normale queries te foarkommen, kinne jo fill (foarige) brûke. Dit sil InfluxDB twinge om de wearde fan 'e ôfrûne oere te brûken.
Spitigernôch hat trochgeande query in eigenaardichheid: de fill (foarige) trúk wurket net en records wurde gewoan net oanmakke. Boppedat, dit is in soarte fan insurmountable probleem, dy't . Wy sille dit probleem letter omgean, en lit folje (foarige) yn trochgeande query der wêze - it bemoeit net.
Litte wy kontrolearje wat der bard is (fansels moatte jo in pear oeren wachtsje):
> 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
Tink derom dat de wearden yn 'e databank wurde opslein yn UTC, dus dizze list ferskilt mei 3 oeren - de 7am-wearden yn' e InfluxDB-útfier oerienkomme mei de 10am-wearden yn 'e boppesteande charts. Tink derom ek dat tusken 2 en 5 moarns d'r gewoan gjin records binne - dit is it eigenskip fan trochgeande query.
Sa't jo sjen kinne, is de aggregearre wearde ek in monotoanysk tanimmende folchoarder, allinich de yngongen binne minder faak - ien kear yn 'e oere. Mar dit is gjin probleem - wy kinne in oare fraach skriuwe dy't de juste gegevens foar it diagram ekstrahearje.
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)Ik sil ûntsiferje:
- Ut de homeassistant.month.water_meter_hour databank, wy sille lûke gegevens foar entity_id = 'water_meter_cold' foar de lêste dei (tiid>= no () -24h).
- Lykas ik neamde, kinne guon yngongen ûntbrekke yn 'e folchoarder fan homeassistant.month.water_meter_hour. Wy sille dizze gegevens opnij generearje troch de query út te fieren mei GROUP BY tiid (1h). Dizze kear sil fill (foarige) goed wurkje, de ûntbrekkende gegevens generearje (de funksje sil de foarige wearde nimme)
- It wichtichste ding yn dizze query is de ferskilfunksje, dy't it ferskil tusken de oeremarken sil berekkenje. Op himsels wurket it net en fereasket in aggregaasjefunksje. Lit dit de max () wêze dy't earder brûkt waard.
It útfieringsresultaat sjocht der sa út
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 72Fan 2 oere oant 5 oere (UTC) wie der gjin konsumpsje. Dochs sil de query deselde konsumpsjewearde werombringe tank oan fill (foarige), en de ferskilfunksje sil dizze wearde fan himsels ôflûke en 0 krije by de útfier, dy't eins fereaske is.
It iennichste wat te dwaan is om in grafyk te bouwen. Om dit te dwaan, iepenje Grafana, iepenje wat besteande (of meitsje in nij) dashboard, meitsje in nij paniel. De kaartynstellingen sille as folgjend wêze.
Ik sil werjaan kâld en hyt wetter gegevens op deselde grafyk. It fersyk is krekt itselde as ik hjirboppe beskreaun.
Display parameters wurde ynsteld as folget. Foar my sil it in grafyk wêze mei rigels (linen), dy't yn stappen (treppen) giet. De Stack parameter sil hjirûnder wurde útlein. D'r binne in pear mear werjefteopsjes hjirûnder, mar se binne net sa ynteressant.
Om de resultearjende grafyk ta te foegjen oan thúsassistent, moatte jo:
- gean de kaartbewurkingsmodus út. Om ien of oare reden wurde de juste ynstellings foar dielen fan diagrammen allinich oanbean fan 'e dashboardside
- Klikje op it trijehoek njonken de kaartnamme, selektearje diel út it menu
- Gean yn it finster dat iepent nei it ljepblêd ynbêde
- Uncheck aktuele tiidberik - wy sille it tiidberik ynstelle fia URL
- Selektearje it fereaske ûnderwerp. Yn myn gefal is it ljocht
- Kopiearje de resultearjende URL nei de lovelace-UI-ynstellingskaart
- 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"
Tink derom dat it tiidbereik (lêste 2 dagen) hjir is ynsteld, en net yn 'e dashboardynstellingen.
De grafyk sjocht der sa út. Ik haw de lêste 2 dagen gjin hyt wetter brûkt, dus wurdt allinich in grafyk fan kâld wetter tekene.
Ik haw net foar mysels besletten hokker diagram ik it bêste fyn, in stapline of echte balken. Dêrom sil ik gewoan in foarbyld jaan fan in deistige konsumpsjeskema, allinich dizze kear yn bars. Queries wurde boud op deselde wize as hjirboppe beskreaun. De werjefte opsjes binne:
Dit diagram sjocht der sa út:
Dus, oer de Stack parameter. Yn dizze grafyk wurdt in kâld wetterbalke tekene boppe op in waarme bar. De totale hichte komt oerien mei it totale konsumpsje fan kâld en hyt wetter foar de perioade.
Alle werjûn grafiken binne dynamysk. Jo kinne de mûs oer it punt fan belang ferpleatse en de details en wearde sjen op in bepaald punt.
Spitigernôch wie it net sûnder in pear fly yn 'e salve. Op in staafdiagram (yn tsjinstelling ta de grafyk mei staplinen), is it midden fan 'e balke net yn' e midden fan 'e dei, mar om 00:00. Dy. de lofterhelte fan de balke wurdt tekene yn plak fan de foarige deis. Sa wurde de charts foar sneon en snein in bytsje links fan 'e blauwich sône tekene. Oant ik derachter hoe te winnen it.
In oar probleem is it ûnfermogen om goed te wurkjen mei moanlikse yntervallen. It feit is dat de lingte fan 'e oere / dei / wike fêst is, mar de lingte fan' e moanne is elke kear oars. InfluxDB kin allinich wurkje mei gelikense yntervallen. Oant no hawwe myn harsens genôch west om in fêst ynterval fan 30 dagen yn te stellen. Ja, de kaart sil it jier in bytsje driuwe en de balken sille net krekt oerienkomme mei de moannen. Mar sûnt dit ding is nijsgjirrich foar my krekt as in display meter, Ik bin ok mei dit.
Ik sjoch op syn minst twa oplossingen:
- Om te skoaren op moanlikse charts en josels te beheinen ta wyklikse. 52 wyklikse bars yn in jier sjogge der aardich goed út
- Beskôgje de moanlikse konsumpsje sels as metoade No.. 2, en brûk de grafana allinnich foar moaie grafiken. It is in frij krekte oplossing. Jo kinne sels charts oerlaapje foar it ôfrûne jier foar fergeliking - grafana kin dat dwaan.
konklúzje
Ik wit net wêrom, mar ik hâld fan dit soarte charts. Se litte sjen dat it libben yn folle gong is en alles feroaret. Juster wie der in protte, hjoed is der min, moarn komt der wat oars. It bliuwt om mei húshâldens te wurkjen oer it ûnderwerp fan konsumpsje. Mar sels mei de hjoeddeiske appetit, krekt in grut en ûnbegryplik figuer yn 'e rekken is al feroaret yn in frij begryplik byld fan konsumpsje.
Nettsjinsteande myn hast 20-jierrige karriêre as programmeur, krús ik praktysk net mei databases. Dêrom, it ynstallearjen fan in eksterne databank like wat sa abstrus en ûnbegryplik. Alles is feroare - it die bliken dat it skroefjen fan in gaadlik ark wurdt dien yn in pear mûsklikken, en mei in spesjalisearre ark wurdt de taak fan plotting in bytsje makliker.
Yn de titel neamde ik elektrisiteitsferbrûk. Spitigernôch kin ik op it stuit gjin grafyk leverje. Ien SDM120 meter is dea, en de oare is buggy as tagong fia Modbus. Dit hat lykwols gjin ynfloed op it ûnderwerp fan dit artikel - de grafiken wurde op deselde manier boud as foar wetter.
Yn dit artikel haw ik dy oanpak jûn dy't ik sels haw besocht. D'r binne wis wat oare manieren om de kolleksje en fisualisaasje fan gegevens te organisearjen wêrfan ik net wit. Fertel my deroer yn 'e kommentaren, ik sil tige ynteressearre wêze. Ik sil bliid wêze mei konstruktive krityk en nije ideeën. Ik hoopje dat it boppesteande materiaal ek immen sil helpe.
Boarne: www.habr.com