MQTT nella domotica personale: come configurare il broker e i vari client

MQTT, acronimo di Message Queue Telemetry Transport è semplice ma efficacissimo servizio di rete concepito allo scopo di scambiare rapidamente messaggi da e per componenti e dispositivi domotici o di diversa natura. Tali “messaggi” transitano in modo bidirezionale e vengono utilizzati sia per “comandare” i cambi di stato dei componenti sia per raccoglierne le risposte, le eventuale telemetrie e, più genericamente, informazioni da essi prodotte.

Una spiegazione veloce
MQTT nella domotica personale
- Come configurare i vari soggetti
  - BROKER
  - CLIENT (Sonoff, Shelly e similari)
  - HUB personali (Home Assistant, Homey, openHAB ecc.)
- Come effettuare dei test

Una spiegazione veloce

Il funzionamento è davvero semplice, concettualmente: nello scenario tipico di un ambiente domotico basato di rete LAN/Wi-Fi esiste (si implementa) un broker MQTT, il quale funge da smistatore di messaggi, e poi dei client MQTT, i quali inviano e ricevono tali messaggi.

Esempi di broker MQTT sono i più disparati: uno dei più noti e utilizzati è Eclipse Mosquitto, il quale è anche disponibile per esempio come add-on per Home Assistant OS, oppure come applicazione container su Docker. e in molte altre declinazioni.

Esempi di client MQTT sono:

componenti/dispositivi abilitati all’uso di MQTT (ad esempio un componente Sonoff dotato di firmware Tasmota o ESPHome, oppure uno Shelly debitamente configurato);
un qualsiasi HUB personale (Home Assistant, Homey, openHAB ecc.);
un computer, uno smartphone, un tablet che utilizzino un qualsiasi client MQTT.

Il meccanismo è molto semplice: ogni client può “registrarsi” al broker come publisher (editore) e/o come subscriber (sottoscrittore).

Il ruolo di publisher prevede la pubblicazione presso il broker di messaggi MQTT, mentre quello da subscriber prevedere la ricezione da parte del broker di tutti i messaggi da esso ricevuti contenenti una data firma/firme ai quali il soggetto si è, appunto, “iscritto”. La “firma” è definita nel “topic”, il quale è una stringa contenente una serie di informazioni relative al dispositivo e al tipo di messaggio (che sia per esempio telemetrico o di comando).

I messaggi MQTT sono formati da un topic e da un payload (“carico utile”), ovvero un certo set di informazioni che saranno utili a uno o più riceventi in ascolto presso il broker.

Ipotizziamo di avere un sensore di temperatura iscritto sul broker come publisher che pubblichi automaticamente (ogni tot) un messaggio MQTT contenente la telemetria della temperatura da esso rilevata e due subscriber registrati in ascolto su quel dato topic presso il broker, tali subscriber riceverebbero (ogni tot) la temperatura attraverso un messaggio MQTT giratogli dal broker contenente la temperatura contenuta nel payload.

Un esempio di topic “telemetrico” potrebbe essere:

stat/SensoreCamera/sensor

con relativo payload (in notazione JSON)

{“Time”:”1980-01-01T00:00:01″,”AM2301″:{“Temperature”:18.8,”Humidity”:60.7},”TempUnit”:”C”}

(come si nota, esso contiene la temperatura oltre ad altre informazioni relative a data, ora, tipo di sensore eccetera).
Sottoscrivendo quel topic, a ogni pubblicazione tutti i subscriber ne riceveranno il contenuto.

Analogamente, i messaggi di comando (eg. accensione/spegnimento di un interruttore intelligente MQTT) sono formati da un topic (contenente il “nome” del destinatario) e da un payload (contenente l’azione da eseguire). Qualunque client MQTT che abbia sottoscritto come subscriber quel topic verrà ingaggiato ad eseguire un’azione a fronte della pubblicazione presso il broker di un messaggio destinato, appunto, a quel topic.

Un esempio di topic “di comando” potrebbe essere:

cmnd/Luce/power

con relativo payload (o messaggio) in notazione JSON:

{“ON”}

