Appunti di Simon

13. Bluetooth proxy, Assist, Zigbee e Thread

7 minuti

Fin qui l’ESP32 è stato un sensore o un attuatore: qualcosa che misura o che comanda. Questo capitolo parla dei ruoli in cui l’ESP32 non ha niente attaccato e serve lo stesso: fa da ponte per il Bluetooth, da orecchio per l’assistente vocale, o si presenta in casa come un nodo Zigbee invece che come un dispositivo Wi-Fi.

Sono le applicazioni con il miglior rapporto fra risultato e fatica dell’intero corso, perché non richiedono saldature, cablaggi o scatole: si compila una configurazione, si infila il chip in una presa USB, e la casa funziona meglio. In questo capitolo vediamo il Bluetooth proxy, i satelliti vocali per Assist, e cosa cambia quando l’ESP32 esce dal Wi-Fi.

Bluetooth proxy: il progetto da fare per primo

Home Assistant può parlare direttamente con i dispositivi Bluetooth Low Energy, ma solo con quelli che il server riesce a sentire. Il Bluetooth ha una portata di dieci-quindici metri in campo libero e molto meno attraverso i muri: se il server sta in cantina, i sensori BLE del primo piano non esistono.

Un Bluetooth proxy è un ESP32 che ascolta il traffico BLE nella sua zona e lo inoltra a Home Assistant sul Wi-Fi. Ne metti tre o quattro sparsi per casa e improvvisamente tutta la superficie è coperta.

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true
 
bluetooth_proxy:
  active: true

Sono sei righe, e il device non ha bisogno di nient’altro: il chip nudo dentro un alimentatore USB da parete. Costo cinque euro l’uno.

Cosa ci guadagni concretamente:

  • Sensori Xiaomi/Mijia di temperatura e umidità (quelli da 5 € con lo schermo LCD) diventano leggibili in tutta la casa.
  • SwitchBot: i pulsantini robotici, le tende, i termoigrometri, funzionano senza il loro hub.
  • Termovalvole BLE come le Xiaomi o le Tuya.
  • Presenza per stanza: i tag BLE e gli smartwatch vengono visti dal proxy più vicino, e con l’integrazione Bermuda si ottiene una localizzazione per stanza abbastanza affidabile senza installare niente addosso alle persone.
  • Bilance, sensori di piante, luci BLE e un lungo elenco di dispositivi economici.

L’active: true fa sì che il proxy interroghi attivamente i dispositivi invece di limitarsi ad ascoltare gli annunci: serve per i device che richiedono una connessione, come le SwitchBot. Consuma un po’ più di banda radio ma vale la pena.

Un’avvertenza: il Bluetooth e il Wi-Fi condividono la stessa antenna e la stessa banda a 2,4 GHz. Un proxy attivo tiene la radio occupata, quindi non caricare un Bluetooth proxy di altri compiti: niente sensori collegati, niente display. Un chip da cinque euro per fare una cosa sola è la scelta giusta. Sulle interferenze in banda 2,4 GHz, il tema è già trattato in Wi-fi 2.4 Ghz.

Satelliti vocali per Assist

Assist è l’assistente vocale di Home Assistant, e la sua caratteristica è che può funzionare interamente in locale: riconoscimento vocale, comprensione e sintesi girano sul tuo server, senza mandare niente a nessun cloud. Il problema è avere dei microfoni in giro per casa, e comprare altoparlanti smart commerciali vanificherebbe tutto il discorso sulla privacy.

Un ESP32-S3 con microfono e altoparlante risolve esattamente questo. Il chip cattura l’audio, rileva la parola di attivazione (con microWakeWord, che gira sul chip stesso), invia il flusso a Home Assistant, e riproduce la risposta.

Due strade. La prima è comprare hardware già fatto: l’Home Assistant Voice Preview Edition ufficiale, oppure un ESP32-S3-BOX, che arrivano montati e con la configurazione pronta. La seconda è assemblarlo: un S3 DevKit, un microfono I²S (INMP441 o simili), un piccolo amplificatore I²S e un altoparlante. Costa meno ma richiede un po’ di lavoro, e per il primo tentativo consiglio l’hardware pronto: quando l’assistente non capisce, poter escludere che il problema sia il microfono vale la differenza di prezzo.

L’S3 con PSRAM è un requisito reale: il buffer audio e il modello di wake word hanno bisogno di memoria che i chip più piccoli non hanno.

L’ESP32 fuori dal Wi-Fi: Zigbee e Thread

