Integrazione e Sperimentazione dello Standard EIB/KNX in...

POLITECNICO DI TORINO

III Facolta di Ingegneria dell’InformazioneCorso di Laurea in Ingegneria Informatica

Tesi di Laurea Specialistica

Integrazione e Sperimentazionedello Standard EIB/KNX in

Gateway Residenziali

Relatore:prof. Fulvio Corno

Candidato:Enrico Allione

Luglio 2007

A chi,da quaggiue da lassu,

mi ha seguitoed aiutato

ii

Ringraziamenti

Un sincero ringraziamento ai miei genitori ed alla mia famiglia, che mi hannopermesso di intraprendere il cammino universitario e di arrivare fino a qui.

Ringrazio il prof. Corno ed il gruppo ELITE per avermi dato la possibilita direalizzare questa tesi, con un lavoro sia teorico che pratico; in particolare ringraziol’ing. Bonino per avermi seguito ed assistito durante l’intera realizzazione di questatesi.

iii

Indice

Ringraziamenti iv

1 Introduzione 1

2 Stato dell’arte 42.1 Domotica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Mezzi Trasmissivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Cavo coassiale (CX) . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Twisted pair (TP) o doppino in rame . . . . . . . . . . . . . . 62.2.3 Fibra ottica (Optical Fiber - OF) . . . . . . . . . . . . . . . . 72.2.4 Linea di potenza (Onde convogliate, Power line, PL) . . . . . 72.2.5 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Dispositivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 Dispositivi di input . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Dispositivi di output: attuatori . . . . . . . . . . . . . . . . . 112.3.3 Dispositivi di sistema . . . . . . . . . . . . . . . . . . . . . . . 112.3.4 Interfacciamento . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Protocolli di comunicazione . . . . . . . . . . . . . . . . . . . . . . . 122.4.1 Consumer Electronic Bus (CEBus) . . . . . . . . . . . . . . . 132.4.2 Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.3 LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.4 X-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.5 Home Bus System (HBS) . . . . . . . . . . . . . . . . . . . . . 152.4.6 BatiBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.7 European Home Systems (EHS) . . . . . . . . . . . . . . . . . 162.4.8 European InstaBus (EIB) . . . . . . . . . . . . . . . . . . . . 162.4.9 KONNEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Obiettivi e motivazioni 183.1 Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iv

4 Architettura 20

4.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.1 Interaction Manager . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.2 Reti e dispositivi domotici . . . . . . . . . . . . . . . . . . . . 22

4.1.3 House Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Banco di lavoro EIB/KNX 25

5.1 EIB/KNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.1 Gerarchia e suddivisione in linee e aree . . . . . . . . . . . . . 25

5.1.2 Indirizzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Scelta componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.1 Materiale elettrico . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.2 Materiale domotico . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Montaggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3.1 Sezione layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3.2 Sezione centralino . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3.3 Collegamenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6 House Manager 53

6.1 Architettura interna . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.1 Intelligence Layer . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.2 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.3 Abstraction Layer . . . . . . . . . . . . . . . . . . . . . . . . . 57

7 SoluzioniAdottate 59

7.1 Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.1.1 KnxDispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.1.2 KnxWriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1.3 KnxReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1.4 KnxEncoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.1.5 Differenze con BTicino . . . . . . . . . . . . . . . . . . . . . . 63

7.2 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.2.1 Gruppi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.2.2 HouseModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.3 Regole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.3.1 Esempio base . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.3.2 Regole per comandi intervaligia . . . . . . . . . . . . . . . . . 75

v

8 Conclusioni 858.1 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.1.1 Raggiungimento obiettivi . . . . . . . . . . . . . . . . . . . . . 858.1.2 Problemi riscontrati . . . . . . . . . . . . . . . . . . . . . . . 87

8.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.2.1 Complessita di EIB . . . . . . . . . . . . . . . . . . . . . . . . 888.2.2 Costi della domotica . . . . . . . . . . . . . . . . . . . . . . . 908.2.3 Modifiche ed implementazioni future . . . . . . . . . . . . . . 90

Bibliografia 91

vi

Elenco delle tabelle

2.1 CENELEC: suddivisione frequenze . . . . . . . . . . . . . . . . . . . 85.1 Consumi apparati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Caratteristiche valigia . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3 Disposizione su guida DIN EN50022 - linea sinistra . . . . . . . . . . 475.4 Disposizione su guida DIN EN50022 - linea destra . . . . . . . . . . . 477.1 Indirizzi fisici dispositivi . . . . . . . . . . . . . . . . . . . . . . . . . 677.2 Elenco gruppi nell’installazione EIB/KNX . . . . . . . . . . . . . . . 70

vii

Elenco delle figure

2.1 Corrente alternata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Onda convogliata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Risultante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Pila protocollare ISO/OSI . . . . . . . . . . . . . . . . . . . . . . . . 124.1 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 House Manager - struttura . . . . . . . . . . . . . . . . . . . . . . . . 235.1 Topologia della rete EIB/KNX . . . . . . . . . . . . . . . . . . . . . . 275.2 Bus Coupling Unit - BCU . . . . . . . . . . . . . . . . . . . . . . . . 285.3 Architettura di comunicazione con bus . . . . . . . . . . . . . . . . . 295.4 Struttura indirizzo individuale . . . . . . . . . . . . . . . . . . . . . . 305.5 Struttura indirizzo di gruppo . . . . . . . . . . . . . . . . . . . . . . . 315.6 Eib Tool Software (ETS) . . . . . . . . . . . . . . . . . . . . . . . . . 325.7 Frutti e loro inserimento . . . . . . . . . . . . . . . . . . . . . . . . . 345.8 Gruppo prese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.9 Gruppo luci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.10 Tasti tradizionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.11 Interruttore differenziale . . . . . . . . . . . . . . . . . . . . . . . . . 365.12 Interruttore magnetotermico . . . . . . . . . . . . . . . . . . . . . . . 365.13 Attuatore Abb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.14 Attuatore Merten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.15 Gateway Abb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.16 Alimentatore Merten . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.17 Tastiera Abb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.18 Tastiera Merten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.19 Telecomando IR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.20 Merten Interfaccia a tasti . . . . . . . . . . . . . . . . . . . . . . . . . 425.21 Valigia Manutan 1986Y57 . . . . . . . . . . . . . . . . . . . . . . . . 455.22 Sezione layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.23 Sezione centralino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.24 Terminale di connessione bus . . . . . . . . . . . . . . . . . . . . . . 505.25 Topologia di rete in oggetto . . . . . . . . . . . . . . . . . . . . . . . 50

viii

5.26 Schema elettrico installazione . . . . . . . . . . . . . . . . . . . . . . 515.27 Valigia EIB/KNX ultimata . . . . . . . . . . . . . . . . . . . . . . . . 526.1 House Manager: schema a blocchi . . . . . . . . . . . . . . . . . . . . 546.2 Esempio di corrispondenza tra oggetti software e device domotici . . . 567.1 KnxDriver da inserire nell’Abstraction Layer . . . . . . . . . . . . . . 597.2 Driver BTicino e Knx . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.3 Struttura indirizzo di gruppo . . . . . . . . . . . . . . . . . . . . . . . 637.4 Pseudo-codice per il concatenamento di main e middle . . . . . . . . 637.5 Funzionamento BTicinoDispatcher . . . . . . . . . . . . . . . . . . . 647.6 Funzionamento KnxDispatcher . . . . . . . . . . . . . . . . . . . . . . 647.7 Corrispondenza oggetti software - device domotici (valigia Knx) . . . 687.8 Schema loop con 3 luci . . . . . . . . . . . . . . . . . . . . . . . . . . 83

ix

Capitolo 1

Introduzione

La tesi mira a definire metodologie per integrare, nel contesto di gateway residenzialiper edifici intelligenti, diversi sottosistemi domotici tra loro eterogenei e potenzial-mente incompatibili. Essa prevede lo studio dei dispositivi domotici esistenti e deirelativi protocolli di accesso, la definizione di opportune rappresentazioni e metodidi accesso astratti capaci di rappresentare in modo uniforme i vari dispositivi e l’im-plementazione di un prototipo dimostrativo che integri piu sottosistemi in un unicoambiente di controllo. Verranno trattati alcuni standard ad-hoc, per poi soffermar-si maggiormente su sistemi con protocollo OpenWebNet (BTicino) ed EIB/KNX,affrontando la loro integrazione nell’House Manager, gateway domestico in fase disviluppo presso il Politecnico di Torino. Il dimostratore sara composto da compo-nenti software e da un banco contenente dispositivi domotici.

La tesi e cosı strutturata: nel capitolo 2 viene introdotto il campo della domo-tica, con alcuni concetti e terminologie chiave al fine di delineare l’ambito in cui latesi va a collocarsi. Viene inoltre proposta una panoramica sugli standard e sul-le tecnologie domotiche attualmente presenti sul mercato mondiale, spiegando inparticolare le alternative a disposizione nel caso si voglia progettare e/o installareuna rete domotica. Termina con l’introduzione ad EIB/KNX, tecnologia scelta peril presente lavoro, la cui trattazione piu esaustiva e rimandata al capitolo successivo.

Nel capitolo 3 vengono spiegate ed argomentate le motivazioni che hanno portatoalla proposta ed alla realizzazione di questa tesi. Viene innanzitutto introdotto ilruolo dell’House Manager, pur lasciando una sua trattazione completa al capitolo 4ed in seguito viene spiegata la progettazione di un banco dimostrativo in grado diinteragire col gateway in oggetto. Chiariti i requisiti, vengono presentati gli obiettiviche ci si prefigge di raggiungere con questo lavoro.

1

1 – Introduzione

Nel quarto capitolo viene presentata l’architettura logica in cui si inserisce l’Hou-se Manager e, scendendo nell’opportuno livello di dettaglio, il driver EIB/KNX ne-cessario alla comunicazione con tale tecnologia.

Nel capitolo 5 vengono spiegati i passi necessari alla costruzione del banco dilavoro, dalla scelta dei componenti fino alla realizzazione fisica. Una volta definiti ilcontesto ed i requisiti da soddisfare, vengono motivate le scelte in fatto di dispositivie loro integrazione nel prototipo; essi vengono presentati nel dettaglio, mettendonein luce le caratteristiche sia positive che negative ed in seguito viene trattato il loromontaggio fisico sia a livello elettrico che domotico.

Il capitolo si conclude con la presentazione del prototipo ultimato, la cui confi-gurazione logica viene presentata nel capitolo 7.

Una volta chiariti gli obiettivi della tesi, nel capitolo 6 viene presentata l’archi-tettura dell’House Manager, soffermandosi sui moduli di cui si compone, al fine dicomprendere la sua funzione di collegamento tra differenti tecnologie domotiche edinterfacce. Astraendo ad alto livello la rete domotica come insieme di oggetti soft-ware co-operanti tra loro, esso favorisce la comunicazione tra divese reti domotiche.L’integrazione descritta consta di un modulo driver da inserire nel gateway che sioccupi di tradurre il linguaggio astratto ad alto livello, utilizzato dallo stesso, inmessaggi sulla rete domotica e viceversa.

Viene inoltre presentato uno schema rappresentante i moduli base necessari al-l’House Manager per comunicare con una rete domotica; tale schema viene affiancatoda una trattazione dell’interazione che i suddetti moduli devono avere sia tra loro,sia verso l’esterno, permettendo la configurazione ed il comando da parte dell’utente.

Il capitolo 7 tratta l’inserimento del driver necessario per la comunicazione con larete EIB/KNX; tale driver viene introdotto nell’Abstraction Layer dell’House Mana-ger, ove e gia presente quello per la rete BTicino. In seguito vengono evidenziate ledifferenze tra i due driver necessari alle due tecnologie, rimandando una discussionepiu esaustiva al capitolo 8.Nel capitolo 7 viene inoltre presentata la configurazione necessaria al funzionamentologico della rete in oggetto, spiegando i collegamenti e le motivazioni che hanno por-tato alle scelte effettuate. Inoltre, nel medesimo capitolo, si dimostra come il motorea regole interno all’House Manager possa essere utilizzato per garantire l’effettivainteroperabilita tra le installazioni BTicino ed EIB/KNX.

Nell’ultimo capitolo (8) viene analizzato in maniera critica il lavoro svolto. Inparticolare ci si sofferma sui risultati ottenuti una volta ultimato il prototipo, sul-le difficolta e/o ritardi di realizzazione e sulla precisione dello stesso nell’attua-re cio per cui e stato progettato. Viene proposta inoltre una riflessione sulla tesi

2

1 – Introduzione

portata a termine, valutando il lavoro fatto e proponendo eventuali modifiche e/oimplementazioni future.

3

Capitolo 2

Stato dell’arte

In questo capitolo si presenta il campo della domotica, effettuando una panoramicasui concetti chiave, sui mezzi trasmissivi e dispositivi impiegati e sugli standard at-tualmente presenti sul mercato. Si conclude introducendo EIB/KNX quale standardutilizzato nel lavoro svolto.

2.1 Domotica

La domotica e la disciplina che si occupa di studiare le tecnologie, atte a migliorarela qualita della vita degli esseri viventi, negli ambienti antropizzati.[1]

Il termine domotics (domotica in italiano) deriva dall’unione di domus e infor-matics [2] e pone la sua attenzione particolare sull’automazione della casa (homeautomation), intesa come integrazione di tecnologie dell’impiantistica tradizionale,magari pre-esistenti, con tecnologie innovative e di nuova installazione, al fine diottenere funzionalita maggiori e moderne, mirando a migliorare la qualita della vitadegli utilizzatori dell’edificio, il comfort, la sicurezza ed il risparmio energetico.

Tale integrazione e da intendersi come condivisione dell’informazione tra i variimpianti, permettendo quindi una riorganizzazione degli stessi in un unico sistema ingrado di coordinare le diverse funzionalita, permettendo da un lato l’indipendenzaoperativa dei vari impianti e dall’altro l’interoperabilita degli stessi. La presenza diun sistema coordinatore fornisce funzionalita aggiuntive e, in caso di guasto, “do-vrebbe” garantire che i vari sottosistemi continuino ad operare singolarmente, per-dendo quindi solamente quelle funzionalita aggiuntive rese possibili dall’integrazionedegli stessi.

Tali funzionalita aggiuntive possono essere potenzialmente molte e complesse:se in un contesto di impianti isolati un dispositivo puo comunicare solamente condispositivi del suo impianto o addirittura con un solo particolare dispositivo, in uncontesto multifunzione si puo avere un sensore piuttosto che un interruttore in grado

4

2 – Stato dell’arte

di dialogare con apparati non prettamente rientranti nel suo ambito. Si pensi adesempio ad un rilevatore di gas che non solo sia collegato con un avvisatore acusticoma che permetta anche l’apertura della finestra per aerare il locale e l’invio di unsms ad un numero telefonico prestabilito.

Un concetto simile all’home automation e quello di building automation, il qua-le concerne l’automazione degli edifici intesi di grosse dimensioni o comunque conun uso ben specifico, si pensi ad esempio all’ambito residenziale (alberghi), socio-assistenziale (ospedali, cliniche, scuole, uffici), produttivo (fabbriche e industrie) ocommerciale (centri commerciali). I due tipi di automazione sono nati in perio-di diversi, per esigenze diverse e si rivolgono ad utilizzatori differenti: mentre labuilding automation si rivolge prevalentemente ad operatori professionali, tecnici egestisce funzionalita piuttosto complesse, la home automation gestisce un ambientedomestico e fornisce servizi a persone che, molto spesso, non sono solite utilizzareun personal computer e quindi deve disporre di interfacce utente semplici, facili dautilizzare senza una competenza tecnica specifica.

2.2 Mezzi Trasmissivi

I mezzi trasmissivi utilizzati per collegare i vari dispositivi possono essere differenti,non solo da installazione ad installazione, ma anche all’interno di una stessa installa-zione. La scelta e fatta in base all’estensione della rete, alla sua topologia, all’analisidell’ambiente in cui essa va ad inserirsi, alla distanza tra i dispositivi e all’utilizzoche si intende effettuare dell’installazione considerata o parte di essa.

2.2.1 Cavo coassiale (CX)

Il cavo coassiale e formato da un conduttore in rame, rivestito da uno strato inplastica che ne garantisce l’isolamento con un ulteriore strato metallico intrecciatoesterno il cui compito e contenere i disturbi esterni (gabbia di Faraday1 [3]) e dimi-nuire le interferenze. Il suo utilizzo tipico avviene nella trasmissione a distanza didati digitali, piu sensibili a rumori e distorsioni rispetto ai dati analogici. Il vincolodell’utilizzo di questo tipo di cavo risiede nella contenuta distanza a cui possonotrovarsi i dispositivi senza utilizzo di apparati di rete appositi che prendono il nomedi repeater, il cui compito e rigenerare il segnale ricevuto e ritrasmetterlo in uscita.Essi non possono essere sostituiti banalmente con semplici amplificatori in quantoverrebbe non solo amplificato il segnale ma anche il rumore e la distorsione.

1Con gabbia di Faraday si intende qualunque sistema costituito da un contenitore in mate-riale elettricamente conduttore (o conduttore cavo) in grado di isolare l’ambiente interno da unqualunque campo elettrostatico presente al suo esterno, per quanto intenso questo possa essere.

5


La resistenza all’interferenza presenta pero una bassa “maneggevolezza” dovutaalla rigidita del rivestimento in metallo, che lo rende poco pratico in ambienti ristrettie confinati e soggetto a rotture meccaniche; risulta inoltre costoso e difficile darealizzare.

Il campo di applicazione solito e la trasmissione di segnali video.

2.2.2 Twisted pair (TP) o doppino in rame

Il twisted pair e costituito da una coppia di fili di rame ritorti secondo un processochiamato binatura che permette di far agire i campi elettromagnetici esterni in egualmisura su entrambi i cavi. Utilizzando inoltre tecniche di trasmissione differenzialesi puo ridurre il rumore, sfruttando il fatto che esso agisce su entrambi i cavi e vienead annullarsi nell’operazione di differenza fatta dal ricevitore.

Il twisted pair e formato da 4 coppie di fili colorati, ognuna avente una frequen-za di binatura differente per permettere di ridurre il fenomeno della diafonia2. Ildoppino puo essere schermato (Shielded Twisted Pair [STP] ) oppure non schermato(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, classificati secondo la velocita ditrasmissione e l’uso. 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 fino a 16 MHz

• Categoria 4: reti locali fino a 10 Mbps

• Categoria 5: reti locali fino a 100 Mbps

• Categoria 5e: reti locali fino a 1 Gbps

• Categoria 6: reti locali fino a 1 Gbps (qualita migliore di Cat. 5e)

• Categoria 7: reti fino a 600-700 Mbps

2Con diafonia si intende il fenomeno per cui vi e un passaggio, in maniera capacitiva o induttiva,di energia da una linea ad un’altra (piu precisamente da un circuito ad un altro) [4]

6


2.2.3 Fibra ottica (Optical Fiber - OF)

La fibra ottica e formata da un filamento di materiale vetroso in grado di condurrela luce, rivestito da uno strato protettivo che lo isola dall’esterno. La trasmissioneavviene sfruttando i principi dell’ottica e consiste in un trasferimento di luce e nondi segnali elettrici come nei casi visti in precedenza, eliminando quindi i disturbidovuti all’interferenza elettrica.

La fibra ottica permette un collegamento ad alta velocita, a distanze molto eleva-te ed e impiegata maggiormente nelle dorsali di comunicazione. Il suo utilizzo nellabuilding automation puo trovare motivazione nelle tratte dorsali, di collegamento adesempio tra piu edifici di un comprensorio, ma risulta eccessiva per connessioni inambito residenziale. La breve spiegazione e fatta per completare la panoramica deimezzi 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) acui si aggiunge un basso voltaggio modulato (3-148 KHz, Fig. 2.2) che non va adinfluire significativamente 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 affinche questi possano essere opportunamente separati infase di ricezione. Questo mezzo trasmissivo permette di raggiungere, ovviamente,qualunque dispositivo che sia collegato alla rete elettrica, oltre ad evitare la posa diuna nuova infrastruttura.

La regolamentazione delle frequenze utilizzate e affidata per l’Europa al ComitatoEuropeo per la Standardizzazione Elettrica (CENELEC) [5] e per il nord America

7


Figura 2.3. Risultante

al Federal Communications Commission (FCC) [6]. Il CENELEC ha stabilito regoledi suddivisione delle frequenze, riportate in Tabella 2.1

