Casa Intelligente e Interessi Multipli: La Mia Guida a Domotica, Conflitti e Sicurezza

Amici, parliamoci chiaro: la casa intelligente è una figata pazzesca! Luci che si accendono da sole, termostati che imparano le nostre abitudini, assistenti vocali pronti a esaudire ogni nostro desiderio (o quasi). Ma cosa succede quando in questa casa super tecnologica non c’è solo “io”, ma un “noi” fatto di persone diverse, con esigenze e preferenze che a volte fanno a pugni tra loro? E se ci mettiamo pure l’amministratore del condominio, il fornitore di energia o persino il comune con le sue regole? Ecco, lì la faccenda si complica un tantino. È proprio di questo che voglio parlarvi oggi: di come si progetta un sistema di domotica che non solo automatizzi, ma gestisca anche i conflitti, garantisca la sicurezza e magari ci dia pure qualche dritta utile con sistemi di raccomandazione intelligenti. Pronti a fare un viaggio nel futuro (che è già qui)?

L’Architettura del Sistema: Come Funziona Davvero?

Quando si parla di gestire spazi intelligenti con più “attori” in gioco (quelli che in gergo chiamiamo stakeholder), la prima domanda è: come diavolo si costruisce un’architettura che tenga insieme tutto? Pensateci: c’è bisogno di monitorare e controllare, di proteggere la privacy e la sicurezza di tutti, e magari di analizzare i dati raccolti per imparare e migliorare. La nostra idea è stata quella di basarci su un principio fondamentale: la separazione delle responsabilità. Abbiamo creato un linguaggio di regole che permette agli utenti di dire “cosa” vogliono ottenere, senza doversi preoccupare del “come” tecnico per farlo. Questo ci ha portato a un’architettura a strati, un po’ come una torta multistrato, dove ogni livello ha il suo compito specifico: trasformare decisioni di alto livello in azioni concrete per la casa, e viceversa, trasformare i dati grezzi dei sensori in informazioni utili per chi deve decidere.

Al cuore di tutto c’è un “motore delle regole”, un componente critico che valuta ed esegue le regole in base allo stato della casa e a chi ci vive, sapendo anche riconoscere e risolvere eventuali conflitti. E non finisce qui! Un sistema di raccomandazione può suggerire nuove regole, imparando dalle abitudini degli abitanti o prendendo spunto da case simili. Per gestire l’introduzione di nuove regole, i conflitti, la sicurezza e chi ha l’autorità di fare cosa, abbiamo pensato a un processo strutturato, guidato da policy chiare. Il bello è che questa architettura permette di integrare facilmente nuove regole o nuovi dispositivi e di raccogliere dati a lungo termine, fondamentali per capire i comportamenti e automatizzare ancora meglio le decisioni.

Usare le regole per automatizzare il controllo di una casa intelligente presenta diverse sfide. Oltre alle regole degli abitanti, spesso ci sono altri stakeholder che vogliono dire la loro. Il proprietario di casa, il comune, il fornitore di energia, persino chi ha sviluppato il sistema: tutti potrebbero voler inserire regole per proteggere i propri interessi. Ad esempio, il comune potrebbe imporre limiti all’inquinamento acustico, il fornitore di energia potrebbe avere requisiti sugli orari migliori per usare certi elettrodomestici, e il proprietario potrebbe voler mantenere una temperatura minima per non far gelare i tubi d’inverno. La presenza di così tanti “suggeritori” di regole crea un bel problema di gestione. Serve un processo chiaro per introdurre nuove regole, una policy che lo guidi e un’autorità designata, chiamiamola Amministratore delle Regole, che supervisioni il tutto. Questo processo deve assicurare che le regole provengano da chi è autorizzato e che si risolvano i potenziali conflitti con le regole esistenti. Un aspetto, questo, non ancora sviscerato a fondo dalla letteratura scientifica.

