Zakaždým, keď dostanem platbu za elektrinu a vodu, som prekvapený - naozaj moja rodina toľko spotrebuje? Áno, v kúpeľni je vyhrievaná podlaha a bojler, ale stále nepália oheň. Zdá sa, že šetríme aj vodu (hoci sa tiež radi čvachtáme v kúpeľni). Už pred niekoľkými rokmi и do inteligentnej domácnosti, ale tam sa veci zasekli. Až teraz sme sa dostali k analýze spotreby, o ktorej je vlastne tento článok.
Nedávno som prešiel na Home Assistant ako môj inteligentný domáci systém. Jedným z dôvodov bola práve možnosť organizovať zber veľkého množstva dát s možnosťou pohodlnej konštrukcie rôznych typov grafov.
Informácie opísané v tomto článku nie sú nové, všetky tieto veci pod rôznymi omáčkami už boli popísané na internete. Ale každý článok zvyčajne popisuje iba jeden prístup alebo aspekt. Všetky tieto prístupy som musel porovnať a sám vybrať ten najvhodnejší. Článok stále neposkytuje komplexné informácie o zbere dát, ale je akýmsi zhrnutím toho, ako som to urobil. Takže konštruktívna kritika a návrhy na zlepšenie sú vítané.
Vyhlásenie o probléme
Takže cieľom dnešného cvičenia je získať krásne grafy spotreby vody a elektriny:
- Každú hodinu počas 2 dní
- Denne po dobu 2 týždňov
- (voliteľné) týždenne a mesačne
Sú s tým určité ťažkosti:
- Štandardné komponenty grafu sú zvyčajne dosť slabé. V najlepšom prípade môžete vytvoriť čiarový graf bod po bode.
Ak sa pozriete dostatočne pozorne, môžete nájsť komponenty tretích strán, ktoré rozširujú možnosti štandardného grafu. Pre domáceho asistenta je to v zásade dobrý a krásny komponent , ale je tiež trochu obmedzený:
- Je ťažké nastaviť parametre stĺpcového grafu vo veľkých intervaloch (šírka stĺpca sa nastavuje v zlomkoch hodiny, čo znamená, že intervaly dlhšie ako hodina budú nastavené v zlomkových číslach)
- Do jedného grafu nemôžete pridávať rôzne entity (napríklad teplotu a vlhkosť alebo kombinovať stĺpcový graf s čiarou)
- Nielenže domáci asistent v predvolenom nastavení používa najprimitívnejšiu databázu SQLite (a ja, domáci majster, som si s inštaláciou MySQL alebo Postgres neporadil), ale údaje sa neukladajú tým najoptimálnejším spôsobom. Takže napríklad vždy, keď zmeníte aj ten najmenší digitálny parameter parametra, do databázy sa zapíše obrovský súbor json s veľkosťou približne kilobajtu.
{"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}}}Mám pomerne veľa senzorov (snímače teploty v každej miestnosti, vodomery a elektromery) a niektoré generujú aj dosť veľa údajov. Napríklad samotný elektromer SDM220 generuje každých 10-15 sekúnd asi tucet hodnôt a ja by som chcel takýchto meračov namontovať asi 8. Je tam aj kopa parametrov, ktoré sa počítajú na základe iných senzorov. To. všetky tieto hodnoty môžu ľahko nafúknuť databázu o 100-200 MB denne. Za týždeň sa systém ledva pohne a o mesiac umrie flash disk (v prípade typickej inštalácie domáceho asistenta na Raspberry PI) a ukladanie dát na celý rok neprichádza do úvahy.
- Ak budete mať šťastie, váš merač dokáže počítať spotrebu sám. Kedykoľvek sa môžete obrátiť na merač a opýtať sa, kedy je naakumulovaná hodnota spotreby. Túto možnosť poskytujú spravidla všetky elektromery, ktoré majú digitálne rozhranie (RS232/RS485/Modbus/Zigbee).
Horšie je, ak zariadenie dokáže jednoducho merať nejaký okamžitý parameter (napríklad okamžitý výkon alebo prúd), alebo jednoducho generovať impulzy každých X watthodín alebo litrov. Potom sa treba zamyslieť nad tým, ako a s čím to integrovať a kde akumulovať hodnotu. Existuje riziko zmeškania nasledujúcej správy z akéhokoľvek dôvodu a presnosť systému ako celku vyvoláva otázky. Toto všetko môžete samozrejme zveriť systému inteligentnej domácnosti, akým je domáci asistent, no nikto nezrušil bod o počte záznamov v databáze a nebude možné voliť senzory viac ako raz za sekundu (a obmedzenie architektúry domáceho asistenta).
Prístup 1
Najprv sa pozrime, čo domáci asistent ponúka hneď po vybalení. Meranie spotreby za určité obdobie je veľmi žiadaná funkcia. Samozrejme, že bol implementovaný už dávno vo forme špecializovaného komponentu - utility_meter.
Podstatou komponentu je, že interne vytvára premennú current_accumulated_value a po stanovenom období (hodina/týždeň/mesiac) ju resetuje. Komponent sám monitoruje vstupnú premennú (hodnotu nejakého snímača), prihlasuje sa k zmenám hodnoty - práve dostanete hotový výsledok. Táto vec je popísaná v niekoľkých riadkoch v konfiguračnom súbore
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Tu sensor.water_meter_cold je aktuálna hodnota v litroch, ktorú dostávam od mqtt. Dizajn vytvára 2 nové senzory water_cold_hour_um a water_cold_day_um, ktoré akumulujú hodinové a denné hodnoty a po uplynutí doby ich vynulujú. Tu je graf hodinovej batérie za pol dňa.
Kód pre hodinové a denné grafy pre lovelace-UI vyzerá takto:
- 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
V skutočnosti problém tohto prístupu spočíva v tomto algoritme. Ako som už spomínal, pre každú vstupnú hodnotu (aktuálny stav merača pre každý ďalší liter) sa v databáze vygeneruje 1kb záznamov. Každý elektromer zároveň generuje novú hodnotu, ktorá sa tiež pripočítava k základu. Ak chcem zbierať hodinové/denné/týždenné/mesačné údaje a pre niekoľko stúpačiek vody a pridať balík elektromerov, bude to veľa údajov. Teda, presnejšie, dát nie je veľa, no keďže domáci asistent zapisuje do databázy kopu nepotrebných informácií, veľkosť databázy narastie míľovými krokmi. Veľkosť základne pre týždenné a mesačné grafy sa bojím čo i len odhadnúť.
Okrem toho samotný elektromer tento problém nerieši. Graf hodnôt generovaných elektromerom je monotónne rastúca funkcia, ktorá sa každú hodinu resetuje na 0. Potrebujeme pre používateľa zrozumiteľnú tabuľku spotreby, ktorá ukazuje, koľko litrov sa za dané obdobie spotrebovalo. Štandardný komponent histórie – graf to nedokáže, ale externý komponent mini grafickej karty nám môže pomôcť.
Toto je kód karty pre 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'Okrem štandardných nastavení, ako je názov senzora, typ grafu, farba (nepáčila sa mi štandardná oranžová), je dôležité poznamenať 3 nastavenia:
- group_by:hour — graf sa vygeneruje s pruhmi zarovnanými na začiatok hodiny
- points_per_hour: 1 – jeden pruh za každú hodinu
- A čo je najdôležitejšie, agregácia_funkcie: max - získajte maximálnu hodnotu v rámci každej hodiny. Práve tento parameter mení pílový graf na pruhy
Nevenujte pozornosť riadku stĺpcov naľavo - toto je štandardné správanie komponentu, ak neexistujú žiadne údaje. Neexistovali však žiadne údaje - len pred pár hodinami som zapol zber údajov z meračov energie len kvôli tomuto článku (súčasný prístup popíšem nižšie).
Na tomto obrázku som chcel ukázať, že niekedy funguje zobrazenie údajov a stĺpce skutočne odrážajú správne hodnoty. To však nie je všetko. Z nejakého dôvodu vybraný stĺpec pre obdobie od 11 do 12 hodín zobrazuje 19 litrov, aj keď na zubatom grafe o niečo vyššie za rovnaké obdobie z rovnakého snímača vidíme spotrebu 62 litrov. Buď je tam chyba, alebo sú ruky krivé. Stále však nerozumiem, prečo sa údaje vpravo odlomili - spotreba tam bola normálna, čo je viditeľné aj zo zubatého grafu.
Vo všeobecnosti som nebol schopný dosiahnuť vierohodnosť tohto prístupu - graf takmer vždy ukazuje nejaký druh herézy.
Podobný kód pre denný snímač.
- 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'
Upozorňujeme, že parameter group_by je nastavený na interval a parameter points_per_hour riadi všetko. A v tom je ďalší problém s týmto komponentom - points_per_hour funguje dobre na grafoch s hodinou alebo menej, ale vo väčších intervaloch je nanič. Aby som teda dostal jeden stĺpec za jeden deň, musel som zadať hodnotu 1/24=0.04166666. O týždenných a mesačných grafoch ani nehovorím.
Prístup 2
Zatiaľ čo som stále pochopil domáceho asistenta, narazil som na toto video:
Kamarát zbiera údaje o spotrebe z niekoľkých typov zásuviek Xiaomi. Jeho úloha je o niečo jednoduchšia – jednoducho zobraziť hodnotu spotreby za dnes, včera a za mesiac. Nevyžadujú sa žiadne plány.
Nechajme bokom diskusie o manuálnej integrácii hodnôt okamžitého výkonu – o „presnosti“ tohto prístupu som už písal vyššie. Nie je jasné, prečo nepoužil naakumulované hodnoty spotreby, ktoré už inkasuje tá istá predajňa. Podľa mňa bude lepšie fungovať integrácia vo vnútri hardvéru.
Z videa preberieme myšlienku manuálneho počítania spotreby za určité obdobie. Ten chlap počíta iba hodnoty za dnes a včera, ale pôjdeme ďalej a pokúsime sa nakresliť graf. Podstata navrhovanej metódy v mojom prípade je nasledovná.
Vytvorme si premennú value_at_the_beginning_of_hour, do ktorej budeme zaznamenávať aktuálne stavy meračov
Pomocou časovača vypočítame na konci hodiny (alebo na začiatku nasledujúcej) rozdiel medzi aktuálnou hodnotou a hodnotou uloženou na začiatku hodiny. Tento rozdiel bude spotreba za aktuálnu hodinu - hodnotu uložíme do snímača a v budúcnosti na základe tejto hodnoty zostavíme graf.
Musíte tiež „resetovať“ premennú value_at_beginning_of_hour tak, že tam napíšete aktuálnu hodnotu počítadla.
To všetko je možné vykonať prostredníctvom samotného domáceho asistenta.
Budete musieť napísať trochu viac kódu ako v predchádzajúcom prístupe. Najprv vytvorte tie isté „premenné“. Po vybalení nemáme „variabilnú“ entitu, ale môžeme využiť služby brokera mqtt. Budeme tam posielať hodnoty s príznakom keep=true – tým sa uloží hodnota vo vnútri brokera a dá sa odtiaľ kedykoľvek stiahnuť, aj keď sa domáci asistent reštartuje. Robil som hodinové a denné počítadlá naraz.
- 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: lVšetky kúzla sa odohrávajú v automatizácii, ktorá beží každú hodinu a každú noc.
- 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: trueObe automatizácie vykonávajú 2 akcie:
- Vypočítajte hodnotu pre interval ako rozdiel medzi počiatočnou a koncovou hodnotou
- Aktualizujte základnú hodnotu pre nasledujúci interval
Konštrukcia grafov je v tomto prípade riešená obvyklým grafom histórie:
- 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_dayVyzerá to takto:
V zásade je to už potrebné. Výhodou tejto metódy je, že údaje sa generujú raz za interval. Tie. iba 24 záznamov za deň pre hodinový graf.
Bohužiaľ to stále nerieši všeobecný problém rastúcej základne. Ak chcem mesačný graf spotreby, budem musieť uchovávať dáta aspoň rok. A keďže domáci asistent poskytuje iba jedno nastavenie dĺžky uloženia pre celú databázu, znamená to, že VŠETKY dáta v systéme budú musieť byť uložené celý rok. Napríklad za rok spotrebujem 200 kubických metrov vody, čo znamená, že to znamená 200000 XNUMX záznamov v databáze. A ak vezmete do úvahy ďalšie senzory, potom sa toto číslo stane všeobecne neslušným.
Prístup 3
Našťastie šikovní ľudia už tento problém vyriešili napísaním databázy InfluxDB. Táto databáza je špeciálne optimalizovaná na ukladanie údajov založených na čase a je ideálna na ukladanie hodnôt rôznych senzorov. Systém tiež poskytuje dotazovací jazyk podobný SQL, ktorý vám umožňuje extrahovať hodnoty z databázy a potom ich rôznymi spôsobmi agregovať. Nakoniec, rôzne údaje môžu byť uložené na rôzne časy. Napríklad často sa meniace namerané hodnoty, ako je teplota alebo vlhkosť, môžu byť uložené len niekoľko týždňov, zatiaľ čo denné údaje o spotrebe vody môžu byť uložené na celý rok.
Okrem InfluxDB vynašli chytrí ľudia aj Grafana, systém na kreslenie grafov na základe údajov z InfluxDB. Grafana dokáže kresliť rôzne typy grafov, detailne ich prispôsobovať, a čo je najdôležitejšie, tieto grafy je možné „zastrčiť“ do domáceho asistenta lovelace-UI.
Dostať inšpiráciu и . Články podrobne popisujú proces inštalácie a pripojenia InfluxDB a Grafana k domácemu asistentovi. Zameriam sa na riešenie môjho konkrétneho problému.
Takže najprv začnime pridávať hodnotu počítadla v influxDB. Kúsok konfigurácie domáceho asistenta (v tomto príklade sa budem baviť nielen so studenou, ale aj horúcou vodou):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldZakážme ukladanie rovnakých údajov do internej databázy domáceho asistenta, aby sme ich znova nenafúkli:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldPoďme teraz do konzoly InfluxDB a nakonfigurujeme našu databázu. Predovšetkým je potrebné nakonfigurovať, ako dlho budú určité údaje uložené. Toto upravuje tzv. politika uchovávania – je podobná databázam v rámci hlavnej databázy, pričom každá interná databáza má svoje vlastné nastavenia. V predvolenom nastavení sú všetky údaje uložené v zásade uchovávania nazývanej autogén; tieto údaje budú uložené týždeň. Chcel by som, aby sa hodinové údaje uchovávali mesiac, týždenné údaje rok a mesačné údaje sa nikdy nevymazali. Vytvorme vhodnú politiku uchovávania
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 1Teraz je v skutočnosti hlavným trikom agregácia údajov pomocou nepretržitého dopytovania. Toto je mechanizmus, ktorý automaticky spúšťa dotaz v určených intervaloch, agreguje údaje pre tento dotaz a pridáva výsledok do novej hodnoty. Pozrime sa na príklad (píšem do stĺpca kvôli čitateľnosti, ale v skutočnosti som musel zadať tento príkaz v jednom riadku)
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)
ENDTento príkaz:
- V databáze domáceho asistenta vytvorí súvislý dotaz s názvom cq_water_cold_hourly
- Požiadavka sa vykoná každú hodinu (čas (1h))
- Požiadavka zoškrabe všetky údaje z merania' homeassistant.autogen.l (litre), vrátane hodnôt studenej a teplej vody
- Agregované údaje budú zoskupené podľa entity_id, čo nám poskytne samostatné hodnoty pre studenú a teplú vodu
- Keďže počítadlo litrov je monotónne rastúca sekvencia v rámci každej hodiny, bude potrebné vziať maximálnu hodnotu, takže agregáciu vykoná funkcia max(hodnota)
- Nová hodnota sa zapíše do homeassistant.month.water_meter_hour, kde mesiac je názov politiky uchovávania s dobou uchovávania jeden mesiac. Údaje o studenej a teplej vode budú navyše rozdelené do samostatných záznamov so zodpovedajúcim identifikátorom entity a hodnotou v poli hodnoty
V noci alebo keď nikto nie je doma, nedochádza k spotrebe vody, a preto nie sú v homeassistant.autogen.l žiadne nové položky. Aby ste sa vyhli chýbajúcim hodnotám v bežných dopytoch, môžete použiť výplň (predchádzajúca). To prinúti InfluxDB použiť hodnotu poslednej hodiny.
Žiaľ, súvislé dopytovanie má jednu zvláštnosť: vyplňovací (predchádzajúci) trik nefunguje a záznamy sa jednoducho nevytvárajú. Navyše ide o nejaký neprekonateľný problém . Týmto problémom sa budeme zaoberať neskôr, ale nech je fill(previous) v súvislom dotaze - neprekáža.
Pozrime sa, čo sa stalo (samozrejme, musíte počkať niekoľko hodín):
> 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
Všimnite si, že hodnoty v databáze sú uložené v UTC, takže tento zoznam sa líši o 3 hodiny - hodnoty o 7:10 vo výstupe InfluxDB zodpovedajú hodnotám o 2:5 v grafoch vyššie. Všimnite si tiež, že medzi XNUMX. a XNUMX. hodinou ráno jednoducho neexistujú žiadne záznamy – ide o rovnakú funkciu nepretržitého dopytovania.
Ako vidíte, agregovaná hodnota je tiež monotónne rastúca sekvencia, iba záznamy sa vyskytujú menej často - raz za hodinu. Ale to nie je problém - môžeme napísať ďalší dotaz, ktorý načíta správne údaje pre graf.
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)rozlúštim:
- Z databázy homeassistant.month.water_meter_hour vytiahneme údaje pre entity_id='water_meter_cold' za posledný deň (čas >= now() -24h).
- Ako som už spomenul, niektoré položky môžu chýbať v sekvencii homeassistant.month.water_meter_hour. Tieto údaje vygenerujeme spustením dotazu s časom GROUP BY (1h). Táto časová výplň (predchádzajúca) bude fungovať podľa očakávania a vygeneruje chýbajúce údaje (funkcia bude mať predchádzajúcu hodnotu)
- Najdôležitejšia vec v tejto požiadavke je rozdielová funkcia, ktorá vypočíta rozdiel medzi hodinovými známkami. Nepracuje sám osebe a vyžaduje agregačnú funkciu. Nech je to max() použitá predtým.
Výsledok vykonania vyzerá takto
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 72Od 2. do 5. hodiny rannej (UTC) nebola spotreba. Napriek tomu dotaz vráti rovnakú hodnotu spotreby vďaka fill(previous) a rozdielová funkcia túto hodnotu od seba odpočíta a výstupom bude 0, čo je presne to, čo sa požaduje.
Zostáva len zostaviť graf. Ak to chcete urobiť, otvorte Grafana, otvorte nejaký existujúci (alebo vytvorte nový) informačný panel a vytvorte nový panel. Nastavenia grafu budú takéto.
Údaje o studenej a teplej vode zobrazím na rovnakom grafe. Požiadavka je presne taká, ako som opísal vyššie.
Parametre zobrazenia sa nastavujú nasledovne. Pre mňa to bude graf s čiarami, ktorý ide v krokoch (schodoch). Parameter Stack vysvetlím nižšie. Nižšie je niekoľko ďalších možností zobrazenia, ale nie sú také zaujímavé.
Ak chcete pridať výsledný graf do domáceho asistenta, musíte:
- ukončiť režim úpravy grafu. Z nejakého dôvodu sú správne nastavenia zdieľania grafu ponúkané iba zo stránky dashboardu
- Kliknite na trojuholník vedľa názvu grafu a z ponuky vyberte možnosť zdieľať
- V okne, ktoré sa otvorí, prejdite na kartu vložiť
- Odškrtnite aktuálny časový rozsah – časový rozsah nastavíme cez URL
- Vyberte požadovanú tému. V mojom prípade je to svetlo
- Skopírujte výslednú adresu URL na kartu nastavení lovelace-UI
- 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"
Upozorňujeme, že časový rozsah (posledné 2 dni) sa nastavuje tu a nie v nastaveniach hlavného panela.
Graf vyzerá takto. Posledné 2 dni som nepoužil horúcu vodu, takže je nakreslený iba graf studenej vody.
Stále som sa sám nerozhodol, ktorý graf sa mi páči viac, čiarový krok alebo skutočné pruhy. Preto uvediem jednoducho príklad grafu dennej spotreby, len tentoraz v pruhoch. Dotazy sú zostavené podobne ako tie, ktoré sú opísané vyššie. Možnosti zobrazenia sú:
Tento graf vyzerá takto:
Takže o parametri Stack. V tomto grafe je stĺpec studenej vody nakreslený nad stĺpcom horúcej vody. Celková výška zodpovedá celkovej spotrebe studenej a teplej vody za dané obdobie.
Všetky zobrazené grafy sú dynamické. Môžete umiestniť kurzor myši na bod záujmu a zobraziť podrobnosti a hodnotu v konkrétnom bode.
Žiaľ, pár mušiek tam bolo. Na stĺpcovom grafe (na rozdiel od grafu s krokovými čiarami) nie je stred stĺpca uprostred dňa, ale o 00:00. Tie. ľavá polovica stĺpca je nakreslená namiesto predchádzajúceho dňa. Takže grafy pre sobotu a nedeľu sú nakreslené mierne naľavo od modrastej zóny. Kým som neprišiel na to, ako to poraziť.
Ďalším problémom je neschopnosť správne pracovať v mesačných intervaloch. Faktom je, že dĺžka hodiny/dňa/týždňa je pevná, no dĺžka mesiaca je zakaždým iná. InfluxDB môže pracovať iba v rovnakých intervaloch. Doteraz môj mozog stačil na to, aby som si nastavil pevný interval 30 dní. Áno, graf bude počas roka trochu plávať a stĺpce nebudú presne zodpovedať mesiacom. Ale keďže ma táto vec zaujíma jednoducho ako merač displeja, som s tým v poriadku.
Vidím minimálne dve riešenia:
- Vzdajte sa mesačných grafov a obmedzte sa na týždenné. 52 týždenných barov za rok vyzerá celkom dobre
- Samotnú mesačnú spotrebu považujte za metódu č.2 a grafana používajte len na krásne grafy. Bude to celkom presné riešenie. Pre porovnanie si môžete dokonca prekryť grafy za uplynulý rok – to dokáže aj grafana.
Záver
Neviem prečo, ale som posadnutý týmito druhmi grafov. Ukazujú, že život je v plnom prúde a všetko sa mení. Včera toho bolo veľa, dnes málo, zajtra to bude niečo iné. Ostáva už len pracovať s členmi domácnosti na téme spotreby. Ale aj pri súčasných chúťkach sa už len veľká a nepochopiteľná cifra na výplatnom lístku mení na celkom zrozumiteľný obraz spotreby.
Napriek takmer 20-ročnej kariére programátora som nemal prakticky žiadny kontakt s databázami. Inštalácia externej databázy sa preto javila ako niečo také nezrozumiteľné a nepochopiteľné. Všetko zmenil — Ukázalo sa, že pripojenie vhodného nástroja sa vykonáva niekoľkými kliknutiami a so špecializovaným nástrojom je úloha vykresľovania grafov o niečo jednoduchšia.
V nadpise som spomenul spotrebu el. Bohužiaľ, momentálne nemôžem poskytnúť žiadne grafy. Jeden merač SDM120 mi zomrel a druhý je chybný pri prístupe cez Modbus. To však nijako neovplyvňuje tému tohto článku – grafy budú konštruované rovnako ako pre vodu.
V tomto článku som predstavil prístupy, ktoré som sám vyskúšal. Určite existujú nejaké iné spôsoby, ako organizovať zber údajov a vizualizáciu, o ktorých neviem. Povedzte mi o tom v komentároch, veľmi ma to zaujíma. Budem rád za konštruktívnu kritiku a nové nápady. Dúfam, že aj prezentovaný materiál niekomu pomôže.
Zdroj: hab.com
