Allione

POLITECNICO DI TORINO
III Facolt` di Ingegneria dellInformazione a

Corso di Laurea in Ingegneria Informatica
Tesi di Laurea Specialistica
Integrazione e Sperimentazione dello Standard EIB/KNX in Gateway Residenziali
Relatore: prof. Fulvio Corno Candidato: Enrico Allione
Luglio 2007
A chi, da quaggi` u e da lass`, u mi ha seguito ed aiutato
ii
Ringraziamenti
Un sincero ringraziamento ai miei genitori ed alla mia famiglia, che mi hanno permesso di intraprendere il cammino universitario e di arrivare no a qui. Ringrazio il prof. Corno ed il gruppo ELITE per avermi dato la possibilit` di a realizzare questa tesi, con un lavoro sia teorico che pratico; in particolare ringrazio ling. Bonino per avermi seguito ed assistito durante lintera realizzazione di questa tesi.
iii
Indice
Ringraziamenti 1 Introduzione 2 Stato dellarte 2.1 Domotica . . . . . . . . . . . . . . . . . . . . . . 2.2 Mezzi Trasmissivi . . . . . . . . . . . . . . . . . . 2.2.1 Cavo coassiale (CX) . . . . . . . . . . . . 2.2.2 Twisted pair (TP) o doppino in rame . . . 2.2.3 Fibra ottica (Optical Fiber - OF) . . . . . 2.2.4 Linea di potenza (Onde convogliate, Power 2.2.5 Wireless . . . . . . . . . . . . . . . . . . . 2.3 Dispositivi . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Dispositivi di input . . . . . . . . . . . . . 2.3.2 Dispositivi di output: attuatori . . . . . . 2.3.3 Dispositivi di sistema . . . . . . . . . . . . 2.3.4 Interfacciamento . . . . . . . . . . . . . . 2.4 Protocolli di comunicazione . . . . . . . . . . . . 2.4.1 Consumer Electronic Bus (CEBus) . . . . 2.4.2 Jini . . . . . . . . . . . . . . . . . . . . . . 2.4.3 LonWorks . . . . . . . . . . . . . . . . . . 2.4.4 X-10 . . . . . . . . . . . . . . . . . . . . . 2.4.5 Home Bus System (HBS) . . . . . . . . . . 2.4.6 BatiBUS . . . . . . . . . . . . . . . . . . . 2.4.7 European Home Systems (EHS) . . . . . . 2.4.8 European InstaBus (EIB) . . . . . . . . . 2.4.9 KONNEX . . . . . . . . . . . . . . . . . . iv 1 4 4 5 5 6 7 7 8 9 10 11 11 12 12 13 13 14 15 15 16 16 16 17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . line, PL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
3 Obiettivi e motivazioni 18 3.1 Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 iv
4 Architettura 4.1 Architettura . . . . . . . . . . . . 4.1.1 Interaction Manager . . . 4.1.2 Reti e dispositivi domotici 4.1.3 House Manager . . . . . . 5 Banco di lavoro EIB/KNX 5.1 EIB/KNX . . . . . . . . . . . . . 5.1.1 Gerarchia e suddivisione in 5.1.2 Indirizzi . . . . . . . . . . 5.1.3 Congurazione . . . . . . 5.2 Scelta componenti . . . . . . . . . 5.2.1 Materiale elettrico . . . . 5.2.2 Materiale domotico . . . . 5.3 Montaggio . . . . . . . . . . . . . 5.3.1 Sezione layout . . . . . . . 5.3.2 Sezione centralino . . . . . 5.3.3 Collegamenti . . . . . . . 6 House Manager 6.1 Architettura interna . . 6.1.1 Intelligence Layer 6.1.2 Startup . . . . . 6.1.3 Abstraction Layer
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
20 20 21 22 22 25 25 25 29 31 33 34 36 42 44 45 48 53 53 53 57 57 59 59 60 61 61 62 63 66 68 72 73 74 75
. . . linee . . . . . . . . . . . . . . . . . . . . . . . . . . .
. e . . . . . . . . .
. . . aree . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
7 SoluzioniAdottate 7.1 Driver . . . . . . . . . . . . . . . . . . 7.1.1 KnxDispatcher . . . . . . . . . 7.1.2 KnxWriter . . . . . . . . . . . . 7.1.3 KnxReader . . . . . . . . . . . 7.1.4 KnxEncoder . . . . . . . . . . . 7.1.5 Dierenze con BTicino . . . . . 7.2 Congurazione . . . . . . . . . . . . . 7.2.1 Gruppi . . . . . . . . . . . . . . 7.2.2 HouseModel . . . . . . . . . . . 7.3 Regole . . . . . . . . . . . . . . . . . . 7.3.1 Esempio base . . . . . . . . . . 7.3.2 Regole per comandi intervaligia v
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
8 Conclusioni 8.1 Risultati ottenuti . . . . . . . . . . . . . . . 8.1.1 Raggiungimento obiettivi . . . . . . . 8.1.2 Problemi riscontrati . . . . . . . . . 8.2 Conclusioni . . . . . . . . . . . . . . . . . . 8.2.1 Complessit` di EIB . . . . . . . . . . a 8.2.2 Costi della domotica . . . . . . . . . 8.2.3 Modiche ed implementazioni future Bibliograa
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
85 85 85 87 88 88 90 90 91
vi
Elenco delle tabelle

2.1 5.1 5.2 5.3 5.4 7.1 7.2 CENELEC: suddivisione frequenze . . . . Consumi apparati . . . . . . . . . . . . . . Caratteristiche valigia . . . . . . . . . . . Disposizione su guida DIN EN50022 - linea Disposizione su guida DIN EN50022 - linea Indirizzi sici dispositivi . . . . . . . . . . Elenco gruppi nellinstallazione EIB/KNX . . . . . . . . . . . . . . . sinistra destra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 39 44 47 47 67 70
vii
Elenco delle gure

2.1 2.2 2.3 2.4 4.1 4.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 Corrente alternata . . . . . . . . . . . Onda convogliata . . . . . . . . . . . . Risultante . . . . . . . . . . . . . . . . Pila protocollare ISO/OSI . . . . . . . Architettura generale . . . . . . . . . . House Manager - struttura . . . . . . . Topologia della rete EIB/KNX . . . . . Bus Coupling Unit - BCU . . . . . . . Architettura di comunicazione con bus Struttura indirizzo individuale . . . . . Struttura indirizzo di gruppo . . . . . . Eib Tool Software (ETS) . . . . . . . . Frutti e loro inserimento . . . . . . . . Gruppo prese . . . . . . . . . . . . . . Gruppo luci . . . . . . . . . . . . . . . Tasti tradizionali . . . . . . . . . . . . Interruttore dierenziale . . . . . . . . Interruttore magnetotermico . . . . . . Attuatore Abb . . . . . . . . . . . . . Attuatore Merten . . . . . . . . . . . . Gateway Abb . . . . . . . . . . . . . . Alimentatore Merten . . . . . . . . . . Tastiera Abb . . . . . . . . . . . . . . Tastiera Merten . . . . . . . . . . . . . Telecomando IR . . . . . . . . . . . . . Merten Interfaccia a tasti . . . . . . . . Valigia Manutan 1986Y57 . . . . . . . Sezione layout . . . . . . . . . . . . . . Sezione centralino . . . . . . . . . . . . Terminale di connessione bus . . . . . Topologia di rete in oggetto . . . . . . viii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 8 12 21 23 27 28 29 30 31 32 34 35 35 35 36 36 37 37 38 39 40 40 41 42 45 46 49 50 50
5.26 5.27 6.1 6.2 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8
Schema elettrico installazione . . . . . . . . . . . . . . . . . . . . Valigia EIB/KNX ultimata . . . . . . . . . . . . . . . . . . . . . . House Manager: schema a blocchi . . . . . . . . . . . . . . . . . . Esempio di corrispondenza tra oggetti software e device domotici . KnxDriver da inserire nellAbstraction Layer . . . . . . . . . . . . Driver BTicino e Knx . . . . . . . . . . . . . . . . . . . . . . . . . Struttura indirizzo di gruppo . . . . . . . . . . . . . . . . . . . . . Pseudo-codice per il concatenamento di main e middle . . . . . . Funzionamento BTicinoDispatcher . . . . . . . . . . . . . . . . . Funzionamento KnxDispatcher . . . . . . . . . . . . . . . . . . . . Corrispondenza oggetti software - device domotici (valigia Knx) . Schema loop con 3 luci . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
51 52 54 56 59 60 63 63 64 64 68 83
ix
Capitolo 1 Introduzione
La tesi mira a denire metodologie per integrare, nel contesto di gateway residenziali per edici intelligenti, diversi sottosistemi domotici tra loro eterogenei e potenzialmente incompatibili. Essa prevede lo studio dei dispositivi domotici esistenti e dei relativi protocolli di accesso, la denizione di opportune rappresentazioni e metodi di accesso astratti capaci di rappresentare in modo uniforme i vari dispositivi e limplementazione di un prototipo dimostrativo che integri pi` sottosistemi in un unico u ambiente di controllo. Verranno trattati alcuni standard ad-hoc, per poi soermarsi maggiormente su sistemi con protocollo OpenWebNet (BTicino) ed EIB/KNX, arontando la loro integrazione nellHouse Manager, gateway domestico in fase di sviluppo presso il Politecnico di Torino. Il dimostratore sar` composto da compoa nenti software e da un banco contenente dispositivi domotici. La tesi ` cos` strutturata: nel capitolo 2 viene introdotto il campo della domoe tica, con alcuni concetti e terminologie chiave al ne di delineare lambito in cui la tesi va a collocarsi. Viene inoltre proposta una panoramica sugli standard e sulle tecnologie domotiche attualmente presenti sul mercato mondiale, spiegando in particolare le alternative a disposizione nel caso si voglia progettare e/o installare una rete domotica. Termina con lintroduzione ad EIB/KNX, tecnologia scelta per il presente lavoro, la cui trattazione pi` esaustiva ` rimandata al capitolo successivo. u e Nel capitolo 3 vengono spiegate ed argomentate le motivazioni che hanno portato alla proposta ed alla realizzazione di questa tesi. Viene innanzitutto introdotto il ruolo dellHouse Manager, pur lasciando una sua trattazione completa al capitolo 4 ed in seguito viene spiegata la progettazione di un banco dimostrativo in grado di interagire col gateway in oggetto. Chiariti i requisiti, vengono presentati gli obiettivi che ci si pregge di raggiungere con questo lavoro.
1 Introduzione
Nel quarto capitolo viene presentata larchitettura logica in cui si inserisce lHouse Manager e, scendendo nellopportuno livello di dettaglio, il driver EIB/KNX necessario alla comunicazione con tale tecnologia. Nel capitolo 5 vengono spiegati i passi necessari alla costruzione del banco di lavoro, dalla scelta dei componenti no alla realizzazione sica. Una volta deniti il contesto ed i requisiti da soddisfare, vengono motivate le scelte in fatto di dispositivi e loro integrazione nel prototipo; essi vengono presentati nel dettaglio, mettendone in luce le caratteristiche sia positive che negative ed in seguito viene trattato il loro montaggio sico sia a livello elettrico che domotico. Il capitolo si conclude con la presentazione del prototipo ultimato, la cui congurazione logica viene presentata nel capitolo 7. Una volta chiariti gli obiettivi della tesi, nel capitolo 6 viene presentata larchitettura dellHouse Manager, soermandosi sui moduli di cui si compone, al ne di comprendere la sua funzione di collegamento tra dierenti tecnologie domotiche ed interfacce. Astraendo ad alto livello la rete domotica come insieme di oggetti software co-operanti tra loro, esso favorisce la comunicazione tra divese reti domotiche. Lintegrazione descritta consta di un modulo driver da inserire nel gateway che si occupi di tradurre il linguaggio astratto ad alto livello, utilizzato dallo stesso, in messaggi sulla rete domotica e viceversa. Viene inoltre presentato uno schema rappresentante i moduli base necessari allHouse Manager per comunicare con una rete domotica; tale schema viene aancato da una trattazione dellinterazione che i suddetti moduli devono avere sia tra loro, sia verso lesterno, permettendo la congurazione ed il comando da parte dellutente. Il capitolo 7 tratta linserimento del driver necessario per la comunicazione con la rete EIB/KNX; tale driver viene introdotto nellAbstraction Layer dellHouse Manager, ove ` gi` presente quello per la rete BTicino. In seguito vengono evidenziate le e a dierenze tra i due driver necessari alle due tecnologie, rimandando una discussione pi` esaustiva al capitolo 8. u Nel capitolo 7 viene inoltre presentata la congurazione necessaria al funzionamento logico della rete in oggetto, spiegando i collegamenti e le motivazioni che hanno portato alle scelte eettuate. Inoltre, nel medesimo capitolo, si dimostra come il motore a regole interno allHouse Manager possa essere utilizzato per garantire leettiva interoperabilit` tra le installazioni BTicino ed EIB/KNX. a Nellultimo capitolo (8) viene analizzato in maniera critica il lavoro svolto. In particolare ci si soerma sui risultati ottenuti una volta ultimato il prototipo, sulle dicolt` e/o ritardi di realizzazione e sulla precisione dello stesso nellattuaa re ci` per cui ` stato progettato. Viene proposta inoltre una riessione sulla tesi o e 2
1 Introduzione
portata a termine, valutando il lavoro fatto e proponendo eventuali modiche e/o implementazioni future.
Capitolo 2 Stato dellarte

In questo capitolo si presenta il campo della domotica, eettuando una panoramica sui concetti chiave, sui mezzi trasmissivi e dispositivi impiegati e sugli standard attualmente presenti sul mercato. Si conclude introducendo EIB/KNX quale standard utilizzato nel lavoro svolto.
2.1
Domotica
La domotica ` la disciplina che si occupa di studiare le tecnologie, atte a migliorare e la qualit` della vita degli esseri viventi, negli ambienti antropizzati.[1] a Il termine domotics (domotica in italiano) deriva dallunione di domus e informatics [2] e pone la sua attenzione particolare sullautomazione della casa (home automation), intesa come integrazione di tecnologie dellimpiantistica tradizionale, magari pre-esistenti, con tecnologie innovative e di nuova installazione, al ne di ottenere funzionalit` maggiori e moderne, mirando a migliorare la qualit` della vita a a degli utilizzatori delledicio, il comfort, la sicurezza ed il risparmio energetico. Tale integrazione ` da intendersi come condivisione dellinformazione tra i vari e impianti, permettendo quindi una riorganizzazione degli stessi in un unico sistema in grado di coordinare le diverse funzionalit`, permettendo da un lato lindipendenza a operativa dei vari impianti e dallaltro linteroperabilit` degli stessi. La presenza di a un sistema coordinatore fornisce funzionalit` aggiuntive e, in caso di guasto, doa vrebbe garantire che i vari sottosistemi continuino ad operare singolarmente, perdendo quindi solamente quelle funzionalit` aggiuntive rese possibili dallintegrazione a degli stessi. Tali funzionalit` aggiuntive possono essere potenzialmente molte e complesse: a se in un contesto di impianti isolati un dispositivo pu` comunicare solamente con o dispositivi del suo impianto o addirittura con un solo particolare dispositivo, in un contesto multifunzione si pu` avere un sensore piuttosto che un interruttore in grado o 4
2 Stato dellarte
di dialogare con apparati non prettamente rientranti nel suo ambito. Si pensi ad esempio ad un rilevatore di gas che non solo sia collegato con un avvisatore acustico ma che permetta anche lapertura della nestra per aerare il locale e linvio di un sms ad un numero telefonico prestabilito. Un concetto simile allhome automation ` quello di building automation, il quae le concerne lautomazione degli edici intesi di grosse dimensioni o comunque con un uso ben specico, si pensi ad esempio allambito residenziale (alberghi), socioassistenziale (ospedali, cliniche, scuole, uci), produttivo (fabbriche e industrie) o commerciale (centri commerciali). I due tipi di automazione sono nati in periodi diversi, per esigenze diverse e si rivolgono ad utilizzatori dierenti: mentre la building automation si rivolge prevalentemente ad operatori professionali, tecnici e gestisce funzionalit` piuttosto complesse, la home automation gestisce un ambiente a domestico e fornisce servizi a persone che, molto spesso, non sono solite utilizzare un personal computer e quindi deve disporre di interfacce utente semplici, facili da utilizzare senza una competenza tecnica specica.
2.2
Mezzi Trasmissivi
I mezzi trasmissivi utilizzati per collegare i vari dispositivi possono essere dierenti, non solo da installazione ad installazione, ma anche allinterno di una stessa installazione. La scelta ` fatta in base allestensione della rete, alla sua topologia, allanalisi e dellambiente in cui essa va ad inserirsi, alla distanza tra i dispositivi e allutilizzo che si intende eettuare dellinstallazione considerata o parte di essa.
2.2.1
Cavo coassiale (CX)
Il cavo coassiale ` formato da un conduttore in rame, rivestito da uno strato in e plastica che ne garantisce lisolamento con un ulteriore strato metallico intrecciato esterno il cui compito ` contenere i disturbi esterni (gabbia di Faraday1 [3]) e dimie nuire le interferenze. Il suo utilizzo tipico avviene nella trasmissione a distanza di dati digitali, pi` sensibili a rumori e distorsioni rispetto ai dati analogici. Il vincolo u dellutilizzo di questo tipo di cavo risiede nella contenuta distanza a cui possono trovarsi i dispositivi senza utilizzo di apparati di rete appositi che prendono il nome di repeater, il cui compito ` rigenerare il segnale ricevuto e ritrasmetterlo in uscita. e Essi non possono essere sostituiti banalmente con semplici amplicatori in quanto verrebbe non solo amplicato il segnale ma anche il rumore e la distorsione.
Con gabbia di Faraday si intende qualunque sistema costituito da un contenitore in materiale elettricamente conduttore (o conduttore cavo) in grado di isolare lambiente interno da un qualunque campo elettrostatico presente al suo esterno, per quanto intenso questo possa essere.
1
2 Stato dellarte
La resistenza allinterferenza presenta per` una bassa maneggevolezza dovuta o alla rigidit` del rivestimento in metallo, che lo rende poco pratico in ambienti ristretti a e connati e soggetto a rotture meccaniche; risulta inoltre costoso e dicile da realizzare. Il campo di applicazione solito ` la trasmissione di segnali video. e
2.2.2
Twisted pair (TP) o doppino in rame
Il twisted pair ` costituito da una coppia di li di rame ritorti secondo un processo e chiamato binatura che permette di far agire i campi elettromagnetici esterni in egual misura su entrambi i cavi. Utilizzando inoltre tecniche di trasmissione dierenziale si pu` ridurre il rumore, sfruttando il fatto che esso agisce su entrambi i cavi e viene o ad annullarsi nelloperazione di dierenza fatta dal ricevitore. Il twisted pair ` formato da 4 coppie di li colorati, ognuna avente una frequene za di binatura dierente per permettere di ridurre il fenomeno della diafonia2 . Il doppino pu` essere schermato (Shielded Twisted Pair [STP] ) oppure non schermato o (Unshielded Twisted Pair [UTP] ) e permette solamente collegamenti punto-punto, realizzando quindi una topologia a stella o ad anello. Esistono diverse categorie di cavo twisted pair, classicati secondo la velocit` di a trasmissione e luso. Di seguito ne viene presentata una panoramica. Categoria 1: telefonia analogica (POTS) - citofoni e reti a 1 Mbps Categoria 2: telefonia digitale (ISDN) - reti token ring a 4 Mbps Categoria 3: reti locali con frequenze no a 16 MHz Categoria 4: reti locali no a 10 Mbps Categoria 5: reti locali no a 100 Mbps Categoria 5e: reti locali no a 1 Gbps Categoria 6: reti locali no a 1 Gbps (qualit` migliore di Cat. 5e) a Categoria 7: reti no a 600-700 Mbps
Con diafonia si intende il fenomeno per cui vi ` un passaggio, in maniera capacitiva o induttiva, e di energia da una linea ad unaltra (pi` precisamente da un circuito ad un altro) [4] u
2
2 Stato dellarte
2.2.3
Fibra ottica (Optical Fiber - OF)
La bra ottica ` formata da un lamento di materiale vetroso in grado di condurre e la luce, rivestito da uno strato protettivo che lo isola dallesterno. La trasmissione avviene sfruttando i principi dellottica e consiste in un trasferimento di luce e non di segnali elettrici come nei casi visti in precedenza, eliminando quindi i disturbi dovuti allinterferenza elettrica. La bra ottica permette un collegamento ad alta velocit`, a distanze molto elevaa te ed ` impiegata maggiormente nelle dorsali di comunicazione. Il suo utilizzo nella e building automation pu` trovare motivazione nelle tratte dorsali, di collegamento ad o esempio tra pi` edici di un comprensorio, ma risulta eccessiva per connessioni in u ambito residenziale. La breve spiegazione ` fatta per completare la panoramica dei e mezzi trasmissivi.
2.2.4
Linea di potenza (Onde convogliate, Power line, PL)
Utilizzano i normali cavi delle rete elettrica (alternata 220 v - 50 Hz, Fig. 2.1) a cui si aggiunge un basso voltaggio modulato (3-148 KHz, Fig. 2.2) che non va ad inuire signicativamente sulla potenza distribuita Fig.2.3.
Figura 2.1.
Corrente alternata
Figura 2.2.
Onda convogliata
Alimentazione e dati viaggiano sullo stesso mezzo, la rete elettrica appunto, quindi occorre operare anch questi possano essere opportunamente separati in e fase di ricezione. Questo mezzo trasmissivo permette di raggiungere, ovviamente, qualunque dispositivo che sia collegato alla rete elettrica, oltre ad evitare la posa di una nuova infrastruttura. La regolamentazione delle frequenze utilizzate ` adata per lEuropa al Comitato e Europeo per la Standardizzazione Elettrica (CENELEC) [5] e per il nord America 7
2 Stato dellarte
Figura 2.3.
Risultante
al Federal Communications Commission (FCC) [6]. Il CENELEC ha stabilito regole di suddivisione delle frequenze, riportate in Tabella 2.1 FREQUENZE ACCESSO 3 - 95 KHz Riservato 95 - 125 KHz Libero 125 - 140 KHz RegolamentatoCELENEC 140 - 148,5 KHz Riservato
Tabella 2.1.
UTILIZZO Fornitori energia elettrica Sistemi domotici Sistemi domotici Allarmi e Sicurezza
CENELEC: suddivisione frequenze
Le velocit` raggiungibili in Europa sono nellordine di alcuni Kbps (no a circa a 5,4 Kbps) da rispettare per lo standard, anche se velocit` superiori sono tecnicaa mente raggiungibili ma non necessarie (trasmissione audio/video esclusa).
2.2.5
Wireless
La tecnologia di trasmissione senza li (dallinglese wireless) si suddivide principalmente tra infrarosso e radiofrequenza a seconda della banda di frequenza impiegata. Limportante caratteristica ` data dallassenza di li, che permette una maggioe re mobilit` dei dispositivi, dei suoi utilizzatori ed una maggiore comodit` duso. a a Inoltre, nel caso in cui non si possano posare cavi, risulta essere di fondamentale utilit`. Tra gli svantaggi occorre annoverare sicuramente linterferenza di trasmisa sione, la dicolt` nel superare barriere siche e strutturali e la distanza limitata tra a i dispositivi. Raggi Infrarossi (IR - Infrared Rays) Utilizza linfrarosso (lunghezza donda maggiore della luce visibile e minore delle onde radio) e necessita di un campo aperto e privo di ostacoli non trasparenti tra trasmettitore e ricevitore. Trova impiego nella termograa ma anche nella comunicazione, ad esempio tra telecomando e TV per evitare le interferenze delle onde radio del segnale televisivo. La radiazione infrarossa viene emessa da diodi (detti anche LED luminosi) e messa a fuoco da lenti in plastica; 8
2 Stato dellarte
in seguito viene modulata assegnandole informazione ed inviata. Il ricevitore traduce con un fotodiodo la radiazione infrarossa in corrente elettrica e da qui viene estratta linformazione originale. Standardizzato da IrDA (Infrared Digital Association, 1994) [7] per comunicazioni punto-punto entro il metro e velocit` no a 4 Mbps. a Radiofrequenza (RF - Radio Frequency) La radiofrequenza utilizza onde radio per la trasmissione e ricezione dei segnali la cui lunghezza donda supera quella dellinfrarosso. La porzione dello spettro elettromagnetico ` ampia e a seconda del e campo di applicazione, esso si pu` suddividere in fasce. La radiofrequenza ` utilizo e zata in campi di uso comune quali radio e TV, ma in particolare per gli usi che se ne possono fare in campo domotico risultano importanti le frequenze dai 300 Hz ai 30 GHz. Una tecnologia diventata famosa e di uso sempre pi` frequente al giorno u doggi ` il Bluetooth. e Il Bluetooth ` stato standardizzato dallomonimo consorzio [8] nato nel 1988 e dalla cooperazione tra grandi societ` operanti nel campo della telefonia3 . Esso pera mette tramite collegamento radio a 2.4 GHz la comunicazione ad un massimo di 1 Mbps tra dispositivi nel raggio di alcune decine di metri4 . I dispositivi compatibili Bluetooth superano una fase di test da parte del consorzio ottenendo il marchio di certicazione e quindi sono per denizione interoperabili tra loro. Un esempio di collegamento Bluetooth pu` essere quello tra cellulare e PC o tra cellulare ed auricoo lare. Per permettere sicurezza del canale, il Bluetooth utilizza lo FHSS (Frequency Hopping Spread Spectrum)5 la cui sequenza di salti ` conosciuta solo ai dispositivi e appartenenti alla comunicazione in oggetto, rendendo quindi ardua lintrusione di apparecchiature estranee.
2.3
Dispositivi
La rete domotica ` solitamente strutturata a bus e comprende due tipi di linee, una e di potenza che alimenta i vari dispositivi presenti e una di controllo/comando che gestisce gli apparati permettendo loro la comunicazione. Mentre la linea di potenza ` e costituita dai classici tre cavi (fase, neutro e terra), la linea bus pu` essere realizzata o utilizzando vari mezzi trasmissivi descritti in precedenza sia nella totalit` della rete, a sia in partizioni di essa. In questultimo caso si rende opportuno limpiego di gateway o dispositivi che si occupino di operare il collegamento e la comunicazione tra reti non omogenee.
IBM, Toshiba, Intel, Nokia, Ericsson Maggiori distanze signicano antenne + potenti (no a 20 dB) e pi` probabilit` di interferenza u a con le reti 802.11b 5 Tecnica che prevede limpiego di sequenze di frequenze tra le quali saltare
4 3
2 Stato dellarte
Esistono dierenti tipi di device, suddivisibili in dispositivi di: input: sensori, pulsanti, interruttori; output: attuatori; di sistema: accoppiatori, gateway, alimentatori; interfacce: interfacce USB, Ethernet, RS232, ... Alcune tipologie di rete pi` complesse (ad esempio EIB/KNX), introducono u unulteriore dispositivo tra il bus e il dispositivo vero e proprio, con il compito di accoppiare questultimo al bus (sezione 5.1.1).
2.3.1
Dispositivi di input
Tra i dispositivi di input, importanti sono i sensori, che hanno il compito di rilevare o misurare grandezze dellambiente esterno e segnalare eventuali variazioni per le quali sono stati impostati. Generalmente hanno due soglie, una inferiore ed una superiore e possono essere settati per avvisare in caso di superamento di anche solo una delle due. Lavviso consiste in una segnalazione alla rete, la quale provveder` a ad avviare le opportune procedure richieste, oppure nellinvio di un comando ad un particolare dispositivo precedentemente settato. I sensori possono essere usati in ambiti diversi e per motivazioni dierenti: si pensi ad un sensore che rilevi la quantit` di gas presente in un ambiente (cucina), a ad uno che rilevi la velocit` del vento e ad uno che rilevi i movimenti. Uno stesso a sensore pu` avere non necessariamente un unico utilizzo. Il sensore che rileva il o movimento pu` essere usato per accendere una luce al passaggio di una persona ed o agevolare cos` il suo cammino evitando che questa debba azionare un interruttore manuale, ma pu` anche azionare un allarme nel caso in cui il suo compito sia quello o di rilevare delle presenze ostili e non previste in un determinato ambiente. I sensori possono essere inseriti direttamente sulla rete oppure essere collegati ad una centralina (allarmi, meteo, ...), la quale provveder`, al ricevimento della sea gnalazione, ad avviare le opportune procedure ed azionare eventuali altri dispositivi (sirene, motori, luci, ...), oppure semplicemente ad immagazzinare i dati rilevati per analisi ed usi futuri. In questa categoria ricadono anche gli interruttori ed i pulsanti comunemente usati nelle abitazioni e collegati con la rete domotica tramite opportune interfacce. La dierenza tra interruttori e pulsanti risiede nello stato che possono assumere: mentre i primi possono avere due stati (generalmente ON e OFF), i pulsanti hanno uno stato solo. La pressione di questi determina, previa congurazione pi` o u meno complessa a seconda delle reti, una variazione dello stato dei dispositivi a 10
2 Stato dellarte
cui essi sono stati legati in fase di congurazione. La segnalazione su rete avviene dapprima allattuatore ed in seguito al carico, in quanto questultimo verr` pilotato a dallattuatore a cui ` collegato. e
2.3.2
Dispositivi di output: attuatori
Gli attuatori hanno il compito di realizzare (attuare) un comando. Ricevono i comandi dalla rete e provvedono ad eettuarli sulle uscite corrette a cui sono collegati i carichi elettrici. A seconda del tipo di uscita lattuatore si comporta in modo dierente: binaria: luscita viene attivata e disattivata tramite rel` o circuito equivalente; e dimmer: tramite un regolatore elettronico regola la tensione o la corrente per pilotare il carico; analogica: fornisce corrente o tensione variabile per comandare uscite non intelligenti. Inoltre gli attuatori si dierenziano ancora a seconda del numero e tipologia di carichi collegabili (induttivi, resistivi, ...), del massimo carico collegabile e della forma (montabile a incasso o su modulo DIN EN500226 ).
2.3.3
Dispositivi di sistema
In questa categoria rientrano dispositivi necessari per la realizzazione, il controllo e la gestione della rete. Alcuni dispositivi, quali ad esempio lalimentatore, sono necessari e senza di essi qualunque sistema non sarebbe operativo, mentre altri diventano necessari solo in talune reti o tipologie. Lalimentatore fornisce energia elettrica ai dispositivi connessi al bus; tali dispositivi solitamente operano con tensioni variabili dai 12 V ai 30 V. Esso ` posizionato e normalmente dentro il quadro generale e pu` essere utilizzato singolo o con altri o alimentatori a seconda di quanti ne vengano richiesti dalle speciche del sistema. Generalmente due fattori che inuenzano il numero di alimentatori utilizzati sono la quantit` di dispositivi impiegati sulla rete e la massima distanza tollerata degli a stessi dallalimentatore. Altri dispositivi utili soprattutto in reti di dimensioni considerevoli sono i dispositivi di accoppiamento del bus, il cui scopo ` ampliare la porzione di rete, collee gando due sottoreti eventualmente con mezzi trasmissivi diversi. Si pu` parlare di o ripetitori, accoppiatori, gateway o utilizzare nomenclature pi` speciche. u
Deutsches Institut fr Normung e.V. - German Institute for Standardization: standard tedesco, u ora mondiale, per il montaggio di apparecchi elettrici sullomonima apposita guida.
6
11
2 Stato dellarte
2.3.4
Interfacciamento
Compito di questi dispositivi ` permettere il dialogo tra la rete e lesterno, ad esempio e un personal computer. Tali interfacce da una parte operano il collegamento sul bus e dallaltra orono una porta USB, RS232 oppure una presa di rete a cui collegare il pc. Tramite opportuni pacchetti software ` possibile visualizzare la rete domotica e ed operare su di essa.
2.4
Protocolli di comunicazione
Nella presentazione della domotica una parte rilevante ` costituita dal protocollo di e comunicazione tra i vari dispositivi. Questo caratterizza una determinata installazione e pu` essere molto dierente da altri protocolli presenti in altre realt`. Molti o a di questi seguono un modello ISO/OSI (Fig. 2.4), con la relativa suddivisione in 7 livelli.
Figura 2.4.
Pila protocollare ISO/OSI
La potenzialit` dellutilizzo di tale modello ` la possibilit` di permettere unina e a terconnessione tra livelli omogenei presenti in dispositivi di reti dierenti. Tale comunicazione pu` essere eettuata grazie ad apparati particolari, detti generalo mente gateway, il cui compito ` quello di realizzare un ponte tra due installazioni e dierenti ma comunque simili. Data la complessit` del modello ISO/OSI si assiste a solitamente ad una non-implementazione dei livelli dal 3 al 6, ed inglobazione degli stessi nei livelli adiacenti (2 e 7), permettendo una minore complessit` ed un minor a costo di implementazione. 12
2 Stato dellarte
I primi standard nacquero quando organizzazioni operanti sul mercato domotico cercarono di creare uno standard unico al ne di favorirne la crescita e lo sviluppo. Dato che a tale processo non ader` la totalit` delle aziende, non ebbe il successo a desiderato e si assistette al proliferare di dierenti standard. Con il passare degli anni sono stati eettuati ulteriori tentativi, ma a tuttoggi non esiste ancora uno standard unico e globale, sebbene vi siano associazioni nate con lo scopo di creare a livello locale quellunicazione che non si ` riusciti a creare e a livello mondiale. Considerando le tre principali aree geograche mondiali (America del Nord, Europa e Giappone) viene presentata una suddivisione dei vari standard e dei tentativi di standardizzazione locale degli stessi. America del Nord: CEBus, Jini, LonTalk, X-10 Giappone: HBS Europa: BatiBUS, EHS, EIB, KONNEX
2.4.1
Consumer Electronic Bus (CEBus)
CEBus [10] ` anche noto come EIA-600 ed ` stato sviluppato dallamericana EIA e e (Electronic Industries Alliance)7 [9] nel 1992, in seguito ad un lavoro di sei anni per cercare di migliorare e ampliare le capacit` dellallora standard de facto Xa 10 (sezione 2.4.4). CEBus ` uno standard integrato multimediale per i sistemi e di automazione domestica, presenta caratteristiche quali essibilit` e modularit`, a a ma non risulta molto diuso. I dispositivi che lo utilizzano devono possedere una potenza di elaborazione non minimale per gestire tutti i dati in transito sulla rete. Inizialmente supportava solamente linee di potenza, mentre in seguito ` stato e permesso lutilizzo di cavi coassiali, raggi infrarossi, frequenze radio e bre ottiche.
2.4.2
Jini
Jini technology is a service oriented architecture that denes a programming model which both exploits and extends Java technology to enable the construction of secure, distributed systems consisting of federations of well-behaved network services and clients. [11] Prodotto dallamericana Sun [14], prende il suo nome dallarabo jini il cui signicato ` mago, per evidenziare la sua capacit` di autocongurazione. Ogni dispositivo e a connesso alla presa di rete viene inserito in un registro contenente tutti gli apparati
7
Fino al 1997 nota come Electronic Industries Association
13
2 Stato dellarte
presenti, permettendo che ogni device riesca a venire a conoscenza di qualunque altro device presente nella rete. Jini ` basato sul concetto di servizio: ogni apparato fornisce servizi al resto della e rete (o comunit`) tramite una propria interfaccia attraverso cui ` possibile accertarne a e ladabilit` e la compatibilit` con altri servizi. A sua volta ogni dispositivo pu` a a o utilizzare i servizi messi a disposizione da altri apparati, andando cos` a formare una rete articolata dalle funzionalit` complesse. a Quando si rende necessario comunicare con un dispositivo, tramite un servizio di ricerca viene individuato il destinatario e da esso il richiedente scaricher` il codice a Java necessario per la comunicazione. Punto fondamentale di tutto ci` ` lestensione oe al modello di sicurezza di Java che permette lesecuzione sicura di codice scaricato dalla rete. Il modello originale di sicurezza Java ` basato sulla localit`, per cui ogni applet e a scaricata pu` accedere solamente ai servizi messi a disposizione dal dispositivo da o cui essa ` stata scaricata. Ogni servizio inoltre gestisce una lista di controllo che ne e specica gli utilizzatori. Lutilizzo del servizio ` eettuato tramite il meccanismo e detto leasing, che rappresenta una concessione a tempo sulluso del servizio. Esistono due tipi di leasing, quello esclusivo, che permette ad un unico componente di utilizzare il servizio e quello condiviso, che permette ad una lista di fruitori di accedervi ed utilizzarlo.
2.4.3
LonWorks
LonWorks [12] ` un tipo di rete creato nel 1988 dalla Echelon Corporation [13]. E e stato studiato per lautomazione industriale, di grandi complessi e di aerei. Ha costi relativamente alti, anche se il principale fornitore di energia elettrica in Italia ha installato milioni di contatori elettrici compatibili con questo standard. Il protocollo che utilizza prende il nome di LonTalk8 e si basa sullintelligenza distribuita e su una rete aperta, in cui ogni applicazione pu` interagire con unaltra o senza bisogno di un controllo o di una intermediazione gerarchica. I protocolli non sono proprietari e i prodotti che li utilizzano, dopo aver superato una fase di test, possono utilizzare il logo LonWorks. La Echelon Corporation ha ideato il Neuron Chip (costruito da Toshiba, Cypress e Motorola) che implementa tali protocolli ed il sistema si completa con Lonworks Network Service (LNS), il sistema operativo per la connessione e lo sviluppo della rete dei dispositivi di controllo, permettendo linstallazione, la congurazione ed il monitoraggio della rete di controllo LonWorks. Il server LNS supporta a livello di trasporto sia il protocollo LonTalk che TCP/IP.
8
Denito nello standard ANSI/EIA 701.9-A-1999
14
2 Stato dellarte
2.4.4
X-10
X-10 [15] ` nato nel 1976 con comunicazione monodirezionale da dispositivi di coe mando ad attuatori e solamente due anni pi` tardi viene aggiornato (X-10-Pro) u permettendo anche la lettura dello stato di un dispositivo e rendendo bidirezionale la comunicazione. Il mezzo sico di trasmissione utilizzato ` costituito dalle onde convogliate sulla e rete elettrica tradizionale e la velocit` di trasmissione ` molto bassa. Negli USA ove a e ` nato utilizza la rete elettrica 120 volt a 60 Hz, mentre in Europa quella 220 volt a e 50 Hz. Ogni apparato viene identicato da una lettera (A-P) e da un numero (1-16) e quindi permette di collegare no a 256 dispositivi o gruppi di dispositivi. Il trasmettitore ` una unit` centrale che invia comandi a dispositivi periferici, ma il sistema e a pu` essere controllato e comandato da telecomandi ad infrarossi o computer. o Principalmente diuso negli Stati Uniti, ha trovato anche un suo utilizzo in Europa e, grazie alla presenza di numerosi dispositivi disponibili sul mercato, a basso costo e alla semplicit` di installazione, ha una posizione di rilievo tra gli a standard attualmente usati.
2.4.5
Home Bus System (HBS)
HBS ` frutto di un progetto congiunto di tre diversi soggetti giapponesi: Ministry of e International Trade & Industry (MITI) [16], Radio Engeneering & Electronics Association (REEA) [17] e Electronic Industries Association of Japan (EIAJ) [18]. Oltre a questi colossi, al progetto hanno partecipato anche alcune tra le maggiori compagnie giapponesi del settore, fornendo un enorme apporto di capitali di investimento. Standardizzato nel 1986 dopo cinque anni di ricerca, ha subito unulteriore innovazione quando un anno pi` tardi ` stato proposto Super-HBS, per allargare luso u e di HBS ad unutenza condominiale. Per renderlo accessibile dallesterno inoltre ` e stato sviluppato nel 1997 un gateway HBS/ISDN. Utilizza due cavi coassiali e otto cavi twisted pair e permette il collegamento di apparati audio, video e telefonici. Risulta lunico standard de facto presente in Giappone grazie anche alle modalit` a di creazione adottate e la successiva ricerca e sviluppo nel campo degli elettrodomestici di nuova generazione con un basso consumo energetico [19]. Occorre precisare che in Giappone il processo di standardizzazione segue un iter dierente da quello europeo: prima viene proposto uno standard alla cui creazione partecipa una pluralit` di soggetti e solo successivamente viene avviata la produzione a di apparati che rispettino tale standard. In Europa invece il processo risulta spesso invertito: prima avviene la produzione dei 15
2 Stato dellarte
dispositivi e solo dopo si cerca di armonizzare lo status quo creando uno standard per permettere la comunicazione tra di essi. La realt` dei fatti dimostra come in a Giappone sia molto pi` facile, per uno standard, essere lunico adottato, al contrario u dellEuropa dove un eventuale standard deve scontrarsi con le quote di mercato gi` a consolidate da protocolli proprietari.
2.4.6
BatiBUS
Lo standard Batibus [20] ` stato il primo bus sul mercato europeo; nato in Francia e ad opera della Schneider ` stato sviluppato nel 1989 su iniziativa di MERLIN GEe RIN, AIRELEC, EDF e LANDIS & GYR, utilizza un doppino come mezzo sico e permette una topologia libera. Ogni pacchetto di comunicazione ` composto da un numero sso di byte rappree sentanti il tipo di apparato da gestire, il controllo dellerrore, lindirizzo e un numero variabile di byte di dati, contenente istruzioni e comandi per la gestione della rete. La velocit` di trasmissione ` di 4800 baud. a e Successivamente alla sua creazione ` stato fondato nel 1990 il Batibus Club Ine ternational con lo scopo di promuovere le applicazioni dello standard BatiBus. Tale associazione ha partecipato insieme ad EIBA ed EHSA al processo detto Convergenza che ha portato nel maggio 1999 alla fusione delle tre associazioni ed alla nascita di una nuova associazione (KONNEX) [23] che ha dato il nome allomonimo standard.
2.4.7
European Home Systems (EHS)
EHS ` stato creato nel 1992 dalla EHSA (European Home System Association) e [21] con il compito di promuovere uno standard aperto basato sui 7 livelli ISO/OSI per permettere la comunicazione tra milioni di dispositivi, riuniti in gruppi di 256 elementi. Prevede la funzionalit` Plug&Play, permette autocongurazione della rete, esa sibilit` di posizionamento ed alta adabilit` dovuta ad un ecace metodo per il a a controllo e la correzione di errori. Prevede bus su quasi tutti i mezzi di trasmissione ed ` uno standard aperto per il quale esiste la certicazione dei prodotti. e EHSA ha partecipato insieme a BatiBus ed EIBA al processo detto Convergenza che ha portato nel maggio 1999 alla fusione dei tre ed alla nascita di una nuova associazione (KONNEX) [23] che ha dato il nome allomonimo standard.
2.4.8
European InstaBus (EIB)
EIB ` stato creato ad opera della EIBA (European InstaBus Association) [22] e e prevede un sistema decentralizzato suddiviso gerarchicamente in aree e linee. Per 16
2 Stato dellarte
collegare insieme pi` linee vengono usati apparecchi di rete che prendono il nome u di accoppiatori di linea (o Line Coupler ), mentre per accoppiare pi` aree vengono u impiegati gli accoppiatori di area (o Area Coupler ). Su ciascuna linea possono essere inseriti no a 64 dispositivi, mentre no a 15 linee possono entrare a far parte di unarea. Nel caso in cui le linee in questione siano no a 12, esse potranno comunicare tra loro senza la necessit` di creare unarea. In una installazione EIB ` a e quindi possibile inserire no a 11.520 dispositivi. EIB supporta qualunque topologia di rete, anche unioni di topologie diverse, fatta eccezione per lanello ma presenta alcuni limiti in fatto di distanze da rispettare tra alimentatore e dispositivo (max 350 m), tra due dispositivi (max 700 m) e tra due alimentatori (min 200 m). EIBA ha partecipato insieme a BatiBus ed EHSA al processo detto Convergenza che ha portato nel maggio 1999 alla fusione delle tre associazioni ed alla nascita di una nuova associazione (KONNEX) [23] che ha dato il nome allomonimo standard.
2.4.9
KONNEX
Questo nuovo standard ` stato il risultato del processo detto Convergenza ad e opera di Batibus, EIBA e EHSA ed ` anche noto con lacronimo EIB/KNX. Lassoe ciazione creata, Konnex [23], trova il suo scopo nel creare uno standard europeo per la home e building automation. EIB/KNX si basa sulle caratteristiche migliori dei tre protocolli da cui deriva, anche se in realt` risulta essere uninnovazione di EIB a (paragrafo 2.4.8) con cui mantiene una compatibilit` totale. Produttori dierenti a costruiscono i dispositivi e li sottopongono allapprovazione del consorzio, il quale dopo una fase di testing di rispetto delle speciche pone il marchio Konnex, garantendo quindi la loro compatibilit` con qualunque altro dispositivo certicato. I a mezzi sici principalmente utilizzati sono twisted pair e powerline, anche se esistono dispositivi utilizzanti InfraRed e radiofrequenze. Permette una topologia a scelta, anche mista. Mantiene una compatibilit` totale con EIB, da cui deriva e da esso a ha preso la suddivisone gerarchica in aree, linee e device, innalzando per` a 16 i o bit di indirizzamento, permettendo quindi un impiego di 65.536 dispositivi in una istallazione EIB/KNX. Il protocollo di comunicazione si basa sullo stack ISO/OSI, con un accorpamento di alcuni livelli. Una trattazione pi` esaustiva viene proposta u allinizio del capitolo 5.
17
Capitolo 3 Obiettivi e motivazioni

In questo capitolo vengono spiegate le motivazioni alla base della tesi, presentando il contesto in cui questa va ad inserirsi e quali sono gli obiettivi ssati.
3.1
Contesto
Nel contesto dellautomazione degli ambiente domestici, il gruppo di ricerca elite del Politecnico di Torino ha realizzato un progetto denominato Domotic House Gateway [24], il cui scopo ` collegare tramite un gateway, che prende il nome di House e Manager, dierenti reti domotiche che utilizzano una variet` di protocolli di comua nicazione di basso livello. LHouse Manager permette uninterazione omogenea con i vari dispositivi e fornisce una interoperabilit` tra gli stessi che risulta attualmente a impossibile viste le dierenti tecnologie presenti sul mercato (presentati nella sezione 2.4). Una trattazione pi` approfondita del contesto in cui la tesi va ad inserirsi ` u e rimandata al capitolo 4 Nel caso particolare arontato in questa tesi, si ` deciso di estendere loperativit` e a dellHouse Manager alla rete EIB/KNX, a cui verr` collegato tramite LAN ed un a apposito apparato domotico noto come gateway. Lobiettivo ` quello di integrare la e soluzione House Manager, gi` disponibile ed in grado di operare con la rete MyHome a BTicino [25], con il supporto a reti EIB/KNX. Ci` consentir` di dimostrare lecacia o a dellapproccio allinteroperabilit` tra sistemi domotici diversi, anche con speciche a prove sperimentali come illustrato nel capitolo 8. Lintegrazione di reti EIB/KNX allinterno del set gestibile dallHouse Manager richiede la progettazione e lo sviluppo di un driver apposito per la rete EIB/KNX e la realizzazione di un prototipo che consenta di vericare sperimentalmente la tesi proposta. La scelta di EIB/KNX come protocollo di comunicazione ` stata fatta in quanto e questo risulta essere il protocollo maggiormente diuso a livello europeo e mira ad 18
3 Obiettivi e motivazioni
essere uno standard in tale continente. EIB/KNX ` stato introdotto nella sezione e 2.4.9 e verr` arontato in maniera pi` approfondita nel capitolo successivo a questo. a u
3.2
Prototipo
Al ne di dimostrare la tesi non solamente dal punto di vista architetturale e funzionale ma anche praticamente, si intende realizzare un banco dimostrativo, contenente dispositivi domotici EIB/KNX, i quali devono essere comandabili tramite House Manager, oltre che ovviamente da un ipotetico utilizzatore. Mirando alla dimostrazione della tesi il banco viene attrezzato con elementi base quali luci, prese ed attuatori, sebbene la vastit` di dispositivi possibili sia di gran lunga maggiore; per semplicit` a a realizzativa si pensa inoltre di non inserire dispositivi complessi quali ad esempio telecamere, sensori meteorologici o anti-intrusione, pur non escludendone una futura introduzione. Requisito fondamentale del progetto ` che lHouse Manager sia in grado di ine teragire con dispositivi presenti nel banco di lavoro EIB/KNX, attuando i comandi richiesti. Inoltre, dovranno essere presenti collegamenti e tecniche opportune al ne di comandare laccensione e spegnimento di utenze intervaligia; dovr` cio` esa e sere possibile sia pilotare luci BTicino tramite pulsanti EIB/KNX, sia luci e prese EIB/KNX tramite pulsanti BTicino. LHouse Manager dovr` conservare intatta la sua architettura, eccezion fatta a per i moduli aggiuntivi necessari alla comunicazione con la nuova rete. Esso dovr` a quindi continuare ad operare a livello astratto sui device presenti nellinstallazione globale e non dovr` rendersi necessaria la distinzione secondo il protocollo utilizzato a a basso livello. Lutilizzo dellinstallazione da parte utente tramite House Manager non dovr` a interferire con luso consueto delle utenze elettriche attraverso i relativi dispositivi di comando.
19
Capitolo 4 Architettura
In questo capitolo viene presentata larchitettura dellHouse Manager, soermandosi sui moduli in esso contenuti, al ne di comprendere la sua funzione di collegamento tra dierenti tecnologie domotiche ed interfacce. In particolare esso risulta gi` a testato su rete BTicino, utilizzante il protocollo SCS, ma la sua architettura non ` e specica per tale tecnologia; astraendo ad alto livello la rete domotica come insieme di oggetti software operanti tra loro, potenzialmente favorisce la comunicazione con qualunque altra rete domotica, a patto che lHouse Manager riesca ad interagire con essa. Tale collegamento viene operato tramite appositi moduli driver da inserire nel gateway che si occupino di tradurre il linguaggio astratto ad alto livello da esso adottato in messaggi sulla rete domotica e viceversa.
4.1
Architettura
Quando un ambiente come una casa viene dotato di intelligenza operativa, attraverso opportuni device e meccanismi, un utente pu` usare e comandare tale ambiente o tramite appositi tasti o bottoni opportunamente congurati e facenti parte dellinstallazione. Naturalmente il fatto stesso che lambiente sia intelligente fa si che a queste interfacce pi` tradizionali si possano aancare interfacce pi` evolute basate ad esempio u u sul tracciamento oculare, sul riconoscimento di gesti, ecc. Data la variet` di intera facce che si possono immaginare e dato che il loro utilizzo ` frequentemente mediato e da dispositivi con potenza elaborativa limitata, ` necessario operare una separazione e tra la presentazione allutente (Interface Layer ) e lelaborazione che la gestione della casa implica (Application Logic). Questultima richiede capacit` e potenza di calcolo non indierenti e quindi deve a essere eseguita da un sistema pi` potente/adatto, quale ad esempio un PC o un u Home Gateway. Date queste considerazioni larchitettura che ne consegue (Fig. 20
4 Architettura
4.1) presenta principalmente 3 entit`: lInteraction Manager, lHouse Manager e la a casa.
Figura 4.1.
Architettura generale
I primi due elementi si occupano rispettivamente della generazione delle interfacce e della gestione dellApplication Logic (Interaction Manager) e dellinterazione con la casa (House Manager). Viene ora presentata una breve trattazione di questi, per quanto di interesse ai ni del lavoro di tesi.
4.1.1
Interaction Manager
LInteraction Manager gestisce le varie interfacce grache agendo come un proxy e permettendo laccesso e la gestione degli apparati domotici tramite House Manager. Esso comunica da una parte con lHouse Manager, tramite un opportuno protocollo (House Manager Protocol - HMP) e dallaltra con le varie interfacce a cui risulta collegato. Tali interfacce necessitano di essere molto semplici, dovendo essere gestibili da dispositivi solitamente poco potenti e lavorano quindi su insiemi semplicati di elementi 21
4 Architettura
(pagine), in cui vengono raggruppati e collocati i dispositivi e le funzioni controllabili. LInteraction Manager si occupa di aggiornare le interfacce secondo le variazioni di stato che la rete domotica subisce e di raccogliere le azioni dellutente per poterle elaborare ed attuare tramite House Manager.
4.1.2
Reti e dispositivi domotici
In tale gruppo ricadono le reti domotiche ma anche i semplici dispositivi non connessi alle reti stesse ma in possesso di una interfaccia di comunicazione (Ethernet, WiFi, Bluetooth, RS232, ...). Le reti domotiche che possono essere impiegate sono numerose: oltre che essere prodotte da costruttori dierenti, esse possono contenere dispositivi eterogenei, distribuiti e posizionati nellambiente domestico e connessi tra loro tramite un opportuno canale di collegamento che prende il nome di bus. I dispositivi scambiano tra loro informazioni e comandi utilizzando il bus ed opportuni protocolli specici per ogni singola tecnologia (BTicino, EIB/KNX, X10, ...) e non sono direttamente accessibili dallesterno. Per fare ci` viene impiegato o un device particolare, che prende il nome di gateway e che si occupa di operare le traduzioni necessarie tra il protocollo di basso livello utilizzato dalla rete domotica su bus ed un ulteriore protocollo che gli permetta di comunicare con lesterno. Nello scenario in cui si va ad inserire la trattazione ` richiesto che tale gateway permetta e un accesso alla rete domotica tramite Ethernet.
4.1.3
House Manager
LHouse Manager ` un concetto sviluppato dal gruppo elite del Politecnico di Torino; e la sua struttura (Fig. 4.2) deriva dallo studio degli house gateways sviluppati e resi disponibili dalla comunit` scientica negli ultimi anni. a Le caratteristiche importanti di tale tecnologia sono soprattutto due: la capacit` a di astrarre le funzionalit` ed i dispositivi della casa secondo un linguaggio di alto a livello e lutilizzo di un livello di intelligenza basato su di un motore a regole. La sua struttura ` suddivisa in due livelli principali: lIntelligent Layer e lAbe stracion Layer. LAbstracion Layer si occupa di tradurre il protocollo di basso livello utilizzato dalle reti in un linguaggio/protocollo di alto livello che permetta un accesso ed un utilizzo uniformi e trasparenti per ogni installazione domotica collegata. Questo protocollo, denominato House Manager Protocol (HMP), adotta una notazione URI-like per identicare i dispositivi ed un set predenito di comandi associato ad ogni tipo di device. Ci` permette sia un controllo di tutti i dispositivi apparo tenenti alla casa, sia un impiego del sistema in ambienti con tecnologie domotiche 22
4 Architettura
Figura 4.2.
House Manager - struttura
dierenti, garantendo laccessibilit` a livello di Abstraction Layer. a LIntelligent Layer permette laccesso ai dispositivi domotici tramite uninterazione pi` di alto livello rispetto allutilizzo dei comandi disponibili a livello di bus. u Esso ` formato da dierenti moduli, i quali si occupano di presentare un ambiente e pi` consono alle esigenze di semplicit` dellutente. In tale livello ` presente una u a e parte di Domotic Intelligence, la quale provvede a fornire una certa automaticit` a nel funzionamento dellHouse Manager. La parte di Domotic Intelligence ` formata e principalmente da un Rule-Engine (motore a regole) ed un Rule-Miner (estrattore automatico di regole): essi posso recepire nuove regole monitorando il normale utilizzo della casa da parte dellutente, cercando quindi di prevederne le scelte ed i gusti, oppure eseguono una serie pressata di regole. E possibile ad esempio creare una regola che, se ` rilevata la presenza di una persona e nella stanza, accenda la luce quando viene rilevato labbassamento delle tapparelle, evitando quindi che questa rimanga al buio. In questo caso lazione che fa scattare la regola risulta essere un comportamento dellutente (che comanda labbassamento della tapparella). La stessa azione potrebbe essere invece il risultato di una regola, realizzata ad esempio tramite un sensore di luminosit` che segnala il superamento a della soglia inferiore, da cui consegue un abbassamento delle tapparelle. 23
4 Architettura
Come detto, ` anche possibile che la Domotic Intelligence monitori lutente e deduca e regole dal suo comportamento: ci` pu` essere utile ma anche fonte di problemi in o o quanto ` molto inuenzato dal grado di abitudinariet` dellutilizzatore; perci` in e a o questi casi potrebbe essere indicato richiedere la conferma di un eventuale comando dedotto da esperienze passate prima di provvedere ad attuarlo unilateralmente senza consenso dellutente. Il controllo di tutti i device facenti parte dellinstallazione da parte dellHouse Manager permette anche unulteriore ed interessante funzione: quella di rendere tali dispositivi potenzialmente interoperabili tra loro, pur appartenendo a, ed utilizzando tecnologie domotiche dierenti. Ci` ` reso possibile dallastrazione ad alto livello oe che viene fatta di ogni dispositivo, tale da rendere ininuente il protocollo da esso usato a basso livello, sul bus. Lastrazione fornita dallHouse Manager risulta molto importante, in quanto permette la realizzazione e lutilizzo di reti domotiche eterogenee e non vincola alluso esclusivo di una di esse. Questo pu` risultare utile data la variet` di dispositivi doo a motici che proliferano sul mercato, la cui scelta risulta essere nora molto vincolante, in quanto non ` possibile aancare due o pi` device con tecnologie diverse, anche se e u il loro utilizzo congiunto pu` apportare determinanti beneci. Se i due dispositivi o non utilizzano il medesimo protocollo, risultano in generale non interoperabili e ci` o obliga lutente a dover scegliere una tecnologia specica per la propria installazione, rinunciando conseguentemente ad alcune funzionalit`. Tramite lHouse Manager a invece ` possibile inserire ogni device desiderato, il quale riuscir` ad interagire con e a ogni altro dispositivo.
24
Capitolo 5 Banco di lavoro EIB/KNX

In questo capitolo viene spiegata passo passo la realizzazione del banco di lavoro (valigetta) EIB/KNX, partendo dalle speciche richieste, passando per la scelta dei componenti, il loro montaggio e concludendo con la presentazione della valigetta realizzata.
5.1
EIB/KNX
Il protocollo di comunicazione scelto presenta unarchitettura molto pi` complessa u di quella della BTicino con cui lHouse Manager risulta gi` in grado di interagire. a Innanzitutto occorre precisare che la divisione dei dispositivi avviene tramite posizionamento sico in linee ed aree (sezione 5.1.1), collegate tra loro da accoppiatori particolari, i quali realizzano uninfrastruttura di rete che si allontana dal semplice bus e si avvicina molto ad una rete cablata IP. Nei paragra successivi vengono delineate le caratteristiche principali del protocollo EIB/KNX, soermandosi in particolare su ci` che lo rende, o dovrebbe renderlo, o uno standard unico ed aermato a livello europeo.
5.1.1
Gerarchia e suddivisione in linee e aree
Come accennato in precedenza, larchitettura di rete EIB/KNX risulta complessa in quanto il semplice collegamento a bus viene potenzialmente ampliato di molto, no a raggiungere complesse strutture e sottoreti. Questo permette da una parte una separazione di partizioni dal resto della rete e dallaltra una complessit` non a trascurabile dei dispositivi di rete, i quali devono occuparsi di gestire queste divisioni logiche tramite opportune regole che assomigliano molto alle regole di routing presenti su hub e switch di una LAN. La separazione avviene tramite appositi dispositivi di sistema, detti accoppiatori: 25
5 Banco di lavoro EIB/KNX
line coupler (accoppiatori di linea) e area coupler (accoppiatori di area). Oltre a questi sono presenti anche altri due tipi di device di sistema, il gateway e la BCU, che vengono trattati in seguito. I vari dispositivi presenti in uninstallazione EIB/KNX vengono suddivisi in linee, con al massimo 256 device ed ogni linea pu` essere a sua o volta inserita in unulteriore livello di gerarchia chiamato area, tramite lopportuno accoppiatore. La similitudine con linfrastruttura di una LAN ` notevole al punto che spesso e i due tipi di accoppiatori vengono presentati appunto come hub (line coupler) e switch (area coupler). La gerarchia risultante riette non solo i collegamenti sici sul bus, ma anche gli indirizzi necessari alla comunicazione, come viene spiegato successivamente (sezione 5.1.2). Linee ed aree vengono accorpate secondo un criterio ben preciso e, a dierenza della struttura di una rete locale, vi sono vincoli sul numero massimo di elementi presenti in una linea e di linee facenti parte di una determinata area. Infatti ogni linea pu` o contenere al massimo 256 device e, salendo di grado, ogni area pu` avere solamente o un massimo di 16 linee. Inne no a 16 aree possono essere collegate tra loro formando un dominio ed interagire, raggiungendo la massima profondit` consentita a nellinstallazione; ci` comporta limpiego di un massimo di 65.536 dispositivi (si o veda la sezione 5.1.2 per i dettagli) che, seppur notevolmente elevato in ambito home automation, pu` risultare vincolante per la building automation. Nel caso in o cui tale limite debba essere valicato, si pu` introdurre la gura di un gateway, il o quale colleghi tramite backbone, ad esempio IP, due installazioni separate, creando unulteriore rete domotica suddivisa in aree e linee come la precedente. Per chiarire la complessa struttura possibile nella rete viene presentato un esempio (Fig. 5.1) in cui si pu` vedere il posizionamento dei vari device allinterno delle o aree e linee oppure anche direttamente sul collegamento tra le varie aree, denominato backbone. Occorre soermarsi un attimo sul concetto di alimentazione del bus, in quanto ogni linea deve essere separata elettricamente dalle altre e quindi necessita di un proprio alimentatore; nel caso in cui una linea necessiti di unalimentazione maggiore ai 160 mA e 320 mA (a seconda dellalimentatore considerato) si pu` inserire un o secondo alimentatore a patto che esso disti sul bus almeno 200 m dal precedente. Se anche laggiunta non sopperisse alla richiesta della linea, due alimentatori possono essere collegati ad essa in parallelo su un shared choke. Oltre ci` ` necessario rispettare i vincoli di distanza massima tra alimentatore e o e dispositivo alimentato (< 350 m) e tra due device (< 700 m): il primo per motivi di operativit`, il secondo per permettere il rilevamento della collisione. Infatti laccesso a al bus avviene tramite il meccanismo noto come Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), il quale obbliga ogni utilizzatore ad ascoltare il canale prima della trasmissione ed impiegarlo solamente se questo risulta libero, ossia se nessun altro sta trasmettendo. In seguito allavvenuto invio occorre rimanere in 26
Figura 5.1.
Topologia della rete EIB/KNX
attesa che il telegramma raggiunga il destinatario senza che unaltra comunicazione disturbi quella attuale: per fare ci` si rimane in attesa un tempo limite necessario al o raggiungimento dellaltro capo del bus, riuscendo a sentire uneventuale collisione e, nel caso, a ritrasmettere secondo opportune tempistiche. Questo meccanismo limita a 1000 m la lunghezza massima di una linea di bus. Gateway Il gateway agisce da interfaccia verso una rete esterna, ad esempio LAN, ed ha il compito di permettere il collegamento tra il bus EIB/KNX a cui ` collegato, con una e rete IP (ad esempio). Questo risulta essere molto importante in quanto in installazioni di grosse dimensioni, quali ad esempio quella di un campus universitario, ci si trova frequentemente nella situazione di dover collegare due edici distanti anche 27
centinaia di metri. Realizzare il collegamento tramite semplice bus risulta sia inutile che tecnicamente impossibile in quanto si presuppone di avere migliaia di dispositivi ed il traco da essi prodotto assume un peso importante e caratteristiche quali il ritardo di propagazione ed i tempi di latenza devono essere tenute ampiamente in considerazione. Oltre a ci`, il gateway permette un accesso alla rete domotica o dallesterno tramite LAN: esso infatti si occupa di incapsulare opportunamente i telegrammi EIB/KNX in normali pacchetti IP, dando la possibilit` a tutti i dispositivi a di utilizzare questo protocollo. Bus Coupling Unit (BCU) Le Bus Coupling Unit (Fig. 5.2) invece sono il cuore della comunicazione su bus in quanto esse si frappongono tra il dispositivo vero e proprio ed il bus. Ogni device comprende una BCU, sia essa esterna, come ad esempio nelle tastiere, sia essa inglobata allinterno come negli accoppiatori di linea, di area, negli attuatori o negli ingressi analogici e binari.
Figura 5.2.
Bus Coupling Unit - BCU
La BCU risulta essere il punto di contatto con il bus e tramite unopportuna interfaccia chiamata Physical External Interface (PEI) comunica con una specica unit` chiamata Application Unit (AU), entrambe a bordo del dispositivo. La BCU si a occupa di ricevere telegrammi EIB/KNX e controlla la AU inviandole le informazioni decodicati. Essa elabora opportunamente i dati ricevuti e ne fornisce di nuovi alla BCU, che provveder` a codicarli e trasmetterli su bus. La PEI ore la possibilit` a a alle due unit` di comunicare in modo semplice. a La BCU contiene un microprocessore, una ROM (Read Only Memory), una RAM (Random Access Memory) ed una EEPROM (Electrically Erasable Programmable ROM) che le permettono di operare; in particolare nella EEPROM sono caricate in atto di congurazione (sezione 5.1.3) le informazioni necessarie al funzionamento del dispositivo mentre la ROM contiene software specico di sistema che il conguratore non pu` variare. o 28
Nella gura 5.3 si pu` vedere larchitettura necessaria alla comunicazione di un o device su bus: come detto non sempre la BCU risulta essere sicamente esterna al dispositivo quindi si pu` avere il caso in cui essa sia inglobata, in ogni caso o larchitettura logica non cambia.
Figura 5.3.
Architettura di comunicazione con bus
5.1.2
Indirizzi
Ogni dispositivo ` individualmente riconosciuto dalla rete tramite un identicativo e univoco. Tale identicativo prende il nome di indirizzo ed ` scritto nella forma 5.1 e area.linea.device (5.1)
e presentato in Figura 5.4, a seconda della posizione che esso occupa nella gerarchia della rete. Lindirizzo totale risulta essere di 16 bit (2 byte), 4 di area, 4 di linea ed i rimanenti 8 di device, da cui deriva 65.536, il numero massimo di dispositivi che ` possibile indirizzare in una rete EIB/KNX. e Lordine di grandezza risulta essere molto elevato e rende EIB/KNX un protocollo adatto a reti di medie/grosse dimensioni, quali ad esempio alberghi, ospedali, fabbriche, centri congressi, i quali intrinsecamente hanno gi` al loro interno una suda divisione in quelle che possono essere paragonate a linee e aree. Si pensi ad esempio ad un albergo, suddiviso in camere, ali e piani, oltre che luoghi di uso personale 29
(camere) ed uso comune (hall, sale da pranzo, ...). Nella home automation tale infrastruttura di rete incide pesantemente sulla realizzazione oltre che risultare non necessaria, pertanto, come si vedr` nella sezione 5.3.3, non verr` realizzata una vera a a e propria gerarchia di rete con gli accoppiatori presi in considerazione.
Figura 5.4.
Struttura indirizzo individuale
Oltre che individualmente, un device pu` essere comandato tramite quello che o viene chiamato indirizzo di gruppo. Tale meccanismo ha una granularit` inferiore al a precedente in quanto non individua uno specico dispositivo, ma tutti i dispositivi facenti parte del gruppo. Anche qui il paragone con il mondo delle reti locali ` e quanto mai idoneo, nel particolare del riferimento al multicast. Il gruppo ` identicato tramite una gerarchia per certi versi simile allidenticae zione del singolo device; lindirizzo di gruppo continua ad essere di 16 bit, ma ci` o che cambia ` la suddivisione interna dei bit (Fig. 5.5), in quanto si perde il concetto e di area, linea e dispositivo per assumere quello di main group, middle group e group address, che vanno a costituire lindirizzo nella forma 5.1. mainGroup.middleGroup.groupAddress (5.2)
Inoltre, come separatore logico dei campi ad alto livello non viene usato . ma /. Mentre gli 8 bit a disposizione per lultimo livello di identicazione risultano essere uguali a quelli per il device allinterno della singola linea, occorre precisare che gli altri due livelli variano; in particolare per il middle group si hanno a disposizione 3 bit e per il main group 5. Questi ultimi due livelli formano la parte alta, primo byte, dellindirizzo di gruppo. Va sottolineato che il bit pi` signicativo del main u group ` sempre pari a 0 in quanto le speciche consentono di avere un massimo di 16 e main group, per il cui indirizzamento sono necessari solamente 4 bit. Lallineamento a 8 bit ed il dimensionamento massimo del middle group ad 8 elementi (su 3 bit) rende necessario lintroduzione del suddetto bit a valore sso. Come nel multicast IP viene associato un indirizzo al gruppo e tramite questo vengono raggiunti tutti i device che vi appartengono: ci` evita loneroso compito di o dover interagire singolarmente con ogni dispositivo interessato alla comunicazione. 30
Figura 5.5.
Struttura indirizzo di gruppo
Potenzialmente il gruppo pu` essere formato da decine di elementi e la quantit` di o a telegrammi che occorrerebbe scambiare risulta in questultimo caso non indierente rispetto al singolo messaggio inviato su bus e decodicato solamente dai destinatari interessati. Ogni dispositivo non ` vincolato ad appartenere ad un singolo gruppo, ma pu` essere e o congurato per operare con gruppi diversi, in quanto le sue caratteristiche possono essere varie ed ognuna di esse pu` risultare utile come attributo di raggruppamento o con altri device simili. Gli esempi di utilizzo possono essere molti e articolati, basti pensare ad un gruppo contenente un pulsante e due luci che devono accendersi insieme, pur continuando ad essere pilotabili anche separatamente. Oppure ad un gruppo con sensori di rilevamento fumo e gas, i quali in determinate situazioni segnalano il superamento di una soglia prestabilita, permettendo al motore che aziona porta e nestra di aprirsi ed al lampeggiante di attirare lattenzione degli occupanti della casa. Anche se posson sembrare complesse, tali congurazioni vengono fatte in via centralizzata tramite un opportuno tool software denominato ETS (sezione 5.1.3), il quale si occupa di connettersi alla rete e scaricare su ogni dispositivo (in particolare sulla relativa BCU) tutto il codice necessario per operare quanto richiesto.
5.1.3
Congurazione
Per congurare uninstallazione EIB/KNX occorre un lavoro complesso che non pu` o essere eettuato semplicemente tramite collegamento di opportuni li in alloggiamenti specici. Una volta collegati tra loro gli apparati tramite bus (qualunque sia la sua topologia) ed eettuati i collegamenti elettrici per il controllo delle utenze, occorre permettere la comunicazione vera e propria tra i dispositivi non solo a livello elettrico ma anche ad alto livello, operando unopportuna e alquanto complessa congurazione. Lassociazione KONNEX ha provveduto a questo aspetto tramite un apposito software denominato Eib Tool Software (ETS) (di cui si pu` vedere una schermata o in Fig. 5.6); come gi` accennato in precedenza EIB/KNX fornisce compatibilit` con a a 31
tutti i dispositivi EIB e quindi non deve stupire lacronimo. Tale strumento viene installato su un personal computer che a sua volta deve essere collegato al bus nel modo che si ritiene pi` utile e comodo, sia esso RS232, USB o IP. E possibile operare u la congurazione dellintera installazione anche senza il collegamento, in quanto tutto il lavoro viene fatto oine; la connessione al bus ` necessaria solamente quando e si desidera eettuare il download su rete di quanto no al momento congurato. Il download pu` coinvolgere uno o pi` dispositivi e pu` riguardare lintero software o o u o solamente alcuni parametri di un device.
Figura 5.6.
Eib Tool Software (ETS)
Il collegamento col bus avviene come detto tramite uninterfaccia scelta dallinstallatore ed utilizza librerie particolari denominate Falcon, che consentono la comunicazione tra il bus ed applicativi presenti sul personal computer in uso, vincolando luso del sistema operativo Windows. Sono presenti nellambito opersource tools software che cercano di permettere la comunicazione col bus domotico non solo tramite lutilizzo del software ETS e delle librerie Falcon: in particolare si segnala il Linux Eib Home Server [27], il quale utilizza uninterfaccia RS232 per il collegamento ad una installazione EIB. Tale progetto per` necessita di una congurazione o preesistente. 32
5.2
Scelta componenti
Per dimostrare la tesi iniziale (capitolo 3) ` stato necessario realizzare un prototipo e funzionante di rete EIB/KNX. Inizialmente si ` pensato di creare un pannello di e lavoro contenente dispositivi domotici ed elettrici al ne di dimostrare leettiva possibilit` di comando di una rete domotica EIB/KNX tramite lHouse Manager. a In seguito a considerazioni ulteriori di trasportabilit` per eventuali dimostraa zioni, la visione del pannello risultava poco consona e si ` deciso di passare ad un e ambiente leggermente pi` ristretto ma al contempo con eguali possibilit` funzionali, u a rappresentato da una valigetta stile 24 ore contenente alcuni dispositivi domotici. Per permetterne il funzionamento e la comunicazione, essa ` stata predisposta per e essere alimentata da rete elettrica esterna ed ` stata fornita di una interfaccia verso e LAN attraverso cui fosse possibile la comunicazione con lHouse Manager. La scelta dei componenti ` stata dettata dalle dimensioni contenute del banco e di lavoro e al contempo da una minima variet` di dispositivi con cui operare. Per a semplicit` ci si ` focalizzati sullutilizzo di luci e prese a cui ovviamente sia possibile a e collegare un qualunque apparato alimentato a 220 V (ventilatore, radio, lampada...). Dato che EIB/KNX viene presentato come standard, si possono utilizzare dispositivi non solamente di ununica marca o casa produttrice, ma si possono inserire anche componenti costruiti da aziende diverse: limportante ` scegliere dispositivi che hane no ottenuto il marchio KONNEX, il quale garantisce che essi rispettino le speciche e siano in grado di essere inseriti in una rete EIB/KNX con altri dispositivi di marche dierenti e con essi operare facilmente. Dato che lassociazione KONNEX presenta sul proprio sito [23] lelenco dei membri associati e dei 10.777 partners divisi in 71 Nazioni, i possibili fornitori sono stati ricercati in tale elenco. In gran parte si tratta di produttori del centro Europa, soprattutto di madrelingua tedesca. I rapporti con i rappresentanti commerciali sono stati lunghi e dicoltosi e solo dopo un tempo non indierente si sono avuti a disposizione una serie di cataloghi aggiornati allinterno dei quali scegliere i dispositivi ricercati. Innanzitutto si ` pensato di utilizzare dispositivi di due marche solamente, per e dimostrare la reale gura di standard di EIB/KNX e al contempo non allargare eccessivamente la cerchia di fornitori, per non allungare i gi` lunghi tempi di cona segna e poter iniziare il lavoro. Si ` scelto di concentrare lattenzione su dispositivi e Abb e Merten, i primi per facilit` di reperibilit` disponendo di grandi distributori a a localizzati in Italia, i secondi per il prezzo contenuto. E da sottolineare che la dierenza di prezzo tra i dispositivi delle due marche citate ` principalmente, ma non unicamente, dovuta alla presenza di una maggior e variet` di programmi su taluni apparati, atti a fornire allutilizzatore una gamma a pi` vasta e complessa di funzionalit`, anche se di (quasi) inutilit` ai ni del lavoro u a a di tesi. 33
La tipologia risultante degli apparati ` poco varia, ma suciente data la semplie cit` del banco. a Ne viene ora presenta una descrizione suddivisa secondo materiale elettrico e domotico.
5.2.1
Materiale elettrico
Nella prima categoria ricadono i materiali di uso in una comune installazione elettrica domestica, quindi con scatole, frutti, portafrutti, placche, li della luce, interruttori e pulsanti. Il montaggio dei frutti ` avvenuto sul rispettivo portafrutto, coronato e dalla placca (Fig. 5.7) come nelle tradizionali installazioni elettriche domestiche.
Figura 5.7.
Frutti e loro inserimento
In particolare, pensando di suddividere il banco di lavoro in due stanze data la presenza di due marche dierenti di dispositivi, si ` dotata ogni stanza con 2 prese e (Fig. 5.8) e 2 luci (Fig. 5.9), per avere una basilare variet` di utenze da comandare. a Entrambe le tipologie di utenze sono state raggruppate ciascuna in portafrutti da 3 posti ciascuno, lasciando un posto per unulteriore aggiunta futura, al momento occupata da un semplice copriforo. Visto linserimento dei frutti e portafrutto allinterno di una valigetta, si ` sude diviso linterno in due scomparti: uno superiore in cui inserire le utenze e i tasti comando ed uno inferiore in cui inserire i moduli DIN, una presa Ethernet ed una presa di alimentazione a vaschetta. Questultima permette la connessione dellalimentatore alla tensione di rete; la presa Ethernet invece collega il gateway domotico ad una LAN. Sebbene gi` disponibile come porta sul gateway, tale presa ` stata proa e lungata al ne di fornire un alloggiamento raggiungibile una volta coperto il quadro centralino con lapposito pannello. Unulteriore considerazione va fatta riguardo la presenza di dispositivi domotici atti ad interfacciare interruttori e pulsanti (sezione 5.2.2): ci` ha suggerito lutilizzo o 34
Figura 5.8.
Gruppo prese
Figura 5.9.
Gruppo luci
di tasti tradizionali (Fig. 5.10), congurati opportunamente per pilotare carichi tramite la rete domotica. Tale scelta permette di conservare in parte la visuale esterna dellinstallazione, con pulsanti e relativa placca tradizionali e quindi pi` u facilmente utilizzabili da persone che preferiscano una visuale pi` classica rispetto u ad una pi` tecnologica e/o complessa, fornita dai tasti e pulsanti domotici. u
Figura 5.10.
Tasti tradizionali
Per porre in sicurezza il prototipo si sono inseriti due dispositivi appositi: linterruttore magnetotermico e quello dierenziale. 35
Linterruttore magnetotermico protegge dai cortocircuiti ed i sovraccarichi ed ` fore mato, nella sua realizzazione pi` semplice, da una elettrocalamita ed una lama u bimetallica: entrambe aprono il circuito nel caso in cui la corrente sia eccessiva, ma hanno range operativi dierenti. La prima si occupa di sovraccarichi pi` consistenti, u mentre la seconda di quelli poco oltre la soglia preimpostata. Linterruttore dierenziale invece agisce contro i guasti a terra o dispersioni: misura la dierenza di corrente tra fase e neutro e se essa risulta sovra soglia, interrompe il circuito. Il dispositivo con cui si ` dotato il banco comprende entrambi gli interruttori; e nel particolare risulta essere un interruttore magnetotermico dierenziale In 16 A, ld 0.01 A, 2 poli, tipo AC, 230V formato dai due interruttori presentati separatamente in Figura 5.12 e Figura 5.11.
Figura 5.11.
Interruttore dierenziale
Figura 5.12.
Interruttore magnetotermico
5.2.2
Materiale domotico
Nella seconda categoria occorre delineare cosa di specico ` stato inserito nel banco e tra la variet` di dispositivi domotici esistenti. Dalla suddivisione presentata nella a sezione 2.3 si ` avuta la necessit` di avere dispositivi di tutte le categorie, al e a ne di comandare linstallazione (input) e vedere lattuazione di comandi (output). 36
Di fondamentale importanza risultano essere anche le ultime due categorie (dispositivi di sistema e di interfacciamento), sia per quanto riguarda la comunicazione tra linstallazione ed lHouse Manager (interfacciamento), sia per il collegamento e funzionamento dei vari dispositivi (sistema).
Attuatori Utilizzando una suddivisione in due stanze, ognuna di esse ` stata fornita di un e attuatore a 4 canali: un utilizzo di un unico attuatore a 8 canali che piloti tutte le utenze indistintamente risultava troppo concentrato e si ` preferito dunque realizzare e una struttura pi` pulita e separata per le due stanze. Dovendo pertanto selezionau re 2 attuatori si sono scelti lAbb (SA/S 4.10.1) (Fig.5.13) e il Merten (6474 90) (Fig.5.14), entrambi a 4 canali ed entrambi da 10 A; una corrente nominale maggiore risultava inutile se non in presenza di carichi pi` pesanti quali ad esempio motori u per serramenti. Gli attuatori non necessitano di una BCU per essere accoppiati al bus in quanto la montano gi` al proprio interno ed inoltre, sempre tramite bus, ricevono lalimentaa zione necessaria ad operare (24 V DC). Tali dispositivi sono montabili su guida DIN EN50022 ed entrambi occupano una larghezza di 4 moduli.
Figura 5.13.
Attuatore Abb
Figura 5.14.
Attuatore Merten
37
Gateway Per poter accedere al banco e pilotarlo dallesterno, si ` resa necessaria uninterfaccia e verso il PC. Nella variet` di interfacce presenti sul mercato, dalle RS232 alle USB a alle Ethernet, si ` optato per un gateway IP (Abb IG/S 1.1) (Fig.5.15) con una e porta Ethernet, permettendo quindi un collegamento LAN tra il PC, la valigetta BTicino e la valigetta EIB/KNX.
Figura 5.15.
Gateway Abb
Tale gateway presenta una porta di comunicazione col bus EIB/KNX, una porta Ethernet 10 Mbps (10 Base-T, IEEE 802.3) e pu` essere alimentato sia a 12 V o in continua che 230 V in alternata. Come gli attuatori non necesssita di BCU in quanto essa ` gi` contenuta al suo interno ed il collegamento necessario col bus e a avviene semplicemente tramite doppino. Il montaggio del gateway ` fatto su guida e DIN EN50022, per una larghezza di 5 moduli. Per quanto riguarda la parte di rete Ethernet, il gateway dispone di un client DHCP, il quale si mette in attesa di un server DHCP il quale gli fornisca un indirizzo IP e nel caso in cui ci` non avvenga esso ` predisposto per autocongurarsi asseo e gnandosi un indirizzo IP nella forma 169.254.xxx.yyy. Data la vastit` di possibili a indirizzi entro cui esso pu` andare a ricadere si ` scelto di fornire il PC contenente o e lHouse Manager di un server DHCP (tftpd32 v3.03 [26]), eettuando unassegnazione statica dellindirizzo tramite MAC e facendolo ricadere nella sottorete contenente anche il gateway della valigia BTicino, permettendo quindi ai due gateway di comunicare tramite IP. Non ` stato necessario introdurre un ulteriore apparato di rete e in quanto il gateway BTicino risulta operare anche la funzione di switch a 6 porte 10/100 Mbps. Per i collegamenti alla rete EIB/KNX occorre precisare che non ` stato necese sario un ulteriore accoppiatore di linea o di area in quanto il gateway Abb IG/S 1.1 svolge gi` la funzione di entrambi. Inoltre esso pu` essere congurato per la o trare o meno i telegrammi EIB/KNX, dato che si potrebbe avere la necessit` di a limitare determinato traco entro unarea o linea precisa, per motivi di sicurezza 38
o performance; per il caso in esame ` risultato essere utile, se non necessario, die sabilitare il ltraggio, permettendo quindi al gateway di trasmettere i telegrammi EIB/KNX ricevuti dal bus alla LAN, incapsulandoli opportunamente in pacchetti IP, e viceversa. La possibilit` di creare pacchetti IP contenenti telegrammi formati a opportunamente permette allHouse Manager di pilotare la rete EIB/KNX come se fosse un qualunque dispositivo eettivamente presente nella rete. Alimentatore Lalimentazione necessaria per il banco di lavoro risulta molto esigua (< 60 mA) come mostrato in Tabella 5.1, quindi lalimentatore ricercato non deve fornire unalta corrente nominale. APPARATO Gateway Attuatore Abb Attuatore Merten Interfaccia tasti Merten TOTALE
Tabella 5.1.
CONSUMO 22 mA < 12 mA < 10 mA < 10 mA < 60 mA
Consumi apparati
Visto il consumo a cui far fronte e vista la presenza di ununica linea, si ` scelto e lalimentatore con la minor corrente nominale disponibile ed il minor costo, optando per il Merten 6833 29 a 160 mA (Fig. 5.16). Esso opera ad una tensione di rete pari a 230 V AC a 50-60 Hz ed ore una tensione di uscita di 29 V CC circa. Se da una parte esso fornisce unalimentazione ben superiore a quella necessaria allintera valigia (nominalmente il dispositivo supporta una linea con 32 utenti bus), dallaltra risulta suciente ad un eventuale, e contenuto, ampliamento futuro dellinstallazione. Lalimentatore richiede un posizionamento su guida DIN EN50022 ed occupa 4 moduli.
Figura 5.16.
Alimentatore Merten
39
Pulsanti Ogni camera inoltre ` stata fornita di alcuni interruttori/pulsanti per permettere e di pilotare le utenze ivi contenute. Per testare leettiva operabilit` di dierenti a marche di dispositivi purch` compatibili KONNEX, si ` abbinato ogni attuatore ai e e pulsanti dellaltra marca. E da sottolineare che variare la congurazione e quindi linteroperabilit` tra dispoa sitivi EIB/KNX signica eettuare una variazione a livello software e non occorre andare a praticare alcuna variazione a livello hardware, come ad esempio avviene con il protocollo SCS di BTicino. Queste ed altre dierenze verranno trattate in maggior dettaglio nel capitolo 8. Sono state utilizzate due tastiere da 4/8 tasti, una Abb (6117-24-101) (Fig.5.17) ed una Merten (6228 44) (Fig.5.18).
Figura 5.17.
Tastiera Abb
Figura 5.18.
Tastiera Merten
La tastiera Abb presenta 8 tasti pilotabili sia singolarmente (ON/OFF) su medesimo tasto) sia a coppie (4 tasti risultanti). Sono presenti 4 LED subito al di sotto dei tasti superiori, indicanti lo stato degli stessi (verde = non premuto; rosso = premuto). Congurando opportunamente gli indirizzi di gruppo, la tastiera ` in e grado di aggiornare lo stato, quindi anche levenuale LED, in caso di comando esterno sullutenza da essa controllata. Risulta quindi possibile, ad esempio, accendere una luce da una fonte esterna (altro pulsante o comando inviato da House Manager) e spegnerla tramite pulsante di questa tastiera, in quanto esso recepisce il comando EIB/KNX che eettua laccensione della luce, varia il proprio stato e alla successiva pressione provveder` a spegnere la luce interessata. a 40
La tastiera Merten presenta anchessa 8 tasti in modalit` ON/OFF, con la a possibilit` di congurazione a 4 tasti, utile soprattutto per utenze non solamente a ON/OFF ma con stati intermedi, quali ad esempio tapparelle. Ogni tasto presenta una corona luminosa che rappresenta lo stato in cui si trova il pulsante. In aggiunta la tastiera Merten integra un ricevitore IR che permette, tramite opportuno telecomando (Merten 6833 29) presentato in Fig. 5.18, di pilotare a distanza i tasti presenti. Lutilizzo di un telecomando, non presente nella tastiera Abb presa in considerazione, facilita un utilizzo della tastiera a persone non normodotate o con problemi di deambulazione.
Figura 5.19.
Telecomando IR
Interfaccia a tasti Per poter inserire interruttori e pulsanti di uso tradizionale nellinstallazione domotica ` stato necessario ricorrere ad una interfaccia a tasti (Merten 6707 90), proposta e in Fig. 5.20, presentante 4 coppie di li per collegare altrettante utenze. Ogni coppia contiene il canale di output, tramite cui avviene linvio del comando ed un canale di appoggio, utile nel caso in cui si voglia ad esempio accendere un LED come segnalazione dellavvenuta pressione del tasto abbinato. Tale canale non viene collegato in quanto non si dispone di un LED da abbinare ad ogni uscita. Riassumendo, i dispositivi domotici presenti risultano quindi essere: alimentatore Merten, 160 mA, 4 moduli DIN attuatore Abb SA/S 4.10.1, 4 canali, 10 A, 4 moduli DIN attuatore Merten 6474 90, 4 canali, 10 A, 4 moduli DIN gateway Abb IG/S 1.1, porta Ethernet 10 Mbps, 5 moduli DIN tastiera Abb 6117-24-101, 4/8 tasti 41
Figura 5.20.
Merten Interfaccia a tasti
tastiera Merten 6228 44, 4/8 tasti + ricevitore IR interfaccia a tasti Merten 6707 90, 4 canali Presentati quelli che sono i vari apparati facenti parte dellinstallazione si pu` o procedere alla spiegazione del montaggio degli stessi ed al completamento della valigetta dimostrativa.
5.3
Montaggio
Come detto in precedenza la valigetta ` stata suddivisa in due vani, distinguendo ci` e o che ` comando ed utenza (area layout) da ci` che realizza linfrastruttura di rete e che e o pu` essere connata in un modulo per centralino (area centralino). Tale suddivisione o di massima ha richiesto comunque unattenta organizzazione dei dispositivi al ne di creare un prototipo esteticamente pulito e presentabile ed al contempo funzionale. Nelle sezioni seguenti (5.3.1 e 5.3.2) vengono spiegati i passi che hanno delineato la scelta della valigia, la quale doveva presentare misure non indierenti data la quantit` di dispositivi da contenere ma che comunque doveva rispettare dei vincoli, a primi tra tutti la trasportabilit` e la maneggevolezza. a Altezza e larghezza interne della valigia sono state dettate principalmente dalla disposizione della sezione layout rispetto a quella centralino, in quanto la prima risulta essere quella a diretto contatto con lulitizzatore e deve quindi essere di facile uso, orendo una visuale di facile comprensione ed una disposizione pulita ed ordinata. La sezione centralino contiene moduli DIN che vengono montati sullapposita guida EN50022 e pertanto ha gi` una sua collocazione intrinseca: ci` che rimane a o da scegliere per tale sezione risulta essere la disposizione orizzontale (nel verso della larghezza della valigetta) oppure verticale. 42
La valigetta ricercata, oltre ad avere misure non standard per permettere la disposizione delle utenze e degli apparati di comando in modo subottimo ma al contempo usabile, deve avere limportante caratteristica di possedere una profondit` a non indierente. Sebbene la sezione layout risulti non particolarmente profonda (< 5 cm), la sezione centralino necessita di maggiore profondit` data la presenza di a moduli DIN. In particolare linterrutore magnetotermico presenta nella leva il punto di altezza massima di tutta la sezione, che risulta essere di circa 9 cm. A tali altezze occorre ancora aggiungere un certo margine per permettere il passaggio dei cavi evitando di perdere in praticit` allatto di installazione, soprattutto per a la sezione layout. La profondit` risultante (> 14 cm) ha rappresentato la carattea ristica principale della valigetta da ricercare, con particolare attenzione al fatto che si trattasse di altezza interna e che spesso le valigette dicilmente raggiungono tali dimensioni, a meno che non si entri nel campo professionale in cui si possono trovare anche contenitori su misura, ignifughi e con range altimetrico operativo elevato. E evidente che tale campo, oltre che oneroso, risulta essere non necessario per le speciche richieste. In seguito alle considerazioni che vengono presentate nelle sezioni relative, si possono notare le caratteristiche principali che la valigia ricercata deve possedere: larghezza di almeno 41 cm, altezza di almeno 35 cm e profondit` di almeno 16 cm. a Questultima misura ` risultata essere fonte di notevoli problemi di reperibilit` in e a quanto le classiche valigette stile 24 ore reperibili sul mercato non presentano una profondit` cos` ampia, dato che risulterebbe uno spreco enorme dovendo portare a con s` documenti, che, per quanto voluminosi, dicilmente necessitano un vano cos` e ampio. Ulteriore problema risulta essere la suddivisione della profondit` della valigia a tra il fondo ed il coperchio della stessa: dovendo inserire dispositivi su entrambe le parti, occorre che essa non solo presenti una profondit` complessiva di 16 cm, ma a che le due sezioni siano di almeno 5 e 9 cm rispettivamente. Per facilitare il montaggio nei due vani della valigia sono state necessarie due plance di legno compensato che simulassero la parete nella sezione layout e la copertura nella sezione centralino. Essendo una valigia dimostrativa e non una vera e propria installazione a muro, i frutti inseriti negli appositi portafrutto e rivestiti dalla placche non sono stati inseriti nelle consuete scatole da incasso a parete, ma semplicemente avvitate alla plancia superiore in legno, la quale a sua volta ` stata e inserita e fermata nel vano verticale della valigia. Questo ha permesso di avere una maggiore libert` nel collegamento dei li elettrici e del cavo bus tra i vari dispositivi a ivi contenuti, fornendo al contempo una separazione tra utente e li allatto dellutilizzo. Nella sezione centralino la plancia in legno simula la copertura in plastica tipica dei quadri luce, inutilizzabile in questo caso data la variazione della distanza tra le due linee DIN. Tale pannello ha il fondamentale compito di isolare il cavo EIB/KNX ed i cavi 43
elettrici da un accidentale tocco dellutilizzatore; ci` potrebbe risultare potenzialo mente molto pericoloso, nonostante la presenza dellinterruttore magnetotermico, in quanto al di sotto del pannello vi sono i li che portano lalimentazione a tutta la valigia. I requisiti della valigia sono riassunti in Tabella 5.2. DIMENSIONI Altezza > 41 cm Larghezza > 35 cm Profondit` a fondo > 5 cm coperchio > 9 cm totale > 16 cm MATERIALE Esterno robusto, antiurto Interno adatto per ssaggio pannelli in legno e guide DIN
Tabella 5.2. Caratteristiche valigia
La valigia scelta risulta essere una Manutan 1986Y57, capacit` 25 l, 410x325x190 a mm, presentata di seguito (Fig. 5.21).
5.3.1
Sezione layout
Pensando di realizzare due stanze, una possibile soluzione risultava essere quella di disporre gli elementi facenti parte del medesimo locale logico su di una stessa riga, abbinando quindi una placca prese, una luci e la relativa tastiera in linea tra loro. La presenza dellinterfaccia a tasti, che non risulta visibile ma ` nascosta allintere no del pannello, necessitava la vicinanza della placca con pulsanti tradizionali la quale, essendo sensibilmente pi` ampia degli altri elementi, ha obligato ad occuu pare unulteriore linea. Lo spazio avanzato in questultima, oltre a nascondere nel retro la posizione dellinterfaccia a tasti, lascia unarea relativamente comoda per linserimento di uneventuale utenza futura. In seguito a queste considerazioni la disposizione pi` consona ` risultata essere u e quella in orizzontale, lungo il lato pi` lungo della valigetta, considerando la maggiore u visibilit` di tale sezione: aprendo la valigetta, il fondo rimane poco visibile, ma ci` a o che ` il coperchio viene sollevato e rimane posizionato in perpendicolare rispetto al e piano di appoggio, orendo quindi unottima visuale allutilizzatore. 44
Figura 5.21.
Valigia Manutan 1986Y57
Nella gura seguente (Fig. 5.22) si pu` vedere la disposizione della sezione layout o con le misure salienti al ne della realizzazione: la gura risulta ruotata di 90 in senso antiorario rispetto alla visuale che si ha aprendo la valigia. Come si pu` o notare, oltre alle considerazioni fatte in precedenza, vi ` dello spazio, seppur non e abbondante, distribuito sui bordi, in particolare nella zona bassa (verso lattaccatura delle due sezioni) al ne di permettere il passaggio del cavo del bus e dei li elettrici da una sezione allaltra.
5.3.2
Sezione centralino
La sezione centralino risulta inserita nella parte inferiore della valigia e contiene principalmente moduli DIN EN50022. Per evitare spreco di spazio e permettere un dimensionamento del centralino pi` contenuto di quello standard, le due guide DIN u necessarie allinstallazione sono state montate direttamente sul fondo della valigia, 45
Figura 5.22.
Sezione layout
tralasciando linserimento di quello che ` il normale supporto ad esse e la relativa e copertura in plastica. Questultima ` necessaria al ne di non lasciare li volanti e a stretto contatto con lutilizzatore, ma si ` stati costretti a realizzarla ad-hoc in e quanto, avvicinando le due guide DIN EN50022 per motivi di spazio, la copertura in plastica non trovava pi` il suo normale incastro. u Deciso il verso di posizionamento si ` cercato di montare gli apparati su guida e 46
DIN in modo da ottimizzare i moduli a disposizione ed al contempo operare una minima separazione di sicurezza tra la parte di alimentazione ed i rimanenti apparati. In particolare ` stata prestata attenzione al posizionamento dellalimentatore e dele linterruttore magnetotermico, inserendoli il pi` vicino possibile. Gli apparati che u necessitano di montaggio su guida DIN EN50022 risultavano essere il gateway, lalimentatore ed i due attuatori, in aggiunta allinterruttore magnetotermico per sicurezza e due prese (una per lalimentazione ed una per la LAN) per comodit` di a utilizzo. Le Tabelle 5.3 e 5.4 mostrano la suddivisione dei dispositivi sulle due guide DIN necessarie, ottimizzando la disposizione sia per laspetto della sicurezza, sia per la comodit` di utilizzo e congurazione. a APPARATO Presa alimentazione Presa LAN Attuatore Abb Gateway TOTALE
Tabella 5.3.
MODULI OCCUPATI 1,5 1,5 4 5 12
Disposizione su guida DIN EN50022 - linea sinistra
APPARATO Interruttore dierenziale Interruttore magnetotermico Alimentatore Attuatore Merten TOTALE

