Chytrý dům: Mapování spotřeby vody a elektřiny v Home Assistant

Pokaždé, když dostanu platbu za elektřinu a vodu, říkám si - opravdu moje rodina spotřebuje tolik? No ano, v koupelně je vyhřívaná podlaha a bojler, ale nepracují pořád jako hasiči. Zdá se, že také šetříme vodou (i když se také rádi cákáme v koupelně). Já už před pár lety připojené vodoměry и elektrické energie do chytré domácnosti, ale tady se věci zasekávaly. K rozboru spotřeby se ručičky dostaly až nyní, o čemž je vlastně tento článek.

Nedávno jsem přešel na Home Assistant jako svůj systém chytré domácnosti. Jedním z důvodů byla právě možnost organizovat sběr velkého množství dat s možností pohodlné konstrukce různých druhů grafů.

Informace popsané v tomto článku nejsou nové, všechny tyto věci pod různými omáčkami již byly na internetu popsány. Ale každý článek zpravidla popisuje pouze jeden přístup nebo aspekt. Všechny tyto přístupy jsem musel porovnat a sám vybrat ten nejvhodnější. Článek stále neposkytuje vyčerpávající informace o sběru dat, ale je jakýmsi shrnutím toho, jak jsem to udělal. Takže konstruktivní kritika a návrhy na zlepšení jsou vítány.

Formulace problému

Cílem dnešního cvičení je tedy získat krásné grafy spotřeby vody a elektřiny:

• Každou hodinu po dobu 2 dnů
• Denně po dobu 2 týdnů
• (volitelné) týdně a měsíčně

V tom jsou určité potíže:

• Standardní komponenty grafu bývají dost špatné. V nejlepším případě můžete vytvořit spojnicový graf podle bodů.

  Pokud dobře hledáte, můžete najít komponenty třetích stran, které rozšiřují možnosti standardního grafu. Pro domácího asistenta je v zásadě dobrá a krásná součást mini grafická karta, ale je také poněkud omezená:

  • Je obtížné nastavit parametry sloupcového grafu ve velkých intervalech (šířka sloupce je nastavena ve zlomcích hodiny, což znamená, že intervaly delší než hodina budou nastaveny ve zlomcích)
  • Do jednoho grafu nelze přidat různé entity (například teplotu a vlhkost nebo kombinovat sloupcový graf s čárou)
