Differenze tra le versioni di "Progetto Domotico Senza Nome"

Da raspibo.
Jump to navigation Jump to search
Riga 37: Riga 37:
  
 
Protocollo basato su '''http''' come una serie di API RESTful esposte dall'HAL; probabilmente i dati verranno scambiati in formato '''JSON'''.
 
Protocollo basato su '''http''' come una serie di API RESTful esposte dall'HAL; probabilmente i dati verranno scambiati in formato '''JSON'''.
 +
  
 
== HAL: Home Abstraction Level ==
 
== HAL: Home Abstraction Level ==
Riga 45: Riga 46:
  
 
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.
 
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.
+
 
 +
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.
 
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''' 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, ...)
  
 
= Specifiche implementative =
 
= Specifiche implementative =

Versione delle 15:59, 30 lug 2013

{{#if:| {{#if:| }} {{#if:| }}
Progetto
Domotica.png }}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 tramite introspezione 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

architettura di massima.

Descrivendo dall'alto verso il basso l'architettura di massima, incontreremo i seguenti componenti.

Interfacce 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 le interfacce 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.


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 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, ...)

Specifiche implementative