Tabella 5.4.
MODULI OCCUPATI 2 2 4 4 12
Disposizione su guida DIN EN50022 - linea destra
La scelta della disposizione delle due guide DIN EN50022 ` dettata dalla scelta e di contenere il pi` possibile loccupazione di spazio del bus EIB/KNX, in quanto i u li elettrici risultano molto pi` essibili e pertanto si pu` sfruttare tale loro caratteu o ristica. Inoltre i dispositivi Abb e Merten presentano i collegamenti su lati opposti e ci` suggerisce un montaggio dei primi sulla guida sinistra e gli ultimi su quella o destra. Lo spazio tra le guide risulta occupato dai collegamenti bus, mentre i li elettrici vengono posti lungo passaggi esterni. Ci` permette inutili tensioni e torsioni del cavo o EIB/KNX, riducendone la possibilit` di malfunzionamento per cause meccaniche. a 47
In tale sezione sono presenti sia il cavo bus EIB/KNX, contenente il doppino nero/rosso, avvolto nella schermatura e rivestito in plastica verde, sia i li elettrici di fase (nero), neutro (blu) e terra (giallo/verde). Il montaggio della sezione non ha presentato particolari dicolt` in quanto sono a state necessarie solamente di due viti per ogni linea DIN da ancorare al fondo della valigia. In Figura 5.23 (ruotata di 90 in senso antiorario rispetto alla visuale che si ha aprendo la valigia) vengono riportate le misure per il posizionamento delle linee, avvicinandole tra loro rispetto a quanto solitamente fatto nei quadri luce o centralini, pur mantenendo una distanza tale da permettere il passaggio comodo dei cavi e la loro maneggevolezza. Nel lato su cui vi ` la giunzione con la sezione layout e ` stato predisposto spazio adeguato al passaggio dei cavi tra le due sezioni, come e altres` fatto nellaltra sezione.
5.3.3
Collegamenti
La topologia della rete EIB/KNX pu` essere una qualunque tra anello, stella o mista, o che possono essere considerate equivalenti ai ni della situazione presa in esame. Ogni terminale di connessione bus pu` contenere no a 4 cavi di collegamento come o si pu` notare in Fig. 5.24; quindi, per evitare saldature ed intrecci di cavi si ` o e deciso di utilizzare nella sezione inferiore una topologia a centrostella con al centro il gateway, nel cui apposito alloggiamento si sono fatti convergere i li derivanti dallalimentatore, dai due attuatori ed un ultimo per prolungare il bus nella parte superiore della valigia (sezione layout). Questo ` stato fatto perch` in tale sezione vi sono presenti ancora tre dispositivi e e domotici: linterfaccia a tasti, la tastiera Abb e la tastiera Merten. Tali dispositivi sono stati collegati in cascata con il cavo bus derivante dalla sezione centralino, passando in ordine nei tre dispositivi di cui sopra. La Fig. 5.25 presenta una visuale dei collegamenti del bus EIB/KNX. Oltre ai collegamenti domotici tramite bus EIB/KNX si sono eettuati i collegamenti elettrici al ne di permettere un utilizzo completo dellinstallazione. Per semplicit` viene proposto solamente lo schema dei collegamenti (Fig. 5.26) al ne a di ottenere cos` una visuale dinsieme il pi` chiara possibile. u Unendo le due sezioni negli appositivi vani della valigia si ` ultimata la costrue zione del banco di lavoro EIB/KNX richiesto. In Figura 5.27 viene presentata la visuale della stessa aperta e pronta alluso.
48
Figura 5.23.
Sezione centralino
49
Figura 5.24.
Terminale di connessione bus
Figura 5.25.
Topologia di rete in oggetto
50
51
Figura 5.26. Schema elettrico installazione
Figura 5.27.
Valigia EIB/KNX ultimata
52
Capitolo 6 House Manager

In questo capitolo viene presentata larchitettura interna dellHouse Manager, soermandosi sui due livelli logici che lo compongono: lAbstraction Layer e lIntelligence Layer.
6.1
Architettura interna
La struttura interna dellHouse Manager ` presentata in Fig. 6.1, in cui si possono e notare i vari componenti logici. LHouse Manager ` architetturalmente organizzato su due livelli, che principale mente si occupano di fornire interazione con la rete domotica (Abstraction Layer) e con le applicazioni lato utente (Intelligence Layer). Di seguito vengono presentati i moduli facenti parte del gateway, al ne di delinearne la particolare funzione e fornendo le basi di conoscenza per la contestualizzazione del lavoro eettuato, che verr` proposto nel capitolo 7. a
6.1.1
Intelligence Layer
LIntelligence Layer rappresenta lastrazione delle reti a cui lHouse Manager ` cole legato. In esso vengono rappresentati i singoli dispositivi eterogenei, rendendoli quanto pi` omogenei possibile: tale rappresentazione permette una maggiore interau zione tra gli stessi, in quanto si cerca di abbattere quella dicolt` di comunicazione a intrinseca quando si opera con apparati utilizzanti protocolli dierenti. Tramite questo livello allutente ` consentito accedere, gestire ed interagire con e la casa, secondo forme e modalit` dettate dallo stesso House Manager e che vena gono presentate allutilizzatore tramite apposite interfacce, gestite dallInteraction Manager (sezione 4.1.1). Dallaltra parte lIntelligence Layer interagisce con la casa 53
6 House Manager
Figura 6.1.
House Manager: schema a blocchi
grazie allAbstraction Layer, attuando i comandi desiderati dallutente e ricevendo eventuali risposte o messaggi da recapitare a questultimo. Come si pu` vedere nella gura, lIntelligence Layer ` formato da 3 componenti o e principali: lHouse Server, lHouse Model ed il Rule Engine, che interagiscono tra di loro. House Server LHouse Server permette allHouse Manager di ricevere comandi dallesterno e ad essi rispondere, eventualmente eettuando le necessarie comunicazioni e veriche 54
6 House Manager
con lHouse Model. Tramite XML-RPC propone una vista dellinstallazione domotica, fornendo i dati necessari allinterazione con essa e tralasciando gli aspetti di basso livello (bus) intrinsechi della comunicazione con questultima. LHouse Server fornisce un elenco di dispositivi logici disponibili e ad ognuno di essi abbina un elenco di possibili comandi. Dallesterno ` quindi possibile ottenere la congurazione e della casa ed interagire con questa, ma la granularit` con cui essa viene vista non ` a e quella reale ma quella corrispondente alla rappresentazione logica fornita dallHouse Server. Per non operare un inserimento di tutti i dispositivi contenuti nella casa ogni volta che si avvia lHouse Manager ` presente un le di congurazione, il quale contiene e lo schema XML che descrive le caratteristiche e la disposizione dei vari dispositivi allinterno dellinstallazione. Il le ` impostato come segue: e
1 <HOUSE> 2 <ROOM> 3 <NAME>NomeStanza</NAME> 4 <DESCRIPTION>DescrizioneStanza</DESCRIPTION> 5 <DEVICE id=Identificativo type=NumeroStati manifacturer=
tecnologia>
6 <NAME>NomeDevice</NAME> 7 <DESCRIPTION>DescrizioneDevice</DESCRIPTION> 8 </DEVICE> 9 ... 10 </ROOM> 11 </HOUSE>
in cui si pu` notare la denizione di ogni singolo oggetto software. Ognuno di o questi rappresenta un device reale della rete, a cui ` associato lidenticativo univoco e (id ), il tipo (type) e la tecnologia domotica relativa (tecnologia). Tramite questultima si riesce ad associare loggetto software (o anche device astratto) di alto livello al driver corretto al ne di operare la giusta sequenza di operazioni per interagire con il device domotico relativo.
House Model LHouse Model contiene la rappresentazione astratta dei device domotici presenti nella casa; esso aggrega gli oggetti software risultanti suddividendoli in stanze, per rispecchiarne la disposizione reale. E in questo componente che si attua la corrispondenza tra il device astratto, di alto livello (quello logico su cui si opera) e quello di basso livello (il device domotico presente realmente nella casa). Il device astratto 55
6 House Manager
altro non ` che un oggetto software in cui sono delineate le caratteristiche necessae rie per linterazione con esso: principalmente saranno dettagliati lo stato attuale, il tipo di device e lelenco di comandi pendenti su di esso e in attesa di essere attuati tramite interazione con la rete domotica. Per meglio comprendere la terminologia e la distinzione che verr` utilizzata per a tutta la trattazione, viene presentata la seguente gura (Fig. 6.2) che rappresenta un esempio di congurazione in sui si pu` notare lambiente di lavoro su cui si opera o ad alto livello (sinistra) e ci` a cui questo corrisponde nella rete domotica reale o (destra).
Figura 6.2.
Esempio di corrispondenza tra oggetti software e device domotici
Rule Engine Il Rule Engine contiene la logica necessaria per il controllo continuo del vericarsi di alcune regole e per lattuazione delle conseguenze ad esse correlate. Tale motore di regole ` realizzato attraverso un applicativo opensource (drools v2.0 [28]) che e costantemente monitora la rappresentazione logica della casa (House Model) e valuta un insieme di regole. Le regole seguono il semplice schema
1 ... 2 <java:condition> 3 condizione da verificare 4 </java:condition> 5 <java:consequence> 6 codice eseguito se la condizione ` verificata e 7 </java:consequence> 8 ...
in cui viene valutato il vericarsi di una o pi` condizioni (condition), a fronte del u 56
6 House Manager
quale viene eseguito quanto previsto nella conseguenza (consequence). Nel caso in cui la condizione richiesta dalla regola non venga vericata, la regola viene ignorata. Le regole possono attuare un insieme di comandi utili al vericarsi di alcune situazioni, siano esse causate dallutente (ad esempio labbassamento delle tapparelle che causa laccensione della luce nel locale), siano esse causate da eventi non imputabili allutente (ad esempio il sensore di pioggia che rileva acqua sulle nestre aperte e le chiude).
6.1.2
Startup
Lavvio dellHouse Manager comporta la seguente sequenza di iterazioni: 1. Caricamento congurazione: vista la necessit` di conoscenza dellinstala lazione e suddivisione della casa viene letta da le la congurazione opportuna, procedendo quindi alla creazione della corrispondente architettura logica nellHouse Model e allassociazione degli oggetti software al driver corretto presente nellAbstraction Layer. 2. Caricamento scenari: nel caso in cui si desiderino avere funzionalit` pi` a u evolute e complesse ` necessario apprendere tali impostazioni da un ulteriore e le contenente le regole necessarie. La separazione di queste dalla congurazione logica relativa ai dispositivi ` necessaria sia per luso dierente a cui e sono destinate, sia per il carattere opzionale delluso delle regole, contrario allassoluta necessit` della congurazione dellarchitettura logica. a 3. Lancio server: viene lanciato il server (House Server) il quale sar` in grado a di ascoltare le richieste eettuate dallutente (comandi) ma anche di interagire con le reti domotiche a cui lHouse Manager ` collegato. e
6.1.3
Abstraction Layer
Compito dellAbstraction Layer ` quello di operare una traduzione tra il comando di e alto livello presente nella coda delloggetto software e leettivo comando EIB/KNX da inviare su bus. Per fare ci`, tale livello deve comprendere il driver necessario o allinterfacciamento con le dierenti tecnologie domotiche; in particolare occorre che ogni protocollo venga trattato diversamente, essendo necessario il rispetto delle speciche relative. LAbstraction Layer permette allIntelligence Layer di accedere e gestire la casa rispettando i protocolli utilizzati in essa. Lunica rete al momento collegata allHouse Manager risulta essere quella BTicino e pertanto lAbstraction Layer contiene il BTicino Driver. 57
6 House Manager
Il driver si occupa di attuare i comandi e di controllare lo stato dei device domotici. La prima funzione viene realizzata tramite un ciclo in cui vengono controllate le code abbinate agli oggetti software; nel caso in cui vi sia presente un comando, si provveder` ad attuarlo, pilotando quindi lutenza; in seguito verr` aggiornato lo a a stato del relativo oggetto software in memoria, al ne di avere sempre una corrispondenza corretta tra apparato reale presente nella rete domotica e la sua rappresentazione astratta presente in memoria. Nel ciclo di controllo invece il driver opera in polling e richiede lo stato attuale a tutti i dispositivi domotici facenti parte della rete a cui esso ` abbinato. Una volta e ricevuta risposta, opera per aggiornare eventualmente lo stato del device astratto presente in memoria, assicurando la corrispondenza tra i due. Il collegamento alla rete domotica avviene tramite LAN al gateway relativo, il quale si occuper` di eettuare le necessarie traduzioni tra il protocollo utilizzato sul a bus e quello su LAN con lHouse Manager. Per laccesso alla LAN viene utilizzato un socket attraverso cui si inviano e ricevono i messaggi con il gateway. Per rispettare sia il protocollo utilizzato sulla LAN sia quello utilizzato sul bus, il driver deve provvedere ad opportuni meccanismi di basso livello per eettuare le codiche e decodiche necessarie per tradurre i messaggi nelle code in comandi corretti per il bus e viceversa.
58
Capitolo 7 SoluzioniAdottate
Nel capitolo precedente ` stata presentata larchitettura dellHouse Manager nella e granularit` necessaria al ne di comprendere il lavoro svolto. In questo capitolo viene a fornita la spiegazione di come ` stato introdotto un driver nellAbstraction Layer e (Fig. 7.1), per permettere la comunicazione dello stesso con una rete EIB/KNX.
Figura 7.1.
KnxDriver da inserire nellAbstraction Layer
7.1
Driver
Il KnxDriver deve interagire e comunicare con lIntelligence Layer e la rete domotica (tramite LAN). Nella gura Figura 7.2 viene presentata la dierenza macroscopica tra il driver BTicino gi` presente nellHouse Manager e quello Knx che verr` trattato a a nelle sezioni seguenti. 59
7 SoluzioniAdottate
Figura 7.2.
Driver BTicino e Knx
7.1.1
KnxDispatcher
Il KnxDispatcher deve essere in grado di gestire le code comandi dei vari device e, nel caso ve ne siano di pendenti, deve provvedere ad attuarli inoltrandoli alla rete domotica tramite il KnxWriter. Dovendo interagire con gli oggetti software deve avere i necessari riferimenti ad essi e mantenerne quindi una lista. Il comando nella coda messaggi dei vari oggetti device ` sempre nella forma 7.1, e room.device.comando viene tradotto nella forma 7.2 destinatario,comando (7.2) (7.1)
ed inviato alla rete: la realizzazione del collegamento e la gestione della comunicazione ` demandata al KnxWriter. e Tramite le prime due parti del comando di alto livello (room e device) si identica il device domotico (o eventualmente il gruppo) interessato. Nel caso delle due valigie, ognuna di esse corrisponde ad una stanza, nominata rispettivamente valigia Bticino e valigia Knx. Ad alto livello gli oggetti software vengono identicati con lindirizzo di gruppo, permettendo quindi allHouse Manager di interagire col gruppo nel suo insieme. Se questo non fosse fatto, occorrerebbe interagire con ogni dispositivo singolarmente, portando ad un incremento del numero di messaggi necessari per eettuare la medesima comunicazione. Risulta quindi pi` performante interagire con il gruppo di u dispositivi tramite un unico comando, indirizzato al gruppo appunto; inoltre ci` o 60
7 SoluzioniAdottate
permette al tasto che pilota lutenza di rilevare la variazione di stato della stessa, il tutto in maniera automatica, senza bisogno di alcun settaggio aggiuntivo. Si provi ad immaginare un esempio per meglio comprendere la situazione. Si desidera realizzare un collegamento che permetta laccensione di una luce tramite apposito tasto: il gruppo che viene formato conterr` quindi il pulsante, luscita a dellattuatore (su cui ` attestata lutenza) ed il canale di aggiornamento abbinato. e Tramite questultimo il gruppo riesce a venire a conoscenza del cambiamento di stato della luce e quindi controllarla opportunamente. Questo signica che se il tasto accende la luce e lHouse Manager la spegne, il primo si accorge della variazione ed alla successiva pressione provvede ad accenderla nuovamente. Se invece non fosse realizzato il gruppo, il tasto non capterebbe lo spegnimento eettuato da altri device (non necessariamente facenti parte del gruppo, come ad esempio lHouse Manager) ed alla successiva pressione invierebbe un comando di accensione inutile, dato che il device domotico risulta gi` in tale stato. Questo a dimostra non solo la facilit` di invio di un singolo comando al gruppo invece di n a comandi ai singoli elementi che vi appartengono, ma anche la necessit` di avere un a gruppo per permettere a pi` dispositivi domotici di cooperare correttamente. u Operando con gruppi e non con singoli device, si pu` avere un numero maggiore o di oggetti software rispetto al numero reale di dispositivi presenti nella rete. Questo ` dovuto al fatto che alcuni di essi sono ttizi, cio` non corrispondono ad un vero e e e proprio device domotico, ma ad un insieme di questi.
7.1.2
KnxWriter
Il KnxWriter permette al KnxDispatcher di inviare su bus i comandi pendenti. Il KnxWriter realizza la connessione alla LAN (tramite linterfaccia di rete presente sul PC) e di qui alla rete EIB/KNX (attraverso lIP Gateway); verso la LAN viene utilizzata una comunicazione UDP e vengono inviati pacchetti in cui sono incapsulati i telegrammi EIB/KNX (KNXoverIP). Per lincapsulamento e la codica il KnxWriter si appoggia al KnxEncoder, al quale demanda i complessi metodi di traduzione da comando di alto livello (letto dalla coda delloggetto software) in comando di basso livello (da inviare su bus).
7.1.3
KnxReader
Per permettere allHouse Manager di riconoscere lo stato dei dispositivi EIB/KNX si rende necessario linserimento del KnxReader, un server in grado di mettersi in ascolto e ricevere le comunicazione dalla rete domotica. Tale gura viene introdotta a causa dellimpossibilit`, al momento attuale, di ricevere un ACK (Acknowledge a o conferma) relativo al comando inviato ed una risposta in caso di interrogazione sullo stato di un device domotico. 61
7 SoluzioniAdottate
Il KnxReader permette inoltre allHouse Manager di rilevare i cambi di stato che le utenze hanno quando vengono premuti i relativi tasti comando. Avendo congurato lIP Gateway per non eettuare ltraggio sullo scambio di telegrammi, esso inoltra su LAN i comandi EIB/KNX (incapsulandoli in IP) che circolano su bus; questo permette allHouse Manager di aggiornare lo stato corrente delloggetto software corrispondente al device domotico che ha subito il cambiamento di stato. Per operare correttamente il KnxReader necessita lassociazione allindirizzo multicast a cui lIP Gateway inoltra i telegrammi incapsulati. La gura del KnxReader risulta necessaria per permettere la corretta corrispondenza tra oggetto software e relativa controparte domotica ed evitare inconsistenze, potenzialmente pericolose. Si pensi ad esempio al controllo di un sensore che rilevi la presenza di gas nellambiente. Se viene superata la soglia preimpostata si ha una situazione di pericolo: occorre quindi scatenare un allarme e provvedere ad alcune azioni che permettano unopportuna gestione della situazione. Se non fosse presente il KnxReader, la segnalazione del sensore rimarrebbe connata al bus e lHouse Manager non sarebbe in grado di rilevare nulla; il corrispondente oggetto software risulterebbe nel proprio range operativo e linconsistenza potrebbe portare a gravi conseguenze. Quando riceve un pacchetto UDP il KnxReader provvede ad estrarne il contenuto e tradurlo come telegramma EIB/KNX: da tale telegramma ` in grado di riconoscere e il gruppo interessato ed il nuovo stato impostato. Dopodich`, tramite il collegamento e con KnxDispatcher, il KnxReader riesce ad accedere al set di oggetti software ad esso collegati e variarne lo stato.
7.1.4
KnxEncoder
Il KnxEncoder fornisce adeguato supporto alla traduzione dellHouse Manager Protocol (HMP) in EIB/KNX e viceversa, sia al KnxWriter sia al KnxReader. Il primo si occupa di inviare al bus, tramite LAN, un comando e quindi necessita di una codica da comando di alto livello a telegramma EIB/KNX; il secondo invece riceve tramite LAN da bus un telegramma e necessita la codica inversa. Il comando presente nella coda delloggetto software comprende il proprio identicativo logico ed il comando vero e proprio: lidenticativo rappresenta lindirizzo di gruppo (su 2 byte) da comandare. I comandi attuabili al momento sono solamente quelli di ON e OFF, che permettono uninterazione base tra i dispositivi EIB/KNX e lHouse Manager. Si rimanda al futuro lintegrazione eventuale di comandi pi` complessi. u Lindirizzo di gruppo (riportato in Fig. 7.3 per chiarezza) richiede una codica leggermente complessa in quanto le parti corrispondenti al main ed al middle devono essere opportunamente concatenate per formare il primo byte dellindirizzo, mentre il group andr` a formare il secondo byte. a 62
7 SoluzioniAdottate
Figura 7.3.
Struttura indirizzo di gruppo
Lo pseudo-codice seguente (Fig. 7.4) mostra come avviene il concatenamento necessario per la formazione del primo byte dellindirizzo di gruppo partendo dai due valori separati.
Figura 7.4.
Pseudo-codice per il concatenamento di main e middle
7.1.5
Dierenze con BTicino
Il lavoro di progettazione ed inserimento dei moduli necessari al ne di operare correttamente con una rete EIB/KNX ` stato eseguito seguendo la struttura pressata e dallAbstraction Layer dellHouse Manager e prendendo come esempio i moduli relativi alla rete BTicino. Ovviamente, operando con due tecnologie domotiche diverse, ` facile comprendere e che vi siano dierenze nella realizzazione. Tali dierenze risultano essere interessanti ed occorre soermarvisi adeguatamente, per meglio comprendere linterazione dellHouse Manager con entrambe. Vengono proposte prima due gure per meglio spiegare il funzionamento del modulo Dispatcher nel driver BTicino (Fig. 7.5) e EIB/KNX (Fig. 7.6) utili a migliorarne il paragone fatto in seguito. 63
7 SoluzioniAdottate
Figura 7.5.
Funzionamento BTicinoDispatcher
Figura 7.6.
Funzionamento KnxDispatcher
Aggiornamento dello stato di un device Innanzitutto risulta evidente la presenza di un modulo in ascolto (KnxReader) per la rete EIB/KNX, che non trova controparte nella rete BTicino: ci` ` dovuto prinoe cipalmente ad una separazione del meccanismo di ascolto dal Dispatcher relativo, la cui necessit` ` stata arontata nella sezione 7.1.3. Mentre il BTicinoDispatcher si a e occupa di interrogare i device reali tramite polling e quindi di aggiornare lo stato del corrispondente device astratto per permettere di avere una corrispondenza valida tra i due, il KnxDispatcher non lo fa, in quanto opera secondo un meccanismo dierente. Esso infatti non interroga i dispositivi per ottenerne lo stato ma ` il KnxReader che e si pone semplicemente in ascolto continuo sulla rete e, ad ogni variazione di stato, opera la medesima variazione ad alto livello nel relativo oggetto software, agendo 64
7 SoluzioniAdottate
sul set di dispositivi collegati al KnxDispatcher. La dierenza di meccanismo permette una pi` performante attuazione di un u comando rispetto a quanto avviene per BTicino, ma permette soprattutto di ovviare al comportamento erratico dimostrato nella rete EIB/KNX quando si voglia controllare lo stato di un dispositivo domotico. Infatti, anche tramite ETS, la risposta allinterrogazione non ` mai sicura ed adabile: in particolare si nota che il e dispositivo interrogato risponde saltuariamente. Questa incertezza impedisce lutilizzo di un meccanismo di polling da parte del KnxDispatcher, come avviene invece nel BTicinoDispatcher, ed obbliga allinserimento di un server in ascolto delle variazione dovute a comandi manuali sulla rete. Dovendo creare un server in ascolto continuo si rende necessario la creazione di un nuovo modulo, il KnxReader appunto, separato dal KnxDispatcher in quanto entrambi necessitano di operare contemporaneamente.
ACK Altra dierenza da sottolineare riguarda la ricezione di un ACK in seguito ad un comando. Mentre in BTicino, quando un comando viene attuato, viene ricevuto un ACK a conferma dellavvenuta ricezione ed un successivo controllo dello stato permette di vericare non solo lavvenuta ricezione ma anche la sua attuazione, nellinstallazione EIB/KNX ci` non avviene. Una volta inviato il comando, il Knxo Dispatcher deve dare per scontato che esso venga ricevuto senza problemi e che la sua attuazione sia sicura. Lunica soluzione attuabile, al momento, risulta quella di variare automaticamente lo stato del device astratto in seguito allinvio del comando alla rete: lavvenuta ricezione e successiva attuazione dello stesso non risultano controllabili se non visivamente, ma questo non permette alcun riscontro allHouse Manager. Come detto prima, inoltre, non ` adabile richiedere lo stato attuale ad e un dispositivo. Questo pu` essere fonte di notevoli problemi, primo tra tutti la non corrispondenza o tra device astratti e reali, ma al momento non vi ` soluzione alternativa. Nel caso in e cui un comando non venga attuato regolarmente, per motivi la cui spiegazione non ` e qui di interesse, si viene a creare una situazione inconsistente, che pu` generare a sua o volta una reazione a catena e potenzialmente pericolosa. Occorre sottolineare per` o che un ulteriore comando sul medesimo dispositivo non viene preceduto da un test (locale o sico) sul dispositivo e quindi impone uno stato arbitrario in base principalmente a ci` che viene visto dallutente, il quale ` in grado di vericare lavvenuta o e attuazione del comando precedente (si pensi ad esempio allaccensione di una luce). 65
7 SoluzioniAdottate
7.2
Congurazione
Una volta fatti gli opportuni collegamenti sici ed elettrici tra i componenti domotici occorre realizzare anche i collegamenti logici, per permettere ad essi di operare secondo schemi e regole decise dallutente. Questa congurazione viene attuata tramite ETS (sezione 5.1.3), al momento unica possibilit` presente sul mercato che a permetta di eettuare tale operazione. Inizialmente si ` pensato di suddividere i device domotici in due stanze, ognuna e contenente una tastiera, un attuatore e 4 utenze (2 luci e 2 prese), che per facilitare la visualizzazione risultano disposte orizzontalmente. Esternamente a queste due camere sono presenti una pulsantiera tradizionale, che permette il comando di utenze in entrambe le stanze, lalimentatore ed il gateway che permette linterfacciamento con lHouse Manager. Nella prima stanza sono presenti: una placca con 2 prese; una placca con 2 luci, una verde ed una rossa; la tastiera Merten; lattuatore Merten. mentre nella seconda sono presenti: una placca con 2 prese; una placca con 2 luci, una verde ed una rossa; la tastiera Abb; lattuatore Abb. Per motivi tecnici di aggiornamento dei software ed altre problematiche tecniche relative agli apparati Merten, si ` provveduto alla sola congurazione della stanza e inferiore, con soli device Abb. I problemi hanno riguardato sia la tastiera sia lattuatore Merten. Questultimo non ` riuscito ad essere opportunamente congurato in quanto tramite ETS non era e permesso accedervi, in quanto la versione della BCU richiesta dieriva da quella fornita dal dispositivo. Ogni tentativo di accesso ` risultato vano. Probabilmente tale e device viene congurato di default alluscita della produzione, permettendo quindi di accedervi durante la fase di congurazione, in cui viene scaricato sulla BCU il software desiderato; una volta tentato di resettare il device per ripristinare la congurazione iniziale, esso ha terminato di funzionare, rendendo impossibile qualunque 66
7 SoluzioniAdottate
tipo di accesso. Per quanto riguarda la tastiera Merten, invece, si sono riscontrati notevoli problemi, soprattutto dovuti al comportamento dei tasti; essi, seppur congurati per inviare comandi di ON e OFF, non si limitano solo a questo e con il loro operato inuenzano tutti i gruppi a cui appartengono, portando anche altri dispositivi al malfunzionamento o al funzionamento secondo un criterio dierente da quello stabilito. Maggiori considerazioni vengono apportate successivamente (sezione 7.2.1). Ogni dispositivo deve essere univocamente identicato da un indirizzo (sezione 5.1.2) che ne spieghi la posizione allinterno dellarchitettura (Tab. 7.1). DISPOSITIVO Ip Gateway Tastiera Merten Attuatore Merten Tastiera Abb Attuatore Abb Interfaccia Tasti Merten
Tabella 7.1.
INDIRIZZO 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6
Indirizzi sici dispositivi
In base alla suddivisione proposta si sono assegnati gli indirizzi singoli, sottolineando il fatto che ogni attuatore ha un unico indirizzo individuale, ma ad esso ` e necessario associare alcuni indirizzi di gruppo per permettere il comando delle utenze collegate. Se ci` non avvenisse e si comandasse lattuatore come elemento unico, o tutte le utenze su di esso attestate avrebbero un comportamento identico. Questo potrebbe soddisfare una particolare richiesta, ma non soddisferebbe casistiche pi` u generali, nelle quali occorre comandare ogni uscita singolarmente: per fare questo occorre inserire ognuna di esse in un gruppo dierente, in cui inserire a loro volta altrettanti tasti. Gli indirizzi sici permettono di identicare il dispositivo hardware, sulla cui BCU eettuare il download del software e dei parametri che ne permettano il funzionamento secondo quanto desiderato. Le utenze (luci e prese) ed i singoli tasti di una tastiera invece non hanno un indirizzo sico associato, ma sono raggiungibili tramite gli attuatori (i primi) e le tastiere Abb e Merten (i secondi); con essi si interagisce tramite indirizzo di gruppo, utilizzato dallHouse Manager. Nel caso in cui si voglia accendere la luce attestata come primo canale dellattuatore Abb, occorrer` inviare un comando di ON al gruppo di cui tale luce fa parte. Per a far ci` si pu` sia utilizzare uninterfaccia abbinata allHouse Manager, sia un tasto o o domotico (ovviamente appartenente al medesimo gruppo). 67
7 SoluzioniAdottate
Su taluni device vi sono canali ausiliari che permettono funzionalit` pi` evolute a u o solamente dierenti: essi non vengono congurati in questa sezione e risultano non operativi in quanto inutili al ne del lavoro di tesi. Inoltre, una loro attivazione si ` e rivelata a volte dannosa al funzionamento totale dellinstallazione. Visti i problemi riscontrati con lutilizzo degli apparati Merten, la stanza relativa risulta inutilizzabile e quindi ` stata trattata solamente la stanza Abb di seguito e congurata come room con il nome di valigia Knx (nella sezione 7.2.2 ` riportata e la congurazione realizzata); data la presenza di due prese, si ` pensato di abbinare e alle stesse un ventilatore (presa sx ) ed una radio (presa dx ) al ne di esemplicarne luso anche tramite esempio. Nella gura seguente (Fig. 7.7) viene presentata la congurazione logica (a sinistra) a cui corrispondono gli elementi presenti nella valigia (a destra).
Figura 7.7.
Corrispondenza oggetti software - device domotici (valigia Knx)
Si sottolinea che per mantenere operativo almeno un tasto Merten (ulteriori tasti come detto porterebbero ad un malfunzionamento totale dellinstallazione vista la congurazione attuale), si ` associato questo alla luce rossa della stanza. Tale e congurazione verr` trattata nel dettaglio nella sezione 7.2.1. a Oltre allindirizzo singolo, occorre congurare ogni device con un insieme di indirizzi di gruppo che permettano la comunicazione automatica con altri dispositivi.
7.2.1
Gruppi
Ogni gruppo presenta un minimo di 3 elementi: un tasto comando; unuscita attuatore; un canale di aggiornamento attuatore. 68
7 SoluzioniAdottate
Mentre il primo ed il secondo trovano spiegazione nella necessit` di collegamena to per permettere lattuazione del comando, occorre soermarsi maggiormente sul terzo oggetto. Esso serve per laggiornamento dello stato dellutenza e la sua comunicazione a tutto il gruppo. Se ci` non avvenisse non si potrebbe avere un comando o delle utenze da parte di pi` soggetti. Questo trova applicazione nel caso in cui vi u siano almeno due tasti che comandino ad esempio una luce: se uno dei due la accende, laltro deve essere in grado di spegnerla, ma per far ci` deve capacitarsi della o variazione di stato della luce o, in caso contrario, ne comanderebbe laccensione e solo successivamente lo spegnimento, intaccando la funzionalit` del sistema. a A questo si aggiunge il fatto che ` necessario che il tasto senta la variazione di stato, e in quanto lutenza ` pilotabile dallHouse Manager e quindi un comando inviato trae mite questo produce un cambiamento di stato che deve essere noto a tutto il gruppo, in particolare, al tasto. Nellinstallazione in oggetto sono stati creati i gruppi necessari al controlla da parte dellHouse Manager. Nel le di congurazione (sezione 7.2.2) infatti sono presenti tutti i device necessari al funzionamento della valigia; essi presentano per` una o particolarit` dierente rispetto ai dispositivi BTicino in quanto ogni device astratto a non corrisponde ad un device reale, ma al ruolo dello stesso allinterno di uno dei gruppi a cui ` associato. Una luce, ad esempio, non viene identicata ad alto livello e come uscita di un attuatore in quanto solo questultimo dispone di un indirizzo sico e quindi essa risulterebbe irraggiungibile semplicemente tramite identicazione con indirizzo singolo. Essa far` parte, come uscita di attuatore, di un gruppo in a cui saranno anche presenti un tasto che la pilota ed il canale per laggiornamento. Quando ad alto livello si comanda laccensione dellutenza, non viene inviato un telegramma allindirizzo singolo del destinatario perch inesistente, ma bens` al gruppo e interessato. Luscita dellattuatore eettuer` la commutazione dello stato delluscita a relativa e, tramite il canale di aggiornamento, tutti i partecipanti al gruppo verranno informati della variazione. Questa considerazione permette di capire la mancata corrispondenza tra device astratto e device sico: ad un device sico infatti possono corrispondere pi` device u astratti, uno per ogni gruppo a cui esso appartiene. Ci` comporta anche una mano cata corrispondenza tra numero di dispositivi reali e astratti, in quanto questi ultimi possono essere anche di gran lunga pi` numerosi dei primi. u Avendo la possibilit` di operare su di ununica stanza, contenente un attuatore a e 4 utenze (2 prese e 2 luci) si ` pensato di creare i gruppi in Tab. 7.2. e Come si pu` notare, risulta presente un gruppo (1/2/34 ) che permette di pio lotare tramite un unico tasto (tradizionale) entrambe le luci (verde e rossa). Tale gruppo risulta essere, ad alto livello, un device astratto che non corrisponde sicamente ad un dispositivo in quanto tale: sia la luce verde che quella rossa risultano gi` presenti come device astratti e come tali pilotabili separatamente. Laggiunta a 69
7 SoluzioniAdottate
Tastiera Abb (1 tasto) Presa sinistra Canale aggiornamento abbinato 1/2/2 Tastiera Abb (2 tasto) Presa destra Canale aggiornamento abbinato 1/2/3 Tastiera Abb (3 tasto) Luce verde Canale aggiornamento abbinato 1/2/4 Tastiera Abb (1 tasto) Tastiera Merten (tasto in basso a destra) Luce rossa Canale aggiornamento abbinato 1/2/34 Tastiera Tradizionale (1 tasto) Luci verde e rossa Canale aggiornamento (luce verde) Canale aggiornamento (luce rossa) 1/2/1
Tabella 7.2. Elenco gruppi nellinstallazione EIB/KNX
di questo ulteriore gruppo fa si che entrambe le utenze possano essere pilotate contemporaneamente tramite il tasto tradizionale abbinato. Non solo: tramite House Manager ` suciente interagire con il device astratto per riuscire ad interagire col e gruppo allo stesso modo del tasto a cui ` consentito il comando. e Per quanto riguarda il gruppo 1/2/4 occorre sottolineare come esso sia formato da due tasti comando: uno Abb ed uno Merten. Questo pulsante rappresenta lunico elemento Merten congurato durante questa installazione, a causa dei notevoli problemi che tale apparato pu` causare nella congurazione totale. o Il tasto del gruppo di cui sopra ` congurato per essere una copia fedele del tasto e Abb appartenente al medesimo gruppo, riuscendo a condividere con questultimo il comando dellutenza. Lestensione di tale considerazione e congurazione ad altri pulsanti della medesima tastiera, al ne di permettere il comando anche delle altre 3 utenze rimanenti, non ` stato possibile. Infatti, se vengono congurati altri tasti e Merten, tutte le tastiere presentano un comportamento totalmente anomalo: alla pressione dei tasti (siano essi Merten, siano essi Abb), sul bus vengono inviati comandi indecifrabili. E da sottolineare che il comportamento non avviene solamente per la tastiera Merten, ma che questa va ad inuenzare anche la tastiera Abb. Lipotesi che si pu` azzardare ` che la pressione dei tasti Merten causi un cambiao e mento di stato dellutenza (e dei relativi tasti appartenenti al gruppo), portandola 70
7 SoluzioniAdottate
in uno stato che non pu` essere semplicemente catalogato come ON o OFF. Da queo sto stato, qualunque tasto venga premuto (sia Merten sia Abb), non si riesce pi` a u tornare n` allo stato spento (OFF) n` allo stato acceso (ON) utilizzando solamente e e i tasti domotici. Solamente lHouse Manager risulta in grado di forzare la variazione allo stato desiderato. Dato che questa situazione porta ad un utilizzo non consono dellinstallazione, si ` e pensato di congurare solamente un tasto Merten ed assegnarlo al gruppo 1/2/4, dimostrando quindi linteroperabilit` di device di due marche diverse (tasto Merten a e attuatore Abb). Non si ` in grado, al momento, di permettere una dimostrazione e pi` valida, utilizzando un numero maggiore di tasti. u Lutilizzo della tastiera Merten, seppure limitatamente ad un solo tasto, permette inoltre limpiego del telecomando abbinato a tale tastiera; esso presenta semplicemente una serie di tasti a cui sono abbinati i corrispondenti tasti della tastiera. Nel caso preso in considerazione il pulsante del telecomando da cui si pu` comandare a o distanza lutenza risulta essere il numero 8. E possibile inserire numerosi altri gruppi, creandone ad esempio uno in cui siano presenti sia le prese sia le luci della stanza, assegnandogli quindi un ruolo di interruttore generale. Questo pu` sembrare a parole molto facile, ma comporta una o congurazione tramite ETS ed una successiva aggiunta di un device ttizio nel le di congurazione. Il primo passo risulta necessario in quanto occorre creare un nuovo gruppo a cui associare le opportune uscite degli attuatori, almeno un tasto e i relativi canali di aggiornamento degli attuatori stessi; lultimo passo permette allHouse Manager di operare con le due luci come se fossero ununica entit`. a Si potrebbe pensare di raggiungere il medesimo risultato creando un nuovo gruppo come contenitore di altri gruppi, una sorta di raggruppamento degli stessi in una entit` pi` generale. Questo non ` fattibile tramite ETS, in quanto ` possibile opea u e e rare con i singoli oggetti ma non con i gruppi: essi rappresentano gi` una sorta di a aggregazione e non ` possibile aggregare ulteriormente ci` che risulta gi` aggregato. e o a Una soluzione intermedia pu` per` venir attuata: lutilizzo di regole permetteo o rebbe di associare la pressione di un tasto allinvio di un comando ad un insieme di device. Considerando che si sta trattando con device astratti, siano essi ttizi o meno, risulta possibile raggruppare gruppi di utenze insieme, formando un ulteriore gruppo di granularit` pi` ampia, che permetta ad esempio di attivare/disattivare la a u stanza inferiore. Una volta congurata linstallazione con gli indirizzi di gruppo, occorre operare la medesima congurazione anche allHouse Manager (sezione 7.2.2), permettendo quindi linterazione tra rete domotica ed House Manager. 71
7 SoluzioniAdottate
Gruppi intervaligia Per dimostrare linteroperabilit` tra le due valigie collegate allHouse Manager e a valutarne leettiva capacit` di collegamento tra tecnologie diverse, si ` congurato a e opportunamente il sistema per permettere il comando di unutenza EIB/KNX da un tasto BTicino e di unutenza BTicino da un tasto EIB/KNX. Per fare questo si ` e dovuto ricorrere allutilizzo di regole di alto livello, che pilotassero e controllassero i comandi da e per lHouse Manager, riuscendo a catturare le informazioni necessarie allo scopo pressato. In realt`, le regole non agiscono direttamente sui comandi a inviati o ricevuti ma operano a livello di Intelligence Layer, trattando quindi con gli oggetti software ed i loro stati. Per vedere nella pratica come sono state congurate le regole e come esse agiscano ed operino, si rimanda al paragrafo 7.3.
7.2.2
HouseModel
Come spiegato nella sezione 6.1.1, occorre congurare opportunamente il le che rappresenta la casa al ne di permettere allHouse Manager di interagire correttamente con linstallazione. Per quanto riguarda i device inseriti per la valigia EIB/KNX, si ` reso necessario provvedere allinserimento dei necessari oggetti software secondo lo e schema presentato nella sezione 6.1.1. In esso ogni valigia corrisponde ad una stanza (room), a sua volta contenente un insieme di device. Il le di congurazione dellHouse Manager presentava gi` i dispositivi relativi alla a valigia BTicino e sono stati aggiunti quelli relativi alla valigia Knx, formando una nuova stanza (room).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
<ROOM> <NAME>valigia_Knx</NAME> <DESCRIPTION>Valigia KNX</DESCRIPTION> <DEVICE id="1/2/1" type="2" manifacturer="Knx"> <NAME>presa_sx</NAME> <DESCRIPTION>Riga 2 presa sinistra</DESCRIPTION> </DEVICE> <DEVICE id="1/2/2" type="2" manifacturer="Knx"> <NAME>presa_dx</NAME> <DESCRIPTION>Riga 2 presa destra</DESCRIPTION> </DEVICE> <DEVICE id="1/2/3" type="2" manifacturer="Knx"> <NAME>luce_verde</NAME> <DESCRIPTION>Riga 2 luce verde</DESCRIPTION> </DEVICE> <DEVICE id="1/2/4" type="2" manifacturer="Knx">
72
7 SoluzioniAdottate
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
<NAME>luce_rossa</NAME> <DESCRIPTION>Riga 2 luce rossa</DESCRIPTION> </DEVICE> <DEVICE id="1/2/34" type="2" manifacturer="Knx"> <NAME>luci_verde_e_rossa</NAME> <DESCRIPTION>Riga 2 luci rossa e verde</DESCRIPTION> </DEVICE> <DEVICE id="2/1/1" type="2" manifacturer="Knx"> <NAME>pulsante_trad_1</NAME> <DESCRIPTION>Interfaccia tasti, tasto 1</DESCRIPTION > </DEVICE> <DEVICE id="2/1/2" type="2" manifacturer="Knx"> <NAME>pulsante_trad_2</NAME> <DESCRIPTION>Interfaccia tasti, tasto 2</DESCRIPTION > </DEVICE> </ROOM>
Come introdotto precedentemente sono presenti 4 entry, le prime 4, che permettono allHouse Manager di riconoscere le 4 utenze della riga inferiore della valigia Knx, nel particolare le 2 prese e le 2 luci. A seguire, ` presente un device ttizio identicato da 1/2/34 il quale raggruppa e le luci verde e rossa. Tale gruppo inoltre viene abbinato ad un tasto della tastiera tradizionale (1 da destra) e permette di operare contemporaneamente su entrambe le utenze. Questo gruppo, per come ` stato creato, necessita una congurazione da e ETS: in esso compariranno il tasto comando, i due canali di output dellattuatore ed i rispettivi canali di aggiornamento ad essi legati. I successivi ultimi due device (2/1/1 e 2/1/2 ) verranno meglio spiegati nella sezione 7.3 in quanto necessitano dellappoggio di alcune regole.
7.3
Regole
Tramite il motore a regole presente nellHouse Manager (sezione 6.1.1) ` possibie le inserire funzionalit` evolute che risultino di interesse allutilizzatore; nel caso in a esame esse riguardano in particolare le interazioni intervaligia. Infatti, una volta congurati appositamente i vari device astratti, occorre impostare opportunamente anche alcune regole, per permettere che i comandi e le variazioni di stato relativi ad una valigia vadano ad inuire anche sullaltra: mentre lHouse Manager, in particolare lAbstraction Layer, si occuper` di provvedere allascolto e alla ricezione di ci` a o che avviene su una valigia, il motore a regole valuter` gli stati rilevati e, nel caso, a provveder` a sua volta a creare ulteriori comandi. a 73
7 SoluzioniAdottate
Vengono di seguito presentati alcuni esempi di congurazioni di regole per meglio spiegare quanto asserito precedentemente. Negli esempi riportati si far` riferimena to alla congurazione riportata in questa sezione, a cui eventualmente verranno aggiunte le variazioni necessarie quando richiesto.
7.3.1
Esempio base
In questo primo esempio viene presentata una regola molto semplice, per mostrare il lavoro del motore a regole evitando di confondere il lettore con una complessit` a che verr` presentata solo successivamente, una volta compreso il funzionamento di a base. Una regola come la seguente
1 <rule name="verdeON_rossaON"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_verde") 5 & device.getStatus().equalsIgnoreCase("ON") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("
valigia_Knx")
8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Knx.luce_rossa.ON"); 11 </java:consequence> 12 </rule>
realizza una funzionalit` del tipo: Se la luce verde ` accesa, allora accendi anche a e la luce rossa, con riferimento alle due luci della valigia EIB/KNX. Tale regola fa si che venga controllato lo stato della luce denominata luce verde e, nel caso in cui questa sia accesa, si provveda ad inviare un comando di accensione alla luce rossa. Pur essendo la regola molto semplice, si pu` notare come il test sulla condizione si o trasformi in un controllo sul nome del dispositivo controllato, il suo stato, il suo tipo e la stanza a cui appartiene. Nel caso in cui si voglia testare un ulteriore device in contemporanea (per realizzare un controllo tipo entrambi accesi), la parte relativa alla condizione aumenta di consistenza, ostacolando in parte la facile comprensione. Si sottolinea inoltre come tale regola permetta esattamente quanto asserito in precedenza e nessuna altra funzionalit`: se si volesse imporre un funzionamento identico a alle due luci, tramite regole, occorrerebbe inserire unulteriore regola, che imponga lo spegnimento della luce rossa quando quella verde assume lo stato OFF. Tale regola pu` essere scritta come o
74
7 SoluzioniAdottate
1 <rule name="verdeOFF_rossaOFF"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_verde") 5 & device.getStatus().equalsIgnoreCase("OFF") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("
valigia_Knx")
8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Knx.luce_rossa.OFF"); 11 </java:consequence> 12 </rule>
Bisogna prestare attenzione a regole di questo tipo in quanto, seppur semplici (e presentate con lo scopo di esemplicarne la redazione e lutilizzo), esse possono portare a false considerazioni e convinzioni. Le due regole precedenti permettono una corrispondenza tra lo stato della luce rossa e quello della luce verde; tale corrispondenza per` viene comandata da questultima luce e quindi nulla accade se a o variare di stato ` la luce rossa, in quanto nessuna delle due regole proposte presenta e alcuna considerazione su tale luce nella parte di condizione. Se si volesse far lavorare le due luci realmente in simbiosi tramite regole, occorrerebbe inserire altre due regole, in cui nella parte di condizione viene valutato lo stato della luce rossa e nella conseguenza viene comandata la luce verde di conseguenza.
7.3.2
Regole per comandi intervaligia
Prima di presentare le regole intervaligia, occorre riportare alcune righe del le di congurazione, relativamente ai dispositivi interessati per la valigia BTicino (luce 11 e luce 12 ).
1 2 3 4 5 6 7 8 9 10 11 12
<ROOM> <NAME>valigia_Bticino</NAME> <DESCRIPTION>la valigia Bticino</DESCRIPTION> <DEVICE id="11" type="2" manifacturer="BTicino"> <NAME>luce_11</NAME> <DESCRIPTION>la luce con indirizzo 11</DESCRIPTION> </DEVICE> <DEVICE id="12" type="2" manifacturer="BTicino"> <NAME>luce_12</NAME> <DESCRIPTION>la luce con indirizzo 12</DESCRIPTION> </DEVICE> ...
75
7 SoluzioniAdottate
13 14
... </ROOM>
Si pu` notare come, nella valigia denominata valigia Bticino, siano presenti i o device chiamati luce 11 e luce 12, corrispondenti a due uscite di un attuatore, non collegate a vere e proprie utenze, ma il cui stato pu` essere visualizzato grazie ad o un piccolo LED, di cui ogni uscita ` fornita. e Dallelenco device del le di congurazione dellHouse Manager (sezione 7.2.2) vengono presi in considerazione i seguenti gruppi, per la creazione di opportune regole per comando intervaligia: 2/1/1, contenente le luci luce 11 e luce 12 BTicino; 2/1/2, contenente le luci luce 11 e luce 12 BTicino e le luci luce verde e luce rossa EIB/KNX; Di seguito viene riportato parte del le di congurazione, nella parte interessata dai gruppi in questione.
1 2 3 4 5 6 7 8 9 10
... <DEVICE id="2/1/1" type="2" manifacturer="Knx"> <NAME>pulsante_trad_1</NAME> <DESCRIPTION>Interfaccia tasti, tasto 1</DESCRIPTION > </DEVICE> <DEVICE id="2/1/2" type="2" manifacturer="Knx"> <NAME>pulsante_trad_2</NAME> <DESCRIPTION>Interfaccia tasti, tasto 2</DESCRIPTION > </DEVICE> ...
Entrambi i gruppi permettono il comando di utenze da una valigia allaltra, ma il primo in particolare ` anomalo e viene spiegato qui di seguito. e Da EIB/KNX a BTicino In esso infatti, in fase di congurazione in ETS, ` stato inserito solamente un tasto e e nessuna uscita. Questo ` dovuto al fatto che la pressione di tale tasto viene e intercettata dallHouse Manager ed essendo abbinato ad un device ttizio (2/1/1 ), ma pur sempre un device, causa lo scatenamento di una regola, la quale provveder` a ad attuare il comando di due utenze BTicino, nel particolare le due luci (luce 11 e luce 12 ). In questo modo si riesce ad eettuare il primo comando intervaligia desiderato: da un tasto EIB/KNX si comanda unutenza BTicino. Lasserzione utilizzata pu` essere unespressione tipo o 76
7 SoluzioniAdottate
Se il 1 tasto della placca tradizionale ` nello stato ON, accendi le luci luce 11 e e luce 12 trasformata nella regola
1 <rule name="ITF_Knx_luci_11e12_ON"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("pulsante_trad_1") 5 & device.getStatus().equalsIgnoreCase("ON") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("valigia_Knx") 8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Bticino.luce_11.ON"); 11 house.handleCommand("valigia_Bticino.luce_12.ON"); 12 </java:consequence> 13 </rule>
Occorre inoltre utilizzare unulteriore espressione tipo: e Se il 1 tasto della placca tradizionale ` nello stato OFF, spegni le luci luce 11 e luce 12 per realizzare la regola duale alla precedente, trasformata a sua volta nella regola
1 <rule name="ITF_Knx_luci_11e12_OFF"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("pulsante_trad_1") 5 & device.getStatus().equalsIgnoreCase("OFF") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("valigia_Knx") 8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Bticino.luce_11.OFF"); 11 house.handleCommand("valigia_Bticino.luce_12.OFF"); 12 </java:consequence> 13 </rule>
Gruppo misto Il secondo gruppo invece realizza un gruppo che comanda in contemporanea 4 luci, le 2 BTicino (luce 11 e luce 12 ) e le 2 EIB/KNX (luce verde e luce rossa). Le regole 77
7 SoluzioniAdottate
per eettuare questo sono

