SCOPI DEL PROGETTO:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTILIZZATE:PREREQUISITI:DISPOSITIVI FISICI UTILIZZATI:
|
GUIDA maggiormente indicatA per:
|
|
NOTE E DISCLAIMER
|
|
| Revisione progetto: 1.1 | |
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 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 topic “cmnd/Sonoff/POWER” e il payload “ON“:
- 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 { e } 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 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 cancello | cmnd/PULSANTE1/POWER ON |
| PULSANTE relativo alla chiusura del cancello | cmnd/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:
|
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" mqtt: lock: - 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
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 APRI | cmnd/PULSANTE1/POWER ON |
| cmnd/cancello/azione CHIUDI |
cmnd/PULSANTE2/POWER ON |
La sequenza logica è la seguente:
- diciamo di comandare, tramite l’interfaccia dell’HUB personale, l’apertura del cancello;
- l’apertura del cancello presso l’HUB corrisponde alla pubblicazione da parte sia, presso il broker MQTT, del comando “cmnd/cancello/azione APRI“;
- la black box (rappresentata da Node-RED), collegata al broker, è configurata in modo da essere iscritta al topic “cmnd/cancello/azione” (e quindi lo riceve);
- la black box è altresì configurata in modo da domandarsi subito dopo tale ricezione: “qual è il payload del topic?”
- dato che la risposta è “APRI“, pubblica sul broker il comando “cmnd/PULSANTE1/POWER ON“
- se la risposta fosse stata “CHIUDI“, avrebbe pubblicato sul broker il comando “cmnd/PULSANTE2/POWER ON“
- a questo punto:
- 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;
- 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à rappresentata 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 Raspberry Pi OS (Raspbian), altrimenti può essere installato su Home Assistant OS 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“:
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“:
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“:
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“:
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“:
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:
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“.
Valorizziamo ora il campo “Name” con “APRI to ON” e il campo “to” in “ON“:
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“:
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:
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“:
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
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:
Una volta trascinato in dashboard il nodo “Debug“, colleghiamo l’input agli output dei due nodi di tipo “Change“:
Infine, cliccare sul pulsante “Deploy” in alto a destra.
A questo punto il flusso sarà operativo.
SPIEGAZIONE DEL FUNZIONAMENTO
A partire da questo momento, ogni volta che un topic “cmnd/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:
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.
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“:
Doppio click sul nodo appena aggiunto per configurarlo tramite la dialog box che si aprirà, “Edit mqtt in node“:
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”:
A questo punto doppio click sul nodo “Switch” per accedere alla dialog box “Edit switch node“:
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“:
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“:
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.
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“:
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.
|
⚠️ Se di Home Assistant ne sai poco ma sei interessato a capirne di più, ti suggeriamo di partire da qui. |
| 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. |