Un altro nodo cruciale è il linguaggio delle regole. Questo linguaggio deve combinare due elementi centrali: le condizioni (lo stato della casa, le attività degli abitanti, fattori ambientali) e le decisioni (tipicamente, istruzioni per attivare o disattivare dispositivi). Un buon linguaggio per spazi intelligenti dovrebbe permettere di esprimere le preferenze di automazione a un livello di astrazione abbastanza alto, così gli utenti non devono impazzire con i dettagli tecnici e, magari, le stesse regole possono funzionare in case simili. Sganciare le decisioni di alto livello dai dettagli della casa, dalla disposizione delle stanze o dal dispositivo specifico usato ha vantaggi enormi. Se una regola dice di impostare la temperatura a un certo livello, specifica un requisito, non come farlo. Questo requisito può essere tradotto in modi diversi a seconda della casa: accendere il condizionatore, attivare un ventilatore, aprire una finestra, o una combinazione di queste cose.

La Struttura a Strati: Un Flusso Continuo di Dati e Comandi

La nostra architettura si basa su un’idea di “feedback”: raccogliere dati sullo stato del sistema e usarli per fare aggiustamenti. Immaginate una struttura a cipolla, con tre strati principali:

• Strato Esterno Primario: Decide cosa dovrebbe succedere, usando le regole per definire lo stato desiderato.
• Strato Intermedio Secondario: Decide esattamente quale azione intraprendere e con quali dispositivi, basandosi sulla decisione dello strato esterno.
• Strato Interno Terziario: Attiva i dispositivi giusti, mantenendo lo stato della casa al livello desiderato tramite un controllo a “ciclo chiuso” (feedback continuo).

Questo crea due flussi interdipendenti che attraversano gli strati in direzioni opposte: il flusso di monitoraggio e il flusso di controllo. I dati viaggiano dai sensori verso l’alto, aggregandosi e diventando informazioni sempre più elaborate (dallo stato di un sensore, allo stato di una stanza, fino allo stato generale della casa e alle attività degli occupanti). Le decisioni, invece, fluiscono dall’alto verso il basso, trasformandosi da “COSA fare” a “COME farlo” e infine a “FARLO”.

Facciamo un esempio. Immaginiamo questa regola: SE Joe È IN Casa E È ESTATE E È MATTINA ALLORA MANTIENI TemperaturaStanzaJoe TRA 21 E 23.

1. Nello strato primario, i dati (Joe è in casa? Che stagione è? Che ora è?) arrivano al Generic Event Process. Se la condizione della regola è vera, il comando “MANTIENI TemperaturaStanzaJoe TRA 21 E 23” passa al Concrete Action Process.
2. Nello strato secondario, il Concrete Action Process sa qual è la stanza di Joe e quali dispositivi ci sono. Traduce la richiesta in un setpoint per il sistema di raffreddamento, ad esempio impostando la temperatura a 22 gradi.
3. Nello strato terziario, se il sistema di raffreddamento non è autoregolante, un sensore di temperatura nella stanza farà parte di un ciclo di feedback. La temperatura attuale viene confrontata con il setpoint e il sistema si accende o si spegne di conseguenza.

Il nostro linguaggio di regole, che chiamiamo paradigma Event-Require, è più inclusivo del classico “Trigger-Action”. L’evento non è solo scatenato da un dispositivo, ma può originare da algoritmi di IA che rilevano anomalie, da cambi di stagione, o persino da dichiarazioni dell’utente (tipo “sono in vacanza”). La parte “Require” non è legata a un dispositivo specifico ma può coinvolgerne multipli. Ad esempio, mantenere la temperatura sotto i 25°C può significare usare il condizionatore, una finestra, un ventilatore, o una combinazione, integrati con un sensore di temperatura.

Il Linguaggio delle Regole: Parole Chiave per un Dialogo Intelligente