FREQUENZE ACCESSO UTILIZZO3 - 95 KHz Riservato Fornitori energia elettrica

95 - 125 KHz Libero Sistemi domotici125 - 140 KHz RegolamentatoCELENEC Sistemi domotici

140 - 148,5 KHz Riservato Allarmi e Sicurezza

Tabella 2.1. CENELEC: suddivisione frequenze

Le velocita raggiungibili in Europa sono nell’ordine di alcuni Kbps (fino a circa5,4 Kbps) da rispettare per lo standard, anche se velocita superiori sono tecnica-mente raggiungibili ma non necessarie (trasmissione audio/video esclusa).

2.2.5 Wireless

La tecnologia di trasmissione senza fili (dall’inglese wireless) si suddivide principal-mente tra infrarosso e radiofrequenza a seconda della banda di frequenza impiegata.L’importante caratteristica e data dall’assenza di fili, che permette una maggio-re mobilita dei dispositivi, dei suoi utilizzatori ed una maggiore comodita d’uso.Inoltre, nel caso in cui non si possano posare cavi, risulta essere di fondamentaleutilita. Tra gli svantaggi occorre annoverare sicuramente l’interferenza di trasmis-sione, la difficolta nel superare barriere fisiche e strutturali e la distanza limitata trai dispositivi.

Raggi Infrarossi (IR - Infrared Rays) Utilizza l’infrarosso (lunghezza d’ondamaggiore della luce visibile e minore delle onde radio) e necessita di un campo apertoe privo di ostacoli non trasparenti tra trasmettitore e ricevitore. Trova impiego nellatermografia ma anche nella comunicazione, ad esempio tra telecomando e TV perevitare le interferenze delle onde radio del segnale televisivo. La radiazione infrarossaviene emessa da diodi (detti anche LED luminosi) e messa a fuoco da lenti in plastica;

8


in seguito viene modulata assegnandole informazione ed inviata. Il ricevitore traducecon un fotodiodo la radiazione infrarossa in corrente elettrica e da qui viene estrattal’informazione originale.

Standardizzato da IrDA (Infrared Digital Association, 1994) [7] per comunica-zioni punto-punto entro il metro e velocita fino a 4 Mbps.

Radiofrequenza (RF - Radio Frequency) La radiofrequenza utilizza onde ra-dio per la trasmissione e ricezione dei segnali la cui lunghezza d’onda supera quelladell’infrarosso. La porzione dello spettro elettromagnetico e ampia e a seconda delcampo di applicazione, esso si puo suddividere in fasce. La radiofrequenza e utiliz-zata in campi di uso comune quali radio e TV, ma in particolare per gli usi che sene possono fare in campo domotico risultano importanti le frequenze dai 300 Hz ai30 GHz. Una tecnologia diventata famosa e di uso sempre piu frequente al giornod’oggi e il Bluetooth.

Il Bluetooth e stato standardizzato dall’omonimo consorzio [8] nato nel 1988dalla cooperazione tra grandi societa operanti nel campo della telefonia3. Esso per-mette tramite collegamento radio a 2.4 GHz la comunicazione ad un massimo di 1Mbps tra dispositivi nel raggio di alcune decine di metri4. I dispositivi compatibiliBluetooth superano una fase di test da parte del consorzio ottenendo il marchio dicertificazione e quindi sono per definizione interoperabili tra loro. Un esempio dicollegamento Bluetooth puo essere quello tra cellulare e PC o tra cellulare ed aurico-lare. Per permettere sicurezza del canale, il Bluetooth utilizza lo FHSS (FrequencyHopping Spread Spectrum)5 la cui sequenza di salti e conosciuta solo ai dispositiviappartenenti alla comunicazione in oggetto, rendendo quindi “ardua” l’intrusione diapparecchiature estranee.

2.3 Dispositivi

La rete domotica e solitamente strutturata a bus e comprende due tipi di linee, unadi potenza che alimenta i vari dispositivi presenti e una di controllo/comando chegestisce gli apparati permettendo loro la comunicazione. Mentre la linea di potenza ecostituita dai classici tre cavi (fase, neutro e terra), la linea bus puo essere realizzatautilizzando vari mezzi trasmissivi descritti in precedenza sia nella totalita della rete,sia in partizioni di essa. In quest’ultimo caso si rende opportuno l’impiego di gatewayo dispositivi che si occupino di operare il collegamento e la comunicazione tra retinon omogenee.

3IBM, Toshiba, Intel, Nokia, Ericsson4Maggiori distanze significano antenne + potenti (fino a 20 dB) e piu probabilita di interferenza

con le reti 802.11b5Tecnica che prevede l’impiego di sequenze di frequenze tra le quali saltare

9


Esistono differenti 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 piu complesse (ad esempio EIB/KNX), introduconoun’ulteriore dispositivo tra il bus e il dispositivo vero e proprio, con il compitodi accoppiare quest’ultimo 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 rilevareo misurare grandezze dell’ambiente esterno e segnalare eventuali variazioni per lequali sono stati impostati. Generalmente hanno due soglie, una inferiore ed unasuperiore e possono essere settati per avvisare in caso di superamento di anche solouna delle due. L’avviso consiste in una segnalazione alla rete, la quale provvederaad avviare le opportune procedure richieste, oppure nell’invio di un comando ad unparticolare dispositivo precedentemente settato.

I sensori possono essere usati in ambiti diversi e per motivazioni differenti: sipensi ad un sensore che rilevi la quantita di gas presente in un ambiente (cucina),ad uno che rilevi la velocita del vento e ad uno che rilevi i movimenti. Uno stessosensore puo avere non necessariamente un unico utilizzo. Il sensore che rileva ilmovimento puo essere usato per accendere una luce al passaggio di una persona edagevolare cosı il suo cammino evitando che questa debba azionare un interruttoremanuale, ma puo anche azionare un allarme nel caso in cui il suo compito sia quellodi rilevare delle presenze ostili e non previste in un determinato ambiente.

I sensori possono essere inseriti direttamente sulla rete oppure essere collegatiad una centralina (allarmi, meteo, ...), la quale provvedera, al ricevimento della se-gnalazione, ad avviare le opportune procedure ed azionare eventuali altri dispositivi(sirene, motori, luci, ...), oppure semplicemente ad immagazzinare i dati rilevati peranalisi ed usi futuri.

In questa categoria ricadono anche gli interruttori ed i pulsanti comunementeusati nelle abitazioni e collegati con la rete domotica tramite opportune interfacce.La differenza tra interruttori e pulsanti risiede nello stato che possono assumere:mentre i primi possono avere due stati (generalmente ON e OFF), i pulsanti han-no uno stato solo. La pressione di questi determina, previa configurazione piu omeno complessa a seconda delle reti, una variazione dello stato dei dispositivi a

10


cui essi sono stati legati in fase di configurazione. La segnalazione su rete avvienedapprima all’attuatore ed in seguito al carico, in quanto quest’ultimo verra pilotatodall’attuatore a cui e collegato.

2.3.2 Dispositivi di output: attuatori

Gli attuatori hanno il compito di realizzare (attuare) un comando. Ricevono i co-mandi dalla rete e provvedono ad effettuarli sulle uscite corrette a cui sono collegatii carichi elettrici. A seconda del tipo di uscita l’attuatore si comporta in mododifferente:

• binaria: l’uscita viene attivata e disattivata tramite rele o circuito equivalente;

• dimmer: tramite un regolatore elettronico regola la tensione o la corrente perpilotare il carico;

• analogica: fornisce corrente o tensione variabile per comandare uscite “nonintelligenti”.

Inoltre gli attuatori si differenziano ancora a seconda del numero e tipologiadi carichi collegabili (induttivi, resistivi, ...), del massimo carico collegabile e dellaforma (montabile a incasso o su modulo DIN EN500226).

2.3.3 Dispositivi di sistema

In questa categoria rientrano dispositivi necessari per la realizzazione, il controlloe la gestione della rete. Alcuni dispositivi, quali ad esempio l’alimentatore, sononecessari e senza di essi qualunque sistema non sarebbe operativo, mentre altridiventano necessari solo in talune reti o tipologie.

L’alimentatore fornisce energia elettrica ai dispositivi connessi al bus; tali dispo-sitivi solitamente operano con tensioni variabili dai 12 V ai 30 V. Esso e posizionatonormalmente dentro il quadro generale e puo essere utilizzato singolo o con altrialimentatori a seconda di quanti ne vengano richiesti dalle specifiche del sistema.Generalmente due fattori che influenzano il numero di alimentatori utilizzati sonola quantita di dispositivi impiegati sulla rete e la massima distanza tollerata deglistessi dall’alimentatore.

Altri dispositivi utili soprattutto in reti di dimensioni considerevoli sono i dispo-sitivi di accoppiamento del bus, il cui scopo e ampliare la porzione di rete, colle-gando due sottoreti eventualmente con mezzi trasmissivi diversi. Si puo parlare diripetitori, accoppiatori, gateway o utilizzare nomenclature piu specifiche.

6Deutsches Institut fur Normung e.V. - German Institute for Standardization: standard tedesco,ora mondiale, per il montaggio di apparecchi elettrici sull’omonima apposita guida.

11


2.3.4 Interfacciamento

Compito di questi dispositivi e permettere il dialogo tra la rete e l’esterno, ad esempioun personal computer. Tali interfacce da una parte operano il collegamento sul buse dall’altra offrono una porta USB, RS232 oppure una presa di rete a cui collegareil pc. Tramite opportuni pacchetti software e possibile visualizzare la rete domoticaed operare su di essa.

2.4 Protocolli di comunicazione

Nella presentazione della domotica una parte rilevante e costituita dal protocollo dicomunicazione tra i vari dispositivi. Questo caratterizza una determinata installa-zione e puo essere molto differente da altri protocolli presenti in altre realta. Moltidi questi seguono un modello ISO/OSI (Fig. 2.4), con la relativa suddivisione in 7livelli.

Figura 2.4. Pila protocollare ISO/OSI

La potenzialita dell’utilizzo di tale modello e la possibilita di permettere un’in-terconnessione tra livelli omogenei presenti in dispositivi di reti differenti. Talecomunicazione puo essere effettuata grazie ad apparati particolari, detti general-mente gateway, il cui compito e quello di realizzare un ponte tra due installazionidifferenti ma comunque simili. Data la complessita del modello ISO/OSI si assistesolitamente ad una non-implementazione dei livelli dal 3 al 6, ed inglobazione deglistessi nei livelli adiacenti (2 e 7), permettendo una minore complessita ed un minorcosto di implementazione.

12


I primi standard nacquero quando organizzazioni operanti sul mercato domoticocercarono di creare uno standard unico al fine di favorirne la crescita e lo sviluppo.Dato che a tale processo non aderı la totalita delle aziende, non ebbe il successodesiderato e si assistette al proliferare di differenti standard.

Con il passare degli anni sono stati effettuati ulteriori tentativi, ma a tutt’ogginon esiste ancora uno standard unico e globale, sebbene vi siano associazioni natecon lo scopo di creare a livello locale quell’unificazione che non si e riusciti a crearea livello mondiale.

Considerando le tre principali aree geografiche mondiali (America del Nord, Eu-ropa e Giappone) viene presentata una suddivisione dei vari standard e dei tentatividi 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] e anche noto come EIA-600 ed e stato sviluppato dall’americana EIA(Electronic Industries Alliance)7 [9] nel 1992, in seguito ad un lavoro di sei anniper cercare di migliorare e ampliare le capacita dell’allora standard de facto X-10 (sezione 2.4.4). CEBus e uno standard integrato multimediale per i sistemidi automazione domestica, presenta caratteristiche quali flessibilita e modularita,ma non risulta molto diffuso. I dispositivi che lo utilizzano devono possedere unapotenza di elaborazione non minimale per gestire tutti i dati in transito sulla rete.

Inizialmente supportava solamente linee di potenza, mentre in seguito e statopermesso l’utilizzo di cavi coassiali, raggi infrarossi, frequenze radio e fibre ottiche.

2.4.2 Jini

“Jini technology is a service oriented architecture that defines a programming modelwhich both exploits and extends Java technology to enable the construction of secure,distributed systems consisting of federations of well-behaved network services andclients.” [11]

Prodotto dall’americana Sun [14], prende il suo nome dall’arabo jini il cui signifi-cato e mago, per evidenziare la sua capacita di autoconfigurazione. Ogni dispositivoconnesso alla presa di rete viene inserito in un registro contenente tutti gli apparati

7Fino al 1997 nota come Electronic Industries Association

13


presenti, permettendo che ogni device riesca a venire a conoscenza di qualunquealtro device presente nella rete.

Jini e basato sul concetto di servizio: ogni apparato fornisce servizi al resto dellarete (o comunita) tramite una propria interfaccia attraverso cui e possibile accertarnel’affidabilita e la compatibilita con altri servizi. A sua volta ogni dispositivo puoutilizzare i servizi messi a disposizione da altri apparati, andando cosı a formare unarete articolata dalle funzionalita complesse.

Quando si rende necessario comunicare con un dispositivo, tramite un servizio diricerca viene individuato il destinatario e da esso il richiedente scarichera il codiceJava necessario per la comunicazione. Punto fondamentale di tutto cio e l’estensioneal modello di sicurezza di Java che permette l’esecuzione sicura di codice scaricatodalla rete.

Il modello originale di sicurezza Java e basato sulla localita, per cui ogni appletscaricata puo accedere solamente ai servizi messi a disposizione dal dispositivo dacui essa e stata scaricata. Ogni servizio inoltre gestisce una lista di controllo che nespecifica gli utilizzatori. L’utilizzo del servizio e effettuato tramite il meccanismodetto leasing, che rappresenta una concessione a tempo sull’uso del servizio. Esi-stono due tipi di leasing, quello esclusivo, che permette ad un unico componentedi utilizzare il servizio e quello condiviso, che permette ad una lista di fruitori diaccedervi ed utilizzarlo.

2.4.3 LonWorks

LonWorks [12] e un tipo di rete creato nel 1988 dalla Echelon Corporation [13]. E’stato studiato per l’automazione industriale, di grandi complessi e di aerei. Ha costirelativamente alti, anche se il principale fornitore di energia elettrica in Italia hainstallato milioni di contatori elettrici compatibili con questo standard.

Il protocollo che utilizza prende il nome di LonTalk8 e si basa sull’intelligenzadistribuita e su una rete aperta, in cui ogni applicazione puo interagire con un’altrasenza bisogno di un controllo o di una intermediazione gerarchica. I protocolli nonsono 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 NeuronChip (costruito da Toshiba, Cypress e Motorola) che implementa tali protocolli edil sistema si completa con Lonworks Network Service (LNS), il sistema operativoper la connessione e lo sviluppo della rete dei dispositivi di controllo, permettendol’installazione, la configurazione ed il monitoraggio della rete di controllo LonWorks.Il server LNS supporta a livello di trasporto sia il protocollo LonTalk che TCP/IP.

8Definito nello standard ANSI/EIA 701.9-A-1999

14


2.4.4 X-10

X-10 [15] e nato nel 1976 con comunicazione monodirezionale da dispositivi di co-mando ad attuatori e solamente due anni piu tardi viene aggiornato (X-10-Pro)permettendo anche la lettura dello stato di un dispositivo e rendendo bidirezionalela comunicazione.

Il mezzo fisico di trasmissione utilizzato e costituito dalle onde convogliate sullarete elettrica tradizionale e la velocita di trasmissione e molto bassa. Negli USA ovee nato utilizza la rete elettrica 120 volt a 60 Hz, mentre in Europa quella 220 volt a50 Hz.

Ogni apparato viene identificato da una lettera (A-P) e da un numero (1-16) equindi permette di collegare fino a 256 dispositivi o gruppi di dispositivi. Il trasmet-titore e una unita centrale che invia comandi a dispositivi periferici, ma il sistemapuo essere controllato e comandato da telecomandi ad infrarossi o computer.

Principalmente diffuso negli Stati Uniti, ha trovato anche un suo utilizzo inEuropa e, grazie alla presenza di numerosi dispositivi disponibili sul mercato, abasso costo e alla semplicita di installazione, ha una posizione di rilievo tra glistandard attualmente usati.

2.4.5 Home Bus System (HBS)

HBS e frutto di un progetto congiunto di tre diversi soggetti giapponesi: Ministry ofInternational Trade & Industry (MITI) [16], Radio Engeneering & Electronics Asso-ciation (REEA) [17] e Electronic Industries Association of Japan (EIAJ) [18]. Oltre aquesti colossi, al progetto hanno partecipato anche alcune tra le maggiori compagniegiapponesi del settore, fornendo un enorme apporto di capitali di investimento.

Standardizzato nel 1986 dopo cinque anni di ricerca, ha subito un’ulteriore inno-vazione quando un anno piu tardi e stato proposto Super-HBS, per allargare l’usodi HBS ad un’utenza condominiale. Per renderlo accessibile dall’esterno inoltre estato sviluppato nel 1997 un gateway HBS/ISDN.

Utilizza due cavi coassiali e otto cavi twisted pair e permette il collegamento diapparati audio, video e telefonici.

Risulta l’unico standard de facto presente in Giappone grazie anche alle modalitadi creazione adottate e la successiva ricerca e sviluppo nel campo degli elettrodome-stici di nuova generazione con un basso consumo energetico [19].

Occorre precisare che in Giappone il processo di standardizzazione segue un iterdifferente da quello europeo: prima viene proposto uno standard alla cui creazionepartecipa una pluralita di soggetti e solo successivamente viene avviata la produzionedi apparati che rispettino tale standard.In Europa invece il processo risulta spesso invertito: prima avviene la produzione dei

15


dispositivi e solo dopo si cerca di armonizzare lo status quo creando uno standardper permettere la comunicazione tra di essi. La realta dei fatti dimostra come inGiappone sia molto piu facile, per uno standard, essere l’unico adottato, al contrariodell’Europa dove un eventuale standard deve scontrarsi con le quote di mercato giaconsolidate da protocolli proprietari.

2.4.6 BatiBUS

Lo standard Batibus [20] e stato il primo bus sul mercato europeo; nato in Franciaad opera della Schneider e stato sviluppato nel 1989 su iniziativa di MERLIN GE-RIN, AIRELEC, EDF e LANDIS & GYR, utilizza un doppino come mezzo fisico epermette una topologia libera.

Ogni pacchetto di comunicazione e composto da un numero fisso di byte rappre-sentanti il tipo di apparato da gestire, il controllo dell’errore, l’indirizzo e un numerovariabile di byte di dati, contenente istruzioni e comandi per la gestione della rete.

La velocita di trasmissione e di 4800 baud.Successivamente alla sua creazione e stato fondato nel 1990 il Batibus Club In-

ternational con lo scopo di promuovere le applicazioni dello standard BatiBus. Taleassociazione ha partecipato insieme ad EIBA ed EHSA al processo detto “Conver-genza” che ha portato nel maggio 1999 alla fusione delle tre associazioni ed allanascita di una nuova associazione (KONNEX) [23] che ha dato il nome all’omonimostandard.

2.4.7 European Home Systems (EHS)

EHS e stato creato nel 1992 dalla EHSA (European Home System Association)[21] con il compito di promuovere uno standard aperto basato sui 7 livelli ISO/OSIper permettere la comunicazione tra milioni di dispositivi, riuniti in gruppi di 256elementi.

Prevede la funzionalita Plug&Play, permette autoconfigurazione della rete, fles-sibilita di posizionamento ed alta affidabilita dovuta ad un efficace metodo per ilcontrollo e la correzione di errori. Prevede bus su quasi tutti i mezzi di trasmissioneed e uno standard aperto per il quale esiste la certificazione dei prodotti.

EHSA ha partecipato insieme a BatiBus ed EIBA al processo detto “Convergen-za” che ha portato nel maggio 1999 alla fusione dei tre ed alla nascita di una nuovaassociazione (KONNEX) [23] che ha dato il nome all’omonimo standard.

2.4.8 European InstaBus (EIB)

EIB e stato creato ad opera della EIBA (European InstaBus Association) [22] eprevede un sistema decentralizzato suddiviso gerarchicamente in aree e linee. Per

16


