Un dispositivo local-first svolge il suo compito principale sul proprio hardware e sulla rete locale, e considera internet un bonus anziché un requisito. Quando il cloud è opzionale, una connessione che cade o una fascia di load shedding significa un breve fastidio, non un dispositivo morto. Questo articolo spiega perché i gadget dipendenti dal cloud si trasformano in mattoni, quali schemi progettuali continuano a funzionare offline e quale semplice prova fare prima di comprare.

Perché i dispositivi dipendenti dal cloud diventano mattoni

Molti prodotti smart mettono il ragionamento da un'altra parte. Il pulsante sul muro non decide niente: invia un messaggio a un server, il server decide e la risposta torna indietro via internet. Quel giro è invisibile finché tutto funziona. Diventa evidente nel momento in cui il collegamento si interrompe.

In Sudafrica il collegamento si interrompe spesso. Il load shedding manda giù insieme il router e la borchia della fibra. I dati mobili finiscono o rallentano fino a strisciare. Il server di un fornitore va in sovraccarico, oppure l'azienda dismette in sordina la linea di prodotto e spegne il servizio che c'era dietro. Quando succede una di queste cose, un interruttore che ha bisogno del cloud per accendere una lampadina sullo stesso muro smette di funzionare. L'hardware sta benissimo. È il suo cervello che abita troppo lontano.

Il caso peggiore è quello lento. Un dispositivo può funzionare alla perfezione per due anni e poi diventare rifiuto elettronico il giorno in cui il costruttore decide che il servizio cloud non vale più la spesa. Avete comprato un prodotto; stavate affittando una dipendenza.

Che cosa significa davvero local-first

Local-first non vuol dire contro internet. Riguarda il luogo in cui vengono prese le decisioni importanti. In un'architettura local-first il ciclo di controllo principale gira sul dispositivo stesso, o su un piccolo hub collocato sulla vostra rete. Il cloud è riservato ai compiti che hanno davvero bisogno del mondo esterno: raggiungere il dispositivo quando siete fuori casa, conservare lo storico di lungo periodo, distribuire gli aggiornamenti software e condividere l'accesso con altre persone.

Immaginatelo come tre livelli. La logica a bordo del dispositivo gestisce il compito immediato. Il coordinamento sulla rete locale permette al telefono di parlare con il dispositivo via Wi-Fi senza uscire di casa. La sincronizzazione opzionale con il cloud gestisce tutto il resto, e solo quando una connessione è disponibile. Togliete il livello in cima e i due sotto continuano ad andare avanti.

Schemi che continuano a funzionare offline

Non serve progettare hardware per riconoscere le buone abitudini. Alcuni schemi separano i dispositivi che sopravvivono a un'interruzione da quelli che non ci riescono.

• Ciclo di controllo locale. Le letture dei sensori e le decisioni che innescano avvengono sul microcontrollore, non su un server. Un termostato mantiene la sua programmazione; un interruttore interrompe.
• Hub sulla rete locale. Un piccolo dispositivo sempre acceso coordina gli altri sulla vostra LAN, così i comandi dal telefono al dispositivo non devono mai uscire dalla proprietà.
• Sincronizzazione differita, non dati persi. Quando è offline, il dispositivo conserva le sue letture e le carica appena la connessione torna, invece di buttarle via.
• Degrado controllato. Il dispositivo ha un comportamento definito per quando è offline: mantenere l'ultimo stato noto, seguire una programmazione predefinita sicura o ripiegare sulla posizione più sicura. Non si limita a lampeggiare un errore e ad arrendersi.
• Credenziali locali. Potete comunque accedere e configurare il dispositivo sulla vostra rete senza che il server degli account del fornitore sia raggiungibile.

La prova del funzionamento offline

Potete giudicare quasi tutto questo nella prima serata, prima che scada il diritto di reso. Installate il dispositivo, poi mettetelo alla prova di proposito contro un internet morto.

1. Spegnete il router, o disattivate i dati mobili, e usate la funzione principale. L'interruttore interrompe ancora e il sensore risponde ancora?
2. Riavviate il dispositivo con internet ancora spento. Torna da solo a uno stato funzionante o resta appeso in attesa di chiamare casa?
3. Aprite l'app sullo stesso Wi-Fi senza alcuna connessione a internet. Riesce a trovare e comandare il dispositivo in locale?
4. Fate al fornitore una domanda diretta: che ne è di questo hardware se chiudete il servizio? Una risposta sicura di solito significa che esiste un ripiego locale.
5. Cercate protocolli aperti come Matter, Zigbee o MQTT verso un broker vostro. Gli standard che controllate voi sono la differenza tra cambiare app domani e ricomprare tutto da capo.

Se un dispositivo non supera i primi due passaggi, non è un dispositivo smart. È un telecomando per il server di qualcun altro.

Insegnare la mentalità local-first

L'istinto si costruisce più facilmente da piccoli. I bambini che imparano a programmare su hardware che esegue il programma sulla scheda stessa crescono aspettandosi che un dispositivo sia padrone della propria logica. Quando il codice vive sul chip, un progetto con luci e sensori continua a funzionare che ci sia o meno il Wi-Fi nella stanza, e chi impara vede esattamente dove viene presa la decisione.

È il modello che usa la nostra scheda sheenbot∞: il programma viene eseguito sul microcontrollore, così un progetto si comporta allo stesso modo su una rete domestica, a scuola o su un tavolo senza alcuna connessione. È un modo pratico per mostrare che "smart" non deve per forza voler dire "online". Se volete vedere come lo insegniamo, la nostra academy costruisce questi progetti passo dopo passo, potete prenotare una lezione di prova e le schede e i kit sono nello store.

In sintesi

Il cloud è utile per l'accesso da remoto, lo storico e gli aggiornamenti. È un pessimo posto in cui tenere la capacità di base di un dispositivo di funzionare. Preferite prodotti in cui il ciclo principale gira in locale, in cui i dati vengono conservati e sincronizzati anziché scartati, e in cui i protocolli aperti vi evitano di restare legati a una sola azienda. Poi dedicate una serata alla prova del funzionamento offline. I dispositivi che la superano sono quelli ancora attivi la prossima volta che va via la corrente.

Domande frequenti

Local-first significa che perdo l'accesso da remoto?

No. Il local-first mantiene funzionante la funzione principale senza internet, ma un dispositivo può comunque offrire l'accesso da remoto come extra opzionale. La differenza è che perdere quell'extra non impedisce al dispositivo di svolgere il suo compito principale.

Il cloud è sempre la scelta sbagliata?

No. I servizi cloud sono lo strumento giusto per lo storico di lungo periodo, gli aggiornamenti over-the-air e per raggiungere un dispositivo quando siete lontani. La regola è usare il cloud per ciò che ha bisogno del mondo esterno, non per decisioni che il dispositivo potrebbe prendere da solo.

Come funzionano gli aggiornamenti software se il dispositivo è offline?

Le buone architetture scaricano un aggiornamento quando la connessione è disponibile e lo applicano in locale, invece di dover essere online nel momento in cui lo eseguono. I periodi offline ritardano gli aggiornamenti; non devono disabilitare il dispositivo.