Tale esempio è relativo al comando di accensione di un dispositivo chiamato “Luce” dotato di firmware Tasmota.
Chi sottoscrive presso il borker quel topic è solitamente il dispositivo stesso, mentre chi pubblica i messaggi di comando in questo caso è l’HUB personale.

Ovviamente, come spiegato, i subscriber in ascolto su un dato topic possono essere molteplici; inoltre, i publisher possono senza limitazioni pubblicare sul broker quanti e quali messaggi vogliono. Non c’è alcun controllo sulla sorgente del messaggio: il broker si limita a riceverli e poi a girarli a chiunque sia sottoscrittore di quel dato topic.

MQTT nella domotica personale

Solitamente nella domotica personale si presenta uno scenario piuttosto tipico, con la presenza di:

uno o più componenti/dispositivi MQTT;
uno o più HUB personali;
un broker MQTT.

Il broker MQTT è solitamente unico e locale, in quanto funge da collettore per lo scambio di tutti i messaggi MQTT relativi alla domotica e risiede, solitamente, su un computer specifico, esso sia basato su Windows, su macOS o sia un Mini PC o un Raspberry Pi.

Ipotizziamo di avere uno scenario in cui un HUB personale abbia in configurazione un’entità che rappresenta un interruttore MQTT al quale, se attivato/disattivato, inviare il relativo messaggio di comando MQTT e dal quale ricevere, in risposta, il suo nuovo stato (attivato/disattivato).

La sequenza sarà la seguente:

l’utente aziona l’interruttore presso l’HUB personale (da interfaccia web, app mobile, comando vocale – quel che è);
l’HUB personale formatta e invia un messaggio di comando MQTT destinato all’interruttore intelligente in base alla configurazione attribuitagli:
- col topic contenente le informazioni relative al tipo di comando e al destinatario;
- col payload contenente l’azione da eseguire
il broker riceve il messaggio MQTT;
il broker verifica se e quale client MQTT abbia sottoscritto il topic contenuto nel messaggio (in questo caso, il dispositivo da comandare);
il broker gira al client MQTT (il componente/dispositivo) il messaggio MQTT;
il dispositivo, che sa cosa fare alla ricezione di un messaggio dal tale topic e dal tale payload, esegue l’azione;
il dispositivo formatta e invia un messaggio telemetrico MQTT a grandi linee così concepito:
- contenente un topic che identifica il messaggio come telemetrico e il fatto che sia prodotto da lui (non ha un “destinatario”, è semplicemente un “alzare la mano per comunicare qualcosa”);
- contenente un payload contenente la risposta all’azione appena eseguita;
il broker riceve il messaggio MQTT;
il broker verifica se e quale client MQTT abbia sottoscritto il topic contenuto nel messaggio (in questo caso, l’HUB personale, che avrà nella configurazione dell’interruttore appena comandato non solo il topic di comando, ma anche il topic telemetrico da sottoscrivere per ottenere le risposte);
il broker gira al client MQTT (l’HUB personale) il messaggio MQTT;
l’HUB personale assume la risposta in base al contenuto del payload e relativa interpretazione (eg. “ON” indicherà, banalmente, l’avvenuta accensione dell’interruttore).

Il tutto in una frazione di secondo.

Come configurare i vari soggetti

Innanzitutto è importante chiarire una cosa: è necessario che il broker MQTT possegga un IP statico (eg. 192.168.1.90) o un nome multicast DNS (mDNS eg. broker.local) statico, invariabile, all’interno della propria rete. Questo perché TUTTI i client MQTT (di qualunque tipo) saranno “puntati” verso esso e dovranno poterlo contattare sempre senza che esso cambi. Al cambiare dell’IP o del nome mDNS del broker, tutte le configurazioni dei vari componenti/dispositivi andrebbero a farsi benedire e smetterebbero di funzionare.

L’indirizzo IP dei client MQTT (di qualunque tipo) può invece serenamente variare. Questo perché ogni client che si presenta al broker, si autentica e poi sottoscrive (e/o pubblica) uno o più topic, viene automaticamente ricordato dal broker stesso, quindi il variare dell’IP non ha alcun effetto negativo.

BROKER