L’idea centrale del nostro linguaggio è mantenerlo abbastanza astratto da rendere le regole facilmente trasferibili da una casa all’altra, simile. Anche se ci concentriamo sulle case private, l’approccio si può estendere ad uffici, ospedali, scuole. Ogni dominio avrà le sue parole chiave specifiche, ma alcune saranno comuni.

Le parole chiave (keywords) si dividono in categorie:

• Location: Luoghi dentro o fuori casa (es. Casa, Cucina, Salotto, TutteLeStanze). Esempio: SE Joe IN Bagno A MEZZOGIORNO
• Role: Persone legate alla casa con responsabilità e permessi (es. Residente, Proprietario, PersonaDellePulizie). Esempio: SE PersonaDellePulizie IN Bagno ALLORA IMPOSTA LuceBagno ACCESA
• Resident: Nomi specifici degli abitanti (es. Joe, Ruth).
• Activity: Attività comuni (es. Dormire, Riposare, Lavorare). Esempio: SE Qualcuno STA Dormendo ALLORA IMPOSTA TuttoVolume SOTTO 25
• Date/Time/Event: Indicazioni di tempo o eventi (es. Mattina, Pomeriggio, Festa, Oggi).
• Action: Comandi risultanti dalle decisioni (es. IMPOSTA, MANTIENI, ACCENDI, SPEGNI, NOTIFICA). Esempio: SE Qualcuno IN Casa E TuttiInquilini NON IN Casa ALLORA AVVERTI Joe

Poi ci sono le Variabili:

• Misurate (suffisso VAL): Dipendono da cosa si può misurare (es. TemperaturaVAL, UmiditaVAL). Esempio: SE TemperaturaVAL IN Cucina SOPRA 25 ALLORA...
• Controllate (suffisso KEEP o SET): Dipendono da cosa si può attuare (es. TemperaturaKEEP, LuceSET).

E infine, gli Operatori (UGUALE, SOPRA, SOTTO, E, O, NON) e le Strutture di Controllo che determinano il flusso di esecuzione.

L’Interprete delle Regole: Il Cervello Pensante

L’Interprete è il componente chiave del Generic Operation Process. È lui che prende le regole e decide se le condizioni sono soddisfatte per far scattare un’azione. Ci sono diversi modi per decidere quando valutare le regole: periodicamente (controllando a intervalli fissi) o in base ai cambiamenti di stato (più efficiente, ed è la nostra scelta). Noi usiamo un approccio event-driven: quando un parametro monitorato cambia, solo le condizioni rilevanti vengono valutate. Se una condizione è VERA, l’azione corrispondente viene eseguita, inviando un messaggio allo strato successivo che la traduce in una risposta appropriata.

Un aspetto interessante è come codifichiamo le condizioni delle regole. Usiamo un approccio basato su “solutori logici” che trasformano il problema in un grafo orientato (una specie di albero decisionale). Questo ha diversi vantaggi:

• Efficienza: Non serve cercare e interpretare ogni volta tutte le regole.
• Negazione automatica: Capire quando un’azione deve cessare diventa più semplice.
• Rilevamento conflitti: Si possono identificare e risolvere facilmente i conflitti tra regole già in fase di inserimento.
• Apprendimento automatico: Si possono integrare facilmente meccanismi per imparare nuove regole dai comportamenti.

Ad esempio, la regola SE Joe IN Stanza ALLORA IMPOSTA Luce ACCESA viene trasformata in una struttura semplice. Quando Joe entra, la luce si accende. Quando esce, il sistema verifica se ci sono altre ragioni per tenere la luce accesa prima di spegnerla (negazione).

Gestione dei Conflitti: Quando le Regole Fanno a Botte

