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/coordinator -> 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ě...