collegare insieme piu linee vengono usati apparecchi di rete che prendono il nomedi accoppiatori di linea (o Line Coupler), mentre per accoppiare piu aree vengonoimpiegati gli accoppiatori di area (o Area Coupler). Su ciascuna linea possonoessere inseriti fino a 64 dispositivi, mentre fino a 15 linee possono entrare a farparte di un’area. Nel caso in cui le linee in questione siano fino a 12, esse potrannocomunicare tra loro senza la necessita di creare un’area. In una installazione EIB equindi possibile inserire fino a 11.520 dispositivi.

EIB supporta qualunque topologia di rete, anche unioni di topologie diverse, fattaeccezione per l’anello ma presenta alcuni limiti in fatto di distanze da rispettare traalimentatore e dispositivo (max 350 m), tra due dispositivi (max 700 m) e tra duealimentatori (min 200 m).

EIBA ha partecipato insieme a BatiBus ed EHSA al processo detto “Conver-genza” che ha portato nel maggio 1999 alla fusione delle tre associazioni ed allanascita di una nuova associazione (KONNEX) [23] che ha dato il nome all’omonimostandard.

2.4.9 KONNEX

Questo nuovo standard e stato il risultato del processo detto “Convergenza” adopera di Batibus, EIBA e EHSA ed e anche noto con l’acronimo EIB/KNX. L’asso-ciazione creata, Konnex [23], trova il suo scopo nel creare uno standard europeo perla home e building automation. EIB/KNX si basa sulle caratteristiche migliori deitre protocolli da cui deriva, anche se in realta risulta essere un’innovazione di EIB(paragrafo 2.4.8) con cui mantiene una compatibilita totale. Produttori differenticostruiscono i dispositivi e li sottopongono all’approvazione del consorzio, il qualedopo una fase di testing di rispetto delle specifiche pone il marchio Konnex, ga-rantendo quindi la loro compatibilita con qualunque altro dispositivo certificato. Imezzi fisici principalmente utilizzati sono twisted pair e powerline, anche se esistonodispositivi utilizzanti InfraRed e radiofrequenze. Permette una topologia a scelta,anche mista. Mantiene una compatibilita totale con EIB, da cui deriva e da essoha preso la suddivisone gerarchica in aree, linee e device, innalzando pero a 16 ibit di indirizzamento, permettendo quindi un impiego di 65.536 dispositivi in unaistallazione EIB/KNX. Il protocollo di comunicazione si basa sullo stack ISO/OSI,con un accorpamento di alcuni livelli. Una trattazione piu esaustiva viene propostaall’inizio del capitolo 5.

17

Capitolo 3

Obiettivi e motivazioni

In questo capitolo vengono spiegate le motivazioni alla base della tesi, presentandoil contesto in cui questa va ad inserirsi e quali sono gli obiettivi fissati.

3.1 Contesto

Nel contesto dell’automazione degli ambiente domestici, il gruppo di ricerca elitedel Politecnico di Torino ha realizzato un progetto denominato Domotic House Ga-teway [24], il cui scopo e collegare tramite un gateway, che prende il nome di HouseManager, differenti reti domotiche che utilizzano una varieta di protocolli di comu-nicazione di basso livello. L’House Manager permette un’interazione omogenea coni vari dispositivi e fornisce una interoperabilita tra gli stessi che risulta attualmenteimpossibile viste le differenti tecnologie presenti sul mercato (presentati nella sezione2.4). Una trattazione piu approfondita del contesto in cui la tesi va ad inserirsi erimandata al capitolo 4

Nel caso particolare affrontato in questa tesi, si e deciso di estendere l’operativitadell’House Manager alla rete EIB/KNX, a cui verra collegato tramite LAN ed unapposito apparato domotico noto come gateway. L’obiettivo e quello di integrare lasoluzione House Manager, gia disponibile ed in grado di operare con la rete MyHomeBTicino [25], con il supporto a reti EIB/KNX. Cio consentira di dimostrare l’efficaciadell’approccio all’interoperabilita tra sistemi domotici diversi, anche con specificheprove sperimentali come illustrato nel capitolo 8.

L’integrazione di reti EIB/KNX all’interno del set gestibile dall’House Managerrichiede la progettazione e lo sviluppo di un driver apposito per la rete EIB/KNX ela realizzazione di un prototipo che consenta di verificare sperimentalmente la tesiproposta.

La scelta di EIB/KNX come protocollo di comunicazione e stata fatta in quantoquesto risulta essere il protocollo maggiormente diffuso a livello europeo e mira ad

18

3 – Obiettivi e motivazioni

essere uno standard in tale continente. EIB/KNX e stato introdotto nella sezione2.4.9 e verra affrontato in maniera piu approfondita nel capitolo successivo a questo.

3.2 Prototipo

Al fine di dimostrare la tesi non solamente dal punto di vista architetturale e funzio-nale ma anche praticamente, si intende realizzare un banco dimostrativo, contenentedispositivi domotici EIB/KNX, i quali devono essere comandabili tramite House Ma-nager, oltre che ovviamente da un ipotetico utilizzatore. Mirando alla dimostrazionedella tesi il banco viene attrezzato con elementi base quali luci, prese ed attuatori,sebbene la vastita di dispositivi possibili sia di gran lunga maggiore; per semplicitarealizzativa si pensa inoltre di non inserire dispositivi complessi quali ad esempiotelecamere, sensori meteorologici o anti-intrusione, pur non escludendone una futuraintroduzione.

Requisito fondamentale del progetto e che l’House Manager sia in grado di in-teragire con dispositivi presenti nel banco di lavoro EIB/KNX, attuando i comandirichiesti. Inoltre, dovranno essere presenti collegamenti e tecniche opportune alfine di comandare l’accensione e spegnimento di utenze intervaligia; dovra cioe es-sere possibile sia pilotare luci BTicino tramite pulsanti EIB/KNX, sia luci e preseEIB/KNX tramite pulsanti BTicino.

L’House Manager dovra conservare intatta la sua architettura, eccezion fattaper i moduli aggiuntivi necessari alla comunicazione con la nuova rete. Esso dovraquindi continuare ad operare a livello astratto sui device presenti nell’installazioneglobale e non dovra rendersi necessaria la distinzione secondo il protocollo utilizzatoa basso livello.

L’utilizzo dell’installazione da parte utente tramite House Manager non dovrainterferire con l’uso consueto delle utenze elettriche attraverso i relativi dispositividi comando.

19

Capitolo 4

Architettura

In questo capitolo viene presentata l’architettura dell’House Manager, soffermandosisui moduli in esso contenuti, al fine di comprendere la sua funzione di collegamen-to tra differenti tecnologie domotiche ed interfacce. In particolare esso risulta giatestato su rete BTicino, utilizzante il protocollo SCS, ma la sua architettura non especifica per tale tecnologia; astraendo ad alto livello la rete domotica come insiemedi oggetti software operanti tra loro, potenzialmente favorisce la comunicazione conqualunque altra rete domotica, a patto che l’House Manager riesca ad interagire conessa. Tale collegamento viene operato tramite appositi moduli driver da inserirenel gateway che si occupino di tradurre il linguaggio astratto ad alto livello da essoadottato in messaggi sulla rete domotica e viceversa.

4.1 Architettura

Quando un ambiente come una casa viene dotato di intelligenza operativa, attraver-so opportuni device e meccanismi, un utente puo usare e comandare tale ambientetramite appositi tasti o bottoni opportunamente configurati e facenti parte dell’in-stallazione.Naturalmente il fatto stesso che l’ambiente sia “intelligente” fa si che a queste inter-facce piu tradizionali si possano affiancare interfacce piu evolute basate ad esempiosul tracciamento oculare, sul riconoscimento di gesti, ecc. Data la varieta di inter-facce che si possono immaginare e dato che il loro utilizzo e frequentemente mediatoda dispositivi con potenza elaborativa limitata, e necessario operare una separazionetra la presentazione all’utente (Interface Layer) e l’elaborazione che la gestione dellacasa implica (Application Logic).

Quest’ultima richiede capacita e potenza di calcolo non indifferenti e quindi deveessere eseguita da un sistema piu potente/adatto, quale ad esempio un PC o unHome Gateway. Date queste considerazioni l’architettura che ne consegue (Fig.

20

4 – Architettura

4.1) presenta principalmente 3 entita: l’Interaction Manager, l’House Manager e lacasa.

Figura 4.1. Architettura generale

I primi due elementi si occupano rispettivamente della generazione delle inter-facce e della gestione dell’Application Logic (Interaction Manager) e dell’interazionecon la casa (House Manager).Viene ora presentata una breve trattazione di questi, per quanto di interesse ai finidel lavoro di tesi.

4.1.1 Interaction Manager

L’Interaction Manager gestisce le varie interfacce grafiche agendo come un proxy epermettendo l’accesso e la gestione degli apparati domotici tramite House Manager.Esso comunica da una parte con l’House Manager, tramite un opportuno protocollo(House Manager Protocol - HMP) e dall’altra con le varie interfacce a cui risultacollegato.Tali interfacce necessitano di essere molto semplici, dovendo essere gestibili da dispo-sitivi solitamente poco potenti e lavorano quindi su insiemi semplificati di elementi

21

4 – Architettura

(pagine), in cui vengono raggruppati e collocati i dispositivi e le funzioni controllabi-li. L’Interaction Manager si occupa di aggiornare le interfacce secondo le variazionidi stato che la rete domotica subisce e di raccogliere le azioni dell’utente per poterleelaborare 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 con-nessi alle reti stesse ma in possesso di una interfaccia di comunicazione (Ethernet,WiFi, Bluetooth, RS232, ...). Le reti domotiche che possono essere impiegate sononumerose: oltre che essere prodotte da costruttori differenti, esse possono conteneredispositivi eterogenei, distribuiti e posizionati nell’ambiente domestico e connessitra 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 op-portuni protocolli specifici per ogni singola tecnologia (BTicino, EIB/KNX, X10,...) e non sono direttamente accessibili dall’esterno. Per fare cio viene impiegatoun device particolare, che prende il nome di gateway e che si occupa di operare letraduzioni necessarie tra il protocollo di basso livello utilizzato dalla rete domoticasu bus ed un ulteriore protocollo che gli permetta di comunicare con l’esterno. Nelloscenario in cui si va ad inserire la trattazione e richiesto che tale gateway permettaun accesso alla rete domotica tramite Ethernet.

4.1.3 House Manager

L’House Manager e un concetto sviluppato dal gruppo elite del Politecnico di Torino;la sua struttura (Fig. 4.2) deriva dallo studio degli house gateways sviluppati e residisponibili dalla comunita scientifica negli ultimi anni.

Le caratteristiche importanti di tale tecnologia sono soprattutto due: la capacitadi astrarre le funzionalita ed i dispositivi della casa secondo un linguaggio di altolivello e l’utilizzo di un livello di intelligenza basato su di un motore a regole.

La sua struttura e suddivisa in due livelli principali: l’Intelligent Layer e l’Ab-stracion Layer.

L’Abstracion Layer si occupa di tradurre il protocollo di basso livello utilizzatodalle reti in un linguaggio/protocollo di alto livello che permetta un accesso ed unutilizzo uniformi e trasparenti per ogni installazione domotica collegata.Questo protocollo, denominato House Manager Protocol (HMP), adotta una nota-zione URI-like per identificare i dispositivi ed un set predefinito di comandi associatoad ogni tipo di device. Cio permette sia un controllo di tutti i dispositivi appar-tenenti alla casa, sia un impiego del sistema in ambienti con tecnologie domotiche

22

4 – Architettura

Figura 4.2. House Manager - struttura

differenti, garantendo l’accessibilita a livello di Abstraction Layer.

L’Intelligent Layer permette l’accesso ai dispositivi domotici tramite un’intera-zione piu di alto livello rispetto all’utilizzo dei comandi disponibili a livello di bus.Esso e formato da differenti moduli, i quali si occupano di presentare un ambientepiu consono alle esigenze di semplicita dell’utente. In tale livello e presente unaparte di Domotic Intelligence, la quale provvede a fornire una certa automaticitanel funzionamento dell’House Manager. La parte di Domotic Intelligence e formataprincipalmente da un Rule-Engine (motore a regole) ed un Rule-Miner (estratto-re automatico di regole): essi posso recepire nuove regole monitorando il normaleutilizzo della casa da parte dell’utente, cercando quindi di prevederne le scelte ed igusti, oppure eseguono una serie prefissata di regole.E’ possibile ad esempio creare una regola che, se e rilevata la presenza di una personanella stanza, accenda la luce quando viene rilevato l’abbassamento delle tapparelle,evitando quindi che questa rimanga al buio. In questo caso l’azione che fa scattarela regola risulta essere un comportamento dell’utente (che comanda l’abbassamentodella tapparella). La stessa azione potrebbe essere invece il risultato di una regola,realizzata ad esempio tramite un sensore di luminosita che segnala il superamentodella soglia inferiore, da cui consegue un abbassamento delle tapparelle.

23

4 – Architettura

Come detto, e anche possibile che la Domotic Intelligence monitori l’utente e deducaregole dal suo comportamento: cio puo essere utile ma anche fonte di problemi inquanto e molto influenzato dal grado di abitudinarieta dell’utilizzatore; percio inquesti casi potrebbe essere indicato richiedere la conferma di un eventuale comandodedotto da esperienze passate prima di provvedere ad attuarlo unilateralmente senzaconsenso dell’utente.

Il controllo di tutti i device facenti parte dell’installazione da parte dell’HouseManager permette anche un’ulteriore ed interessante funzione: quella di rendere talidispositivi potenzialmente interoperabili tra loro, pur appartenendo a, ed utilizzan-do tecnologie domotiche differenti. Cio e reso possibile dall’astrazione ad alto livelloche viene fatta di ogni dispositivo, tale da rendere ininfluente il protocollo da essousato a basso livello, sul bus.L’astrazione fornita dall’House Manager risulta molto importante, in quanto per-mette la realizzazione e l’utilizzo di reti domotiche eterogenee e non vincola all’usoesclusivo di una di esse. Questo puo risultare utile data la varieta di dispositivi do-motici che proliferano sul mercato, la cui scelta risulta essere finora molto vincolante,in quanto non e possibile affiancare due o piu device con tecnologie diverse, anche seil loro utilizzo congiunto puo apportare determinanti benefici. Se i due dispositivinon utilizzano il medesimo protocollo, risultano in generale non interoperabili e cioobliga l’utente a dover scegliere una tecnologia specifica per la propria installazio-ne, rinunciando conseguentemente ad alcune funzionalita. Tramite l’House Managerinvece e possibile inserire ogni device desiderato, il quale riuscira ad interagire conogni 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 specifiche richieste, passando per la scelta deicomponenti, il loro montaggio e concludendo con la presentazione della valigettarealizzata.

5.1 EIB/KNX

Il protocollo di comunicazione scelto presenta un’architettura molto piu complessadi quella della BTicino con cui l’House Manager risulta gia in grado di interagire.Innanzitutto occorre precisare che la divisione dei dispositivi avviene tramite posi-zionamento fisico in linee ed aree (sezione 5.1.1), collegate tra loro da accoppiatoriparticolari, i quali realizzano un’infrastruttura di rete che si allontana dal semplicebus e si avvicina molto ad una rete cablata IP.

Nei paragrafi successivi vengono delineate le caratteristiche principali del proto-collo EIB/KNX, soffermandosi in particolare su cio che lo rende, o dovrebbe renderlo,uno standard unico ed affermato a livello europeo.

5.1.1 Gerarchia e suddivisione in linee e aree

Come accennato in precedenza, l’architettura di rete EIB/KNX risulta complessain quanto il semplice collegamento a bus viene potenzialmente ampliato di molto,fino a raggiungere complesse strutture e sottoreti. Questo permette da una parteuna separazione di partizioni dal resto della rete e dall’altra una complessita nontrascurabile dei dispositivi di rete, i quali devono occuparsi di gestire queste divi-sioni logiche tramite opportune regole che assomigliano molto alle regole di routingpresenti 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 aquesti sono presenti anche altri due tipi di device di sistema, il gateway e la BCU, chevengono trattati in seguito. I vari dispositivi presenti in un’installazione EIB/KNXvengono suddivisi in linee, con al massimo 256 device ed ogni linea puo essere a suavolta inserita in un’ulteriore livello di gerarchia chiamato area, tramite l’opportunoaccoppiatore.

La similitudine con l’infrastruttura di una LAN e notevole al punto che spessoi due tipi di accoppiatori vengono presentati appunto come hub (line coupler) eswitch (area coupler). La gerarchia risultante riflette non solo i collegamenti fisicisul bus, ma anche gli indirizzi necessari alla comunicazione, come viene spiegatosuccessivamente (sezione 5.1.2).Linee ed aree vengono accorpate secondo un criterio ben preciso e, a differenza dellastruttura di una rete locale, vi sono vincoli sul numero massimo di elementi presentiin una linea e di linee facenti parte di una determinata area. Infatti ogni linea puocontenere al massimo 256 device e, salendo di grado, ogni area puo avere solamenteun massimo di 16 linee. Infine fino a 16 aree possono essere collegate tra loroformando un dominio ed interagire, raggiungendo la massima profondita consentitanell’installazione; cio comporta l’impiego di un massimo di 65.536 dispositivi (siveda la sezione 5.1.2 per i dettagli) che, seppur notevolmente elevato in ambitohome automation, puo risultare vincolante per la building automation. Nel caso incui tale limite debba essere valicato, si puo introdurre la figura di un gateway, ilquale colleghi tramite backbone, ad esempio IP, due installazioni separate, creandoun’ulteriore rete domotica suddivisa in aree e linee come la precedente.

Per chiarire la complessa struttura possibile nella rete viene presentato un esem-pio (Fig. 5.1) in cui si puo vedere il posizionamento dei vari device all’interno dellearee e linee oppure anche direttamente sul collegamento tra le varie aree, denominatobackbone.

Occorre soffermarsi un attimo sul concetto di alimentazione del bus, in quantoogni linea deve essere separata elettricamente dalle altre e quindi necessita di unproprio alimentatore; nel caso in cui una linea necessiti di un’alimentazione maggioreai 160 mA e 320 mA (a seconda dell’alimentatore considerato) si puo inserire unsecondo alimentatore a patto che esso disti sul bus almeno 200 m dal precedente.Se anche l’aggiunta non sopperisse alla richiesta della linea, due alimentatori possonoessere collegati ad essa in parallelo su un shared choke.Oltre cio e necessario rispettare i vincoli di distanza massima tra alimentatore edispositivo alimentato (< 350 m) e tra due device (< 700 m): il primo per motivi dioperativita, il secondo per permettere il rilevamento della collisione. Infatti l’accessoal bus avviene tramite il meccanismo noto come Carrier Sense Multiple Access withCollision Avoidance (CSMA/CA), il quale obbliga ogni utilizzatore ad ascoltare ilcanale prima della trasmissione ed impiegarlo solamente se questo risulta libero, ossiase nessun altro sta trasmettendo. In seguito all’avvenuto invio occorre rimanere in

26


Figura 5.1. Topologia della rete EIB/KNX

attesa che il telegramma raggiunga il destinatario senza che un’altra comunicazionedisturbi quella attuale: per fare cio si rimane in attesa un tempo limite necessario alraggiungimento dell’altro capo del bus, riuscendo a sentire un’eventuale collisione e,nel caso, a ritrasmettere secondo opportune tempistiche. Questo meccanismo limitaa 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 ilcompito di permettere il collegamento tra il bus EIB/KNX a cui e collegato, con unarete IP (ad esempio). Questo risulta essere molto importante in quanto in instal-lazioni di grosse dimensioni, quali ad esempio quella di un campus universitario, cisi trova frequentemente nella situazione di dover collegare due edifici distanti anche

27


centinaia di metri. Realizzare il collegamento tramite semplice bus risulta sia inutileche tecnicamente impossibile in quanto si presuppone di avere migliaia di dispositi-vi ed il traffico da essi prodotto assume un peso importante e caratteristiche qualiil ritardo di propagazione ed i tempi di latenza devono essere tenute ampiamentein considerazione. Oltre a cio, il gateway permette un accesso alla rete domoticadall’esterno tramite LAN: esso infatti si occupa di incapsulare opportunamente i te-legrammi EIB/KNX in normali pacchetti IP, dando la possibilita a tutti i dispositividi utilizzare questo protocollo.

Bus Coupling Unit (BCU)

Le Bus Coupling Unit (Fig. 5.2) invece sono il cuore della comunicazione su bus inquanto esse si frappongono tra il dispositivo vero e proprio ed il bus. Ogni devicecomprende una BCU, sia essa esterna, come ad esempio nelle tastiere, sia essa in-globata all’interno come negli accoppiatori di linea, di area, negli attuatori o negliingressi analogici e binari.