Con più fonti di regole, i conflitti sono inevitabili. Uno dice “accendi il riscaldamento”, l’altro “attiva il raffreddamento”. Come si fa? Molti sistemi cercano di risolvere automaticamente, basandosi su priorità o preferenze. Il nostro approccio, usando i solutori logici, permette di rilevare i conflitti quando una nuova regola viene inserita, se questa porta a un’azione contraddittoria con una esistente. Se, per esempio, Joe vuole la luce accesa quando è nella stanza, ma Alex vuole che la luce sia SEMPRE SPENTA quando lui è lì, si crea un potenziale conflitto. Se Alex ha l’autorità per sovrascrivere la preferenza di Joe (stabilita dall’Amministratore delle Regole e dalla policy del sistema), la sua regola avrà la precedenza. La parola chiave SEMPRE (ALWAYS) nel nostro linguaggio serve proprio a gestire queste situazioni. La risoluzione avviene trattando la regola di Alex come una condizione “AND” che prevale sulle altre.

Sistemi di Raccomandazione: La Casa che Ti Conosce

Creare le regole giuste per una casa può richiedere tempo e fatica. Ma se case simili, famiglie con strutture simili o persone con abitudini simili potessero condividere le loro “ricette”? Ecco l’idea dietro i sistemi di raccomandazione. Il nostro sistema supporta quattro tipi di suggerimenti:

1. Basati su stakeholder comuni: Ad esempio, la compagnia elettrica potrebbe suggerire a tutti i suoi clienti la regola: SE ORE 2:00 ALLORA IMPOSTA Lavatrice ACCESA per sfruttare tariffe più basse.
2. Basati su utenti simili: “Le persone come te apprezzano anche…”. Qui entrano in gioco tecniche come la Matrix Factorization per trovare utenti con caratteristiche latenti simili.
3. Basati sull’apprendimento dei comportamenti dei residenti: Il sistema osserva nel tempo le abitudini (es. ogni volta che Joe è in una stanza e la temperatura è sopra X, accende l’aria condizionata a Y) e suggerisce regole. Per questo usiamo le Reti Bayesiane, che sono un analogo probabilistico della logica proposizionale usata per le regole. In pratica, le connessioni tra stati (sensori) e azioni (attuatori) che co-occorrono frequentemente vengono rafforzate.
4. Basati su obiettivi condivisi: Aggiungendo una clausola PERCHÉ (BECAUSE) alla regola, tipo SE ORE 7:00 ALLORA IMPOSTA Sveglia ACCESA PERCHÉ "Voglio andare al lavoro presto". Se un’altra persona imposta una regola diversa ma con lo stesso obiettivo (magari scritto in modo leggermente diverso, ma semanticamente simile), il sistema può fare raccomandazioni incrociate.

Il processo di apprendimento agisce come una fonte di regole. I suggerimenti vengono valutati dall’Amministratore delle Regole o dall’utente, che può accettarli o rifiutarli. Se un utente rifiuta una raccomandazione, la “soglia” per quel tipo di suggerimento si alza, rendendolo meno probabile in futuro.

Sicurezza Prima di Tutto: Chi Può Fare Cosa?

Uno dei principi innovativi del nostro design è come gestiamo il controllo degli accessi. Invece di dare permessi diretti sui dispositivi, l’utente specifica uno stato desiderato per una variabile controllata (es. “voglio la temperatura a 22 gradi in salotto”). È poi il Concrete Action Process a tradurlo in attivazioni di dispositivi specifici. Quindi, il controllo accessi si basa sulle richieste di stato, non sull’accesso diretto ai dispositivi. Se un utente vuole cambiare la temperatura di una stanza che non gli “appartiene”, la richiesta viene negata.

Seguiamo i principi delle “3 A” del controllo accessi: Autenticazione, Autorizzazione, Audit. La nostra soluzione si basa su:

• Minimizzare la fiducia tra i moduli.
• Isolare i moduli.
• Autenticare l’utente.
• Separare i privilegi.
• Canali di comunicazione sicuri.

