Dispositivi e Servizi – Parte 1

Bentrovati amici smart!

Nel video precedente abbiamo visto i comandi principali da utilizzare da linea di comando per gestire e mantenere aggiornato il nostro setup di microservizi, primo tra tutti Home Assistant. Oggi iniziamo ad addentrarci nel dettaglio delle singole sezioni di Home Assistant per comprendere meglio lo scopo di ciascuna e imparare a muoverci al loro interno con maggiore consapevolezza. Inoltre, affronteremo nuove tematiche legate alle tecnologie e alle funzioni più diffuse nel mondo della smart home in generale, così da poterle padroneggiare al meglio.

È importante ricordare che, per quanto si possa approfondire un argomento di HomeAssistant o della smart home generale, non sarà mai possibile affrontare ogni singolo dettaglio in un unico corso. Se provassimo a farlo, questo viaggio non avrebbe fine! Questo perché, oltre alle basi essenziali, la configurazione di una smart home non è qualcosa di definito che può andar bene a chiunque, al contrario, il setup di ognuno di noi è un mondo a sé. Ognuno ha esigenze diverse, dispositivi differenti e quindi configurazioni personalizzate.

Per questo motivo, il valore aggiunto di questo corso è imparare a conoscere le basi e a muoversi in autonomia, per acquisire la consapevolezza necessaria a trovare le informazioni giuste al momento giusto. Creare una smart home, per ognuno di noi, è un viaggio che si costruisce nel tempo, man mano che emergono nuove esigenze, queste ci portano ad aggiungere nuovi dispositivi, nuove automazioni, tecnologie e, quindi, un nuovo bagaglio di conoscenze.

Questo per dire che il miglior insegnante che possiamo avere saremo sempre noi stessi: Sperimentare è la chiave.

Alcune delle tematiche che vedremo getteranno le fondamenta per comprendere meglio Home Assistant, in quanto rappresentano convenzioni o routine che utilizzeremo spesso nella gestione della nostra casa smart. Altre, invece, seguiranno percorsi specifici sui quali documentarsi di volta in volta, come, ad esempio, la scelta dei migliori dispositivi da integrare, le migliori tecnologie da adottare, la configurazione delle singole integrazioni, la scrittura di automazioni mirate ecc. Questi aspetti andranno affrontati e approfonditi caso per caso, quando ne avremo bisogno.

Gli argomenti che affronteremo a partire da oggi potrebbero sembrare piuttosto articolati, per tale motivo, al fin di renderli più semplici ed evitare di tagliare parti fondamentali, ho deciso di dividere questa tappa in più parti.

A proposito di fondamenta, direi di partire dalla sezione Dispositivi e Servizi di Home Assistant, che considero il cuore della nostra configurazione. Perché il cuore? Perché è qui che diamo vita alla nostra Smart Home, aggiungendo tutti i dispositivi — fisici o virtuali — che potremo gestire e automatizzare. Partire da questa sezione ci permetterà di conoscere concetti e tecnologie cruciali per imparare a scegliere consapevolmente i migliori dispositivi da acquistare per la nostra Smart Home, come integrarli e utilizzarli. Inoltre conosceremo anche alcune delle dinamiche offerte da HomeAssistant che ci consentiranno di rendere la nostra casa smart ancora più intelligente.

Prima di entrare nel vivo di questa sezione e analizzarla punto per punto, direi di esplorare anzitutto i retroscena dei dispositivi smart: come funzionano, quali tecnologie utilizzano e come comunicano tra loro. I concetti che vedremo scindono da Home Assistant e rappresentano uno standard per qualsiasi HUB decidiamo di utilizzare. È importante affrontare questo argomento all'inizio, poiché ci aiuterà a comprendere meglio la sezione Dispositivi e Servizi e a sviluppare la capacità di scegliere un dispositivo rispetto a un altro con maggiore consapevolezza.

Quando pensiamo a un dispositivo qualunque per la Smart Home, possiamo raggrupparlo in due macro-categorie fondamentali, che ci aiutano a comprendere come comunica e come interagisce con il nostro ecosistema. Queste macro categorie sono:

• Il metodo di comunicazione
• Il tipo di interfacciamento

Metodo di Comunicazione