• Nejen, že domácí asistent standardně používá tu nejprimitivnější SQLite databázi (a já kutil jsem nezvládl instalaci MySQL nebo Postgresu), data se neukládají nejoptimálněji. Takže například s každou změnou každého i sebemenšího digitálního parametru parametru se do databáze zapíše obrovský json o velikosti kilobajtu

  {"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}}}

  Senzorů mám docela dost (teplotní čidla v každé místnosti, vodoměry a elektroměry) a některá generují i ​​docela dost dat. Například jen elektroměr SDM220 generuje každých 10-15 sekund asi tucet hodnot a takových měřičů bych rád nainstaloval 8. A ještě je tam spousta parametrů, které se počítají na základě jiných čidel. Že. všechny tyto hodnoty mohou snadno nafouknout databázi o 100-200 MB denně. Za týden se systém sotva zvrtne a za měsíc umře flashka (v případě typické instalace domácího asistenta na malinu PI) a o ukládání dat na celý rok nemůže být ani řeč .

• Pokud budete mít štěstí, dokáže spotřebu počítat i váš měřič sám. Měřič můžete kdykoli kontaktovat a zeptat se, v kolik hodin je kumulovaná hodnota spotřeby. Takovou možnost poskytují zpravidla všechny elektroměry, které mají digitální rozhraní (RS232/RS485/Modbus/Zigbee).

  Horší je, pokud zařízení může jednoduše měřit nějaký okamžitý parametr (například okamžitý výkon nebo proud), nebo jednoduše generovat impulsy každých X watthodin nebo litrů. Pak je potřeba přemýšlet, jak a s čím to integrovat a kde akumulovat hodnotu. Existuje riziko, že z jakéhokoli důvodu zmeškáte další zprávu, a přesnost systému jako celku vyvolává otázky. To vše můžete samozřejmě svěřit systému chytré domácnosti, jako je domácí asistent, ale nikdo nezrušil bod o počtu záznamů v databázi a senzory dotazování více než jednou za sekundu nebudou fungovat (omezení architektura domácího asistenta).

Přístup 1

Nejprve se podívejme, jaký domácí asistent je k dispozici po vybalení. Velmi žádanou funkcí je měření spotřeby za určité období. Samozřejmě byl již dávno implementován jako specializovaná komponenta - utility_meter.

Podstatou komponenty je, že uvnitř spustí proměnnou current_accumulated_value a po zadané době (hodina/týden/měsíc) ji resetuje. Komponenta sama hlídá příchozí proměnnou (hodnotu jakéhosi senzoru), přihlásí se ke změnám samotné hodnoty – dostanete jen hotový výsledek. Tato věc je popsána na několika řádcích v konfiguračním souboru

utility_meter:
  water_cold_hour_um:
    source: sensor.water_meter_cold
    cycle: hourly
  water_cold_day_um:
    source: sensor.water_meter_cold
    cycle: daily

Zde sensor.water_meter_cold je aktuální hodnota měřiče v litrech, kterou dostanu přímo ze žehličky od mqtt. Návrh vytváří 2 nové senzory water_cold_hour_um a water_cold_day_um, které akumulují hodinové a denní hodnoty a po určité době je vynulují. Zde je graf hodinové baterie za půl dne.

Hodinový a denní kód grafu pro lovelace-UI vypadá takto:

      - 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

Ve skutečnosti v tomto algoritmu spočívá problém tohoto přístupu. Jak jsem již zmínil, pro každou příchozí hodnotu (aktuální stav měřiče pro každý další litr) se v databázi vygeneruje 1kb záznamu. Každý elektroměr také generuje novou hodnotu, která se rovněž připočítává k základu. Pokud chci sbírat hodinové/denní/týdenní/měsíční odečty, ano, pro několik stoupaček vody, a dokonce přidat balík elektroměrů, bude to hodně dat. Tedy přesněji dat je málo, ale jelikož domácí asistent zapisuje do databáze hromadu zbytečných informací, velikost databáze naroste mílovými kroky. U týdenních a měsíčních grafů se dokonce bojím odhadnout velikost základny.

Navíc samotný elektroměr problém neřeší. Graf elektroměru je monotónně rostoucí funkce, která se každou hodinu resetuje na 0. Potřebujeme také uživatelsky přívětivý harmonogram spotřeby, kolik litrů se za dané období snědlo. Standardní komponenta historie-graf toto nedělá, ale může nám pomoci komponenta externí mini-grafická karta.

Toto je kód karty pro 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'

Kromě standardních nastavení, jako je název senzoru, typ grafu, barva (nelíbila se mi standardní oranžová), je důležité poznamenat zde 3 nastavení:

• group_by:hour - graf bude generován se sloupci zarovnanými na začátek hodiny
• points_per_hour: 1 - jeden bar za hodinu
• A co je nejdůležitější, agregace_func: max má mít maximální hodnotu během každé hodiny. Je to tento parametr, který mění pilový graf na pruhy.

Nevěnujte pozornost řádku sloupců vlevo - to je standardní chování komponenty, pokud nejsou žádná data. Ale nebyla tam žádná data - jen jsem před pár hodinami zapnul sběr dat pomocí měřiče spotřeby jen kvůli tomuto článku (svůj současný přístup popíšu trochu níže).

Na tomto obrázku jsem chtěl ukázat, že někdy zobrazení dat dokonce funguje a pruhy skutečně odrážejí správné hodnoty. Ale to není všechno. Z nějakého důvodu zvýrazněný sloupec pro období od 11 do 12 hodin zobrazuje 19 litrů, i když na zubatém grafu o něco vyšší za stejné období ze stejného senzoru vidíme spotřebu 62 litrů. Buď brouk, nebo ruce jsou křivé. Pořád ale nechápu, proč se data vpravo odlomila - spotřeba tam byla normální, což je vidět i z toho zubatého grafu.

Obecně se mi nepodařilo dosáhnout věrohodnosti tohoto přístupu – graf téměř vždy ukazuje nějaký druh kacířství.

Podobný kód pro denní 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'

Pamatujte, že parametr group_by je nastaven na interval a parametr points_per_hour řídí vše. A to je další problém s touto komponentou - body_per_hour funguje dobře na grafech za hodinu nebo méně, ale nechutně na větších intervalech. Abych tedy získal jeden sloupec za jeden den, musel jsem zadat hodnotu 1/24=0.04166666. Nemluvím o týdenních a měsíčních grafech.

Přístup 2

Když jsem stále zjišťoval domácího asistenta, narazil jsem na toto video:

Soudruh sbírá údaje o spotřebě z více typů zásuvek Xiaomi. Jeho úkol je trochu jednodušší – stačí zobrazit hodnotu spotřeby za dnešek, včerejšek a za měsíc. Nejsou vyžadovány žádné grafy.

Ponechme stranou argumenty o ruční integraci hodnot okamžitého výkonu – o „přesnosti“ tohoto přístupu jsem již psal výše. Není jasné, proč nevyužil naakumulované hodnoty spotřeby, které již sbírá stejná výdejna. Podle mého názoru bude lépe fungovat integrace uvnitř kusu železa.

Z videa si vezmeme myšlenku ručního počítání spotřeby za určité období. Pro muže se berou v úvahu pouze hodnoty pro dnešek a včerejšek, ale půjdeme dále a zkusíme nakreslit graf. Podstata navrhované metody v mém případě je následující.

Vytvoříme proměnnou value_at_the_beginning_of_hour, do které budeme zapisovat aktuální stavy počítadel
Podle časovače na konci hodiny (nebo na začátku další) vypočítáme rozdíl mezi aktuální odečtenou hodnotou a uloženou na začátku hodiny. Tento rozdíl bude spotřebou za aktuální hodinu – hodnotu uložíme do senzoru a v budoucnu na základě této hodnoty sestavíme graf.
Musíte také „resetovat“ proměnnou value_at_beginning_of_hour tím, že tam zapíšete aktuální hodnotu počítadla.

To vše lze provést dobře ... pomocí samotného domácího asistenta.

Budete muset napsat trochu více kódu než v předchozím přístupu. Začněme těmito „proměnnými“. Z krabice nemáme „proměnnou“ entitu, ale můžete využít služeb mqtt brokera. Budeme tam posílat hodnoty s příznakem keep=true – tím se uloží hodnota uvnitř brokera a lze ji kdykoli vytáhnout, i když je domácí asistent restartován. Dělal jsem hodinové a denní počítadla najednou.

- 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: l

Všechna kouzla se odehrávají v automatizaci, která běží každou hodinu, respektive každou noc.

- 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: true

Obě automatizace dělají 2 věci:

• Vypočítejte hodnotu za interval jako rozdíl mezi počáteční a koncovou hodnotou
• Aktualizujte základní hodnotu pro další interval

Konstrukce grafů je v tomto případě řešena obvyklým grafem historie:

      - 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

Vypadá to takto:

V zásadě je to již to, co potřebujete. Výhodou této metody je, že data jsou generována jednou za interval. Tito. celkem 24 záznamů za den pro hodinový graf.

Bohužel to stále neřeší obecný problém rostoucí základny. Pokud budu chtít měsíční graf spotřeby, budu muset uchovávat data minimálně rok. A protože domácí asistent poskytuje pouze jedno nastavení doby uložení pro celou databázi, znamená to, že VŠECHNA data v systému budou muset být uložena po celý rok. Například za rok spotřebuji 200 kubíků vody, což znamená 200000 XNUMX záznamů v databázi. A pokud vezmete v úvahu další senzory, pak se toto číslo stane obecně neslušným.

Přístup 3

Chytří lidé naštěstí tento problém již vyřešili sepsáním databáze InfluxDB. Tato databáze je speciálně optimalizována pro ukládání časových dat a je ideální pro ukládání hodnot různých senzorů. Systém také poskytuje dotazovací jazyk podobný SQL, který umožňuje extrahovat hodnoty z databáze a poté je různými způsoby agregovat. A konečně, různá data mohou být uložena pro různé doby. Například často se měnící údaje, jako je teplota nebo vlhkost, mohou být uloženy pouze několik týdnů, zatímco denní údaje o spotřebě vody mohou být uloženy po celý rok.

Chytří lidé kromě InfluxDB vymysleli také Grafanu, systém pro kreslení grafů z dat z InfluxDB. Grafana umí kreslit různé typy grafů, detailně je upravovat, a co je nejdůležitější, tyto grafy lze „zapojit“ do domácího asistenta lovelace-UI.

být inspirován zde и zde. Články podrobně popisují proces instalace a připojení InfluxDB a Grafana k domácímu asistentovi. Zaměřím se na řešení mého konkrétního problému.

Nejprve tedy začněme přidávat hodnotu čítače v influxDB. Kousek konfigurace domácího asistenta (v tomto příkladu se budu bavit nejen se studenou, ale i teplou vodou):

influxdb:
  host: localhost
  max_retries: 3
  default_measurement: state
  database: homeassistant
  include:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Pojďme vypnout ukládání stejných dat do interní databáze domácího asistenta, abychom ji znovu nenafoukli:

recorder:
  purge_keep_days: 10
  purge_interval: 1
  exclude:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Pojďme nyní do konzole InfluxDB a nastavte naši databázi. Zejména je potřeba nakonfigurovat, jak dlouho budou určitá data uložena. To je regulováno tzv. retenční politika – jedná se o obdobu databází uvnitř hlavní databáze, přičemž každá interní databáze má své vlastní nastavení. Ve výchozím nastavení jsou všechna data přidána do zásady uchovávání zvané autogen, tato data budou uložena po dobu jednoho týdne. Přál bych si, aby se hodinová data ukládala měsíc, týdenní data rok a měsíční data nebyla vůbec smazána. Vytvoříme vhodné zásady uchovávání

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 1

Ve skutečnosti je hlavním trikem agregace dat pomocí kontinuálního dotazu. Jedná se o mechanismus, který automaticky spouští dotaz v určených intervalech, agreguje data pro tento dotaz a přidává výsledek k nové hodnotě. Podívejme se na příklad (pro čitelnost píšu do sloupce, ale ve skutečnosti jsem tento příkaz musel zadat na jeden řádek)

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) 
END