<rule name="ITF_Knx_luci_11_12_sx_dx_ON"> 1 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("pulsante_trad_2") 5 & device.getStatus().equalsIgnoreCase("ON") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("valigia_Knx") 8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Bticino.luce_11.ON"); 11 house.handleCommand("valigia_Bticino.luce_12.ON"); 12 house.handleCommand("valigia_Knx.luce_verde.ON"); 13 house.handleCommand("valigia_Knx.luce_rossa.ON"); 14 </java:consequence> 15 </rule>
per laccensione e
<rule name="ITF_Knx_luci_11_12_sx_dx_OFF"> 1 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("pulsante_trad_2") 5 & device.getStatus().equalsIgnoreCase("OFF") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("valigia_Knx") 8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Bticino.luce_11.OFF"); 11 house.handleCommand("valigia_Bticino.luce_12.OFF"); 12 house.handleCommand("valigia_Knx.luce_verde.OFF"); 13 house.handleCommand("valigia_Knx.luce_rossa.OFF"); 14 </java:consequence> 15 </rule>
per lo spegnimento. Da BTicino a EIB/KNX Ultima considerazione per i gruppi intervaligia ` necessaria nel caso si desideri coe mandare laccensione e spegnimento di una utenza da parte di un tasto presente sulla valigia BTicino. A dierenza del caso inverso, non ` possibile congurare un e 78
7 SoluzioniAdottate
pulsante a vuoto, cio` senza abbinarlo ad alcuna utenza della medesima tecnoloe gia, in quanto ci` non lo rende operativo: una eventuale pressione dello stesso non o viene presa in considerazione e lHouse Manager non risulta in grado di captare la sua variazione di stato. Una soluzione che permetta il comando desiderato risulta essere quella di mantenere unaccoppiata tasto/utenza sulla valigia BTicino, utilizzando quindi un device astratto (in questo caso non ttizio) e poi, tramite regola, accendere/spegnere una luce EIB/KNX, che a sua volta pu` essere o meno pilotabile da tasti della valigia o stessa. Questultima caratteristica risulta interessante in quanto un eventuale cambio di stato imposto alla luce EIB/KNX deve essere captato per variare a sua volta il device astratto BTicino. Non viene riportata lesempio di regola in quanto molto simile ai precedenti. Regole per comandi intervaligia: loop Un interessante ulteriore esempio di interoperabilit` pu` essere quello di sfruttare il a o motore a regole e portarlo a creare dei loop di regole, imponendo stati precisi ad un insieme di luci, in seguito alla variazione degli stessi. Il motore a regole ` realizzato per evitare condizioni di stallo di questo tipo; esso e lavora a stati e se si trova nella condizione per cui una regola porterebbe ad una variazione che unaltra regola, al medesimo stato, provvederebbe ad annullare, allora opta per non attuare entrambe le regole. Ci` viene fatto in quanto si innescherebbe o proprio un loop in quanto entrambe le regole si troverebbero ad agire su un medesimo elemento (variabile interna del motore a regole) variandone il valore senza sosta. Un loop interno ` quindi impossibile da realizzare secondo quanto spiegato, in e quanto il motore a regole per primo ne impedirebbe lattuazione. Ci` detto, rimane o comunque possibile portare il motore a regole ad avviare uno o pi` loop esterni, cio` u e che non vadano ad incidere su variabili interne ma su elementi esterni. In pratica, nellesempio che segue, vengono prodotti opportuni comandi di accensione/spegnimento di luci i cui stati vengono valutati nella parte di condizione. Essendo queste esterne al motore a regole ed essendo il numero di stati possibili assumibili non conosciuto a priori dal motore, ci si aspetta che esso provveda ad attuare il loop e non fermarlo, in quanto incapace di riconoscerlo. Per rendere pi` interessante la condizione di loop si pu` inserire nellinsieme u o di utenze considerate luci delle diverse valigie, dimostrando come lHouse Manager operi con i device astratti di alto livello, indipendentemente dalla loro posizione nella rete e dalla tecnologia da essi utilizzata. Nellesempio riportato in seguito vengono utilizzate 3 luci: luce verde: luce verde della seconda linea della valigia EIB/KNX; 79
7 SoluzioniAdottate
luce rossa: luce rossa della seconda linea della valigia EIB/KNX; luce 11 : luce sul primo canale di uscita del primo attuatore della valigia BTicino; sui cui stati vengono applicate una serie di regole logiche. Tali regole vengono proposte abbinate al relativo codice per comprenderne meglio il funzionamento. e 1. Se la luce verde ` accesa, spegni la luce 11
1 <rule name="verdeON-11OFF"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_verde") 5 & device.getStatus().equalsIgnoreCase("ON") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("
valigia_Knx")
8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Bticino.luce_11.OFF"); 11 </java:consequence> 12 </rule>
2. Se la luce verde ` spenta, accendi la luce 11 e

1 <rule name="verdeOFF-11ON"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_verde") 5 & device.getStatus().equalsIgnoreCase("OFF") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("
valigia_Knx")
8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Bticino.luce_11.ON"); 11 </java:consequence> 12 </rule>
3. Se la luce 11 ` accesa, spegni la luce rossa e
80
7 SoluzioniAdottate
1 <rule name="11ON-rossaOFF"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_11") 5 & device.getStatus().equalsIgnoreCase("ON") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("
valigia_BTicino")
8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Knx.luce_rossa.OFF"); 11 </java:consequence> 12 </rule>
4. Se la luce 11 ` spenta, accendi la luce rossa e

1 <rule name="11OFF-rossaON"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_11") 5 & device.getStatus().equalsIgnoreCase("OFF") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("
valigia_BTicino") 8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Knx.luce_rossa.ON"); 11 </java:consequence> 12 </rule>
5. Se la luce rossa ` accesa, spegni la luce verde e

