runtime

projects/iot/state.md

@@ -0,0 +1,88 @@
+# State
+
+## Témata projektu
+
+1. **Měření teploty/vlhkosti v „chlívku"** — znovu zapojit (dříve provozované,
+   nyní nedopadá). Detaily hardware a důvod odstavení neznám.
+2. **MQTT broker** — plán: samostatný LXC kontejner na Proxmoxu.
+3. **Home Assistant** — plán: provozovat ve VM na Proxmoxu.
+4. **Otevřená otázka: čidla fyzicky jinde** — jak dotáhnout čidla k HA,
+   když nejsou u HA; hlavně Zigbee (rádiová, potřeba koordinator v dosahu)
+   a Matter (obvykle přes Wi-Fi/Thread).
+
+## Tuya WiFi čidla — DEFINITIVNÍ ZÁVĚR: slepý konec
+Data nelze dostat lokálně (HTTPS pinning, krátká spojení), jediná
+cesta: Tuya cloud API. Reflash nereálný (novější chipy), sniffing
+zamítnut. Všechny cesty (per-device poll, hromadný poll, Pulsar
+push) limituje samotný model „data musí projít Tuya cloud“ —
+kvóty Trial Edition (26k API volání/měsíc, 68k messages, 50 zařízení,
+bez overage) to neobejde žádným designem. Neškáluje.
+
+**Rozhodnutí:**
+- **Target = Zigbee (ZB Bridge Pro) + MQTT lokálně** — plná vlastní
+  režie, žádné kvóty. Alternativa: WiFi senzory ve vlastní režii
+  (ESP32 DIY) publikující přímo na MQTT.
+- Zpracování pravděpodobně HA, ale **ne nutně** — MQTT je neutrální
+  sběrnice, konzument cokoliv.
+- **tuya2mqtt bridge = legacy** — pro existující Tuya WiFi čidla,
+  dokud se nevymění. Jednou vymře.
+- Migrace postupná: čidlo umře / slabá baterie / špatné měření →
+  náhrada Zigbee/ESP32. Žádná aktivní hromadná náhrada zdravých čidel.
+- **Lekce: nekupovat další Tuya WiFi battery čidla.** Před nákupem
+  čidla ověřit, že data jdou v plné vlastní režii (MQTT-first,
+  žádný povinný cloud).
+
+**Pro reference (co jsme ověřili):**
+- Hromadný `/v1.0/iot-03/devices/status` — jen code/value, bez
+  timestampu, limit 20 IDs.
+- Per-device `GET /v1.0/devices/{id}` — status[] + `update_time` +
+  `online`; 10 čidel × 15 min ≈ 29k/měsíc — přes limitem.
+- Message Service (Pulsar push) — existuje, latence sekundy, ale
+  žere message kvótu (68k/měsíc) a při častém reportu ji vydře.
+- Pokud by se legacy bridge přece jen stavěl: Pulsar push primárně,
+  pomalý poll (1×/h) fallback, dedup na update_time.
+
+## Zigbee brána — rozhodnutí
+
+Požadavky: bez počítače na místě (žádný RPi, žádný server), okamžitě
+funkční po power-loss, žádný boot/maintenance, **WiFi nutně, Ethernet
+kabel nepoužitelný**. Max. zásah = přehrání firmware. NIC nestavíme.
+
+Kandidáti (network coordinator s WiFi):
+
+1. **SMLIGHT SLZB-06M / SLZB-06p10** — ETH+USB+WiFi v jednom, firmware
+   bez OS, vlastní web UI vč. remote flash, Z2M připojení
+   `tcp://<ip>:6638`. Nejrozšířenější v komunitě, oficiálně podporovaný
+   síťový adapter v Z2M.
+2. **SONOFF ZB Bridge Pro (ZBBridge-P)** — WiFi brána, potřebuje Tasmota
+   flash (EZSP, EFR32MG21), pak network coordinator pro Z2M přes
+   `tcp://ip:8888`. Levnější (~29 USD, OpenELAB), ale hacknutá cesta.
+3. **SONOFF ZBDongle-Max (Dongle-M)** — EFR32MG24 + ESP32, ETH/WiFi/USB,
+   síťový mód pro Z2M. Novější, méně zavedený. Cena ~43 USD
+   (sonoff.tech, ETH+PoE zaměřený — WiFi podporuje, ale je to spíš
+   PoE dongle).
+
+## Zigbee mesh — praktická zkušenost
+Mesh u náplňových čidel (CR2032) reálně **nefunguje**: čidlo se probudí,
+odvysílá a v tu chvíli nikdo jiný nevysílí, relay cesta nevzniká.
+Ověřeno prakticky mnohokrát. **Čidlo musí mít přímý dohled na
+coordinator**, jinak smolík. Umístění coordinatoru je kritické;
+případně více coordinatorů (každý s vlastní Z2M instancí).
+
+Preference: **SONOFF ZB Bridge Pro** — zvoleno. Kompaktní, ~29 USD,
+USB napájení, WiFi. Tradeoff: Tasmota flash (EZSP, EFR32MG21) nutný
+před použitím; pak network coordinator pro Z2M přes `tcp://ip:8888`.
+
+## Čidla fyzicky jinde — vyřešeno
+Zigbee: síťový coordinator umístěný pro rádiový dosah + mesh z
+mains-powered zařízení (routery). Náplňová čidla jsou end-devices.
+Matter: Wi-Fi čidla pokryje WiFi síť; Thread potřebuje OTBR
+(experimentální v HA, nižší preference než Zigbee).
+
+## Tuya WiFi čidla — otevřená otázka
+User by je chtěl používat (levná), ale: natvrdo vypálená HTTPS adresa
+(Tuya cloud), čidlo se na WiFi připojí jen krátce při vysílání.
+Lokální odběr dat tedy prakticky nemožný — data jdou do Tuya cloudu
+a ven se dostanou jen přes cloud API, nebo vůbec. Možnosti probrat:
+Tuya cloud API integrace (LocalTuya nefunguje na battery WiFi čidla),
+nahrazení firmware (ne vždy existuje), nebo se Tuya WiFi čidlům vyhnout.