Tento příkaz:

• Vytvoří souvislý dotaz s názvem cq_water_cold_hourly v databázi domácího asistenta
• Dotaz bude proveden každou hodinu (čas (1h))
• Dotaz vytáhne všechna data z měření'a homeassistant.autogen.l (litry), včetně odečtů studené a teplé vody
• Agregovaná data budou seskupena podle entity_id, což vytvoří samostatné hodnoty pro studenou a teplou vodu.
• Vzhledem k tomu, že počítadlo litrů je monotónně rostoucí sekvence v rámci každé hodiny, budete muset vzít maximální hodnotu, takže agregace bude provedena funkcí max(value)
• Nová hodnota bude zapsána do homeassistant.month.water_meter_hour, kde měsíc je název zásady uchovávání s dobou uchování jeden měsíc. Data o studené a teplé vodě budou navíc roztroušena do samostatných záznamů s odpovídajícím id entity a hodnotou v poli hodnoty

V noci, nebo když nikdo není doma, nedochází ke spotřebě vody, a tudíž ani v homeassistant.autogen.l nejsou žádné nové záznamy. Chcete-li se vyhnout chybějícím hodnotám v běžných dotazech, můžete použít výplň (předchozí). To přinutí InfluxDB použít hodnotu minulé hodiny.

