Progetto Domotico Senza Nome
| Progetto |
 }}Progetto Domotico Senza Nome
|
|---|
| infrastruttura di sensori per una casa intelligente |
| Gruppo: [[Gruppo_{{{gruppo}}}|{{{gruppo}}}]]
}} |
| [ social network] |
| [ code repository] |
Obiettivi
Il Progetto Domotico Senza Nome ha come obiettivo - oltre al trovarsi un nome decente - la creazione di una architettura completa per l'automazione della casa e l'interazione tra dispositivi.
Il progetto spazia dalla sensoristica/elettronica alla interfaccia utente di comando.
Specifiche funzionali
Deve essere possibile:
- descrivere (e ricevere la descrizione di) un sensore in termini di sue capacità funzionali e di risposta (per praticità, in questo documento intendiamo con "sensore" anche gli attuatori).
- leggere e/o comandare un sersore.
- comunicare coi sensori in maniera trasparente rispetto al mezzo fisico (ed al livello di rete, anche?)
- raggruppare ed astrarre i sensori in maniera coerente con la loro effettiva disposizione e/o funzionalità nella casa.
- fornire diversi modi di controllo del sistema (GUI web, command line interface, ...)
Architettura
Descrivendo dall'alto verso il basso l'architettura di massima, incontreremo i seguenti componenti.
Livello utente
GUI orientate ad umani e non. Avremo quindi interfacce web che consentono di gestire i sensori ad esempio per stanza o funzionalità, oltre che a leggerne i valori ed impartire comandi.
Oltre al web, sarà probabilmente implementata anche una command line interface ed è pensabile che uno o più demoni possano usare la stessa interfaccia verso l'HAL al fine ad esempio di gestire trigger e reagire ad eventi più o meno complessi.
Si assume che questa parte sia sempre implementata su un server (Raspberry o superiore) e che non siano presenti particolari restrizioni, in quanto a risorse.
Interfaccia tra il livello utente e l'HAL
Protocollo basato su http come una serie di API RESTful esposte dall'HAL; probabilmente i dati verranno scambiati in formato JSON.
Esempi di comunicazione:
- utente->hal: forniscimi l'elenco di tutti i sensori di tipo "termometro".
- utente->hal: accendi "luce salotto".
- utente->hal: reagisci all'eccessivo assorbimento complessivo spegnendo la lavatrice e/o la lavastoviglie.
- hal->utente: "come da trigger precedentemente creato, attivo il sistema antincendio avendo il sensore di CO2 superato la soglia X".
HAL: Home Abstraction Level
(precedentemente noto come m2m: se il nome non piace, cambiamo pure di nuovo)
Gli oggetti esposti dall'HAL saranno le rappresentazioni generiche dei diversi sensori presenti nella casa, oltre che della loro disposizione fisica o logica. Viene inoltre fornito accesso alla lettura ed al controllo dei sensori stessi.
L'HAL conosce quali sensori sono presenti nella casa (tramite una qualche forma di configurazione manuale o discovery ancora da definire) e la loro classe di appartenenza e configurazione.
Comunica con i sensori tramite il canale fisico e di rete appropriato, mantenendo uno stato (ed uno storico dello stato?) della rete di sensori. Gestisce la comunicazione, incluse eventuali ritrasmissioni.
Probabilmente (TBD?) incorporerà funzionalità basilari di reazione a triggers ed eventi.
L'HAL è implementato in un Raspberry o hardware superiore.
interfaccia tra l'HAL e l'elettronica
A prima vista potrebbero essere necessarie diverse implementazioni di driver di comunicazioni (implementati in HAL e nell'hardware dei vari sensori) per accedere ai diversi sensori che possono essere connessi a GPIO di un Raspberry, ad un Arduino, un JeeNode o altro ancora. Quando possibile si privilegerà http su TCP/IP, oppure una qualche implementazione di un queue manager. Tutti i dati scambiati saranno in formato JSON.
Oltre ad una serie di API su entrambi i lati (per gestire inizializzazione, introspezione, configurazione, pushing e polling), gioca qui un ruolo importante il Sensor Description Language (SDL) che - sempre in formato JSON - va a descrivere come un dato sensore è configurato e quali sono le sue capacità (che misure fornisce, che comandi può ricevere, se è accessibile via polling o funziona in pushing, ...)
Esempi di comunicazione:
- hal->elettronica: forniscimi la tua configurazione in formato SDL.
- elettronica->hal (nella configurazione SDL): sono un sensore di temperatura; leggo da 0 a 100 gradi centigradi con precisione 1; puoi chiedermi la temperatura via polling (al massimo 1 volta ogni 5 secondi); non faccio pushing; per chiedermi la temperatura, usa una GET /temp (ritorno un intero tipo {temperature: 42})
- hal->elettronica: interruttore X, spegniti (con una chiamata tipo POST /set_switch e body {state: false})
Elettronica e driver
Attorno all'elettronica vera e propria (di cui verranno forniti schemi di base per i vari sensori), si va a costruire un driver che ne astrae le funzionalità, descritte tramite l'SDL.
Questo livello è quindi essenzialmente composto di tre parti:
- l'hardware, descritto da uno schema elettronico (per Raspberry, Arduino, JeeNode, ...)
- il driver specifico per la tupla (hardware, driver di comunicazione), che espone le API e comunica con l'HAL. Esempi di tuple: (raspberry, http), (arduino, mqtt).
- la configurazione del sensore in SDL.
Resta aperta la questione se l'SDL debba o meno comprendere informazioni quali i PIN da usare per letture e scritture verso l'hardware o se non vadano invece previsti degli hook a funzioni (io-voto-la-seconda ;)
Specifiche implementative
Essendo il progetto in fase embrionale, è ragionevole che le specifiche implementative vere e proprie non emergano prima di settimane o mesi.
Va ovviamente consigliato un approccio incrementale, partendo da piccoli componenti ed - ad esempio - ignorando per il momento qualsiasi cosa non sia http su TCP/IP.
È inoltre richiesta una analisi dell'esistente, per capire se e come sono già stati affrontati e risolti alcuni di questi problemi. Si consiglia poi di valurare la creazione di mock up anche per la parte dei driver, in modo da non dover avere hardware per lo sviluppo degli altri componenti.