Figura 5.2. Bus Coupling Unit - BCU

La BCU risulta essere il punto di contatto con il bus e tramite un’opportunainterfaccia chiamata Physical External Interface (PEI) comunica con una specificaunita chiamata Application Unit (AU), entrambe a bordo del dispositivo. La BCU sioccupa di ricevere telegrammi EIB/KNX e controlla la AU inviandole le informazionidecodificati. Essa elabora opportunamente i dati ricevuti e ne fornisce di nuovi allaBCU, che provvedera a codificarli e trasmetterli su bus. La PEI offre la possibilitaalle due unita di comunicare in modo semplice.

La BCU contiene un microprocessore, una ROM (Read Only Memory), una RAM(Random Access Memory) ed una EEPROM (Electrically Erasable ProgrammableROM) che le permettono di operare; in particolare nella EEPROM sono caricate inatto di configurazione (sezione 5.1.3) le informazioni necessarie al funzionamento deldispositivo mentre la ROM contiene software specifico di sistema che il configuratorenon puo variare.

28


Nella figura 5.3 si puo vedere l’architettura necessaria alla comunicazione di undevice su bus: come detto non sempre la BCU risulta essere fisicamente esternaal dispositivo quindi si puo avere il caso in cui essa sia inglobata, in ogni casol’architettura logica non cambia.

Figura 5.3. Architettura di comunicazione con bus

5.1.2 Indirizzi

Ogni dispositivo e individualmente riconosciuto dalla rete tramite un identificativounivoco. Tale identificativo prende il nome di indirizzo ed e scritto nella forma 5.1

area.linea.device (5.1)

e presentato in Figura 5.4, a seconda della posizione che esso occupa nella gerar-chia della rete. L’indirizzo totale risulta essere di 16 bit (2 byte), 4 di area, 4 di lineaed i rimanenti 8 di device, da cui deriva 65.536, il numero massimo di dispositiviche e possibile indirizzare in una rete EIB/KNX.

L’ordine di grandezza risulta essere molto elevato e rende EIB/KNX un proto-collo adatto a reti di medie/grosse dimensioni, quali ad esempio alberghi, ospedali,fabbriche, centri congressi, i quali intrinsecamente hanno gia al loro interno una sud-divisione in quelle che possono essere paragonate a linee e aree. Si pensi ad esempioad 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 taleinfrastruttura di rete incide pesantemente sulla realizzazione oltre che risultare nonnecessaria, pertanto, come si vedra nella sezione 5.3.3, non verra realizzata una verae propria gerarchia di rete con gli accoppiatori presi in considerazione.

Figura 5.4. Struttura indirizzo individuale

Oltre che individualmente, un device puo essere comandato tramite quello cheviene chiamato indirizzo di gruppo. Tale meccanismo ha una granularita inferiore alprecedente in quanto non individua uno specifico dispositivo, ma tutti i dispositivifacenti parte del gruppo. Anche qui il paragone con il mondo delle reti locali equanto mai idoneo, nel particolare del riferimento al multicast.

Il gruppo e identificato tramite una gerarchia per certi versi simile all’identifica-zione del singolo device; l’indirizzo di gruppo continua ad essere di 16 bit, ma cioche cambia e la suddivisione interna dei bit (Fig. 5.5), in quanto si perde il concettodi area, linea e dispositivo per assumere quello di main group, middle group e groupaddress, che vanno a costituire l’indirizzo 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 l’ultimo livello di identificazione risultanoessere uguali a quelli per il device all’interno della singola linea, occorre precisare chegli altri due livelli variano; in particolare per il middle group si hanno a disposizione3 bit e per il main group 5. Questi ultimi due livelli formano la parte alta, primobyte, dell’indirizzo di gruppo. Va sottolineato che il bit piu significativo del maingroup e sempre pari a 0 in quanto le specifiche consentono di avere un massimo di 16main group, per il cui indirizzamento sono necessari solamente 4 bit. L’allineamentoa 8 bit ed il dimensionamento massimo del middle group ad 8 elementi (su 3 bit)rende necessario l’introduzione del suddetto bit a valore fisso.

Come nel multicast IP viene associato un indirizzo al gruppo e tramite questovengono raggiunti tutti i device che vi appartengono: cio evita l’oneroso compito didover interagire singolarmente con ogni dispositivo interessato alla comunicazione.

30


Figura 5.5. Struttura indirizzo di gruppo

Potenzialmente il gruppo puo essere formato da decine di elementi e la quantita ditelegrammi che occorrerebbe scambiare risulta in quest’ultimo caso non indifferenterispetto al singolo messaggio inviato su bus e decodificato solamente dai destinatariinteressati.Ogni dispositivo non e vincolato ad appartenere ad un singolo gruppo, ma puo essereconfigurato per operare con gruppi diversi, in quanto le sue caratteristiche possonoessere varie ed ognuna di esse puo risultare utile come attributo di raggruppamentocon altri device simili.

Gli esempi di utilizzo possono essere molti e articolati, basti pensare ad un grup-po contenente un pulsante e due luci che devono accendersi insieme, pur continuandoad essere pilotabili anche separatamente. Oppure ad un gruppo con sensori di rile-vamento fumo e gas, i quali in determinate situazioni segnalano il superamento diuna soglia prestabilita, permettendo al motore che aziona porta e finestra di aprirsied al lampeggiante di attirare l’attenzione degli occupanti della casa.

Anche se posson sembrare complesse, tali configurazioni vengono fatte in viacentralizzata tramite un opportuno tool software denominato ETS (sezione 5.1.3), ilquale si occupa di connettersi alla rete e scaricare su ogni dispositivo (in particolaresulla relativa BCU) tutto il codice necessario per operare quanto richiesto.

5.1.3 Configurazione

Per configurare un’installazione EIB/KNX occorre un lavoro complesso che non puoessere effettuato semplicemente tramite collegamento di opportuni fili in alloggia-menti specifici. Una volta collegati tra loro gli apparati tramite bus (qualunque siala sua topologia) ed effettuati i collegamenti elettrici per il controllo delle utenze,occorre permettere la comunicazione vera e propria tra i dispositivi non solo a livel-lo elettrico ma anche ad alto livello, operando un’opportuna e alquanto complessaconfigurazione.

L’associazione KONNEX ha provveduto a questo aspetto tramite un appositosoftware denominato Eib Tool Software (ETS) (di cui si puo vedere una schermatain Fig. 5.6); come gia accennato in precedenza EIB/KNX fornisce compatibilita con

31


tutti i dispositivi EIB e quindi non deve stupire l’acronimo. Tale strumento vieneinstallato su un personal computer che a sua volta deve essere collegato al bus nelmodo che si ritiene piu utile e comodo, sia esso RS232, USB o IP. E’ possibile operarela configurazione dell’intera installazione anche senza il collegamento, in quantotutto il lavoro viene fatto offline; la connessione al bus e necessaria solamente quandosi desidera effettuare il download su rete di quanto fino al momento configurato. Ildownload puo coinvolgere uno o piu dispositivi e puo riguardare l’intero software osolamente alcuni parametri di un device.

Figura 5.6. Eib Tool Software (ETS)

Il collegamento col bus avviene come detto tramite un’interfaccia scelta dal-l’installatore ed utilizza librerie particolari denominate Falcon, che consentono lacomunicazione tra il bus ed applicativi presenti sul personal computer in uso, vin-colando l’uso del sistema operativo Windows. Sono presenti nell’ambito opersourcetools software che cercano di permettere la comunicazione col bus domotico non solotramite l’utilizzo del software ETS e delle librerie Falcon: in particolare si segnalail Linux Eib Home Server [27], il quale utilizza un’interfaccia RS232 per il collega-mento ad una installazione EIB. Tale progetto pero necessita di una configurazionepreesistente.

32


5.2 Scelta componenti

Per dimostrare la tesi iniziale (capitolo 3) e stato necessario realizzare un prototipofunzionante di rete EIB/KNX. Inizialmente si e pensato di creare un pannello dilavoro contenente dispositivi domotici ed elettrici al fine di dimostrare l’effettivapossibilita di comando di una rete domotica EIB/KNX tramite l’House Manager.

In seguito a considerazioni ulteriori di trasportabilita per eventuali dimostra-zioni, la visione del pannello risultava poco consona e si e deciso di passare ad unambiente leggermente piu ristretto ma al contempo con eguali possibilita funzionali,rappresentato da una valigetta “stile 24 ore” contenente alcuni dispositivi domotici.Per permetterne il funzionamento e la comunicazione, essa e stata predisposta peressere alimentata da rete elettrica esterna ed e stata fornita di una interfaccia versoLAN attraverso cui fosse possibile la comunicazione con l’House Manager.

La scelta dei componenti e stata dettata dalle dimensioni contenute del bancodi lavoro e al contempo da una minima varieta di dispositivi con cui operare. Persemplicita ci si e focalizzati sull’utilizzo di luci e prese a cui ovviamente sia possibilecollegare un qualunque apparato alimentato a 220 V (ventilatore, radio, lampada...).Dato che EIB/KNX viene presentato come standard, si possono utilizzare dispositivinon solamente di un’unica marca o casa produttrice, ma si possono inserire anchecomponenti costruiti da aziende diverse: l’importante e scegliere dispositivi che han-no ottenuto il marchio KONNEX, il quale garantisce che essi rispettino le specifichee siano in grado di essere inseriti in una rete EIB/KNX con altri dispositivi di mar-che differenti e con essi operare facilmente.Dato che l’associazione KONNEX presenta sul proprio sito [23] l’elenco dei membriassociati e dei 10.777 partners divisi in 71 Nazioni, i possibili fornitori sono statiricercati in tale elenco. In gran parte si tratta di produttori del centro Europa, so-prattutto di madrelingua tedesca. I rapporti con i rappresentanti commerciali sonostati lunghi e difficoltosi e solo dopo un tempo non indifferente si sono avuti a di-sposizione una serie di cataloghi aggiornati all’interno dei quali scegliere i dispositiviricercati.

Innanzitutto si e pensato di utilizzare dispositivi di due marche solamente, perdimostrare la reale figura di standard di EIB/KNX e al contempo non allargareeccessivamente la cerchia di fornitori, per non allungare i gia lunghi tempi di con-segna e poter iniziare il lavoro. Si e scelto di concentrare l’attenzione su dispositiviAbb e Merten, i primi per facilita di reperibilita disponendo di grandi distributorilocalizzati in Italia, i secondi per il prezzo contenuto.

E’ da sottolineare che la differenza di prezzo tra i dispositivi delle due marchecitate e principalmente, ma non unicamente, dovuta alla presenza di una maggiorvarieta di programmi su taluni apparati, atti a fornire all’utilizzatore una gammapiu vasta e complessa di funzionalita, anche se di (quasi) inutilita ai fini del lavorodi tesi.

33


La tipologia risultante degli apparati e poco varia, ma sufficiente data la sempli-cita del banco.Ne viene ora presenta una descrizione suddivisa secondo materiale elettrico e domo-tico.

5.2.1 Materiale elettrico

Nella prima categoria ricadono i materiali di uso in una comune installazione elettricadomestica, quindi con scatole, frutti, portafrutti, placche, fili della luce, interruttorie pulsanti. Il montaggio dei frutti e avvenuto sul rispettivo portafrutto, coronatodalla 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 lapresenza di due marche differenti di dispositivi, si e dotata ogni stanza con 2 prese(Fig. 5.8) e 2 luci (Fig. 5.9), per avere una basilare varieta di utenze da comandare.Entrambe le tipologie di utenze sono state raggruppate ciascuna in portafrutti da3 posti ciascuno, lasciando un posto per un’ulteriore aggiunta futura, al momentooccupata da un semplice copriforo.

Visto l’inserimento dei frutti e portafrutto all’interno di una valigetta, si e sud-diviso l’interno in due scomparti: uno superiore in cui inserire le utenze e i tasticomando ed uno inferiore in cui inserire i moduli DIN, una presa Ethernet ed unapresa di alimentazione a vaschetta. Quest’ultima permette la connessione dell’ali-mentatore alla tensione di rete; la presa Ethernet invece collega il gateway domoticoad una LAN. Sebbene gia disponibile come porta sul gateway, tale presa e stata pro-lungata al fine di fornire un alloggiamento raggiungibile una volta coperto il quadrocentralino con l’apposito pannello.

Un’ulteriore considerazione va fatta riguardo la presenza di dispositivi domoticiatti ad interfacciare interruttori e pulsanti (sezione 5.2.2): cio ha suggerito l’utilizzo

34


Figura 5.8. Gruppo prese

Figura 5.9. Gruppo luci

di tasti tradizionali (Fig. 5.10), configurati opportunamente per pilotare carichitramite la rete domotica. Tale scelta permette di conservare in parte la visualeesterna dell’installazione, con pulsanti e relativa placca tradizionali e quindi piufacilmente utilizzabili da persone che preferiscano una visuale piu classica rispettoad una piu tecnologica e/o complessa, fornita dai tasti e pulsanti domotici.

Figura 5.10. Tasti tradizionali

Per porre in sicurezza il prototipo si sono inseriti due dispositivi appositi: l’in-terruttore magnetotermico e quello differenziale.

35


L’interruttore magnetotermico protegge dai cortocircuiti ed i sovraccarichi ed e for-mato, nella sua realizzazione piu semplice, da una elettrocalamita ed una lamabimetallica: entrambe aprono il circuito nel caso in cui la corrente sia eccessiva, mahanno range operativi differenti. La prima si occupa di sovraccarichi piu consistenti,mentre la seconda di quelli poco oltre la soglia preimpostata.L’interruttore differenziale invece agisce contro i guasti a terra o dispersioni: misurala differenza di corrente tra fase e neutro e se essa risulta sovra soglia, interrompe ilcircuito.

Il dispositivo con cui si e dotato il banco comprende entrambi gli interruttori;nel particolare risulta essere un interruttore magnetotermico differenziale In 16 A, ld0.01 A, 2 poli, tipo AC, 230V formato dai due interruttori presentati separatamentein Figura 5.12 e Figura 5.11.

Figura 5.11. Interruttore differenziale

Figura 5.12. Interruttore magnetotermico

5.2.2 Materiale domotico

Nella seconda categoria occorre delineare cosa di specifico e stato inserito nel bancotra la varieta di dispositivi domotici esistenti. Dalla suddivisione presentata nellasezione 2.3 si e avuta la necessita di avere dispositivi di tutte le categorie, al fi-ne di comandare l’installazione (input) e vedere l’attuazione di comandi (output).

36


Di fondamentale importanza risultano essere anche le ultime due categorie (dispo-sitivi di sistema e di interfacciamento), sia per quanto riguarda la comunicazionetra l’installazione ed l’House Manager (interfacciamento), sia per il collegamento efunzionamento dei vari dispositivi (sistema).

Attuatori