Il metodo di comunicazione, fa riferimento alla tecnologia hardware adottata dal produttore in fase di progettazione e utilizzata dal dispositivo per trasmettere e/o ricevere dati. In altre parole, rappresenta il "canale" hardware attraverso cui il dispositivo comunica con gli altri elementi della rete o con l'hub di gestione. Questo canale può essere basato su una tecnologia cablata, come Ethernet, oppure wireless, come Wi-Fi, Zigbee, Z-Wave, Bluetooth o Thread. Ogni tecnologia ha le sue peculiarità, sia in termini di velocità di trasmissione che di consumo energetico, raggio d'azione e affidabilità. Ad esempio, Ethernet offre una connessione stabile e ad alta velocità, mentre tecnologie wireless come Zigbee e Z-Wave sono spesso preferite per il basso consumo energetico e per la loro estendibilità su rete mesh.

Tipo di Interfacciamento

Il tipo di interfacciamento, invece, si riferisce alla tecnologia software adottata dal produttore in fase di progettazione e utilizzata dal dispositivo per controllarlo, interrogarlo e ricevere dati. In altre parole, è il "linguaggio" attraverso cui il dispositivo comunica e si integra con il sistema di gestione. Linguaggio che possiamo utilizzare, in base alle sue specifiche, per dialogare con il dispositivo. Ogni dispositivo espone le sue funzionalità in modo diverso, utilizzando tecnologie che possono essere standard o proprietarie.

I tipi di interfacciamento sono molteplici, ma noi ci soffermeremo sui principali che possiamo incontrare, cioè:

• Le API esposte da un WebService locale o online (ad esempio in cloud)
• Il protocollo MQTT
• Le WebHook
• Matter

Proviamo a capire meglio di cosa si tratta

API

Le API sono un meccanismo client-server utilizzato per interfacciarsi, generalmente attraverso il protocollo HTTP (per comunicazioni unidirezionali) o tramite WebSocket (per comunicazioni bidirezionali), verso uno specifico servizio o, meglio, un WebService.

In poche parole, un particolare dispositivo (come un hub o un bridge, ad esempio HomeAssistant o Philips Hue) o una piattaforma web (ad esempio un servizio online come IFTTT), espone delle risorse che è possibile interrogare, dopo averle studiate e implementate, inviando apposite richieste. La risorsa server interrogata elabora l'informazione richiesta e restituisce una risposta al client.

Provando a fare un'analogia di vita reale, possiamo pensare alle API come alle ordinazioni fatte ad un cameriere di un ristorante dopo che il cliente ha analizzato e ha preso visione dei piatti offerti dal menu. Schematicamente possiamo dire che:

• Il ristorante rappresenta il WebService
• I clienti sono i client.
• Il menu del ristorante è il documento tecnico che permette ai clienti di conoscere le risorse (o meglio i piatti) proposti dal WebService (cioè il ristorante), al fine di studiarle e prenderne consapevolezza.
• Il cameriere è il controller, ovvero l'intermediario tra il cliente e la cucina. Quindi è la figura al quale il cliente, dopo aver studiato il menu, fa la richiesta (cioè l'ordinazione) e il quale può sollevarci eccezioni o errori sulla disponibilità di un piatto o di un ingrediente prima di prendere in carico la comanda a farla elaborare alla cucina.
• La cucina è il cuore del WebService, che si occupa di elaborare la richiesta (cioè preparare i piatti) e di rispondere al client (cioè il cliente) con il risultato finale (il piatto).

Ritornando al contesto della SmartHome, possiamo immaginare un WebService come il servizio offerto da un bridge di un determinato brand, come ad esempio quello della Philips Hue. Quest'ultimo mette a disposizione un set di API tramite il suo WebService locale, utilizzabili per gestire e controllare tutti i dispositivi a lui collegati.

Il documento delle API esposte da Philips Hue (che sarebbe il "menu del ristorante") viene utilizzato dagli sviluppatori per comprendere le risorse disponibili e integrarle in un eventuale piattaforma client, ad esempio Home Assistant attraverso una rispettiva integrazione. Home Assistant, agendo da client attraverso l'integrazione, conosce queste risorse e le può utilizzare per fare richieste specifiche. Ad esempio, quando vogliamo accendere o spegnere una lampadina, Home Assistant (o qualunque altra piattaforma voglia utilizzare quelle API) invia una richiesta al controller del WebService del bridge, quest'ultimo la prende in carico, dopo aver fatto le opportune verifiche, e la passa al modello che la elabora e risponde.

