Valahányszor kifizetést kapok az áramért és a vízért, elgondolkodom azon, vajon tényleg olyan sokat fogyaszt a családom? Hát igen, van padlófűtés és kazán a fürdőszobában, de nem dolgoznak állandóan tűzoltóként. Úgy tűnik, hogy spórolunk is a vízzel (bár szeretünk fröccsenni a fürdőszobában is). Néhány évvel ezelőtt én már и okosotthonba, de itt elakadtak a dolgok. A kezek csak most jutottak el a fogyasztás elemzéséig, amiről tulajdonképpen ez a cikk szól.
Nemrég váltottam az otthoni asszisztensre, mint intelligens otthoni rendszeremre. Az egyik ok éppen az volt, hogy meg lehet szervezni nagy mennyiségű adat gyűjtését különféle grafikonok kényelmes felépítésének lehetőségével.
Az ebben a cikkben leírt információk nem új keletűek, ezeket a dolgokat különböző szószok alatt már leírták az interneten. De minden cikk általában csak egy megközelítést vagy szempontot ír le. Ezeket a megközelítéseket össze kellett hasonlítanom, és magamnak kellett kiválasztanom a legmegfelelőbbet. A cikk továbbra sem ad kimerítő információkat az adatgyűjtésről, de egyfajta összefoglalója annak, hogyan csináltam. Ezért várjuk az építő kritikát és a fejlesztési javaslatokat.
Probléma nyilatkozat
Tehát a mai gyakorlat célja gyönyörű víz- és áramfogyasztási grafikonok készítése:
- 2 napon keresztül óránként
- Naponta 2 hétig
- (opcionális) hetente és havonta
Ebben van néhány nehézség:
- A szabványos diagramösszetevők általában meglehetősen gyengeek. Legjobb esetben pontok alapján készíthet vonaldiagramot.
Ha jól keres, találhat harmadik féltől származó összetevőket, amelyek kiterjesztik a szabványos diagram lehetőségeit. Otthoni asszisztensnek elvileg jó és szép alkatrész , de némileg korlátozott is:
- Nehéz nagy időközönként beállítani az oszlopdiagram paramétereit (az oszlop szélessége az óra törtrészében van beállítva, ami azt jelenti, hogy az egy óránál hosszabb intervallumok törtszámokban lesznek beállítva)
- Nem adhat hozzá különböző entitásokat egy grafikonhoz (például hőmérséklet és páratartalom, vagy nem kombinálhat oszlopdiagramot egy vonallal)
- Az otthoni asszisztens nem csak a legprimitívebb SQLite adatbázist használja alapból (és én, az ezermester nem sajátítottam el a MySQL vagy a Postgres telepítését), az adatok tárolása sem a legoptimálisabb. Így például a paraméterek legkisebb digitális paraméterének minden változtatásával egy hatalmas, körülbelül egy kilobájt méretű json kerül az adatbázisba.
{"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}}}Van elég sok szenzorom (hőmérséklet érzékelők minden helyiségben, víz- és villanyóra), és van, amelyik elég sok adatot generál. Például csak az SDM220 villanyóra körülbelül egy tucat értéket generál 10-15 másodpercenként, és 8 ilyen mérőt szeretnék telepíteni. És van egy csomó paraméter, amelyet más érzékelők alapján számítanak ki. Hogy. Mindezek az értékek napi 100-200 MB-tal könnyedén megnövelhetik az adatbázist. Egy hét múlva már alig-alig dobog a rendszer, egy hónap múlva pedig meghal a pendrive (egy tipikus háziasszisztens málna PI-re telepítése esetén), és szó sem lehet egész éves adattárolásról. .
- Szerencsés esetben a fogyasztásmérője maga is képes számolni a fogyasztást. Bármikor felveheti a kapcsolatot a mérővel, és megkérdezheti, hogy mennyi az összesített fogyasztási érték. Általános szabály, hogy minden digitális interfésszel rendelkező villamosenergia-mérő (RS232/RS485/Modbus/Zigbee) biztosít ilyen lehetőséget.
Rosszabb, ha a készülék egyszerűen meg tud mérni valamilyen pillanatnyi paramétert (például pillanatnyi teljesítményt vagy áramerősséget), vagy egyszerűen impulzusokat generál X wattóránként vagy literenként. Ezután át kell gondolni, hogyan és mivel integrálja, és hol halmozzon fel értéket. Fennáll annak a veszélye, hogy bármilyen okból kimarad a következő jelentés, és a rendszer egészének pontossága kérdéseket vet fel. Természetesen mindezt rábízhatja egy intelligens otthoni rendszerre, például az otthoni asszisztensre, de senki sem törölte az adatbázis bejegyzéseinek számát, és a másodpercenkénti többszöri lekérdező szenzorok nem működnek (az házi asszisztens építészet).
1. megközelítés
Először nézzük meg, milyen otthoni asszisztens áll rendelkezésre a dobozból. A fogyasztás mérése egy időszakon belül nagyon igényelt funkció. Természetesen már régen speciális komponensként - utility_meter - lett megvalósítva.
A komponens lényege, hogy belül elindítja az aktuális_felhalmozott_érték változót, és egy meghatározott időszak (óra/hét/hónap) után visszaállítja. Maga a komponens figyeli a bejövő változót (valamilyen érzékelő értékét), feliratkozik magának az értéknek a változásaira - csak megkapja a kész eredményt. Ezt a dolgot csak néhány sor írja le a konfigurációs fájlban
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Itt a sensor.water_meter_cold a mérő aktuális értéke literben, amit kapok által mqtt. A kialakítás 2 új water_cold_hour_um és water_cold_day_um érzékelőt hoz létre, amelyek óránkénti és napi értéket gyűjtenek, és egy időszak után nullára állítják őket. Íme egy fél nap óránkénti akkumulátorának grafikonja.
A lovelace-UI óránkénti és napi diagramkódja így néz ki:
- 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
Valójában ebben az algoritmusban rejlik ennek a megközelítésnek a problémája. Ahogy már említettem, minden bejövő értékhez (az aktuális mérőállás minden következő literhez) 1 kb rekord generálódik az adatbázisban. Minden közüzemi mérő egy új értéket is generál, ami szintén hozzáadódik az alaphoz. Ha szeretnék óránkénti/napi/heti/havi leolvasást gyűjteni, igen, több vízemelőhöz, és még egy csomag villanyórát is hozzátenni, akkor ez sok adat lesz. Nos, pontosabban nincs sok adat, de mivel az otthoni asszisztens egy csomó felesleges információt ír az adatbázisba, az adatbázis mérete ugrásszerűen nő. Még attól is félek, hogy megbecsüljem a heti és havi diagramok alap méretét.
Ráadásul maga a közüzemi mérő sem oldja meg a problémát. A közüzemi mérő diagram egy monoton növekvő függvény, amely óránként 0-ra áll vissza. Kell egy felhasználóbarát fogyasztási ütemezés is, hány litert fogyasztottak el az adott időszakban. A szabványos history-graph komponens nem ezt teszi, de a külső mini-grafikonkártya komponens segíthet nekünk.
Ez a lovelace-UI kártyakódja:
- 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'Az olyan szabványos beállításokon kívül, mint az érzékelő neve, grafikon típusa, színe (nem szerettem a szabványos narancsot), fontos itt 3 beállítást megjegyezni:
- group_by:hour – a diagram az óra elejéhez igazított oszlopokkal jön létre
- pontok_óránként: 1 - óránként egy ütem
- És ami a legfontosabb, az aggregate_func: max az, hogy minden órán belül a maximális értéket vegyük fel. Ez a paraméter az, ami a fűrészfog diagramot oszlopokká alakítja.
Ne figyeljen a bal oldali oszlopsorra - ez a komponens szokásos viselkedése, ha nincs adat. De nem volt adat - csak pár órája kapcsoltam be az adatgyűjtést a közüzemi mérővel, csak a cikk kedvéért (a jelenlegi megközelítésemet kicsit lejjebb írom le).
Ezen a képen azt szerettem volna bemutatni, hogy néha még az adatmegjelenítés is működik, és a sávok valóban a helyes értékeket tükrözik. De ez még nem minden. Valamiért a 11 és 12 óra közötti időszak kiemelt oszlopa 19 litert mutat, bár a fogazott grafikonon ugyanarra az időszakra kicsit feljebb ugyanarra az érzékelőre vonatkozóan 62 literes fogyasztást látunk. Vagy egy bogár, vagy a kezek görbék. De még mindig nem értem, miért törtek ki a jobb oldali adatok - ott a fogyasztás normális volt, ami a fogas grafikonon is látható.
Általánosságban elmondható, hogy nem sikerült elérni ennek a megközelítésnek a hitelességét – a grafikon szinte mindig valamilyen eretnekséget mutat.
Hasonló kód a nappali érzékelőhöz.
- 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'
Kérjük, vegye figyelembe, hogy a group_by paraméter intervallumra van beállítva, és a points_per_hour paraméter mindent szabályoz. És ez egy másik probléma ezzel a komponenssel – a point_per_hour jól működik az egyórás vagy annál rövidebb diagramokon, de undorítóan nagyobb időközönként. Tehát ahhoz, hogy egy nap alatt egy oszlopot kapjak, az 1/24=0.04166666 értéket kellett megadnom. Nem a heti és havi grafikonokról beszélek.
2. megközelítés
Miközben még mindig kitaláltam a háziasszisztenst, erre a videóra bukkantam:
Az elvtárs többféle Xiaomi aljzatból gyűjti a fogyasztási adatokat. Az ő feladata egy kicsit egyszerűbb - csak jelenítse meg a fogyasztás értékét a mai, a tegnapi és a hónapi fogyasztás értékében. Nincs szükség diagramokra.
Hagyjuk félre a pillanatnyi teljesítményértékek kézi integrálásával kapcsolatos érveket - fentebb már írtam ennek a megközelítésnek a „pontosságáról”. Nem világos, hogy miért nem használta fel a felhalmozott fogyasztási értékeket, amelyeket már ugyanaz az üzlet gyűjt. Véleményem szerint a vasdarabon belüli integráció jobban fog működni.
A videóból átvesszük a fogyasztás manuális számlálását egy időszakra. Egy férfi számára csak a mai és a tegnapi értékek számítanak, de tovább megyünk, és megpróbálunk grafikont rajzolni. A javasolt módszer lényege esetemben a következő.
Létrehozunk egy value_at_the_beginning_of_hour változót, amelybe az aktuális számlálóállást írjuk.
Az óra végén (vagy a következő elején) lévő időzítő szerint kiszámítjuk az aktuális és az óra elején tárolt érték közötti különbséget. Ez a különbség lesz az aktuális óra fogyasztása - az értéket elmentjük az érzékelőhöz, és a jövőben ennek alapján készítünk grafikont.
A számláló aktuális értékének odaírásával az value_at_beginning_of_hour változót is „resetelni” kell.
Mindez jól megtehető... magának az otthoni asszisztensnek a segítségével.
Kicsit több kódot kell írnia, mint az előző megközelítésben. Kezdjük ezekkel a "változókkal". A dobozból nem áll rendelkezésünkre a „változó” entitás, de igénybe veheti az mqtt bróker szolgáltatásait. Oda az értékeket a retain=true jelzővel fogjuk küldeni – ez elmenti az értéket a brókeren belül, és bármikor kihúzható, még az otthoni asszisztens újraindításakor is. Egyszerre készítettem óra- és napiszámlálót.
- 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: lMinden varázslat megtörténik az automatizálásban, amely óránként és minden éjjel működik.
- 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: trueMindkét automatika két dolgot csinál:
- Számítsa ki az intervallumonkénti értéket a kezdő és a végérték különbségeként
- Frissítse a következő intervallum alapértékét
A gráfok felépítését ebben az esetben a szokásos történelemgráf oldja meg:
- 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_dayEz így néz ki:
Elvileg már erre van szüksége. Ennek a módszernek az az előnye, hogy intervallumonként egyszer generálódik az adat. Azok. összesen napi 24 bejegyzés az órai diagramhoz.
Sajnos ez még mindig nem oldja meg a növekvő bázis általános problémáját. Ha havi fogyasztási grafikont akarok, akkor legalább egy évig kell adatokat tárolnom. És mivel az otthoni asszisztens csak egy tárolási időtartam beállítást biztosít a teljes adatbázishoz, ez azt jelenti, hogy a rendszerben lévő ÖSSZES adatot egy teljes évig kell tárolni. Például egy év alatt 200 köbméter vizet fogyasztok el, ami 200000 XNUMX bejegyzést jelent az adatbázisban. És ha más érzékelőket is figyelembe vesz, akkor az ábra általában illetlenné válik.
3. megközelítés
Szerencsére az okos emberek már megoldották ezt a problémát az InfluxDB adatbázis megírásával. Ez az adatbázis kifejezetten időalapú adatok tárolására lett optimalizálva, és ideális a különböző érzékelők értékeinek tárolására. A rendszer egy SQL-szerű lekérdezési nyelvet is biztosít, amely lehetővé teszi az értékek kinyerését az adatbázisból, majd különféle módon összesítheti azokat. Végül különböző adatok tárolhatók különböző időpontokra. Például a gyakran változó értékek, mint a hőmérséklet vagy a páratartalom, csak néhány hétig tárolhatók, míg a napi vízfogyasztási értékek egy egész évig.
Az InfluxDB mellett az okos emberek feltalálták a Grafanát is, egy olyan rendszert, amely az InfluxDB adataiból grafikonokat rajzolhat. A Grafana különböző típusú diagramokat tud rajzolni, részletesen testre szabhatja azokat, és ami a legfontosabb, ezek a diagramok „dughatók” a lovelace-UI otthoni asszisztenshez.
inspiráltnak lenni и . A cikkek részletesen leírják az InfluxDB és a Grafana otthoni asszisztenshez való telepítésének és csatlakoztatásának folyamatát. Konkrét problémám megoldására fogok koncentrálni.
Tehát először is kezdjük hozzá a számláló értékét az influxDB-ben. Az otthoni asszisztens konfiguráció egy darabja (ebben a példában nem csak hidegen, hanem meleg vízzel is szórakozni fogok):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldKapcsoljuk ki ugyanazon adatok mentését az otthoni asszisztens belső adatbázisába, nehogy még egyszer felfújjuk őket:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldMost menjünk az InfluxDB konzolra, és állítsuk be az adatbázisunkat. Különösen azt kell beállítani, hogy mennyi ideig legyenek tárolva bizonyos adatok. Ezt szabályozza az ún. megőrzési szabályzat – ez hasonló a fő adatbázison belüli adatbázisokhoz, minden belső adatbázisnak saját beállításai vannak. Alapértelmezés szerint minden adat hozzáadódik az autogen nevű megőrzési szabályzathoz, ezeket az adatokat egy hétig tároljuk. Szeretném, ha az óránkénti adatokat egy hónapig, a heti adatokat egy évig tárolnák, a havi adatokat pedig soha nem törölnék. Megfelelő megőrzési szabályzatot készítünk
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 1Valójában a fő trükk az adatok összesítése folyamatos lekérdezéssel. Ez egy olyan mechanizmus, amely meghatározott időközönként automatikusan elindít egy lekérdezést, összesíti a lekérdezés adatait, és hozzáadja az eredményt egy új értékhez. Nézzünk egy példát (az olvashatóság kedvéért egy oszlopba írom, de a valóságban egy sorba kellett beírnom ezt a parancsot)
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)
ENDEz a parancs:
- Létrehoz egy cq_water_cold_hourly nevű folyamatos lekérdezést a Homeassistant adatbázisban
- A lekérdezés óránként végrehajtásra kerül (idő(1h))
- A lekérdezés az összes adatot kiveszi a mérés'a homeassistant.autogen.l (liter), beleértve a hideg és meleg víz méréseit is.
- Az összesített adatok az entity_id szerint lesznek csoportosítva, ami külön értékeket hoz létre a hideg és a meleg víz számára.
- Mivel a literek számlálója minden órán belül monoton növekvő sorozat, ezért a maximális értéket kell venni, így az összesítést a max(érték) függvény végzi.
- Az új érték a homeassistant.month.water_meter_hour mappába kerül, ahol a hónap az egy hónapos megőrzési időszakkal rendelkező megőrzési szabályzat neve. Ezenkívül a hideg és meleg vízre vonatkozó adatok külön rekordokba kerülnek szétszórva a megfelelő entity_id-vel és az értékmező értékével.
Éjszaka, vagy amikor senki nincs otthon, nincs vízfogyasztás, és ennek megfelelően a homeassistant.autogen.l-ben sincsenek új rekordok. A hiányzó értékek elkerülése érdekében a normál lekérdezésekben használhatja a fill(previous) parancsot. Ez arra kényszeríti az InfluxDB-t, hogy az elmúlt óra értéket használja.
Sajnos a folyamatos lekérdezésnek van egy sajátossága: a fill(previous) trükk nem működik, és a rekordok egyszerűen nem jönnek létre. Ráadásul ez valamiféle megoldhatatlan probléma, ami . Ezzel a problémával később foglalkozunk, és a folyamatos lekérdezésnél legyen ott a fill(previous) - nem zavar.
Nézzük meg, mi történt (persze, várni kell pár órát):
> 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
Ne feledje, hogy az adatbázisban szereplő értékek UTC-ben vannak tárolva, így ez a lista 3 órával eltér – az InfluxDB kimenet 7:10 értékei megegyeznek a fenti diagramokon látható 2:5 értékekkel. Azt is vegye figyelembe, hogy hajnali XNUMX és XNUMX között egyszerűen nincs rekord – ez a folyamatos lekérdezés jellemzője.
Mint látható, az összesített érték is monoton növekvő sorrend, csak a bejegyzések ritkábban - óránként egyszer. De ez nem probléma - írhatunk egy másik lekérdezést, amely kivonja a megfelelő adatokat a diagramhoz.
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)megfejtem:
- A homeassistant.month.water_meter_hour adatbázisból lekérjük az entity_id='water_meter_cold' utolsó napra vonatkozó adatokat (idő >= most() -24h).
- Mint említettem, néhány bejegyzés hiányozhat a homeassistant.month.water_meter_hour sorozatból. Ezeket az adatokat úgy generáljuk újra, hogy a GROUP BY time(1h) lekérdezést futtatjuk. Ezúttal a fill(previous) megfelelően fog működni, generálva a hiányzó adatokat (a függvény az előző értéket veszi fel)
- Ebben a lekérdezésben a legfontosabb a különbségfüggvény, amely kiszámolja az órajelek közötti különbséget. Önmagában nem működik, és aggregációs függvényt igényel. Legyen ez a korábban használt max() érték.
A végrehajtás eredménye így néz ki
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 72Hajnali 2 és 5 óra között (UTC) nem volt fogyasztás. Ennek ellenére a lekérdezés ugyanazt a fogyasztási értéket adja vissza a fill(previous) függvénynek köszönhetően, és a differencia függvény ezt az értéket kivonja magából, és 0-t kap a kimeneten, ami valójában szükséges.
Már csak egy grafikon felépítése maradt hátra. Ehhez nyissa meg a Grafanát, nyisson meg néhány meglévő (vagy hozzon létre egy új) irányítópultot, hozzon létre egy új panelt. A diagram beállításai a következők lesznek.
Ugyanazon a grafikonon fogom megjeleníteni a hideg és a meleg víz adatait. A kérés pontosan ugyanaz, mint amit fentebb leírtam.
A kijelző paraméterei a következők szerint vannak beállítva. Számomra ez egy vonalakkal (vonalakkal) rendelkező grafikon lesz, amely lépésekben halad (lépcsők). A Stack paraméter leírása alább olvasható. Lent van még néhány megjelenítési lehetőség, de ezek nem annyira érdekesek.
Az eredményül kapott grafikon otthoni asszisztenshez való hozzáadásához a következőket kell tennie:
- lépjen ki a diagramszerkesztési módból. Valamilyen oknál fogva a megfelelő diagrammegosztási beállítások csak az irányítópult oldaláról érhetők el
- Kattintson a diagram neve melletti háromszögre, válassza ki a megosztás lehetőséget a menüből
- A megnyíló ablakban lépjen a beágyazás fülre
- Törölje az aktuális időtartomány bejelölését – az időtartományt URL-en keresztül állítjuk be
- Válassza ki a kívánt témát. Az én esetemben könnyű
- Másolja a kapott URL-t a lovelace-UI beállításkártyára
- 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"
Kérjük, vegye figyelembe, hogy az időtartomány (az utolsó 2 nap) itt van beállítva, és nem az irányítópult beállításaiban.
A diagram így néz ki. Az elmúlt 2 napban nem használtam meleg vizet, ezért csak a hideg víz grafikonja készült.
Még nem döntöttem el, hogy melyik diagramot szeretem a legjobban, a lépésvonalat vagy az igazi sávokat. Ezért egyszerűen a napi fogyasztási ütemtervre mondok egy példát, ezúttal csak bárokban. A lekérdezések a fent leírtak szerint épülnek fel. A megjelenítési lehetőségek a következők:
Ez a diagram így néz ki:
Tehát a Stack paraméterről. Ezen a grafikonon egy hideg víz oszlopot rajzolunk a forró sáv tetejére. A teljes magasság az adott időszak teljes hideg és meleg víz fogyasztásának felel meg.
Az összes megjelenített grafikon dinamikus. Az egeret az érdekes pont fölé mozgatva megtekintheti egy adott pont részleteit és értékét.
Sajnos nem volt pár légy nélkül. Az oszlopdiagramon (ellentétben a lépésvonalakat tartalmazó grafikonnal) az oszlop közepe nem a nap közepén van, hanem 00:00-nál. Azok. a sáv bal fele az előző nap helyére húzódik. Tehát a szombati és vasárnapi diagramok a kékes zónától kissé balra húzódnak. Amíg rá nem jöttem, hogyan nyerhetem meg.
Egy másik probléma az, hogy nem tud megfelelően dolgozni havi időközönként. A helyzet az, hogy az óra / nap / hét hossza fix, de a hónap hossza minden alkalommal más. Az InfluxDB csak egyenlő időközönként tud működni. Eddig elég volt az agyam egy fix 30 napos intervallum beállításához. Igen, a diagram egy kicsit lebeg az év során, és az oszlopok nem fognak pontosan megegyezni a hónapokkal. De mivel ez a dolog csak kijelző mérőként érdekes számomra, ezzel rendben vagyok.
Legalább két megoldást látok:
- Pontot szerezni a havi grafikonokon, és a heti grafikonokra korlátozni magát. 52 heti rúd egy évben elég jól néz ki
- Tekintsük magát a havi fogyasztást a 2. módszernek, és a grafanát csak szép grafikonokhoz használjuk. Elég pontos megoldás. Összehasonlításképpen akár az elmúlt év diagramjait is átfedheti – a grafana képes erre.
Következtetés
Nem tudom miért, de szeretem az ilyen típusú diagramokat. Megmutatják, hogy az élet javában zajlik, és minden változik. Tegnap sok volt, ma kevés, holnap lesz más. Marad a háztartásokkal való együttműködés a fogyasztás témakörében. De még a jelenlegi étvágyak mellett is csak egy nagy és érthetetlen szám a számlában, máris eléggé érthető fogyasztási képpé válik.
A közel 20 éves programozói pályafutásom ellenére gyakorlatilag nem kereszteztem az adatbázisokat. Ezért egy külső adatbázis telepítése olyan elgondolkodtatónak és érthetetlennek tűnt. Minden megváltozott - kiderült, hogy a megfelelő szerszám csavarozása pár kattintással megtörténik, és egy speciális szerszámmal kicsit könnyebbé válik a rajzolás.
A címben említettem az áramfogyasztást. Sajnos jelenleg nem tudok grafikont adni. Az egyik SDM120-as mérő halott, a másik pedig hibás, amikor Modbus-on keresztül érik el. Ez azonban semmilyen módon nem érinti a cikk témáját – a grafikonok ugyanúgy készülnek, mint a víz esetében.
Ebben a cikkben azokat a megközelítéseket adtam meg, amelyeket magam is kipróbáltam. Bizonyára vannak más módok is az adatok gyűjtésének és megjelenítésének megszervezésére, amelyekről nem tudok. Mesélj róla kommentben, nagyon érdekelni fogok. Örömmel fogadom az építő kritikát és az új ötleteket. Remélem a fenti anyag is segít valakinek.
Forrás: will.com