Utilizzando una suddivisione in due stanze, ognuna di esse e stata fornita di unattuatore a 4 canali: un utilizzo di un unico attuatore a 8 canali che piloti tutte leutenze indistintamente risultava troppo concentrato e si e preferito dunque realizzareuna struttura piu pulita e separata per le due stanze. Dovendo pertanto seleziona-re 2 attuatori si sono scelti l’Abb (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 maggio-re risultava inutile se non in presenza di carichi piu pesanti quali ad esempio motoriper serramenti.Gli attuatori non necessitano di una BCU per essere accoppiati al bus in quanto lamontano gia al proprio interno ed inoltre, sempre tramite bus, ricevono l’alimenta-zione necessaria ad operare (24 V DC). Tali dispositivi sono montabili su guida DINEN50022 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 dall’esterno, si e resa necessaria un’interfacciaverso il PC. Nella varieta di interfacce presenti sul mercato, dalle RS232 alle USBalle Ethernet, si e optato per un gateway IP (Abb IG/S 1.1) (Fig.5.15) con unaporta Ethernet, permettendo quindi un collegamento LAN tra il PC, la valigettaBTicino e la valigetta EIB/KNX.

Figura 5.15. Gateway Abb

Tale gateway presenta una porta di comunicazione col bus EIB/KNX, una portaEthernet 10 Mbps (10 Base-T, IEEE 802.3) e puo essere alimentato sia a 12 Vin continua che 230 V in alternata. Come gli attuatori non necesssita di BCU inquanto essa e gia contenuta al suo interno ed il collegamento necessario col busavviene semplicemente tramite doppino. Il montaggio del gateway e fatto su guidaDIN EN50022, per una larghezza di 5 moduli.

Per quanto riguarda la parte di rete Ethernet, il gateway dispone di un clientDHCP, il quale si mette in attesa di un server DHCP il quale gli fornisca un indirizzoIP e nel caso in cui cio non avvenga esso e predisposto per autoconfigurarsi asse-gnandosi un indirizzo IP nella forma 169.254.xxx.yyy. Data la vastita di possibiliindirizzi entro cui esso puo andare a ricadere si e scelto di fornire il PC contenentel’House Manager di un server DHCP (tftpd32 v3.03 [26]), effettuando un’assegnazio-ne statica dell’indirizzo tramite MAC e facendolo ricadere nella sottorete contenenteanche il gateway della valigia BTicino, permettendo quindi ai due gateway di comu-nicare tramite IP. Non e stato necessario introdurre un ulteriore apparato di retein quanto il gateway BTicino risulta operare anche la funzione di switch a 6 porte10/100 Mbps.

Per i collegamenti alla rete EIB/KNX occorre precisare che non e stato neces-sario un ulteriore accoppiatore di linea o di area in quanto il gateway Abb IG/S1.1 svolge gia la funzione di entrambi. Inoltre esso puo essere configurato per fil-trare o meno i telegrammi EIB/KNX, dato che si potrebbe avere la necessita dilimitare determinato traffico entro un’area o linea precisa, per motivi di sicurezza

38


o performance; per il caso in esame e risultato essere utile, se non necessario, di-sabilitare il filtraggio, permettendo quindi al gateway di trasmettere i telegrammiEIB/KNX ricevuti dal bus alla LAN, incapsulandoli opportunamente in pacchettiIP, e viceversa. La possibilita di creare pacchetti IP contenenti telegrammi formatiopportunamente permette all’House Manager di pilotare la rete EIB/KNX come sefosse un qualunque dispositivo effettivamente presente nella rete.

Alimentatore

L’alimentazione necessaria per il banco di lavoro risulta molto esigua (< 60 mA)come mostrato in Tabella 5.1, quindi l’alimentatore ricercato non deve fornire un’altacorrente nominale.

APPARATO CONSUMOGateway 22 mA

Attuatore Abb < 12 mAAttuatore Merten < 10 mA

Interfaccia tasti Merten < 10 mA

TOTALE < 60 mA

Tabella 5.1. Consumi apparati

Visto il consumo a cui far fronte e vista la presenza di un’unica linea, si e sceltol’alimentatore con la minor corrente nominale disponibile ed il minor costo, optandoper il Merten 6833 29 a 160 mA (Fig. 5.16). Esso opera ad una tensione di retepari a 230 V AC a 50-60 Hz ed offre una tensione di uscita di 29 V CC circa. Se dauna parte esso fornisce un’alimentazione ben superiore a quella necessaria all’interavaligia (nominalmente il dispositivo supporta una linea con 32 utenti bus), dall’altrarisulta sufficiente ad un eventuale, e contenuto, ampliamento futuro dell’installazio-ne. L’alimentatore richiede un posizionamento su guida DIN EN50022 ed occupa 4moduli.

Figura 5.16. Alimentatore Merten

39


Pulsanti

Ogni camera inoltre e stata fornita di alcuni interruttori/pulsanti per permetteredi pilotare le utenze ivi contenute. Per testare l’effettiva operabilita di differentimarche di dispositivi purche compatibili KONNEX, si e abbinato ogni attuatore aipulsanti dell’altra marca.E’ da sottolineare che variare la configurazione e quindi l’interoperabilita tra dispo-sitivi EIB/KNX significa effettuare una variazione a livello software e non occorreandare a praticare alcuna variazione a livello hardware, come ad esempio avvienecon il protocollo SCS di BTicino. Queste ed altre differenze verranno trattate inmaggior dettaglio nel capitolo 8. Sono state utilizzate due tastiere da 4/8 tasti, unaAbb (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 me-desimo tasto) sia a coppie (4 tasti risultanti). Sono presenti 4 LED subito al disotto dei tasti superiori, indicanti lo stato degli stessi (verde = non premuto; rosso= premuto). Configurando opportunamente gli indirizzi di gruppo, la tastiera e ingrado di aggiornare lo stato, quindi anche l’evenuale LED, in caso di comando ester-no sull’utenza da essa controllata. Risulta quindi possibile, ad esempio, accendereuna 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 comandoEIB/KNX che effettua l’accensione della luce, varia il proprio stato e alla successivapressione provvedera a spegnere la luce interessata.

40


La tastiera Merten presenta anch’essa 8 tasti in modalita ON/OFF, con lapossibilita di configurazione a 4 tasti, utile soprattutto per utenze non solamenteON/OFF ma con stati intermedi, quali ad esempio tapparelle. Ogni tasto presentauna corona luminosa che rappresenta lo stato in cui si trova il pulsante.In aggiunta la tastiera Merten integra un ricevitore IR che permette, tramite oppor-tuno telecomando (Merten 6833 29) presentato in Fig. 5.18, di pilotare a distanza itasti presenti. L’utilizzo di un telecomando, non presente nella tastiera Abb presain considerazione, facilita un utilizzo della tastiera a persone non normodotate o conproblemi di deambulazione.

Figura 5.19. Telecomando IR

Interfaccia a tasti

Per poter inserire interruttori e pulsanti di uso tradizionale nell’installazione domo-tica e stato necessario ricorrere ad una interfaccia a tasti (Merten 6707 90), propostain Fig. 5.20, presentante 4 coppie di fili per collegare altrettante utenze. Ogni coppiacontiene il canale di output, tramite cui avviene l’invio del comando ed un canaledi appoggio, utile nel caso in cui si voglia ad esempio accendere un LED come se-gnalazione dell’avvenuta pressione del tasto abbinato.Tale canale non viene collegato in quanto non si dispone di un LED da abbinare adogni 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 dell’installazione si puoprocedere alla spiegazione del montaggio degli stessi ed al completamento dellavaligetta dimostrativa.

5.3 Montaggio

Come detto in precedenza la valigetta e stata suddivisa in due vani, distinguendo cioche e comando ed utenza (area layout) da cio che realizza l’infrastruttura di rete e chepuo essere confinata in un modulo per centralino (area centralino). Tale suddivisionedi massima ha richiesto comunque un’attenta organizzazione dei dispositivi al fine dicreare 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 delineatola scelta della valigia, la quale doveva presentare misure non indifferenti data laquantita di dispositivi da contenere ma che comunque doveva rispettare dei vincoli,primi tra tutti la trasportabilita e la maneggevolezza.

Altezza e larghezza interne della valigia sono state dettate principalmente dalladisposizione della sezione layout rispetto a quella centralino, in quanto la prima ri-sulta essere quella a diretto contatto con l’ulitizzatore e deve quindi essere di facileuso, offrendo una visuale di facile comprensione ed una disposizione pulita ed ordi-nata. La sezione centralino contiene moduli DIN che vengono montati sull’appositaguida EN50022 e pertanto ha gia una sua collocazione intrinseca: cio che rimaneda scegliere per tale sezione risulta essere la disposizione orizzontale (nel verso dellalarghezza della valigetta) oppure verticale.

42


La valigetta ricercata, oltre ad avere misure non standard per permettere ladisposizione delle utenze e degli apparati di comando in modo subottimo ma al con-tempo usabile, deve avere l’importante caratteristica di possedere una profonditanon indifferente. Sebbene la sezione layout risulti non particolarmente profonda (<5 cm), la sezione centralino necessita di maggiore profondita data la presenza dimoduli DIN. In particolare l’interrutore magnetotermico presenta nella leva il puntodi 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 passag-gio dei cavi evitando di perdere in praticita all’atto di installazione, soprattutto perla sezione layout. La profondita risultante (> 14 cm) ha rappresentato la caratte-ristica principale della valigetta da ricercare, con particolare attenzione al fatto chesi trattasse di altezza interna e che spesso le valigette difficilmente raggiungono talidimensioni, a meno che non si entri nel campo professionale in cui si possono trova-re anche contenitori su misura, ignifughi e con range altimetrico operativo elevato.E’ evidente che tale campo, oltre che oneroso, risulta essere non necessario per lespecifiche richieste.

In seguito alle considerazioni che vengono presentate nelle sezioni relative, sipossono notare le caratteristiche principali che la valigia ricercata deve possedere:larghezza di almeno 41 cm, altezza di almeno 35 cm e profondita di almeno 16 cm.Quest’ultima misura e risultata essere fonte di notevoli problemi di reperibilita inquanto le classiche valigette “stile 24 ore” reperibili sul mercato non presentano unaprofondita cosı ampia, dato che risulterebbe uno spreco enorme dovendo portarecon se documenti, che, per quanto voluminosi, difficilmente necessitano un vano cosıampio. Ulteriore problema risulta essere la suddivisione della profondita della valigiatra il fondo ed il coperchio della stessa: dovendo inserire dispositivi su entrambe leparti, occorre che essa non solo presenti una profondita complessiva di 16 cm, mache le due sezioni siano di almeno 5 e 9 cm rispettivamente.

Per facilitare il montaggio nei due vani della valigia sono state necessarie dueplance di legno compensato che simulassero la parete nella sezione layout e la co-pertura nella sezione centralino. Essendo una valigia dimostrativa e non una verae propria installazione a muro, i frutti inseriti negli appositi portafrutto e rivestitidalla placche non sono stati inseriti nelle consuete scatole da incasso a parete, masemplicemente avvitate alla plancia superiore in legno, la quale a sua volta e statainserita e fermata nel vano verticale della valigia. Questo ha permesso di avere unamaggiore liberta nel collegamento dei fili elettrici e del cavo bus tra i vari dispositiviivi contenuti, fornendo al contempo una separazione tra utente e fili all’atto dell’u-tilizzo.Nella sezione centralino la plancia in legno simula la copertura in plastica tipica deiquadri luce, inutilizzabile in questo caso data la variazione della distanza tra le duelinee DIN.

Tale pannello ha il fondamentale compito di isolare il cavo EIB/KNX ed i cavi

43


elettrici da un accidentale tocco dell’utilizzatore; cio potrebbe risultare potenzial-mente molto pericoloso, nonostante la presenza dell’interruttore magnetotermico, inquanto al di sotto del pannello vi sono i fili che portano l’alimentazione a tutta lavaligia.

I requisiti della valigia sono riassunti in Tabella 5.2.

DIMENSIONIAltezza > 41 cmLarghezza > 35 cmProfondita

fondo > 5 cmcoperchio > 9 cmtotale > 16 cm

MATERIALEEsterno robusto, antiurtoInterno adatto per fissaggio pan-

nelli in legno e guideDIN

Tabella 5.2. Caratteristiche valigia

La valigia scelta risulta essere una Manutan 1986Y57, capacita 25 l, 410x325x190mm, presentata di seguito (Fig. 5.21).

5.3.1 Sezione layout

Pensando di realizzare due stanze, una possibile soluzione risultava essere quella didisporre 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 dell’interfaccia a tasti, che non risulta visibile ma e nascosta all’inter-no del pannello, necessitava la vicinanza della placca con pulsanti tradizionali laquale, essendo sensibilmente piu ampia degli altri elementi, ha obligato ad occu-pare un’ulteriore linea. Lo spazio avanzato in quest’ultima, oltre a nascondere nelretro la posizione dell’interfaccia a tasti, lascia un’area relativamente comoda perl’inserimento di un’eventuale utenza futura.

In seguito a queste considerazioni la disposizione piu consona e risultata esserequella in orizzontale, lungo il lato piu lungo della valigetta, considerando la maggiorevisibilita di tale sezione: aprendo la valigetta, il fondo rimane poco visibile, ma cioche e il coperchio viene sollevato e rimane posizionato in perpendicolare rispetto alpiano di appoggio, offrendo quindi un’ottima visuale all’utilizzatore.

44


Figura 5.21. Valigia Manutan 1986Y57

Nella figura seguente (Fig. 5.22) si puo vedere la disposizione della sezione layoutcon le misure salienti al fine della realizzazione: la figura risulta ruotata di 90◦ insenso antiorario rispetto alla visuale che si ha aprendo la valigia. Come si puonotare, oltre alle considerazioni fatte in precedenza, vi e dello spazio, seppur nonabbondante, distribuito sui bordi, in particolare nella zona bassa (verso l’attaccaturadelle due sezioni) al fine di permettere il passaggio del cavo del bus e dei fili elettricida una sezione all’altra.

5.3.2 Sezione centralino

La sezione centralino risulta inserita nella parte inferiore della valigia e contieneprincipalmente moduli DIN EN50022. Per evitare spreco di spazio e permettere undimensionamento del centralino piu contenuto di quello standard, le due guide DINnecessarie all’installazione sono state montate direttamente sul fondo della valigia,

45


Figura 5.22. Sezione layout

tralasciando l’inserimento di quello che e il normale supporto ad esse e la relativacopertura in plastica. Quest’ultima e necessaria al fine di non lasciare fili volantia stretto contatto con l’utilizzatore, ma si e stati costretti a realizzarla ad-hoc inquanto, avvicinando le due guide DIN EN50022 per motivi di spazio, la coperturain plastica non trovava piu il suo normale incastro.

Deciso il verso di posizionamento si e cercato di montare gli apparati su guida

46


DIN in modo da ottimizzare i moduli a disposizione ed al contempo operare una mi-nima separazione di sicurezza tra la parte di alimentazione ed i rimanenti apparati.In particolare e stata prestata attenzione al posizionamento dell’alimentatore e del-l’interruttore magnetotermico, inserendoli il piu vicino possibile. Gli apparati chenecessitano di montaggio su guida DIN EN50022 risultavano essere il gateway, l’a-limentatore ed i due attuatori, in aggiunta all’interruttore magnetotermico per si-curezza e due prese (una per l’alimentazione ed una per la LAN) per comodita diutilizzo. Le Tabelle 5.3 e 5.4 mostrano la suddivisione dei dispositivi sulle due guideDIN necessarie, ottimizzando la disposizione sia per l’aspetto della sicurezza, sia perla comodita di utilizzo e configurazione.

APPARATO MODULI OCCUPATIPresa alimentazione 1,5

Presa LAN 1,5Attuatore Abb 4

Gateway 5

TOTALE 12

Tabella 5.3. Disposizione su guida DIN EN50022 - linea sinistra

APPARATO MODULI OCCUPATIInterruttore differenziale 2

Interruttore magnetotermico 2Alimentatore 4

Attuatore Merten 4

TOTALE 12

Tabella 5.4. Disposizione su guida DIN EN50022 - linea destra

La scelta della disposizione delle due guide DIN EN50022 e dettata dalla sceltadi contenere il piu possibile l’occupazione di spazio del bus EIB/KNX, in quanto ifili elettrici risultano molto piu flessibili e pertanto si puo sfruttare tale loro caratte-ristica. Inoltre i dispositivi Abb e Merten presentano i collegamenti su lati oppostie cio suggerisce un montaggio dei primi sulla guida sinistra e gli ultimi su quelladestra.Lo spazio tra le guide risulta occupato dai collegamenti bus, mentre i fili elettricivengono posti lungo passaggi esterni. Cio permette inutili tensioni e torsioni del cavoEIB/KNX, riducendone la possibilita di malfunzionamento per cause meccaniche.

47


In tale sezione sono presenti sia il cavo bus EIB/KNX, contenente il doppinonero/rosso, avvolto nella schermatura e rivestito in plastica verde, sia i fili elettricidi fase (nero), neutro (blu) e terra (giallo/verde).Il montaggio della sezione non ha presentato particolari difficolta in quanto sonostate necessarie solamente di due viti per ogni linea DIN da ancorare al fondo dellavaligia. In Figura 5.23 (ruotata di 90◦ in senso antiorario rispetto alla visuale chesi ha aprendo la valigia) vengono riportate le misure per il posizionamento dellelinee, avvicinandole tra loro rispetto a quanto solitamente fatto nei quadri luce ocentralini, pur mantenendo una distanza tale da permettere il passaggio comodo deicavi e la loro maneggevolezza. Nel lato su cui vi e la giunzione con la sezione layoute stato predisposto spazio adeguato al passaggio dei cavi tra le due sezioni, comealtresı fatto nell’altra sezione.

5.3.3 Collegamenti

La topologia della rete EIB/KNX puo essere una qualunque tra anello, stella o mista,che possono essere considerate equivalenti ai fini della situazione presa in esame.Ogni terminale di connessione bus puo contenere fino a 4 cavi di collegamento comesi puo notare in Fig. 5.24; quindi, per evitare saldature ed intrecci di cavi si edeciso di utilizzare nella sezione inferiore una topologia a centrostella con al centroil gateway, nel cui apposito alloggiamento si sono fatti convergere i fili derivantidall’alimentatore, dai due attuatori ed un ultimo per prolungare il bus nella partesuperiore della valigia (sezione layout).

Questo e stato fatto perche in tale sezione vi sono presenti ancora tre dispositividomotici: l’interfaccia a tasti, la tastiera Abb e la tastiera Merten. Tali dispositivisono 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 effettuati i colle-gamenti elettrici al fine di permettere un utilizzo completo dell’installazione. Persemplicita viene proposto solamente lo schema dei collegamenti (Fig. 5.26) al finedi ottenere cosı una visuale d’insieme il piu chiara possibile.

Unendo le due sezioni negli appositivi vani della valigia si e ultimata la costru-zione del banco di lavoro EIB/KNX richiesto. In Figura 5.27 viene presentata lavisuale della stessa aperta e pronta all’uso.

48


Figura 5.23. Sezione centralino

49


Figura 5.24. Terminale di connessione bus

Figura 5.25. Topologia di rete in oggetto

50


Figura 5.26. Schema elettrico installazione

51


Figura 5.27. Valigia EIB/KNX ultimata

52

Capitolo 6

House Manager

In questo capitolo viene presentata l’architettura interna dell’House Manager, soffer-mandosi sui due livelli logici che lo compongono: l’Abstraction Layer e l’IntelligenceLayer.

6.1 Architettura interna

La struttura interna dell’House Manager e presentata in Fig. 6.1, in cui si possononotare i vari componenti logici.

L’House Manager e architetturalmente organizzato su due livelli, che principal-mente si occupano di fornire interazione con la rete domotica (Abstraction Layer)e con le applicazioni lato utente (Intelligence Layer). Di seguito vengono presentatii moduli facenti parte del gateway, al fine di delinearne la particolare funzione efornendo le basi di conoscenza per la contestualizzazione del lavoro effettuato, cheverra proposto nel capitolo 7.

6.1.1 Intelligence Layer

L’Intelligence Layer rappresenta l’astrazione delle reti a cui l’House Manager e col-legato. In esso vengono rappresentati i singoli dispositivi eterogenei, rendendoliquanto piu omogenei possibile: tale rappresentazione permette una maggiore intera-zione tra gli stessi, in quanto si cerca di abbattere quella difficolta di comunicazioneintrinseca quando si opera con apparati utilizzanti protocolli differenti.

Tramite questo livello all’utente e consentito accedere, gestire ed interagire conla casa, secondo forme e modalita dettate dallo stesso House Manager e che ven-gono presentate all’utilizzatore tramite apposite interfacce, gestite dall’InteractionManager (sezione 4.1.1). Dall’altra parte l’Intelligence Layer interagisce con la casa

53

6 – House Manager

Figura 6.1. House Manager: schema a blocchi

grazie all’Abstraction Layer, attuando i comandi desiderati dall’utente e ricevendoeventuali risposte o messaggi da recapitare a quest’ultimo.

Come si puo vedere nella figura, l’Intelligence Layer e formato da 3 componentiprincipali: l’House Server, l’House Model ed il Rule Engine, che interagiscono tra diloro.

House Server

L’House Server permette all’House Manager di ricevere comandi dall’esterno e adessi rispondere, eventualmente effettuando le necessarie comunicazioni e verifiche

54

6 – House Manager

con l’House Model. Tramite XML-RPC propone una vista dell’installazione domo-tica, fornendo i dati necessari all’interazione con essa e tralasciando gli aspetti dibasso livello (bus) intrinsechi della comunicazione con quest’ultima. L’House Serverfornisce un elenco di dispositivi logici disponibili e ad ognuno di essi abbina un elen-co di possibili comandi. Dall’esterno e quindi possibile ottenere la configurazionedella casa ed interagire con questa, ma la granularita con cui essa viene vista non equella reale ma quella corrispondente alla rappresentazione logica fornita dall’HouseServer.

Per non operare un inserimento di tutti i dispositivi contenuti nella casa ogni vol-ta che si avvia l’House Manager e presente un file di configurazione, il quale contienelo schema XML che descrive le caratteristiche e la disposizione dei vari dispositiviall’interno dell’installazione. Il file e impostato come segue:

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 puo notare la definizione di ogni singolo oggetto software. Ognuno diquesti rappresenta un device reale della rete, a cui e associato l’identificativo univoco(id), il tipo (type) e la tecnologia domotica relativa (tecnologia). Tramite quest’ul-tima si riesce ad associare l’oggetto software (o anche device astratto) di alto livelloal driver corretto al fine di operare la giusta sequenza di operazioni per interagirecon il device domotico relativo.

House Model

L’House Model contiene la rappresentazione astratta dei device domotici presentinella casa; esso aggrega gli oggetti software risultanti suddividendoli in stanze, perrispecchiarne la disposizione reale. E’ in questo componente che si attua la corri-spondenza tra il device astratto, di alto livello (quello logico su cui si opera) e quellodi basso livello (il device domotico presente realmente nella casa). Il device astratto

55

6 – House Manager

altro non e che un oggetto software in cui sono delineate le caratteristiche necessa-rie per l’interazione con esso: principalmente saranno dettagliati lo stato attuale, iltipo di device e l’elenco di comandi pendenti su di esso e in attesa di essere attuatitramite interazione con la rete domotica.

Per meglio comprendere la terminologia e la distinzione che verra utilizzata pertutta la trattazione, viene presentata la seguente figura (Fig. 6.2) che rappresentaun esempio di configurazione in sui si puo notare l’ambiente di lavoro su cui si operaad alto livello (sinistra) e cio a cui questo corrisponde nella rete domotica reale(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 verificarsidi alcune regole e per l’attuazione delle conseguenze ad esse correlate. Tale motoredi regole e realizzato attraverso un applicativo opensource (drools v2.0 [28]) checostantemente monitora la rappresentazione logica della casa (House Model) e valutaun insieme di regole.

Le regole seguono il semplice schema

1 ...2 <java:condition>3 condizione da verificare4 </java:condition>5 <java:consequence>6 codice eseguito se la condizione e verificata7 </java:consequence>8 ...

in cui viene valutato il verificarsi di una o piu condizioni (condition), a fronte del

56

6 – House Manager

quale viene eseguito quanto previsto nella conseguenza (consequence). Nel caso incui la condizione richiesta dalla regola non venga verificata, la regola viene ignorata.

Le regole possono attuare un insieme di comandi utili al verificarsi di alcunesituazioni, siano esse causate dall’utente (ad esempio l’abbassamento delle tappa-relle che causa l’accensione della luce nel locale), siano esse causate da eventi nonimputabili all’utente (ad esempio il sensore di pioggia che rileva acqua sulle finestreaperte e le chiude).

6.1.2 Startup

L’avvio dell’House Manager comporta la seguente sequenza di iterazioni:

1. Caricamento configurazione: vista la necessita di conoscenza dell’instal-lazione e suddivisione della casa viene letta da file la configurazione opportu-na, procedendo quindi alla creazione della corrispondente architettura logicanell’House Model e all’associazione degli oggetti software al driver correttopresente nell’Abstraction Layer.

2. Caricamento scenari: nel caso in cui si desiderino avere funzionalita piuevolute e complesse e necessario apprendere tali impostazioni da un ulteriorefile contenente le regole necessarie. La separazione di queste dalla configu-razione logica relativa ai dispositivi e necessaria sia per l’uso differente a cuisono destinate, sia per il carattere opzionale dell’uso delle regole, contrarioall’assoluta necessita della configurazione dell’architettura logica.

3. Lancio server: viene lanciato il server (House Server) il quale sara in gradodi ascoltare le richieste effettuate dall’utente (comandi) ma anche di interagirecon le reti domotiche a cui l’House Manager e collegato.

6.1.3 Abstraction Layer

Compito dell’Abstraction Layer e quello di operare una traduzione tra il comando dialto livello presente nella coda dell’oggetto software e l’effettivo comando EIB/KNXda inviare su bus. Per fare cio, tale livello deve comprendere il driver necessarioall’interfacciamento con le differenti tecnologie domotiche; in particolare occorreche ogni protocollo venga trattato diversamente, essendo necessario il rispetto dellespecifiche relative.

L’Abstraction Layer permette all’Intelligence Layer di accedere e gestire la casarispettando i protocolli utilizzati in essa.

L’unica rete al momento collegata all’House Manager risulta essere quella BTi-cino e pertanto l’Abstraction Layer contiene il BTicino Driver.

57

6 – House Manager

Il driver si occupa di attuare i comandi e di controllare lo stato dei device domo-tici. La prima funzione viene realizzata tramite un ciclo in cui vengono controllatele code abbinate agli oggetti software; nel caso in cui vi sia presente un comando,si provvedera ad attuarlo, pilotando quindi l’utenza; in seguito verra aggiornato lostato del relativo oggetto software in memoria, al fine di avere sempre una corri-spondenza corretta tra apparato reale presente nella rete domotica e la sua rappre-sentazione astratta presente in memoria.

Nel ciclo di controllo invece il driver opera in polling e richiede lo stato attuale atutti i dispositivi domotici facenti parte della rete a cui esso e abbinato. Una voltaricevuta risposta, opera per aggiornare eventualmente lo stato del device astrattopresente in memoria, assicurando la corrispondenza tra i due.

Il collegamento alla rete domotica avviene tramite LAN al gateway relativo, ilquale si occupera di effettuare le necessarie traduzioni tra il protocollo utilizzato sulbus e quello su LAN con l’House Manager. Per l’accesso alla LAN viene utilizzatoun 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 effettuarele codifiche e decodifiche necessarie per tradurre i messaggi nelle code in comandicorretti per il bus e viceversa.

58

Capitolo 7

SoluzioniAdottate

Nel capitolo precedente e stata presentata l’architettura dell’House Manager nellagranularita necessaria al fine di comprendere il lavoro svolto. In questo capitolo vienefornita la spiegazione di come e stato introdotto un driver nell’Abstraction Layer(Fig. 7.1), per permettere la comunicazione dello stesso con una rete EIB/KNX.

Figura 7.1. KnxDriver da inserire nell’Abstraction Layer

7.1 Driver

Il KnxDriver deve interagire e comunicare con l’Intelligence Layer e la rete domotica(tramite LAN). Nella figura Figura 7.2 viene presentata la differenza macroscopicatra il driver BTicino gia presente nell’House Manager e quello Knx che verra trattatonelle 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 retedomotica tramite il KnxWriter. Dovendo interagire con gli oggetti software deveavere i necessari riferimenti ad essi e mantenerne quindi una lista.

Il comando nella coda messaggi dei vari oggetti device e sempre nella forma 7.1,

room.device.comando (7.1)

viene tradotto nella forma 7.2

destinatario,comando (7.2)

ed inviato alla rete: la realizzazione del collegamento e la gestione della comuni-cazione e demandata al KnxWriter.

Tramite le prime due parti del comando di alto livello (room e device) si iden-tifica il device domotico (o eventualmente il gruppo) interessato. Nel caso delledue valigie, ognuna di esse corrisponde ad una stanza, nominata rispettivamente“valigia Bticino” e “valigia Knx”.

Ad alto livello gli oggetti software vengono identificati con l’indirizzo di gruppo,permettendo quindi all’House Manager di interagire col gruppo nel suo insieme. Sequesto non fosse fatto, occorrerebbe interagire con ogni dispositivo singolarmente,portando ad un incremento del numero di messaggi necessari per effettuare la me-desima comunicazione. Risulta quindi piu performante interagire con il gruppo didispositivi tramite un unico comando, indirizzato al gruppo appunto; inoltre cio

60


permette al tasto che pilota l’utenza di rilevare la variazione di stato della stessa, iltutto in maniera automatica, senza bisogno di alcun settaggio aggiuntivo.

Si provi ad immaginare un esempio per meglio comprendere la situazione. Sidesidera realizzare un collegamento che permetta l’accensione di una luce tramiteapposito tasto: il gruppo che viene formato conterra quindi il pulsante, l’uscitadell’attuatore (su cui e attestata l’utenza) ed il canale di aggiornamento abbinato.Tramite quest’ultimo il gruppo riesce a venire a conoscenza del cambiamento distato della luce e quindi controllarla opportunamente. Questo significa che se il tastoaccende la luce e l’House Manager la spegne, il primo si accorge della variazione edalla successiva pressione provvede ad accenderla nuovamente.

Se invece non fosse realizzato il gruppo, il tasto non capterebbe lo spegnimentoeffettuato da altri device (non necessariamente facenti parte del gruppo, come adesempio l’House Manager) ed alla successiva pressione invierebbe un comando diaccensione inutile, dato che il device domotico risulta gia in tale stato. Questodimostra non solo la facilita di invio di un singolo comando al gruppo invece di ncomandi ai singoli elementi che vi appartengono, ma anche la necessita di avere ungruppo per permettere a piu dispositivi domotici di cooperare correttamente.

Operando con gruppi e non con singoli device, si puo avere un numero maggioredi oggetti software rispetto al numero reale di dispositivi presenti nella rete. Questoe dovuto al fatto che alcuni di essi sono fittizi, cioe non corrispondono ad un vero eproprio device domotico, ma ad un insieme di questi.

7.1.2 KnxWriter

Il KnxWriter permette al KnxDispatcher di inviare su bus i comandi pendenti. IlKnxWriter realizza la connessione alla LAN (tramite l’interfaccia di rete presentesul PC) e di qui alla rete EIB/KNX (attraverso l’IP Gateway); verso la LAN vieneutilizzata una comunicazione UDP e vengono inviati pacchetti in cui sono incapsulatii telegrammi EIB/KNX (KNXoverIP).Per l’incapsulamento e la codifica il KnxWriter si appoggia al KnxEncoder, al qualedemanda i complessi metodi di traduzione da comando di alto livello (letto dallacoda dell’oggetto software) in comando di basso livello (da inviare su bus).

7.1.3 KnxReader

Per permettere all’House Manager di riconoscere lo stato dei dispositivi EIB/KNXsi rende necessario l’inserimento del KnxReader, un server in grado di mettersi inascolto e ricevere le comunicazione dalla rete domotica. Tale figura viene introdottaa causa dell’impossibilita, al momento attuale, di ricevere un ACK (Acknowledgeo conferma) relativo al comando inviato ed una risposta in caso di interrogazionesullo stato di un device domotico.

61


Il KnxReader permette inoltre all’House Manager di rilevare i cambi di stato chele utenze hanno quando vengono premuti i relativi tasti comando. Avendo confi-gurato l’IP Gateway per non effettuare filtraggio sullo scambio di telegrammi, essoinoltra su LAN i comandi EIB/KNX (incapsulandoli in IP) che circolano su bus;questo permette all’House Manager di aggiornare lo stato corrente dell’oggetto soft-ware corrispondente al device domotico che ha subito il cambiamento di stato. Peroperare correttamente il KnxReader necessita l’associazione all’indirizzo multicasta cui l’IP Gateway inoltra i telegrammi incapsulati.

La figura del KnxReader risulta necessaria per permettere la corretta corrispon-denza 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 nell’am-biente. Se viene superata la soglia preimpostata si ha una situazione di pericolo:occorre quindi scatenare un allarme e provvedere ad alcune azioni che permettanoun’opportuna gestione della situazione. Se non fosse presente il KnxReader, la se-gnalazione del sensore rimarrebbe confinata al bus e l’House Manager non sarebbein grado di rilevare nulla; il corrispondente oggetto software risulterebbe nel propriorange operativo e l’inconsistenza potrebbe portare a gravi conseguenze.

Quando riceve un pacchetto UDP il KnxReader provvede ad estrarne il contenutoe tradurlo come telegramma EIB/KNX: da tale telegramma e in grado di riconoscereil gruppo interessato ed il nuovo stato impostato. Dopodiche, tramite il collegamentocon KnxDispatcher, il KnxReader riesce ad accedere al set di oggetti software adesso collegati e variarne lo stato.

7.1.4 KnxEncoder

Il KnxEncoder fornisce adeguato supporto alla traduzione dell’House Manager Pro-tocol (HMP) in EIB/KNX e viceversa, sia al KnxWriter sia al KnxReader. Il primosi occupa di inviare al bus, tramite LAN, un comando e quindi necessita di unacodifica da comando di alto livello a telegramma EIB/KNX; il secondo invece ricevetramite LAN da bus un telegramma e necessita la codifica inversa.

Il comando presente nella coda dell’oggetto software comprende il proprio iden-tificativo logico ed il comando vero e proprio: l’identificativo rappresenta l’indirizzodi gruppo (su 2 byte) da comandare.I comandi attuabili al momento sono solamente quelli di ON e OFF, che permettonoun’interazione base tra i dispositivi EIB/KNX e l’House Manager. Si rimanda alfuturo l’integrazione eventuale di comandi piu complessi.

L’indirizzo di gruppo (riportato in Fig. 7.3 per chiarezza) richiede una codificaleggermente complessa in quanto le parti corrispondenti al main ed al middle devonoessere opportunamente concatenate per formare il primo byte dell’indirizzo, mentreil group andra a formare il secondo byte.

62


Figura 7.3. Struttura indirizzo di gruppo

Lo pseudo-codice seguente (Fig. 7.4) mostra come avviene il concatenamentonecessario per la formazione del primo byte dell’indirizzo di gruppo partendo daidue valori separati.

Figura 7.4. Pseudo-codice per il concatenamento di main e middle

7.1.5 Differenze con BTicino

Il lavoro di progettazione ed inserimento dei moduli necessari al fine di operare cor-rettamente con una rete EIB/KNX e stato eseguito seguendo la struttura prefissatadall’Abstraction Layer dell’House Manager e prendendo come esempio i moduli re-lativi alla rete BTicino.Ovviamente, operando con due tecnologie domotiche diverse, e facile comprendereche vi siano differenze nella realizzazione. Tali differenze risultano essere interes-santi ed occorre soffermarvisi adeguatamente, per meglio comprendere l’interazionedell’House Manager con entrambe. Vengono proposte prima due figure per megliospiegare il funzionamento del modulo Dispatcher nel driver BTicino (Fig. 7.5) eEIB/KNX (Fig. 7.6) utili a migliorarne il paragone fatto in seguito.

63


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) perla rete EIB/KNX, che non trova controparte nella rete BTicino: cio e dovuto prin-cipalmente ad una separazione del meccanismo di ascolto dal Dispatcher relativo, lacui necessita e stata affrontata nella sezione 7.1.3. Mentre il BTicinoDispatcher sioccupa di interrogare i device reali tramite polling e quindi di aggiornare lo stato delcorrispondente device astratto per permettere di avere una corrispondenza valida trai due, il KnxDispatcher non lo fa, in quanto opera secondo un meccanismo differente.Esso infatti non interroga i dispositivi per ottenerne lo stato ma e il KnxReader chesi 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


sul set di dispositivi collegati al KnxDispatcher.

La differenza di meccanismo permette una piu performante attuazione di uncomando rispetto a quanto avviene per BTicino, ma permette soprattutto di ov-viare al comportamento erratico dimostrato nella rete EIB/KNX quando si vogliacontrollare lo stato di un dispositivo domotico. Infatti, anche tramite ETS, la ri-sposta all’interrogazione non e mai sicura ed affidabile: in particolare si nota che ildispositivo interrogato risponde saltuariamente.

Questa incertezza impedisce l’utilizzo di un meccanismo di polling da parte delKnxDispatcher, come avviene invece nel BTicinoDispatcher, ed obbliga all’inseri-mento 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 diun nuovo modulo, il KnxReader appunto, separato dal KnxDispatcher in quantoentrambi necessitano di operare contemporaneamente.

ACK

Altra differenza da sottolineare riguarda la ricezione di un ACK in seguito ad uncomando. Mentre in BTicino, quando un comando viene attuato, viene ricevutoun ACK a conferma dell’avvenuta ricezione ed un successivo controllo dello sta-to permette di verificare non solo l’avvenuta ricezione ma anche la sua attuazione,nell’installazione EIB/KNX cio non avviene. Una volta inviato il comando, il Knx-Dispatcher deve dare per scontato che esso venga ricevuto senza problemi e che lasua attuazione sia sicura. L’unica soluzione attuabile, al momento, risulta quella divariare automaticamente lo stato del device astratto in seguito all’invio del coman-do alla rete: l’avvenuta ricezione e successiva attuazione dello stesso non risultanocontrollabili se non visivamente, ma questo non permette alcun riscontro all’HouseManager. Come detto prima, inoltre, non e affidabile richiedere lo stato attuale adun dispositivo.Questo puo essere fonte di notevoli problemi, primo tra tutti la non corrispondenzatra device astratti e reali, ma al momento non vi e soluzione alternativa. Nel caso incui un comando non venga attuato regolarmente, per motivi la cui spiegazione non equi di interesse, si viene a creare una situazione inconsistente, che puo generare a suavolta una reazione a catena e potenzialmente pericolosa. Occorre sottolineare peroche un ulteriore comando sul medesimo dispositivo non viene preceduto da un test(locale o fisico) sul dispositivo e quindi impone uno stato arbitrario in base princi-palmente a cio che viene visto dall’utente, il quale e in grado di verificare l’avvenutaattuazione del comando precedente (si pensi ad esempio all’accensione di una luce).

65


7.2 Configurazione

Una volta fatti gli opportuni collegamenti fisici ed elettrici tra i componenti domoticioccorre realizzare anche i collegamenti logici, per permettere ad essi di operaresecondo schemi e regole decise dall’utente. Questa configurazione viene attuatatramite ETS (sezione 5.1.3), al momento unica possibilita presente sul mercato chepermetta di effettuare tale operazione.Inizialmente si e pensato di suddividere i device domotici in due stanze, ognunacontenente una tastiera, un attuatore e 4 utenze (2 luci e 2 prese), che per facilitarela visualizzazione risultano disposte orizzontalmente. Esternamente a queste duecamere sono presenti una pulsantiera tradizionale, che permette il comando di utenzein entrambe le stanze, l’alimentatore ed il gateway che permette l’interfacciamentocon l’House Manager.

Nella prima stanza sono presenti:

• una placca con 2 prese;

• una placca con 2 luci, una verde ed una rossa;

• la tastiera Merten;

• l’attuatore Merten.

mentre nella seconda sono presenti:

• una placca con 2 prese;

• una placca con 2 luci, una verde ed una rossa;

• la tastiera Abb;

• l’attuatore Abb.

Per motivi tecnici di aggiornamento dei software ed altre problematiche tecnicherelative agli apparati Merten, si e provveduto alla sola configurazione della stanzainferiore, con soli device Abb.

I problemi hanno riguardato sia la tastiera sia l’attuatore Merten. Quest’ultimonon e riuscito ad essere opportunamente configurato in quanto tramite ETS non erapermesso accedervi, in quanto la versione della BCU richiesta differiva da quella for-nita dal dispositivo. Ogni tentativo di accesso e risultato vano. Probabilmente taledevice viene configurato di default all’uscita della produzione, permettendo quindidi accedervi durante la fase di configurazione, in cui viene scaricato sulla BCU ilsoftware desiderato; una volta tentato di resettare il device per ripristinare la confi-gurazione iniziale, esso ha terminato di funzionare, rendendo impossibile qualunque

66


tipo di accesso.

Per quanto riguarda la tastiera Merten, invece, si sono riscontrati notevoli pro-blemi, soprattutto dovuti al comportamento dei tasti; essi, seppur configurati perinviare comandi di ON e OFF, non si limitano solo a questo e con il loro operatoinfluenzano tutti i gruppi a cui appartengono, portando anche altri dispositivi al mal-funzionamento o al funzionamento secondo un criterio differente da quello stabilito.Maggiori considerazioni vengono apportate successivamente (sezione 7.2.1).

Ogni dispositivo deve essere univocamente identificato da un indirizzo (sezione5.1.2) che ne spieghi la posizione all’interno dell’architettura (Tab. 7.1).

DISPOSITIVO INDIRIZZOIp Gateway 1.1.1Tastiera Merten 1.1.2Attuatore Merten 1.1.3Tastiera Abb 1.1.4Attuatore Abb 1.1.5Interfaccia Tasti Merten 1.1.6

Tabella 7.1. Indirizzi fisici dispositivi

In base alla suddivisione proposta si sono assegnati gli indirizzi singoli, sottoli-neando il fatto che ogni attuatore ha un unico indirizzo individuale, ma ad esso enecessario associare alcuni indirizzi di gruppo per permettere il comando delle uten-ze collegate. Se cio non avvenisse e si comandasse l’attuatore come elemento unico,tutte le utenze su di esso attestate avrebbero un comportamento identico. Questopotrebbe soddisfare una particolare richiesta, ma non soddisferebbe casistiche piugenerali, nelle quali occorre comandare ogni uscita singolarmente: per fare questooccorre inserire ognuna di esse in un gruppo differente, in cui inserire a loro voltaaltrettanti tasti.

Gli indirizzi fisici permettono di identificare il dispositivo hardware, sulla cuiBCU effettuare il download del software e dei parametri che ne permettano il fun-zionamento secondo quanto desiderato. Le utenze (luci e prese) ed i singoli tasti diuna tastiera invece non hanno un indirizzo fisico associato, ma sono raggiungibilitramite gli attuatori (i primi) e le tastiere Abb e Merten (i secondi); con essi siinteragisce tramite indirizzo di gruppo, utilizzato dall’House Manager.Nel caso in cui si voglia accendere la luce attestata come primo canale dell’attuatoreAbb, occorrera inviare un comando di ON al gruppo di cui tale luce fa parte. Perfar cio si puo sia utilizzare un’interfaccia abbinata all’House Manager, sia un tastodomotico (ovviamente appartenente al medesimo gruppo).

67


Su taluni device vi sono canali ausiliari che permettono funzionalita piu evoluteo solamente differenti: essi non vengono configurati in questa sezione e risultano nonoperativi in quanto inutili al fine del lavoro di tesi. Inoltre, una loro attivazione si erivelata a volte dannosa al funzionamento totale dell’installazione.

Visti i problemi riscontrati con l’utilizzo degli apparati Merten, la stanza relati-va risulta inutilizzabile e quindi e stata trattata solamente la stanza Abb di seguitoconfigurata come room con il nome di “valigia Knx” (nella sezione 7.2.2 e riportatala configurazione realizzata); data la presenza di due prese, si e pensato di abbinarealle stesse un ventilatore (presa sx ) ed una radio (presa dx ) al fine di esemplificar-ne l’uso anche tramite esempio. Nella figura seguente (Fig. 7.7) viene presentatala configurazione logica (a sinistra) a cui corrispondono gli elementi presenti nellavaligia (a destra).

Figura 7.7. Corrispondenza oggetti software - device domotici (valigia Knx)

Si sottolinea che per mantenere operativo almeno un tasto Merten (ulterioritasti come detto porterebbero ad un malfunzionamento totale dell’installazione vistala configurazione attuale), si e associato questo alla luce rossa della stanza. Taleconfigurazione verra trattata nel dettaglio nella sezione 7.2.1.

Oltre all’indirizzo singolo, occorre configurare ogni device con un insieme diindirizzi 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;

• un’uscita attuatore;

• un canale di aggiornamento attuatore.

68


Mentre il primo ed il secondo trovano spiegazione nella necessita di collegamen-to per permettere l’attuazione del comando, occorre soffermarsi maggiormente sulterzo oggetto. Esso serve per l’aggiornamento dello stato dell’utenza e la sua comu-nicazione a tutto il gruppo. Se cio non avvenisse non si potrebbe avere un comandodelle utenze da parte di piu soggetti. Questo trova applicazione nel caso in cui visiano almeno due tasti che comandino ad esempio una luce: se uno dei due la ac-cende, l’altro deve essere in grado di spegnerla, ma per far cio deve capacitarsi dellavariazione di stato della luce o, in caso contrario, ne comanderebbe l’accensione esolo successivamente lo spegnimento, intaccando la funzionalita del sistema.A questo si aggiunge il fatto che e necessario che il tasto senta la variazione di stato,in quanto l’utenza e pilotabile dall’House Manager e quindi un comando inviato tra-mite questo produce un cambiamento di stato che deve essere noto a tutto il gruppo,in particolare, al tasto.

Nell’installazione in oggetto sono stati creati i gruppi necessari al controlla daparte dell’House Manager. Nel file di configurazione (sezione 7.2.2) infatti sono pre-senti tutti i device necessari al funzionamento della valigia; essi presentano pero unaparticolarita differente rispetto ai dispositivi BTicino in quanto ogni device astrattonon corrisponde ad un device reale, ma al ruolo dello stesso all’interno di uno deigruppi a cui e associato. Una luce, ad esempio, non viene identificata ad alto livellocome uscita di un attuatore in quanto solo quest’ultimo dispone di un indirizzo fi-sico e quindi essa risulterebbe irraggiungibile semplicemente tramite identificazionecon indirizzo singolo. Essa fara parte, come uscita di attuatore, di un gruppo incui saranno anche presenti un tasto che la pilota ed il canale per l’aggiornamento.Quando ad alto livello si comanda l’accensione dell’utenza, non viene inviato un tele-gramma all’indirizzo singolo del destinatario perche inesistente, ma bensı al gruppointeressato. L’uscita dell’attuatore effettuera la commutazione dello stato dell’uscitarelativa e, tramite il canale di aggiornamento, tutti i partecipanti al gruppo verrannoinformati della variazione.

Questa considerazione permette di capire la mancata corrispondenza tra deviceastratto e device fisico: ad un device fisico infatti possono corrispondere piu deviceastratti, uno per ogni gruppo a cui esso appartiene. Cio comporta anche una man-cata corrispondenza tra numero di dispositivi reali e astratti, in quanto questi ultimipossono essere anche di gran lunga piu numerosi dei primi.

Avendo la possibilita di operare su di un’unica stanza, contenente un attuatoree 4 utenze (2 prese e 2 luci) si e pensato di creare i gruppi in Tab. 7.2.

Come si puo notare, risulta presente un gruppo (1/2/34 ) che permette di pi-lotare tramite un unico tasto (tradizionale) entrambe le luci (verde e rossa). Talegruppo risulta essere, ad alto livello, un device astratto che non corrisponde fisica-mente ad un dispositivo in quanto tale: sia la luce verde che quella rossa risultanogia presenti come device astratti e come tali pilotabili separatamente. L’aggiunta

69


1/2/1 Tastiera Abb (1◦ tasto)Presa sinistraCanale aggiornamento abbinato

1/2/2 Tastiera Abb (2◦ tasto)Presa destraCanale aggiornamento abbinato

1/2/3 Tastiera Abb (3◦ tasto)Luce verdeCanale aggiornamento abbinato

1/2/4 Tastiera Abb (1◦ tasto)Tastiera Merten (tasto in basso a destra)Luce rossaCanale aggiornamento abbinato

1/2/34 Tastiera Tradizionale (1◦ tasto)Luci verde e rossaCanale aggiornamento (luce verde)Canale aggiornamento (luce rossa)

Tabella 7.2. Elenco gruppi nell’installazione EIB/KNX

di questo ulteriore gruppo fa si che entrambe le utenze possano essere pilotate con-temporaneamente tramite il tasto tradizionale abbinato. Non solo: tramite HouseManager e sufficiente interagire con il device astratto per riuscire ad interagire colgruppo allo stesso modo del tasto a cui e consentito il comando.

Per quanto riguarda il gruppo 1/2/4 occorre sottolineare come esso sia formatoda due tasti comando: uno Abb ed uno Merten. Questo pulsante rappresenta l’u-nico elemento Merten configurato durante questa installazione, a causa dei notevoliproblemi che tale apparato puo causare nella configurazione totale.Il tasto del gruppo di cui sopra e configurato per essere una copia fedele del tastoAbb appartenente al medesimo gruppo, riuscendo a condividere con quest’ultimo ilcomando dell’utenza. L’estensione di tale considerazione e configurazione ad altripulsanti della medesima tastiera, al fine di permettere il comando anche delle altre3 utenze rimanenti, non e stato possibile. Infatti, se vengono configurati altri tastiMerten, tutte le tastiere presentano un comportamento totalmente anomalo: allapressione dei tasti (siano essi Merten, siano essi Abb), sul bus vengono inviati co-mandi indecifrabili. E’ da sottolineare che il comportamento non avviene solamenteper la tastiera Merten, ma che questa va ad influenzare anche la tastiera Abb.

L’ipotesi che si puo azzardare e che la pressione dei tasti Merten causi un cambia-mento di stato dell’utenza (e dei relativi tasti appartenenti al gruppo), portandola

70


in uno stato che non puo essere semplicemente catalogato come ON o OFF. Da que-sto stato, qualunque tasto venga premuto (sia Merten sia Abb), non si riesce piu atornare ne allo stato spento (OFF) ne allo stato acceso (ON) utilizzando solamentei tasti domotici. Solamente l’House Manager risulta in grado di forzare la variazioneallo stato desiderato.Dato che questa situazione porta ad un utilizzo non consono dell’installazione, si epensato di configurare solamente un tasto Merten ed assegnarlo al gruppo 1/2/4,dimostrando quindi l’interoperabilita di device di due marche diverse (tasto Mertene attuatore Abb). Non si e in grado, al momento, di permettere una dimostrazionepiu valida, utilizzando un numero maggiore di tasti.

L’utilizzo della tastiera Merten, seppure limitatamente ad un solo tasto, permetteinoltre l’impiego del telecomando abbinato a tale tastiera; esso presenta semplice-mente una serie di tasti a cui sono abbinati i corrispondenti tasti della tastiera. Nelcaso preso in considerazione il pulsante del telecomando da cui si puo comandare adistanza l’utenza risulta essere il numero 8.

E’ possibile inserire numerosi altri gruppi, creandone ad esempio uno in cui sia-no presenti sia le prese sia le luci della stanza, assegnandogli quindi un ruolo diinterruttore generale. Questo puo sembrare a parole molto facile, ma comporta unaconfigurazione tramite ETS ed una successiva aggiunta di un device fittizio nel fi-le di configurazione. Il primo passo risulta necessario in quanto occorre creare unnuovo gruppo a cui associare le opportune uscite degli attuatori, almeno un tastoe i relativi canali di aggiornamento degli attuatori stessi; l’ultimo passo permetteall’House Manager di operare con le due luci come se fossero un’unica entita.Si potrebbe pensare di raggiungere il medesimo risultato creando un nuovo gruppocome contenitore di altri gruppi, una sorta di raggruppamento degli stessi in unaentita piu generale. Questo non e fattibile tramite ETS, in quanto e possibile ope-rare con i singoli oggetti ma non con i gruppi: essi rappresentano gia una sorta diaggregazione e non e possibile aggregare ulteriormente cio che risulta gia aggregato.

Una soluzione intermedia puo pero venir attuata: l’utilizzo di regole permette-rebbe di associare la pressione di un tasto all’invio di un comando ad un insiemedi device. Considerando che si sta trattando con device astratti, siano essi fittizi omeno, risulta possibile raggruppare gruppi di utenze insieme, formando un ulterioregruppo di granularita piu ampia, che permetta ad esempio di attivare/disattivare lastanza inferiore.

Una volta configurata l’installazione con gli indirizzi di gruppo, occorre operarela medesima configurazione anche all’House Manager (sezione 7.2.2), permettendoquindi l’interazione tra rete domotica ed House Manager.

71


Gruppi intervaligia

Per dimostrare l’interoperabilita tra le due valigie collegate all’House Manager evalutarne l’effettiva capacita di collegamento tra tecnologie diverse, si e configuratoopportunamente il sistema per permettere il comando di un’utenza EIB/KNX daun tasto BTicino e di un’utenza BTicino da un tasto EIB/KNX. Per fare questo si edovuto ricorrere all’utilizzo di regole di alto livello, che pilotassero e controllassero icomandi da e per l’House Manager, riuscendo a catturare le informazioni necessarieallo scopo prefissato. In realta, le regole non agiscono direttamente sui comandiinviati o ricevuti ma operano a livello di Intelligence Layer, trattando quindi con glioggetti software ed i loro stati.Per vedere nella pratica come sono state configurate le regole e come esse agiscanoed operino, si rimanda al paragrafo 7.3.

7.2.2 HouseModel

Come spiegato nella sezione 6.1.1, occorre configurare opportunamente il file che rap-presenta la casa al fine di permettere all’House Manager di interagire correttamentecon l’installazione. Per quanto riguarda i device inseriti per la valigia EIB/KNX, sie reso necessario provvedere all’inserimento dei necessari oggetti software secondo loschema presentato nella sezione 6.1.1. In esso ogni valigia corrisponde ad una stanza(room), a sua volta contenente un insieme di device.Il file di configurazione dell’House Manager presentava gia i dispositivi relativi allavaligia BTicino e sono stati aggiunti quelli relativi alla valigia Knx, formando unanuova stanza (room).

1 <ROOM>2 <NAME>valigia_Knx</NAME>3 <DESCRIPTION>Valigia KNX</DESCRIPTION>4 <DEVICE id="1/2/1" type="2" manifacturer="Knx">5 <NAME>presa_sx</NAME>6 <DESCRIPTION>Riga 2 presa sinistra</DESCRIPTION>7 </DEVICE>8 <DEVICE id="1/2/2" type="2" manifacturer="Knx">9 <NAME>presa_dx</NAME>

10 <DESCRIPTION>Riga 2 presa destra</DESCRIPTION>11 </DEVICE>12 <DEVICE id="1/2/3" type="2" manifacturer="Knx">13 <NAME>luce_verde</NAME>14 <DESCRIPTION>Riga 2 luce verde</DESCRIPTION>15 </DEVICE>16 <DEVICE id="1/2/4" type="2" manifacturer="Knx">

72


17 <NAME>luce_rossa</NAME>18 <DESCRIPTION>Riga 2 luce rossa</DESCRIPTION>19 </DEVICE>20 <DEVICE id="1/2/34" type="2" manifacturer="Knx">21 <NAME>luci_verde_e_rossa</NAME>22 <DESCRIPTION>Riga 2 luci rossa e verde</DESCRIPTION>23 </DEVICE>24 <DEVICE id="2/1/1" type="2" manifacturer="Knx">25 <NAME>pulsante_trad_1</NAME>26 <DESCRIPTION>Interfaccia tasti, tasto 1</DESCRIPTION

>27 </DEVICE>28 <DEVICE id="2/1/2" type="2" manifacturer="Knx">29 <NAME>pulsante_trad_2</NAME>30 <DESCRIPTION>Interfaccia tasti, tasto 2</DESCRIPTION

>31 </DEVICE>32 </ROOM>

Come introdotto precedentemente sono presenti 4 entry, le prime 4, che permet-tono all’House Manager di riconoscere le 4 utenze della riga inferiore della valigiaKnx, nel particolare le 2 prese e le 2 luci.A seguire, e presente un device fittizio identificato da 1/2/34 il quale raggruppale luci verde e rossa. Tale gruppo inoltre viene abbinato ad un tasto della tastieratradizionale (1◦ da destra) e permette di operare contemporaneamente su entrambele utenze. Questo gruppo, per come e stato creato, necessita una configurazione daETS: in esso compariranno il tasto comando, i due canali di output dell’attuatoreed i rispettivi canali di aggiornamento ad essi legati.I successivi ultimi due device (2/1/1 e 2/1/2 ) verranno meglio spiegati nella sezione7.3 in quanto necessitano dell’appoggio di alcune regole.

7.3 Regole

Tramite il motore a regole presente nell’House Manager (sezione 6.1.1) e possibi-le inserire funzionalita evolute che risultino di interesse all’utilizzatore; nel caso inesame esse riguardano in particolare le interazioni intervaligia. Infatti, una voltaconfigurati appositamente i vari device astratti, occorre impostare opportunamenteanche alcune regole, per permettere che i comandi e le variazioni di stato relativi aduna valigia vadano ad influire anche sull’altra: mentre l’House Manager, in partico-lare l’Abstraction Layer, si occupera di provvedere all’ascolto e alla ricezione di cioche avviene su una valigia, il motore a regole valutera gli stati rilevati e, nel caso,provvedera a sua volta a creare ulteriori comandi.

73


Vengono di seguito presentati alcuni esempi di configurazioni di regole per megliospiegare quanto asserito precedentemente. Negli esempi riportati si fara riferimen-to alla configurazione riportata in questa sezione, a cui eventualmente verrannoaggiunte le variazioni necessarie quando richiesto.

7.3.1 Esempio base

In questo primo esempio viene presentata una regola molto semplice, per mostrareil lavoro del motore a regole evitando di confondere il lettore con una complessitache verra presentata solo successivamente, una volta compreso il funzionamento dibase.

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()== 27 & 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 funzionalita del tipo: “Se la luce verde e accesa, allora accendi anchela luce rossa”, con riferimento alle due luci della valigia EIB/KNX. Tale regola fasi che venga controllato lo stato della luce denominata luce verde e, nel caso in cuiquesta sia accesa, si provveda ad inviare un comando di accensione alla luce rossa.Pur essendo la regola molto semplice, si puo notare come il test sulla condizione sitrasformi in un controllo sul nome del dispositivo controllato, il suo stato, il suo tipoe la stanza a cui appartiene. Nel caso in cui si voglia testare un ulteriore device incontemporanea (per realizzare un controllo tipo “entrambi accesi”), la parte relativaalla condizione aumenta di consistenza, ostacolando in parte la facile comprensione.Si sottolinea inoltre come tale regola permetta esattamente quanto asserito in prece-denza e nessuna altra funzionalita: se si volesse imporre un funzionamento identicoalle due luci, tramite regole, occorrerebbe inserire un’ulteriore regola, che impongalo spegnimento della luce rossa quando quella verde assume lo stato OFF.Tale regola puo essere scritta come

74


1 <rule name="verdeOFF_rossaOFF">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("luce_verde")5 & device.getStatus().equalsIgnoreCase("OFF")6 & device.getType()== 27 & device.getRoomName().equalsIgnoreCase("


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 esemplificarne la redazione e l’utilizzo), esse possonoportare a false considerazioni e convinzioni. Le due regole precedenti permettonouna corrispondenza tra lo stato della luce rossa e quello della luce verde; tale cor-rispondenza pero viene comandata da quest’ultima luce e quindi nulla accade se avariare di stato e la luce rossa, in quanto nessuna delle due regole proposte presentaalcuna considerazione su tale luce nella parte di condizione. Se si volesse far lavo-rare le due luci realmente in simbiosi tramite regole, occorrerebbe inserire altre dueregole, in cui nella parte di condizione viene valutato lo stato della luce rossa e nellaconseguenza 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 file diconfigurazione, relativamente ai dispositivi interessati per la valigia BTicino (luce 11e luce 12 ).

1 <ROOM>2 <NAME>valigia_Bticino</NAME>3 <DESCRIPTION>la valigia Bticino</DESCRIPTION>4 <DEVICE id="11" type="2" manifacturer="BTicino">5 <NAME>luce_11</NAME>6 <DESCRIPTION>la luce con indirizzo 11</DESCRIPTION>7 </DEVICE>8 <DEVICE id="12" type="2" manifacturer="BTicino">9 <NAME>luce_12</NAME>

10 <DESCRIPTION>la luce con indirizzo 12</DESCRIPTION>11 </DEVICE>12 ...

75


13 ...14 </ROOM>

Si puo notare come, nella valigia denominata “valigia Bticino”, siano presenti idevice chiamati luce 11 e luce 12, corrispondenti a due uscite di un attuatore, noncollegate a vere e proprie utenze, ma il cui stato puo essere visualizzato grazie adun piccolo LED, di cui ogni uscita e fornita.

Dall’elenco device del file di configurazione dell’House Manager (sezione 7.2.2)vengono presi in considerazione i seguenti gruppi, per la creazione di opportuneregole 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 eluce rossa EIB/KNX;

Di seguito viene riportato parte del file di configurazione, nella parte interessatadai gruppi in questione.

1 ...2 <DEVICE id="2/1/1" type="2" manifacturer="Knx">3 <NAME>pulsante_trad_1</NAME>4 <DESCRIPTION>Interfaccia tasti, tasto 1</DESCRIPTION

>5 </DEVICE>6 <DEVICE id="2/1/2" type="2" manifacturer="Knx">7 <NAME>pulsante_trad_2</NAME>8 <DESCRIPTION>Interfaccia tasti, tasto 2</DESCRIPTION

>9 </DEVICE>

10 ...

Entrambi i gruppi permettono il comando di utenze da una valigia all’altra, mail primo in particolare e anomalo e viene spiegato qui di seguito.

Da EIB/KNX a BTicino

In esso infatti, in fase di configurazione in ETS, e stato inserito solamente un tastoe nessuna uscita. Questo e dovuto al fatto che la pressione di tale tasto vieneintercettata dall’House Manager ed essendo abbinato ad un device fittizio (2/1/1 ),ma pur sempre un device, causa lo scatenamento di una regola, la quale provvederaad attuare il comando di due utenze BTicino, nel particolare le due luci (luce 11e luce 12 ). In questo modo si riesce ad effettuare il primo comando intervaligiadesiderato: da un tasto EIB/KNX si comanda un’utenza BTicino.

L’asserzione utilizzata puo essere un’espressione tipo

76


“Se il 1◦ tasto della placca tradizionale e nello stato ON, accendi le luci luce 11 eluce 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()== 27 & 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 un’ulteriore espressione tipo:

“Se il 1◦ tasto della placca tradizionale e nello stato OFF, spegni le luci luce 11 eluce 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()== 27 & 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


per effettuare questo sono

1<rule name="ITF_Knx_luci_11_12_sx_dx_ON">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("pulsante_trad_2")5 & device.getStatus().equalsIgnoreCase("ON")6 & device.getType()== 27 & 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 l’accensione e

1<rule name="ITF_Knx_luci_11_12_sx_dx_OFF">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("pulsante_trad_2")5 & device.getStatus().equalsIgnoreCase("OFF")6 & device.getType()== 27 & 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 e necessaria nel caso si desideri co-mandare l’accensione e spegnimento di una utenza da parte di un tasto presentesulla valigia BTicino. A differenza del caso inverso, non e possibile configurare un

78


pulsante “a vuoto”, cioe senza abbinarlo ad alcuna utenza della medesima tecnolo-gia, in quanto cio non lo rende operativo: una eventuale pressione dello stesso nonviene presa in considerazione e l’House Manager non risulta in grado di captare lasua variazione di stato.

Una soluzione che permetta il comando desiderato risulta essere quella di mante-nere un’accoppiata tasto/utenza sulla valigia BTicino, utilizzando quindi un deviceastratto (in questo caso non fittizio) e poi, tramite regola, accendere/spegnere unaluce EIB/KNX, che a sua volta puo essere o meno pilotabile da tasti della valigiastessa. Quest’ultima caratteristica risulta interessante in quanto un eventuale cam-bio di stato imposto alla luce EIB/KNX deve essere captato per variare a sua voltail device astratto BTicino.Non viene riportata l’esempio di regola in quanto molto simile ai precedenti.

Regole per comandi intervaligia: loop

Un interessante ulteriore esempio di interoperabilita puo essere quello di sfruttare ilmotore a regole e portarlo a creare dei loop di regole, imponendo stati precisi ad uninsieme di luci, in seguito alla variazione degli stessi.Il motore a regole e realizzato per evitare condizioni di stallo di questo tipo; essolavora a stati e se si trova nella condizione per cui una regola porterebbe ad unavariazione che un’altra regola, al medesimo stato, provvederebbe ad annullare, alloraopta per non attuare entrambe le regole. Cio viene fatto in quanto si innescherebbeproprio un loop in quanto entrambe le regole si troverebbero ad agire su un mede-simo elemento (variabile interna del motore a regole) variandone il valore senza sosta.

Un loop interno e quindi impossibile da realizzare secondo quanto spiegato, inquanto il motore a regole per primo ne impedirebbe l’attuazione. Cio detto, rimanecomunque possibile portare il motore a regole ad avviare uno o piu loop esterni, cioeche non vadano ad incidere su variabili interne ma su elementi esterni. In pratica,nell’esempio che segue, vengono prodotti opportuni comandi di accensione/spegni-mento di luci i cui stati vengono valutati nella parte di condizione. Essendo questeesterne al motore a regole ed essendo il numero di stati possibili assumibili non co-nosciuto a priori dal motore, ci si aspetta che esso provveda ad attuare il loop e nonfermarlo, in quanto incapace di riconoscerlo.

Per rendere piu interessante la condizione di loop si puo inserire nell’insiemedi utenze considerate luci delle diverse valigie, dimostrando come l’House Manageroperi con i device astratti di alto livello, indipendentemente dalla loro posizione nellarete e dalla tecnologia da essi utilizzata. Nell’esempio riportato in seguito vengonoutilizzate 3 luci:

• luce verde: luce verde della seconda linea della valigia EIB/KNX;

79


• luce rossa: luce rossa della seconda linea della valigia EIB/KNX;

• luce 11 : luce sul primo canale di uscita del primo attuatore della valigiaBTicino;

sui cui stati vengono applicate una serie di regole logiche. Tali regole vengonoproposte abbinate al relativo codice per comprenderne meglio il funzionamento.

1. “Se la luce verde e 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()== 27 & device.getRoomName().equalsIgnoreCase("


10 house.handleCommand("valigia_Bticino.luce_11.OFF");11 </java:consequence>12 </rule>

2. “Se la luce verde e spenta, accendi la luce 11”

1 <rule name="verdeOFF-11ON">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("luce_verde")5 & device.getStatus().equalsIgnoreCase("OFF")6 & device.getType()== 27 & device.getRoomName().equalsIgnoreCase("


10 house.handleCommand("valigia_Bticino.luce_11.ON");11 </java:consequence>12 </rule>

3. “Se la luce 11 e accesa, spegni la luce rossa”

80


1 <rule name="11ON-rossaOFF">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("luce_11")5 & device.getStatus().equalsIgnoreCase("ON")6 & device.getType()== 27 & 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 e spenta, accendi la luce rossa”

1 <rule name="11OFF-rossaON">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("luce_11")5 & device.getStatus().equalsIgnoreCase("OFF")6 & device.getType()== 27 & 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 e accesa, spegni la luce verde”

1 <rule name="rossaON-verdeOFF">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("luce_rossa")5 & device.getStatus().equalsIgnoreCase("ON")6 & device.getType()== 27 & device.getRoomName().equalsIgnoreCase("


10 house.handleCommand("valigia_Knx.luce_verde.OFF");

81


11 </java:consequence>12 </rule>

6. “Se la luce rossa e spenta, accendi la luce verde”

1 <rule name="rossaOFF-verdeON">2 ...3 <java:condition>4 device.getName().equalsIgnoreCase("luce_rossa")5 & device.getStatus().equalsIgnoreCase("OFF")6 & device.getType()== 27 & device.getRoomName().equalsIgnoreCase("


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 l’accensione o lospegnimento di un’altra tra quelle prese in considerazione.Partendo dal caso in cui esse siano tutte OFF, possono accadere 3 casi, a secondadell’ordine con cui vengono considerate le regole.

Considerando verosimile la valutazione delle regole in ordine, viene soddisfattaper prima la regola n◦ 2, la quale causa l’accensione della luce 11. Questo portaall’utilizzo della regola n◦ 3 che spegne la luce rossa (comando inutile dato che risultagia spenta); in seguito scatta la regola n◦ 6 che a sua volta accende la luce verde.Cio causa lo spegnimento della luce 11, regola n◦ 1 (accesa in precedenza), a cuifa seguito l’attuazione della regola n◦ 4, che comanda l’accensione della luce rossa.Ultimo passo necessario a dimostrare il loop e dato dalla regola n◦ 5, che spegne laluce verde visto lo stato ON della luce rossa.A questo punto si e ritornati allo stato iniziale, da cui si prosegue nuovamenteentrando in loop.

Nella figura seguente (Fig. 7.8) sono presentati gli stati possibili delle 3 luciconsiderate, collegati da archi rappresentanti l’attuazione delle regole di cui sopra.Per facilita di visualizzazione gli stati sono stati rinominati nella forma 7.3

identificativo luce.STATO (7.3)

relativamente alla luce che fa scattare la regola.

82


Figura 7.8. Schema loop con 3 luci

Nello schema precedente si puo notare come la partenza con tutte luci spentepuo portare all’entrata nello stesso da 3 punti differenti, ciascuno utilizzante uncammino unico tra gli stati. Cio che varia e il ciclo minimo che porta alla creazionedi loop, dovuto alla differente partenza.Considerando gli stati in cui le luci risultano passare, i cicli minimi per ogni partenzapossibile 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, icicli 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


Questo insieme di regole, oltre a permettere il loop citato, da anche dimostrazio-ne dell’utilizzo dell’House Manager come figura di collegamento tra l’installazioneBTicino e quella EIB/KNX.

Da questa dimostrazione si evince la pericolosita creata dai loop esterni in quantonon rilevati e gestiti dal motore a regole. Occorre quindi prestare molta attenzionealla realizzazione delle regole, sia da parte della persona che configura la rete, sia daparte dell’utente (se gliene viene data la possibilita).Quest’ultimo caso e molto sconsigliato, data la notevole competenza che gli vienerichiesta e/o la complessita non banale di una guida che lo segua e lo affianchi nellarealizzazione delle regole, valutandone gli impatti sull’intero sistema.

84

Capitolo 8

Conclusioni

In questo capitolo viene analizzato in maniera critica il lavoro svolto. In particolareci si sofferma sui risultati ottenuti una volta ultimato il prototipo, sulle difficoltae/o ritardi di realizzazione e sulla precisione dello stesso nell’attuare cio per cui estato progettato. Viene proposta inoltre una riflessione sulla tesi portata a termine,valutando il lavoro fatto e proponendo eventuali modifiche e/o implementazionifuture.

8.1 Risultati ottenuti

8.1.1 Raggiungimento obiettivi

Con il completamento della configurazione del prototipo si e riusciti a dimostrarei principali due punti che erano stati prefissati nel capitolo 3, cioe l’integrazionedi un driver nell’House Manager al fine di permettere a quest’ultimo l’interazionecon un’installazione EIB/KNX e l’interoperabilita, tramite tale gateway, della reterealizzata con quella preesistente della BTicino. In particolare si e riusciti a dimo-strare, seppure con due installazioni minimali e con interazioni altrettanto basilari,come l’House Manager possa essere la figura centrale che permette di non scegliereuna specifica tecnologia per la rete desiderata ma di scegliere i dispositivi necessarisecondo le proprie esigenze e le capacita di questi ultimi di realizzarle. Sara il ga-teway che realizzera i collegamenti necessari al fine di permettere la comunicazionee l’interoperabilita tra i dispositivi.

Tramite i gruppi intervaligia creati (sezione 7.3) si e potuto dimostrare il comandodi utenze di una valigia tramite pulsanti dell’altra valigia e viceversa. Sebbene questovenga fatto tramite House Manager e verifichi quindi quanto asserito in precedenza,occorre focalizzare la differenza 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, cio risulta facilmente realizzabile tramitedue semplici passi: inserimento del pulsante in un gruppo privo di utenze tramiteETS e realizzazione di una regola che si occupi di testare lo stato ON/OFF di talegruppo e di propagarlo alla luce BTicino corrispondente, che non necessita di unaparticolare configurazione.

Caso differente si ha invece se si vuole realizzare l’altro scenario, cioe il comandodella valigia EIB/KNX tramite pulsante BTicino. Mentre per la parte della primatecnologia non vi e alcuna differenza rispetto a prima, eccezion fatta per la presenzanel gruppo di riferimento della sola utenza senza abbinamento di un tasto, per laconfigurazione della componente BTicino interessata non si puo operare specular-mente. L’House Manager, al momento, non e in grado di rilevare la pressione deltasto se ad esso non e associato un attuatore o comunque un dispositivo da pilotare,appartenente alla rete BTicino. La soluzione in questo caso e al contempo semplicee dannosa: abbinare ugualmente il tasto al canale di un attuatore, permettendoquindi il comando di una luce BTicino al tasto BTicino. Questo permette la catturadella segnalazione da parte dell’House Manager, il quale tramite una regola simileal caso precedente si occupera di pilotare opportunamente l’utenza EIB/KNX.

Tale soluzione risulta semplice in quanto non necessita di particolare complessitadi configurazione, ma dannosa in quanto in Bticino ogni dispositivo puo far parte alpiu di 2 gruppi: inserire un canale come comandabile da un tasto solo per permetterela cattura del comando di quest’ultimo riduce gia il numero di gruppi possibili aduno solamente. Essendo inoltre tale configurazione fatta con lo scopo di comandareun’utenza di un’altra valigia, la possibilita di comando della luce BTicino risultanon richiesta, probabilmente inutilizzata, col risultato che l’appartenenza del canaledi output al gruppo non permette a tale canale di far parte di un altro gruppo,possibilmente piu utile.

In BTicino infatti ogni dispositivo puo essere configurato come appartenente adue gruppi solamente: uno primario ed uno ausiliario, solitamente utilizzati il primoper permettere il comando di utenze tramite pulsante ed il secondo per permettere ilcollegamento ad esempio di sensori e determinati attuatori. Un esempio puo essere ilseguente: si e in presenza di 3 dispositivi (tasto, attuatore per motorino per finestre,sensore pioggia) che necessitano di comunicare tra loro; l’apertura e chiusura dellafinestra e comandata sia manualmente tramite tasto, sia automaticamente tramitesensore di caduta pioggia, il che impone al canale dell’attuatore di essere presentein due gruppi.

Ulteriore considerazione da fare, in particolare valutando il comportamento delledue reti domotiche, riguarda la velocita di interazione con le medesime. La reteEIB/KNX e molto piu reattiva della rete BTicino, aggiorna piu velocemente le va-riazioni di stato ed altrettanto velocemente riesce ad attuare i comandi. Tale pregionon e tanto dovuto ad una intrinseca velocita quando ad una lentezza dell’intera-zione dell’House Manager con l’altra rete. Il Dispatcher (7.1.5) di tale rete infatti

86

8 – Conclusioni

aggiorna gli stati operando in polling, rendendo quindi piu lenti gli aggiornamenti ele attuazioni di comandi.Il driver EIB/KNX invece non lascia effettuare l’aggiornamento degli stati al rela-tivo Dispatcher, essendo impossibile al momento operare una lettura dello stato darete, ma la delega ad un server apposito (KnxReader), il quale rimane in costanteascolto delle evoluzioni degli stati e si occupa di aggiornarne i corrispondenti og-getti software solo quando riceve dati in merito. Non operando in polling evita lamonopolizzazione delle risorse, permettendo quindi una piu veloce attuazione deicomandi.

8.1.2 Problemi riscontrati

Innanzitutto occorre sottolineare che il prototipo non rappresenta un’installazioneoperativa in tutte le proprie funzionalita: come accennato durante la realizzazio-ne esso e un banco di lavoro minimale, formato da utenze base comandabili inmaniera binaria (ON/OFF) ma che comunque necessitano una precedente configu-razione tramite un apposito software, al momento unica possibilita per compieretale operazione.

Progettazione banco

Durante la fase di progettazione del banco di lavoro sono stati riscontrati ritardi edifficolta di comunicazione sia nei contatti sia nel reperimento di cataloghi e ma-teriale informativo. Una prima barriera e stata rappresentata dalla lingua madreparlata dalla gran parte dei fornitori (tedesco), pur esistendo fornitori e rivenditoriin Italia ed avendo EIB/KNX un respiro europeo.Un secondo problema e stata la poca assistenza tecnica ricevuta, in particolare per idispositivi Merten e la difficolta nell’uso di ETS; quest’ultimo e stato utilizzato so-lamente in una versione di prova, in quanto sia la versione completa del programmasia tutte le specifiche del protocollo risultano liberamente consultabili, ma solo aimembri e/o partner del consorzio.

Integrazione in House Manager

Oltre che una barriera intrinseca del software di configurazione di EIB/KNX, visono stati almeno altri due problemi che hanno portato alla necessita di trovare so-luzioni alternative: il mancato ricevimento di un ACK in seguito ad un comando el’instabilita nella risposta in seguito ad interrogazione sullo stato di un dispositivo.Entrambi i problemi sono stati risolti, o per meglio dire arginati dando per scontatoche un comando venga ricevuto correttamente ed attuato dal relativo device e noneffettuando alcuna lettura di stato. In particolare quest’ultima soluzione comporta

87

8 – Conclusioni

potenziali problemi di inconsistenza, ma tramite opportuno server in lettura (Knx-Reader, 7.1.3) vengono catturati i comandi che influiscono sulla variazione di statodei vari dispositivi, aggiornando quindi la copia locale dello stesso. Una lettura dellostato sarebbe consigliabile per sicurezza, ma anche in questo modo si riesce a farcorrispondere correttamente le due entita.

8.2 Conclusioni

Al termine della realizzazione di questa tesi e valutando i risultati ottenuti si possonodelineare alcune conclusioni.

8.2.1 Complessita di EIB

Il protocollo EIB/KNX utilizzato risulta molto complesso da diversi punti di vista,di seguito affrontati.

Architettura di rete

Innanzitutto occorre sottolineare come EIB/KNX, presentato come standard eu-ropeo e possibile panacea nel campo domotico, in realta non solo non lo sia, marisulti essere molto inadatto nell’ambiente della home automation. Esso infatti ri-sulta trovare la sua naturale collocazione nel campo della building automation, vistasoprattutto la notevole architettura di rete su cui e basato. Anche se permette unaversione priva di un’infrastruttura complessa di rete, come visto nella realizzazionedel prototipo in oggetto, EIB/KNX risulta palesemente creato per ambienti che ne-cessitano una suddivisione in linee ed aree secondo quanto stabilito. L’innalzamentoa 256 dispositivi per linea (rispetto a EIB) da una parte permette un utilizzo inambito domestico tramite una singola linea (eliminando quindi parte dell’infrastrut-tura), ma dall’altra mostra anche la visione di grande respiro per cui EIB/KNXrisulta maggiormente adatto, innalzando ad oltre 60.000 i dispositivi utilizzabili inuna installazione.

Dispositivi

Oltre ad una complessa infrastruttura possibile, EIB/KNX presenta anche un altrotipo di complessita, forse maggiormente influente, ricoperta dalla struttura logica diogni dispositivo; ognuno di essi infatti perde la propria figura di semplice apparatoelettrico 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 lapila protocollare ISO/OSI, seppure accorpando taluni livelli.

88

8 – Conclusioni

L’enormita di applicazioni e funzioni disponibili, a seconda del costruttore, suidevice presenti in una rete puo rendere anche molto costoso l’impiego di uno diessi: se gia puo sembrare dubbiosa l’utilita di ognuna di esse, il costo che si devesostenere per il suo acquisto incide pesantemente sul budget a cui si puo attingere.Tale costo rende alquanto proibitivo l’uso dei dispositivi EIB/KNX all’interno diuna abitazione.

In base all’esperienza maturata durante il lavoro effettuato occorre infine sot-tolineare la difficolta nel reperire gli opportuni software aggiornati relativi ad ognidispositivo. Spesso, ammesso di trovare quello necessario al funzionamento basilaredel device, esso risulta essere redatto in lingua tedesca, con ben poche eccezioni perl’inglese e praticamente nessuna per l’italiano.

Configurazione

La configurazione della rete EIB/KNX avviene via software tramite un apposito pro-gramma (ETS), unica possibilita per chi desideri realizzare un’installazione con taletecnologia domotica. Tale programma e stato realizzato appositamente per questafunzione ed offre, oltre alla (tutt’altro che) semplice configurazione visuale, ancheuna serie di supporti aggiuntivi per la gestione e la diagnostica dell’installazione.Tale protocollo richiede dunque una figura aggiuntiva al semplice elettricista in gradodi installare fisicamente i dispositivi, poiche per la configurazione occorre necessaria-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 l’installatore dal configuratore, due persone, elettricista ilprimo, informatico o simile il secondo, che devono cooperare e convivere dove in altricasi (uno per tutti BTicino) ne bastava uno: il primo. Effettivamente e possibileche le due figure coesistano in un’unica persona, ma questa necessita di competenzee certificazioni in entrambi i campi; usando una singola persona come figura di rife-rimento per entrambe le funzioni, essa risulta ricoprire un ruolo piu informatico cheelettrico.

Concludendo, EIB/KNX risulta essere un protocollo architetturalmente comples-so, il cui campo di utilizzo dista dalla semplicita richiesta nella home automation,scenario di studio del caso in oggetto in questa tesi, dai costi non indifferenti e dallagestione tutt’altro che facile ed intuitiva.EIB/KNX altri non e che il vecchio EIB leggermente ampliato e rivisto: sono statiaggiunti alcuni mezzi trasmissivi, ereditati dagli altri protocolli rappresentati nelconsorzio ed e stato aumentato di gran lunga il numero di dispositivi inseribili inun’installazione, ma per la quasi totalita delle altre caratteristiche sono direttamentemutuate da EIB.

89

8 – Conclusioni

8.2.2 Costi della domotica

Fintanto che non si raggiungeranno costi di produzione e quindi prezzi di venditanettamente inferiori e si effettueranno economie di scala, il mercato della domoticain ambito domestico potra rimanere un’area riservata solamente a coloro i quali nonabbiano problemi di disponibilita monetaria.

Cio sembra ragionevole se l’utente che si considera e normodotato ed in salute,ma risulta invece molto iniquo se questi ha forti limitazioni fisico-mentali e taletecnologia gli permetterebbe di essere piu autosufficiente in casa propria.

8.2.3 Modifiche ed implementazioni future

Valutando quanto realizzato fisicamente e logicamente con il prototipo, possonoscaturire suggerimenti per modifiche ed implementazioni future.

Per prima cosa il funzionamento parziale dei dispositivi della valigia suggeriscela ricerca di una soluzione al mancato funzionamento e relativo controllo dei de-vice Merten, sia l’attuatore, con problemi irrisolti di aggiornamento della BCU aduna versione precedente richiesta da ETS, sia la tastiera, che seppure configurataper inviare semplici comandi ON/OFF, in taluni casi invia comandi indecifrabili ecomplessi.

Per un aumento delle performance risulterebbe utile riuscire ad impostare i di-spositivi al fine di obbligarli all’invio dell’ACK e alla risposta quando interrogati,permettendo quindi di testare lo stato di un dispositivo tramite apposito comandoed avere una piu affidabile corrispondenza tra device astratto (nell’House Manager)e device reale presente nella rete.

Puo essere infine interessante valutare l’inserimento di una centralina allarmie/o meteo, formata da alcuni sensori analogici o digitali, quali ad esempio rilevato-ri di fumo, gas, acqua, rottura vetro, vento, pioggia, luminosita, temperatura, perrealizzare scenari in cui si puo dimostrare l’utilita di un meccanismo autonomo edautomatico in grado di provvedere a segnalare un pericolo o una variazione clima-tica importante ed eventualmente di prendere provvedimenti al fine di eliminare oarginare il pericolo oppure attuare scelte di comodita (accensione luce se luminositainsufficiente, chiusura finestre in caso di pioggia, ...).

90

Bibliografia

[1] http://it.wikipedia.org/wiki/Domotica[2] http://www.domotics.com/ix domo.htm[3] http://it.wikipedia.org/wiki/Gabbia di Faraday[4] http://it.wikipedia.org/wiki/Diafonia[5] http://www.cenelec.org/[6] http://www.fcc.gov/[7] http://www.irda.org/[8] http://www.bluetooth.com/[9] http://www.eia.org/

[10] http://www.cebus.org/[11] http://www.jini.org/[12] http://www.echelon.com/developers/lonworks/default.htm[13] http://www.echelon.com/[14] http://www.sun.com/[15] http://www.x10.com/[16] http://www.meti.go.jp/english/[17] http://www.reea.or.jp/[18] http://www.jeita.or.jp/eiaj/english/[19] http://www.echonet.gr.jp/english/index.htm[20] http://www.batibus.com/[21] http://www.ehsa.com/[22] http://www.eiba.com/[23] http://www.konnex.org/[24] P. Pellegrino, D. Bonino, F. Corno, DOMOTIC HOUSE GATEWAY, SAC

2006, ACM Symposium on Applied Computing, April 23-27 2006, Dijon(France)

[25] http://www.myhome-bticino.it/web/home page.page/[26] http://tftpd32.jounin.net/[27] http://sourceforge.net/projects/eibcontrol/[28] http://labs.jboss.com/jbossrules[29] http://elite.polito.it/

91

Integrazione e Sperimentazione dello Standard EIB/KNX in...

Documents

Transcript of Integrazione e Sperimentazione dello Standard EIB/KNX in...