In modo più schematico:

• Il client (che sia HomeAssistant o altro) conosce già le risorse disponibili (le API) e sa come utilizzarle. Pertanto invia una richiesta ad una specifica risorsa del bridge, ad esempio: Accendimi la lampadina del soggiorno.
• Il controller del WebService riceve la richiesta, ne verifica la fattibilità e la passa al cuore del sistema per elaborarla.
• Il cuore del sistema finalizza la richiesta (accendendo la lampadina del soggiorno) e invia una risposta al client (ad esempio Home Assistant) per tramite del controller.
• Il client riceve la risposta e aggiorna la sua interfaccia, mostrando lo stato del dispositivo in dashboard e/o attivando eventuali automazioni collegate.

Questo flusso rappresenta la logica di base per qualsiasi WebService che utilizza delle API, sia su internet che su rete locale, indipendentemente dal contesto specifico. In breve, molti servizi online funzionano in questo modo "dietro le quinte". Ed è un meccanismo ampiamente utilizzato da molti brand per l'interazione con i dispositivi della nostra smart home.

MQTT

MQTT, a differenza delle API, è un protocollo di comunicazione progettato appositamente per contesti come quelli per la SmartHome. È particolarmente adatto a dispositivi con risorse limitate o che necessitano di un basso consumo energetico.

I dispositivi progettati per lavorare mediante il protocollo MQTT si integrano in un meccanismo suddiviso in 3 attori principali:

• Il Publisher
• Il Broker
• Il Subscriber

Il Publisher: È un dispositivo che invia messaggi al broker ad ogni suo cambio di stato. Ogni singolo dispositivo smart che utilizziamo ha delle sue funzionalità (meglio chiamate entità), ognuna delle quali, all'interno del protocollo MQTT, viene identificata come un topic. Il topic, quindi, è una sorta di canale univoco, direttamente connesso al broker, per una specifica entità di un dispositivo.

Il Broker: È una sorta di smistatore dei messaggi. Riceve i messaggi dai dispositivi publisher, nei rispettivi topic, e li invia verso i dispositivi subscriber che sono interessati a riceverli. Pertanto il broker conosce tutti i topic di tutti i dispositivi Publisher e li rende disponibili ai subscriber che vogliono iscriversi.

I Subscriber: Sono i client, come Home Assistant, che si iscrivono ai topic esposti dal broker al fine di ricevere i messaggi da quest'ultimo riguardanti lo stato dei dispositivi per ogni singola entità/topic.

In un video dedicato vedremo come installare un broker MQTT sul nostro Raspberry Pi utilizzando Docker e come configurarlo per integrarne la comunicazione con Home Assistant, permettendo a quest'ultimo di iscriversi a tutti i topic disponibili nel broker.

Anche in questo caso, proviamo a comprendere meglio il meccanismo attraverso un'analogia di vita reale.

• Pensiamo al publisher come a un canale radiofonico che trasmette contenuti, come notizie o bollettini meteo, sulla sua specifica frequenza. La frequenza può essere vista come il topic su cui il canale trasmette.
• Il broker, invece, è la torre di trasmissione che raccoglie le trasmissioni da tutte le frequenze (cioè i topic) e le distribuisce a tutti coloro che sono sintonizzati su una determinata frequenza.
• Il subscriber, invece, è come un autoradio (quindi il client), che si sintonizza su una specifica frequenza e riceve le informazioni che ha scelto di ascoltare.

Tornando a Home Assistant, vediamo un esempio pratico con un sensore di temperatura che lavora utilizzando il protocollo MQTT.

