---
tipo: progetto
stato: avviato — architettura decisa, primo acquisto (dongle) in corso
data: 2026-08-26
---

# Progetto domotica / IoT — ipotesi di lavoro

Nota di sintesi da conversazione esplorativa, poi diventata piano attivo il 26/08/2026.

**(26/08/2026) Avviato, in parallelo all'esplorazione [[arduino-kit|Arduino]]**: Mauro ha deciso di partire. Protocollo **Zigbee** (non Matter/Thread — catalogo sensori più ampio, il vantaggio multi-ecosistema di Matter non serve qui), architettura **ZHA** (vedi raccomandazione sotto).

**Primo acquisto fatto (26/08/2026)**: **Sonoff ZBDongle-E** (chip Silicon Labs EFR32MG21, firmware EmberZNet/EZSP preinstallato, antenna esterna SMA) — verificato da Adrian prima dell'ordine, combacia con l'opzione consigliata nella ricerca coordinator sotto, EZSP è il firmware nativo per ZHA. Valutato e scartato per ora lo SMLight SLZB-06 PoE/LAN (coordinator di rete, permetterebbe posizionamento centrale senza USB) — costa quasi il doppio, rimandato a un eventuale upgrade se il posizionamento vicino alla Nave risultasse un problema reale, non ipotetico. Da fare al collegamento: prolunga USB 2m (presa così, costava meno della 1,5m — comunque nel range utile), lontano dal case/porte USB 3 (interferenza nota).

**Sensori acquistati (26/08/2026)**: 3x **SONOFF SNZB-02P** — combacia col candidato consigliato dopo la ricerca (vedi sotto), stesso modello per tutti e tre come da regola "nomenclatura/confronto fra stanze" (accortezze in fondo al file). Una stanza + una di riferimento, secondo il primo lotto proposto.

**Stato: hardware in arrivo, nessuna installazione ancora fatta.** Prossimo passo quando arriva tutto: container HA (`network_mode: host` per la discovery) + integrazione ZHA + accoppiamento dongle e sensori.

**⚠️ Promemoria esplicito (26/08/2026), da non saltare all'installazione**: il recorder di default di HA tiene lo storico completo solo pochi giorni (poi comprime/scarta) — per lo storico di settimane/mesi che serve al confronto pre/post intervento pannelli radianti (10/10), va affiancato **fin dal primo giorno** un database a ritenzione lunga (InfluxDB o Timescale), non aggiunto dopo. Punto già scritto in "Decisioni da prendere all'inizio" sotto, ma Mauro l'ha chiesto di nuovo esplicitamente prima che arrivasse l'hardware — vale la pena tenerlo in cima quando si monta lo stack, non solo in una sezione più giù nel file.

~~**(12/08/2026) Nel cassetto, non un piano attivo**~~ — **superato il 26/08/2026** (vedi sopra): la finestra pre-15/10 resta comunque non riaperta (confermato di nuovo il 26/08, non è il motivo per cui si parte ora). Il contenuto sotto resta valido come ragionamento tecnico.

**(26/08/2026) Aggiornamento da `@ritorno` claude.ai — recuperato dopo una prima cancellazione errata**: il controllo di coerenza su SecondBrain aveva depositato un promemoria su Zigbee/ZHA che Adrian ha cancellato senza leggerne il corpo (bug di processo: `fetch_pending_tasks()` scarta il campo `body` a monte — vedi gotcha in `.claude/skills/processa-promemoria/SKILL.md` e `archivio/Adrian/feedback/feedback_ritorno_body_prima_di_cancellare.md`). Mauro ha fatto ricreare il promemoria da claude.ai; questa volta il contenuto è stato letto e integrato per bene (sezioni sotto). **Nota sulla causa della prima sparizione**: il promemoria ricreato conteneva un'ipotesi (non verificata) che la perdita fosse dovuta a caratteri non-ASCII nel testo — non è così, la causa reale è la cancellazione esplicita di Adrian descritta sopra, confermata dai log della sessione.

