Vsakič, ko dobim račun za elektriko in vodo, se sprašujem — ali moja družina res toliko porablja? No ja, v kopalnici imamo talno ogrevanje in bojler, a vendarle ne delujeta nenehno. Tudi vodo nekako varčujemo (čeprav se radi plaskamo v kadi). Pred nekaj leti sem že in s pametnim domom, a se je na tem ustavilo. Do analize porabe sem prišel šele zdaj, o čemer je pravzaprav ta članek.
Nedavno sem prešel na Home Assistant kot sistem pametnega doma. Ena od razlogov je bila prav sposobnost organiziranja zbiranja velikega števila podatkov z možnostjo priročnega ustvarjanja raznih grafikonov.
Informacije, opisane v tem članku, niso nove; vse te stvari so bile že opisane na spletu pod različnimi okusi. A vsaka študija običajno opisuje le en pristop ali vidik. Moralo se je samo primerjati vse te pristope in izbrati najbolj primernega. Članek vseeno ne ponuja izčrpnih informacij o zbiranju podatkov, ampak je neke vrste povzetek, kako sem to storil jaz. Tako da so konstruktivna kritika in predlogi za izboljšanje dobrodošli.
Definisanje zadatka
Torej, cilj današnjega vajanja je dobiti lepe grafike porabe vode in električne energije:
- Udobno po urah za 2 dni
- Po dnevih za 2 tedna
- (neobvezno) po tednih in po mesecih
Tukaj nas čakajo nekatere težave:
- Standardne komponente grafikonov so običajno precej skromne. V najboljšem primeru lahko zgradite linearni grafikon iz točk.
Če dobro iščete, lahko najdete zunanje komponente, ki razširjajo možnosti standardnega grafikona. Za Home Assistant je v resnici dobra in lepa komponenta , vendar ima tudi ona nekaj omejitev:
- Težko je nastaviti parametre stolpčnega grafikona na velikih intervalih (širina stolpca je nastavljena v delih ure, kar pomeni, da so intervali daljši od ure določeni v decimalnih številkah)
- Ni mogoče dodati različnih entitet na en grafikon (na primer temperature in vlažnosti ali kombinirati stolpčni grafikon z linijskim)
- Ne samo da home assistant koristi najosnovniju bazu podataka SQLite po defaultu (a ja, nespretan, nisam uspeo da instaliram MySQL ili Postgres), već se podaci čuvaju na vrlo suboptimalan način. Tako, na primer, pri svakoj promeni čak i najmalog numeričkog parametra, u bazu se beleži ogroman json veličine oko kilobajta.
{"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}}}Imam poprilično veliki broj senzora (temperaturni senzori u svakoj sobi, merni uređaji za vodu i struju), a neki od njih generišu prilično velike količine podataka. Na primer, samo merni uređaj za struju SDM220 generiše oko desetak vrednosti svakih 10-15 sekundi, a takvih uređaja bih želeo da postavim 8. Takođe, postoji niz parametara koji se obračunavaju na osnovu drugih senzora. Dakle, sve te vrednosti lako mogu povećati bazu za 100-200 MB dnevno. Nakon nedelju dana, sistem će jedva raditi, a nakon mesec dana će USB fleš disk propasti (u slučaju tipične instalacije home assistant na Raspberry Pi), a o čuvanju podataka tokom cele godine ne može biti ni reči.
- Ako imate sreće, vaš merni uređaj može sam da proračuna potrošnju. U bilo kojem trenutku možete da se obratite mernom uređaju i pitate koje je trenutno akumulirano stanje potrošnje. Obično svi merni uređaji za struju koji imaju digitalni interfejs (RS232/RS485/Modbus/Zigbee) obezbeđuju tu mogućnost.
Poslabše je, če naprava lahko le meri določen trenutni parameter (na primer trenutna moč ali tok), ali pa preprosto generira impulze vsake X vatnih ur ali litrov. Takrat je treba razmisliti, kako in s čim to integrirati ter kje shraniti vrednost. Obstaja tveganje, da se zamudi poročilo iz kakršnega koli razloga, in točnost sistema kot celote vzbuja vprašanja. Seveda lahko to prepustimo pametnemu domu, kot je home assistant, vendar nihče ni odpovedal točki o številu zapisov v bazi, pa tudi vprašanje je, ali je mogoče anketirati senzorje pogosteje kot enkrat na sekundo (omejitev arhitekture home assistant).
Pristop 1
Najprej si oglejmo, kaj home assistant nudi kar tako. Meritve porabe v določenem obdobju so zelo iskana funkcionalnost. Seveda so jo že dolgo nazaj realizirali v obliki specializirane komponente - utility_meter.
Namen komponente je, da znotraj ustvari spremenljivko trenutna_nakopljena_vrednost in jo ponastavi po preteku določenega obdobja (ura/teden/mesec). Komponenta sama spremlja vhodno spremenljivko (vrednost nekega senzorja) in se sama naroči na spremembe vrednosti - vi preprosto prejmete končni rezultat. To stvar opišete s samo nekaj vrsticami v konfiguracijski datoteki.
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Tukaj je sensor.water_meter_cold trenutna vrednost števca v litrih, ki jo prejmem prek mqtt. Konstrukcija ustvari 2 nova senzorna water_cold_hour_um in water_cold_day_um, ki zbirata urne in dnevne podatke, jih ponastavljata po preteku obdobja. Tukaj je graf urnega akumulatorja za pol dneva.
Koda urnih in dnevnih grafov za lovelace-UI izgleda takole:
- type: history-graph
title: 'Urošnja porabe vode z uporabo variabl'
hours_to_show: 48
entities:
- sensor.water_hour
- type: history-graph
title: 'Dnevna poraba vode z uporabo variabl'
hours_to_show: 360
entities:
- sensor.water_day
V tem algoritmu se skriva problem tega pristopa. Kot sem že omenil, za vsako vhodno vrednost (trenutno stanje števcem za vsak naslednji liter) generira 1 kB zapis v bazi. Vsak utility meter prav tako generira novo vrednost, ki se prav tako vstavi v bazo. Če želim zbirati urne / dnevne / tedenske / mesečne podatke, pa še za več vodovodnih sistemov, poleg tega pa dodati še paket električnih števcev - to bo zelo veliko podatkov. Natančneje, podatkov ne bo veliko, a ker home assistant v bazo zapisuje kup odvečnih informacij, se bo velikost baze povečevala, kot bi zrasla z kvasom. Bojim se celo oceniti velikost baze za tedenske in mesečne grafikone.
Poleg tega utility meter sam po sebi ne reši postavljene naloge. Grafikon vrednosti, ki jih poda utility meter, je monotonno naraščajoča funkcija, ki se ob vsakem uri ponastavi na 0. Potrebujemo jasen grafikon porabe za uporabnika, koliko litrov je bilo porabljenih v tem obdobju. Standardna komponenta history-graph tega ne zna, lahko pa nam pomaga zunanja komponenta mini-graph-card.
To je koda za kartico za lovelace-UI:
- aggregate_func: max
entities:
- color: var(--primary-color)
entity: sensor.water_cold_hour_um
group_by: hour
hours_to_show: 48
name: "Urna poraba vode agregirana po utility meter"
points_per_hour: 1
show:
graph: bar
type: 'custom:mini-graph-card'Poleg standardnih nastavitev, kot so ime senzorja, vrsta grafikona, barva (standardna oranžna mi ni bila všeč), je pomembno omeniti 3 nastavitve:
- group_by:hour — grafikon bo generiran s poravnavo stolpcev na začetku ure
- points_per_hour: 1 — en stolpec na vsako uro
- In najpomembneje, aggregate_func: max — vzeti največjo vrednost v okviru vsake ure. Ta parameter spremeni zobni grafikon v stolpce.
Na vrsto stolpcev na levi ne bodite pozorni — to je standardno vedenje komponente, če ni podatkov. Podatkov ni bilo — le nekaj ur nazaj sem aktiviral zbiranje podatkov po utility meter samo zaradi tega članka (svoj trenutni pristop bom opisal nekoliko nižje).
Na tej sliki sem želel pokazati, da včasih prikaz podatkov dejansko deluje in stebričke res odražajo pravilne vrednosti. Le da niso vse. Oznak stebrička za časovno obdobje med 11. in 12. uro iz nekega razloga prikazuje 19 litrov, čeprav na zobatem grafu malo višje za isto obdobje iz istega senzorja vidimo porabo 62 litra. Bodisi gre za napako, bodisi za slabo izvedbo. Ne razumem pa, zakaj so se podatki na desni strani lomili — tam je bila poraba normalna, kar je prav tako razvidno iz zobatega grafika.
Na splošno mi ni uspelo doseči verodostojnosti tega pristopa — graf skoraj vedno prikazuje nekakšno neumnost.
Analogna koda za dnevni senzor.
- aggregate_func: max
entities:
- color: var(--primary-color)
entity: sensor.water_cold_day_um
group_by: interval
hours_to_show: 360
name: "Dnevna poraba vode, združena po merilniku"
points_per_hour: 0.0416666666
show:
graph: bar
type: 'custom:mini-graph-card'
Upoštevajte, da je parameter group_by nastavljena na vrednost interval in da vpliva na vse parameter points_per_hour. In v tem leži še en problem tega komponenta — points_per_hour dobro deluje na grafih za eno uro ali manj, a se slabo obnese pri daljših obdobjih. Da bi dobili en stolpec za en dan, sem moral vpisati vrednost 1/24=0.04166666. O tedenskih in mesečnih grafih pa niti ne govorim.
Pristop 2
Še ko sem se samo začel ukvarjati z home assistant, sem naletel na tole video:
Prijatelj zbira podatke o porabi iz več vrst vtičnic Xiaomi. Njegova naloga je nekoliko lažja — preprosto prikazati vrednost porabe za danes, včeraj in za mesec. Nobenih grafov ni treba.
Pustimo ob strani razprave o ročnem integriranju trenutnih vrednosti moči — o "natančnosti" takšnega pristopa sem že pisal zgoraj. Ni jasno, zakaj ni uporabil nabranih vrednosti porabe, ki jih že zbira ta ista vtičnica. Po mojem mnenju bo integracija znotraj naprave delovala bolje.
Iz videa bomo vzeli idejo ročnega štetja porabe za obdobje. Pri človeku se štejejo samo vrednosti za danes in včeraj, mi pa bomo šli naprej in poskusili narisati graf. Bistvo predlagane metode v mojem primeru je naslednje.
Ustanovili bomo spremenljivko vrednost_na_zacetku_ure, v katero bomo zabeležili trenutne podatke števc
Na koncu ure (ali na začetku naslednje) bomo izračunali razliko med trenutnim številom in tistim, ki je bil shranjen na začetku ure. Ta razlika bo poraba v trenutni uri - vrednost bomo shranili v senzor in v prihodnje bomo to vrednost uporabili za izdelavo grafa.
Prav tako je potrebno "ponastaviti" spremenljivko vrednost_v_začetku_ure tako, da vanjo zapišemo trenutno vrednost števec.
Vse to lahko storimo prek … sredstev samega home assistant.
Kode bo treba napisati nekoliko več, kot v prejšnjem pristopu. Najprej bomo ustvarili te "spremenljivke". Privzeto nimamo entitete "spremenljivka", vendar lahko izkoristimo storitve mqtt posrednika. Pošiljali bomo vrednosti tja s flagom retain=true - to bo ohranilo vrednost v posredniku, in jo lahko kadar koli izvlečemo, tudi pri ponovnem zagonu home assistant. Tako sem ustvaril urne in dnevne števce.
- 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: lVsa magija poteka v avtomatizaciji, ki se izvaja vsako uro in vsako noč.
- 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 avtomatizaciji izvajata 2 dejanja:
- Izračunata vrednost za interval kot razliko med začetno in končno vrednostjo.
- Posodobita osnovno vrednost za naslednji interval.
Izdelava grafov se v tem primeru reši s preprostim history-graph:
- type: history-graph
title: 'Urošnja porabe vode z uporabo variabl'
hours_to_show: 48
entities:
- sensor.water_hour
- type: history-graph
title: 'Dnevna poraba vode z uporabo variabl'
hours_to_show: 360
entities:
- sensor.water_dayIzgleda ovako:
V načelu je to že tisto, kar potrebujemo. Prednost te metode je, da se podatki generirajo enkrat na interval. To pomeni 24 vnosov na dan za urni graf.
Žal, to ne rešuje splošne težave rastoče baze. Če želim grafikon mesečne porabe, bom moral hraniti podatke vsaj eno leto. Ker home assistant omogoča le eno nastavitev trajanja hrambe za celo bazo, to pomeni, da je treba VSE podatke v sistemu hraniti celo leto. Na primer, v enem letu porabim 200 kubičnih metrov vode, kar pomeni 200000 vnosov v bazo. Če k temu dodam še druge senzorje, se številka sploh postavi v smešen okvir.
Pristop 3
Na srečo so pametni ljudje že rešili to težavo z ustvarjanjem podatkovne baze InfluxDB. Ta baza je posebej optimizirana za shranjevanje časovno povezanih podatkov in je popolna za shranjevanje vrednosti različnih senzorjev. Sistem prav tako ponuja SQL-podobni jezik poizvedb, ki omogoča, da iz baze izvlečemo vrednosti in jih nato agregiramo na različne načine. Nazadnje, različni podatki se lahko shranjujejo različno dolgo. Na primer, pogosto spremenljive vrednosti, kot so temperatura ali vlaga, lahko hranimo le nekaj tednov, medtem ko lahko dnevne vrednosti porabe vode hranimo celo leto.
Poleg InfluxDB so pametni ljudje tudi izumili Grafano — sistem za risanje grafikonov z podatki iz InfluxDB. Grafana zna risati različne vrste grafikonov, jih podrobno prilagoditi in, kar je najpomembneje, te grafe je mogoče "vstaviti" v lovelace-UI home assistant-a.
Navdihovati se in . Članki podrobno opisujejo postopek namestitve in povezovanja InfluxDB in Grafane s home assistant. Poudaril bom reševanje svoje specifične naloge.
Torej, najprej začnimo shranjevati vrednost števca v influxDB. Kos konfiguracije home assistant (v tem primeru se bom zabaval ne le s pitno, temveč tudi s toplo vodo):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldIzklopili bomo shranjevanje teh istih podatkov v notranjo bazo home assistant, da je ne bomo nepotrebno napihovali:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldZdajmo se v konzolo InfluxDB in nastavimo našo bazo. Zlasti je treba nastaviti, koliko časa bodo shranjeni določeni podatki. To se ureja s t. im. retention policy — to je podobno bazam podatkov znotraj glavne baze podatkov, pri čemer ima vsaka notranja baza svoje nastavitve. Privzeto se vsi podatki shranijo v retention policy, imenovani autogen, in ti podatki bodo shranjeni en teden. Rad bi, da se podatki na uro shranijo mesec, tedenski — leto, mesečni pa se nikoli ne izbrišejo. Ustvarimo ustrezne retention policy.
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 1Sedaj, v resnici, glavna poteza — agregacija podatkov s pomočjo continuous query. To je mehanizem, ki samodejno izvaja poizvedbo v rednih časovnih presledkih, agregira podatke po tej poizvedbi, in rezultat shrani kot novo vrednost. Oglejmo si primer (pišem v stolpec za boljšo berljivost, a v resnici sem morali vstaviti to ukaz v eni vrstici).
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)
ENDTa ukaz:
- Ustvari continuous query z imenom cq_water_cold_hourly v bazi homeassistant.
- Poizvedba se bo izvajala vsakih eno uro (time(1h)).
- Poizvedba bo pridobila vse podatke iz meritev homeassistant.autogen.l (litri), vključno z odčitki hladne in tople vode.
- Agregirani podatki se bodo grupirali po entity_id, kar nam bo omogočilo, da dobimo ločene vrednosti za hladno in toplo vodo.
- Ker je števec litrov monotonno naraščajoča zaporedje, je potrebno v okviru vsake ure vzeti maksimalno vrednost, tako da bo agregacija izvedena s funkcijo max(value).
- Nova vrednost bo zapisana v homeassistant.month.water_meter_hour, kjer je month ime retention policy s trajanjem shranjevanja en mesec. Podatki o topli in hladni vodi bodo razporejeni v ločene vnose s pripadajočim entity_id in vrednostjo v polju value.
Ponoči ali ko nikogar ni doma ni porabe vode, in posledično ni novih zapisov v homeassistant.autogen.l. Da ne pride do vrzeli v vrednostih v običajnih poizvedbah, lahko uporabimo fill(previous). To omogoči InfluxDB, da uporabi vrednost prejšnje ure.
Nažalost, continuous query ima posebnost: trik fill(previous) ne radi i zapisi se jednostavno ne kreiraju. Očigledno, ovo je neka nepremostiva prepreka koja S ovim problemom ćemo se suočiti kasnije, a fill(previous) u continuous query neka ostane — ne smeta.
Proverićemo šta smo dobili (naravno, potrebno je sačekati nekoliko sati):
> 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
Obratite pažnju da se vrednosti u bazi čuvaju u UTC, tako da se na ovoj listi razlikuju za 3 sata — vrednosti za 7 sati ujutro u izlazu InfluxDB odgovaraju vrednostima za 10 sati ujutro na prethodnim grafikonima. Takođe, obratite pažnju da između 2 i 5 ujutro jednostavno nema zapisa — to je ona posebnost continuous query.
Kao što vidite, agregirana vrednost takođe predstavlja monotonously rastuću sekvencu, samo su zapisi ređi — jedan na sat. Ali to nije problem — možemo napisati još jedan upit koji će izvući ispravne podatke za grafikon.
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)Objašnjenje:
- Iz baze homeassistant.month.water_meter_hour izvući ćemo podatke za entity_id='water_meter_cold' za poslednja 24 sata (time >= now() -24h).
- Kao što sam već spomenuo, u sekvenci homeassistant.month.water_meter_hour mogu nedostajati neki zapisi. Ove podatke ćemo ponovo generisati, pokrenuvši upit sa GROUP BY time(1h). Ovog puta fill(previous) će raditi kako treba, generišući nedostajuće podatke (funkcija će uzeti prethodnu vrednost)
- Najvažnija stavka u ovom upitu je funkcija difference, koja će izračunati razliku između časovnih oznaka. Sama po sebi ne funkcioniše i zahteva agregatnu funkciju. Neka to bude max() koja je ranije korišćena.
Rezultat izvršenja izgleda ovako:
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 ure (UTC) ni bilo porabe. Kljub temu bo zahteva vrnila enako vrednost porabe zahvaljujoč fill(previous), funkcija difference pa bo to vrednost odštela od same sebe in na izhodu dobili 0, kar je v bistvu tudi potrebno.
Ostalo je le še to, da zgradimo graf. V ta namen odprite Grafano, odprite obstoječ (ali ustvarite nov) nadzorni plošči, ustvarite novo ploščo. Nastavitve grafov bodo takšne.
Prikazal bom podatke o hladni in topli vodi na enem grafu. Zahteva je točno taka, kot sem jo opisal zgoraj.
Nastavitve prikaza so določene na naslednji način. To bo graf z linijami (lines), ki gre v stopničastem (stairs) načinu. Parameter Stack bom razložil malo pozneje. Tam spodaj je še nekaj drugih parametrov prikaza, a ti niso tako zanimivi.
Da dodate pridobljen graf v home assistant, morate:
- izstopiti iz načina urejanja grafov. Iz neznanega razloga so pravilne nastavitve deljenja grafov na voljo le s strani nadzorne plošče.
- Kliknite na trikotnik ob imenu grafa, izberite share v meniju.
- V okenčku, ki se odpre, preklopite na zavihek embed.
- Odkljukajte current time range — časovni razpon bomo določili preko URL-ja.
- Izberite potrebno temo. V mojem primeru je to light.
- Kopirajte pridobljeni URL v kartico nastavitev 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"
Upoštevajte, da se časovni razpon (zadnji 2 dni) nastavi prav tu, ne pa v nastavitvah nadzorne plošče.
Graf izgleda takole. Tople vode v zadnjih 2 dneh nisem uporabil, zato se prikaže le graf hladne vode.
Še vedno nisem uspel ugotoviti, kateri graf mi je bolj všeč, stopničasta linija ali pravi stolpci. Zato preprosto prinašam primer dnevnega grafika porabe, tokrat z stolpci. Zahteve se gradijo na podoben način kot zgoraj opisane. Nastavitve prikaza so naslednje:
Ta graf izgleda takole:
Tako o parametru Stack. V tem grafu je stolpec hladne vode natančno nadeven na stolpec tople vode. Skupna višina ustreza skupni porabi za hladno in toplo vodo v obdobju.
Vsi prikazani grafi so dinamični. Lahko premaknete miško na interesno točko in si ogledate podrobnosti in vrednost v konkretnem trenutku.
Na žalost ni brez ene dvojice negativnih stvari. Na stolpčnem grafu (v nasprotju s korakastim grafom) se sredina stolpca ne nahaja sredi dneva, temveč ob 00:00. To pomeni, da je leva polovica stolpca narisana na mestu prejšnjega dne. Tako so grafi za soboto in nedeljo narisani nekoliko levo od modrikaste cone. Še nisem našel načina, kako to premagati.
Drug problem je v nemogočnosti pravilnega dela z mesečnimi intervali. Gre za to, da je dolžina ure/dneva/tedna fiksna, medtem ko je dolžina meseca vsakokrat različna. InfluxDB zna delati samo z enakimi intervali. Zaenkrat mi je uspelo nastaviti fiksni interval 30 dni. Da, graf med letom nekoliko zamoči in stolpci ne bodo čisto natančno ustrezali mesecem. Ker me ta stvar zanima le kot merilnik, se s tem strinjam.
Rešitev vidim vsaj dve:
- Pustiti mesečne grafike in se omejiti na tedenske. 52 tedenskih stolpcev na leto se kar lepo obnese.
- Sam mesečni porabi šteti kot način št. 2, grafano pa uporabiti samo za lepe grafike. Tako bo dobili kar natančno rešitev. Lahko celo prekrivamo grafe iz prejšnjega leta za primerjavo — grafana zna tudi to.
Zaključek
Ne vem zakaj, ampak obožujem tovrstne grafe. Pokazujejo, da življenje vre in vse se spreminja. Včeraj je bilo veliko, danes malo, jutri bo spet drugače. Ostalo je le še, da se pogovorim z družinskimi člani o porabi. Toda tudi pri trenutnih apetiti preprosto velika in nejasna številka v plačilu postane precej jasna slika porabe.
Kljub skoraj 20-letni karieri programerja se nisem nikoli srečal z bazami podatkov. Zato je namestitev zunanje baze podatkov delovala kot nekaj tako zapletenega in nejasnega. Vse se je spremenilo, se je izkazalo, da je pritrditev primernega orodja izvedljiva v nekaj klikih, in s specializiranim orodjem je naloga gradnje grafov nekoliko lažja.
V naslovu sem omenil porabo električne energije. Na žalost v tem trenutku ne morem priskrbeti nobene grafike. En merilnik SDM120 mi je odpovedal, drugi pa ima težave pri komunikaciji preko Modbus-a. Kakor koli, to ne vpliva na temo tega članka — grafi bodo narisani na enak način kot za vodo.
V tem članku sem predstavil pristope, ki sem jih sam preizkusil. Verjetno obstajajo še drugi načini zbiranja in vizualizacije podatkov, o katerih ne vem. O tem mi sporočite v komentarjih, zelo me zanima. Vesel bom konstruktivne kritike in novih idej. Upam, da bo predstavljen material koristil tudi komu drugemu.
Izvor: habr.com