Le famiglie C6 e H2 hanno una radio 802.15.4, che è il livello fisico su cui girano Zigbee e Thread. Questo apre una possibilità diversa: invece di essere un dispositivo Wi-Fi che parla con Home Assistant, l’ESP32 diventa un nodo della rete mesh, esattamente come un sensore Zigbee commerciale.

Cosa ci si guadagna:

  • Consumi molto più bassi. È la differenza fra mesi e anni di autonomia a batteria, per le ragioni viste in 12 Automazioni on-device e deep sleep.
  • Mesh invece di stella. I dispositivi alimentati fanno da ripetitori e la copertura si estende da sola, invece di dipendere tutta dall’access point. Il funzionamento è descritto in Zigbee e Thread.
  • Nessun carico sul Wi-Fi. Venti sensori Wi-Fi su un access point domestico sono venti client che occupano slot; venti nodi Zigbee non pesano sulla rete dati.

Cosa ci si perde:

  • Il supporto ESPHome è più recente e meno completo di quello Wi-Fi. Funziona, ma con meno componenti disponibili e meno documentazione.
  • Niente API nativa e niente OTA come lo conosci: aggiornare un device Zigbee è un’altra cosa rispetto al ciclo di trenta secondi a cui ti sei abituato.
  • Serve un coordinator Zigbee già funzionante in casa, con tutto quello che comporta in termini di setup (15 Zigbee Matter setup).

Ho fatto esattamente questa scelta per un sensore di presenza, e i motivi e i risultati sono nel progetto 3 SENSORE DI PRESENZA mmWave con HLK-LD2410S e XIAO ESP32-C6 (con Zigbee): un sensore mmWave che in Wi-Fi sarebbe stato l’ennesimo client sull’access point, e in Zigbee è un nodo che si comporta come tutti gli altri sensori di casa.

La regola pratica: resta sul Wi-Fi finché non hai un motivo specifico per uscirne. Il Wi-Fi ha l’ecosistema ESPHome completo, l’OTA veloce e l’API nativa. Passa a Zigbee/Thread quando il motivo c’è: batteria che deve durare anni, troppi device sull’access point, o un sensore che deve stare dove il Wi-Fi non arriva ma la mesh sì.

MQTT: quando serve parlare con qualcos’altro

L’ultimo ruolo è meno appariscente ma capita più spesso di quanto si creda. L’API nativa collega il chip solo a Home Assistant. Se il dato deve arrivare anche altrove, Node-RED, un dashboard esterno, InfluxDB, un altro sistema di automazione, la strada è MQTT.

mqtt:
  broker: 192.168.1.10
  username: !secret mqtt_user
  password: !secret mqtt_password
  discovery: true

Con discovery: true il chip si annuncia da solo e Home Assistant lo trova senza configurazione aggiuntiva, esattamente come farebbe con l’API nativa. Il protocollo è spiegato in MQTT (Message Queuing Telemetry Transport).

Si possono tenere accesi API nativa e MQTT insieme, ma raddoppia il traffico radio e serve raramente. La cosa da sapere è che attivare MQTT non ti fa perdere niente: resta un device ESPHome normale, con OTA e Device Builder che funzionano come sempre.

Ricapitolando

  • Un Bluetooth proxy è un ESP32 nudo in una presa che estende la copertura BLE di Home Assistant: sei righe di configurazione, 5 €.
  • Rende utilizzabili sensori Xiaomi, SwitchBot, termovalvole BLE, e abilita la presenza per stanza con Bermuda.
  • Non caricare un proxy di altri compiti: Bluetooth e Wi-Fi condividono antenna e banda.
  • Un ESP32-S3 con microfono diventa un satellite vocale per Assist, con riconoscimento della wake word sul chip e tutto il resto in locale.
  • Per il primo satellite vocale conviene l’hardware pronto (Voice PE, S3-BOX): elimina il microfono dalla lista dei sospetti.
  • C6 e H2 possono uscire dal Wi-Fi e presentarsi come nodi Zigbee o Thread: consumi bassi, mesh, nessun carico sull’access point.
  • Il prezzo è un supporto ESPHome meno maturo e la perdita dell’OTA veloce: resta sul Wi-Fi finché non hai un motivo per uscirne.
  • MQTT serve quando il dato deve andare anche fuori da Home Assistant; con discovery: true la scoperta resta automatica.
  • Se devi scegliere da dove partire: Bluetooth proxy, è il progetto con il miglior rapporto risultato/fatica del corso.

Vista grafico

Link entranti