**Importante, chiarito con Mauro lo stesso giorno**: il body attribuiva a Mauro la scelta di ZHA ("decisioni prese da Mauro in questa conversazione") — **non è corretto**, Mauro non ha deciso nulla in quella conversazione claude.ai, è un errore di valutazione del modello che ha scambiato un'ipotesi discussa per una decisione presa. La raccomandazione ZHA qui sotto è invece il giudizio di **Adrian**, dato su richiesta esplicita di Mauro ("dimmi la tua opinione, che è quello che realmente mi interessa") dopo aver letto sia il ragionamento originale del 12/08 sia gli argomenti pro-ZHA del body recuperato — non un'eredità automatica della proposta esterna.

## Perché

Ampliare competenze usando Claude Code, su un dominio dove l'AI tocca hardware reale. La tesi: l'integrazione AI-hardware (fino ai robot) è una direzione che conta, e la competenza scarsa non sarà montare il sensore ma **saper decidere cosa può stare nell'anello di controllo e cosa no**.

Cosa trasferisce davvero a domini futuri (robotica, impianti): non Zigbee né lo YAML, ma la disciplina di far convivere output probabilistici con conseguenze fisiche — sensori che mentono, stato interno che diverge dal reale, azioni da poter annullare.

Curva frazionabile: ogni pezzo funziona da solo, ci si può fermare per mesi senza aver buttato niente.

## Principio architetturale portante

> **AI nell'anello di autoria, non in quello di esecuzione.**

L'agente osserva, propone, scrive la regola. Poi la regola gira da sola — deterministica, attiva anche con l'agente spento e la linea giù.

Conseguenza: due anelli separati fisicamente.

| | Anello 1 — esecuzione | Anello 2 — autoria e analisi |
|---|---|---|
| Cosa | broker + zigbee2mqtt + HA + regole | Claude Code + MCP + time-series |
| Quando | sempre attivo | intermittente, batch notturno |
| Se muore | la casa si ferma | salta un report |

È la stessa forma già adottata con `collect_logs.py`: script puro da cron, l'intelligenza entra dopo, sul risultato.

## Architettura — l'ordine di montaggio conta

```
dongle USB → zigbee2mqtt → Mosquitto (MQTT) → ┬→ Home Assistant  (app, notifiche, integrazioni)
                                              └→ consumer Python → time-series → Claude Code
```

**⚠️ Superata il 28/08/2026 — vedi sezione "Modello per sensori ad alta urgenza" più sotto**: all'arrivo dell'hardware, ripensando al ruolo di Adrian (cresciuto nel frattempo, vedi [[project_trigger_push_scalabile]]) e a un'obiezione di Mauro sul mantenere controllo/debuggabilità sulla parte critica, si è deciso di **tornare al broker fin dal primo giorno** — non solo ZHA. Paragrafo sotto tenuto per il ragionamento originale, non più la decisione attuale.

**Raccomandazione aggiornata (26/08/2026, giudizio di Adrian su richiesta di Mauro — non la posizione originale del 12/08, superata il 28/08)**: partire con **ZHA**, non zigbee2mqtt+broker, per il primo lotto. Il ragionamento sotto ("il mattone di base è MQTT") resta valido in astratto ma presuppone che il progetto vada avanti sul serio — per un'idea "nel cassetto" che potrebbe non partire mai, montare broker+zigbee2mqtt+HA+consumer prima di sapere se un solo sensore vale la pena è complessità anticipata su un'ipotesi. Due cose cambiano il calcolo rispetto ad agosto:
1. **Esiste un MCP server ufficiale di HA** (`/api/mcp`, autenticazione a token, controllo per-entità) — Adrian potrebbe leggere lo stato dei sensori senza costruire/mantenere un consumer Python + time-series da zero.
2. **Il costo di cambiare idea dopo è più basso del previsto**: migrare da ZHA a zigbee2mqtt significa ri-accoppiare i sensori uno per uno, perdendo continuità dello storico solo nel punto della migrazione, non tutto lo storico — non è "la porta murata" descritta sotto.

