Vlákno názorů k článku Home Assistant: ovládáme interní data a vizualizujeme od PaJaSoft - Diky za tento další výborný članek z vyživného...

Diky za tento další výborný članek z vyživného seriálu, který spoustě lidí pomůže se v obsáhlé problematice orientovat a nakopnout správným směrem.

Bohužel i v tento článku je jak červená nit protkán jedním architektonickým nesmyslem, kteý se bohužel jako mor rozšířil po Internetu a (skoro) všichni ho bez přemýšlení opakují...

Předchozí díly se zabývaly následující topologií: ZigBee zařízení -> MQTT -> HAOS - to stačí k tomu, abychom pochopili, jak hloupě a vyloženě špatně je další část cesty HAOS -> Recorder -> storage.

Vážení, uvědomme si v prvé řadě jak pracuje HAOS s MQTT - on "nepřehrává historii" (a má k tomu sakramentsky dobrý důvod), ale zaznamenává "poslední známý stav" - což je ale v případě senzorů (např. teplota, osvit, tlak, vlhkost...) úplně něco jiného než po systému vlastně chceme a požadujeme. Toto chování má ale zásadní význam a je v pořádku pro jinou kategorii senzorů - např. Dveřní senzor, tlačítko apod.

Zatímco v prvním případě chceme s nějakou granularitou a agregací *kontinuálně* zaznamenávat historii ve formě time series dat, v druhém případě opravdu nechceme přehrát např. předchozích 10 zazvonění zvonku...

Jenže HAOS neumí mezi těmito dvěma rozdílnými formami senzorů a přístupů rozlišovat a umí jen ten druhý způsob - jinými slovy předchozí historii se ani nenamáhá dozvědět (byť to persistentní session v MQTT umožňuje), on ji prostě nechce a *nikdy* nezpracovává (ani se ji nedozvídá!) - a díky tomu je jakákoli taková snaha na něj navěsit "Recorder" odsouzena k nezdaru prvoplánově...

Ze situace mohou vést dvě správné cesty:
a) HAOS -> recorder -> ... ale jen pro věci, u kterých to má opravdu význam a nepožadujeme (časově spojitý) záznam (např. poslední stav zvonku, ale už ne záznam "kolikrát denně nám někdo zvonil")
b) MQTT - > storage -> HAOS

Konkrétní příklad pro správnou architektonickou implementaci vypadá následovně Temperature&Hu­midity senzor -> zigbee2mqtt -> eclipse-mosquitto -> Telegraf -> InfluxDB -> HAOS/Grafana.

Pokud si chceme ušetřit bolehlav a umíme jen MQTT -> HAOS, nevadí, data (až se to naučíme) můžeme kontinuálně zaznamenávat do InfluxDB i HAOS současně, ale prosím, zapomeňme na HAOS/Recorder -> InfluxDB (např.). Jde to i bez problémů a v principu naprosto správně následovně:

A) senzor -> zigbee2mqtt -> MQTT
B1) MQTT -> HAOS
B2) MQTT -> Telegraf-> InfluxDB -> Grafana
B3) MQTT -> Telegraf -> InfluxDB -> HAOS

a to vše klidně i dohromady, dle správného účelu použití.

Místo Telegraf -> InfluxDB si dosaďtě cokoli co umíte, on Telegraf má těch output pluginů fakt hodně (včetně oblíbených MariaDB, PostgreSQL atd.)

Přiznávám, že mi konečně dorazily hračky, takže řetězec jako: zmáčknuto tlačítko -> switch on -> based on lux -> nope / beep budu teprve řešit, takže zde vhodný formát řetězce neporadím. Osobně se přikláním k čistému řešení ve formě:
A1) ZigBee device -> zigbee2mqtt -> MQTT
B1) MQTT -> Telegraf -> InfluxDB -> Grafana
B2) MQTT -> HAOS (toto jen pro případnou část tlačítko -> podmínka -> akce)
B3) HAOS -> MQTT
, ale musím vyzkoušet a zhodnotit neduhy v praxi...

Bohužel jak jsem už uvedl v úvodu - celý Internet je plný špatných (opakovaných/ko­pírovaných) návodů a příkladů jak spojit MQTT s HAOS a skrze jeho Recorder nebo obdobný přístup odsypávat data do stabilní databáze (+ eventuelně downsampling) - opravdu to je pitomost pro velkou část scénářů, kterou chceme realizovat. Používejme skvělé dostupné nástroje ke správným účelům a přemýšlejme nad tím...

PS: Až mi někdo vysvětlí a obhájí si tu (mně unikající) genialitu v MQTT -> HAOS -> Recorder -> DB, hluboce smeknu a omluvím se...:-r

