Vsakič, ko prejmem položnico za elektriko in vodo, sem presenečen - ali moja družina res porabi toliko? No, ja, kopalnica ima ogrevana tla in bojler, vendar ne kurijo ves čas. Zdi se, da tudi z vodo varčujemo (čeprav radi čofotamo tudi v kopalnici). Pred nekaj leti sem že и v pametni dom, a tam se je zataknilo. Šele zdaj smo se lotili analize porabe, o čemer pravzaprav govori ta članek.
Nedavno sem preklopil na Home Assistant kot svoj sistem pametnega doma. Eden od razlogov je bila ravno priložnost za organizacijo zbiranja velike količine podatkov z možnostjo priročne sestave različnih vrst grafov.
Informacije, opisane v tem članku, niso nove, vse te stvari pod različnimi omakami so že opisane na internetu. Toda vsak članek običajno opisuje samo en pristop ali vidik. Vse te pristope sem moral primerjati in sam izbrati najprimernejšega. Članek še vedno ne ponuja celovitih informacij o zbiranju podatkov, ampak je nekakšen povzetek tega, kako sem to naredil. Zato so dobrodošle konstruktivne kritike in predlogi za izboljšave.
Izjava o težavah
Torej, cilj današnje vaje je dobiti lepe grafe porabe vode in elektrike:
- Vsako uro 2 dni
- Dnevno 2 tedna
- (neobvezno) tedensko in mesečno
Pri tem je nekaj težav:
- Standardne komponente grafikona so običajno precej slabe. V najboljšem primeru lahko sestavite črtni graf točko za točko.
Če dovolj natančno pogledate, lahko najdete komponente drugih proizvajalcev, ki razširijo zmogljivosti standardnega grafikona. Za domačega pomočnika je to načeloma dobra in lepa komponenta , vendar je tudi nekoliko omejen:
- Težko je nastaviti parametre paličnega grafikona v velikih intervalih (širina stolpca je nastavljena v delčkih ure, kar pomeni, da bodo intervali, daljši od ene ure, nastavljeni v delčkih)
- V en graf ne morete dodati različnih entitet (na primer temperature in vlažnosti ali kombinirati palični graf s črto)
- Ne samo, da domači pomočnik privzeto uporablja najprimitivnejšo bazo podatkov SQLite (in jaz, mojster, nisem mogel namestiti MySQL ali Postgres), ampak tudi podatki niso shranjeni na najbolj optimalen način. Tako se na primer vsakič, ko spremenite najmanjši digitalni parameter parametra, v bazo podatkov zapiše ogromen json, velik približno kilobajt
{"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}}}Senzorjev imam kar veliko (senzorji temperature v vsaki sobi, števci za vodo in elektriko), nekateri pa generirajo tudi kar veliko podatkov. Na primer, samo števec električne energije SDM220 ustvari približno ducat vrednosti vsakih 10-15 sekund, jaz pa bi rad namestil približno 8 takšnih števcev, obstaja pa tudi cel kup parametrov, ki se izračunajo na podlagi drugih senzorjev. to. vse te vrednosti lahko enostavno napihnejo bazo podatkov za 100-200 MB dnevno. V enem tednu se bo sistem komaj premaknil, v enem mesecu pa bo bliskovni pogon umrl (v primeru tipične namestitve domačega pomočnika na Raspberry PI), shranjevanje podatkov za celo leto pa ne pride v poštev.
- Če imate srečo, lahko vaš števec sam šteje porabo. Kadarkoli se lahko obrnete na števec in vprašate, koliko časa znaša skupna vrednost porabe. To možnost imajo praviloma vsi števci električne energije, ki imajo digitalni vmesnik (RS232/RS485/Modbus/Zigbee).
Huje je, če lahko naprava preprosto izmeri nek trenutni parameter (na primer trenutno moč ali tok) ali preprosto ustvari impulze vsakih X vatnih ur ali litrov. Potem morate razmišljati o tem, kako in s čim ga integrirati in kje akumulirati vrednost. Obstaja tveganje, da iz kakršnega koli razloga zamudite naslednje poročilo, točnost sistema kot celote pa postavlja vprašanja. Vse to lahko seveda zaupate sistemu pametnega doma, kot je domači pomočnik, vendar nihče ni preklical točke o številu zapisov v bazi podatkov in senzorjev ne bo mogoče anketirati več kot enkrat na sekundo (a omejitev arhitekture domačega pomočnika).
Pristop 1
Najprej si poglejmo, kaj ponuja domači pomočnik takoj po izdelavi. Merjenje porabe v obdobju je zelo iskana funkcionalnost. Seveda je bil implementiran že zdavnaj v obliki specializirane komponente - utility_meter.
Bistvo komponente je, da interno ustvari spremenljivko current_accumulated_value in jo ponastavi po določenem obdobju (ura/teden/mesec). Komponenta sama spremlja vhodno spremenljivko (vrednost nekega senzorja), se naroči na spremembe vrednosti - dobite samo končni rezultat. Ta stvar je opisana v samo nekaj vrsticah 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
Tu je sensor.water_meter_cold trenutna vrednost merilnika v litrih, ki jo prejmem avtor mqtt. Zasnova ustvari 2 nova senzorja water_cold_hour_um in water_cold_day_um, ki zbirata urne in dnevne odčitke ter jih po poteku obdobja ponastavita na nič. Tukaj je graf urne baterije za pol dneva.
Koda za urne in dnevne grafikone za lovelace-UI je videti takole:
- 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
Pravzaprav je problem tega pristopa v tem algoritmu. Kot sem že omenil, se za vsako vhodno vrednost (trenutno stanje števca za vsak naslednji liter) v bazi ustvari 1kb zapisov. Vsak komunalni števec ustvari tudi novo vrednost, ki se prav tako prišteje k osnovi. Če želim zbrati urne/dnevne/tedenske/mesečne odčitke in za več dvižnih vodov ter dodati paket električnih števcev, bo to veliko podatkov. No, natančneje, podatkov ni veliko, a ker hišni pomočnik v bazo zapiše kup nepotrebnih informacij, bo velikost baze skokovito narasla. Bojim se celo oceniti velikost osnove za tedenske in mesečne lestvice.
Poleg tega števec komunalnih storitev sam po sebi ne reši problema. Graf vrednosti, ki jih proizvede merilnik komunalnih storitev, je monotono naraščajoča funkcija, ki se vsako uro ponastavi na 0. Potrebujemo uporabniku razumljivo tabelo porabe, ki prikazuje, koliko litrov je bilo porabljenih v določenem obdobju. Standardna komponenta grafa zgodovine tega ne more storiti, lahko pa nam pomaga zunanja komponenta mini grafične kartice.
To je koda kartice 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: "Hourly water consumption aggregated by utility meter"
points_per_hour: 1
show:
graph: bar
type: 'custom:mini-graph-card'Poleg standardnih nastavitev, kot so ime senzorja, vrsta grafa, barva (standardna oranžna mi ni bila všeč), je pomembno upoštevati 3 nastavitve:
- group_by:hour — graf bo ustvarjen s stolpci, poravnanimi na začetek ure
- točke_na_uro: 1 - en stolpec za vsako uro
- In kar je najpomembneje, aggregate_func: max - vzemite največjo vrednost v vsaki uri. Ta parameter pretvori zobni graf v palice
Ne bodite pozorni na vrstico stolpcev na levi - to je standardno vedenje komponente, če ni podatkov. Vendar ni bilo nobenih podatkov - zbiranje podatkov števcev komunalnih storitev sem vklopil šele pred nekaj urami samo zaradi tega članka (spodaj bom opisal svoj trenutni pristop).
Na tej sliki sem želel pokazati, da včasih prikaz podatkov celo deluje in stolpci dejansko odražajo pravilne vrednosti. A to še ni vse. Izbrani stolpec za obdobje od 11. do 12. ure iz neznanega razloga prikazuje 19 litrov, čeprav na zobatem grafu malo višje za isto obdobje z istega tipala vidimo porabo 62 litrov. Ali je hrošč ali pa so roke ukrivljene. Še vedno pa ne razumem, zakaj se je podatek na desni odlomil - tam je bila poraba normalna, kar je razvidno tudi iz zobatega grafa.
Na splošno nisem mogel doseči verodostojnosti tega pristopa - graf skoraj vedno kaže neko herezijo.
Podobna 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: "Daily water consumption aggregated by utility meter"
points_per_hour: 0.0416666666
show:
graph: bar
type: 'custom:mini-graph-card'
Upoštevajte, da je parameter group_by nastavljen na interval, parameter points_per_hour pa ureja vse. In v tem je še ena težava s to komponento - points_per_hour deluje dobro na grafikonih za eno uro ali manj, vendar je zanič v večjih intervalih. Torej, da bi dobil en stolpec v enem dnevu, sem moral vnesti vrednost 1/24=0.04166666. Da o tedenskih in mesečnih lestvicah niti ne govorim.
Pristop 2
Medtem ko sem še vedno razumel domačega pomočnika, sem naletel na ta video:
Prijatelj zbira podatke o porabi iz več vrst vtičnic Xiaomi. Njegova naloga je nekoliko preprostejša - preprosto prikaže vrednost porabe za danes, včeraj in za mesec. Urniki niso potrebni.
Pustimo ob strani razprave o ročni integraciji trenutnih vrednosti moči - zgoraj sem že pisal o "natančnosti" tega pristopa. Zakaj ni uporabil akumuliranih vrednosti porabe, ki jih že zbira isto prodajno mesto, ni jasno. Po mojem mnenju bo integracija znotraj strojne opreme delovala bolje.
Iz videa bomo vzeli zamisel o ročnem štetju porabe v določenem obdobju. Fant šteje samo vrednosti za danes in včeraj, vendar bomo šli dlje in poskusili narisati graf. Bistvo predlagane metode v mojem primeru je naslednje.
Ustvarimo spremenljivko value_at_the_beginning_of_hour, v katero bomo zapisovali trenutne odčitke števca
S pomočjo merilnika časa na koncu ure (ali na začetku naslednje) izračunamo razliko med trenutnim odčitkom in tistim, shranjenim na začetku ure. Ta razlika bo poraba za trenutno uro - vrednost bomo shranili v senzor, v prihodnje pa bomo na podlagi te vrednosti zgradili graf.
Prav tako morate »ponastaviti« spremenljivko value_at_beginning_of_hour, tako da vanjo zapišete trenutno vrednost števca.
Vse to lahko storite prek samega domačega pomočnika.
Napisati boste morali malo več kode kot v prejšnjem pristopu. Najprej ustvarimo te iste "spremenljivke". Izven škatle nimamo "spremenljive" entitete, lahko pa uporabimo storitve posrednika mqtt. Tja bomo poslali vrednosti z zastavico retain=true - to bo vrednost shranilo znotraj posrednika in jo je mogoče kadar koli izvleči od tam, tudi ko se domači pomočnik znova zažene. Izdelala sem urne in dnevne števce naenkrat.
- 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 čarovnija se zgodi v avtomatizaciji, ki deluje vsako uro oziroma 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čunajte vrednost za interval kot razliko med začetno in končno vrednostjo
- Posodobite osnovno vrednost za naslednji interval
Konstrukcijo grafov v tem primeru rešuje običajni zgodovinski graf:
- type: history-graph
title: 'Hourly water consumption using vars'
hours_to_show: 48
entities:
- sensor.water_hour
- type: history-graph
title: 'Daily water consumption using vars'
hours_to_show: 360
entities:
- sensor.water_dayIzgleda takole:
Načeloma je to že tisto, kar je potrebno. Prednost te metode je, da se podatki generirajo enkrat na interval. Tisti. samo 24 zapisov na dan za urni grafikon.
Na žalost to še vedno ne reši splošnega problema rastoče baze. Če želim graf mesečne porabe, bom moral hraniti podatke vsaj eno leto. In ker domači pomočnik omogoča samo eno nastavitev trajanja shranjevanja za celotno bazo podatkov, to pomeni, da bodo morali biti VSI podatki v sistemu shranjeni celo leto. Jaz na primer v enem letu porabim 200 kubičnih metrov vode, kar pomeni, da to pomeni 200000 vpisov v bazo. In če upoštevate druge senzorje, potem številka postane na splošno nespodobna.
Pristop 3
Na srečo so pametni ljudje to težavo že rešili s pisanjem baze podatkov InfluxDB. Ta zbirka podatkov je posebej optimizirana za shranjevanje časovno zasnovanih podatkov in je idealna za shranjevanje vrednosti različnih senzorjev. Sistem ponuja tudi jezik poizvedb, podoben SQL, ki vam omogoča, da iz baze podatkov izvlečete vrednosti in jih nato združite na različne načine. Nazadnje, različne podatke je mogoče shraniti za različne čase. Na primer, odčitke, ki se pogosto spreminjajo, kot sta temperatura ali vlažnost, lahko shranite le za nekaj tednov, odčitke dnevne porabe vode pa celo leto.
Poleg InfluxDB so si pametni ljudje izmislili tudi Grafano, sistem za risanje grafov na podlagi podatkov iz InfluxDB. Grafana zna risati različne vrste grafov, jih podrobno prilagoditi, in kar je najpomembneje, te grafe lahko “priklopimo” na domačega pomočnika lovelace-UI.
Dobiti navdih и . V člankih je podrobno opisan postopek namestitve in povezovanja InfluxDB in Grafana z domačim pomočnikom. Osredotočil se bom na rešitev svoje specifične težave.
Torej, najprej začnimo dodajati vrednost števca v influxDB. Delček konfiguracije domačega pomočnika (v tem primeru se bom zabaval ne samo s hladno, ampak tudi s toplo vodo):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldOnemogočimo shranjevanje teh istih podatkov v notranjo zbirko podatkov domačega pomočnika, da je ne bi znova napihnili:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldPojdimo zdaj na konzolo InfluxDB in konfigurirajmo našo bazo podatkov. Zlasti morate konfigurirati, kako dolgo bodo določeni podatki shranjeni. To ureja t.i. politika hrambe - to je podobno bazam podatkov znotraj glavne baze podatkov, pri čemer ima vsaka notranja baza podatkov svoje nastavitve. Privzeto so vsi podatki shranjeni v politiki hrambe, imenovani autogen; ti podatki bodo shranjeni en teden. Želel bi, da se urni podatki hranijo en mesec, tedenski eno leto, mesečni podatki pa se nikoli ne brišejo. Ustvarimo ustrezno politiko zadrževanja
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 1Dejansko je glavni trik združevanje podatkov z neprekinjenim poizvedovanjem. To je mehanizem, ki samodejno zažene poizvedbo v določenih intervalih, združi podatke za to poizvedbo in doda rezultat v novo vrednost. Poglejmo primer (zaradi berljivosti pišem v stolpec, v resnici pa sem moral ta ukaz vnesti v eno vrstico)
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 neprekinjeno poizvedbo z imenom cq_water_cold_hourly v bazi podatkov homeassistant
- Zahteva bo izvršena vsako uro (čas (1h))
- Zahteva bo postrgala vse podatke iz meritve homeassistant.autogen.l (litri), vključno z odčitki hladne in tople vode
- Zbrani podatki bodo razvrščeni glede na entity_id, kar nam bo dalo ločene vrednosti za hladno in toplo vodo
- Ker je števec litrov monotono naraščajoče zaporedje znotraj vsake ure, bo treba vzeti največjo vrednost, zato bo združevanje izvedeno s funkcijo max(value)
- Nova vrednost bo zapisana v homeassistant.month.water_meter_hour, kjer je mesec ime politike hrambe z obdobjem hrambe enega meseca. Poleg tega bodo podatki o hladni in topli vodi razpršeni v ločene zapise z ustreznim entity_id in vrednostjo v polju vrednosti
Ponoči ali ko ni nikogar doma, ni porabe vode, zato ni novih vnosov v homeassistant.autogen.l. Če se želite izogniti manjkajočim vrednostim v običajnih poizvedbah, lahko uporabite fill(previous). To bo prisililo InfluxDB, da uporabi vrednost zadnje ure.
Na žalost ima neprekinjeno poizvedovanje posebnost: trik izpolni (prejšnji) ne deluje in zapisi preprosto niso ustvarjeni. Še več, to je nekakšna nerešljiva težava, ki . To težavo bomo obravnavali pozneje, vendar naj bo fill(previous) v neprekinjeni poizvedbi - ne moti.
Preverimo, kaj se je zgodilo (seveda morate počakati nekaj ur):
> 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
Upoštevajte, da so vrednosti v zbirki podatkov shranjene v UTC, zato se ta seznam razlikuje za 3 ure - vrednosti ob 7 v izhodu InfluxDB ustrezajo vrednostim ob 10 v zgornjih grafih. Upoštevajte tudi, da med 2. in 5. uro zjutraj preprosto ni nobenih zapisov - to je ista značilnost neprekinjenega poizvedovanja.
Kot lahko vidite, je tudi agregirana vrednost monotono naraščajoče zaporedje, le da se vnosi pojavljajo manj pogosto - enkrat na uro. Vendar to ni problem - lahko napišemo drugo poizvedbo, ki bo pridobila pravilne podatke za 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)bom dešifriral:
- Iz baze podatkov homeassistant.month.water_meter_hour bomo izvlekli podatke za entity_id='water_meter_cold' za zadnji dan (čas >= zdaj() -24h).
- Kot sem že omenil, nekateri vnosi morda manjkajo v zaporedju homeassistant.month.water_meter_hour. Te podatke bomo znova ustvarili tako, da bomo zagnali poizvedbo s časom GROUP BY (1h). Tokrat bo fill(previous) deloval po pričakovanjih in ustvaril manjkajoče podatke (funkcija bo prevzela prejšnjo vrednost)
- Najpomembnejša stvar v tej zahtevi je funkcija razlike, ki bo izračunala razliko med urnimi oznakami. Samostojno ne deluje in zahteva funkcijo združevanja. Naj bo to max(), uporabljen prej.
Rezultat izvedbe je videti takole
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 poizvedba vrnila isto vrednost porabe zahvaljujoč fill(previous), funkcija razlike pa bo to vrednost odštela od sebe in rezultat bo 0, kar je natanko tisto, kar se zahteva.
Vse kar ostane je sestaviti graf. Če želite to narediti, odprite Grafano, odprite obstoječo (ali ustvarite novo) nadzorno ploščo in ustvarite novo ploščo. Nastavitve grafikona bodo takšne.
Podatke o hladni in topli vodi bom prikazal na istem grafu. Zahteva je popolnoma enaka, kot sem jo opisal zgoraj.
Parametri zaslona so nastavljeni na naslednji način. Zame bo to graf s črtami, ki gre v korakih (stopnicah). Spodaj bom razložil parameter Stack. Spodaj je še nekaj možnosti prikaza, ki pa niso tako zanimive.
Če želite dodati nastali grafikon v pomočnika za dom, morate:
- zapustite način urejanja grafikona. Iz nekega razloga so pravilne nastavitve skupne rabe grafikona na voljo samo na strani nadzorne plošče
- Kliknite trikotnik poleg imena grafikona in v meniju izberite skupno rabo
- V oknu, ki se odpre, pojdite na zavihek za vdelavo
- Odkljukajte trenutni časovni razpon – časovni razpon bomo nastavili prek URL-ja
- Izberite želeno temo. V mojem primeru je svetloba
- Kopirajte dobljeni URL na kartico z nastavitvami uporabniškega vmesnika lovelace
- 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 je časovni razpon (zadnja 2 dni) nastavljen tukaj in ne v nastavitvah nadzorne plošče.
Graf izgleda takole. V zadnjih 2 dneh nisem uporabljal tople vode, zato je narisan samo graf za hladno vodo.
Sam se še vedno nisem odločil, kateri graf mi je bolj všeč, črtni korak ali pravi stolpci. Zato bom navedel le primer tabele dnevne porabe, le da tokrat v stolpcih. Poizvedbe so sestavljene podobno kot zgoraj opisane. Možnosti prikaza so:
Ta graf izgleda takole:
Torej o parametru Stack. Na tem grafu je stolpec hladne vode narisan na stolpcu vroče vode. Skupna višina ustreza skupni porabi hladne in tople vode za obdobje.
Vsi prikazani grafi so dinamični. Z miško se lahko pomaknete nad zanimivo točko in si ogledate podrobnosti in vrednost na določeni točki.
Na žalost je bilo nekaj muh v manikuri. Na paličnem grafikonu (za razliko od grafikona s stopničastimi črtami) sredina stolpca ni sredi dneva, ampak ob 00:00. Tisti. leva polovica stolpca je narisana namesto prejšnjega dne. Grafa za soboto in nedeljo sta torej narisana rahlo levo od modrikaste cone. Dokler nisem ugotovil, kako ga premagati.
Druga težava je nezmožnost pravilnega dela v mesečnih intervalih. Dejstvo je, da je dolžina ure/dneva/tedna določena, dolžina meseca pa je vsakič drugačna. InfluxDB lahko deluje samo v enakih intervalih. Doslej so bili moji možgani dovolj za nastavitev fiksnega intervala 30 dni. Da, graf bo skozi leto nekoliko lebdel in stolpci ne bodo natančno ustrezali mesecem. Ampak ker me ta stvar zanima zgolj kot merilnik zaslona, mi to ustreza.
Vidim vsaj dve rešitvi:
- Odpovejte se mesečnim lestvicam in se omejite na tedenske. 52 tedenskih stolpcev za leto je videti precej dobro
- Samo mesečno porabo upoštevajte kot metodo št. 2, grafano pa uporabljajte samo za lepe grafe. To bo kar natančna rešitev. Za primerjavo lahko celo prekrijete grafe za preteklo leto – grafana zmore tudi to.
Zaključek
Ne vem zakaj, vendar sem obseden s tovrstnimi grafi. Kažejo, da je življenje v polnem teku in da se vse spreminja. Včeraj je bilo veliko, danes malo, jutri bo kaj drugega. Preostane le še delo s člani gospodinjstva na temo potrošnje. A tudi ob trenutnih apetitih se le velika in nerazumljiva številka na položnici že spreminja v dokaj razumljivo sliko porabe.
Kljub skoraj 20-letni karieri programerja z bazami podatkov tako rekoč nisem imel stika. Zato se je namestitev zunanje baze zdela nekaj tako neumnega in nerazumljivega. Spremenil vse — izkazalo se je, da pritrditev ustreznega orodja poteka v nekaj klikih, s specializiranim orodjem pa je izris grafikonov nekoliko lažji.
V naslovu sem omenil porabo električne energije. Na žalost trenutno ne morem zagotoviti nobenega grafa. En števec SDM120 mi je umrl, drugi pa dela napake pri dostopu prek Modbusa. Vendar to na noben način ne vpliva na temo tega članka - grafi bodo zgrajeni na enak način kot za vodo.
V tem članku sem predstavil pristope, ki sem jih preizkusil sam. Zagotovo obstajajo drugi načini organiziranja zbiranja podatkov in vizualizacije, ki jih ne poznam. Povejte mi o tem v komentarjih, zelo me bo zanimalo. Vesela bom konstruktivne kritike in novih idej. Upam, da bo predstavljeno gradivo tudi komu pomagalo.
Vir: www.habr.com