Il punto dove il broker pagherebbe davvero (non il broker in sé) resta la ritenzione lunga del time-series separata dal recorder di HA — se/quando il progetto si dimostra vivo e questo diventa un'esigenza sentita, non solo teorica, rivalutare.

**Ragionamento originale (12/08/2026, superato dalla raccomandazione sopra ma tenuto per contesto)**: il mattone di base è MQTT, non Home Assistant. zigbee2mqtt è indipendente da HA: pubblica su un bus, HA è solo uno dei consumatori possibili. Mettere il broker per primo costa un container in più e tiene aperta la strada "a mattoncini". Errore da evitare (secondo questo ragionamento): usare l'integrazione Zigbee interna di HA (ZHA), senza broker — un container in meno, ma i dispositivi vivono *dentro* HA e HA diventa il padrone invece di essere un client.

### Glossario minimo
- **Home Assistant (HA)** — software open source, hub domotico locale. Standard di fatto, nessuna vera alternativa nella nicchia. Non è AI: è un motore di regole deterministico.
- **MQTT** — protocollo publish/subscribe. I dispositivi pubblicano su *topic*, i consumatori si iscrivono, il **broker** (Mosquitto) smista. Chi pubblica non sa chi ascolta: è il disaccoppiamento che rende i pezzi sostituibili.
- **zigbee2mqtt** — traduce la radio Zigbee in messaggi MQTT. Database di migliaia di dispositivi supportati: si consulta *prima* di comprare.
- **Frigate** — riconoscimento oggetti locale su stream telecamere (persona/auto/animale). Il "riconosce" deterministico, sotto l'eventuale layer LLM che "capisce".

## Zigbee in due righe

Standard aperto, **nessun lock-in di marca**: lo stesso dongle parla con Aqara, Sonoff, IKEA, Tuya insieme. Rete **mesh**: i dispositivi a corrente (prese, relè) fanno da ripetitori, quelli a batteria no. Una sola presa smart in posizione intermedia copre un appartamento.

Accortezze pratiche:
- dongle su **prolunga USB**, lontano dal case (USB 3 disturba i 2,4 GHz — causa n.1 di reti instabili);
- passare il device al container col path stabile `/dev/serial/by-id/...`, mai `/dev/ttyUSB0`;
- accoppiare **prima** i dispositivi a corrente, lasciarli assestare, poi quelli a batteria.

## Decisioni da prendere all'inizio (costose da rimediare dopo)

1. **Storico separato dal recorder di HA.** Il recorder nasce per l'interfaccia: tiene il dettaglio pieno pochi giorni, poi comprime. Per ragionare su pattern stagionali serve InfluxDB o Timescale accanto, con ritenzione lunga. **I dati non registrati non si recuperano.**
2. **Nomenclatura = schema dati.** `sensor.sala_nord_temperatura` è interrogabile, `sensor.0x00158d00...` no. Rinominare a valle spezza lo storico.
3. **Ridondanza deliberata.** Due sensori nella stessa stanza non sono uno sprecato: sono il modo per distinguere un guasto del sensore da un fenomeno reale. È la prima cosa su cui un agente prende cantonate.
4. **Cosa esce verso il cloud.** Il modello gira comunque su cloud (dati che escono). Mandare **aggregati** — medie orarie per stanza — non lo stream completo: uno storico di sensori di presenza è un profilo dettagliato delle abitudini.

## Vincoli specifici di casa (Segrate)

- **Riscaldamento condominiale a pannelli radianti** → il controllo non è terreno nostro, il **monitoraggio sì**. Circa metà dei pannelli della sala non funziona (termografie); intervento soffiatura/spurgo fissato **10/10/2026**, stagione riaccende dal 15/10.
  → **Finestra vera**: sensori installati e registranti *prima* del 15/10, altrimenti l'inverno passa senza baseline. Delta di temperatura per stanza su settimane = prova ben più solida delle termografie spot da portare allo Studio Perotti, utile anche in vista di un cambio gestore.
