Svaki put kad dobijem uplatu za struju i vodu, pitam se - troši li moja obitelj stvarno punoooooooooooooo mnogo? Pa da, postoji podno grijanje i bojler u kupaonici, ali ne rade stalno kao vatrogasci. Čini se da štedimo i vodu (iako volimo i prskanje u kupaonici). Već sam prije nekoliko godina и u pametnu kuću, ali tu su stvari zapele. Ruke su se tek sada dohvatile analize potrošnje, o čemu je, zapravo, i riječ u ovom članku.
Nedavno sam se prebacio na Home Assistant kao svoj sustav pametnog doma. Jedan od razloga bila je upravo mogućnost organiziranja prikupljanja velike količine podataka uz mogućnost prikladne konstrukcije raznih vrsta grafikona.
Informacije opisane u ovom članku nisu nove, sve te stvari pod različitim umacima već su opisane na internetu. Ali svaki članak, u pravilu, opisuje samo jedan pristup ili aspekt. Morao sam usporediti sve te pristupe i sam odabrati najprikladniji. Članak još uvijek ne daje iscrpne informacije o prikupljanju podataka, već je svojevrsni sažetak kako sam to napravio. Stoga su konstruktivne kritike i prijedlozi za poboljšanje dobrodošli.
Formuliranje problema
Dakle, cilj današnje vježbe je dobiti lijepe grafikone potrošnje vode i struje:
- Svaki sat 2 dana
- Dnevno 2 tjedna
- (neobavezno) tjedno i mjesečno
U tome postoje neke poteškoće:
- Standardne komponente grafikona obično su prilično loše. U najboljem slučaju, možete izgraditi linijski grafikon po točkama.
Ako dobro tražite, možete pronaći komponente trećih strana koje proširuju mogućnosti standardnog grafikona. Za kućnog pomoćnika, u principu, dobra i lijepa komponenta , ali je i donekle ograničen:
- Teško je postaviti parametre trakastog grafikona u velikim intervalima (širina trake je postavljena u djelićima sata, što znači da će intervali duži od jednog sata biti postavljeni u djelićima)
- Ne možete dodati različite entitete na jedan grafikon (na primjer, temperaturu i vlažnost, ili kombinirati stupčasti grafikon s linijom)
- Ne samo da kućni pomoćnik standardno koristi najprimitivniju SQLite bazu (a ja, majstor, nisam savladao instalaciju MySQL-a ili Postgresa), podaci nisu pohranjeni na najoptimalniji način. Tako se, primjerice, svakom promjenom svakog pa i najmanjeg digitalnog parametra parametra u bazu podataka upisuje 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 dosta senzora (senzori temperature u svakoj sobi, brojila za vodu i struju), a neki generiraju i dosta podataka. Na primjer, samo mjerač električne energije SDM220 generira desetak vrijednosti svakih 10-15 sekundi, a ja bih želio instalirati takvih brojila 8. A tu je i cijela hrpa parametara koji se izračunavaju na temelju drugih senzora. Da. sve te vrijednosti mogu lako napuhati bazu podataka za 100-200 MB dnevno. Za tjedan dana sustav će se jedva bacati i okretati, a za mjesec dana flash pogon će umrijeti (u slučaju tipične instalacije kućnog pomoćnika na malinu PI), a ne može biti govora o pohranjivanju podataka cijelu godinu.
- Ako imate sreće, vaše brojilo može samo brojati potrošnju. U svakom trenutku možete kontaktirati brojilo i pitati koliko je sati akumulirane vrijednosti potrošnje. U pravilu sva brojila električne energije koja imaju digitalno sučelje (RS232/RS485/Modbus/Zigbee) pružaju takvu mogućnost.
Još gore, ako uređaj može jednostavno izmjeriti neki trenutni parametar (na primjer, trenutnu snagu ili struju), ili jednostavno generirati impulse svakih X vat-sati ili litara. Zatim morate razmisliti kako i s čim to integrirati i gdje akumulirati vrijednost. Postoji rizik da iz bilo kojeg razloga propustite sljedeće izvješće, a točnost sustava u cjelini postavlja pitanja. Sve to, naravno, možete povjeriti pametnom kućnom sustavu poput kućnog asistenta, ali nitko nije otkazao točku o broju unosa u bazi podataka, a prozivanje senzora više od jednom u sekundi neće raditi (ograničenje arhitektura kućnog pomoćnika).
Pristup 1
Prvo, da vidimo koji je kućni pomoćnik dostupan odmah. Mjerenje potrošnje kroz razdoblje vrlo je tražena funkcionalnost. Naravno, davno je implementiran kao specijalizirana komponenta - utility_meter.
Bit komponente je da pokreće varijablu current_accumulated_value unutra i resetira je nakon određenog perioda (sat/tjedan/mjesec). Sama komponenta prati dolaznu varijablu (vrijednost neke vrste senzora), pretplaćuje se na promjene u samoj vrijednosti - samo dobivate gotov rezultat. Ova stvar je opisana u samo nekoliko redaka u konfiguracijskoj datoteci
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Ovdje sensor.water_meter_cold je trenutna vrijednost mjerača u litrama koju dobivam od strane mqtt. Dizajn stvara 2 nova senzora water_cold_hour_um i water_cold_day_um, koji skupljaju očitanja po satu i dnevno, vraćajući ih na nulu nakon određenog razdoblja. Ovdje je grafikon satne baterije za pola dana.
Kod satnog i dnevnog grafikona za lovelace-UI izgleda ovako:
- 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
Zapravo, u ovom algoritmu leži problem ovog pristupa. Kao što sam već napomenuo, za svaku ulaznu vrijednost (trenutno očitanje brojila za svaku sljedeću litru) u bazi se generira 1kb zapisa. Svaki komunalni mjerač također generira novu vrijednost, koja se također dodaje osnovici. Ako želim prikupiti satna/dnevna/tjedna/mjesečna očitanja, da, za nekoliko vodostaja, pa čak i dodati paket električnih brojila, to će biti puno podataka. Pa, točnije, nema puno podataka, ali budući da kućni pomoćnik upisuje hrpu nepotrebnih informacija u bazu podataka, veličina baze će rasti skokovito. Čak se bojim procijeniti veličinu baze za tjedne i mjesečne grafikone.
Osim toga, samo mjerač komunalnih usluga ne rješava problem. Dijagram mjerača komunalnih usluga monotono je rastuća funkcija koja se svakog sata vraća na 0. Potreban nam je i jednostavan raspored potrošnje, koliko je litara pojedeno tijekom razdoblja. Standardna komponenta grafikona povijesti to ne čini, ali vanjska komponenta minigrafa može nam pomoći.
Ovo je kod 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'Uz standardne postavke kao što su naziv senzora, vrsta grafikona, boja (nije mi se svidjela standardna narančasta), ovdje je važno napomenuti 3 postavke:
- group_by:hour - grafikon će biti generiran sa stupcima usklađenim s početkom sata
- bodovi_po_satu: 1 - jedna traka po satu
- I što je najvažnije, aggregate_func: max treba uzeti najveću vrijednost unutar svakog sata. Upravo ovaj parametar pretvara grafikon zubaca pile u stupce.
Ne obraćajte pozornost na red stupaca s lijeve strane - to je standardno ponašanje komponente ako nema podataka. Ali nije bilo podataka - samo sam uključio prikupljanje podataka pomoću mjerača komunalnih usluga prije nekoliko sati samo za potrebe ovog članka (moj trenutni pristup opisat ću malo niže).
Ovom sam slikom želio pokazati da ponekad prikaz podataka uopće funkcionira, a stupci stvarno odražavaju točne vrijednosti. Ali to nije sve. Iz nekog razloga označeni stupac za razdoblje od 11 do 12 sati prikazuje 19 litara, iako na zubatom grafu malo više za isto razdoblje s istog senzora vidimo potrošnju od 62 litre. Ili je buba ili su ruke krive. Ali i dalje mi nije jasno zašto su podaci s desne strane pukli - tamo je potrošnja bila normalna, što je vidljivo i iz zubatog grafikona.
Općenito, nisam uspio postići vjerodostojnost ovog pristupa - grafikon gotovo uvijek pokazuje neku vrstu hereze.
Sličan kod 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'
Imajte na umu da je parametar group_by postavljen na interval, a parametar points_per_hour upravlja svime. I to je još jedan problem s ovom komponentom - points_per_hour dobro funkcionira na grafikonima od sat vremena ili manje, ali odvratno na većim intervalima. Da bih dobio jedan stupac u jednom danu, morao sam unijeti vrijednost 1/24=0.04166666. Ne govorim o tjednim i mjesečnim grafikonima.
Pristup 2
Dok sam još smišljao kućnog pomoćnika, naišao sam na ovaj video:
Drug prikuplja podatke o potrošnji iz nekoliko vrsta Xiaomi utičnica. Njegov zadatak je malo jednostavniji - samo prikazati vrijednost potrošnje za danas, jučer i za mjesec. Nisu potrebni grafikoni.
Ostavimo po strani argumente o ručnoj integraciji trenutnih vrijednosti snage - već sam pisao o "točnosti" ovog pristupa gore. Nije jasno zašto nije upotrijebio akumulirane vrijednosti potrošnje, koje već prikuplja ista poslovnica. Po mom mišljenju, integracija unutar komada željeza će raditi bolje.
Iz videa ćemo preuzeti ideju ručnog brojanja potrošnje za razdoblje. Za čovjeka se uzimaju u obzir samo vrijednosti za danas i za jučer, ali mi ćemo ići dalje i pokušati nacrtati grafikon. Suština predložene metode u mom slučaju je sljedeća.
Kreirat ćemo varijablu value_at_the_beginning_of_hour, u koju ćemo upisati trenutna očitanja brojača
Prema mjeraču vremena na kraju sata (ili na početku sljedećeg) izračunavamo razliku između trenutnog očitanja i onog pohranjenog na početku sata. Ova razlika će biti potrošnja za trenutni sat - mi ćemo spremiti vrijednost na senzor, au budućnosti ćemo izgraditi grafikon na temelju te vrijednosti.
Također morate "resetirati" varijablu value_at_beginning_of_hour tako da tamo upišete trenutnu vrijednost brojača.
Sve se to može učiniti dobro ... uz pomoć samog kućnog pomoćnika.
Morat ćete napisati malo više koda nego u prethodnom pristupu. Počnimo s ovim "varijablama". Izvan kutije nemamo "varijabilni" entitet, ali možete koristiti usluge mqtt brokera. Tamo ćemo poslati vrijednosti s oznakom retain=true - to će spremiti vrijednost unutar brokera i može se izvući u bilo kojem trenutku, čak i kada se kućni pomoćnik ponovno pokrene. Odjednom sam napravio satne i dnevne brojače.
- 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: lSva se čarolija događa u automatizaciji, koja radi svaki sat, odnosno svaku 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: trueObje automatizacije rade 2 stvari:
- Izračunajte vrijednost po intervalu kao razliku između početne i krajnje vrijednosti
- Ažurirajte osnovnu vrijednost za sljedeći interval
Konstrukcija grafova u ovom slučaju rješava se uobičajenim povijesnim grafom:
- 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 ovako:
U principu, to je već ono što vam treba. Prednost ove metode je što se podaci generiraju jednom u intervalu. Oni. ukupno 24 unosa dnevno za satni grafikon.
Nažalost, to još uvijek ne rješava opći problem rastuće baze. Ako želim mjesečni grafikon potrošnje, morat ću pohraniti podatke najmanje godinu dana. A budući da kućni pomoćnik pruža samo jednu postavku trajanja pohrane za cijelu bazu podataka, to znači da će SVI podaci u sustavu morati biti pohranjeni cijelu godinu. Primjerice, u godini dana potrošim 200 kubika vode, što znači 200000 unosa u bazu. A ako uzmete u obzir druge senzore, tada brojka postaje općenito nepristojna.
Pristup 3
Srećom, pametni ljudi već su riješili ovaj problem pisanjem baze podataka InfluxDB. Ova baza podataka je posebno optimizirana za pohranjivanje podataka temeljenih na vremenu i idealna je za pohranjivanje vrijednosti različitih senzora. Sustav također nudi upitni jezik nalik SQL-u koji vam omogućuje izdvajanje vrijednosti iz baze podataka i njihovo agregiranje na različite načine. Konačno, različiti podaci mogu biti pohranjeni za različita vremena. Na primjer, očitanja koja se često mijenjaju kao što su temperatura ili vlažnost mogu se pohraniti samo nekoliko tjedana, dok se dnevna očitanja potrošnje vode mogu pohraniti cijelu godinu.
Osim InfluxDB-a, pametni su ljudi izmislili i Grafanu, sustav za crtanje grafova iz podataka iz InfluxDB-a. Grafana može crtati različite vrste grafikona, detaljno ih prilagođavati, a što je najvažnije, ti se grafikoni mogu “ubaciti” u kućni asistent lovelace-UI.
biti nadahnut и . U člancima je detaljno opisan proces instaliranja i povezivanja InfluxDB-a i Grafana s kućnim pomoćnikom. Usredotočit ću se na rješavanje svog specifičnog problema.
Dakle, prije svega, počnimo dodavati vrijednost brojača u influxDB. Dio konfiguracije kućnog pomoćnika (u ovom primjeru ću se zabaviti ne samo hladnom, već i toplom vodom):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldIsključimo spremanje istih podataka u internu bazu kućnog pomoćnika kako je ne bismo ponovno napuhali:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldIdemo sada na InfluxDB konzolu i postavimo našu bazu podataka. Konkretno, trebate konfigurirati koliko će dugo određeni podaci biti pohranjeni. To je regulirano tzv. politika zadržavanja - ovo je slično bazama podataka unutar glavne baze podataka, pri čemu svaka interna baza podataka ima vlastite postavke. Prema zadanim postavkama, svi se podaci dodaju u politiku zadržavanja koja se zove autogen, ti će se podaci pohranjivati tjedan dana. Želio bih da se podaci po satu pohranjuju za mjesec dana, podaci po tjednu za godinu dana, a podaci po mjesecu da se nikad ne brišu. Stvorit ćemo odgovarajuće politike zadržavanja
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 1Sada, zapravo, glavni trik je prikupljanje podataka pomoću kontinuiranog upita. Ovo je mehanizam koji automatski pokreće upit u određenim intervalima, agregira podatke za ovaj upit i dodaje rezultat novoj vrijednosti. Pogledajmo primjer (pišem u stupac radi čitljivosti, ali u stvarnosti sam ovu naredbu morao unijeti u jednom retku)
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)
ENDOva naredba:
- Stvara kontinuirani upit pod nazivom cq_water_cold_hourly u bazi podataka homeassistant
- Upit će se izvršavati svaki sat (vrijeme (1h))
- Upit će izvući sve podatke iz izmjere'a homeassistant.autogen.l (litre), uključujući očitanja hladne i tople vode
- Skupni podaci bit će grupirani prema entitetu_id, što će stvoriti zasebne vrijednosti za hladnu i toplu vodu.
- Budući da je brojač litara monotono rastući niz unutar svakog sata, morat ćete uzeti maksimalnu vrijednost, tako da će agregaciju izvršiti funkcija max(value)
- Nova vrijednost bit će zapisana u homeassistant.month.water_meter_hour gdje je mjesec naziv pravila zadržavanja s razdobljem zadržavanja od mjesec dana. Štoviše, podaci o hladnoj i toploj vodi bit će raspršeni u zasebne zapise s odgovarajućim entity_id i vrijednošću u polju vrijednosti
Noću ili kada nema nikoga kod kuće, nema potrošnje vode, a shodno tome nema ni novih zapisa u homeassistant.autogen.l. Kako biste izbjegli nedostajanje vrijednosti u normalnim upitima, možete koristiti fill(previous). Ovo će prisiliti InfluxDB da koristi vrijednost prošlog sata.
Nažalost, kontinuirani upit ima jednu osobitost: trik s popunom (prethodnim) ne radi i zapisi se jednostavno ne stvaraju. Štoviše, ovo je neka vrsta nepremostivog problema, koji . Kasnije ćemo se pozabaviti ovim problemom, a neka fill(previous) in continuous query bude tu - ne smeta.
Provjerimo što se dogodilo (naravno, morate prič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
Imajte na umu da su vrijednosti u bazi podataka pohranjene u UTC-u, tako da se ovaj popis razlikuje za 3 sata - vrijednosti u 7 ujutro u izlazu InfluxDB-a odgovaraju vrijednostima u 10 sati u gornjim grafikonima. Također imajte na umu da između 2 i 5 ujutro jednostavno nema zapisa - to je sama značajka kontinuiranog upita.
Kao što vidite, agregirana vrijednost je također monotono rastući niz, samo su unosi rjeđi - jednom na sat. Ali to nije problem - možemo napisati još jedan upit koji će izdvojiti točne 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)Ja ću dešifrirati:
- Iz baze podataka homeassistant.month.water_meter_hour izvući ćemo podatke za entity_id='water_meter_cold' za zadnji dan (vrijeme >= sada() -24h).
- Kao što sam spomenuo, neki unosi mogu nedostajati u nizu homeassistant.month.water_meter_hour. Ponovno ćemo generirati ove podatke pokretanjem upita s GROUP BY time(1h). Ovaj put, fill(previous) će ispravno raditi, generirajući podatke koji nedostaju (funkcija će uzeti prethodnu vrijednost)
- Najvažnija stvar u ovom upitu je funkcija razlike, koja će izračunati razliku između oznaka sata. Sam po sebi ne radi i zahtijeva funkciju agregacije. Neka ovo bude max() korišten prije.
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 ujutro do 5 ujutro (UTC) nije bilo potrošnje. Unatoč tome, upit će vratiti istu vrijednost potrošnje zahvaljujući fill(previous), a funkcija razlike će tu vrijednost oduzeti od sebe i dobiti 0 na izlazu, što je zapravo i potrebno.
Jedino što preostaje je izgraditi grafikon. Da biste to učinili, otvorite Grafanu, otvorite neku postojeću (ili izradite novu) nadzornu ploču, napravite novi panel. Postavke grafikona bit će sljedeće.
Prikazat ću podatke o hladnoj i toploj vodi na istom grafikonu. Zahtjev je potpuno isti kao što sam gore opisao.
Parametri prikaza postavljaju se na sljedeći način. Za mene će to biti grafikon s linijama (linijama), koji ide u koracima (stepenicama). Parametar Stack bit će objašnjen u nastavku. Postoji još nekoliko opcija prikaza u nastavku, ali nisu toliko zanimljive.
Da biste dodali dobiveni grafikon kućnom pomoćniku, trebate:
- izađite iz moda za uređivanje grafikona. Iz nekog razloga, ispravne postavke dijeljenja grafikona nude se samo na stranici nadzorne ploče
- Kliknite na trokut pored naziva grafikona, odaberite dijeljenje iz izbornika
- U prozoru koji se otvori idite na karticu za ugradnju
- Poništite odabir trenutnog vremenskog raspona - postavit ćemo vremenski raspon putem URL-a
- Odaberite traženu temu. U mom slučaju to je svjetlo
- Kopirajte dobiveni URL na karticu postavki korisničkog sučelja 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"
Imajte na umu da je vremenski raspon (zadnja 2 dana) postavljen ovdje, a ne u postavkama nadzorne ploče.
Grafikon izgleda ovako. Zadnja 2 dana nisam koristio toplu vodu, pa se crta samo graf hladne vode.
Za sebe još nisam odlučio koji mi se grafikon najviše sviđa, stepenasta linija ili pravi stupci. Stoga ću samo dati primjer dnevnog rasporeda konzumacije, samo ovaj put u barovima. Upiti se izrađuju na isti način kao što je gore opisano. Opcije prikaza su:
Ovaj grafikon izgleda ovako:
Dakle, o parametru Stack. Na ovom grafikonu, šipka hladne vode nacrtana je na vrhu trake tople vode. Ukupna visina odgovara ukupnoj potrošnji hladne i tople vode za razdoblje.
Svi prikazani grafikoni su dinamički. Možete pomicati miša preko točke interesa i vidjeti detalje i vrijednost na određenoj točki.
Nažalost, nije prošlo bez par zapleta. Na stupčastom dijagramu (za razliku od grafikona sa stepenastim linijama), sredina stupca nije u sredini dana, već u 00:00. Oni. lijeva polovica trake nacrtana je umjesto prethodnog dana. Dakle, grafikoni za subotu i nedjelju nacrtani su malo lijevo od plavkaste zone. Sve dok nisam smislio kako ga osvojiti.
Drugi problem je nemogućnost ispravnog rada s mjesečnim intervalima. Činjenica je da je duljina sata / dana / tjedna fiksna, ali je duljina mjeseca svaki put drugačija. InfluxDB može raditi samo s jednakim intervalima. Do sada mi je pamet bila dovoljna da postavim fiksni interval od 30 dana. Da, grafikon će malo lebdjeti tijekom godine i stupci neće točno odgovarati mjesecima. Ali pošto mi je ova stvar zanimljiva samo kao mjerač prikaza, ok sam s ovim.
Vidim barem dva rješenja:
- Da postignete bodove na mjesečnim ljestvicama i ograničite se na tjedne. 52 tjedne trake u godini izgledaju prilično dobro
- Samu mjesečnu potrošnju smatrajte metodom broj 2, a grafanu koristite samo za lijepe grafikone. To je prilično točno rješenje. Možete čak i prekriti grafikone za prošlu godinu za usporedbu - grafana to može.
Zaključak
Ne znam zašto, ali volim ovakve karte. Pokazuju da je život u punom jeku i da se sve mijenja. Jučer je bilo puno, danas malo, sutra će biti nešto drugo. Ostalo je raditi s kućanstvima na temu potrošnje. Ali čak i uz trenutne apetite, samo velika i neshvatljiva brojka na računu već se pretvara u prilično razumljivu sliku potrošnje.
Unatoč mojoj gotovo 20-godišnjoj karijeri programera, praktički se nisam bavio bazama podataka. Stoga je instaliranje vanjske baze podataka izgledalo kao nešto tako nejasno i neshvatljivo. Sve se promijenilo - pokazalo se da se uvrtanje odgovarajućeg alata obavlja u par klikova, a sa specijaliziranim alatom posao iscrtavanja postaje malo lakši.
U naslovu sam naveo potrošnju električne energije. Nažalost, trenutno ne mogu dati nikakav grafikon. Jedan SDM120 mjerač je mrtav, a drugi je neispravan kada mu se pristupa putem Modbusa. Međutim, to ni na koji način ne utječe na temu ovog članka - grafikoni će biti izgrađeni na isti način kao i za vodu.
U ovom članku dao sam one pristupe koje sam sam isprobao. Sigurno postoje neki drugi načini organiziranja prikupljanja i vizualizacije podataka za koje ja ne znam. Recite mi o tome u komentarima, jako će me zanimati. Bit će mi drago konstruktivnim kritikama i novim idejama. Nadam se da će i gornji materijal nekome pomoći.
Izvor: www.habr.com