Abbiamo un Servizio di Autenticazione (AS) e un Servizio di Controllo Accessi (ACS) che usa delle Liste di Controllo Accessi (ACL). Queste ACL specificano per ogni utente (soggetto) e per ogni variabile di stato (oggetto) quali azioni sono permesse (lettura, modifica, ecc.). Quando uno stakeholder vuole aggiungere una regola, il sistema verifica che abbia i permessi per leggere i dati dei sensori coinvolti e per modificare lo stato degli attuatori specificati nella regola. La risoluzione dei conflitti tra regole può anche basarsi su una gerarchia di priorità tra i ruoli: la regola di un utente con priorità più alta (es. il proprietario) può sovrascrivere quella di un utente con priorità più bassa (es. un ospite).

Dalla Teoria alla Pratica: Il Nostro Sistema Pilota

Abbiamo implementato e testato questa architettura in un complesso residenziale con quattro unità abitative diverse, con abitanti con ruoli e preferenze differenti, sotto l’egida della compagnia elettrica locale. Il sistema usa Node.js per il server, MongoDB come database, e React per l’interfaccia. I processi di apprendimento sono microservizi in Python. I Concrete Action Process e Concrete State Process girano su Raspberry Pi che comunicano con gli elettrodomestici. Questi Raspberry Pi, chiamati “stazioni base”, traducono i protocolli proprietari dei vari dispositivi (condizionatori, lavatrici, prese intelligenti, sensori di movimento) in modo che le regole astratte possano funzionare ovunque.

Abbiamo testato vari scenari:

• Utenti multipli e gerarchie: Un residente imposta una regola per la luce, il proprietario ne imposta un’altra che ha la precedenza in certi orari.
• Regole conflittuali e risoluzione: Due residenti allo stesso livello gerarchico tentano di inserire regole contraddittorie per il condizionatore; il sistema segnala il conflitto e il proprietario (manager delle regole) autorizza una delle due.
• Portabilità: La stessa regola (es. SE Joe IN Salotto ALLORA IMPOSTA AC 25) funziona in case diverse con hardware diverso.
• Sistemi di raccomandazione:
  • Stakeholder comuni: La compagnia elettrica spinge la regola del lavaggio notturno.
  • Apprendimento comportamentale: Il sistema impara che l’utente accende la luce al risveglio e suggerisce una regola.
  • Obiettivi condivisi: Regole con la clausola “PERCHÉ” permettono raccomandazioni incrociate tra utenti con obiettivi simili.

Un’Interfaccia a Misura d’Uomo (e di Stakeholder)

L’interfaccia utente riflette la nostra architettura. È gerarchica, per adattarsi a diverse strutture organizzative e ai permessi dei vari ruoli. Si parte da una visione d’insieme delle case sotto il proprio controllo, per poi scendere nel dettaglio della singola casa, stanza, o persino del giardino. L’app principale ha diverse schede:

• “Spazi”: Mostra tutte le aree gestite.
• “Posizione”: Indica la posizione dell’utente rispetto alla sua residenza (utile per regole come “accendi il boiler quando sono a X km da casa”).
• “Suggerimenti”: Presenta le raccomandazioni del sistema.
• “Approfondimenti”: Dettaglia i consumi elettrici per dispositivo e per mese.

Entrando in uno spazio specifico, si accede al pannello di gestione della casa con la sua planimetria, e a schede per “Regole” (per visualizzare, aggiungere, modificare o cancellare regole, a seconda dei permessi) e “Calendario” (per programmare eventi, come lezioni in una scuola smart, preparando l’aula e spegnendo tutto alla fine per risparmiare energia).

Insomma, come avrete capito, gestire una casa (o uno spazio) intelligente con tanti “cuochi” che vogliono mettere il loro mestolo nella zuppa non è banale. Ma con un’architettura ben pensata, un linguaggio di regole flessibile, meccanismi di risoluzione dei conflitti, sistemi di raccomandazione che imparano e, soprattutto, una solida gestione della sicurezza, si può fare! E i vantaggi vanno ben oltre la semplice comodità domestica, aprendo scenari interessantissimi per ospedali, scuole, uffici e intere città intelligenti. Un bel viaggetto nel futuro, non trovate?

Fonte: Springer