Bentrovati amici smart!
Nel video precedente abbiamo iniziato ad analizzare alcuni dei temi che si celano dietro le quinte dei dispositivi smart, temi che considero essenziali per destreggiarsi al meglio nella scelta dei dispositivi giusti. Oggi continueremo ad approfondire questi argomenti, aggiungendo un ulteriore livello di conoscenza che ritengo necessario avere. So che la teoria può sembrare un po' noiosa, ma capire concetti come il metodo di comunicazione e il tipo di interfacciamento dei dispositivi, che sia per Home Assistant o in generale, sono essenziali per prendere decisioni ponderate quando progettiamo la nostra smart home. Come dicevo, ogni caso è a sè: che si tratti del nostro budget, delle nostre idee, del tipo di casa, dell'efficienza complessiva della rete, del consumo energetico ecc. Per questo motivo ognuno di noi deve analizzare attentamente ogni aspetto, ma soprattutto sapere da dove partire e quali strumenti ha a disposizione.
Iniziamo questa seconda parte da dove ci eravamo fermati, facendo un ulteriore esempio di vita reale per ripassare e identificare meglio i vari attori in gioco:
- I dispositivi: Possiamo pensare a un dispositivo come a una persona.
- Il mezzo di comunicazione: Possiamo pensare al mezzo di comunicazione come al modo con cui la persona comunica, ad esempio la voce, che è una conseguenza meccanica delle corde vocali.
- Il tipo di interfacciamento: Possiamo pensare al tipo di interfacciamento è invece la lingua che utilizza, cioè il modo con cui si esprime e la capacità di elaborare e rispondere durante una conversazione.
Esempio di vita reale
Immaginiamo quattro persone sedute allo stesso tavolo all'interno di una stanza (la stanza rappresenta il nostro hub, ad esempio Home Assistant). Tutte e quattro parlano utilizzando la voce (che, ad esempio, potrebbe rappresentare una tecnologia come il WiFi), ma due di loro parlano francese (che potrebbe rappresentare un protocollo come le API) e le altre due parlano italiano (ad esempio, utilizzano MQTT).
Possiamo vedere queste due coppie come due sistemi chiusi di differenti brand/nazioni. Sebbene si trovino nello stesso ambiente, non riusciranno a comunicare tra loro senza alcun aiuto.
Per permettere alle due coppie di comunicare, possiamo seguire due strade:
- La prima strada è quella di affiancare un interprete: Possiamo aggiungere una quinta persona che conosca entrambe le lingue (API e MQTT), che parla usando la voce e che faccia da interprete tra le due coppie (possiamo pensare all’interprete come ad un’integrazione per ciascun brand su Home Assistant). In questo modo, anche se abbiamo due gruppi di dispositivi appartenenti a brand chiusi, il nostro hub, grazie alle sue integrazioni, fungerà da ponte (o interprete) per permettere la comunicazione.
- La seconda strada è quella di adottare una lingua comune: cioè fare in modo che tutte e quattro le persone imparino una lingua comune, come l’inglese (possiamo pensare a questo come un aggiornamento dei dispositivi per supportare uno standard come Matter). Così facendo, tutti potranno comunicare direttamente senza l’aiuto di un interprete. Home Assistant, che supporta anch’esso Matter, farà semplicemente da hub per coordinare i dispositivi, ma la comunicazione avverrà in modo trasparente utilizzando lo stesso linguaggio.
In aggiunta a questo, potrebbero subentrare ulteriori fattori che influenzano una normale comunicazione, provocando ritardi o disturbi e creando disagi. Oggi ci concentreremo su questo tema, integrandolo con quanto discusso a appreso nel video precedente.
Questi esempi sono fondamentali per capire quanto sia importante la scelta dei dispositivi e come si integrano tra loro per formare un ecosistema smart coeso ed efficiente.
Classificazione dispositivi
Bene, dopo aver chiarito meglio la distinzione tra i metodi di comunicazione e i tipi di interfacciamento, possiamo classificare i dispositivi distinguendoli in due macro categorie: local e cloud, combinate con i concetti di Push e Polling.
Lo so, detti cosi questi termini suonano un po’ tecnici, ma in realtà sono più semplici di quello che sembra. Quello che vedremo rappresentano delle linee guida, che ci aiuteranno a fare scelte consapevoli e mirate quando selezioniamo i dispositivi per la nostra smart home. Partiamo da Local e Cloud.
Local
Local, come suggerisce il nome, si riferisce a una comunicazione che avviene esclusivamente all’interno della rete domestica. Questo significa che i dispositivi comunicano su una rete LAN/WiFi o mediante altre tecnologie wireless come ZigBee, Z-Wave, Bluetooth, o Thread. In altre parole, questi dispositivi non necessitano di una connessione a internet per funzionare in ambito domestico, garantendo maggiore indipendenza e una minore latenza nelle interazioni, permettendo di comandare, ad esempio, una lampadina senza dover passare da server esterni. Se la connessione a internet dovesse venire a mancare, la lampadina continuerebbe a funzionare, perché tutto è gestito a livello locale.
Attenzione: Quando dico che LOCAL definisce un dispositivo che lavora su rete domestica, non significa che non è possibile gestirlo fuori dall’abitazione mediante un HUB, ma solo che per funzionare in casa, non necessita di una connessione ad internet.
Cloud
Cloud, invece, significa che la comunicazione del dispositivo passa attraverso Internet, sfruttando servizi cloud che sono spesso forniti dal produttore. Questo significa che il funzionamento del dispositivo dipenderà dalla disponibilità di una connessione a internet e dalla stabilità del servizio remoto. Ad esempio, una lampadina che si appoggia al cloud per essere controllata richiederà sempre una connessione attiva per funzionare.
È vero, nella maggior parte delle situazioni moderne, siamo sempre connessi, ma se la connessione a internet dovesse venire a mancare o il servizio cloud del produttore non fosse disponibile, la nostra smart home potrebbe smettere di funzionare. Immaginate di non poter più accendere o spegnere una luce perché la connessione internet è fuori uso: è facile capire come questo possa causare un disagio.
Una volta stabilito se la comunicazione avviene localmente o via cloud, è importante comprendere come l’HUB monitora e ottiene lo stato dei dispositivi. Questo può avvenire in due modi che vanno a combinarsi con Local e Cloud, mi riferisco a Push e Polling:
Push
In Push il dispositivo o servizio invia aggiornamenti all’HUB non appena il suo stato cambia. Questo approccio è reattivo e immediato, poiché, normalmente, l'HUB riceve i cambiamenti in tempo reale senza doverli richiedere continuamente al dispositivo o al servizio.
Polling
In modalità Polling, invece, è l’HUB a richiedere periodicamente lo stato del dispositivo, indipendentemente dal fatto che sia cambiato o meno. Questo processo avviene a intervalli prestabiliti, come ogni tot secondi, minuti, o ore. Sebbene sia un metodo semplice, può essere meno efficiente, in quanto porta l'HUB a inviare un gran numero di richieste, anche quando non ci sono cambiamenti effettivi da rilevare, con il rischio di non ricevere le variazioni, riceverle in ritardo o appesantire la rete, soprattutto se i dispositivi sono numerosi.
4 Classificazioni di riferimento
Combinando Local/Cloud con Push/Polling, otteniamo quattro classificazioni principali che possono guidarci nella scelta di un dispositivo, abbiamo:
- Local Push
- Local Polling
- Cloud Push
- Cloud Polling
Quando acquistiamo un dispositivo, è utile capire a quale di queste classificazioni appartiene.
Vediamo alcuni esempi pratici per comprendere meglio la combinazione tra Local/Cloud e Push/Polling.
Local e Cloud
Supponiamo di voler acquistare uno switch a batteria e una lampadina smart, e vogliamo fare in modo che, premendo lo switch, l’HUB rilevi l’azione e accenda o spenga la lampadina attraverso una specifica automazione.
Local
Se entrambi i dispositivi funzionano in Local, indipendentemente che si tratti di Push o Polling, il loro funzionamento non dipenderà dalla connessione a internet, ma da una rete locale (ad esempio Wi-Fi, Zigbee, ecc.). Pertanto, anche in caso di mancanza di connessione, la nostra lampadina potrà essere accesa e spenta senza problemi. Questo è possibile perché tutto funziona in locale, senza la necessità di collegarsi a servizi esterni.
Cloud
Se uno o entrambi i dispositivi funzionano in Cloud, indipendentemente che si tratti di Push o Polling, il funzionamento dipenderà dalla connessione a internet. Ciò significa che, in caso di disservizi del provider o del server remoto del produttore, potremmo non riuscire ad accendere o spegnere la lampadina, creando un disagio non indifferente nell'uso domestico.
Adesso proviamo a combinare Local e Cloud con Push e Polling.
Push e Polling
Push
Se entrambi i dispositivi lavorano in Push, che siano in Local o in Cloud, l’HUB riceverà automaticamente le variazioni ogni volta che un dispositivo cambia stato. Ad esempio, quando premiamo lo switch, questo invia un segnale che può viaggiare su rete locale o su internet per comunicare all'HUB che la lampadina deve accendersi o spegnersi. In modalità Local Push, la comunicazione è quasi istantanea, poiché avviene mediante la rete locale. In modalità Cloud Push, invece, il messaggio deve viaggiare attraverso internet, e questo può comportare un ritardo maggiore nella ricezione da parte dell'HUB, oppure il messaggio potrebbe non arrivare affatto.
Concretamente:
- Se premiamo uno switch che lavora in Local Push, l’HUB riceve il cambiamento di stato del dispositivo quasi immediatamente, e potrà accendere o spegnere la lampadina in tempi brevissimi.
- Se invece lo switch lavora in Cloud Push, il cambiamento di stato potrebbe arrivare con qualche secondo di ritardo, poiché la comunicazione deve passare attraverso server esterni. Questo può tradursi in un'esperienza d’uso meno reattiva. Immaginiamo di premere lo switch e vedere accendere la lampadina dopo 4 secondi.
Polling
Se entrambi i dispositivi lavorano in Polling, che siano in Local o in Cloud, sarà l'HUB a interrogare periodicamente i dispositivi per ottenerne lo stato. Questo avviene ogni tot secondi, minuti o ore, anche quando lo stato dei dispositivi non è cambiato. Questo approccio, se applicato a un gran numero di dispositivi, può risultare piuttosto oneroso già in LOCAL, in quanto inonda la rete di richieste ripetute e non sempre necessarie. Se questi dispositivi operano in Cloud Polling, il problema si amplifica, poiché le richieste devono passare attraverso internet, aumentando ulteriormente il rischio di disallineamenti e ritardi nella risposta.
Concretamente:
- In Local Polling, l’HUB interroga periodicamente i dispositivi per ottenerne lo stato. Essendo su rete locale, i tempi di risposta sono solitamente brevi, ma con un numero elevato di dispositivi si rischia di appesantire la rete, causando rallentamenti.
- In Cloud Polling, l’HUB invia richieste periodiche al dispositivo tramite internet. Questo introduce ulteriori rischi di ritardi e disallineamenti, soprattutto se la rete internet è congestionata, non funziona o se il servizio cloud non è stabile.
In sintesi i dispositivi che lavorano in Local Push, o al massimo Local Polling, rappresentano la scelta migliore in termini di reattività e affidabilità per la gestione della smart home, mentre le altre combinazioni possono introdurre maggiori complicazioni.
Esempio di vita reale
Proviamo a fare un esempio di vita reale per comprendere meglio queste classificazioni.
Push
Immaginiamo marito e moglie in casa. Il marito è l'HUB e la moglie è il dispositivo, essendo entrambi in casa lavorano in LOCAL. Il marito, sapendo che la moglie ha messo la pentola sul fuoco, le chiede di avvisarlo appena il pranzo è pronto. In questo contesto, la moglie funge da dispositivo Local Push, informando il marito, che si trova in casa, non appena l'evento "pranzo pronto" si verifica. Tutto accade in modo rapido e senza ritardi. Nel peggiore dei casi il ritardo potrebbe essere dato dal marito che non sente la moglie dall'altro lato della casa.
Polling
Adesso vediamo lo stesso esempio in Polling: marito e moglie in casa, il marito è l'HUB e la moglie è il dispositivo. Questa volta il marito, sapendo della pentola sul fuoco, chiede ogni minuto alla moglie se il pranzo è pronto. In questo contesto, la moglie funge da dispositivo Local Polling, cioè necessita di essere interrogata periodicamente dal marito per dare una risposta. E' chiaro che, nella normalità di una vita coniugale, dopo la decima volta che il marito chiede alla moglie se il pranzo è pronto, quest'ultima prende la pantofola, rigorosamente in legno, e gliela tira in fronte. No, a parte gli scherzi... Il Polling è meno efficiente, poiché il marito deve chiedere ripetutamente lo stato di un evento. Questo porterebbe a ulteriori ritardi e a una comunicazione meno ottimale.
Inoltre, che sia in Push o in Polling, se uno dei due si trovasse fuori casa il meccanismo sarebbe classificabile in CLOUD, quindi potrebbero esserci ulteriori complicazioni nella comunicazione tra marito e moglie, come un problema di linea telefonica.
Conclusione
È evidente che puntare su dispositivi Local è la scelta migliore per stabilità ed efficienza. Tuttavia, in alcune situazioni, non abbiamo altra scelta che optare per dispositivi che funzionano in Cloud. Il consiglio è di non basare l'intera smart home su dispositivi Cloud, ma di utilizzarli all'occorrenza.
Come dicevo all'inizio, conoscere queste classificazioni ci fornisce una linea guida importante. Ogni volta che ci troveremo ad acquistare un dispositivo dovremo chiederci: funziona in local o in cloud? Utilizza Push o Polling? Per capirlo sarà sufficiente documentarsi sul metodo di comunicazione e sul tipo di interfacciamento del dispositivo. Questo vale come regola generale e non solo per chi utilizza Home Assistant.
Per chi utilizza Home Assistant, invece, spesso possiamo trovare questa informazione nella pagina dell'integrazione ufficiale di un dispositivo, dove è indicato, ad esempio una dicitura come questa, "IoT class: Local Push". Così, in base alla sua integrazione, sapremo subito come funziona.
Per ultimo vediamo uno schema che può aiutarci nella scelta:
- Se vogliamo acquistare un dispositivo che lavora in Local Push: Orientiamoci su ZigBee o Thread. In alternativa Wi-Fi ma che dichiari il supporto a Matter, MQTT o API locali con interfacciamento bidirezionale (es. WebSocket).
- Se il dispositivo non rientra nel primo punto ma vogliamo, quantomeno, che lavori in Local Polling: Orientiamoci su dispositivi LAN o Wi-Fi con supporto a API REST locali.
- Se il dispositivo non rientra nei primi due punti ma lavora in Cloud: Assicuriamoci, quantomeno, che lavori in Push, per evitare ritardi con il Polling.
- Come ultima spiaggia, se il dispositivo non dovesse rientrare nei primi 3 punti, allora orientiamoci sul Cloud Polling.
In alternativa è possibile valutare anche dispositivi, nati e progettati per lavorare in Cloud Push o Polling, ma che con degli hack è possibile farli lavorare in Local Push o Polling, installando appositi firmware custom non ufficiali.
Bene per oggi è tutto! Nel prossimo video ci concentreremo sulla sezione Dispositivi e Servizi di Home Assistant, affrontandola con maggiore consapevolezza.
Come sempre se vi fa piacere seguitemi per altri tutorial, attivate la campanellina e lasciate un like al video.