Nepřetržitý dotaz má bohužel jednu zvláštnost: vyplňovací (předchozí) trik nefunguje a záznamy se jednoduše nevytvoří. Navíc se jedná o jakýsi nepřekonatelný problém, který se diskutuje více než rok. Tomuto problému se budeme věnovat později a v průběžném dotazu necháme vyplnit (předchozí) - neruší to.

Pojďme zkontrolovat, co se stalo (samozřejmě musíte počkat několik hodin):

> 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

Všimněte si, že hodnoty v databázi jsou uloženy v UTC, takže tento seznam se liší o 3 hodiny - hodnoty v 7 hodin ve výstupu InfluxDB odpovídají hodnotám v 10 hodin ve výše uvedených grafech. Všimněte si také, že mezi 2. a 5. hodinou ráno prostě nejsou žádné záznamy – to je samotná vlastnost nepřetržitého dotazování.

Jak vidíte, agregovaná hodnota je také monotónně rostoucí posloupnost, pouze záznamy jsou méně časté - jednou za hodinu. To ale není problém – můžeme napsat další dotaz, který vytáhne správná data pro graf.

SELECT difference(max(value)) 
FROM homeassistant.month.water_meter_hour 
WHERE entity_id='water_meter_cold' and time >= now() -24h 
GROUP BY time(1h), entity_id 
fill(previous)