• Il sensore di temperatura rappresenta il publisher, cioè il dispositivo che espone al broker tutte le sue entità, come la temperatura e l'umidità. Ciascuna di queste entità è un topic, cioè un canale univoco verso il broker. Ogni volta che il sensore rileva una variazione in una delle sue entità, ad esempio un cambio di umidità, comunica la variazione al broker su quel topic specifico. Ad esempio l'umidità è cambiata dal 55% al 62%, e lo fa inviando un messaggio sul relativo topic.
• Il broker riceve la variazione dell'umidità nel rispettivo topic dal sensore e la distribuisce in tempo reale a tutti i client che si sono iscritti a quel topic.
• Home Assistant, che è un client, si connette al broker e si iscrive ai topic disponibili per averne notizie in tempo reale, senza che sia lui stesso a chiederle. Quando il broker rileva una variazione dal sensore di temperatura, invia il dato aggiornato a Home Assistant. Quest'ultimo registra la variazione e agisce di conseguenza, ad esempio mostrando la nuova temperatura sulla dashboard o attivando automazioni.

Un ulteriore approfondimento

Home Assistant non è solo un subscriber ma può anche fungere da publisher. Per capire meglio come possa farlo, vediamo un primo esempio più semplicistico e poi un secondo esempio più dettagliato.

Supponiamo di avere una lampadina smart e un pulsante smart, entrambi che utilizzano il protocollo MQTT. Abbiamo anche installato e configurato un broker MQTT (come microservizio di Docker) su un Raspberry Pi o su un altro server, e vogliamo creare un'automazione su Home Assistant per accendere o spegnere la lampadina quando premiamo il pulsante. In questo scenario, Home Assistant funge da intermediario tra i due dispositivi per eseguire l'azione richiesta:

• Il pulsante (Publisher): Il pulsante espone la sua entità "Pressione Pulsante 1" al broker su un relativo e univico topic. Quando il pulsante viene premuto, invia un messaggio al broker indicando il cambio di stato da "non premuto" a "premuto".
• Il Broker: Riceve il messaggio dal pulsante, nel relativo topic "Pressione Pulsante 1", e lo distribuisce a tutti i subscriber interessati a quel topic/entità.
• Home Assistant (Subscriber): È uno dei subscriber del topic del pulsante. Riceve il messaggio di variazione di stato dal broker, per il topic "Pressione Pulsante 1", e innesca l'automazione: se il pulsante 1 è stato premuto, allora la lampadina deve accendersi o spegnersi.
• Home Assistant (Publisher): Quando l'automazione viene attivata, Home Assistant agisce come un publisher e pubblica un messaggio al broker su un altro topic, quella della lampadina "Stato lampadina 1" (per esempio, impostando lo stato a "on").
• Il Broker: Il broker riceve il messaggio di Home Assistant, sul relativo topic "Stato lampadina 1" a "on", e lo inoltra a tutti i subscriber, tra questi la lampadina che si accende.
• Conclusione: Il ciclo di comunicazione si chiude, e la lampadina si accende.

Vediamo un altro esempio, leggermente più dettagliato ma concettualmente identico, sempre con una lampadina e un pulsante:

• In questo esempio la lampadina e il pulsante sono dispositivi Zigbee appartenenti alla stessa rete e comunicano con un coordinatore Zigbee.
• Il coordinatore è responsabile della creazione e della gestione della rete mesh Zigbee (concretamente la inizializza e la imbastisce) e trasmette i messaggi che riceve dai dispositivi a un applicativo ponte (come ad esempio Zigbee2MQTT). Quest'ultimo gestisce la comunicazione con il broker MQTT.
• L'applicativo ponte, installato sul nostro computer o Raspberry Pi (ad esempio mediante docker), è sia un publisher che subscriber (pubblica e riceve messaggi di stato al broker). Quando si presenta al broker MQTT, gli comunica tutte le informazioni relative a tutti i dispositivi del coordinatore Zigbee, esponendo ogni entità di ogni dispositivo (ad esempio, lo stato della lampadina o la pressione del pulsante) come un topic:
  • Esempio di topic esemplificativo
    • "Pressione Pulsante 1"
    • "Stato lampadina 1".
  • Esempio di topic realistico
    • zigbee2mqtt/pulsante_1/action
    • zigbee2mqtt/lampadina_1/state