Il broker può assumere qualunque IP o nome mDNS, purché una volta impostato, quello sia e quello resti; può inoltre utilizzare un’autenticazione semplice (username/password) e/o certificati di crittografia.

Tutto questo è relativo alla configurazione specifica del broker in uso.
A tal proposito abbiamo molte guide a disposizione, per esempio:

DISPOSITIVI (Sonoff, Shelly e similari)

Tutti i componenti/dispositivi MQTT presenti in domotica devono “puntare” all’IP del broker (o al nome mDNS) che, come abbiamo detto, dev’essere immutabile, grazie alla configurazione appropriata del router.

N.b. Sui componenti della linea Shelly “Home Automation Systems” l’attivazione del protocollo MQTT avviene attivando la modalità LAN, cosa fattibile solo collegandosi al componente via browser (la cosa non è fattibile via app). Su quelli della linea ITEAD “Sonoff Smart Home”, invece, è tipicamente necessaria l’adozione di un firmware come Tasmota (o similari), fatta eccezione per quei modelli che supportino la modalità DIY.

Altri presentano configurazioni specifiche, come per esempio l’app MQTT di Homey.

L’IP o il nome mDNS da configurare alla voce “host” o “server” o “broker” nella sezione MQTT sarà quindi quello del broker. Ovviamente se il broker prevederà un username/password, allora sarà necessario indicare anche queste informazioni nella configurazione. La porta solitamente in uso dal broker è la 1883. Qualora sia stata configurata diversamente, riportare anche tale variazione nella configurazione MQTT del componente/dispositivo.

Il campo “client“, invece, rappresenterà il “nome” del dispositivo col quale si presenta al broker e che viene inserito all’interno dei topic dei vari messaggi. Se per esempio il componente fosse un interruttore intelligente MQTT applicato a una lampada, magari imposteremo questo campo banalmente a “Luce” così da ricordarcene facilmente il nome.

N.b. I nomi da usare in ambito MQTT sono case-sensitive. “Luce” sarà quindi diverso da “luce“.

Una volta completata la configurazione è necessario verificare la comunicazione verso il broker: i dispositivi che utilizzino Tasmota hanno a disposizione la “console”, la quale riporta chiaramente la dicitura:

MQT: Attempting connection…
MQT: Connected

la quale conferma l’avvenuta connessione verso il broker.

Un “Connect failed” ovviamente segnala l’impossibilità di collegarsi al broker.
In tal caso verificare:

che il broker sia effettivamente in esecuzione;
che l’IP (o il nome mDNS) e la porta indicati siano corretti;
che username/password siano corretti;
che sulla macchina presso il quale il broker è in esecuzione non sia presente un firewall che impedisce la comunicazione sulla porta 1883.

HUB personali

In presenza di uno o più HUB personali gli scenari possibili sono due:

l’HUB è in esecuzione sul medesimo computer presso il quale è in esecuzione il broker MQTT;
l’HUB è in esecuzione su un computer diverso da quello presso il quale è in esecuzione il broker MQTT.

Nel primo caso la configurazione degli client MQTT dell’HUB personale dovrà “puntare” verso l’IP di loopback, ovvero 127.0.0.1; diversamente, andrà indicato l’IP del broker. Questo però non vale per le eventuali installazioni del broker via Docker, il quale obbliga l’uso dell’indirizzo IP reale dell’host e non il loopback.

Per il resto (credenziali, porta ecc.) valgono gli stessi discorsi fatti per i componenti/dispositivi.

Come effettuare dei test

Per effettuare test sarà sufficiente collegarsi al broker e da lì “fingersi” uno o più dei soggetti presenti in rete. Se si vuole per esempio verificare che l’HUB personale stia effettivamente inviando messaggi di comando MQTT a un dato altro soggetto, basterà iscriversi al topic che ci si aspetti stia utilizzando per verificare che effettivamente venga inoltrato al broker; viceversa, sarà possibile pubblicare comandi e/o telemetrie MQTT per vedere se i soggetti destinatari effettivamente ricevano il comando o meno.

Per capire come effettuare questo tipo di test si rimanda a questa guida specifica:

Mosquitto MQTT Broker: comandi utili

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.