Come configurare MQTT sui dispositivi della propria domotica

6 minuti di lettura

Come spiegato nella scheda dedicata al componente, MQTT è semplice ma efficace servizio di rete concepito allo scopo di scambiare rapidamente messaggi da e per componenti e dispositivi domotici/IoT. Tale servizio permette di “comandare” i cambi di stato dei componenti e raccoglierne le risposte, le telemetrie e, genericamente, informazioni da essi prodotti.

Una spiegazione veloce

Il funzionamento è semplice: nello scenario tipico di un ambiente domotico basato di rete LAN/Wi-Fi esiste 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 come facile addon per Home Assistant (HASSIO).

Esempi di client MQTT sono:

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

Il meccanismo è molto semplice: ogni client può “registrarsi” al broker sia come Publisher (editore) che 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).

MQTT basic schema

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.


Se ad esempio avessimo un sensore di temperatura configurato nel pubblicare 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”:”2019-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 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/Artemide/power

con relativo payload (in notazione JSON)

{“ON”}

Tale esempio è relativo al comando di accensione di un dispositivo chiamato “Artemide” dotato di firmware Sonoff-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, 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 Raspberry Pi con sistema operativo Raspbian o altre soluzioni.

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:

  1. l’utente attiva l’interruttore presso l’HUB personale (da interfaccia web, app mobile, comando vocale – quel che è);
  2. 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
  3. il broker riceve il messaggio MQTT;
  4. il broker verifica se e quale client MQTT abbia sottoscritto il topic contenuto nel messaggio (in questo caso, il dispositivo da comandare);
  5. il broker gira al client MQTT (il componente/dispositivo) il messaggio MQTT;
  6. il dispositivo, che sa cosa fare alla ricezione di un messaggio dal tale topic e dal tale payload, esegue l’azione;
  7. 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;
  8. il broker riceve il messaggio MQTT;
  9. 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);
  10. il broker gira al client MQTT (l’HUB personale) il messaggio MQTT;
  11. 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, invariabile, all’interno della propria rete. Questo perché TUTTI i client MQTT (di qualunque tipo) saranno “puntati” verso di lui e dovranno poterlo contattare sempre senza che esso cambi. Al cambiare dell’IP del broker, tutte le configurazioni dei vari componenti/dispositivi andranno a farsi benedire.

L’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, 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.

COMPONENTI (Sonoff & company)

Tutti i componenti/dispositivi MQTT presenti in domotica devono “puntare” all’IP del broker che, come abbiamo detto, dev’essere immutabile.

L’IP 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 contenuto 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 “Lampada” così da ricordarcene facilmente il nome.

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

Una volta completata la configurazione è necessario verificare la comunicazione verso il broker: i dispositivi che utilizzino Sonoff-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 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.

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

Come effettuare dei test

Per effettuare test in caso di problemi è sempre estremamente utile installare sul proprio computer un client MQTT (in rete se ne trovano a bizzeffe sia per Windows che per macOS).

A questo punto 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.

A questo dedicheremo un focus ad hoc più avanti.


ATTENZIONE: ricorda l'esistenza del nostro community FORUM per qualsiasi dubbio, domanda, informazione nel merito specifico dei contenuti di questa pagina e molto altro.

🔻 Clicca QUI per commentare l'articolo. 🔻