- **Contatore elettrico** probabilmente in armadietto condominiale → pinza sul montante non praticabile. Alternative: prese con misura sui carichi grossi (dice *chi* consuma, che è l'informazione utile), oppure porta utente del contatore 2G da abilitare col distributore. **Da verificare com'è messo prima di comprare.**
- **Luci**: relè dietro l'interruttore (pulito, l'interruttore fisico continua a funzionare) richiede il **neutro nella scatola**, spesso assente nelle case di quell'epoca. Aprire una placca e guardare prima di decidere. Alternativa: lampadine smart, ma se qualcuno spegne al muro il sistema è cieco.
- **Telecamere**: vincolo condominiale — solo proprietà propria, non parti comuni. Servono RTSP (le cinesi cloud-only non vanno) e CPU seria o chiave Coral (~40-70€) per Frigate.
- **Terrazzo**: sensore umidità cassette è a batteria → non ripete, e attraversa muro esterno. Serve un ripetitore vicino alla porta-finestra. Irrigazione automatica richiede presa d'acqua + elettrovalvola: se manca il rubinetto resta solo "il telefono ti dice che devi annaffiare".

## Aree, per rapporto valore/attrito

| Area | Costo indicativo | Note |
|---|---|---|
| **Allagamento** | ~10€ × 3 | Sotto lavastoviglie, lavatrice, sifoni. 10€ che evitano un danno da migliaia con vicini di sotto. Il più alto ritorno della lista. |
| **Temperatura/umidità** | 8-12€ × n | Il caso d'uso dei pannelli radianti. Uno per stanza + uno di riferimento. |
| **Prese con misura** | ~12€ × 2 | Doppio scopo: consumi *e* ripetitori mesh. Dal profilo di consumo si deduce lo stato (lavatrice finita → notifica). |
| **Contatti porta/finestra, PIR** | 8-15€ | HA fa da centrale, nessun contratto. Non è antifurto certificato: è "so cosa succede". |
| **Presenza (via telefono)** | 0€ | Nodo che rende sensate metà delle automazioni: "casa vuota" abilita tutto il resto. |
| **CO2** | 60-80€ | NDIR vero, non i VOC che *stimano* il CO2. L'unico sensore che misura qualcosa di non percepibile: in camera si arriva a 1500-2000 ppm entro mattina. |
| **Congelatore** | ~10€ | Serve solo quando sei via — ma è lì che il guasto costa tutto il contenuto. |
| **Umidità cassette** | ~20€ | Lettura sì, irrigazione è un altro salto (vedi vincoli). |
| **Luci** | variabile | Dipende dal neutro. |
| **Telecamere** | alto | Da ultimo, quando il resto gira. |

**Idea trasversale**: HA come cruscotto della *propria infrastruttura*, non solo della casa — temperatura/carico Nave, UPS (blackout → shutdown pulito), e soprattutto stato backup. Una lampadina che diventa arancione quando `latest.txt` è ⚠️ è un canale che non si ignora come si ignora una riga di log. Rilevante dopo il monitoraggio cieco per 16 giorni scoperto il 10/08.

## Primo lotto proposto

Dongle Zigbee + 3 sensori allagamento + 3 temperatura + 2 prese con misura. **Sotto i 150€** (regge con un dongle USB ~25€; salta se si prende un coordinator PoE/LAN, opzione sotto non considerata ad agosto), copre tre aree e dice se lo stack convince prima di investirci sul serio.

### Ricerca sensori temperatura/umidità (26/08/2026, dati di terze parti non verificati sul campo)

Fonte: confronto testa a testa di 12 sensori Zigbee, SmartHomeScene (pubblicato 04/08, aggiornato 14/08), testati su Zigbee2MQTT contro un riferimento calibrato. **Caveat**: sito con link affiliati, un solo autore — una fonte, non una rassegna indipendente.