1. Do nějaké míry dobrá připomínka – HA má svoje limity p4i práci s historií a je dobré s nimi počítat.
2. Na druhou stranu bych to ale nepovažoval za vyloženě špatnou cestu. Jednak to může být good-enough (jsme-li si vědomi omezení) a jednak i záznam z MQTT má svá omezení – zejména ne všechna zařízení budou komunikovat přes MQTT.
3. Formální – všechny výskyty „HAOS“ bych nahradil za „HA“.

Ad 1) Vzhledem k tomu, kolik lidi se pak snaží najít "otvírák na ohýbák" si troufám tvrdit, že spousta lidí vůbec netuší o čem jsem psal...:-), natož aby si takových limitů byla vědoma... (kolik najdete na Internetu zmínek o tom (jak říkáte) limitu a jak to správně řešit?) Ono se to netýká jen historie, ale bohužel i *aktuálního stavu* (a to už považuji za průser!), který pokud nemáme Retain msg u topicu nebo po startu HA nerestartujeme také např. zigbee2mqtt, který můžeme nastavit, aby "last known state" znovu opublikovalo do MQTT po svém startu, tak naše automatizace do *dalšího* vyskytu buď a) opětovné publikace aktuálního stavu, b) publikace nového stavu, totiž vůbec není schopna se správně chovat a nastavit svoje stavy a chování dle naprogramované logiky... - ano jsou obezličky, jak to řešit, o většině z nich široká uživatelská báze nemá ani tucha. A tyto omezení nevychází vůbec z MQTT, dosaďte si za to něco jiného - i když MQTT vynecháte, tak to rozumné řešení (bez obezliček v "mezikuse") nemá, navíc se v těchto sítích často nepočítá (v tomto případě) s možností obousměrné komunikace - takže není cesta aby si HA řeklo o aktuální známý stav, ale pouze trpně poslouchá "až mu něco přirazí pod nos" (což naštěstí může tím pádem ta obezlička většinou zachránit).

Ad 2) Je to špatná cesta obecně. Pouze za předpokladu, že "good enough" je limitující vstupní podmínka (ale o tomto ta série článků není a definováno to nebylo - začali jsme se ZigBee, stejně tak si za to dosaďmě cokoli podobně použitelného Z-Wave, LoRaWan či jakýkoli jiný IoT či IIoT) jsem schopen připustit, že to může být s výhradami přijatelné řešení (přestože nechápu proč, když už ta data máme zaznamenána, bychom se jich měli dobrovolně vzdát a jednoduše je (nevědomky) zahodit).

"zejména ne všechna zařízení budou komunikovat přes MQTT" a to jako prosím pěkně proč? Kočkopsodortohumus mohu vyrobit taky, ale to snad není našim cílem... (v principu to přece není vůbec o MQTT a naopak co do MQTT neprocpu? - samozřejmě v kontextu sítě, kterou tu řešíme...:-D)

Ad 3) A co takhle HA-like, pro mne je "HA" profesně taky něco jiného než v kontextu tohoto seriálu...:-)

1. Asi se shodneme, že je fajn to omezení ve článku zmínit.
Asi se taky shodneme, že nejspíš spousta lidí bude myslet zejména na optimistický scénář, a málo na možná selhání. Což někdy může být OK (když vypínač nezapne světlo, uživatel to vidí, a asi není ani žádoucí to zkoušet znova), v některých situacích ale může dávat smysl to zkoušet znovu.
Aktuální stav – to už se netýká jen recorderu. Nicméně minimálně u zigbee2mqtt bych řekl, že po restartu HA (i když zigbee2mqtt zůstane běžet) dostanu aktuální hodnoty celkem rychle.
2. HA není jen i zigbee2mqtt, ale je tu hromada dalších integrací. Něco třeba přes Bluetooth, něco přes Matter a někdo z různých důvodů dává přednost ZHA před zigbee2mqtt. Celkem chápu, když někdo chce ukládat data z toho všeho, samotný MQTT recorder mu vyřeší jen část (byť možná lépe), a stejně musí řešit recorder v HA pro zbytek.
A jinak pokud se chci dívat třeba na trend teploty v nějaké části bytu, je ní úplně fuk, že se pár hodnot (zejména při restartu HA) nezaznamenalo.
3. Home Assistant může běžet v rámci jejich OS, můžete v jiném OS použít docker-compose, a jsou tu nějaké další možnosti. Příspěvek se zjevně týkal samotného HA, ať už běží jakkoli, proto mi nepřijde na místě psát o HAOS.

Myslím, že na spoustě věcí se tu shodneme, mne je spíše záhadou, že se 1000x opakuje ta (dle mého špatná) architektura, ale nikdo se nenamáhá napsat ta omezení a uživatele varovat - i já si tím před časem prošel... a na správné řešení jsem si musel přijít sám, to se člověk nedočte... První věc poté, co jsem dostal "nějaká data" do HA jsem měl tři otázky - jak data zálohovat a co to vše obnáší (+ jak utéct z SQLite, nic proti ni, ale sbíraná data po několik let tam nenechám opravdu ani omylem...), jak vyřešit skutečné HA (= high availability), co znamená a způsobí náhodný a neočekávaný "výpadek" jednotlivých služeb v řetězci.

