runtime

projects/ai/memory.md

@@ -8,3 +8,15 @@ Uživatelova diagnóza: nedokáže správně popsat zadání; buď málo informa
 - 2026-09-08: correction: „úplně znovu od nuly — ne" z minula bylo nedorozuměním. Uživatel tím nemyslel „znovu bez specifikace", ale nepoužít existující runbook a existující skripty jako základ — ty ho limitují a anchornují ho špatným směrem. Restart s jeho vlastní specifikací (tabulka scénářů + kostry) je v pořádku, jediné co ne: recyklace agent-runbooku.
 - 2026-09-08: Destilace postupu „převod agent-nástrojů na nástroje pro člověka" uložena jako artefakt: projects/ai/artifacts/agent-to-human-tools.md. Strukturovaný markdown: proč zjednodušení agent-nástrojů nefunguje (neviditelná hranice složitosti, ukotvení existující podobou, plan mode neřeší design), princip „rozhraní navrhuje člověk, model implementuje", 4krokový postup (čistý adresář → tabulka scénář→příkaz → kostry → dokódování těl) a pravidla pro zadání (čísla místo adjektiv, omezení v kódu ne v promptu, agent-runbook nepřevádět). Po vzájemné korektní diskusi: knowledge/ odmítnut, artefakt patří do projektu ai.
 - 2026-09-08: Rozbor článku „Don't Chat With Your AI. Mob With It." (Rodenas) + diskuse s Claude uložen jako artefakt: projects/ai/artifacts/file-based-agent-communication.md. Technikou je komunikace s agentem přes tagy v souborech místo chatu. Článková argumentace odmítnuta (latence ≠ GPU sloty; mob analogie obrácená; autonomní smyčka + mazání tagů = ztráta kontrolního bodu a prodloužení feedback loopu pro člověka). Použitelné jádro: anotace patří tam, kde je předmět anotace (pozice = kontext, jako TODO komentář), trvalost v diffu, tag se nemaže jen se připíše odpověď, max 1–2 tagy na kolo, explicitní spouštění místo autonomní smyčky. Otevřená otázka: jak korigovat agentovy odpovědi — kandidát varianta „vlákno jako komentáře v kódu" oproti vedlejšímu .notes.md souboru. Zájem uživatele o vyzkoušení.
+- 2026-09-09: Refactoring C# třídy s Claude: iterativní review smyčka a její selhání. Postup „review v nové session, opravy taky v nové session" vede k regresím — každá další session najde další „problémy", část z nich je reverz dříve odsouhlasených rozhodnutí, ne reálná chyba. Nová session totiž nevidí historii a znovu otevírá už uzavřené otázky.
+
+Závěr (podle kolegy, uživatel souhlasí): lepší je hybrid — **review v čisté nové session** (svěží pohled bez anchoringu na vlastní práci), ale **závěry vkládat zpět do původní session**, kde se provádějí i opravy. Původní session má kompletní historii, ví, která rozhodnutí padla a proč, a drží se jich — takže nevrací odsouhlasené změny.
+
+Souvisí s požadavkem na „čistý refaktor": ověření, že se chování zvenku vůbec nezměnilo, má být cílem review, ne vedlejším produktem.
+- 2026-09-09: Rozbor článku „LLM jako virtuální projektový tým" (Root.cz, Tonda) a jeho mapování na naše otevřená témata:
+
+- Článkové „přenášej artefakty, ne historii konverzace" = potvrzení našeho závěru z file-based-agent-communication.md i review smyčky. Formulace: kontext = artefakt + role + zadání, nic víc.
+- Naše review smyčka (čistá session na review, opravy v původní session s historií) je přesně článkový workflow; náš přídavek, který článek neřeší: kam závěry oponenta vracet — u nás původní session jako decision-history channel. Článek navíc: iterovaná oponentura (A→B→A/C→B) a různé providery pro procesní nezávislost.
+- Aplikace na kód: persony s omezeným mandátem (security, API konzument, ops, výkon) místo generického „udělej review" — řeší regresní problém, že každá nová session reverzne odsouhlasená rozhodnutí; omezený mandát nedovolí otevírat usazené otázky mimo scope.
+- „Z nápadu hypotéza" = naše „čísla místo adjektiv" z agent-to-human-tools.md. Stage-Gate přenositelný na testy: gates definované předem = co chybělo u Solarflare scénářů.
+- Článek ospravedlňuje strukturu project skill (decision log, živý stav). Nový nápad: explicitní registr předpokladů — seznam neověřených věcí, které držíme za pravdu, s dohledatelností závislostí.