- **Candidato di default: SONOFF SNZB-02P** — ±0,2°C e ±2% RH dichiarati, batteria CR2477 (4 anni dichiarati, la migliore del gruppo), intervallo di reporting modificabile, unico ad aver ricevuto OTA via Z2M, ~13 USD. Su ZHA (invece di Z2M) funziona ma alcune finezze (intervallo reporting, calibrazione, OTA) hanno interfacce meno comode — da verificare al primo dispositivo.
- **Alternative valide**: SNZB-02B (batterie AAA, campionamento più pulito), Aqara T1/WSDCGQ12LM (più piccolo, riporta anche pressione, ma intervallo di reporting non modificabile — preferire alla T11 più vecchia).
- **Da evitare**: ThirdReality T&H Lite (non segue il trend in modo pulito), Tuya di fascia bassa (ZTH02, UZ-01T — deviazioni più larghe).

### Coordinator — opzioni aperte, nessuna scelta fatta

- Sonoff ZBDongle-E (EFR32MG21, ~25€) — miglior rapporto qualità/prezzo, sufficiente per rete piccola
- HA ZBT-2 / Sonoff Dongle Plus MG24 — chip più recente, antenna migliore
- SMLight SLZB-06MG24 (PoE/LAN) — radio posizionabile ovunque in casa, risolve interferenza USB 3 e posizionamento centrale, costa di più

Tutti riflashabili tra firmware Zigbee↔Thread (non simultaneo). Contesto di mercato (non un driver di decisione): a febbraio 2026 Texas Instruments ha annunciato l'acquisizione di Silicon Labs, effetti su prezzi/supporto EFR32 non noti.

## Passi operativi

