SCOPI DEL PROGETTO:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTILIZZATE:
COMPONENTI FISICI UTILIZZATI:
|
PROGETTO MAGGIORMENTE INDICATO PER:
|
|
NOTE E DISCLAIMER
|
|
| Revisione progetto: 1.4 | |
Abstract
Chi decida di adottare ZigBee quale protocollo di comunicazione per alcuni componenti della propria domotica personale basata su HUB personali quasi certamente avrà optato per l’adozione di un BRIDGE/Gateway che traduca le comunicazioni da e per i componenti basati su questo standard verso uno standard direttamente comprensibile dall’HUB personale in uso.
Le soluzioni più efficacemente battute sono, solitamente:
 |
deCONZ con l’adozione delle antenne ConBee o RaspBee
BRIDGE/Gateway ZigBee↔︎TCP/IP |
 |
ZigBee2MQTT con l’adozione di antenne supportate
BRIDGE/Gateway ZigBee↔︎MQTT |
Tali soluzioni consentono l’integrazione di un’ampissimo numero di componenti ZigBee presso gli HUB personali più diffusi come Home Assistant, openHAB, Domoticz e così via; la caratteristica comune è quella di installare l’antenna sul computer (solitamente quello sul quale è in esecuzione l’HUB) e installare un software che provveda, utilizzandola, al servizio in questione.
Solitamente, il fulcro della rete ZigBee (il coordinator) è rappresentato dall’antenna la quale, ovviamente, ha una specifica copertura radio legata ovviamente alle condizioni strutturali dell’ambiente in cui è calata; quando la copertura radio è limitata, la soluzione è solitamente quella di introdurre dei componenti ZigBee alimentati a rete elettrica (non a batteria), i quali fungono (proprio perché alimentati a rete elettrica) da ripetitori (router). Questo, solitamente, basta e avanza per garantirsi una copertura sufficiente: in questi frangenti di solito si utilizzano lampadine ZigBee (tipo le Philips HUE, per capirci).
Quando, per motivi diversi, tale escamotage non fosse sufficiente, allora si avrebbe un bel grattacapo da risolvere. Pensiamo infatti ad appartamenti multi-livello: talvolta muri e i solai schermano il segnale ZigBee (ma magari non il Wi-Fi) e la soluzione “delle lampadine” per diversi motivi può non essere sufficiente.
Come risolvere?
La soluzione ci può venire dalla realizzazione di uno o più BRIDGE/Gateway del tutto autonomo/i rispetto al computer dove sia in esecuzione l’HUB (come nei casi di deCONZ e ZigBee2MQTT sopra spiegati), degli elementi da posizionarsi in casa dove meglio si creda, così da ottenere una sufficiente copertura in tutti gli angoli della casa. In questo progetto proponiamo proprio una di queste soluzioni: l’unica esigenza, in questa logica, sarà che il BRIDGE/Gateway realizzato venga poi posizionato in un punto dove sia almeno garantita la copertura Wi-Fi, standard che utilizzerà per le trasmissioni verso l’HUB personale in uso.
Nello specifico andremo infatti a realizzare un BRIDGE/Gateway ZigBee↔︎MQTT, ovvero un BRIDGE che trasformi le comunicazioni da/per i componenti ZigBee in telemetrie MQTT. Sostanzialmente quello che fa anche ZigBee2MQTT, con la differenza che in questo caso il BRIDGE/Gateway non è in esecuzione su un computer ma su un elemento autonomo, posizionato dove si crede.
La lista dei componenti ZigBee compatibili con questo BRIDGE/Gateway basato su Zigbee2Tasmota è disponibile qui.
| N.b. La soluzione proposta può essere realizzata e introdotta nel proprio ambiente anche in presenza di uno o entrambi i due sistemi precedentemente elencati. Ovviamente ogni componente ZigBee potrà essere abbinato a uno e un solo BRIDGE/Gateway, non a più d’uno contemporaneamente. |
| N.b. Alternativo a questo componente – ma concepito sulla stessa filosofia – è il SLSys Gateway, anche noto come “il gateway russo”. |
Si parte
Descrizione progetto
Sostanzialmente il dispositivo fisico che andremo a realizzare si comporrà di due parti connesse tra loro:
- la componente “intelligente” rappresentata da un NodeMCU o affini (Wemos o altri compatibili Tasmota);
- l’antenna Zigbee, ovvero una CC2530 o affini (CC2591 o altri).
Dato che il firmware Tasmota dalla versione 6.7 in poi è dotato di una funzionalità ZigBee chiamata ZigBee-To-Tasmota (Z2T), tramite l’intelligenza del NodeMCU (sul quale lo installeremo) e l’antenna CC2530 riusciremo a definire un coordinator ZigBee il grado di dialogare, via Wi-Fi, con un broker MQTT, inviando telemetrie e ricevendo comandi MQTT. Un vero e proprio BRIDGE/Gateway ZigBee↔︎MQTT.
Dato che solitamente anche gli HUB personali dialogano senza problemi tramite MQTT, essi saranno in grado di ricevere telemetrie e inviare comandi MQTT verso questo componente, realizzando quindi l’agognata integrazione dei componenti ZigBee ad esso attestati.
Il modello descritto di fatto è identico a quello di ZigBee2MQTT, con la differenza che in quel caso (solitamente) broker MQTT, BRIDGE/Gateway ZigBee↔︎MQTT e HUB personale convivono nello stesso computer, nel modello proposto in questo progetto nel computer (quale sia) rimarrà l’HUB personale e il broker MQTT, mentre il BRIDGE/Gateway ZigBee↔︎MQTT sarà collocato nel dispositivo che andremo a realizzare.
Il canale di dialogo tra computer e BRIDGE/Gateway sarà, per l’appunto il Wi-Fi. consentendo ai vari soggetti di rimanere fisicamente separati. Questo consente di: installare uno o più BRIDGE/Gateway ZigBee↔︎MQTT totalmente autonomi.
Passaggi
I passaggi operativi per la realizzazione del presente progetto sono sostanzialmente i seguenti:
- programmazione dell’antenna CC2530 con firmware adeguato agli scopi;
- programmazione del NodeMCU con firmware Tasmota (versione uguale o superiore alla 6.7)
- connessione dei due componenti hardware
- configurazione NodeMCU
- messa in esercizio.
Programmazione CC2530
La programmazione dell’antenna CC2530 è una condizione necessaria e minimale per far sì che, successivamente, il NodeMCU dotato di firmware Tasmota sia in grado di sfruttare il protocollo trasmissivo ZigBee.
La programmazione si effettua facilmente utilizzando un programmatore CC Debugger (o similari, come per esempio lo Smart RF04EB) e dei cavi di connessione Dupont: una volta scelto il firmware è sufficiente collegare l’antenna al programmatore, il programmatore al computer di appoggio (via USB) e utilizzare il software (variabile da sistema operativo a sistema operativo) per provvedere alla programmazione vera e propria.
Dato che i passi per la programmazione sono svariati, abbiamo deciso di dedicare una guida ad hoc a tale processo (la guida riporta già la scelta appropriata del firmware necessario per la realizzazione del presente progetto).
Una volta terminata la procedura è possibile passare oltre nell’esecuzione del processo.
Programmazione NodeMCU
Analogamente all’antenna CC2530, anche il NodeMCU necessita, allo scopo, di un firmware specifico. In questo caso va bene qualsiasi versione del firmware Tasmota.
Per programmare un NodeMCU (ma, comunemente, qualsiasi componente basato su SOC ESP8266) è necessario un computer di appoggio e un’interfaccia USB/TTL la quale, connessa a specifici pin del componente, permette appunto di riprogrammarne il firmware.
Per la riprogrammazione di NodeMCU con firmware Tasmota abbiamo ritenuto opportuno pubblicare, anche in questo caso, una guida ad hoc, la quale seguita in modo puntuale consente di raggiungere lo scopo.
Il firmware consigliato è banalmente, l’ultima versione disponibile di Tasmota, quale che sia.
| N.b. Il NodeMCU può essere, come da tradizione, alimentato come meglio si crede, in modi molto diversi tra loro, non solo necessariamente via Micro USB. |
Connessione dei due componenti
Una volta programmati in modo opportuno sia l’antenna CC2530 che il NodeMCU, siamo pronti per collegarli tra loro. Per farlo useremo dei cavetti di connessione Dupont (femmina-femmina).
Le connessioni da realizzare sono le seguenti:
Gli schemi di piedinatura dei due componenti, a seguire:
NODEMCU
CC2530
Una volta terminato l’assemblaggio, il consiglio è quello di installare il tutto in una scatolina per elettronica, come da foto che seguono.
Configurazione NodeMCU
Una volta riprogrammati il NodeMCU e la CC2530, connessi tra loro e rialimentato il NodeMCU, è il momento di configurare ZigBee sul firmare Tasmota (in modo da istruirlo nell’uso della propria componente ZigBee-To-Tasmota tramite l’antenna connessa al modulo) e abilitare il protocollo MQTT.
ZigBee-To-Tasmota
Una volta acceso, il modulo NodeMCU entrerà nella propria rete Wi-Fi acquisendo un indirizzo IP (scoperto direttamente post-riprogrammazione). Collegarsi tramite browser a tale IP per accedere all’interfaccia di configurazione.
In alto verrà indicato il modello “Sonoff Basic“, in quanto il firmware Tasmota è ancora configurato in modalità default. Sarà quindi necessario entrare nel menu “Configuration” > “Module Configuration” e scegliere il modello più adatto in base al dispositivo fisicamente in uso.
In questo caso, trattandosi NON di un componente ITEAD, l’impostazione relativa la configurazione sarà “Generic”; impostare poi le funzionalità TX e RX come da figura che segue:
Terminata la configurazione, cliccare su “Save“.
MQTT
Sempre presso l’interfaccia di configurazione Tasmota accedere alla sezione “Configuration” > “MQTT”.
Impostare quindi i seguenti campi:
- alla voce “Host“, inserire l’IP del broker MQTT (solitamente ospitato su Raspberry);
- alla voce “Port“, inserire la porta del broker MQTT (solitamente la 1883);
- alla voce “Client“, inserire il nome che desiderate assegnare al Sonoff in ambito MQTT (in questo caso, “Tavolo”);
- alla voce “Topic“, inserire il nome che desiderate assegnare al Sonoff in ambito MQTT (in questo caso, “Tavolo”);
- alla voce “User“, inserire l’eventuale username per accedere al broker;
- alla voce “Password“, inserire l’eventuale username per accedere al broker.
Terminata la configurazione, cliccare su “Save“.
| N.b. Si consiglia inoltre di leggere con attenzione anche la guida dedicata al tema della configurazione dei componenti MQTT nella propria domotica. |
Verifica
Se tutto sarà andato per il verso giusto, al termine del riavvio del NodeMCU, accedendo alla “Console” sempre da interfaccia web di Tasmota, nel logo si potrà rintracciare un messagio di questo tipo:
{“ZbState”:{“Status”:1,”Message”:”CC2530 booted”,”RestartReason”:”Watchdog”,”MajorRel”:2,”MinorRel”:6}}
il quale confermerà la corretta configurazione e funzionamento di ZigBee-To-Tasmota e della connessione MQTT verso il broker.
Per approfondire il significato dei singoli stati censiti su “Console” (relativi alla funzionalità specifica ZigBee) far riferimento alla pagina dedicata sul progetto Tasmota.
Uso
Il BRIDGE/Gateway così realizzato è pronto per l’uso quotidiano: per far sì che i componenti ZigBee che si vuole coordinare tramite esso è necessario attivare la modalità di pairing. Effettuato il pairing, è possibile utilizzarlo normalmente, integrandolo verso gli HUB personali.
PAIRING
Per attivare tale modalità necessario eseguire un comando MQTT direttamente in “Console” Tasmota o pubblicando tale comando sul broker, in modo che il client (il nostro dispositivo) lo riceva e lo esegua.
Il comando per attivare la modalità di pairing per 60 secondi è il seguente:
cmnd/sonoff-z2t/ZbPermitJoin 1
oppure, per attivarlo perennemente (almeno fino al successivo reboot del dispositivo):
cmnd/sonoff-z2t/ZbPermitJoin 99
Per disattivarlo manualmente, invece:
cmnd/sonoff-z2t/ZbPermitJoin 0
Attenzione: il comando può variare in base al nome client MQTT impostato presso la voce “Topic” nella sezione del menu Tasmota “Configuration” > “MQTT”: se per esempio il nome client fosse pippo, il comando cambierebbe come di seguito:
cmnd/pippo/ZbPermitJoin 1
INTEGRAZIONI
Una volta effettuato l’associazione di un componente ZigBee col nostro BRIDGE/Gateway noteremo da subito – sempre presso la “Console” di Tasmota, oppure mettendoci in ascolto sul broker – dei topic telemetrici di questo tipo:
MQT: tele/sonoff-z2t/SENSOR = {"ZbReceived":{"0x8987":{"Voltage":3.015,"Battery":100,"AqaraUnknown":0,"Power":on, "LinkQuality":26}}}
Ognuno di essi contiene un payload JSON che contiene le letture provenienti dal componente associato (in questo caso in sensore identificato da “0x8987“).
Tasmota, purtroppo, ha il vizio (per ora) di inviare un unico topic telemetrico e accettare in ingresso un unico topic di comando per tutti i componenti ZigBee tramite esso integrati, differenziandoli appunto tramite i contenuti del payload JSON in essi contenuti. Vada sé che l’integrazione presso gli HUB personali preveda di iscriversi/inviare tali topic e, tramite l’uso di template, modellare delle entità specifiche presso l’HUB.
Esempio
Poniamo di aver associato un sensore di apertura varchi della Xiaomi/LUMI al nostro BRIDGE/Gateway. Per integrarlo come sensore binario presso Home Assistant (uno dei tanti, possibili HUB personali in uso), il codice sarebbe il seguente:
mqtt: binary_sensor: - name: "Sensore apertura finestra" state_topic: "tele/sonoff-z2t/SENSOR" availability_topic: "tele/sonoff-z2t/LWT" payload_available: "Online" payload_not_available: "Offline" value_template: > {% if '0x8987' in value_json.ZbReceived and 'Power' in value_json.ZbReceived['0x8987'] %} {{ value_json.ZbReceived['0x8987'].Power }} {% else %} {{ false if states('binary_sensor.sensore_apertura_finestra') == "off" else true }} {% endif %} payload_on: true payload_off: false device_class: "window"
Si sfrutta il blocco “value_template” per analizzare la presenza dello specifico codice del sensore (“0x8987“) e, quindi, per verificare se il suo stato (campo “Power”) sia acceso o spento, esportando tale stato al sensore su Home Assistant.
| N.b. Data l’ampiezza degli scenari di integrazione, dedicheremo a tale tema delle guide specifiche che linkeremo qui sotto. L’esempio è proposto è per far capire quale sia la strada da battere in fase di integrazione verso gli HUB personale dei componenti associati al BRIDGE/Gateway. |
| Questa pagina è redatta, manutenuta e aggiornata dallo staff di inDomus, un gruppo di persone molto diverse tra loro che trovi, per domande e supporto, sul forum e sulla chat del sito. Alcuni link sono taggati in qualità di affiliati Amazon e riceviamo un compenso dagli acquisti idonei, utile al sostenimento del sito, ma le nostre recensioni sono tutte indipendenti e non sponsorizzate. Se ti sei perso, a tua disposizione c'è la mappa. |