Iga kord, kui elektri ja vee eest tasu saan, mõtlen – kas tõesti mu pere tarbib niiii palju? No jah, vannitoas on põrandaküte ja boiler, aga need ei tööta kogu aeg tuletõrjujatena. Näib, et hoiame ka vett kokku (kuigi meile meeldib ka vannitoas sulistada). Paar aastat tagasi ma juba и targasse koju, kuid siin jäid asjad toppama. Käed on jõudnud tarbimise analüüsini alles nüüd, millest see artikkel tegelikult ka räägib.
Lülitasin hiljuti oma nutika kodu süsteemina koduabilisele. Üheks põhjuseks oli just võimalus korraldada suure hulga andmete kogumist koos erinevate graafikute mugava koostamise võimalusega.
Selles artiklis kirjeldatud teave pole uus, kõik need asjad erinevate kastmete all on Internetis juba kirjeldatud. Kuid iga artikkel kirjeldab reeglina ainult ühte lähenemist või aspekti. Pidin kõiki neid lähenemisi võrdlema ja ise sobivaima valima. Artikkel ei anna endiselt ammendavat teavet andmete kogumise kohta, vaid on omamoodi kokkuvõte sellest, kuidas ma seda tegin. Seega on konstruktiivne kriitika ja parendusettepanekud teretulnud.
Probleemi avaldus
Niisiis, tänase harjutuse eesmärk on saada ilusad vee- ja elektritarbimise graafikud:
- 2 päeva tunnis
- Iga päev 2 nädala jooksul
- (valikuline) kord nädalas ja kuus
Selles on mõningaid raskusi:
- Tavalised diagrammikomponendid kipuvad olema üsna kehvad. Parimal juhul saate koostada joongraafiku punktide kaupa.
Kui otsite hästi, võite leida kolmanda osapoole komponente, mis laiendavad standarddiagrammi võimalusi. Koduabilisele põhimõtteliselt hea ja ilus komponent , kuid see on ka mõnevõrra piiratud:
- Lintdiagrammi parameetrite määramine suurte intervallidega on keeruline (tulba laius määratakse tunni murdosades, mis tähendab, et tunnist pikemad intervallid seatakse murdarvudesse)
- Ühele graafikule ei saa lisada erinevaid üksusi (nt temperatuuri ja niiskust ega kombineerida tulpdiagrammi joonega)
- Vähe sellest, et koduabiline kasutab vaikimisi kõige primitiivsemat SQLite'i andmebaasi (ja mina, meistrimees, ei valdanud MySQL-i ega Postgresi installimist), ei salvestata ka andmeid kõige optimaalsemal viisil. Nii näiteks kirjutatakse iga parameetri iga väikseima digitaalse parameetri iga muudatusega andmebaasi tohutu, umbes kilobaidi suurune json
{"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}}}Andureid on mul päris mitu (temperatuuriandurid igas toas, vee- ja elektriarvestid), mõned genereerivad ka päris palju andmeid. Näiteks ainult SDM220 elektriarvesti genereerib kümmekond väärtust iga 10-15 sekundi järel ja selliseid arvestiid tahaks paigaldada 8. Ja seal on ka terve hulk parameetreid, mis arvutatakse teiste andurite põhjal. See. kõik need väärtused võivad hõlpsasti andmebaasi päevas 100–200 MB võrra suurendada. Nädala pärast hakkab süsteem vaevu tossama ja kuu aja pärast sureb mälupulk välja (tavalise koduabilise installimise korral vaarika PI-le) ning andmete terve aasta salvestamisest ei saa juttugi olla. .
- Kui teil veab, suudab teie arvesti ise tarbimist lugeda. Arvestiga saab igal ajal ühendust võtta ja küsida, mis kell on akumuleeritud tarbimisväärtus. Reeglina pakuvad sellist võimalust kõik elektriarvestid, millel on digitaalne liides (RS232/RS485/Modbus/Zigbee).
Veelgi hullem, kui seade suudab lihtsalt mõõta mõnda hetkeparameetrit (näiteks hetkevõimsust või voolu) või genereerida lihtsalt impulsse iga X vatt-tunni või liitri järel. Siis tuleb mõelda, kuidas ja millega seda integreerida ning kuhu väärtust koguda. On oht, et järgmine aruanne jääb mis tahes põhjusel vahele ning süsteemi kui terviku täpsus tekitab küsimusi. Loomulikult võite selle kõik usaldada targa kodu süsteemile, näiteks koduabilisele, kuid keegi pole andmebaasi kirjete arvu punkti tühistanud ja küsitlusandurid rohkem kui korra sekundis ei tööta (piirang koduabi arhitektuur).
Lähenemine 1
Kõigepealt vaatame, milline koduabiline on karbist väljas. Tarbimise mõõtmine teatud perioodi jooksul on väga nõutud funktsioon. Loomulikult rakendati seda juba ammu spetsiaalse komponendina - utility_meter.
Komponendi olemus seisneb selles, et see käivitab sees muutuja praeguse_akumuleeritud_väärtus ja lähtestab selle pärast määratud perioodi (tund/nädal/kuu). Komponent ise jälgib sissetulevat muutujat (mingisuguse anduri väärtust), registreerib enda väärtuse muutused - saate lihtsalt valmis tulemuse. Seda asja kirjeldatakse konfiguratsioonifailis vaid mõne reaga
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Siin sensor.water_meter_cold on arvesti hetkeväärtus liitrites, mille ma saan autor mqtt. Disain loob 2 uut andurit water_cold_hour_um ja water_cold_day_um, mis koguvad tunni- ja päevanäidud, lähtestades need pärast perioodi nulli. Siin on poole päeva tunnise aku graafik.
Lovelace-UI tunni- ja päevagraafiku kood näeb välja selline:
- 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
Tegelikult peitub selle lähenemisviisi probleem selles algoritmis. Nagu ma juba mainisin, genereeritakse andmebaasi iga sissetuleva väärtuse kohta (iga järgmise liitri jooksev arvesti näit) 1 kb kirjet. Iga kommunaalarvesti genereerib ka uue väärtuse, mis lisatakse samuti baasi. Kui ma tahan koguda tunni/päeva/nädala/kuu näitu, jah, mitme veepüstiku kohta ja lisada isegi elektriarvestite paki, on see palju andmeid. No täpsemalt, andmeid on vähe, aga kuna koduabiline kirjutab andmebaasi hunniku ebavajalikku infot, siis andmebaasi suurus kasvab hüppeliselt. Kardan isegi nädala- ja kuugraafikute aluse suurust hinnata.
Lisaks ei lahenda probleemi ka kommunaalarvesti ise. Kommunaalarvesti graafik on monotoonselt kasvav funktsioon, mis lähtestub iga tunni järel nullile. Vajame ka kasutajasõbralikku tarbimisgraafikut, mitu liitrit perioodil söödi. Tavaline ajaloograafiku komponent seda ei tee, kuid väline minigraafikukaardi komponent võib meid aidata.
See on lovelace-UI kaardikood:
- 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'Lisaks standardsätetele, nagu anduri nimi, graafiku tüüp, värv (tavaline oranž mulle ei meeldinud), on oluline siinkohal märkida 3 seadet:
- group_by:hour – diagramm genereeritakse veergudega, mis on joondatud tunni algusega
- punktid_tunni kohta: 1 – üks riba tunnis
- Ja mis kõige tähtsam, aggregate_func: max on võtta iga tunni jooksul maksimaalne väärtus. Just see parameeter muudab saehamba diagrammi tulpadeks.
Ärge pöörake tähelepanu vasakpoolsele veergude reale - see on komponendi tavapärane käitumine, kui andmeid pole. Andmeid aga polnud - andmekogumise lülitasin kommunaalmõõturi abil sisse alles paar tundi tagasi just selle artikli huvides (kirjeldan oma praegust lähenemist veidi madalamalt).
Sellel pildil tahtsin näidata, et mõnikord isegi andmete kuvamine töötab ja tulbad kajastavad tõesti õigeid väärtusi. Kuid see pole veel kõik. Mingil põhjusel näitab esiletõstetud veerg ajavahemikul 11–12 19 liitrit, kuigi hammastatud graafikul sama perioodi kohta veidi kõrgemal näeme sama anduri tarbimist 62 liitrit. Kas viga või käed on kõverad. Aga ma ei saa siiani aru, miks parempoolsed andmed katki läksid - seal oli tarbimine normaalne, mis on ka hammaste graafikult näha.
Üldiselt ei õnnestunud mul selle lähenemise usutavust saavutada – graafik näitab peaaegu alati mingit ketserlust.
Sarnane kood päevaanduri jaoks.
- 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'
Pange tähele, et parameeter group_by on seatud intervallile ja parameeter points_per_hour juhib kõike. Ja see on veel üks selle komponendi probleem – punktid_tunni kohta töötab hästi tunni või vähema graafiku korral, kuid vastikult suuremate intervallidega. Nii et ühe veeru saamiseks ühe päeva jooksul pidin sisestama väärtuse 1/24=0.04166666. Ma ei räägi nädala- ja kuugraafikutest.
Lähenemine 2
Koduabilise väljamõtlemise ajal sattusin selle video peale:
Seltsimees kogub tarbimisandmeid mitut tüüpi Xiaomi pesadest. Tema ülesanne on veidi lihtsam – lihtsalt kuvage tänase, eilse ja kuu tarbimise väärtus. Diagramme pole vaja.
Jätame kõrvale argumendid hetkvõimsuse väärtuste käsitsi integreerimise kohta - selle lähenemisviisi "täpsusest" kirjutasin juba eespool. Jääb arusaamatuks, miks ta ei kasutanud kogunenud tarbimisväärtusi, mida sama müügikoht juba kogub. Minu arvates toimib paremini integreerimine rauatüki sees.
Videost võtame idee perioodi jooksul tarbimist käsitsi lugeda. Mehe jaoks arvestatakse ainult tänase ja eilse päeva väärtusi, kuid läheme kaugemale ja proovime joonistada graafiku. Minu puhul on pakutud meetodi olemus järgmine.
Loome muutuja value_at_the_beginning_of_hour, kuhu kirjutame jooksvad loenduri näidud
Tunni lõpus (või järgmise alguses) oleva taimeri järgi arvutame hetkenäidu ja tunni alguses salvestatud näidu vahe. See erinevus on jooksva tunni tarbimine - salvestame väärtuse andurile ja edaspidi koostame selle väärtuse põhjal graafiku.
Samuti peate "lähtestama" muutuja value_at_beginning_of_hour, kirjutades sinna loenduri praeguse väärtuse.
Seda kõike saab teha läbi kaevu ... koduabilise enda abil.
Peate kirjutama veidi rohkem koodi kui eelmises lähenemisviisis. Alustame nendest "muutujatest". Karbist väljas pole meil "muutuvat" olemit, kuid saate kasutada mqtt maakleri teenuseid. Saadame sinna väärtused reten=true lipuga – see salvestab väärtuse maakleri sees ja selle saab igal ajal välja tõmmata, isegi kui koduabiline taaskäivitatakse. Tegin tunni- ja päevaloendurid korraga.
- 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: lKogu maagia toimub automaatikas, mis töötab vastavalt iga tund ja igal õhtul.
- 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: trueMõlemad automatiseerimised teevad 2 asja:
- Arvutage väärtus intervalli kohta algus- ja lõppväärtuse erinevusena
- Värskendage järgmise intervalli baasväärtust
Graafikute konstrueerimise lahendab sel juhul tavaline ajaloograafik:
- 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_daySee näeb välja selline:
Põhimõtteliselt on see juba see, mida vajate. Selle meetodi eeliseks on see, et andmed genereeritakse üks kord intervalli kohta. Need. tunnigraafikusse kokku 24 kirjet päevas.
Kahjuks ei lahenda see endiselt üldist kasvava baasi probleemi. Kui tahan igakuist tarbimisgraafikut, pean andmeid säilitama vähemalt aasta. Ja kuna koduabiline pakub kogu andmebaasi jaoks ainult ühte salvestuskestuse seadistust, tähendab see, et KÕIKI süsteemis olevaid andmeid tuleb säilitada terve aasta. Näiteks aastas tarbin 200 kuupmeetrit vett, mis tähendab 200000 XNUMX kannet andmebaasis. Ja kui võtta arvesse ka teisi andureid, muutub see näitaja üldiselt sündsusetuks.
Lähenemine 3
Õnneks on targad inimesed selle probleemi juba lahendanud, kirjutades InfluxDB andmebaasi. See andmebaas on spetsiaalselt optimeeritud ajapõhiste andmete salvestamiseks ja sobib ideaalselt erinevate andurite väärtuste salvestamiseks. Süsteem pakub ka SQL-i sarnast päringukeelt, mis võimaldab teil andmebaasist väärtusi välja võtta ja seejärel mitmel viisil koondada. Lõpuks saab eri aegadeks erinevaid andmeid salvestada. Näiteks sageli muutuvaid näitu, nagu temperatuur või õhuniiskus, saab säilitada vaid paar nädalat, päevased veetarbimise näidud aga terve aasta.
Lisaks InfluxDB-le leiutasid targad inimesed ka Grafana, süsteemi InfluxDB andmetest graafikute joonistamiseks. Grafana saab joonistada erinevat tüüpi graafikuid, neid üksikasjalikult kohandada ja mis kõige tähtsam, need diagrammid saab "ühendada" lovelace-UI koduabilisega.
ole inspireeritud и . Artiklites kirjeldatakse üksikasjalikult InfluxDB ja Grafana installimise ja ühendamise protsessi koduabilisega. Keskendun oma konkreetse probleemi lahendamisele.
Nii et kõigepealt alustame loenduri väärtuse lisamist influxDB-s. Tükk koduabilise konfiguratsioonist (selles näites on mul lõbus mitte ainult külma, vaid ka kuuma veega):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldLülitame samade andmete salvestamise koduabilise siseandmebaasi välja, et seda mitte uuesti paisutada:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldLäheme nüüd InfluxDB konsooli ja seadistame oma andmebaasi. Eelkõige peate konfigureerima, kui kaua teatud andmeid salvestatakse. Seda reguleerib nn. säilitamispoliitika – see sarnaneb põhiandmebaasi sees olevate andmebaasidega, kusjuures igal sisemisel andmebaasil on oma sätted. Vaikimisi lisatakse kõik andmed säilitamispoliitikasse nimega autogen, neid andmeid säilitatakse nädal. Soovin, et tunniandmeid säilitataks kuu, nädalaandmeid aasta ja kuuandmeid ei kustutataks üldse. Loome asjakohased säilitamispoliitikad
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 1Nüüd on tegelikult peamine nipp andmete koondamises pideva päringu abil. See on mehhanism, mis käivitab automaatselt päringu määratud ajavahemike järel, koondab selle päringu andmed ja lisab tulemuse uuele väärtusele. Vaatame näidet (kirjutan loetavuse huvides veergu, kuid tegelikult pidin selle käsu ühele reale sisestama)
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)
ENDSee käsk:
- Loob koduabilise andmebaasis pideva päringu nimega cq_water_cold_hourly
- Päring täidetakse iga tund (aeg(1h))
- Päring tõmbab kõik andmed saidilt mõõtmine'a homeassistant.autogen.l (liitrit), sealhulgas külma ja kuuma vee näidud
- Koondandmed rühmitatakse entity_id alusel, mis loob külma ja sooja vee jaoks eraldi väärtused.
- Kuna liitriloendur on iga tunni jooksul monotoonselt kasvav jada, peate võtma maksimaalse väärtuse, nii et liitmise teostab funktsioon max(value)
- Uus väärtus kirjutatakse aadressile homeassistant.month.water_meter_hour, kus kuu on ühekuulise säilitusperioodiga säilitamispoliitika nimi. Lisaks jaotatakse andmed külma ja sooja vee kohta eraldi kirjetesse, millel on vastav entity_id ja väärtus väärtusväljal
Öösel või kui kedagi kodus pole, siis veekulu puudub ja vastavalt sellele pole ka homeassistant.autogen.l-s uusi rekordeid. Väärtuste puudumise vältimiseks tavapäringutes võite kasutada täitmist (eelmine). See sunnib InfluxDB-d kasutama viimase tunni väärtust.
Kahjuks on pideval päringul omapära: täitmisnipp (eelmine) ei tööta ja kirjeid lihtsalt ei teki. Pealegi on see mingi ületamatu probleem, mis . Selle probleemiga tegeleme hiljem ja laseme pidevas päringus täita(eelmine) olla - see ei sega.
Vaatame, mis juhtus (muidugi peate paar tundi ootama):
> 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
Pange tähele, et andmebaasis olevad väärtused on salvestatud UTC-vormingus, seega erineb see loend 3 tunni võrra – InfluxDB väljundis olevad kella 7 väärtused vastavad ülaltoodud graafikute kella 10 väärtustele. Pange tähele ka seda, et kella 2 ja 5 vahel öösel lihtsalt pole kirjeid – see on pideva päringu tunnusjoon.
Nagu näete, on ka koondväärtus monotoonselt kasvav jada, ainult sissekanded on harvemad - kord tunnis. Kuid see pole probleem – saame kirjutada teise päringu, mis eraldab diagrammi jaoks õiged andmed.
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)Ma dešifreerin:
- Andmebaasist homeassistant.month.water_meter_hour tõmbame andmed entity_id='water_meter_cold' jaoks viimase päeva kohta (aeg >= praegu() -24h).
- Nagu mainisin, võivad mõned kirjed puududa järjestuses homeassistant.month.water_meter_hour. Loome need andmed uuesti, käivitades päringu funktsiooniga GROUP BY time(1h). Seekord täidab (eelmine) korralikult, genereerides puuduvad andmed (funktsioon võtab eelmise väärtuse)
- Kõige olulisem selles päringus on erinevuse funktsioon, mis arvutab tunnimärkide erinevuse. Iseenesest see ei tööta ja nõuab liitmisfunktsiooni. Olgu selleks varem kasutatud max().
Täitmise tulemus näeb välja selline
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 72Kella 2-st kuni 5-ni öösel (UTC) tarbimist ei toimunud. Sellest hoolimata tagastab päring tänu funktsioonile fill(previous) sama tarbimisväärtuse ja erinevuse funktsioon lahutab selle väärtuse endast ja saab väljundis 0, mis on tegelikult vajalik.
Ainus asi, mida teha jääb, on graafiku koostamine. Selleks avage Grafana, avage mõni olemasolev (või looge uus) armatuurlaud, looge uus paneel. Diagrammi seaded on järgmised.
Kuvan külma ja sooja vee andmed samal graafikul. Taotlus on täpselt sama, mida eespool kirjeldasin.
Kuva parameetrid seadistatakse järgmiselt. Minu jaoks on see joontega graafik, mis kulgeb sammude kaupa (trepid). Stack parameetrit selgitatakse allpool. Allpool on veel paar kuvamisvalikut, kuid need pole nii huvitavad.
Saadud graafiku lisamiseks koduabilisele peate tegema järgmist.
- välju diagrammi redigeerimisrežiimist. Miskipärast pakutakse õigeid diagrammi jagamise seadeid ainult armatuurlaua lehelt
- Klõpsake diagrammi nime kõrval olevat kolmnurka, valige menüüst jagamine
- Avanevas aknas minge manustamise vahekaardile
- Tühjendage praeguse ajavahemiku märge – me määrame ajavahemiku URL-i kaudu
- Valige vajalik teema. Minu puhul on see kerge
- Kopeerige saadud URL lovelace-UI seadete kaardile
- 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"
Pange tähele, et ajavahemik (viimased 2 päeva) määratakse siin, mitte armatuurlaua seadetes.
Diagramm näeb välja selline. Ma pole viimase 2 päeva jooksul kuuma vett kasutanud, seega joonistatakse ainult külma vee graafik.
Ma ei ole ise otsustanud, milline tabel mulle kõige rohkem meeldib, kas astmeline joon või tõelised tulbad. Seetõttu toon lihtsalt näite igapäevasest tarbimisgraafikust, ainult seekord baarides. Päringud on üles ehitatud samamoodi nagu eespool kirjeldatud. Kuvavalikud on järgmised:
See diagramm näeb välja selline:
Niisiis, virna parameetri kohta. Sellel graafikul on kuuma riba peale joonistatud külma vee riba. Kogukõrgus vastab perioodi külma ja kuuma vee kogutarbimisele.
Kõik näidatud graafikud on dünaamilised. Saate liigutada hiire huvipunkti kohal ja näha konkreetse punkti üksikasju ja väärtust.
Kahjuks ei jäänud see ilma paari kärbseta. Tulpdiagrammil (erinevalt sammujoontega graafikust) ei asu tulba keskpaik keset päeva, vaid kell 00:00. Need. vasak pool riba tõmmatakse eelmise päeva asemele. Seega on laupäeva ja pühapäeva graafikud sinakast tsoonist veidi vasakule joonistatud. Kuni sain aru, kuidas see võita.
Teine probleem on võimetus töötada korrektselt igakuiste intervallidega. Fakt on see, et tunni / päeva / nädala pikkus on fikseeritud, kuid kuu pikkus on iga kord erinev. InfluxDB saab töötada ainult võrdsete intervallidega. Siiani on mu ajudest piisanud, et määrata 30-päevane kindel intervall. Jah, aasta jooksul graafik veidi ujub ja tulbad ei vasta täpselt kuudele. Aga kuna see asi on mulle huvitav just näidikumõõtjana, siis olen sellega rahul.
Ma näen vähemalt kahte lahendust:
- Et saada igakuistes edetabelites skoori ja piirduda iganädalaste edetabelitega. 52 iganädalast baari aastas näevad päris head välja
- Võtke igakuist tarbimist ennast kui meetodit nr 2 ja kasutage grafanat ainult ilusate graafikute jaoks. See on üsna täpne lahendus. Võrdluseks saate isegi eelmise aasta diagramme üle kanda – grafana saab seda teha.
Järeldus
Ma ei tea, miks, aga mulle meeldivad sellised graafikud. Need näitavad, et elu on täies hoos ja kõik muutub. Eile oli palju, täna on vähe, homme on midagi muud. Jääb üle töötada kodumajapidamistega tarbimise teemal. Kuid isegi praeguste isude juures on lihtsalt suur ja arusaamatu arv arvel muutumas juba üsna arusaadavaks tarbimispildiks.
Vaatamata ligi 20-aastasele programmeerijakarjäärile ma andmebaasidega praktiliselt ei ristunud. Seetõttu tundus välise andmebaasi installimine midagi nii ebamäärast ja arusaamatut. Kõik on muutunud - selgus, et sobiva tööriista kruvimine käib paari klõpsuga ja spetsiaalse tööriistaga läheb joonistamine veidi lihtsamaks.
Pealkirjas mainisin elektritarbimist. Kahjuks ei saa ma hetkel ühtegi graafikut esitada. Üks SDM120 arvesti on surnud ja teine on Modbusi kaudu lollakas. See aga ei mõjuta kuidagi selle artikli teemat – graafikud ehitatakse üles samamoodi nagu vee puhul.
Selles artiklis olen andnud need lähenemisviisid, mida olen ise proovinud. Kindlasti on andmete kogumise ja visualiseerimise korraldamiseks ka teisi viise, millest ma ei tea. Rääkige mulle sellest kommentaarides, olen väga huvitatud. Olen rahul konstruktiivse kriitika ja uute ideedega. Loodan, et ülaltoodud materjal on ka kellelegi abiks.
Allikas: www.habr.com