1. **Ricognizione a costo zero** — HA in container, auto-discovery: dice cosa c'è già in casa (router, TV, stampante, eventuali dispositivi smart). Un'ora, zero spesa.
2. **Verifiche fisiche prima di comprare** — contatore elettrico (dov'è, quale modello), neutro nelle scatole, presa d'acqua sul terrazzo.
3. **Compose** con `mosquitto`, `zigbee2mqtt`, `homeassistant` — HA in `network_mode: host` (la discovery mDNS/SSDP non funziona in bridge: errore classico del primo tentativo).
4. **Chiusure di sicurezza** — i container Docker bypassano ufw: la 8123 finisce esposta sulla LAN senza che ufw dica nulla. Mosquitto in configurazione base **non ha autenticazione**: utente/password e bind solo dove serve.
5. **Accesso da fuori**: WireGuard, già disponibile. Non esporre HA via Caddy.
6. **Primo lotto**, accoppiamento nell'ordine giusto, nomenclatura decisa prima.
7. **Backup**: config di HA/z2m nel restic esistente. Sono mesi di taratura.
8. **Git**: `automations.yaml`/`scripts.yaml` versionabili bene. `.storage/` è JSON opaco (helper, integrazioni, entità esposte) → git non lo gestisce in modo utile. Conseguenza: **quello che l'agente scrive deve stare nei file YAML**; la parte da interfaccia resta manuale e va nel backup, non nel versionamento.
9. **Layer AI**, solo dopo che ci sono dati: MCP server di HA (integrazione ufficiale, si abilita dall'interfaccia — stessa forma di `mcp-query` ma sugli stati di casa) + MCP sul time-series. Analisi da cron notturno, output su file, hook `SessionStart` che lo mette davanti alla sessione dopo. **L'LLM non è un demone, è un job.**

## Stack montato e primi 3 sensori accoppiati (28/08/2026)

`[CONFERMATO]` — hardware arrivato, stack Docker montato in `sandbox/domotica-iot/` (Mosquitto+zigbee2mqtt+Home Assistant, il broker fin da subito come deciso sopra, non solo ZHA). Dongle Sonoff riconosciuto (chip Ember, firmware 7.4.4), rete Zigbee formata. Piccolo intoppo iniziale: il dongle sembrava instabile (errori USB), risolto reinserendolo meglio nella porta — non era interferenza USB 3, solo un contatto incerto.

**3 sensori SNZB-02P accoppiati e nominati** (nomenclatura decisa prima dell'accoppiamento, come da regola): `cameretta`, `sala`, `camera_letto` — tutti al 100% batteria, letture coerenti tra loro. Dettaglio tecnico completo (compose, sicurezza, permessi) in `sandbox/domotica-iot/CLAUDE.md`.

**Ritenzione lunga fatta lo stesso giorno**: InfluxDB 2.x aggiunto allo stack, collegato a HA via la sua integrazione nativa, filtrato sui tre sensori. Confermato scrivere correttamente (verificato query diretta dopo un report reale dei sensori). **Gotcha reale trovato e risolto**: rinominare in zigbee2mqtt non rinomina l'entity_id in HA senza il flag `homeassistant_rename: true` — i tre sensori erano rimasti con entity_id basati sull'indirizzo IEEE nonostante il nome friendly fosse già giusto, il filtro InfluxDB non matchava nulla senza errori visibili. Corretto editando l'entity registry di HA a mano. Dettaglio tecnico completo in `sandbox/domotica-iot/CLAUDE.md`.

**Posizionamento fisico completato** per tutti e tre i sensori (28/08/2026).

**Backup verificato**: nessuna azione necessaria, `/mnt/ssd/config/domotica-iot/` (vedi sotto) è già dentro il perimetro del restic esistente.

**⚠️ Incidente e correzione architetturale, stesso giorno**: i dati runtime (HA config/db, stato zigbee2mqtt, InfluxDB) erano stati messi dentro `sandbox/domotica-iot/` — cartella sincronizzata da Dropbox. Database che cambiano ogni pochi secondi hanno mandato Dropbox in tilt (tentativi di sync continui, `dropbox exclude` inaffidabile in quella sessione, arrivato a creare più di 10 cartelle "Conflitto di sincronizzazione selettiva"). Risolto spostando tutto lo stato runtime fuori dall'albero Dropbox, in `/mnt/ssd/config/domotica-iot/` — stessa convenzione già in uso per Guacamole/Jellyfin/Portainer. Nessun dato perso (i tre sensori/pairing sopravvissuti alla migrazione, solo ~20 minuti di dati di test InfluxDB persi, irrilevanti). Dettaglio tecnico completo in `sandbox/domotica-iot/CLAUDE.md`.

**(30/08) Leftover della migrazione trovato e ripulito**: la cartella dati pre-migrazione (`sandbox/domotica-iot/{mosquitto,influxdb,homeassistant,zigbee2mqtt}/`) era rimasta dentro Dropbox invece di essere cancellata dopo lo spostamento del 28/08 — ferma, ma comunque mirrorata in chiaro su pCloud (incluso un `homeassistant/config/secrets.yaml`) e causa di "permission denied" ricorrente su 3 notti di backup/mirror consecutive (file scritti come uid 1883 dal container mosquitto, illeggibili dall'utente `mauro`). Rimossa (restano solo `docker-compose.yml`/`.env`/`CLAUDE.md`/`.gitignore`), aggiunta esclusione strutturale dell'intero albero `mosquitto/` in `scripts/backup_completo_exclusions.txt` + `scripts/pcloud_backup.sh`. Lezione: un errore identico che si ripete notte dopo notte va controllato nello storico log, non ripatchato ogni volta come nuovo. Sensori confermati vivi e regolari lo stesso giorno (temperature 27-28°C, umidità 49-53%, batterie 100%).

## Modello per sensori ad alta urgenza (es. intrusione) — deciso 28/08/2026, non ancora hardware

Discusso prima dell'arrivo di un eventuale sensore di intrusione (oggi il primo lotto è solo temperatura/umidità), per avere il modello già pronto. Punto di partenza: [[project_trigger_push_scalabile]] (thread separato sui meccanismi di trigger/push verso Adrian) e la scelta architetturale del broker fatta oggi stesso — vedi sopra, "Raccomandazione aggiornata" superata da questa conversazione: **si parte col broker (zigbee2mqtt+Mosquitto), non solo ZHA**, proprio per questo motivo.

**Perché non un'automazione HA per la decisione critica**: prima proposta di Adrian era "automazione HA → notifica via app companion HA". Mauro ha obiettato, non per motivi di "dipendenza esterna" in astratto (una notifica push tocca comunque Apple/Google da qualche parte, inevitabile), ma per un punto più preciso: **se il motore di HA si comporta in modo strano, Adrian debugga codice di qualcun altro (HA, ~300k righe), non il proprio** — perde capacità di intervento rapido proprio sulla parte critica.

**Modello deciso**:
```
dongle → zigbee2mqtt → Mosquitto → ┬→ Home Assistant (solo pairing/mesh radio — nessuna decisione)
                                    └→ script nostro (letto/scritto da Adrian) → decide allarme → PushNotification
```
- **HA fa solo da traduttore radio→dati** (pairing, gestione mesh Zigbee) — ruolo che ha senso lasciargli, reinventare un gestore Zigbee da zero sarebbe sforzo ingiustificato (è lo standard di fatto).
- **La decisione "questo è un'intrusione, avvisa Mauro" vive in uno script scritto da Adrian**, che legge direttamente dal bus MQTT (non da un'automazione YAML di HA) — se qualcosa non funziona, il codice da aprire e riparare è il nostro, non quello di HA.
- Notifica finale via `PushNotification` (raggiunge il telefono via Remote Control), non via l'app companion di HA (che passerebbe da Nabu Casa/Firebase, un'altra dipendenza in più senza vantaggio).
- **Nessun LLM nel percorso decisionale** — lo script è codice deterministico puro, coerente col principio "AI nell'anello di autoria, mai in quello di esecuzione" già scritto sopra in questo stesso file. Il ruolo di Adrian eventualmente è arricchire *dopo* che l'allarme di base è già scattato (contesto aggiuntivo), mai sostituirlo.

**Non ancora costruito**: nessun sensore di intrusione nel primo lotto attuale (solo temperatura/umidità) — questo resta il modello di riferimento per quando arriverà, non un'implementazione da fare ora.

## Cosa NON fare

- **Comando vocale via LLM.** Latenza di secondi, esito non deterministico. Per accendere una luce l'interruttore resta migliore. La domanda in linguaggio naturale sullo *storico* invece vale, perché lì l'alternativa non esiste.
- **LLM nel percorso critico di un allarme.** La regola deterministica scatta comunque; l'AI si aggiunge sopra una notifica già arrivata (descrizione contestuale: "una persona con uno scatolone", non classificazione "persona" — quella la fa Frigate meglio e più in fretta).
- **Splittare/complicare in anticipo** per una crescita ipotetica.

## Riserve oneste

- Il grosso del lavoro **non è HA** (parte facile e risolta) ma nomenclatura, dati e regole.
- HA aggiorna ogni mese; ogni tanto un breaking change chiede mezz'ora. Non è "installa e dimentica".
- Rete separata (VLAN o SSID guest) per i dispositivi IoT cinesi.
- **La domanda vera non è se HA, è se è il momento.** Aperti: `gate-ufficio` a metà, domanda PyQt6/MyICR (~~password sudo Avamposto non ruotata~~ **risolto il 12/08 stesso**, la nota era già stantia il giorno in cui è stata scritta). La scadenza reale (pre-15/10) riguarda solo i sensori di temperatura, non tutto il resto — **confermato ancora invariato il 26/08**: l'intervento soffiatura/spurgo pannelli radianti resta in calendario 10/10/2026 09:00-10:00 (Sig. Nozzolino, accordo Studio Perotti 26/02/2026); verifica fatta leggendo il calendario, non confermata col tecnico. La finestra pre-15/10 **non è stata riaperta**: resta nel cassetto come deciso il 12/08.