Záloha - otázka jasná, odpověď přímočará a mimo rozsah tohoto příspěvku

HA -> Recorder -> relační či timeseries DB - o takové řešení jsem zakopával na každém rohu a přitom si stačilo uvědomit, ze "HA neumí persistentní session do MQTT" (záměrně, bohužel ale pro vše) a víme, že jsme fakt blbě...

HA - na úrovni sítě neřešitelné, protože ZigBee i ve verzi 3.0 umožňuje jen jednoho koordinátora v síti (ne heartbeat není varianta multi-master, tedy multi-coordinator, to bychom museli šáhnout např. po Wirepas se zásadně jinou adopcí), na úrovni zpracování dat - viz výpadky

Výpadky:
- sensor(= ZED)/router/co­ordinator -> nejsou data, není co řešit; OUTPUT ZED mohu duplikovat (INPUT ZED - tady už je to tricky, ale řešení by se často dalo spáchat), routery - lze řešit vhodným MESH, coordinator nemá řešení (leda jako vertikální duplikace celé sítě)
- z2m -> nejsou staženy (= dekódovány ze ZigBee)/poslány (do MQTT) data, není co řešit (opět leda jako vertikální duplikace celé sítě i s koordinátorem)
- MQTT - data nějakou dobu "přežijí" na z2m, MQTT lze clusterovat (opensource Mosquitto neobsahuje), takže HA i FO lze zajistit - tady už jsme tedy celkem safe
- Telegraf - MQTT mohu replikovat do aleluja, takže pokud chci (jakože doma nechci), lze vyřešit (obvykle to není potřeba řešit, máme-li persistentní session do MQTT, jen v případě, že máme blbě nastavený (ale syntakticky správný) třeba až output plugin (nebo json_time_format pro input - grrr!), tak data jsou z MQTT vyčtena a nikam nezapsána - suck!)
- InfluxDB - vede na replication cluster-like řešení (zcela mimo sféru opensource, i verze 3.0 aka Edge zřejmě také mimo - viz https://www.influxdata.com/blog/the-plan-for-influxdb-3-0-open-source/ a poznámka o "Features that we’re likely to include in the commercial single server version of InfluxDB 3.0 might include: - Replicas for high availability!)

Tím je kritická cesta pokryta, zbytek už jsou jen další vrstvy, které data primárně neafektují a tedy výpadek obvykle tolerujeme...

A Docker/Podman či K8s based řešení přece není enterprise, který nelze doma multistrojově provozovat.

Ad "Aktuální stav" - to se bohužel pletete - možná v případě ZHA si zbytek HA řekne o "last known state" podobně jako to lze řešit restartem z2m po startu HA, ale pokud něco v MQTT není, z2m nemá důvod to poslat jen tak z plezíru - tedy HA to nemá jak z MQTT vyčíst - kde nic není ani čert nebere... Leda, že by v tomto případě HA prostřednictvím HA/z2m integrace si z2m řekla o to opětovné publikování (ale zase jen "last known state", protože ze sensorů to nejde "vyčíst" - viz Cluster end-pointy, kde GET/PUT není obvykle podporován)

Ad 2) Tady jsme se nepochopili - ja jsem narážel na fakt, že když už mám nasazeno celkem robustní řešení se středobodem MQTT, proč by si nějaká "integrace" měla šahat na něco přímo, proč by se data neměla "scházet" v MQTT a pak je zpracovat dle potřeby toho kterého soudruha - některé HA integrace jdou často přímo proti principům IoT a toho, jak to celé má být seskládáno - kolem HA se motá spousta lidí, kteří jsou rádi, že "něco" "nějak" funguje, ale už to vůbec nedomýšlí... - podobě jako jsou lidé, kteří si s výpadkem Internetu u sebe doma nezatopí... - a neříkejte, že nevíte na co narážím a nejsou to jen urban legends... (a že by měli myslet na backup plán - v tomto případě na linku do činského čoudu - jim nikdo neřekl...:-D)

Navíc většina lidí se o to "fuk" začne zajímat v okamžiu, kdy zjistí jak drahá jsou pro ně data, která nemají (či o ně přišli) a hrozně by je chtěli... Na rádoby populárním eZinu budiž, na tomto serveru bych předpokládal poněkuj jinou sortu audience i erudice (z obou stran) a tudíž i přístup k řešení problematiky...

Ad 3) Open jsme se minuli - HA jako high available, nikoli jako varianty nasazení HA komunitního projektu v konkrétní podobě...