Trasformare più elementi MQTT in un unico dispositivo virtuale tramite Node-RED

SCOPI DEL PROGETTO:
  • Creare un dispositivo virtuale MQTT a partire dalla presenza di più dispositivi (fisici e/o virtuali) MQTT
  • Livello di difficoltà: alto
CONCETTI AFFRONTATI:
  • Configurazione software
COMPONENTI SOFTWARE UTILIZZATE:
PREREQUISITI:
  • Node-RED configurato e funzionante
  • Broker MQTT configurato e funzionante
DISPOSITIVI FISICI UTILIZZATI:
  • Attuatori/componenti MQTT
GUIDA maggiormente indicatA per:

Tutti gli ambienti

Note e disclaimer
  • qualsiasi modifica all'impianto elettrico dev'essere effettuata da personale qualificato
  • qualsiasi modifica attuata in proprio è a propria responsabilità personale nonché a proprio rischio e pericolo (la presente guida ha puro scopo didattico)
  • qualsiasi modifica attuata in proprio a un dispositivo ne fa decadere la garanzia.

Abstract

DUE PAROLE SULL’MQTT

Nella realizzazione della propria domotica personal capita spesso di integrare componenti basati su protocollo MQTT. È solitamente una fortuna: MQTT è un protocollo semplice, veloce, affidabile, il quale apre ad una grande rosa di funzionalità. Sensori, attuatori, dispositivi complessi: un protocollo, l’MQTT, che permette di integrarli ai maggiori HUB personali senza particolari sforzi.

MQTT permette di scambiare messaggi da e verso i componenti compatibili con tale protocollo tramite dei topic, ovvero delle stringhe dotate di payload (carico utile) che possono rappresentare un comando (command) o una risposta/comunicazione (telemetria).
Su inDomus per spiegare questo concetto abbiamo utilizzato la metafora dei fari.

Un topic, solitamente, contiene una componente che ne identifica la natura (se sia un comando o una telemetria), una che identifica il destinatario (se un comando) o il mittente (se telemetria) e infine una restante parte che identifica il contenuto del topic. Infine, il payload (non sempre presente) è un contenuto in notazione JSON che contiene, per l’appunto, il carico utile del comando o della telemetria.

I dispositivi che, ad esempio, siano dotati di firmware Sonoff-Tasmota (come per l’appunto gli ITEAD Sonoff, oppure NodeMCU) solitamente ricevono comandi tramite un messaggio MQTT di questi tipo:

cmnd/Sonoff/POWER ON

in questo caso specifico composto da due parti, il topiccmnd/Sonoff/POWER” e il payloadON“:

  • cmnd identifica la natura “comando” del topic;
  • Sonoff identifica l’attuatore destinatario del comando;
  • POWER identifica il tipo di comando, in questo caso “cambio di stato del relè”;
  • ON identifica il payload, che associato a POWER fa sì che il relè dell’attuatore si accenda. Fosse stato OFF, avrebbe comandato lo spegnimento.

Un topic telemetrico, invece, potrebbe essere il seguente:

stat/Sonoff/SENSOR = {“Time”:”2018-02-15T17:37:10″,”ENERGY”:{“TotalStartTime”:”2018-11-14T18:39:40″,”Total”:6.294,”Yesterday”:5.340,”Today”:0.954,”Period”:217,”Power”:2635,”ApparentPower”:2650,”ReactivePower”:282,”Factor”:0.99,”Voltage”:227,”Current”:11.661}}

dove, in questo caso specifico:

  • stat identifica la natura “telemetrica” del topic;
  • Sonoff identifica l’attuatore mittente della telemetria;
  • SENSOR identifica la sorgente, interna al componente;
  • la restante parte inclusa tra {} rappresenta il payload JSON, il quale, in questo caso, contiene letture di assorbimento elettrico (questo esempio fa riferimento alle letture di un Sonoff POW dotato di firmare Sonoff-Tasmota).

Ma potrebbe essere anche qualcosa di più semplice, per esempio:

stat/Sonoff/POWER = 0

Ovvero una semplice telemetria che indica che il relè di un attuatore Sonoff è spento.

INTEGRAZIONE TRADIZIONALE

Questo modello, in fase di integrazione tradizionale, semplifica enormemente le cose rispetto ad altri scenari. Basterà infatti conoscere i topic di comando e telemetrici per integrare un dato componente MQTT alla propria domotica, in quanto tale protocollo, come già detto, è ampiamente supportato come piattaforma di integrazione trasversale agli HUB personali.

Prendiamo l’esempio di un interruttore (compatibile MQTT) da integrare con Home Assistant: tipicamente utilizzeremmo la piattaforma “MQTT Switch” al fine di creare un’entità “interruttore” presso la configurazione, basterà compilare i campi relativi ai topic in maniera opportuna; analogamente, per Homebridge utilizzeremmo il plugin “homebridge-mqttthing” allo stesso scopo e nelle stesse modalità, e così via.

SCENARI COMPLESSI

Fin qui tutto bene: un componente (e quindi un solo “destinatario comandi/mittente telemetrie“), un broker che funga da smistatore messaggi MQTT, un HUB personale che invia comandi e interpreta telemetrie di ritorno. Easy.

Ma cosa succede in presenza di un dispositivo non domotico domotizzato, per esempio, da più componenti MQTT diversi?

Un esempio classico quanto facile da capire è quello delle tapparelle elettriche. Tipicamente si utilizzano uno o più attuatori al fine di controllarne il funzionamento: è il caso (ma è solo uno dei tantissimi esempi possibili) del Sonoff Dual, attuatore doppio canale ideale per controllare gli altrettanti canali di una tapparella elettrica (quello di alzata e quello di discesa). Tale dispositivo, dopo la ormai tradizionale riprogrammazione con firmware alternativo, si dota di protocollo MQTT, il quale permette di controllare i due canali ma in modo differenziato, come si trattasse di due attuatori fisici disgiunti. Non può infatti essere configurato direttamente come un’unica entità logica di tipo “tapparella”, solo come due interruttori on/off.

Portando un altro esempio (che useremo come traccia per il progetto) immaginiamo di aver domotizzato un telecomando (assicurarsi di aver letto e compreso tale progetto prima di proseguire): in tale scenario un unico dispositivo (diciamo di un cancello motorizzato) viene comandato da tale telecomando, il quale a sua volta è comandato da tanti attuatori domotici MQTT quanti sono i pulsanti da governare.


