Differenze tra le versioni di "Progetto Domotico Senza Nome"
| Riga 14: | Riga 14: | ||
Deve essere possibile: | Deve essere possibile: | ||
| − | * '''descrivere (e ricevere tramite introspezione la descrizione di) un sensore''' in termini di sue capacità funzionali e di risposta. | + | * '''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'''. | * '''leggere e/o comandare un sersore'''. | ||
* '''comunicare coi sensori''' in maniera trasparente rispetto al mezzo fisico (ed al livello di rete, anche?) | * '''comunicare coi sensori''' in maniera trasparente rispetto al mezzo fisico (ed al livello di rete, anche?) | ||
| Riga 20: | Riga 20: | ||
* '''fornire diversi modi di controllo''' del sistema (GUI web, command line interface, ...) | * '''fornire diversi modi di controllo''' del sistema (GUI web, command line interface, ...) | ||
| + | = Architettura = | ||
| + | |||
| + | [[File:Pdsn_architettura.png|thumb|right|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. | ||
| + | |||
| + | L'HAL è implementato in un Raspberry o hardware superiore. | ||
| − | |||
| − | |||
| − | |||
| − | + | = Specifiche implementative = | |
| − | |||
Versione delle 15:44, 30 lug 2013
| 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 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
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.
L'HAL è implementato in un Raspberry o hardware superiore.