Svaki put kada dobijem uplatu za struju i vodu, pitam se – da li moja porodica zaista toliko troši? Pa da, u kupatilu ima grijani pod i bojler, ali oni ne rade stalno kao vatrogasci. Čini se da štedimo i vodu (iako volimo i prskanje u kupatilu). Već prije nekoliko godina и u pametnu kuću, ali tu su stvari zapele. Ruke su tek sada došle do analize potrošnje, o čemu je, zapravo, ovaj članak.
Nedavno sam prešao na Home Assistant kao svoj sistem pametnog doma. Jedan od razloga bila je upravo mogućnost organizovanja prikupljanja velike količine podataka uz mogućnost pogodne konstrukcije raznih vrsta grafova.
Informacije opisane u ovom članku nisu nove, sve su te stvari pod različitim umacima već opisane na internetu. Ali svaki članak, po pravilu, opisuje samo jedan pristup ili aspekt. Morao sam uporediti sve ove pristupe i sam odabrati najprikladniji. Članak još uvijek ne pruža iscrpne informacije o prikupljanju podataka, već je svojevrsni sažetak kako sam to učinio. Stoga su konstruktivna kritika i prijedlozi za poboljšanje dobrodošli.
Izjava o problemu
Dakle, cilj današnje vježbe je da dobijete lijepe grafikone potrošnje vode i struje:
- Po satu 2 dana
- Dnevno tokom 2 sedmice
- (opciono) sedmično i mjesečno
U tome postoje određene poteškoće:
- Standardne komponente grafikona obično su prilično loše. U najboljem slučaju, možete napraviti linijski grafikon po tačkama.
Ako dobro pretražujete, možete pronaći komponente treće strane koje proširuju mogućnosti standardnog grafikona. Za kućnog pomoćnika, u principu, dobra i lijepa komponenta , ali je također donekle ograničen:
- Teško je postaviti parametre trakastog grafikona u velikim intervalima (širina trake se postavlja u dijelovima sata, što znači da će intervali duži od jednog sata biti postavljeni u razlomcima)
- Ne možete dodati različite entitete na jedan grafikon (na primjer, temperaturu i vlažnost ili kombinirati trakasti grafikon s linijom)
- Ne samo da kućni pomoćnik podrazumevano koristi najprimitivniju SQLite bazu podataka (a ja, majstor, nisam savladao instalaciju MySQL-a ili Postgresa), podaci se ne pohranjuju na najoptimalniji način. Tako, na primjer, sa svakom promjenom svakog čak i najmanjeg digitalnog parametra parametra, ogroman json veličine oko kilobajta upisuje se u bazu podataka
{"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 (senzora temperature u svakoj prostoriji, vodomjera i struje), a neki također generiraju dosta podataka. Na primjer, samo strujomjer SDM220 generiše desetak vrijednosti svakih 10-15 sekundi, a ja bih želio da instaliram 8 takvih brojila. A tu je i gomila parametara koji se izračunavaju na osnovu drugih senzora. To. sve ove vrijednosti mogu lako naduvati bazu podataka za 100-200 MB dnevno. Za nedelju dana sistem će se jedva baciti i okrenuti, a za mesec dana fleš disk će umreti (u slučaju tipične instalacije kućnog asistenta na raspberry PI), a o čuvanju podataka za celu godinu ne može biti govora .
- Ako imate sreće, vaš mjerač može sam izbrojati potrošnju. Možete kontaktirati brojilo u bilo koje vrijeme i pitati koliko je sati akumulirana vrijednost potrošnje. Po pravilu, sva brojila električne energije koja imaju digitalni interfejs (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 o tome kako i sa čime to integrirati i gdje akumulirati vrijednost. Postoji rizik da iz bilo kog razloga propustite sledeći izveštaj, a tačnost sistema u celini postavlja pitanja. Sve ovo možete, naravno, povjeriti sistemu pametne kuće poput kućnog asistenta, ali niko nije poništio tačku o broju unosa u bazu podataka, a senzori za prozivanje više od jednom u sekundi neće raditi (ograničenje doma pomoćna arhitektura).
Pristup 1
Prvo, da vidimo koji kućni asistent je isporučen iz kutije. Mjerenje potrošnje u određenom periodu vrlo je tražena funkcionalnost. Naravno, implementiran je davno kao specijalizirana komponenta - utility_meter.
Suština komponente je da pokreće varijablu current_accumulated_value unutra i resetuje je nakon određenog perioda (sat/sedmica/mjesec). Sama komponenta prati dolaznu varijablu (vrijednost neke vrste senzora), pretplaćuje se na promjene same vrijednosti - samo dobijete 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 senzor.water_meter_cold je trenutna vrijednost mjerača u litrima koju dobijem od mqtt. Dizajn kreira 2 nova senzora water_cold_hour_um i water_cold_day_um, koji akumuliraju satna i dnevna očitanja, vraćajući ih na nulu nakon određenog perioda. Evo grafikona satne baterije za pola dana.
Satni i dnevni grafikon kod 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ć spomenuo, za svaku dolaznu vrijednost (trenutna očitavanja brojila za svaki sljedeći litar) generira se 1 kb zapisa u bazi podataka. Svaki mjerač komunalnih usluga također generiše novu vrijednost, koja se također dodaje bazi. Ako želim da prikupim satna/dnevna/tjednička/mjesečna očitanja, da, za nekoliko vodostaja, pa čak i da dodam paket električnih brojila, to će biti mnogo podataka. Pa, preciznije, nema puno podataka, ali budući da kućni pomoćnik upisuje gomilu nepotrebnih informacija u bazu, veličina baze će rasti u skokovima i granicama. Čak se bojim i procijeniti veličinu baze za nedjeljne i mjesečne grafikone.
Osim toga, sam mjerač komunalnih usluga ne rješava problem. Grafikon brojila je monotono rastuća funkcija koja se svakog sata vraća na 0. Potreban nam je i raspored potrošnje koji je prilagođen korisniku, koliko je litara pojedeno tokom perioda. Standardna komponenta historijskog grafa to ne radi, ali vanjska komponenta mini-grafske kartice 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'Pored standardnih postavki kao što su naziv senzora, tip grafikona, boja (nije mi se svidjela standardna narandžasta), ovdje je važno napomenuti 3 postavke:
- group_by:hour - grafikon će biti generiran sa stupcima poravnatim na početku sata
- bodova_po_satu: 1 - jedan bar na sat
- I što je najvažnije, aggregate_func: max je uzeti maksimalnu vrijednost unutar svakog sata. Upravo ovaj parametar pretvara dijagram pile u šipke.
Ne obraćajte pažnju na red kolona na lijevoj strani - ovo je standardno ponašanje komponente ako nema podataka. Ali nije bilo podataka - samo sam prije nekoliko sati uključio prikupljanje podataka pomoću mjerača komunalnih usluga samo radi ovog članka (opisat ću svoj trenutni pristup malo niže).
Na ovoj slici sam htio pokazati da ponekad prikaz podataka čak i radi, a trake zaista odražavaju ispravne vrijednosti. Ali to nije sve. Iz nekog razloga, istaknuta kolona za period od 11 do 12 sati prikazuje 19 litara, iako na zupčastom grafikonu malo više za isti period od istog senzora vidimo potrošnju od 62 litre. Ili buba ili su ruke krive. Ali još uvijek ne razumijem zašto su se podaci na desnoj strani prekinuli - potrošnja je tamo bila normalna, što je vidljivo i sa zupčastog grafikona.
Generalno, nisam uspeo da postignem verodostojnost ovog pristupa - grafikon skoro uvek pokazuje neku vrstu jeresi.
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 point_per_hour upravlja svime. I ovo je još jedan problem sa ovom komponentom - point_per_hour dobro radi na grafikonima od sat vremena ili manje, ali odvratno na većim intervalima. Dakle, da bih dobio jednu kolonu u jednom danu, morao sam unijeti vrijednost 1/24=0.04166666. Ne govorim o sedmičnim 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 prikažite 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 "tačnosti" ovog pristupa iznad. Nije jasno zašto nije iskoristio akumulirane vrijednosti potrošnje koje već prikuplja ista trgovina. Po mom mišljenju, integracija unutar komada željeza će funkcionirati bolje.
Iz videa ćemo preuzeti ideju ručnog brojanja potrošnje za određeni period. Za muškarca se razmatraju samo vrijednosti za danas i za jučer, ali idemo dalje i pokušati nacrtati grafikon. Suština predložene metode u mom slučaju je sljedeća.
Kreiraćemo varijablu value_at_the_beginning_of_hour, u koju ćemo upisati trenutna očitanja brojača
Prema tajmeru 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 tekući sat - vrijednost ćemo sačuvati na senzoru, a u budućnosti ćemo na osnovu te vrijednosti napraviti grafikon.
Također morate “resetirati” varijablu value_at_beginning_of_hour tako što ćete tamo upisati trenutnu vrijednost brojača.
Sve se to može dobro uraditi ... uz pomoć samog kućnog pomoćnika.
Morat ćete napisati malo više koda nego u prethodnom pristupu. Počnimo sa ovim "varijablama". Izvan kutije, nemamo „promjenjivi“ entitet, ali možete koristiti usluge mqtt brokera. Tamo ćemo poslati vrijednosti sa zastavicom retain=true - ovo će sačuvati vrijednost unutar brokera i može se izvući u bilo koje vrijeme, čak i kada se kućni pomoćnik ponovo pokrene. Napravio sam satne i dnevne brojače odjednom.
- 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 magija se dešava 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 historijskim 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_dayTo izgleda ovako:
U principu, ovo je već ono što vam treba. Prednost ove metode je što se podaci generišu jednom u intervalu. One. ukupno 24 unosa dnevno za satni grafikon.
Nažalost, ovo još uvijek ne rješava opći problem rastuće baze. Ako želim mjesečni grafikon potrošnje, morat ću čuvati podatke najmanje godinu dana. A budući da kućni asistent pruža samo jednu postavku trajanja skladištenja za cijelu bazu podataka, to znači da će SVI podaci u sistemu morati biti pohranjeni cijelu godinu. Na primjer, za godinu dana potrošim 200 kubnih metara vode, što znači 200000 unosa u bazu podataka. A ako uzmete u obzir druge senzore, onda cifra postaje općenito nepristojna.
Pristup 3
Srećom, pametni ljudi su već riješili ovaj problem pisanjem InfluxDB baze podataka. Ova baza podataka je posebno optimizirana za pohranjivanje podataka zasnovanih na vremenu i idealna je za pohranjivanje vrijednosti različitih senzora. Sistem također nudi jezik upita sličan SQL-u koji vam omogućava da izvučete vrijednosti iz baze podataka i zatim ih agregirate na različite načine. Konačno, različiti podaci se mogu pohraniti za različita vremena. Na primjer, očitanja koja se često mijenjaju kao što su temperatura ili vlažnost mogu se pohraniti samo nekoliko sedmica, dok se dnevna očitavanja potrošnje vode mogu čuvati cijelu godinu.
Osim InfluxDB-a, pametni ljudi su izmislili i Grafanu, sistem za crtanje grafova iz podataka iz InfluxDB-a. Grafana može crtati različite tipove grafikona, prilagođavati ih do detalja, i, što je najvažnije, ove karte se mogu "priključiti" u lovelace-UI kućni asistent.
budite inspirisani и . Članci detaljno opisuju proces instaliranja i povezivanja InfluxDB-a i Grafane sa kućnim pomoćnikom. Fokusiraću se na rješavanje svog specifičnog problema.
Dakle, prije svega, počnimo sa dodavanjem vrijednosti brojača u influxDB. Komad konfiguracije kućnog pomoćnika (u ovom primjeru zabavljat ću se 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 pohranjivanje istih podataka u internu bazu podataka kućnog pomoćnika kako ih ne bismo još jednom naduvali:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldIdemo sada na InfluxDB konzolu i podesimo našu bazu podataka. Konkretno, morate konfigurirati koliko dugo će se određeni podaci čuvati. To je regulisano tzv. politika zadržavanja - ovo je slično bazama podataka unutar glavne baze podataka, pri čemu svaka interna baza podataka ima svoje postavke. Prema zadanim postavkama, svi podaci se dodaju u politiku zadržavanja koja se zove autogen, ovi podaci će biti pohranjeni tjedan dana. Želio bih da se podaci po satu pohranjuju mjesec dana, sedmični podaci za godinu dana, a mjesečni podaci da se uopće ne brišu. Stvorit ćemo odgovarajuću politiku 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 agregacija 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 redu)
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 komanda:
- Kreira kontinuirani upit pod nazivom cq_water_cold_hourly u bazi podataka homeassistant
- Upit će se izvršavati svakih sat vremena (vrijeme(1h))
- Upit će izvući sve podatke iz mjerenja'a homeassistant.autogen.l (litara), uključujući očitanja hladne i tople vode
- Agregirani podaci će biti grupisani prema entity_id, koji će kreirati odvojene 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 se agregacija izvršiti pomoću funkcije max(value)
- Nova vrijednost će biti upisana u homeassistant.month.water_meter_hour gdje je mjesec naziv politike zadržavanja s periodom zadržavanja od jednog mjeseca. Štaviše, podaci o hladnoj i toploj vodi će biti razbacani u zasebne zapise sa odgovarajućim entity_id i vrijednošću u polju vrijednosti
Noću ili kada nikog nema kod kuće, nema potrošnje vode, a samim tim nema ni novih evidencija u homeassistant.autogen.l. Da biste izbjegli nedostajuće vrijednosti u normalnim upitima, možete koristiti fill(previous). Ovo će prisiliti InfluxDB da koristi vrijednost prošlog sata.
Nažalost, kontinuirani upit ima posebnost: trik za popunjavanje (prethodni) ne radi i zapisi se jednostavno ne kreiraju. Štaviše, ovo je neka vrsta nepremostivog problema, koji . Kasnije ćemo se pozabaviti ovim problemom i neka bude tu fill(previous) u kontinuiranom upitu - to ne ometa.
Hajde da proverimo šta se desilo (naravno, treba sačekati par 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 ova lista razlikuje za 3 sata - vrijednosti u 7 ujutro u InfluxDB izlazu odgovaraju vrijednostima od 10 sati u gornjim grafikonima. Takođe imajte na umu da između 2 i 5 ujutro jednostavno nema zapisa - to je sama karakteristika kontinuiranog upita.
Kao što vidite, agregirana vrijednost je također monotono rastuća sekvenca, samo što su unosi rjeđi - jednom na sat. Ali to nije problem - možemo napisati još jedan upit koji će izdvojiti 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)dešifrovati ću:
- 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 možda nedostaju u nizu homeassistant.month.water_meter_hour. Ove podatke ćemo ponovo generisati pokretanjem upita sa GROUP BY time(1h). Ovaj put, fill (prethodni) će raditi ispravno, 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 sati. 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 do 5 ujutro (UTC) nije bilo potrošnje. Ipak, upit će vratiti istu vrijednost potrošnje zahvaljujući fill(previous), a funkcija razlike će od sebe oduzeti ovu vrijednost i dobiti 0 na izlazu, što je zapravo potrebno.
Jedino što je preostalo je da se napravi grafikon. Da biste to učinili, otvorite Grafanu, otvorite neku postojeću (ili kreirajte novu) nadzornu ploču, kreirajte novi panel. Postavke grafikona će biti sljedeće.
Prikazat ću podatke o hladnoj i toploj vodi na istom grafikonu. Zahtjev je potpuno isti kao što sam gore opisao.
Parametri prikaza se postavljaju na sljedeći način. Za mene će to biti graf sa linijama (linijama), koji ide u koracima (stepenicama). Parametar Stack će biti objašnjen u nastavku. Postoji još nekoliko opcija prikaza ispod, ali one nisu toliko zanimljive.
Da biste rezultirali graf dodali kućnom asistentu, trebate:
- izađite iz moda za uređivanje grafikona. Iz nekog razloga, ispravne postavke dijeljenja grafikona se nude samo na stranici kontrolne ploče
- Kliknite na trougao pored naziva grafikona, odaberite dijeli iz izbornika
- U prozoru koji se otvori idite na karticu za ugrađivanje
- Poništite izbor trenutnog vremenskog raspona - vremenski raspon ćemo postaviti preko URL-a
- Odaberite željenu temu. U mom slučaju je lagan
- Kopirajte rezultirajući URL na karticu postavki 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"
Imajte na umu da je vremenski raspon (posljednja 2 dana) postavljen ovdje, a ne u postavkama kontrolne table.
Dijagram izgleda ovako. Nisam koristio toplu vodu u zadnja 2 dana, tako da je nacrtan samo grafik hladne vode.
Nisam za sebe odlučio koji grafikon mi se najviše sviđa, liniju koraka ili prave šipke. Stoga ću jednostavno dati primjer dnevnog rasporeda konzumacije, samo ovaj put u barovima. Upiti se grade na isti način kao što je gore opisano. Opcije prikaza su:
Ovaj grafikon izgleda ovako:
Dakle, o parametru Stack. Na ovom grafikonu, traka hladne vode je nacrtana na vrhu tople trake. Ukupna visina odgovara ukupnoj potrošnji hladne i tople vode za period.
Svi prikazani grafikoni su dinamički. Možete pomicati miša preko točke interesa i vidjeti detalje i vrijednost u određenoj tački.
Nažalost, nije bilo bez par mušica. Na trakastom grafikonu (za razliku od grafikona sa stepenastim linijama), sredina trake nije usred dana, već u 00:00. One. lijeva polovina trake je nacrtana umjesto prethodnog dana. Tako su grafikoni za subotu i nedjelju nacrtani malo lijevo od plavičaste zone. Sve dok nisam shvatio kako da je osvojim.
Drugi problem je nemogućnost pravilnog rada sa mjesečnim intervalima. Činjenica je da je dužina sata / dana / sedmice fiksna, ali dužina mjeseca je svaki put drugačija. InfluxDB može raditi samo u jednakim intervalima. Do sada je moj mozak bio dovoljan da postavim fiksni interval od 30 dana. Da, grafikon će malo plutati tokom godine i trake neće baš odgovarati mjesecima. Ali pošto mi je ova stvar interesantna samo kao mjerač prikaza, slažem se sa ovim.
Vidim najmanje dva resenja:
- Da postignete rezultate na mjesečnim grafikonima i ograničite se na nedjeljne. 52 nedeljna bara u godini izgledaju prilično dobro
- Smatrajte samu mjesečnu potrošnju metodom br. 2 i koristite grafanu samo za lijepe grafikone. To je prilično precizno rješenje. Možete čak i preklopiti grafikone za prošlu godinu za poređenje - grafana to može.
zaključak
Ne znam zašto, ali volim ovakve karte. Oni pokazuju da je život u punom jeku i da se sve mijenja. Juče je bilo mnogo, danas malo, sutra će biti nešto drugo. Ostalo je raditi sa domaćinstvima na temi potrošnje. Ali čak i uz trenutne apetite, samo velika i neshvatljiva cifra na računu već se pretvara u prilično razumljivu sliku potrošnje.
Uprkos mojoj skoro 20-godišnjoj karijeri programera, bazama podataka se praktično nisam ukrštao. Stoga je instaliranje eksterne baze podataka izgledalo kao nešto tako nejasno i neshvatljivo. Sve se promijenilo - pokazalo se da se uvrtanje odgovarajućeg alata vrši u par klikova, a uz specijalizirani alat zadatak crtanja postaje malo lakši.
U naslovu sam naveo potrošnju struje. Nažalost, trenutno ne mogu dati nikakav grafikon. Jedan SDM120 mjerač je mrtav, a drugi ne radi kada se pristupa preko 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 i sam isprobao. Sigurno postoje neki drugi načini organiziranja prikupljanja i vizualizacije podataka za koje ja ne znam. Recite mi o tome u komentarima, bit će me jako zainteresirano. Bit će mi drago konstruktivnoj kritici i novim idejama. Nadam se da će i gornji materijal nekome pomoći.
izvor: www.habr.com