Poniamo che il telecomando (magari di un cancello) presenti due soli pulsanti (“apertura” e “chiusura“) e quindi due corrispondenti attuatori domotici chiamati rispettivamente (nella propria configurazione MQTT) PULSANTE1 (quello d’apertura) e PULSANTE2 (quello di chiusura) e configurati in modo da attivare (quando comandati) il corrispondente pulsante del telecomando per un breve attimo, come farebbe un essere umano nell’atto di usarlo (questo si configura lato attuatore, ad esempio con comandi tipo (PULSETIME).

Immaginiamo ora che i comandi MQTT che comandano i due attuatori (e quindi che attivano i relativi pulsanti / e quindi comandano il cancello) siano, rispettivamente:

PULSANTE relativo all’apertura del cancellocmnd/PULSANTE1/POWER ON
PULSANTE relativo alla chiusura del cancellocmnd/PULSANTE2/POWER ON

Capire quale sia la logica è semplice: l’invio del topic di comando MQTT scaturisce nell’apertura del cancello, il seconda nella chiusura.

Per integrare in domotica l’apertura e la chiusura del cancello ho dunque due strade:

  • definire due semplici interruttori che, quando attivati, inviino il topic MQTT corrispondente;
  • definire un’entità che rappresenti un cancello virtuale vero e proprio, pertanto che accetti comandi di apertura/chiusura i quali scaturiscano poi nell’invio dei topic MQTT corretti.

Entrambe le strade sono valide ma, mentre la prima è rozza e presenta problemi legati all’imprecisa natura dell’entità (banalmente, abbiamo due “interruttori” piuttosto che un’entità “cancello”), la seconda è più raffinata e sostanzialmente corretta, anche e sopratutto in uso automazione (in termini squisitamente logici è corretto chiedere “apri entità cancello” piuttosto che “attiva interruttore 1“). Non dimentichiamoci che è importante, in domotica, cercare di rappresentare ciò che viene domotizzato con entità a lui il più possibili vicine in termini di caratteristiche, funzionalità eccetera.

Poniamo dunque di volere perseguire la seconda strada.
Come esempio concettuale (valido a grandi linee anche per altri HUB personali), poniamo di voler creare un’entità di tipo “Lock” (serratura) presso Home Assistant (la quale rappresenti virtualmente il cancello). Per farlo utilizzeremmo la piattaforma “MQTT Lock“, la quale a grandi linee si implementa così:

#Esempio di entità "MQTT Lock"
lock:
  - platform: mqtt
    name: Cancello
    state_topic: "topic_telemetrico"
    command_topic: "topic_di_comando"
    payload_unlock: "APRI"
    payload_lock: "CHIUDI"
    value_template: '{{ value }}' 
    optimistic: false
    retain: false
    qos: 1

Le voci di configurazione evidenziate sono il cuore dell’entità, specialmente la seconda, ovvero “command_topic“: in questo campo l’utente deve indicare il topic da inviare quando si comanda l’entità “Lock” associandogli il “payload_*” corretto (in base al fatto che stia aprendo o chiudendo il cancello).

Ma… di topic noi ne abbiamo due, perché due sono i dispositivi MQTT che stiamo comandando, per due funzioni diverse legate allo stesso oggetto. Il payload di attivazione dell’attuatore, poi, è sempre uno e uno solo, ovvero “ON“:

cmnd/PULSANTE1/POWER ON

cmnd/PULSANTE2/POWER ON

E se poi – in altri scenari – i dispositivi MQTT non fossero due, ma quattro, dieci, cento?

Si tratta forse di un problema senza soluzione?
No: la soluzione, come quasi sempre, esiste.

Black box

black-box

Per risolvere questo problema sfrutteremo il modello black box, ovvero l’implementazione di un elemento che si frapponga – in termini logici – tra la domotica e i dispositivi finali, ovvero qualcosa che “traduca” dei topic arbitrari provenienti dalla domotica in topic destinati ai dispositivi corretti, e topic telemetrici provenienti dai dispositivi verso un unico topic telemetrico verso la domotica.

Ciò facendo, andremo a creare una sorta di “dispositivo virtuale” – dotato dei propri topic MQTT – a partire da quelli conosciuti e associati ai dispositivi fisici che stiamo cercando di comandare, come spiegato nell’Abstract.

Il ruolo di “black box” sarà interpretato da quella benedizione informatica che è Node-RED.


Node-RED è un semplice  quanto versatile software che permette di definire dei flussi, ovvero delle sequenze di azione che abbiano solitamente in punto di ingresso “input” e un punto d’uscita “output”. Ciò che capita all’interno di questi flussi può essere un’elaborazione dati, delle valutazioni condizionali e molto, molto altro.

Quello che andremo a fare è definire sostanzialmente due flussi:

  • uno dalla domotica verso i dispositivi;
  • uno dai dispositivi verso la domotica.

In realtà la domotica sarà toccata in senso lato, perché i flussi che definiremo non faranno altro che leggere e scrivere dei messaggi MQTT inoltrati da e verso il broker, messaggi che poi verranno a loro volta letti e scritti dalla domotica.

Logica dei flussi

FLUSSO DALLA DOMOTICA AI DISPOSITIVI

Abbiamo spiegato come, data la necessità di possedere “un unico topic MQTT di comando” per l’entità che andiamo a definire in configurazione dell’HUB contrapposta alla presenza di “più topic MQTT di comando” (tanti quanti sono gli attuatori), dovremo necessariamente inventarcene uno.

Tornando all’esempio del cancello di cui sopra, definiremo quindi un topic MQTT di comando, arbitrario (inventandocelo di sana pianta) che chiameremo:

cmnd/cancello/azione

mentre i due payload (visto che le azioni possibili sono due) saranno, sempre arbitrariamente:

APRI

CHIUDI

Quello che vogliamo quindi che accada è che, pubblicando sul broker MQTT uno specifico topic con un dato payload accada una cosa, con un’altro, un’altra:

Topic MQTT di comando (inoltrato dal dispositivo virtuale definito in domotica)Traduzione topic MQTT (quindi verso i dispositivi fisici)
cmnd/cancello/azione APRIcmnd/PULSANTE1/POWER ON
cmnd/cancello/azione CHIUDI
cmnd/PULSANTE2/POWER ON

La sequenza logica è la seguente:

  1. diciamo di comandare, tramite l’interfaccia dell’HUB personale, l’apertura del cancello;
  2. l’apertura del cancello presso l’HUB corrisponde alla pubblicazione da parte sia, presso il broker MQTT, del comando “cmnd/cancello/azione APRI“;
  3. la black box (rappresentata da Node-RED), collegata al broker, è configurata in modo da essere iscritta al topiccmnd/cancello/azione” (e quindi lo riceve);
  4. la black box è altresì configurata in modo da domandarsi subito dopo tale ricezione: “qual è il payload del topic?
    1. dato che la risposta è “APRI“, pubblica sul broker il comando “cmnd/PULSANTE1/POWER ON
    2. se la risposta fosse stata “CHIUDI“, avrebbe pubblicato sul broker il comando “cmnd/PULSANTE2/POWER ON
  5. a questo punto:
    1. dato che è stato pubblicato “cmnd/PULSANTE1/POWER ON“, a riceverlo e ad agire sarà l’attuatore attestato sul pulsante del telecomando che apre il cancello, causando quindi l’apertura dello stesso;
    2. in caso fosse stato pubblicato “cmnd/PULSANTE2/POWER ON“, l’attuatore ad agire starebbe stato quello attestato sul pulsante del telecomando che chiude il cancello, causandone la chiusura.

Ciò che dobbiamo realizzare è il flusso relativo alla black-box, ovvero i punti 3 e 4 della sequenza logica.

FLUSSO dai DISPOSITIVI alla domotica

Come spiegato, i dispositivi fisici generano, quando comandati, delle telemetrie di stato di ritorno dopo il comando, telemetrie che devono essere ricevute – univocamente – dalla domotica, affinché l’accessorio configurato risulti consistente nello stato.
Vivo, per così dire. In sostanza, la domotica deve avere certezza che il comando inviato sia stato eseguito, e per farlo usa le telemetrie.

Tornando all’esempio del cancello e relativi elementi coinvolti, ogni qual volta che l’attuatore PULSANTE1 o PULSANTE2 viene azionato tramite comando “cmnd/PULSANTE1/POWER ON” o “cmnd/PULSANTE2/POWER ON“, tipicamente in risposta viene pubblicata una telemetria da parte sua presso il broker MQTT.

Poniamo che per questi due attuatori la telemetria prodotta a fronte della loro attivazione sia:

stat/PULSANTEx/POWER = ON

dove ovviamente “PULSANTEx” rappresenta l’attuatore mittente della telemetria.

Dato che ricevere la telemetria “stat/PULSANTE1/POWER = ON” significa, de facto, che il cancello è stato aperto (così come “stat/PULSANTE2/POWER = ON” significa che è stato chiuso), allora questa telemetria deve arrivare alla domotica per confermare l’avvenuto comando sull’attuatore.

Definiremo quindi un topic MQTT telemetrico, arbitrario (anche in questo caso inventandocelo di sana pianta) che chiameremo per questo esempio:

stat/cancello

mentre i due payload (visto che le azioni possibili sono due) saranno, sempre arbitrariamente:

APRI

CHIUDI

N.b. Per descrivere lo stato sarebbe più sensato, trattandosi di telemetrie di risposta, usare dei payload tipo “APERTO” e “CHIUSO” piuttosto che “APRI” e “CHIUDI“. Rimanendo però nel solco esemplificativo di un’implementazione su Home Assistant, il componente “MQTT Lock” che stiamo ipotizzando di usare prevede che i payload da associare ai topic di comando e di telemetria siano gli stessi. Pertanto, assumeremo che la telemetria “di apertura”contenga un payload “APRI“, mentre quella “di chiusura”, “CHIUDI“.

Node-RED

Come anticipato, la nostra “black box” sarà sappresentata da Node-RED, sul quale definiremo due flussi, uno dedicato alle comunicazioni dalla domotica verso gli attuatori e un altro per il percorso inverso.

A questo punto colleghiamoci al nostro Node-RED precedentemente installato (qui abbiamo una GUIDA per l’installazione su Raspberry Pi con sistema operativo Raspbian, altrimenti può essere installato su HASSIO come add-on, o altre soluzioni).

FLUSSO DALLA DOMOTICA AGLI ATTUATORI

In alto a destra premeremo su “+” per creare un nuovo flusso che chiameremo “Flow 1”.

La colonna a sinistra rappresenta l’elenco delle tipologie di “nodi” disponibili. Cerchiamo e troviamo nell’elenco (sotto la voce “Input”) un nodo “mqtt in“:

Node-RED - Flusso domotica>dispositivi - mqtt in

trasciniamolo nello spazio vuoto della dashboard e clicchiamoci sopra due volte per aprire sulla destra la dialog box relativa alla sua configurazione, denominata “Edit mqtt in node“:

Node-RED - Flusso domotica>dispositivi - mqtt in - dettagli

A questo punto è necessario indicare:

  • a quale server (broker MQTT) collegarsi;
  • a quale topic iscriversi, ovvero su quale topic “far stare in ascolto” il nostro nodo.

Iniziamo col definire un nuovo server (broker mqtt).

Clicchiamo su “Add new mqtt:broker“:

Node-RED - Flusso domotica>dispositivi - mqtt in - edit broker

Nel campo “Name” indichiamo un nome qualunque, nel caso dell’esempio “Mosquitto LOCAL”, in quanto il broker in uso è Mosquitto, installato sullo stesso computer di Node-RED.

indichiamo poi, alla voce “Server“, l’IP del broker (se è in esecuzione sullo stesso computer di Node_RED, ovviamente indicheremo “127.0.0.1“, altrimenti l’IP del nostro broker esterno a Node-RED. Indicheremo poi la porta ed eventuali credenziali d’accesso presso la tab “Security“.

Al termine della configurazione, clicchiamo su “Update“.

Tornati alla dialog “Edit mqtt in node” è il momento di indicare al nodo “mqtt ip” appena aggiunto alla dashboard quale topic monitorare.

Nel campo “topic” inseriremo quindi il topic “di fantasia” che utilizzeremo per rappresentare sul piano logico il nostro dispositivo virtuale, ovvero:

cmnd/cancello/azione

Impostiamo QoS a “1” e, nel campo “Name“, sempre “cmnd/cancello/azione“.
Al termine della configurazione, clicchiamo su “Done” per tornare alla dashboard.

Se tutto è corretto, il nodo “mqtt in” acquisirà nome “cmnd/cancello/azione” e sparirà il triangolo rosso, segno che la connessione verso l’MQTT Broker sia andata a buon fine.

Ora è necessario identificare e trascinare in dashboard un nodo di tipo “Switch“:

Node-RED - Flusso domotica>dispositivi - switch

il quale, in sostanza, permette di introdurre delle logiche condizionali.

Una volta posizionato il nuovo nodo sulla dashboard, lo colleghiamo al primo nodo trascinando il circolo grigio posto sul lato destro del primo (l’output) al circoletto grigio posto sul lato sinistro del nodo del secondo (l’input).

Clicchiamo ora due volte sul nodo appena trascinato per aprire la relativa dialog box di configurazione chiamata “Edit switch node“: qui definiremo il nome del nodo, quale proprietà “valutare” al suo ingresso, infine quale condizione considerare corretta.

Nel campo nome indichiamo “AZIONE” lasciando invariata la proprietà da valutare in ingresso (ovvero msg.payload); nel riquadro sotto “Property” indichiamo poi due uguaglianze valorizzate rispettivamente “APRI” e “CHIUDI“:

Node-RED - Flusso domotica>dispositivi - switch - uguaglianze

Clicchiamo infine su “Done“.

A questo punto Node-RED avrà modificato il nodo switch (“AZIONE“) fornendogli due uscite (due pallini grigi sul bordo destro del nodo stesso), le quali rappresenteranno i due punti d’uscita (output) presso il quale il flusso si canalizzerà in caso che il payload (in arrivo dal nodo precedente) sia valorizzato “APRI” o “CHIUDI“.

In pallino grigio in alto rappresenta l’uscita in caso presenza di payload “APRI“; quello in basso, “CHIUDI“.

A questo punto, tra i nodi di tipologia “Function” troviamone uno di tipo “Change” e trasciniamone due nella dashboard:

Node-RED - Flusso domotica>dispositivi - change

A questo punto colleghiamo l’ingresso (input) di uno di questi due nuovi nodi a un’uscita del nodo “AZIONE“, l’altro all’uscita del nodo “AZIONE” rimanente.

Questi due nodi di tipo “Change” servono a trasformare il payload proveniente dal dispositivo virtuale in due payload comprensibili ai dispositivi fisici che andremo a raggiungere via MQTT. Trasformeremo entrambi i payload (“APRI” o “CHIUDI“) in “ON“.

Clicchiamo ora due volte sul primo nodo appena trascinato e collegato con l’output “APRI” del nodo “AZIONE” per aprirne la dialog box di configurazione chiamata “Edit change node“.

Node-RED - Flusso domotica>dispositivi - change - dettagli

Valorizziamo ora il campo “Name” con “APRI to ON” e il campo “to” in “ON“:

Node-RED - Flusso domotica>dispositivi - change - dettagli-2

Clicchiamo infine su “Done“; ripetiamo poi tutto il processo anche con il secondo nodo di tipo “Change“, chiamandolo in questo caso “CHIUDI to ON“.

A questo punto, nella lista delle tipologie di nodi, troviamo e trasciniamo in dashboard due nodi di tipo “MQTT out“:

Node-RED - Flusso domotica>dispositivi - mqtt out

Colleghiamo quindi l’output di uno dei due nodi “Change” precedenti all’input di uno dei due “MQTT out” appena trascinati, poi l’output dell’altro nodo “Change” all’input dell'”MQTT out” rimanente:

Node-RED - Flusso domotica>dispositivi - mqtt out - connessione

I due nodi “MQTT out” sono lo step finale del nostro flusso di trasformazione. In pratica, quando il payload “ON” arriverà a uno dei due (in base al percorso effettuato nel flusso), esso verrà inviato assieme al comando MQTT corretto quindi verso il dispositivo fisico corretto.

Clicchiamo ora due volte sul primo nodo “MQTT out” per aprirne la dialog box di configurazione chiamata “Edit mqtt out node“:

Node-RED - Flusso domotica>dispositivi - mqtt out - dettagli

Ora è necessario configurare il server MQTT (che abbiamo già definito precedentemente) e il topic da inviare.

Abbiamo assunto in precedenza che i comandi vadano inviati al PULSANTE1 in caso di apertura e al PULSANTE2 in caso di chiusura.
Pertanto, la configurazione del campo “topic” del nodo “MQTT out” che chiude il ramo “APRI” sarà:

cmnd/PULSANTE1/POWER

quindi così configurato:

Node-RED - Flusso domotica>dispositivi - mqtt out - dettagli-2

La configurazione dell’altro nodo “MQTT out” sarà identica, ma con “PULSANTE2” al posto di “PULSANTE1

A questo punto il flusso sarà completo, ma aggiungeremo anche un nodo di tipo “Debug” per verificarne il corretto funzionamento:

Node-RED - Flusso domotica>dispositivi - debug

Una volta trascinato in dashboard il nodo “Debug“, colleghiamo l’input agli output dei due nodi di tipo “Change“:

Node-RED - Flusso domotica>dispositivi - Deploy

Infine, cliccare sul pulsante “Deploy” in alto a destra.

Node-RED - Flusso domotica>dispositivi - Deploy

A questo punto il flusso sarà operativo.

SPIEGAZIONE DEL FUNZIONAMENTO

A partire da questo momento, ogni volta che un topiccmnd/cancello/azione” verrà inoltrato sul broker MQTT tale topic verrà ricevuto dal primo nodo del flusso (“MQTT in“) il quale lo invierà al secondo nodo (“Switch“) il quale a sua volta, in base alla propria configurazione, invierà un eventuale payload “APRI” o “CHIUDI” verso in nodo “Change” opportuno che segue. Gli eventuali payload diversi verranno scartati.

Il nodo “Change” (quale sia) convertirà il payload in “ON“, infine lo invierà al nodo “MQTT out” opportuno seguente che provvederà quindi a inoltrare al broker MQTT il comando, il quale sarà o “cmnd/PULSANTE1/POWER ON” o “cmnd/PULSANTE2/POWER ON” in base al ramo attraversato nel flusso.

L’invio di questi due comandi avrà effetto, come sperato, sui dispositivi fisici MQTT da controllare.

TEST

Effettuare un test è semplice: basterà inviare un comando : “cmnd/cancello/azione APRI” o “cmnd/cancello/azione CHIUDI” e verificare che presso Node-RED il nodo “Debug” prima implementato a valle del nodo “Change” abbia ricevuto un payload “ON”, codizione che si verifica a fronte dell’avvenuto attraversamento.

Per fare ciò basta utilizzare un qualunque client MQTT. Nel nostro caso mostriamo l’esempio dell’invio del comando “cmnd/cancello/azione APRI” tramite MQTTBox, un comune client per Mac:

MQTTBox

Tornando su Node-RED – se tutto avrà funzionato in modo corretto – cliccando sul nodo “Debug” e guardando nella colonna destra, dovrebbe apparire inequivocabilmente la voce di log dell’avvenuta ricezione del payload “ON“, payload quindi ricevuto anche da “MQTT out” e quindi conseguentemente pubblicato sul broker.

Node-RED - Flusso domotica>dispositivi - debug log

FLUSSO DAGLI ATTUATORI ALLA DOMOTICA

A questo punto dobbiamo definire un altro flusso, anzi due gemelli:

  • uno che generi un topic telemetrico che la domotica interpreti come “cancello aperto” a fronte dell’attivazione dell’attuatore PULSANTE1, che chiameremo “stat/cancello APRI“;
  • uno gemello che generi un topic telemetrico che la domotica interpreti come “cancello chiuso” a fronte dell’attivazione dell’attuatore PULSANTE2, che chiameremo “stat/cancello CHIUDI“.
PRIMO FLUSSO

Torniamo alla nostra dashboard Node-RED. Aggiungiamo un nodo “MQTT in“:

Node-RED - Flusso dispositivi>domotica - mqtt in

Doppio click sul nodo appena aggiunto per configurarlo tramite la dialog box che si aprirà, “Edit mqtt in node“:

Node-RED - Flusso dispositivi>domotica - mqtt in - dettagli

Nel campo “Server” indicheremo il nostro solito broker MQTT; nel “topic” inseriremo il topic telemetrico fornito dall’attuatore PULSANTE1, ovvero “stat/PULSANTE1/POWER“. Nel campo “Name“, metteremo “PULSANTE1“.

Clicchiamo su “Done” per tornare alla dashboard.

Aggiungiamo ora un nodo “Switch” che utilizzeremo a mo’ di “filtro” per tutti gli eventuali payload telemetrici diversi da “ON“. Colleghiamolo con l’output del nodo “MQTT in”:

Node-RED - Flusso dispositivi>domotica - switchA questo punto doppio click sul nodo “Switch” per accedere alla dialog box “Edit switch node“:

Node-RED - Flusso dispositivi>domotica - switch - dettagli

Inseriamo nel campo “Name” l’etichetta “check”, e “ON” nella condizione verificata nel box sotto “Property“.

Clicchiamo su “Done” per tornare alla dashboard.

Aggiungiamo ora un nodo “Change” che utilizzeremo per convertire il payload “ON” in “APRI“. Colleghiamolo all’output del nodo “Switch” e clicchiamoci sopra due volte per aprire la dialog “Edit change node“:

Node-RED - Flusso dispositivi>domotica - change - dettagli

Impostiamo il campo “Name” a “ON to APRI” e il campo “to” a “APRI“.

Clicchiamo su “Done” per tornare alla dashboard.

Infine aggiungiamo ora un nodo “MQTT out” che utilizzeremo per inviare la telemetria virtuale sul broker. Colleghiamolo all’output del nodo “Change” e clicchiamoci sopra due volte per aprire la dialog “Edit mqtt in node“:

Node-RED - Flusso dispositivi>domotica - mqtt out - dettagli

Impostiamo come “Server” il solito broker MQTT, come topic “stat/cancello” e come “Name” impostiamo “Apertura

Clicchiamo su “Done” per completare il flusso e tornare alla dashboard.

A questo punto collegare l’output del nodo “Change” al nodo “Debug” aggiunto nella fase di definizione del flusso dalla domotica ai dispositivi, giusto per dotarsi di uno strumento di debug in caso di test.

Node-RED - Flusso dispositivi>domotica - primo flusso completato

Ora, selezionando con un riquadro fatto col mouse il flusso appena definito, provvediamo a un CTRL+C / CTRL + V per duplicarlo. Modificarlo poi sostituendo “PULSANTE1” con “PULSANTE2“, “APRI” con “CHIUDI” e “Apertura” con “Chiusura“:

Node-RED - Flusso dispositivi>domotica - entrambi flussi completati

Cliccare infine su “Deploy” per completare l’opera.

TEST

Come nel caso del flusso domotica > attuatori, è possibile (per non dire necessario) effettuare test a questi due nuovi flussi inviando manualmente dei topic MQTT di test tramite il solito client MQTT.

Conclusioni

A questo punto esisterà un “dispositivo virtuale” il quale risponderà ai comandi

cmnd/cancello/azione APRI
cmnd/cancello/azione CHIUDI

e a fronte di tali comandi “risponderà” con telemetrie ben precise:

stat/cancello APRI
stat/cancello CHIUDI

permettendoci così di configurarlo, come fosse un unico dispositivo MQTT reale, presso la nostra domotica personale, qualunque sia il nostro HUB personale.


Questo progetto è applicabile (con le dovute personalizzazioni) in molteplici scenari: domotizzare cancelli, tapparelle, sistemi antitrusione e molto altro ancora: qualsiasi elemento che venga domotizzato tramite più attuatori/elementi MQTT può essere “virtualizzato” tramite le tecniche spiegate in questo progetto.

Ciò che è importante capire è:

  • quali siano i topic di comando per i vari attuatori MQTT;
  • quali siano i topic telemetrici di ritorno;
  • quali siano i topic da configurare all’interno dell’HUB personale per definire l’entità virtuale che rappresenterà il nostro accessorio domotizzato tramite gli attuatori.

Basterà poi applicare le tecniche spiegate in questo progetto per far funzionare il tutto.


Home Assistant Official LogoATTENZIONE: ricorda che sul nostro community FORUM c'è una sezione ad hoc dedica a Home Assistant, per qualsiasi dubbio, domanda, informazione nel merito specifico di queste componenti.

Clicca QUI per commentare e/o valutare l'articolo.