1 <rule name="rossaON-verdeOFF"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_rossa") 5 & device.getStatus().equalsIgnoreCase("ON") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase(" 8 9 10
valigia_Knx") </java:condition> <java:consequence> house.handleCommand("valigia_Knx.luce_verde.OFF");
81
7 SoluzioniAdottate
11 </java:consequence> 12 </rule>
6. Se la luce rossa ` spenta, accendi la luce verde e

1 <rule name="rossaOFF-verdeON"> 2 ... 3 <java:condition> 4 device.getName().equalsIgnoreCase("luce_rossa") 5 & device.getStatus().equalsIgnoreCase("OFF") 6 & device.getType()== 2 7 & device.getRoomName().equalsIgnoreCase("
valigia_Knx") 8 </java:condition> 9 <java:consequence> 10 house.handleCommand("valigia_Knx.luce_verde.ON"); 11 </java:consequence> 12 </rule>
Tali regole controllano lo stato di una delle 3 luci ed operano laccensione o lo spegnimento di unaltra tra quelle prese in considerazione. Partendo dal caso in cui esse siano tutte OFF, possono accadere 3 casi, a seconda dellordine con cui vengono considerate le regole. Considerando verosimile la valutazione delle regole in ordine, viene soddisfatta per prima la regola n 2, la quale causa laccensione della luce 11. Questo porta allutilizzo della regola n 3 che spegne la luce rossa (comando inutile dato che risulta gi` spenta); in seguito scatta la regola n 6 che a sua volta accende la luce verde. a Ci` causa lo spegnimento della luce 11, regola n 1 (accesa in precedenza), a cui o fa seguito lattuazione della regola n 4, che comanda laccensione della luce rossa. Ultimo passo necessario a dimostrare il loop ` dato dalla regola n 5, che spegne la e luce verde visto lo stato ON della luce rossa. A questo punto si ` ritornati allo stato iniziale, da cui si prosegue nuovamente e entrando in loop. Nella gura seguente (Fig. 7.8) sono presentati gli stati possibili delle 3 luci considerate, collegati da archi rappresentanti lattuazione delle regole di cui sopra. Per facilit` di visualizzazione gli stati sono stati rinominati nella forma 7.3 a identicativo luce.STATO relativamente alla luce che fa scattare la regola. 82 (7.3)
7 SoluzioniAdottate
Figura 7.8.
Schema loop con 3 luci
Nello schema precedente si pu` notare come la partenza con tutte luci spente o pu` portare allentrata nello stesso da 3 punti dierenti, ciascuno utilizzante un o cammino unico tra gli stati. Ci` che varia ` il ciclo minimo che porta alla creazione o e di loop, dovuto alla dierente partenza. Considerando gli stati in cui le luci risultano passare, i cicli minimi per ogni partenza possibile risultano essere: rossa.OFF -> verde.ON -> 11.OFF -> rossa.ON -> verde.OFF -> 11.ON -> rossa.OFF ; 11.OFF -> rossa.ON -> verde.OFF -> 11.ON -> rossa.OFF -> verde.ON -> 11.OFF ; verde.OFF -> 11.ON -> rossa.OFF -> verde.ON -> 11.OFF -> rossa.ON -> verde.OFF ; Considerando invece la sequenza di regole la cui condizione viene soddisfatta, i cicli minimi per ogni partenza possibile risultano essere: 6 -> 1 -> 4 -> 5 -> 2 -> 3 -> 6 ; 4 -> 5 -> 2 -> 3 -> 6 -> 1 -> 4 ; 2 -> 3 -> 6 -> 1 -> 4 -> 5 -> 2 ; 83
7 SoluzioniAdottate
Questo insieme di regole, oltre a permettere il loop citato, da anche dimostrazione dellutilizzo dellHouse Manager come gura di collegamento tra linstallazione BTicino e quella EIB/KNX. Da questa dimostrazione si evince la pericolosit` creata dai loop esterni in quanto a non rilevati e gestiti dal motore a regole. Occorre quindi prestare molta attenzione alla realizzazione delle regole, sia da parte della persona che congura la rete, sia da parte dellutente (se gliene viene data la possibilit`). a Questultimo caso ` molto sconsigliato, data la notevole competenza che gli viene e richiesta e/o la complessit` non banale di una guida che lo segua e lo aanchi nella a realizzazione delle regole, valutandone gli impatti sullintero sistema.
84
Capitolo 8 Conclusioni
In questo capitolo viene analizzato in maniera critica il lavoro svolto. In particolare ci si soerma sui risultati ottenuti una volta ultimato il prototipo, sulle dicolt` a e/o ritardi di realizzazione e sulla precisione dello stesso nellattuare ci` per cui ` o e stato progettato. Viene proposta inoltre una riessione sulla tesi portata a termine, valutando il lavoro fatto e proponendo eventuali modiche e/o implementazioni future.
8.1
8.1.1
Risultati ottenuti
Raggiungimento obiettivi
Con il completamento della congurazione del prototipo si ` riusciti a dimostrare e i principali due punti che erano stati pressati nel capitolo 3, cio` lintegrazione e di un driver nellHouse Manager al ne di permettere a questultimo linterazione con uninstallazione EIB/KNX e linteroperabilit`, tramite tale gateway, della rete a realizzata con quella preesistente della BTicino. In particolare si ` riusciti a dimoe strare, seppure con due installazioni minimali e con interazioni altrettanto basilari, come lHouse Manager possa essere la gura centrale che permette di non scegliere una specica tecnologia per la rete desiderata ma di scegliere i dispositivi necessari secondo le proprie esigenze e le capacit` di questi ultimi di realizzarle. Sar` il gaa a teway che realizzer` i collegamenti necessari al ne di permettere la comunicazione a e linteroperabilit` tra i dispositivi. a Tramite i gruppi intervaligia creati (sezione 7.3) si ` potuto dimostrare il comando e di utenze di una valigia tramite pulsanti dellaltra valigia e viceversa. Sebbene questo venga fatto tramite House Manager e verichi quindi quanto asserito in precedenza, occorre focalizzare la dierenza riscontrata nei due casi. Se si desidera comandare una luce, ad esempio, presente nella valigia BTicino tramite 85
8 Conclusioni
un tasto presente nella valigia EIB/KNX, ci` risulta facilmente realizzabile tramite o due semplici passi: inserimento del pulsante in un gruppo privo di utenze tramite ETS e realizzazione di una regola che si occupi di testare lo stato ON/OFF di tale gruppo e di propagarlo alla luce BTicino corrispondente, che non necessita di una particolare congurazione. Caso dierente si ha invece se si vuole realizzare laltro scenario, cio` il comando e della valigia EIB/KNX tramite pulsante BTicino. Mentre per la parte della prima tecnologia non vi ` alcuna dierenza rispetto a prima, eccezion fatta per la presenza e nel gruppo di riferimento della sola utenza senza abbinamento di un tasto, per la congurazione della componente BTicino interessata non si pu` operare specularo mente. LHouse Manager, al momento, non ` in grado di rilevare la pressione del e tasto se ad esso non ` associato un attuatore o comunque un dispositivo da pilotare, e appartenente alla rete BTicino. La soluzione in questo caso ` al contempo semplice e e dannosa: abbinare ugualmente il tasto al canale di un attuatore, permettendo quindi il comando di una luce BTicino al tasto BTicino. Questo permette la cattura della segnalazione da parte dellHouse Manager, il quale tramite una regola simile al caso precedente si occuper` di pilotare opportunamente lutenza EIB/KNX. a Tale soluzione risulta semplice in quanto non necessita di particolare complessit` a di congurazione, ma dannosa in quanto in Bticino ogni dispositivo pu` far parte al o pi` di 2 gruppi: inserire un canale come comandabile da un tasto solo per permettere u la cattura del comando di questultimo riduce gi` il numero di gruppi possibili ad a uno solamente. Essendo inoltre tale congurazione fatta con lo scopo di comandare unutenza di unaltra valigia, la possibilit` di comando della luce BTicino risulta a non richiesta, probabilmente inutilizzata, col risultato che lappartenenza del canale di output al gruppo non permette a tale canale di far parte di un altro gruppo, possibilmente pi` utile. u In BTicino infatti ogni dispositivo pu` essere congurato come appartenente a o due gruppi solamente: uno primario ed uno ausiliario, solitamente utilizzati il primo per permettere il comando di utenze tramite pulsante ed il secondo per permettere il collegamento ad esempio di sensori e determinati attuatori. Un esempio pu` essere il o seguente: si ` in presenza di 3 dispositivi (tasto, attuatore per motorino per nestre, e sensore pioggia) che necessitano di comunicare tra loro; lapertura e chiusura della nestra ` comandata sia manualmente tramite tasto, sia automaticamente tramite e sensore di caduta pioggia, il che impone al canale dellattuatore di essere presente in due gruppi. Ulteriore considerazione da fare, in particolare valutando il comportamento delle due reti domotiche, riguarda la velocit` di interazione con le medesime. La rete a EIB/KNX ` molto pi` reattiva della rete BTicino, aggiorna pi` velocemente le vae u u riazioni di stato ed altrettanto velocemente riesce ad attuare i comandi. Tale pregio non ` tanto dovuto ad una intrinseca velocit` quando ad una lentezza dellinterae a zione dellHouse Manager con laltra rete. Il Dispatcher (7.1.5) di tale rete infatti 86
8 Conclusioni
aggiorna gli stati operando in polling, rendendo quindi pi` lenti gli aggiornamenti e u le attuazioni di comandi. Il driver EIB/KNX invece non lascia eettuare laggiornamento degli stati al relativo Dispatcher, essendo impossibile al momento operare una lettura dello stato da rete, ma la delega ad un server apposito (KnxReader), il quale rimane in costante ascolto delle evoluzioni degli stati e si occupa di aggiornarne i corrispondenti oggetti software solo quando riceve dati in merito. Non operando in polling evita la monopolizzazione delle risorse, permettendo quindi una pi` veloce attuazione dei u comandi.
8.1.2
Problemi riscontrati
Innanzitutto occorre sottolineare che il prototipo non rappresenta uninstallazione operativa in tutte le proprie funzionalit`: come accennato durante la realizzazioa ne esso ` un banco di lavoro minimale, formato da utenze base comandabili in e maniera binaria (ON/OFF) ma che comunque necessitano una precedente congurazione tramite un apposito software, al momento unica possibilit` per compiere a tale operazione. Progettazione banco Durante la fase di progettazione del banco di lavoro sono stati riscontrati ritardi e dicolt` di comunicazione sia nei contatti sia nel reperimento di cataloghi e maa teriale informativo. Una prima barriera ` stata rappresentata dalla lingua madre e parlata dalla gran parte dei fornitori (tedesco), pur esistendo fornitori e rivenditori in Italia ed avendo EIB/KNX un respiro europeo. Un secondo problema ` stata la poca assistenza tecnica ricevuta, in particolare per i e dispositivi Merten e la dicolt` nelluso di ETS; questultimo ` stato utilizzato soa e lamente in una versione di prova, in quanto sia la versione completa del programma sia tutte le speciche del protocollo risultano liberamente consultabili, ma solo ai membri e/o partner del consorzio. Integrazione in House Manager Oltre che una barriera intrinseca del software di congurazione di EIB/KNX, vi sono stati almeno altri due problemi che hanno portato alla necessit` di trovare soa luzioni alternative: il mancato ricevimento di un ACK in seguito ad un comando e linstabilit` nella risposta in seguito ad interrogazione sullo stato di un dispositivo. a Entrambi i problemi sono stati risolti, o per meglio dire arginati dando per scontato che un comando venga ricevuto correttamente ed attuato dal relativo device e non eettuando alcuna lettura di stato. In particolare questultima soluzione comporta 87
8 Conclusioni
potenziali problemi di inconsistenza, ma tramite opportuno server in lettura (KnxReader, 7.1.3) vengono catturati i comandi che inuiscono sulla variazione di stato dei vari dispositivi, aggiornando quindi la copia locale dello stesso. Una lettura dello stato sarebbe consigliabile per sicurezza, ma anche in questo modo si riesce a far corrispondere correttamente le due entit`. a
8.2
Conclusioni
Al termine della realizzazione di questa tesi e valutando i risultati ottenuti si possono delineare alcune conclusioni.
8.2.1
Complessit` di EIB a
Il protocollo EIB/KNX utilizzato risulta molto complesso da diversi punti di vista, di seguito arontati. Architettura di rete Innanzitutto occorre sottolineare come EIB/KNX, presentato come standard europeo e possibile panacea nel campo domotico, in realt` non solo non lo sia, ma a risulti essere molto inadatto nellambiente della home automation. Esso infatti risulta trovare la sua naturale collocazione nel campo della building automation, vista soprattutto la notevole architettura di rete su cui ` basato. Anche se permette una e versione priva di uninfrastruttura complessa di rete, come visto nella realizzazione del prototipo in oggetto, EIB/KNX risulta palesemente creato per ambienti che necessitano una suddivisione in linee ed aree secondo quanto stabilito. Linnalzamento a 256 dispositivi per linea (rispetto a EIB) da una parte permette un utilizzo in ambito domestico tramite una singola linea (eliminando quindi parte dellinfrastruttura), ma dallaltra mostra anche la visione di grande respiro per cui EIB/KNX risulta maggiormente adatto, innalzando ad oltre 60.000 i dispositivi utilizzabili in una installazione.
Dispositivi Oltre ad una complessa infrastruttura possibile, EIB/KNX presenta anche un altro tipo di complessit`, forse maggiormente inuente, ricoperta dalla struttura logica di a ogni dispositivo; ognuno di essi infatti perde la propria gura di semplice apparato elettrico e diventa sede di quella intelligenza distribuita che caratterizza EIB/KNX. In ogni device (o nella relativa BCU su cui esso viene attestato) viene ricostruita la pila protocollare ISO/OSI, seppure accorpando taluni livelli. 88
8 Conclusioni
Lenormit` di applicazioni e funzioni disponibili, a seconda del costruttore, sui a device presenti in una rete pu` rendere anche molto costoso limpiego di uno di o essi: se gi` pu` sembrare dubbiosa lutilit` di ognuna di esse, il costo che si deve a o a sostenere per il suo acquisto incide pesantemente sul budget a cui si pu` attingere. o Tale costo rende alquanto proibitivo luso dei dispositivi EIB/KNX allinterno di una abitazione. In base allesperienza maturata durante il lavoro eettuato occorre inne sottolineare la dicolt` nel reperire gli opportuni software aggiornati relativi ad ogni a dispositivo. Spesso, ammesso di trovare quello necessario al funzionamento basilare del device, esso risulta essere redatto in lingua tedesca, con ben poche eccezioni per linglese e praticamente nessuna per litaliano. Congurazione La congurazione della rete EIB/KNX avviene via software tramite un apposito programma (ETS), unica possibilit` per chi desideri realizzare uninstallazione con tale a tecnologia domotica. Tale programma ` stato realizzato appositamente per questa e funzione ed ore, oltre alla (tuttaltro che) semplice congurazione visuale, anche una serie di supporti aggiuntivi per la gestione e la diagnostica dellinstallazione. Tale protocollo richiede dunque una gura aggiuntiva al semplice elettricista in grado di installare sicamente i dispositivi, poich` per la congurazione occorre necessariae mente utilizzare un PC dotato di apposita interfaccia verso il bus (Ethernet, USB, RS232), su cui sia installato un programma apposito (ETS), il quale, a sua volta, necessita una qual certa dimestichezza e conoscenza per essere utilizzato. Si viene cos` a scindere linstallatore dal conguratore, due persone, elettricista il primo, informatico o simile il secondo, che devono cooperare e convivere dove in altri casi (uno per tutti BTicino) ne bastava uno: il primo. Eettivamente ` possibile e che le due gure coesistano in ununica persona, ma questa necessita di competenze e certicazioni in entrambi i campi; usando una singola persona come gura di riferimento per entrambe le funzioni, essa risulta ricoprire un ruolo pi` informatico che u elettrico. Concludendo, EIB/KNX risulta essere un protocollo architetturalmente complesso, il cui campo di utilizzo dista dalla semplicit` richiesta nella home automation, a scenario di studio del caso in oggetto in questa tesi, dai costi non indierenti e dalla gestione tuttaltro che facile ed intuitiva. EIB/KNX altri non ` che il vecchio EIB leggermente ampliato e rivisto: sono stati e aggiunti alcuni mezzi trasmissivi, ereditati dagli altri protocolli rappresentati nel consorzio ed ` stato aumentato di gran lunga il numero di dispositivi inseribili in e uninstallazione, ma per la quasi totalit` delle altre caratteristiche sono direttamente a mutuate da EIB. 89
8 Conclusioni
8.2.2
Costi della domotica
Fintanto che non si raggiungeranno costi di produzione e quindi prezzi di vendita nettamente inferiori e si eettueranno economie di scala, il mercato della domotica in ambito domestico potr` rimanere unarea riservata solamente a coloro i quali non a abbiano problemi di disponibilit` monetaria. a Ci` sembra ragionevole se lutente che si considera ` normodotato ed in salute, o e ma risulta invece molto iniquo se questi ha forti limitazioni sico-mentali e tale tecnologia gli permetterebbe di essere pi` autosuciente in casa propria. u
8.2.3
Modiche ed implementazioni future
Valutando quanto realizzato sicamente e logicamente con il prototipo, possono scaturire suggerimenti per modiche ed implementazioni future. Per prima cosa il funzionamento parziale dei dispositivi della valigia suggerisce la ricerca di una soluzione al mancato funzionamento e relativo controllo dei device Merten, sia lattuatore, con problemi irrisolti di aggiornamento della BCU ad una versione precedente richiesta da ETS, sia la tastiera, che seppure congurata per inviare semplici comandi ON/OFF, in taluni casi invia comandi indecifrabili e complessi. Per un aumento delle performance risulterebbe utile riuscire ad impostare i dispositivi al ne di obbligarli allinvio dellACK e alla risposta quando interrogati, permettendo quindi di testare lo stato di un dispositivo tramite apposito comando ed avere una pi` adabile corrispondenza tra device astratto (nellHouse Manager) u e device reale presente nella rete. Pu` essere inne interessante valutare linserimento di una centralina allarmi o e/o meteo, formata da alcuni sensori analogici o digitali, quali ad esempio rilevatori di fumo, gas, acqua, rottura vetro, vento, pioggia, luminosit`, temperatura, per a realizzare scenari in cui si pu` dimostrare lutilit` di un meccanismo autonomo ed o a automatico in grado di provvedere a segnalare un pericolo o una variazione climatica importante ed eventualmente di prendere provvedimenti al ne di eliminare o arginare il pericolo oppure attuare scelte di comodit` (accensione luce se luminosit` a a insuciente, chiusura nestre in caso di pioggia, ...).
90
Bibliograa
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] http://it.wikipedia.org/wiki/Domotica http://www.domotics.com/ix domo.htm http://it.wikipedia.org/wiki/Gabbia di Faraday http://it.wikipedia.org/wiki/Diafonia http://www.cenelec.org/ http://www.fcc.gov/ http://www.irda.org/ http://www.bluetooth.com/ http://www.eia.org/ http://www.cebus.org/ http://www.jini.org/ http://www.echelon.com/developers/lonworks/default.htm http://www.echelon.com/ http://www.sun.com/ http://www.x10.com/ http://www.meti.go.jp/english/ http://www.reea.or.jp/ http://www.jeita.or.jp/eiaj/english/ http://www.echonet.gr.jp/english/index.htm http://www.batibus.com/ http://www.ehsa.com/ http://www.eiba.com/ http://www.konnex.org/ P. Pellegrino, D. Bonino, F. Corno, DOMOTIC HOUSE GATEWAY, SAC 2006, ACM Symposium on Applied Computing, April 23-27 2006, Dijon (France) http://www.myhome-bticino.it/web/home page.page/ http://tftpd32.jounin.net/ http://sourceforge.net/projects/eibcontrol/ http://labs.jboss.com/jbossrules http://elite.polito.it/ 91
[25] [26] [27] [28] [29]

