Integrazioni Local/Cloud e stati via Polling/Push: come la domotica dialoga coi componenti

Cardinale, nella domotica personale, è certamente la consapevolezza dello stato dei componenti e servizi ad essa integrati: la temperatura rilevata da un sensore, lo stato di un termostato, l’accensione di una lampadina, la disponibilità di un servizio e così via. Lo “stato” descrive quindi cosa stia facendo (o cos’abbia rilevato) un dispositivo in dato momento: ad esempio, una luce può essere accesa con un colore rosso e una luminosità media.

Le modalità per integrare un componente o un servizio alla propria domotica basata su HUB personali sono le più disparate: componenti software dedicati, add-on, servizi e metodologie varie. Ognuna di queste modalità viene realizzata dalla community open source (oppure dai produttori, in caso di soluzioni “chiuse”) sulla base delle caratteristiche tecniche – specifiche – dell’elemento da integrare.

Esiste però uno spartiacque determinante nella realizzazione di un’integrazione: la modalità di dialogo con l’elemento da integrare, la quale può essere locale oppure basata su cloud.

La classificazione “Local” identifica tutte quelle integrazioni che utilizzano comunicazioni locali con il dispositivo. Per “locale” si intende una comunicazione che avvenga tramite LAN oppure tramite trasmissioni di tipo ZigBee, Z-Wave, Bluetooth, radiofrequenza o comunque che abbiano dignità, per l’appunto, di comunicazione locale.

Diversamente, invece, la classificazione “Cloud” prevede l’utilizzo di servizi Cloud via Internet tipicamente messi a disposizione dal produttore (del componente hardware, oppure del servizio che si vuole integrare in domotica, per esempio un servizio di previsioni meteo). Tale comunicazione col componente o servizio prevede che la propria domotica personale possa accedere ad Internet per raggiungere il servizio Cloud in questione: l’assenza di tale connessione causa per lo più il malfunzionamento di tale integrazione (vedi FOCUS).

Un’integrazione ha sempre, a prescindere, maggior valore quando è di tipo “Local”: caschi il mondo, se non attuo alcuna modifica tenica al componente da integrare quel tipo di integrazione, a logica, funzionerà sempre. Chiaramente modifiche al componente potrebbero causare un malfunzionamento anche nelle integrazioni di questo tipo: è il caso (per esempio) di quanto successo con gli attuatori Broadlink, i quali se aggiornati con la nuova applicazione smettono di funzionare localmente. Esempi di integrazioni “Local” sono quelle con gli attuatori Shelly, quelli Sonoff (se riprogrammati con firmware alternativi), o comunque genericamente i componenti ZigBee, Z-Wave e altri.

Le integrazioni “Cloud” sono comunque molto diffuse e versatili – sebbene sempre legate alla necessità di una connessione ad Internet da parte della nostra domotica personale e alla presenza (manutenuta) di un Cloud fornito dal produttore. Un esempio tra tanti? L’integrazione dei termostati Netatmo, o di tante altre marche: l’utente utilizza le proprie credenziali per far sì che il proprio HUB personale – tramite il componente d’integrazione – possa integrare il componente via Cloud.

Talvolta alcuni componenti domotici possono essere integrati sfruttando integrazioni con classificazioni diverse: è il caso per esempio dei già citati Sonoff, i quali possono essere integrati sia localmente che via cloud.

Capita la differenza tra le due classificazioni, altre due sotto-classificazioni vanno comprese: “Polling” e “Push”: esse riguardano sostanzialmente la modalità in cui la domotica riceve, tramite l’integrazione (quale sia la sua classificazione) gli “stati” dei componenti.

Nel caso della modalità “Polling“, l’informazione relativa allo stato del componente integrato avviene tramite “domanda esplicita” effettuata ciclicamente, ogni tot di tempo, dall’HUB al cloud o al componente locale; nella modalità “Push“, invece, l’informazione arriva direttamente dal cloud o localmente all’HUB.

Ricapitolando:

	Local Push. Le comunicazioni da e per il componente/servizio avvengono tramite comunicazioni locali e l’HUB personale riceve i cambi di stato in modalità “Push”, ovvero viene allertato immediatamente ad ogni cambio di stato. In questa modalità, i comandi vengono inviati direttamente e i nuovi stati vengono ricevuti immediatamente. [esempi]
	Local Polling. Le comunicazioni da e per il componente/servizio avvengono tramite comunicazioni locali e l’HUB personale riceve i cambi di stato in modalità “Polling”, ovvero richiede lo stato ciclicamente, ogni tot di tempo. In questa modalità, i comandi vengono inviati direttamente e per ottenere lo stato di risposta l’HUB effettua una richiesta per verificare che il comando si stato eseguito. [esempi]
	Cloud Push. Le comunicazioni da e per il componente/servizio avvengono tramite Cloud e l’HUB personale riceve i cambi di stato in modalità “Push”, ovvero viene immediatamente allertato dal Cloud ad ogni cambio di stato. In questa modalità, i comandi vengono inviati al Cloud e i nuovi stati vengono ricevuti immediatamente. [esempi]
	Cloud Polling. Le comunicazioni da e per il componente/servizio avvengono tramite Cloud e l’HUB personale riceve i cambi di stato in modalità “Polling”, ovvero richiede lo stato al Cloud ciclicamente, ogni tot di tempo. In questa modalità, i comandi vengono inviati al Cloud e per ottenere lo stato di risposta l’HUB effettua un’ulteriore richiesta al Cloud per verificare che il comando si stato eseguito. [esempi]

Va da sé che le quattro modalità di integrazione siano, nella tabella sopra, elencati ordine decrescente “di preferibilità”: la prima, ovvero la “Local Push“, è in assoluto la migliore, in quanto non solo è possibile integrare un componente localmente, ma in fase di invio comandi la risposta arriva da sé, immediatamente. A scendere, la meno preferibile è la “Cloud Polling”, in quanto non solo è una modalità che sfrutta il Cloud (con i suoi svantaggi tipici), ma prevede anche una doppia interrogazione a fronte della richiesta di esecuzione di un comando (quella di comando stessa + quella di polling per la verifica stato).

Ciò che rende preferibile un componente rispetto ad un altro è sempre la possibilità di essere integrato – o meno – nella propria domotica personale. Un ulteriore parametro di scelta è – alla luce della presente scheda – dato dalla classificazione di tipologia d’integrazione disponibile: un parametro da tenere quindi sempre a mente.