rozluštím:

• Z databáze homeassistant.month.water_meter_hour vytáhneme data pro entity_id='water_meter_cold' za poslední den (čas >= now() -24h).
• Jak jsem zmínil, některé položky mohou v sekvenci homeassistant.month.water_meter_hour chybět. Tato data znovu vygenerujeme spuštěním dotazu s časem GROUP BY (1h). Tentokrát bude fill (předchozí) fungovat správně a vygeneruje chybějící data (funkce převezme předchozí hodnotu)
• Nejdůležitější v tomto dotazu je rozdílová funkce, která vypočítá rozdíl mezi hodinovými značkami. Sám o sobě nefunguje a vyžaduje agregační funkci. Nechť je to dříve použitá max().

Výsledek provedení vypadá takto

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 72

Od 2:5 do 0:XNUMX (UTC) nebyla spotřeba. Dotaz přesto vrátí stejnou hodnotu spotřeby díky fill(previous) a rozdílová funkce si tuto hodnotu odečte a na výstupu dostane XNUMX, která je ve skutečnosti požadována.

Jediné, co zbývá udělat, je vytvořit graf. Chcete-li to provést, otevřete Grafana, otevřete nějaký existující (nebo vytvořte nový) dashboard, vytvořte nový panel. Nastavení grafu bude následující.

Údaje o studené a teplé vodě zobrazím na stejném grafu. Požadavek je úplně stejný, jak jsem popsal výše.

Parametry zobrazení se nastavují následovně. Pro mě to bude graf s čarami (čarami), který jde po krocích (schodech). Parametr Stack bude vysvětlen níže. Níže je několik dalších možností zobrazení, ale nejsou tak zajímavé.

Chcete-li přidat výsledný graf do domácího asistenta, musíte:

• opustit režim úprav grafu. Z nějakého důvodu jsou správná nastavení sdílení grafu nabízena pouze ze stránky řídicího panelu
• Klikněte na trojúhelník vedle názvu grafu, z nabídky vyberte sdílet
• V okně, které se otevře, přejděte na kartu vložení
• Zrušte zaškrtnutí aktuálního časového rozsahu - časový rozsah nastavíme přes URL
• Vyberte požadované téma. V mém případě je to světlo
• Zkopírujte výslednou adresu URL na kartu nastavení 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"