• Il broker MQTT, installato sul nostro computer o Raspberry Pi (ad esempio mediante docker), conosce tutte le entità/topic dall'applicativo ponte e li espone ai subscriber che vogliono iscriversi. Facendo da intermediario tra l'applicativo ponte e i subscriber come Home Assistant.
• Home Assistant agisce sia come publisher che come subscriber. Si iscrive a tutti i topic esposti dal broker (nell'esempio solo due: "Pressione Pulsante 1" e "Stato lampadina 1"), ottenendo così la possibilità di monitorare e controllare tutte le entità dei dispositivi Zigbee.

Cosa succede nel dettaglio quando premiamo il pulsante:

• Pressione del Pulsante: Quando premiamo il pulsante, questo invia un segnale al coordinatore Zigbee.
• Il coordinatore: Il coordinatore informa l'applicativo ponte della variazione di stato del pulsante.
• Applicativo ponte Pubblica al Broker: L'applicativo ponte riceve il segnale dal coordinatore e pubblica un messaggio sul broker MQTT nel topic "Pressione Pulsante 1".
• Il Broker Notifica: Il broker comunica la variazione di stato a tutti i subscriber interessati a quel topic: "Pressione Pulsante 1", tra questi HomeAssistant.
• Home Assistant Riceve e Attiva l'Automazione: Home Assistant riceve il messaggio di variazione di stato dal pulsante, dal relativo topic "Pressione Pulsante 1", e attiva l'automazione: se viene rilevata una pressione sul pulsante, allora la lampadina deve essere commutata.

Quando l'automazione viene attivata:

• Home Assistant come Publisher: Home Assistant, agendo anche da publisher, pubblica uno stato sul topic della lampadina "Stato lampadina 1" presente nel broker (ad esempio "stato lampadina on/off") per accenderla o spegnerla.
• Il Broker Notifica: Il broker comunica la variazione di stato a tutti i subscriber interessati a quel topic: "Stato lampadina 1", tra questi l'applicativo ponte (Zigbee2MQTT).
• L'applicativo ponte traduce: Zigbee2MQTT riceve il comando dal topic MQTT del broker e lo traduce in un comando Zigbee per il coordinatore.
• Il Coordinatore Esegue: Il coordinatore Zigbee inoltra il comando alla lampadina.
• Ciclo Completo: La lampadina si accende o si spegne in base all'automazione.

In questo modo, abbiamo visto come Zigbee2MQTT e Home Assistant collaborino per gestire dispositivi Zigbee tramite MQTT e il coordinatore Zigbee.

WebHook

Una webhook è un metodo di interfacciamento che permette a un dispositivo o servizio di inviare dati, o cambi di stato, ad un altro servizio, come Home Assistant, ogni volta che si verifica un evento specifico.

Facciamo un esempio, supponiamo di voler intercettare l'evento di rilevamento di un movimento di una telecamera. Invece di lasciare che sia il client, come Home Assistant, a chiedere continuamente alla videocamera se ha rilevato dei movimenti, sarà la videocamera stessa a inviare una richiesta ad una risorsa specifica delle API di Home Assistant quando rileva un movimento. Questo metodo è più efficiente e riduce il carico sulla rete oltre a migliorare la velocità di risposta del sistema. In genere questo metodo potrebbe utilizzare tecnologie standard o proprietarie.

Matter

Matter è uno tipo di interfacciamento, che utilizza un meccanismo simile a quello descritto con MQTT, ma che mira ad essere più standardizzato, permettendo a dispositivi di produttori diversi di comunicare tra loro utilizzando un linguaggio comune. Basandosi su tecnologie come Thread, Wi-Fi ed Ethernet, Matter elimina la necessità di utilizzare tipi di interfacciamento proprietari che vincolano il consumatore a orientare la propria smarthome su un solo brand.

In definitiva Matter è un traduttore universale: anche se un dispositivo di un determinato brand usa il wifi come metodo di comunicazione e un altro usa "Thread", Matter garantisce che entrambi possano capirsi, poiché entrambi i dispositivi utilizzano lo stesso linguaggio.

Bene per oggi è tutto, nel prossimo video affronteremo ulteriori tematiche in merito ai dispositivi e servizi. Capire la differenza tra il metodo di Comunicazione e il tipo di interfacciamento è fondamentale per sapere cosa aspettarsi da un dispositivo e da un’integrazione.

Come sempre se vi fa piacere seguitemi per altri tutorial, attivate la campanellina e lasciate un like al video.