Allione

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Allione

Uploaded by

Copyright:

Available Formats

POLITECNICO DI TORINO

III Facolt` di Ingegneria dellInformazione a

Tesi di Laurea Specialistica

Integrazione e Sperimentazione dello Standard EIB/KNX in Gateway Residenziali

Relatore: prof. Fulvio Corno Candidato: Enrico Allione

A chi, da quaggi` u e da lass`, u mi ha seguito ed aiutato

3 Obiettivi e motivazioni 18 3.1 Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 iv

Elenco delle tabelle

Elenco delle gure

Capitolo 2 Stato dellarte

Cavo coassiale (CX)

Twisted pair (TP) o doppino in rame

Fibra ottica (Optical Fiber - OF)

Linea di potenza (Onde convogliate, Power line, PL)

CENELEC: suddivisione frequenze

Dispositivi di output: attuatori

Pila protocollare ISO/OSI

Consumer Electronic Bus (CEBus)

Fino al 1997 nota come Electronic Industries Association

Denito nello standard ANSI/EIA 701.9-A-1999

Home Bus System (HBS)

European Home Systems (EHS)

European InstaBus (EIB)

Capitolo 3 Obiettivi e motivazioni

4.1) presenta principalmente 3 entit`: lInteraction Manager, lHouse Manager e la a casa.

Reti e dispositivi domotici

House Manager - struttura

Capitolo 5 Banco di lavoro EIB/KNX

Gerarchia e suddivisione in linee e aree

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

Topologia della rete EIB/KNX

5 Banco di lavoro EIB/KNX

Bus Coupling Unit - BCU

5 Banco di lavoro EIB/KNX

Architettura di comunicazione con bus

5 Banco di lavoro EIB/KNX

Struttura indirizzo individuale

5 Banco di lavoro EIB/KNX

Struttura indirizzo di gruppo

5 Banco di lavoro EIB/KNX

Eib Tool Software (ETS)

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

Frutti e loro inserimento

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

CONSUMO 22 mA < 12 mA < 10 mA < 10 mA < 60 mA

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

Merten Interfaccia a tasti

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

Valigia Manutan 1986Y57

5 Banco di lavoro EIB/KNX

5 Banco di lavoro EIB/KNX

MODULI OCCUPATI 1,5 1,5 4 5 12

Disposizione su guida DIN EN50022 - linea sinistra