projects/ai/state.md

@@ -3,7 +3,18 @@
 ## Otevřená témata
 - Při hlášení nestabilit ověřit reálný model/preset (session metadata ho nezaznamenávají).
 
+## Nápady k pozdějšímu použití (z článku „LLM jako virtuální projektový tým")
+
+Zdroj:
+https://blog.root.cz/tonda/llm-jako-virtualni-projektovy-tym-od-generovani-textu-k-rizene-oponenture-podnikatelskeho-planu/
+- **Persona s omezeným mandátem** místo generického „udělej review" (security, API konzument, ops, výkon) — omezený scope brání reverzům odsouhlasených rozhodnutí.
+- **Multi-provider oponentura** — jiný model/preset na review pro procesní nezávislost (ne anchoring na terminologii tvůrce); v nanobotu via `model_preset`.
+- **Registr předpokladů** — explicitní seznam neověřených věcí držených za pravdu, s vazbou předpoklad → závislá rozhodnutí.
+- **Stage-Gate pro testy** — pass/fail podmínky další fáze definované předem, ne ad-hoc po běhu.
+- **Iterovaná oponentura** (A→B→A/C→B) — opakovat review po přepracování, ne jen jednou.
+
 ## Lessons learned
+- Review iterací: nová session na review = svěží pohled, ale opravy dělat v původní session s plnou historií rozhodnutí — jinak hrozí regrese (reverzy odsouhlasených rozhodnutí).
 - Inline `python -c` s cestami blokuje exec guard i uvnitř workspace → write_file do tmp/ + `uv run` s working_dir.
 - Před re-runem vždy rekonstruovat loop ze sessions/ — rozhodnout model vs. tooling chyba.
 - Možný upstream report na nanobot: guard blokuje legit `python -c` s workspace cestami.

projects/iot/memory.md

