chManager coinvolti nello sviluppo: il techManager BTicino e il techManager UPnP.
5.2
Il techManager BTicino
Il tech Manager BTicino descritto nel capitolo 3 non si limita a rendere disponibile a DomoNet e quindi alle altre reti domotiche contenuti informa- tivi di tipi semplici, come pu`o essere una stringa, un intero, un booleano. Nell’ambito dello sviluppo di questo tech manager `e stata resa possibile an- che la comunicazione di dati multimediali come un flusso di immagini rese disponibili, per esempio, da una telecamera da interno che possiamo trovare nello stesso starter kit BTicino mostrato in figura 3.5.
La telecamera in questione `e un modello di videocamera che trova la sua collocazione naturale in un contesto di videocitofonia, o di video-controllo da interni. Essa `e completamente gestita dal server OPEN Bticino e non `e possibile instaurare una comunicazione diretta con la videocamera. Per interfacciarsi col dispositivo video, `e necessario aprire una connessione tcp-ip su porta 20000 con il web server, che rende cos`ı disponibile l’immagine. La connessione al web server `e permessa ai soli client che abbiano un indirizzo IP a cui il server OPEN BTicino consente l’accesso senza password.
In particolare, per ricevere l’immagine `e necessario effettuare una richiesta di tipo http del file ‘telecamera.php’. La risposta che si ottiene `e composta da un header, mostrato in figura 5.2, seguito dall’immagine in formato JPEG.
HTTP/1.1 200 OK Server: grabtofile Connection:close
Content-Length: <length\_image> Content-Type: image/jpeg
Figura 5.2: Header di risposta del videoServer
La telecamera restituisce in realt`a uno stream di immagini jpeg con una frequenza di circa 100 millisecondi.
82 DomoNet: un’estensione multimediale Per rendere disponibili le immagini di questa telecamera ad altri tech- Manager, ogni qual volta la telecamera viene accesa, mediante un comando OPEN del tipo *7*0*4000 proveniente direttamente dal bus OPEN o ri- chiesta da un client o un techManger diverso da quello di BTicino, vengono contemporaneamente creati due thread.
Un primo thread, chiamato IntraVideoComunication, si occupa di creare una connessione tcp-ip sulla porta 10000 nei confronti del server OPEN e di richiedere, ad intervalli di circa 100 millisecondi, immagini provenienti dalla telecamera. L’immagine ottenuta viene salvata in un buffer e resa disponibile a chi ne fa richiesta mediante un metodo sincronizzato con la scrittura. Nel caso ci fossero altre telecamere collegate alla rete BTicino, queste potranno essere controllate da altrettanti thread che apriranno delle connessioni con il server BTicino su altre porte. La telecamera uno `e infatti disponibile sulla porta 10000, la due su porta 10001 e cos`ı via.
Il secondo thread, chiamato VideoServer, si occupa invece di creare un ServerSocket e di aspettare eventuali richieste provenienti da altri techMa- nager. Ne caso ci sia una richiesta, il ServerSocket accede al buffer utilizzato dal thread IntraVideoComunication e restituisce l’immagine presente in quel momento.
Le informazioni per far s`ı che gli altri TechManager possano comunicare con il VideoServer del TechMAnager BTicino, come la porta su cui il Server- Socket `e stato aperto, vengono messe all’interno di un messaggio che viene inviato tramite un LinkedService associato al servizio ‘accendi telecamera’.
5.3
Il techManager UPnP
Nel techManager UPnP, gi`a presente in DomoNet `e stato integrato un AV mediaServer UPnP, che segue le linee guida descritte nel capitolo 4, allo scopo di permettere la gestione dei contenuti multimediali.
Il mediaServer utilizzato e modificato per poter essere integrato in Do- moNet fa parte del progetto open source CyberMediaGate scaricabile da http://sourceforge.net/projects/cgupnpjava/. La modifica `e consisti- ta nello sfoltimento della parte del progetto dedicata alla UI, non necessaria a DomoNet, e l’integrazione vera e propria all’interno del framework.
5.5.4 Conclusioni 83 Il funzionamento del techManager UPnP, per quanto concerne l’esten- sione multimediale, pu`o essere brevemente descritto nel modo seguente. Nel momento in cui il techManager BTicino attiva la telecamera (a causa di una richiesta che pu`o essere venuta da un utente, per mezzo di un client di DomoNet o da uno stesso comando BTicino, o anche da uno scenario che prevede l’accensione della telecamera) un LinkedService della telecamera BTicino comunica, mediante un messaggio DomoML, al techManger UPnP quali sono i parametri di connessione che devono essere utilizzati (in parti- colare l’indirizzo e la porta) per potersi connettere al VideoServer BTicino che nel frattempo `e stato attivato, ed si trova in attesa di eventuali richieste. Il TechManager UPnP, acquisiti i parametri di connessione, lancia un thread VideoClient che periodicamente riceve le immagini della telecamera BTicino e le salva localmente in una directory.
Quando l’AV MediaServer, ora integrato in DomoNet, riceve la richiesta, da parte di un Control Point UPnP, di instaurare uno stream verso un Me- diaRenderer , che veda come ‘contenuto multimediale’ proprio le immagine generate dalla telecamera BTicino, potr`a instaurare la connessione usando il protocollo UPnP AV in quanto, grazie alla connessione instaurata tra i TechManager, l’immagine video sar`a a questo punto una delle risorse che l’AV MediaServer pu`o condividere nei confronti delle periferiche UPnP. Per quest’ultime, le risorse disponibili sull’AV MediaServer e accessibili mediante il protocollo spiegato nel capitolo 4 sono dei contenuti audio o video come tutti gli altri e in nessun modo distinguibili da quelli che un AV MediaServer mette a disposizione normalmente.
5.4
Conclusioni
La condivisione di contenuti multimediali fin qui spiegata vuole essere una prima dimostrazione di fattibilit`a, nel contesto DomoNet, dello scambio di informazioni audio/video oltre a quelle di tipo tradizionale, e l’ideazione di una valida architettura per lo scambio dei contenuti tra ogni TechManager.
Lo scambio di informazioni che avvengono tra il TechManager BTicino e quello UPnP sono per il momento solo unidirezionali. Difatti il TechManager BTicino mette a disposizione delle immagini che vengono distribuite ai de-
84 DomoNet: un’estensione multimediale vice UPnP che ne fanno richiesta, ma non `e possibile il viceversa. Il motivo di questa asimmetria risiede nel fatto che nella fase di sviluppo della tesi non era disponibile una periferica BTicino che potesse essere utilizzata come rendererdi un qualche contenuto multimediale. Se una periferica UPnP pu`o infatti essere facilmente simulata da un PC mediante lo sviluppo di un soft- ware che ne emula il funzionamento, o ancora meglio utilizzando una delle tante periferiche virtuali UPnP disponibili in rete, la stessa cosa non pu`o essere fatta per un device BTicino, che diventa disponibile solo acquistando il device specifico.
Capitolo 6
Configuratore di LinkedService
In questo capitolo viene descritta l’interfaccia DomoConfigurator, imple- mentata durante il lavoro di questa tesi, per rendere pi`u intuitivo, veloce e potenzialmente privo di errori, il ‘linking’ (LinkedService) tra i servizi dei dispositivi DomoNet.
6.1
Introduzione
I LinkedService, descritti nel paragrafo 2.2.2, possono essere definiti a tutti gli effetti il cuore di DomoNet. Per mezzo di essi `e possibile rende- re interoperabili tecnologie che, altrimenti, si troverebbero impossibilitate a comunicare tra loro. Una volta implementato ed incluso in DomoNet il tech- Manager di una determinata tecnologia, le sue risorse sono immediatamente disponibili per un’eventuale associazione di queste, con altre risorse presenti nella rete DomoNet. L’unico lavoro aggiuntivo da compiere `e proprio quello di configurare i LinkedService perch´e facciano quello che desideriamo. Possia- mo effettuare una semplice connessione tra un device di comando e un device attuatore (es. pulsante e lampadina) oppure associazioni pi`u elaborate come la realizzazione degli scenari del tipo ‘uscita di casa’ che coinvolgono a ca- scata pi`u componenti diversi, come luci, tapparelle, elettrovalvole, il sistema antifurto ecc.
L’unico problema, se cos`ı possiamo considerarlo, `e la ripetitivit`a della scrittura del codice xml necessario all’implementazione di determinati Lin- kedService. Come si `e visto nella sezione 2.2.2, un tag LinkedService richiede
86 Configuratore di LinkedService gli attributi id, che specificano l’identificatore univoco assegnato da Domo- Net al dispositivo che si vuole ‘linkare’, l’attributo url, nel caso il dispositivo sia connesso a un DomoNet diverso da questo e l’attributo service che spe- cifica il nome del servizio appartenete al device identificato dagli attributi precedenti. A queste informazioni, necessarie alla scrittura di ogni Linked- Service, `e necessario aggiungere, per ogni input del servizio da richiamare, l’input del servizio eseguito da associare.
E’ ovvio che nel momento in cui i device collegati a DomoNet diventano numerosi, la creazione e la modifica di pi`u LinkedService pu`o essere lenta, noiosa e generare errori dovuti al fatto le informazioni necessarie sono varie e numerose.
Per rendere la configurazione dei LinkedService meno noiosa, pi`u veloce e potenzialmente priva di errori `e stata sviluppata un’interfaccia che permette una visione di insieme e un intuitivo ‘linking’ tra i servizi dei dispositivi DomoNet.
6.2
JGraph
L’interfaccia chiamata DomoConfigurator utilizza una delle poche API open source disponibili in rete che permettono il disegno di grafi in java: JGraph, scaricabile dal sito http://www.jgraph.com/. Le classi principa- li di JGraph seguono il pattern architetturale model-view-controller e sono mostrate in figura 6.1.
6.6.2 JGraph 87 JGraph `e un estensione di un JComponent che contiene riferimenti al GraphModel, al GraphLayoutCache e la propria GraphUI.
Il GraphModel memorizza la struttura logica di un grafo, e definisce delle interfacce che un oggetto deve implementare per memorizzare il modello di un grafo, e mette a disposizione dei metodi per modificare e ricavare queste infor- mazioni. L’implementazione di default di GraphModel, DefaultGraphModel pu`o comunque essere usata per la maggior parte delle applicazioni che usano JGraph. Il GraphLayoutCache `e la vista (o viste) di un grafo. Possono essere considerati come uno o pi`u layer logici al di sopra del modello del grafo. Ha il compito di presentare visivamente il grafo in modi diversi, aggiornando auto- maticamente eventuali cambiamenti che avvengono all’interno del modello. La classe GraphUI `e una interfaccia che estende ComponentUI e che si occupa del ‘Look and Feel’ del grafo.
Di importanza fondamentale in JGraph troviamo inoltre le celle: le celle sono gli oggetti che compongono un grafo. In una cella vengono memorizzate le informazioni dell’oggetto che rappresenta e le connessioni alle altre celle del grafo. Per modificare le informazioni di una cella, e far s`ı che questa venga visualizzata come desideriamo, `e necessario settare i suoi attributi. Quest’ultimi sono memorizzati in una AttributeMap, una classe che eredita da java.util.Map, e sono quindi salvati sotto forma di coppie chiave/valore, dove le chiavi sono attributi come il colore, la posizione, o il text font. In figura 6.2 `e mostrato lo schema di un AttributeMap di una cella.
Figura 6.2: AttributeMap di una cella
La classe GraphConstants ha la sola funzione di permettere l’accesso agli attributi della cella senza errori, elencando le possibili costanti . Una volta
88 Configuratore di LinkedService parlato delle celle, e di come queste siano gli oggetti fondamentali che com- pongono il grafo va fatta una precisazione importante: in JGraph esistono tre tipi di celle, che ereditano dalla classe AbstractCellView e la estendono secondo determinate caratteristiche. I tre tipi di cella sono i vertici, gli ed- ge, e le porte.
I vertici sono gli oggetti principali di un grafo, possono essere dei rettangoli, dei cerchi, delle icone o oggetti ancora pi`u complessi come JComponent. Gli edge sono di solito linee che rappresentano una connessione tra due ver- tici. Possono essere uno, pi`u di uno (edge paralleli), possono iniziare in un vertici e terminare in un altro, o iniziare e terminare sullo stesso vertici (loop). Le porte, infine, rappresentano il punto del vertice in cui iniziano o termi- nano gli edge. La ragione per cui le porte sono logicamente distinte dagli edge, risiede nel fatto che un vertice pu`o avere pi`u porte distinte, e quindi la struttura del modello del grafo deve rispecchiare il fatto che le connessioni verso un vertice possono essere distinte in funzione della porta a cui sono connessi. In figura 6.3 si possono vedere le relazioni tra AbstractCellView e le classi che rappresentano i tipi di cella appena descritti.
Figura 6.3: Relazioni tra AbstractCellView e le classi VertexView, EdgeView e PortView
6.6.3 Il configuratore 89
6.3
Il configuratore
Per lo sviluppo del configuratore di LinkedService sono state estese, tra le altre, le classi AbstractCellView e CellViewRenderer esposte nel paragrafo precedente.
Le classi che estendono AbstractCellView sono domoConfigurator.device.Device e domoConfigurator.device.Service. La classe Device ha il compito di
rappresentare un device DomoNet all’interno del configuratore. I parametri distintivi di un Device sono il nome del dispositivo, la tecnologia di apparte- nenza, il deviceId (identificatore univoco di un dispositivo in DomoNet), e i servizi associati al dispositivo.
Ogni Device infatti ha uno o pi`u servizi associati, identificati dalla classe Service, anch’essa un’estensione di AbstractCellView. Di un Service ven- gono memorizzati il nome, gli input ed il tipo degli input. Gli input di un servizio sono rappresentati a livello di JGraph da una o pi`u ‘porte’ associate al servizio.
Quando il DomoConfigurator viene avviato, utilizzando l’apposito pul- sante, viene aperta una connessione con DomoNet a cui vengono richiesti i DomoDevice attualmente collegati in rete. In considerazione del tipo di connessione effettuata, DomoNet considera il DomoConfigurator come un DomoClient descritto nel paragrafo 2.1.3.
Per ogni DomoDevice ricevuto, viene creato il corrispettivo oggetto De- vice e dei suoi Service in DomoConfigurator. La schermata visibile alla fine di questa fase `e quella mostrata in figura 6.4.
Come si pu`o vedere nella figura 6.4, dopo l’avvenuta connessione con Do- moNet e la relativa richiesta dei dispositivi connessi, vengono mostrati sul lato sinistro della schermata i device configurabili, raggruppati ognuno alla tecnologia di appartenenza. Nell’esempio sono disponibili tredici dispositivi della rete Konnex e sette della rete BTicino. Cliccando su uno qualunque degli elementi di questa lista, `e possibile vedere la rappresentazione del de- vice all’interno di DomoConfigurator nella zona centrale dell’applicazione. I device di volta in volta selezionati per essere visualizzati nella cosiddet- ta area di lavoro, posseggono il relativo checkbox selezionato. Per eliminare un dispositivo dall’area di lavoro, `e quindi possibile o deselezionare il check-
90 Configuratore di LinkedService
Figura 6.4: Schermata di DomoConfigurator dopo la connessione a DomoNet box o cliccare col pulsante destro del mouse sulla figura relativa al device e selezionare la voce elimina.
In figura 6.5 `e mostrata la schermata relativa a una configurazione di LinkedService effettuata mediante i dispositivi selezionati nel men`u a sini- stra.
Come `e possibile vedere in figura 6.4 per ogni device `e evidenziato il nome del dispositivo, i suoi servizi e i relativi input. Gli input di ogni servizio sono replicati sia sinistra del device che a destra. Il significato di questa scelta `e principalmente estetica, in quanto, se si considera una normale associazione logica, un collegamento `e generalmente visto da sinistra (source) verso destra (target). Poich´e ogni dispositivo pu`o in ogni momento essere, anche contem- poraneamente, sia la sorgente del servizio scatenante un LinkedService, sia il destinatario di un altro, per evitare, almeno in parte, collegamenti (edge) che attraversano i dispositivi, se un device `e una sorgente il collegamento pu`o essere fatto partire dall’input di destra, se `e un destinatario pu`o ter- minare nell’input di sinistra. Va comunque precisato che questa soluzione `e
6.6.3 Il configuratore 91
Figura 6.5: Schermata di DomoConfigurator durante la configurazione di LinkedService
puramente un suggerimento funzionale in quanto non incide in nessun mo- do a livello semantico utilizzare l’input sinistro di un servizio come sorgente anzich´e destinatario. In ogni caso, ogni edge inizia con il delimitatore ‘cer- chio’ dal lato sorgente, e termina con il simbolo freccia nell’input destinatario. Nella figura 6.5 vengono creati dei LinkedService tra vari dispositivi domotici.
Nell’esempio, si vuole fare in modo che all’ingresso in casa, permesso mediante il lettore di impronte digitali, venga automaticamente disattivato l’allarme, e acceso un percorso di luci predefinito. L’azione scatenante l’intero processo parte quindi proprio dal lettore d’impronte che cambiando stato, richiama il servizio ‘Apertura porta di ingresso’, che a cascata richiama il servizio ‘Reset allarme’ del device Centrale d’allarme e l’accensione di tre luci. Da notare c’`e in particolare il fatto che i LinkedService mostrati in figura, per come sono modellati non afferiscono tutti a un solo dispositivo, come pu`o
92 Configuratore di LinkedService essere la centrale d’allarme. Il LinkedService che in figura vede coinvolti il device Luce2 e Luce4, appartiene al device Luce2, quindi in una singola configurazione in DomoConfigurator sono stati creati in realt`a due scenari: uno scenario, quello principale, che possiamo chiamare ‘Rientro a casa’, e un secondo che riguarda le luci Luce1 e Luce2. Questo secondo scenario esiste anche al di fuori del contesto del primo, e fa si che all’accensione delle Luce1 venga accesa sempre anche la Luce2.
Una volta creata una configurazione, questa pu`o essere salvata median- te l’apposito pulsante presente nella toolbar. Questo generer`a il codice Do- moML equivalente alla rappresentazione grafica appena creata, senza ulteriori interventi.
Capitolo 7
Un caso reale: il progetto
AlmaViva-CNR
In questo capitolo viene descritta sommariamente l’esperienza della colla- borazione nel progetto AlmaViva-CNR, che durante il lavoro di tesi ha visto coinvolto il framework DomoNet e il TechManager BTicino sviluppato.
7.1
Introduzione
Durante lo sviluppo di questa tesi, DomoNet `e entrato al centro di una collaborazione tra il CNR e una delle maggiori realt`a italiane nel campo dell’Information Tecnology, la societ`a AlmaViva, la societ`a attualmente in tredicesima posizione tra le migliori aziende europee di ICT [36] . La collabo- razione prevedeva la messa in prova del framework DomoNet in un ambiente realmente vasto e eterogeneo di tecnologie domotiche, una simulazione che potesse essere considerata un vero e proprio test sulla solidit`a e la scalabilit`a del sistema DomoNet. Le ambientazioni domestiche prese in considerazione, e che prevedevano una riproduzione dimostrativa, sono cucina, soggiorno, bagno e camera da letto.
Per rendere il test una effettiva simulazione dei componenti domotici che possono essere presenti in una casa, sono stati utilizzati una variet`a di di- spositivi che spaziavano in una variet`a di standard diversi, e dove permesso (es. Konnex) anche in device dello stesso standard di comunicazione ma di produttori diversi.
94 Un caso reale: il progetto AlmaViva-CNR
Figura 7.1: Parte dei dispositivi utilizzati per la collaborazione AlmaViva La simulazione `e consistita nel riprodurre una serie di scenari che possono verificarsi ad esempio al rientro in casa da parte di una persona: dopo essersi identificata mediante le proprie impronte digitali, si apre la porta di casa e immediatamente viene accesa la luce dell’ingresso ed eseguita la propria playlist preferita. Una volta entrata i rilevatori di presenza presenti sul soffitto si accorgono automaticamente degli spostamenti all’interno dell’abitazione e accendono o spengono le luci di conseguenza.
In particolare una parte dei dispositivi utilizzati per testare l’applicazione sono stati:
Konnex
Allo standard Konnex, uno tra i pi`u diffusi e presenti sul mercato, ap- partenevano dispositivi come rivelatori di presenza, trasmettitori e un ricevitori di segnali radio, rilevatore di allagamento, una centralina di allarmi, un termostato, un attuatore per termosifone, delle pulsantiere da comando, controllori e interfacce per power line, un touchscreen da 10 pollici.
Signal device
A questa categoria appartengono il rilevatore di impronte digitali, il rivelatore di fumo, i contatti magnetici usati dall’impianto di allarme e per il risparmio energetico, il rilevatore di gas metano, il ripetitore luminoso di allarme ecc. Sono Dispositivi che non appartengono a uno
7.7.2 Controllo carichi 95