I dipositivi connessi a My Home

Una delle prime scelte effettuate nella fase preventiva del lavoro `e con- sistita nel capire quale fosse il modo migliore per effettuare il discovery dei device collegati alla rete My Home. L’approccio pi`u intuitivo sarebbe stato quello di richiedere direttamente al server BTicino i device collegati al bus domotico, effettuando tante richieste per ogni possibile categoria BTicino, come Illuminazione (CHI=1), Automazione (CHI=2), Multimedia (CHI=7) ecc. Il problema fondamentale di questo approccio `e l’impossibilit`a nel protocollo OPEN di poter conoscere, chiedendolo direttamente a un dispositivo, quali sono i possibili comandi che pu`o accettare ed eseguire. L’insieme dei COSA ammissibili per un determinato device, `e generalmente un sottoinsieme di tutti quelli elencanti nella tabella di tutti i possibili COSA di una particolare categoria (per ogni CHI [Appendice A]). Prendiamo come esempio la richiesta generale di tutte le luci collegate al sistema My Home della tabella 3.6.

Messaggio OPEN Descrizione

*#1*0## -> Server Open Richiesta generale dello stato luci

*1*1*11## -> Client Punto luce 11 acceso

*1*5*12## -> Client Punto luce 12 con dimmer al 50%

*1*0*25## -> Client Punto luce 25 spento

*1*19*26## -> Client Punto luce 26 con mancanza carico

*#*1## -> Client Fine lista dispositivi

Tabella 3.6: Esempi di richiesta e risposta stato luci

Non appena il server OPEN viene interrogato sui dispositivi presenti nel sistema, per una determinata area domotica, esso risponde con un messaggio OPEN di stato per ogni device di quella categoria. E’ evidente che non `e possibile conoscere con esattezza se, a titolo di esempio, si tratta del dispo- sitivo F411/4 [8], un attuatore a 4 rel`e, oppure il dispositivo F413 [8], un dimmer. La differenza `e importante in quanto il primo non pu`o effettuare n´e il lampeggio della luce n´e la funzione dimmer. Differenze sostanziali come queste si amplificano nel momento in cui i dispositivi non sono pi`u semplici attuatori, ma device pi`u evoluti come pu`o essere un sistema multimediale o un device di power management.

3.3.5.1 I dipositivi connessi a My Home 69 Alla luce di quanto detto, si `e preferito utilizzare un file di descrizione dei dispositivi BTicino da controllare, utilizzando il formalismo di DomoML. L’esempio della descrizione di un dispositivo BTicino per l’automazione `e visibile in figura 3.6

<device serialNumber="*2**31##"

description="Tapparella del soggiorno" tech="BTICINO">

<service description="SetthestatusAvvolgibile" name="SET_STATUS" prettyName="UP_DOWN Avvolgibile">

<input description="Thevalue" name="status" type="STRING"> <allowed value="2"/> <allowed value="1"/> <allowed value="0"/> </input> </service> </device>

Figura 3.6: Descrizione di un dispositivo di automazione BTicino

La figura 3.6 mostra il codice xml utilizzato per descrivere un disposi- tivo di gestione automatismi BTicino come il F411/2 [8] che comanda un avvolgibile automatizzato mediante un motore.

L’attributo serialNumber viene utilizzato per descrivere il realAddress del dispositivo all’interno della rete My Home. Per farlo viene utilizzato lo stesso formalismo del linguaggio OPEN descritto in 3.4.

L’indirizzo *2**31## rappresenta infatti un comando OPEN con attri- buti CHI=2 (categoria automatismi) e DOVE=31 (punto automazione 31), non menzionando alcun campo COSA. Il realAddress verr`a utilizzato all’interno del TechManager BTicino per comandare e riconoscere il dispositivo nella propria sottorete domotica.

Gli attributi description e tech per il tag device, cos`ı come tutti gli attributi dei tag service e input vengono utilizzati nell’architettura di DomoNet per poter descrivere input e servizi come descritto in 2.1.1.1.

I tag allowed contengono gli input consentiti a un particolare device, cio`e i corrispettivi COSA in OPEN Web Net 3.4.

70 Tech-manager BTicino Nel caso specifico della figura 3.6 i possibili cosa per quel dato dispositivo sono SU (COSA=1), GIU (COSA=2) e STOP (COSA=0).

Capitolo 4

UPnP AV

In questo capitolo viene brevemente descritto lo standard UPnP AV: lo standard UPnP per il trasferimento di contenuti multimediali tra dispositivi.

4.1

Introduzione

Nella maggior parte degli scenari UPnP, un Control Point controlla le operazioni di uno o pi`u UPnP device per raggiungere determinati scopi. Seb- bene il Control Point gestisca molti device, tutte le interazioni tra questo e l’insieme dei device sono tra loro isolate. Il Control Point coordina le opera- zioni per permettere una completa e sincronizzata risposta all’utente. I singoli device quindi non hanno alcun tipo di interazione diretta con gli altri [37]. Tutto il coordinamento tra i device avviene mediante il lavoro del Control Point, e non degli stessi device come mostrato in figura 4.1(a).

Generalmente in scenari che riguardano contenuti audio/video, `e neces- sario instaurare un flusso multimediale tra un dispositivo e un altro. Come mostrato in figura 4.1(b), un AV Control Point interagisce con due o pi`u devi- ce UPnP creando rispettivamente un sorgente e un fruitore di contenuti [38]. Sebbene il Control Point coordini e sincronizzi entrambi i device, quest’ul- timi interagiranno tra loro in modo indipendente usando un protocollo di comunicazione diverso da UPnP per il trasferimento audio/video. Il Control Point utilizza UPnP per inizializzare e configurare i device al trasferimento del contenuto multimediale prescelto, fa partire il flusso multimediale tra i device selezionati e successivamente pu`o essere disconnesso senza influire in

72 UPnP AV

(a) Tipico modello di interazione tra device UPnP

(b) Interazione tra device AV UPnP

Figura 4.1: Confronto tra modello UPnP classico e AV UPnP

nessun modo sul flusso audio/video instaurato, in quanto, a questo punto, non `e pi`u direttamente coinvolto nel trasferimenti dei contenuti. In altre pa- role il cuore dell’applicazione (il flusso multimediale) continua a funzionare senza l’intervento e la presenza del Control Point.

Come `e possibile vedere nella figura 4.1(b), sono coinvolte tre diverse entit`a: il Control Point, la sorgente del contenuto multimediale, chiamato MediaServer, e il fruitore di contenuti, chiamato MediaRenderer. Nelle sezio- ni che seguono verranno descritte tutte e tre le entit`a come se queste fossero device indipendenti nella rete UPnP. Anche se questa configurazione `e chia- ramente possibile (per esempio un telecomando, un videoregistratore e una TV), nel realt`a l’architettura AV UPnP supporta arbitrarie combinazioni delle tre entit`a integrate in un singolo dispositivo fisico. Per esempio una TV pu`o essere considerato un MediaRenderer, ma gli apparecchi televisivi hanno integrato un sintonizzatore TV che pu`o rendere il device un MediaServer se viene per esempio reso disponibile un canale e visualizzato su un altro Me- diaRenderer. Allo stesso modo molti MediaSever e/o MediaRenderer possono includere un Control Point al proprio interno. Per esempio un lettore MP3

4.4.2 Playback Architecture 73