Che cosa è e come funziona MQTT per l'automazione... 
Uno standard molto diffuso per l'automazione e per la domotica per la comunicazione in rete WiFi
 
MQTT significa Message Queue Telemetry Transport ed è un "protocollo" nato in originale per la telemetria, ovvero misurare cose a distanza (quello che fanno TXtemp TXdata ecc.). E' stato inventato nel 1999 da due ricercatori (Andy Stanford-Clark di IBM e Arlen Nipper di Arcom) e le sue specifiche sono pubbliche. 
Il sistema ha delle regole semplici che ben si prestano allo scambio di messaggi tra dispositivi ed è quindi molto usato in domotica personale e IoT (Internet Of Things). 
 
Il funzionamento di MQTT si basa su un broker MQTT (che è un programma "server" che può "girare" su un PC, un dispositivo della rete locale, un HUB come ControlHUB, oppure su un server remoto in Internet) che fa lo "smistatore" di messaggi, e poi dei client MQTT, i quali inviano e ricevono tali messaggi passandoli al Broker o ricevendoli tramite il Broker (e mai direttamente fra di loro). 
 
 
Esempi di broker MQTT sono i più disparati: uno dei più noti e utilizzati è Eclipse Mosquitto (download qui), il quale è anche disponibile come add-on per Home Assistant (HASSIO). 
 
Esempi di client MQTT sono: 
- componenti/dispositivi abilitati all’uso di MQTT (ad esempio dei misuratori di temperatura umidità o altre cose come TXtemp TXdata ModBus e TXsoil, oppure un interruttore o apri-porta cancello garage come DoorOpen, o ancora un display come 8888-Display
- un qualsiasi HUB personale (Home Assistant, Homebridge, openHAB ecc.); 
- un computer, uno smartphone, un tablet che utilizzino un qualsiasi client MQTT (per esempio il programma Mosquitto può fare anche da client) 
 
Il meccanismo è questo: ogni client può “registrarsi” al broker come Publisher (editore) e/o come Subscriber (sottoscrittore), dando il nome di uno o più Topic su cui vuole pubblicare messaggi come Publisher e uno o più Topic che vuole ascoltare come Subscriber (per esempio per ricevere comandi). 
 
Se ad esempio avessimo un sensore di temperatura TXtemp configurato per pubblicare automaticamente (per es. ogni 10 minuti) 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. 
 
Per TXtemp il nome del Topic “telemetrico” è standard e viene ricavato dal nome dato al TXtemp nelle impostazioni, per un TXtemp di nome "Cucina" sarà 
txeasyout-cucina 
e il relativo messaggio/payload (in notazione JSON) 
{"B":21,"C":0,"Temperature":18.25,"Time":"2020-05-30 20:49.05","H":"0721"} 
 
(come si nota, esso contiene la temperatura oltre ad altre informazioni relative a data, ora, eccetera; altri sensori potrebbero inviare dati in formato diverso). 
Sottoscrivendo il Topic txeasyout-cucina, a ogni pubblicazione tutti i Subscriber ne riceveranno il contenuto. 
Il subscriber può essere qui un Hub multifunzione, un display, o altro. 
TXtemp pubblica, il messaggio va al Broker, il Broker lo distribuisce a tutti i Subscriber. 
 
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 lo riceverà, ma sarà "eseguito" cioè comporterà un'azione solo da parte di quei dispositivi progettati per eseguire quel particolare comando. 
 
Per esempio il dispositivo DoorOpen è progettato per rimanere in ascolto su un topic di comando standard che viene ricavato dal nome dato al DoorOpen nelle impostazioni, per esempio un DoorOpen di nome "Garage" il Topic di comando sarà 
dooreasycmd-garage 
e il relativo payload (o messaggio) in notazione JSON che attiva l'apertura è: 
{“ON1”} 
 
Chi sottoscrive presso il Broker un topic di comando è solitamente il dispositivo stesso da comandare, mentre chi pubblica i messaggi di comando in questo caso di solito è l’HUB personale. 
L'hub personale pubblica (per esempio dopo vostra istruzione vocale), il messaggio va al Broker, il Broker lo distribuisce ai subscriber tra cui sicuramente DoorOpen che lo legge ed agisce di conseguenza (per es. aprendo il cancello). 
 
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. 
 
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. 
Oppure, anche se non è una soluzione molto sicura, si può usare un Broker esterno risiedente su Internet (che per fare i fichi si può anche chiamare "Cloud"). 
Alcuni sistemi e hub per l'automazione hanno il broker già dentro: conosciamo almeno un sistema che ha questa utile caratteristica: è il nostro ControlHUB: per sistemi non molto grandi si può sfruttare il Broker Interno già incluso senza dover configurare NIENTE (per sistemi più grandi si dovrà invece utilizzare un broker esterno). 
 
 
Ancora sul broker MQTT e anche su ControlHUB... 
 
 
 
Ci sarebbero un sacco di altre cose da dire su MQTT, ma per far funzionare le cose questo vi dovrebbe già bastare. 
Sono graditi commenti nel forum utenti come al solito... 
 
Home page - Soluzioni Semplici - Home - L'hardware di VisualVision 
(C) 2020 VisualVision