Upozorňujeme, že časové období (poslední 2 dny) se nastavuje zde, nikoli v nastavení řídicího panelu.

Graf vypadá takto. Poslední 2 dny jsem nepoužil teplou vodu, takže je nakreslen pouze graf studené vody.

Sám jsem se nerozhodl, který graf se mi líbí nejvíc, kroková čára nebo skutečné pruhy. Uvedu proto jednoduše příklad denního schématu spotřeby, tentokrát pouze v barech. Dotazy se vytvářejí stejným způsobem, jak je popsáno výše. Možnosti zobrazení jsou:

Tento graf vypadá takto:

Takže o parametru Stack. V tomto grafu je sloupec studené vody nakreslen nad horkým pruhem. Celková výška odpovídá celkové spotřebě studené a teplé vody za období.

Všechny zobrazené grafy jsou dynamické. Můžete najet myší na bod zájmu a zobrazit podrobnosti a hodnotu v konkrétním bodě.

Bohužel se to neobešlo bez pár mouchy. Na sloupcovém grafu (na rozdíl od grafu s krokovými čarami) není střed sloupce uprostřed dne, ale v 00:00. Tito. levá polovina pruhu je nakreslena na místě předchozího dne. Takže grafy pro sobotu a neděli jsou nakresleny trochu vlevo od namodralé zóny. Dokud jsem nepřišel na to, jak to vyhrát.

Dalším problémem je neschopnost správně pracovat s měsíčními intervaly. Faktem je, že délka hodiny / dne / týdne je pevná, ale délka měsíce je pokaždé jiná. InfluxDB může pracovat pouze se stejnými intervaly. Můj mozek mi zatím stačil nastavit si pevný interval 30 dní. Ano, graf bude během roku trochu plavat a sloupce nebudou přesně odpovídat měsícům. Ale protože mě tato věc zajímá jen jako měřidlo displeje, jsem s tím v pořádku.

Vidím minimálně dvě řešení:

• Chcete-li bodovat v měsíčních grafech a omezit se na ty týdenní. 52 týdenních barů za rok vypadá docela dobře
• Samotnou měsíční spotřebu považujte za metodu č. 2 a grafana použijte pouze na krásné grafy. Je to docela přesné řešení. Pro srovnání si můžete dokonce překrýt grafy za uplynulý rok – to grafana umí.

Závěr

Nevím proč, ale miluji tyto druhy grafů. Ukazují, že život je v plném proudu a vše se mění. Včera bylo hodně, dnes je málo, zítra bude něco jiného. Zbývá pracovat s domácnostmi na tématu spotřeby. Ale i při současných choutkách se právě velká a nepochopitelná cifra ve vyúčtování již mění v celkem srozumitelný obrázek spotřeby.

Přes svou téměř 20letou kariéru programátora jsem se s databázemi prakticky neprotínal. Instalace externí databáze proto vypadala jako něco tak nesrozumitelného a nepochopitelného. Vše se změnilo výše uvedený článek - ukázalo se, že našroubování vhodného nástroje se provádí několika kliknutími a se specializovaným nástrojem je úloha kreslení o něco jednodušší.

V nadpisu jsem uvedl spotřebu elektřiny. Bohužel v tuto chvíli nemohu poskytnout žádný graf. Jeden měřič SDM120 je mrtvý a druhý je zabugovaný při přístupu přes Modbus. To však nijak neovlivňuje téma tohoto článku – grafy budou sestaveny stejně jako u vody.

V tomto článku jsem uvedl ty přístupy, které jsem sám vyzkoušel. Určitě existují nějaké další způsoby, jak organizovat sběr a vizualizaci dat, o kterých nevím. Řekněte mi o tom v komentářích, velmi mě to bude zajímat. Budu rád za konstruktivní kritiku a nové nápady. Doufám, že výše uvedený materiál také někomu pomůže.

Zdroj: www.habr.com