to si basa sull’invio di semplici segnali, che mediante un particolare dispositivo Konnex, un modulo bus di in/out, vengono trasformati in messaggi Konnex.
BTicino
Centralina controllo carichi, web server Vimar
Combinatore telefonico, pulsante di chiamata a corda UPnP
Mediacenter con funzioni UPnP collegato ad un monitor Altro
Router multifunzione per l’accesso al web, telecamere wireless per vi- deosorveglianza e controllo remoto
7.2
Controllo carichi
In questa collaborazione il techManager BTicino `e stato utilizzato nella sezione controllo carichi. L’obbiettivo di questa soluzione era impedire possi- bili black-out della rete elettrica tenendo sotto controllo il consumo energetico della casa. Nel caso questo si fosse avvicinato o avesse addirittura superato il limite massimo di energia, fissato nel proprio contratto stipulato con il fornitore energetico, verrebbero distaccati, tenendo conto di una priorit`a as- segnata, prima quegli elettrodomestici che creano minori disagi nel momento in cui vengono a mancare. Quindi sicuramente non un forno, che vedrebbe interrompere la cottura del cibo, n´e tanto meno il frigorifero, ma piuttosto un phon o una lavatrice in funzione.
Il componente scelto per il controllo dei carichi `e stato il modello F421PL BTicino. Questo monitorizza la rete elettrica mediante un anello toroidale al cui interno viene fatta passare la fase della rete elettrica e mediante il quale il controllore carichi effettua una stima della potenza dissipata attimo per attimo. I carichi gestibili dalla centralina sono 8, ad ognuno dei quali pu`o essere assegnata una priorit`a distinta.
96 Un caso reale: il progetto AlmaViva-CNR I messaggi inviati ciclicamente sul bus BTicino e notificati dal server in messaggi OPEN asincroni [3.4] mediante una sessione monitor [3.4.3] dal controllo carichi sono del tipo mostrato in figura 7.1.
Messaggio OPEN *3*1*#1## *3*1*#2## *3*1*#3## *3*1*#4## *3*1*#5## *3*1*#6## *3*1*#7## *3*1*#8##
Tabella 7.1: Messaggi OPEN inviati dalla centralina controllo carichi F421PL Come ampiamente spiegato nel paragrafo dei messaggi OPEN [3.4.2] un messaggio comando `e composto dai campi CHI, COSA e DOVE. Nel caso spe- cifico, il campo CHI=3 sta ad indicare un componente della gestione energia, e il campo DOVE=#1 con COSA=1, che il dispositivo con assegnata priorit`a 1 pu`o rimanere acceso (COSA=1). L’assegnazione delle priorit`a `e un po’ meno intuitiva, in quanto il dispositivo con priorit`a 1 `e in realt`a il dispositivo con la priorit`a pi`u bassa, quello che verr`a distaccato per primo nel caso ce ne fosse bisogno.
Appare chiaro che il sistema My Home BTicino gi`a da solo dispone di tutti i componenti necessari alla gestione energia, in quanto la centralina da sola non avrebbe nessuna utilit`a agli occhi di un acquirente e della stessa azienda BTicino, se non fosse corredata da tutti gli altri componenti necessari per il controllo dei carichi. La centralina difatti viene generalmente acquistata insieme ad un certo numero di attuatori BTicino del tipo F412.
Una soluzione di questo tipo per`o preclude una qualsivoglia interope- rabilit`a tra diversi componenti, in quanto tutti i componenti necessari al funzionamento del sistema sono della stessa casa produttrice. La filosofia di DomoNet `e quella di far s`ı che non ci si debba vincolare a un singolo pro- duttore o un singolo standard per poter automatizzare un ambiente, ma di favorire, nella scelta dei singoli prodotti, una indipendenza pari a quella che
7.7.2 Controllo carichi 97 un utente ha, per esempio, nel momento in cui vuole acquistare un lettore dvd per visualizzare i propri film.
Per dimostrare la fattibilit`a di questa filosofia, nell’ambito della simula- zione AlmaViva, sono stati scelti, come attuatori dei carichi da controllare, dei dispositivi Konnex della Siemens.
<device id="54" serialNumber="*3**#1##" description="Carico1" tech="BTICINO">
<service description="Setthestatus ON-OFF" name="SET_STATUS_ON_OFF" prettyName="Setstatus">
<input description="Thevalue" name="status" type="STRING">
<allowed value="1"/> <allowed value="0"/> </input>
<LinkedService id="42" url="" service="ComandoKonnex" ifInput="value" hasValue="1">
<linkedInput value="0" /> </LinkedService>
<LinkedService id="42" url="" service="ComandoKonnex" ifInput="value" hasValue="0">
<linkedInput value="1" /> </LinkedService>
</service> </device>
Figura 7.2: I LinkedService necessari per collegare la centralina BTicino con gli attuatori Konnex
Il sistema DomoNet ha reso possibile, in questo contesto, l’integrazione della centralina BTicinio con dispositivi Konnex attraverso l’uso dei Linked Service, che permettono l’abilitazione e la disabilitazione di attuatori Konnex mediante comandi provenienti dalla centralina BTicino.
In figura 7.2 `e mostrato il codice DomoML necessario a rendere effettiva l’associazione dei messaggi tra la centralina BTicino e gli attuatori Konnex.
98 Un caso reale: il progetto AlmaViva-CNR Come `e possibile vedere nella figura 7.2 sono necessari, per ogni attuato- re Konnex da controllare, due soli LinkedService che si trovano configuarati all’interno della descrizione astratta del dispositivo BTicino associato all’at- tuatore (con priorit`a 1 nel caso in figura) in quanto `e ovviamente il controllo carichi BTicino a generare l’azione. L’attributo hasValue `e necessario in quanto la semplice logica di abilitazione e disabilitazione del carico di un attuatore in Konnex `e esattamente l’opposta di quella BTicino. In Konnex infatti l’abilitazione di un carico avviene mediante il valore 0, mentre in BTicino mediante il valore 1.
A differenza di quanto evidenziato nel paragrafo che descrive il techMana- ger BTicino `e importante notare come, nell’ambito del progetto AlmaViva, sia stata possibile una virtualizzazione dei dispositivi.
Fino a questo momento, infatti, ogni dispositivo reale BTicino aveva una corrispondenza in DomoNet mediante l’astrazione del dispositivo BTicino in un domoDevice scritto in DomoML. Questo accade perch´e nella sottorete BTicino non `e possibile comandare dispositivi che abbiano un indirizzo non corrispondente a un dispositivo reale. Poich´e ogni comando inviato sulla rete BTicino deve passare necessariamente dal WebServer BTicino, quest’ultimo si comporta da ‘filtro’ e, oltre a far passare (ovviamente) solo messaggi OPEN sintatticamente corretti, si preoccupa anche di non inviare comandi che non abbiano un corrispettivo reale. Una conseguenza di quest’azione, `e l’impos- sibilit`a di vedere in una sessione monitor un messaggio inviato, per esempio, in una sessione comandi per controllare non un dispositivo reale BTicino, ma un device appartenente ad un’altra tecnologia corrispondente a un indirizzo BTicino fittizio, e comandato mediante uno strato software ulteriore come pu`o essere DomoNet.
Se fosse accaduto anche in questo caso, per controllare otto carichi elettri- ci (lavatrice, lavastoviglie, frigorifero ecc.) mediante un dispositivo comandi BTicino e degli attuatori Konnex, sarebbero stati necessari dei dispositivi di comando BTicino, un certo numero di attuatori BTicino e degli attuatori Konnex. Un fantomatico acquirente si sarebbe trovato nell’assurda situazione di dover acquistare una centralina BTicino, un determinato numero di at- tuatori Konnex (uno per ogni carico che si vuole controllare) e un medesimo numero di attuatori BTicino per controllare gli attuatori Konnex mediante
7.7.2 Controllo carichi 99 LinkedService.
In questo caso invece grazie al fatto che `e la stessa centralina del controllo carichi che genera ciclicamente i messaggi di abilitazione o disabilitazione degli attuatori BTicino, quest’ultimi sono in realt`a dei dispositivi virtuali che esistono solo all’interno del TechManager BTicino e che non hanno una corrispondenza reale.
Bench´e sia la centralina a generare i messaggi OPEN inviati sul bus SCS BTicino, al TechManager tutto questo risulta trasparente. Agli occhi di que- st’ultimo sono gli stessi attuatori BTicino (come gi`a detto, in realt`a dispo- sitivi virtuali ed esistenti solo per il TechManager) che notificano il proprio stato, stato che viene poi reso effettivo sugli attuatori reali Konnex mediante l’associazione dei servizi con i LinkedService.
In figura 7.3 `e mostrato una schematizzazione di quanto detto.
Figura 7.3: Virtualizzazione dei dispositivi BTicino
Attraverso i messaggi generati dalla centralina BTicino, ogni qualvolta si verifica il superamento del livello consentito per il consumo energetico, viene inviato ad un certo attuatore il comando di disabilitazione o abilita- zione del carico da cui consegue il distacco o il ripristino del corrispondente elettrodomestico.
Conclusioni
In questa tesi sono state realizzate delle estensioni per DomoNet, un fra- mework per l’interoperabilit`a di sistemi domotici di standard diversi. Alle funzionalit`a gi`a presenti in DomoNet `e stato aggiunto un modulo che per- mette di gestire dispositivi BTicino, nota azienda italiana leader sul mercato dei componenti elettronici per l’automazione domestica. In questo modo, i dispositivi BTicino, al pari di quelli Konnex e UPnp, possono adesso essere integrati nella rete DomoNet, che ne permette il controllo e la gestione.
Per facilitare tale gestione, e, in particolar modo, per facilitare all’utente la configurazione della propria rete domestica, `e stata realizzata un’interfaccia grafica che consente di collegare i vari dispositivi domotici in una sequenza di eventi (LinkedService) che verranno richiamati automaticamente al verificarsi di altri.
Il sistema `e stato oggetto di numerosi test sia durante lo sviluppo del software, sia durante il suo utilizzo nell’ambito del progetto Almaviva-CNR e si `e dimostrato stabile ed utilizzabile anche in simulazioni di situazioni reali. In assenza di accordi tra le grandi aziende, peraltro in parte raggiunti (vedi Konnex), ma poi puntualmente disattesi, l’approccio seguito nello svi- luppo di DomoNet sembrerebbe l’unico tra quelli percorribili che possa avere notevoli chance di successo. A dimostrazione di quanto detto, si possono ci- tare molti progetti nel mondo che seguono la stessa direzione di ricerca, e in particolare modo si pu`o considerare il caso Amigo, accennato nel paragra- fo 1.5, che seguendo le linee guida di un architettura per certi versi molto simile a quella di DomoNet, ha ricevuto dall’Unione Europea, un cospicuo finanziamento.
102 Conclusioni teplici. Da un lato occorrer`a andare nella direzione seguita in questo lavoro, sviluppando ulteriori TechManager che permettano l’integrazione di ulteriori tecnologie pi`u o meno affermate e lo sviluppo ulteriore del framework. Dal- l’altro sarebbe auspicabile che, come avviene purtroppo sempre pi`u spesso solo in altri paesi, DomoNet uscisse dal laboratorio e si avvicinasse al mon- do industriale, integrato in un piccolo server linux, come quello utilizzato nella tesi per l’interfacciamento con il sistema My Home, dotato di tutte le interfacce fisiche necessarie (per un gran numero di tecnologie basterebbe una porta Ethernet) per il collegamento fisico alla sottoreti per cui sia stato sviluppato un TechManager in DomoNet.
Appendice A
Esempi di tabelle dei COSA e
dei DOVE BTicino
In questa sezione verranno mostrate le tabelle di corrispondenza dei COSA e dei DOVE di OPEN Web Net in funzione dei CHI maggiormente utilizzati durante lo sviluppo e la fase di test del TechManager Bticino. In partico- lare vengono trattati il sistema Scenari, il sistema Comfort (Automazione e Illuminazione) e il sistema Multimedia.