@@ -0,0 +1,58 @@
+- 2026-09-09: Založen projekt iot — zaměření na hardware, IoT a bastlení obecně (ESP32, Raspberry Pi, senzory). Motivace: teplotní senzor v pokoji „chlívek" (okno s holubími hřebí), zájem o ESP32 a RPi na testování. Serverové/Proxmox věci zůstávají v projektu proxmox.
+- 2026-09-09: Vytyčeny čtyři témata projektu: 1) znovu zapojit měření teploty/vlhkosti v pokoji „chlívek"; 2) samostatný Proxmox LXC kontejner na MQTT broker; 3) provozovat Home Assistant ve VM na Proxmoxu; 4) otevřená otázka — jak dotáhnout čidla k HA, když jsou fyzicky jinde, hlavně Zigbee a Matter.
+- 2026-09-09: Rozhodnutí k Zigbee architektuře: USB dongle v serveru/RPi odmítnut jako nepraktický — čidla jsou na místech bez počítače, RPi tam mít nechce, brána musí být jednoduchá, spolehlivá a okamžitě funkční (žádný boot, žádný maintenance). Směr: Ethernet Zigbee coordinator (SLZB-06 / UZG-01 typ), umístěný strategicky pro rádiový dosah, připojený přes LAN; Zigbee2MQTT + MQTT broker v LXC na Proxmoxu se k němu dostanou po TCP.
+- 2026-09-09: Rozšíření rozhodnutí o Zigbee bráně: kladné volby — brána nesmí vyžadovat počítač (RPi ani nic jiného na místě čidel), musí být jednoduchá, okamžitě po power-loss funkční, bez boot procesu a maintenance. Navíc: **WiFi nutně, Ethernet kabel vyřazen jako nepoužitelný v daných místech**. Postavení vlastního routeru/bridge z RPi nechce. Max. zásah = přehrání firmware.
+
+Ověřené kandidáty (network coordinator s WiFi):
+
+1. **SMLIGHT SLZB-06p10 / SLZB-06M** — Zigbee 3.0 coordinator, podporuje Ethernet, USB i **WiFi** v jednom; firmware bez OS, okamžitý start; Z2M připojení `tcp://<ip>:6638`; správa přes vlastní web UI (vč. remote flash). Nejrozšířenější v komunitě, Z2M oficiálně podporuje jako síťový adapter.
+2. **SONOFF ZB Bridge Pro (ZBBridge-P)** — WiFi Zigbee brána, **vyžaduje Tasmota flash** (EZSP firmware pro EFR32MG21), poté funguje jako network coordinator pro Z2M (`tcp://ip:8888` přes tasmota ZBBridge režim). Levnější, ale hacknutá cesta — flash přes webový proces, komunitní návody existují (stephengrier.com, haade.fr).
+3. **SONOFF ZBDongle-Max (Dongle-Max)** — Zigbee/Thread PoE dongle (EFR32MG24 + ESP32), podporuje Ethernet, WiFi i USB; síťový mód pro Z2M. Novější kus, méně zavedený v Z2M než SLZB-06, ale funguje jako network adapter.
+
+Zdroj: zigbee2mqtt.io (remote adapter how-to), smlight.tech manual, blakadder.com — vyhledáno, částečně ověřeno (Z2M remote adapter stránka potvrzuje síťový mód SONOFF ZBBridge přes Tasmota).
+- 2026-09-09: Correction k Zigbee meshu: user opravuje dřívější tvrzení, že se Zigbee síť "doroste" k náplňovým čidlům přes mesh. Teoreticky Zigbee je mesh, ale prakticky to u čidel na CR2032 (a malé) baterky nefunguje — čidlo se probudí jednou za čas, odvysílá naměřené hodnoty, a v tu chvíli většinou nikdo jiný nevysílí (routery spí/nemají co přenášet), takže relay cesta přes mesh zařízení reálně nevzniká. Ověřeno prakticky mnohokrát. **Náplňové čidlo musí mít přímý rádiový dohled na coordinator**, jinak má smolíka (ztracené zprávy, odpojené čidlo). Důsledek pro architekturu: umístění WiFi coordinatoru je ještě kritičtější — musí být fyzicky blízko / v dohledu všech čidel, případně více coordinatorů na více místech (každý s vlastní Z2M instancí).
+- 2026-09-09: Volba Zigbee brány: SONOFF ZB Bridge Pro (ZBBridge-P). Důvody: kompaktní provedení, rozumná cena (~29 USD), napájení USB (flexibilní umístění kdekoliv se zásuvkou/USB adaptérem, bez Ethernet kabelu). Přijatý tradeoff: vyžaduje Tasmota flash (EZSP firmware pro EFR32MG21) před použitím jako network coordinator pro Zigbee2MQTT (připojení tcp://ip:8888). Flash je v rámci akceptovaného zásahu (max. přehrání firmware). Odmítnuty: SLZB-06M (dražší, Ethernet-zaměřený tvar), ZBDongle-Max (dražší, PoE dongle tvar).
+- 2026-09-09: User potvrzuje: napájení i Tasmota flash si zvládne sám, žádná asistence od agenta při fyzické instalaci není potřeba. Další krok až po fyzickém pořízení ZB Bridge Pro — pak navázat software stack (MQTT LXC, Z2M, HA VM) na Proxmoxu.
+- 2026-09-09: Téma: Tuya WiFi čidla. User by je rád používal (levná, dostupná), ale problém: mají natvrdo vypálenou HTTPS adresu (cloud endpoint) — lokálně mluvit s nimi nejde přímo. Čidla jsou battery-powered, připojují se na WiFi jen v krátkých časových úsecích, když právě vysílají (probudí se, pošlou data na Tuya cloud, zase spí). Tím pádem: nelze je směrovat do vlastní sítě a čekat na trvalé spojení; lokální integrace by vyžadovala zachytit komunikaci v okamžiku vysílání (prakticky nespolehlivé) nebo přesměrovat DNS (ale čidlo mluví HTTPS na natvrdo daný endpoint — MITM/TLS pinning problém). Zatím otevřená otázka, jak s nimi pracovat, aniž by data šla do Tuya cloudu.
+- 2026-09-09: User vlastní hromadu Tuya čidel, z nich velká část WiFi (historicky vybraná pro nejsnazší zapojení). Tuya aplikace hodnotí jako nahovno, Tuya cloud má omezení počtu API volání (rate limity). Požadavek: vycítání čidel mít plně ve vlastní režii (žádná závislost na Tuya cloudu, žádná API volání). Diskutované cesty: (a) cloud API bridge — nevyhovující, právě kvůli limitům a cloudu; (b) reflash na Tasmota/OpenBK — u WiFi čidel záleží na chipu (Realtek/ESP/Beken), ne vše jde reflashovat, battery čidla navíc vysílají jen krátce; (c) zachytávat Tuya lokální protokol — u battery WiFi čidel nemožné (krátká spojení, HTTPS pinning). Otevřená otázka zůstává: jak dostat existující Tuya WiFi battery čidla do vlastní režie; reálně znamená inventuru — projít jednotlivá čidla, zjistit chipy a určit, která jdou reflashovat, a která jsou mrtvá pro lokální použití.
+- 2026-09-09: Vyřazeny cesty k Tuya WiFi čidlům: reflash nereálný — user má většinou novější Tuya čidla (chipy bez komunitní podpory, ne Beken/ESP generace); sniff/MITM zachytávání hodnoceno jako kravina, nedává to smysl jako režie. Zbývá jediné rozvětvení: (a) Tuya cloud API s rozumným pollingem — teplota/vlhkost se mění pomalu, takže limit volání nemusí být reálný problém, pokud se dotazuje např. jednou za 5-15 min a ne po každém čidle zvlášť; nebo (b) postupná náhrada Tuya WiFi battery čidel Zigbee variantami (brána ZB Bridge Pro už je zvolená). Fyzicky: čidla mluví HTTPS na natvrdo vypálený endpoint — data nelze dostat lokálně vůbec, jediná cesta ven je cloud API.
+- 2026-09-09: Plan rozšířen o Tuya cloud API včítání: polling s nízkou frekvencí, cílově 10-15 min (user preference max 10-15 min). Data se publikují na MQTT jako u ostatních čidel.
+
+Ověřeno na developer.tuya.com (primární zdroj), že cloud REALNĚ ví, kdy hodnota naposledy přišla:
+- GET /v1.0/devices/{device_id} vrací kromě status[] (code/value) také "update_time" (timestamp poslední aktualizace stavu zařízení, sekundy) a "online" flag — stačí z jednoho endpointu.
+- GET /v2.0/cloud/thing/{device_id}/report-logs (nebo /v1.0/iot-03/.../report-logs) vrací per-DP logy s "event_time" pro každý kód — přesná historie kdy co došlo, vč. časů jednotlivých reportů.
+- Tzn. problém "app ukazuje hodnotu starou týden a neumí říct že neplatí" je řešitelný: náš tuya2mqtt script bude porovnávat update_time/event_time proti aktuálním časem a ke každé hodnotě připojí timestamp posledního reálného reportu (a/nebo flag "stale"), takže HA/možné notifikace můžou detekovat mrtvá čidla.
+- 2026-09-09: Upřesnění tuya2mqtt designu: nechat API vrátit update_time pro každé zařízení, držet lokálně poslední známý update_time; pokud se mezi pollly nezměnil, hodnoty se na MQTT nepublikují vůbec (žádný stale flag ve zprávě, žádné opakované posílání stejných dat). MQTT tak zůstane čistý — zpráva = nová data. Detekce mrtvého čidla se pak dělá na straně konzumenta (HA/možný watchdog): absence zprávy na topicu za dlouhý čas = stale/offline; příp. HA MQTT device triggers / last_change sensor. Je to jednodušší a idempotentní, žádné duplikáty v brokeru.
+- 2026-09-09: Ověřeno z Tuya primárních zdrojů (developer.tuya.com membership-service + support.tuya.com): IoT Core **Trial Edition** (free, jen pro osobní/debug použití) — basic resource pack = **26 000 API volání / měsíc** (+ 68 000 messages). Po vyčerpání: přístup omezen, Trial neumí overage (nelze dokoupit), obnoví se začátkem dalšího měsíce. Další Trial limity: max 50 zařízení v projektu, max 10 controllable devices, 1 data center, žádný log backtracking. Trial je navíc oficiálně časově omezený (6 měsíců, pak žádost o prodloužení — dle support.tuya.com lze prodloužit opětovnou žádostí). Rate limit navíc per-endpoint (např. ~10 req/s na některé, 500/s celkové API maximum) — pro náš use case irelevantní.
+
+Spotřeba našeho designu: 1 hromadné volání za poll (GET /v1.0/iot-03/devices/status vrací status pro všechny device_id najednou) — při pollu co 15 min = 96 volání/den = ~2 880/měsíc, tj. cca 11 % kvóty. I s per-device report-logs voláními (pokud bychom chtěli event_time per DP) se do 26k vejdeme, ale hromadný status endpoint to pravděpodobně vyřeší i s update_time. Konec vahy: 15-min poll bezpečně v limitu; 10-min poll taky (~4 320/měsíc).
+- 2026-09-09: Oprava/uhrazení hromadného status endpointu: GET /v1.0/iot-03/devices/status (Get the latest status of multiple devices) — ověřeno v API reference: vrací POUZE code/value per DP, ŽÁDNÝ timestamp (žádné update_time, žádný event_time). Navíc limit max 20 device_ids per volání. Userova zkušenost tedy potvrzena dokumentací — hromadný endpoint pro náš dedup-design (aktualizace dle update_time) NEVYHOVUJE, protože nevrací čas posledního reportu.
+
+Zpětný dopad na design kvót: musí se volat per-device endpoint, který update_time vrací. Kandidáti:
+(a) GET /v1.0/devices/{device_id} (Device Management) — vrací status[] + update_time + online (ověřeno dříve v docs); 1 volání per zařízení.
+(b) GET /v2.0/cloud/thing/batch (Query Device Details in Bulk) — nutné ověřit, zda vrací update_time.
+(c) GET /v2.0/cloud/thing/{device_id}/report-logs — event_time per DP, ale těžší volání.
+
+Matematika s per-device voláním (a) při N čidlech:
+- 10 čidel: poll 15 min = 96 pollů/den × 10 = 960 volání/den ≈ 29k/měsíc — TĚSNĚ PŘES 26k Trial limitem.
+- 10 čidel, poll 20 min: 72 × 10 × 30 = 21 600 — pod limitem.
+- Závěr: per-device read s update_time na Trial edici vyžaduje poll ≥ ~20 min při 10 čidlech, NEBO batch endpoint (b) pokud vrací update_time (ověřit), NEBO Message Service (push namísto pollingu — 68k messages/měsíc kvóta, nutno prověřit).
+
+Dotaz usera "co znamená +68k zprav": 68 000 messages = kvóta Message Service — push zprávy od Tuya cloudu (device status changes doručené aktivně, ne polling). Zatím neověřeno, zda/v jakém formátu to zahrnuje device status reports; potenciálně řeší celý problém (push místo poll), ale vyžaduje ověření API a vlastní endpoint (MQTT bridge / webhook receiver).
+- 2026-09-09: Ověření Tuya Message Service jako skalabilní cesty (místo per-device pollingu): Tuya Message Service používá Apache Pulsar (ne MQTT/HTTP webhook) — po aktivaci subscription na cloud projektu cloud aktivně PUSHuje event data, když se stav zařízení změní (data reporting, offline events, registrace). Klient se připojuje Pulsar SDK/consumerem, cloud doručuje zprávy do fronty, čte se pull-style z Pulsar topicu. Zdroj: developer.tuya.com (Get Messages by Message Queue — device-msg-queue-practice, subscribe-mq, integrate-mq). Klíčové fakty: "If the device status in the project changes, such as registration, data reporting, and offline events, Message Service is used to actively push event data to you with Pulsar" — tedy přesně náš use case, device status reports pushnuté okamžitě po reportu čidla.
+
+Význam pro design: tím pádem NULOVÝ polling nutný pro běžný provoz — čidlo reportuje → cloud pushne zprávu → náš consumer publikuje na MQTT. 68k messages/měsíc Trial kvóta je v pohodě (čidlo reportuje typicky 1-2×/hodinu, 20 čidel = ~1-2k zpráv/den = max ~60k/měsíc, na hraně ale reálně méně, protože ne každý report = nová zpráva pro každé DP). Per-device poll (GET /v1.0/devices/{id}) si necháváme jako bootstrap/fallback (první načtení stavu po restartu, ověření že jsme nezmeškali nic).
+
+Dopad na kvóty: API volání klesnou na minimum (bootstrap + health-check), messages se posunou do 68k kvóty. Skaluje se lineárně s počtem čidel bez nutnosti měnit poll frekvenci.
+
+Otevřené body k doladění: (a) Pulsar consumer běží v našem LXC (Python klient existuje — tuya-iot-pulsar-sdk), (b) formát zprávy obsahuje data + timestamp (nutno ověřit na reálných datech), (c) offline events umožňují detekovat mrtvá čidla pushem, ne pollingem.
+- 2026-09-09: User vytýká principiální problém pollingu: čidlo reportuje klidně každou minutu, ale uživatel to v HA vidí až za 20 minut (worst case = poll period). Tohle je přesně argument, proč polling je špatný model pro čidla, která reportují často. Pulsar push (Message Service) to řeší — zpráva dorazí okamžitě po reportu, tedy latence = sekundy, ne minuty. Tímto je designový směr definitivně: PULL (polling) jen jako fallback/bootstrap, primární tok = PUSH (Pulsar). 20-min poll fallback zůstává jako safety net pro případ výpadku consumeru, ale pro data je hlavní cesta push.
+- 2026-09-09: DEFINITIVNÍ ZÁVĚR k Tuya WiFi čidlům: architektonický slepý konec. Tuya cloud brutálně omezuje přístup k vlastním datům — kvóty (26k API volání/měsíc, 68k messages), Trial limit 50 zařízení, žádný overage dokup, data nutně přes cizí cloud. Žádná z probraných cest (per-device poll, hromadný poll, Pulsar push) tohle neobejde — limit je v samotném modelu "data musí projít Tuya cloud", ne v designu.
+
+Rozhodnutí:
+- Target architektura = 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ě v HA, ale ne nutně — MQTT je neutrální sběrnice, konzument může být cokoliv.
+- tuya2mqtt bridge degradován na legacy: běží pro existující Tuya WiFi čidla, dokud se nevymění. Neškáluje a jednou vymře.
+- Migrace postupná: Tuya čidlo umře / slabá baterie / špatné měření → náhrada Zigbee/ESP32 variantou. Žádná aktivní hromadná náhrada zdravých čidel.
+- DŮLEŽITÉ DO BUDOUCNA: nekupovat už žádná Tuya WiFi battery čidla. Lekce: před nákupem čidla ověřit, že data jdou dostat v plné vlastní režii (MQTT-first, žádný povinný cloud).

projects/iot/prompt.md

@@ -0,0 +1,16 @@
+# IoT / bastlení
+
+## Účel
+Projekt pro hardware, IoT a bastlení obecně — vše od malých deskek po senzory,
+co nepatří do serverových projektů (Proxmox má vlastní projekt).
+
+## Rozsah
+- ESP32 (hardware i firmware)
+- Raspberry Pi na testování
+- Senzory a měření (teplota, …)
+- Další bastlení dle nálady
+
+## Způsob práce
+- Tykání, stručně, technicky.
+- Důraz na nejjednodušší funkční řešení.
+- Fakta a měřené hodnoty ověřovat, ne tipovat.

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.