I LinkedService come gi`a accennato precedentemente, sono il cuore di DomoNet. Sono il costrutto di DomoML per mezzo del quale si rende possibile l’interoperabilit`a tra i diversi standard domotici e senza il quale DomoNet sarebbe una semplice interfaccia nei confronti di varie tecnologie.
I LinkedService sono formalizzati mediante il linguaggio DomoML e per- mettono, mediante il proprio formalismo, di associare con semplicit`a servizi resi disponibili dai device domotici. L’associazione `e possibile grazie al fat- to che ogni dispositivo e tutti suoi relativi servizi possono essere astratti mediante DomoNet e descritti con il medesimo linguaggio (DomoML). Gra- zie a una precedente trasformazione, non si tratta pi`u di device di questo o quello standard, con caratteristiche fisiche particolari e linguaggi di comu- nicazione aperti o proprietari, ma semplici entit`a che possono eseguire dei comandi mediante determinati input. A questo punto il ‘linkaggio’ di una entit`a con un’altra risulta immediata, e richiede, delle volte, solo alcuni pic- coli accorgimenti. Abbiamo gi`a visto nel paragrafo relativo alla descrizione dei domoDevice 2.1.1.1 che un tag LinkedService ha fondamentalmente due attributi.
2.2.2 I LinkedService 43 Gli attributi id e service, che identificano rispettivamente il dispositi- vo (identificatore univoco di DomoNet) e il servizio che si vuole richiamare all’esecuzione di un determinato servizio.
Ogni LinkedService possiede una serie di input (LinkedInput) che vanno opportunamente riempiti, per far si che il servizio da richiamare abbia tutti i parametri di ingresso necessari alla corretta esecuzione e che di conseguenza l’associazione abbia effettivamente luogo nei termini che l’utente aveva ini- zialmente immaginato. Ogni LinkedInput, possiede quindi gli attributi from e to che rispecchiano, come la logica suggerisce, il nome dell’input (from) del servizio chiamante, il cui valore deve essere associato all’input (to) del servi- zio da chiamare. E’ anche possibile per`o associare a un input del servizio da richiamare l’output (se presente) del servizio chiamante. L’unica differanza risiede nel fatto che l’attributo from del LinkedInput non conterr`a il nome di un input ma bens`ı lo stesso nome del servizio da richiamare.
Questi erano inizialmente, nel prototipo di DomoNet, i soli parametri permessi nella scrittura di un LinkedService, ma in seguito, utilizzando il prototipo in situazioni che divenivano sempre pi`u simili a ci`o che la realt`a riserva, `e stato necessario incrementare le possibilit`a offerte da DomoML.
Situazioni diverse avvengono ancora una volta per le particolarit`a delle diverse tecnologie, ma non per via dei diversi standard di comunicazione, che con DomoNet sono stati risolti, ma anche nella semplice logica delle cose. Un esempio su tutti, spiegato anche nel capitolo relativo alla collaborazione con AlmaViva 7, mette in evidenza come anche nel caso in cui due standard prevedano tipi di input simili (ad esempio interi), la loro semantica pu`o es- sere completamente differente. E’ il caso ad esempio del mondo Konnex e quello BTicino. In BTicino l’attivazione di un attuatore, soprassedendo tut- ta la sintassi e il protocollo specifico, avviene mediante l’input 1, mentre la disattivazione dello stesso, mediante l’input 0.
In Konnex la logica semantica `e esattamente opposta. Questo significa che nel momento in cui si vuole scrivere un LinkedService, non pu`o essere fatta una semplice associazione di input, pena la scorrettezza delle azioni eseguite. In figura 2.7 si pu`o vedere un LinkedService e gli attributi aggiunti per risolvere il problema appena descritto.
44 DomoNet
. .
<LinkedService id="53" url="www.WebService.com" service="ComandoKonnex" ifInput="value" hasValue="1">
<linkedInput value="0" /> </LinkedService>
<LinkedService id="53" url="www.WebService.com" service="ComandoKonnex" ifInput="value" hasValue="0"> <linkedInput value="1" /> </LinkedService> . . .
Figura 2.7: Gli attributi ifInput ed hasValue aggiunti nel LinkedService per gestire semantiche differenti
dell’esecuzione del LinkedService quale valore assume un determinato input, ed associare eventualmente un valore diverso al servizio da richiamare, un valore che in questo modo sia in concordanza con la semantica dell’azione da compiere. Nell’esempio in figura 2.7, i LinkedService sono associati a un servizio di BTicino che, in accordo con la sua logica, invia un valore 1 per abilitare un dispositivo. Quando questo avviene, DomoNet, mediante la de- scrizione del LinkedService si occupa di sostituire il valore 1 con il valore 0 e di inviare quindi il messaggio al techManger Konnex che si occuper`a di far eseguire l’operazione.
Un altro problema che pu`o verificarsi, `e il caso in cui si voglia far esegui- re, dopo una determinata azione, un servizio che vuole parametri di input che non hanno alcuna relazione in numero e/o semantica con gli input del servizio chiamante. Prendiamo ad esempio il caso in cui si voglia associare un determinato messaggio registrato allo scattare di un allarme come potrebbe essere ad esempio un allagamento o una fuga di gas. Il messaggio registra- to, risiede e pu`o essere riprodotto su un periferica UPnP. Il LinkedService associato al servizio allarme `e del tipo mostrato in figura 2.8.
2.2.2 I LinkedService 45
. .
<LinkedService id="27" url="" service="Play" ifInput="value" hasValue="1">
<linkedInput to="mediaRendererId" value="52" /> <linkedInput to="mediaRendererURL" value="" />
<linkedInput to="mediaContainerId" value="0/Music" /> <linkedInput to="mediaContentId" value="0/AllarmMessages/AllagamentoBagno1Piano.mp3" /> </LinkedService> . . .
Figura 2.8: Gli attributi ifInput ed hasValue aggiunti nel LinkedService per gestire semantiche differenti
no (ifInput=’value’ hasValue=’1’), viene richiamato il servizio ‘play’, assegnando i giusti valori ai parametri che in seguito, dal TechManager UPnP verrano utilizzati per selezionare il messaggio prescelto.
Questo esempio mostra quindi come sia possibile assegnare parametri ad un servizio chiamato da un LinkedService senza che questi debbano esse- re necessariamente l’input o l’output del servizio chiamante. Grazie a queste modifiche, si sono ampliate le possibilit`a offerte dal framework DomoNet, con- sentendo applicazioni tra dispositivi domotici a valore aggiunto, che rendono davvero potente e flessibile questo strumento.
Capitolo 3
Tech-manager BTicino
In questo capitolo viene descritta un’estensione di DomoNet, effettuata allo scopo di permettere l’integrazione nella rete dei dispositivi BTicino. In questo modo, anche i device domotici di questa azienda potrebbero essere utilizzati all’interno di una rete domotica integrata e potrebbero comunicare e interagire con i dispositivi Konnex e UPnp gi`a installati.
3.1
BTicino
La Bticino, storica azienda italiana nel campo dell’impiantistica elettrica domestica e industriale, quotata in borsa a Parigi, `e presente in 60 Paesi ed `e leader nel mercato degli interruttori elettrici in Centro e Sud America e in Egitto. Il suo nome `e un marchio affermato quasi come la Coca Cola. L’80 per cento degli italiani, infatti, lo cita e lo conosce quasi spontaneamente. I numeri di Bticino sono di eccellenza assoluta: 700 milioni di euro di fatturato, 2724 dipendenti a tempo indeterminato, 7 stabilimenti in Italia, 63 milioni di interruttori civili prodotti in un anno, 400 progettisti che lavorano per sviluppare nuovi prodotti, 50 neolaureati assunti ogni anno e il 5 per cento del fatturato investito in ricerca e sviluppo [24].
Nel corso dell’ultimo decennio BTicino ha concentrato il suo reparto di ricerca e sviluppo nella domotica, con l’obbiettivo di innovare l’installazione elettrica nel residenziale, e favorendone l’ascesa. In quest’ottica `e nato il progetto My Home BTicino, un sistema che integra molteplici soluzioni, dalle pi`u semplici alle pi`u articolate [7], e che permette di rispondere alla crescente
48 Tech-manager BTicino domanda di funzioni sempre pi`u evolute, in particolare nelle abitazioni e nel terziario.