Sei sulla pagina 1di 83

...

Indice

1 Introduzione 6

2 Domotica 9
2.1 I vantaggi della domotica . . . . . . . . . . . 12
2.1.1 Risparmio energetico . . . . . . . . . 12
2.1.2 Comfort . . . . . . . . . . . . . . . . 13
2.1.3 Supporto a disabilità psicomotorie . . 14
2.2 Prodotti commerciali . . . . . . . . . . . . . 15
2.2.1 Virtuoso Home [Ecodhome] . . . . . 15
2.2.2 Di-BOSS [Selex ES] . . . . . . . . . . 17
2.2.3 Clever Energy Manager [Connet] . . 18

3 Descrizione dell’architettura 20
3.1 Home Gateway . . . . . . . . . . . . . . . . 22

2
3

3.2 Domotic Coordinator . . . . . . . . . . . . . 23


3.2.1 Decisore . . . . . . . . . . . . . . . . 25
3.2.2 Database . . . . . . . . . . . . . . . 26
3.2.3 Parser dati . . . . . . . . . . . . . . . 27
3.2.4 Interprete comandi . . . . . . . . . . 27
3.2.5 Controllore dell’operatività dei sistemi 28
3.2.6 Multicast sender . . . . . . . . . . . 28
3.3 Interfacce utente . . . . . . . . . . . . . . . 29

4 Implementazione 30
4.1 Sip Home Gateway . . . . . . . . . . . . . . 31
4.1.1 Session Initial Protocol . . . . . . . . 33
4.1.1.1 ZigBee . . . . . . . . . . . . 36
4.1.1.2 Topologia di rete . . . . . . 37
4.2 Domotic Coordinator . . . . . . . . . . . . . 39
4.2.1 Database . . . . . . . . . . . . . . . 40
4.2.1.1 Tabella SUBSYSTEMS . . 40
4.2.1.2 Tabella NOME SUBSYSTEMS 41
4.2.1.3 Tabella COMMANDS . . . 42
4.2.1.4 Tabella SUBSCRIBERS . . 43
4.2.2 DB connector . . . . . . . . . . . . . 43
4.2.3 Interfaccia SIP fra DC e SHG . . . . 45
4.2.4 Parser dati . . . . . . . . . . . . . . . 47
4

4.2.5 Subscriber . . . . . . . . . . . . . . . 47
4.2.6 Controllore dello stato dei sistemi . . 48
4.2.7 Interfaccia SIP fra DC e User Agent 49
4.2.8 Interfaccia Web Service Rest . . . . . 50
4.2.8.1 Cenni ai Web Service . . . . 50
4.2.8.2 Implementazione . . . . . . 51
4.2.8.3 REST listener . . . . . . . . 52
4.2.9 Interprete dei comandi . . . . . . . . 53
4.2.10 Multicast Sender . . . . . . . . . . . 54
4.2.11 Decisore . . . . . . . . . . . . . . . . 55
4.2.12 Main . . . . . . . . . . . . . . . . . . 57
4.3 Applicazione Android . . . . . . . . . . . . . 57
4.3.0.1 Notifiche Push . . . . . . . 59

5 Validazione tramite lo sviluppo di un prototi-


po 62
5.1 Implementazione del decisore . . . . . . . . 63
5.2 Configurazione del Database . . . . . . . . . 66
5.3 Configurazione e adattamento Home Gateway 67
5.4 Configurazione dei client . . . . . . . . . . . 68
5.5 Svolgimento demo . . . . . . . . . . . . . . . 70
5.5.1 Inizializzazione . . . . . . . . . . . . 71
5.5.2 Invio comandi leciti . . . . . . . . . . 72
INDICE 5

5.5.3 Invio comandi di subscribe . . . . . . 75


5.5.4 Invio comando non lecito . . . . . . . 76
5.5.5 Uscita dalla configurazione critica . . 77
5.5.6 Esecuzione automatica decisore . . . 77

6 Conclusioni 80
Capitolo 1

Introduzione

Negli ultimi anni il mercato della domotica ha vissuto, in


Italia e nel mondo, un notevole sviluppo; si stima una cre-
scita media annua del mercato che supera il 30%, motivo
per cui aziende e enti di ricerca hanno fatto investimenti
per lo sviluppo di nuove soluzioni in ambito domotico, che
possono consistere in soluzioni per la sicurezza, il rispar-
mio energetico e la razionalizzazione dei consumi delle case,
all’intrattenimento e tempo libero fino alla salute e all’assi-
stenza degli utenti. In questo lavoro di tesi si descriverá la
progettazione e l’implementazione di un’architettura, mo-

6
1. Introduzione 7

dulare e multiprotocollare, concepita con lo scopo di fornire


un set di strumenti utili alla realizzazione di un coordinatore
domotico che abbia il compito di amministrare una molti-
tudine di sottosistemi domotici coordinando, nella maniera
piú opportuna e in modo automatico, i comandi inviati da-
gli utenti utilizzatori dei sottosistemi.
La scelta di sviluppare tale architettura deriva dalla tesi se-
condo la quale le scelte che possono essere effettuate all’in-
terno di un particolare sottosistema (ad esempio per quanto
riguarda il risparmio energetico) in maniera piú precisa e
piú ottimizzata se l’elemento che si occupa di compiere la
scelta ha una conoscenza globale di tutti i sottosistemi nella
loro interezza, avendo quindi delle conoscenze estrinseche al
sottosistema in esame.
Nel prosieguo della tesi si andrá dunque a descrivere il con-
cetto di domotica, che cosa é, a cosa serve ed alcuni prodotti
commerciali esemplificativi e come questi si differenzino ri-
spetto alla nostra soluzione. Verrá poi descritta la struttura
dell’architettura della nostra soluzione e come questa sia
stata implementata, garantendo l’estendibilitá a differenti
protocolli e tecnologie in realtiva semplicitá; vedremo infine
la realizzazione di un prototipo funzionante con lo scopo di
1. Introduzione 8

validare l’architettura e mostrare le potenzialitá e i vantaggi


che questa porta.
Capitolo 2

Domotica

Il termine domotica deriva dal neologismo francese do-


motique, a sua volta contrazione della parola greca domos

9
2. Domotica 10

(casa, costruzione) e di automatique (automatica; secondo


altri informatique, informatica): quindi letteralmente casa
automatica.[8]
Con questo termine si vanno ad identificare tutte quelle tec-
nologie integrabili e controllabili in ambito residenziale, ap-
portando cosı̀ benifici all’utilizzatore in termini di efficienza,
sicurezza, funzionalità, estetica, tutto questo in conformità
alle normative vigenti ed alle regole dell’arte. Automatiz-
zare, coerentemente e correttamente, un edificio valorizza
l’immobile stesso; si tratta questo di un dato oggettivo e
non di una valutazione soggettiva. Ad esempio infatti l’al-
legato A della norma tecnica CEI 64-8-V3 [1] afferma che,
utilizzando la domotica, si raggiunge un livello massimo di
prestazione (Livello 3) e di fruibilità di un impianto. Citan-
do la norma questa definisce il livello 3 come “[...] il livello
domotico destinato all’utente che sceglie una casa ai massi-
mi standard di efficienza, sicurezza e comfort [...] consente
di disporre della più avanzata tecnologia domotica: gestio-
ne automatica dei carichi e dei consumi, sensori di sicurezza
[...] tutto controllabile da remoto anche quando non si è in
casa attraverso il cellulare o il pc.”
Nel modello domotico tutti i sottosistemi devono essere ca-
2. Domotica 11

paci di comunicare tra loro e interagire in maniera omo-


genea, perciò le comunicazioni tra il singolo dispositivo e
i vari sottosistemi, siano esse cablate o senza fili, sono di
vitale importanza per il corretto funzionamento dei sistemi
domotici.
I componenti fondamentali di qualunque sistema domotico
sono l’insieme dei sensori e degli attuatori; questi general-
mente vanno a formare una o più reti e ,tra tutte, quelle che
si stanno imponendo con maggior successo sono le Wireless
Sensor Network (WSN); ciò sta accadendo principalmente
perchè la tecnologia senza fili permette una maggior facilità
nell’installazione e nella configurazione della rete, consen-
tendo inoltre di poter installare un sistema domotico anche
successivamente alla costruzione del fabbricato anche lı̀ dove
non era stato previsto in fase di progettazzione. Per l’im-
plementazione delle WSN sono al giorno d’oggi disponibli
diversi standard e tecnologie, nati con l’intento di favorire
l’interoperabilità tra dispositivi resi disponibili da differenti
produttori, come ZigBee, Z-Wave o KNX che sono ormai
largamente diffusi e adottati dalla stragrande maggioranza
delle aziende produttrici.
2.1. I vantaggi della domotica 12

2.1 I vantaggi della domotica

Le applicazioni domotiche consentono di ottenere un sensi-


bile risparmio energetico a vantaggio del bilancio economi-
co dell’utente e alla salute globale del pianeta, migliorare
il comfort domestico e può significare inoltre un aiuto con-
creto a tutti quegli utenti con difficoltà motorie, permet-
tendo di abbattere le barriere architettoniche e tutti quegli
ostacoli che possono rendere complicate anche le azioni più
naturali.[1]

2.1.1 Risparmio energetico

In fase d’uso e di esercizio del sistema domotico è possi-


bile ottenere dei notevoli risparmi riconducibili a circa il
25% per costi energetici rispetto ai sistemi tradizionali [2],
questo grazie a comandi automatizzati (spegnimento degli
impianti in assenza di chi occupa i locali o accensione di
questi poco prima che rientrino) e al controllo degli scenari
(ad esempio l’accensione automatica degli elettrodomesti-
ci secondo le fasce orarie economicamente più vantaggiose
oppure quando l’accensione di più utenze comporterebbe il
superamento della potenza disponibile, oppure prefissando
2.1. I vantaggi della domotica 13

un tetto massimo di budget di spesa che, qualora raggiunto,


ne determini la disattivazione secondo un ordine preventi-
vamente stabilito). Per poter operare al meglio, un siste-
ma di controllo di un edificio ad alta efficienza deve poter
comandare e monitorare gli impianti in funzione di:

• stato di funzionamento dei vari impianti;

• presenza di persone;

• condizioni climatiche esterne;

• condizioni climatiche interne;

• produzione locale energia elettrica/termica;

• sistema di schermatura delle superfici vetrate etc...

2.1.2 Comfort

L’integrazione dei sistemi consente di aumentare il com-


fort nella casa automatizzando azioni della routine quoti-
diana guadagnando in praticità e permettendo di rispar-
miare tempo e fatica. Rendendo la casa in grado di verifi-
care autonomamente i cambiamenti dei fattori ambientali
è possibile fornire agli utenti la possibilità di programmare
2.1. I vantaggi della domotica 14

degli scenari che si attivino automaticamente in presenza di


determinati fattori, come ad esempio:

• sollevare o abbassare le tapparelle in orari diversi a


seconda del giorno della settimana;

• azionare automaticamente l’irrigazione del giardino in


funzione della temperatura e dell’umidità del terreno;

• sollevare le tende o le veneziane in caso di vento e/o


pioggia;

• regolare autonomamente l’illuminazione artificiale in


base a quella proveniente dall’esterno;

• diffusione sonora, aromaterapia, cromoterapia etc...

2.1.3 Supporto a disabilità psicomotorie

Un altro degli obiettivi principali della domotica è sempre


stato quello di realizzare nuovi ausili per persone disabi-
li, affette da handicap e per coloro che, a causa di malattie
neurodegenerative o traumatiche, non hanno più il controllo
volontario dei propri muscoli. A supporto della persona con
disabilità è necessario far sı̀ che i singoli sistemi che com-
pongono la casa non siano indipendenti ma è fondamentale
2.2. Prodotti commerciali 15

che venga reso disponibile all’utente un sistema unico che


comprenda tutte le funzioni di comunicazione ed autonomia
di cui la persona necessita. Bisogna considerare la persona
disabile come elemento attivo all’interno della struttura im-
mobiliare, le strutture edili con cui entra in contatto devo-
no poter interagire e consentire un grado di autonomia alla
persona disabile; quindi l’ambiente e le tecnologie adottate
dovranno necessariamente essere personalizzate sulla base
delle esigenze dell’utilizzatore.

2.2 Prodotti commerciali

L’offerta di prodotti per la domotica è ormai una realtà


consolidata; aziende leader nel settore come Selex ES, Bti-
cino, ABB, Siemens, AMX, Schneider Electric propongono
sul mercato tutta una serie di componenti per la realizza-
zione e l’integrazione di sistemi domotici. In questa sezione
ne illustreremo , a titolo di esempio, alcuni.

2.2.1 Virtuoso Home [Ecodhome]

Virtuoso Home una piattaforma italiana che, mediante l’u-


tilizzo di dispositivi di attuazione e di misura e l’imple-
2.2. Prodotti commerciali 16

mentazione di regole domotiche, consente di incrementare il


comfort casalingo e di ottenere un risparmio energetico. Il
sistema è composto da un gateway che consente il dialogo
tra tutti i dispositivi ad esso collegati (senza fili) utilizzan-
do il protocollo Z-Wave, ha un sistema operativo Linux e
supporta connessioni, oltre al già citato Z-Wave, Ethernet,
Wi-Fi 802.11 b/g/n e GSM/GPRS/3G; è poi possibile acce-
dere al gateway da pc o smarphone per verificare il consumo
e lo stato dei dispositivi.

Figura 2.1: Virtuoso Home

Andando a configurare il gateway sarà quindi possibi-


le ottenere una gestione integrata dell’impianto termico ed
elettrico, avere un controllo costante dell’energia prodotta
2.2. Prodotti commerciali 17

da impianti fotovoltaici ed eolici, avere un controllo sul-


la energia consumata, controllare la temperatura di ciascun
radiatore e agire da remoto sull’accensione o lo spegnimento
delle utenze.
La soluzione offerta dalla Ecodhome si differenzia dal
quella descritta in questo lavoro di tesi per alcune differenze
sostanziali:

• vincola all’utilizzo esclusivo del protocollo Z-Wave;

• l’accesso al gateway é fornito esclusivamente tramite il


software proprietario;

• non provede la possibilitá di separare il dominio in sot-


tosistemi indipendenti differenziando l’accesso a que-
sti.

2.2.2 Di-BOSS [Selex ES]

Di-BOSS (Digital Building Operating System Solution) è


la soluzione di Smart Building sviluppata da Selex ES che
permette di integrare tutte le informazioni provenienti dai
sottosistemi di un edificio, fornendo un quadro completo
dello stato dell’infrastruttura e favorendo cosı̀ l’incremento
2.2. Prodotti commerciali 18

dei livelli di sicurezza. Il sistema utilizza i dati storici, inte-


grandoli con quelli acquisiti in tempo reale, e altri dati come
ad esempio le previsioni meteo o la presenza di persone, e
li utilizza per fornire indicazioni operative necessarie alla
riduzione del consumo energetico nell’edificio e delle emis-
sioni di CO2, mantenendo inalterati i livelli di comfort degli
occupanti.
Le differenze rispetto alla nostra soluzione sono:

• i sottosistemi considerati non sono sistemi indipenden-


ti, ma sono distinti per destinazione d’uso;

• l’accesso al sistema é garantito esclusivamente tramite


software proprietario;

• Di-BOSS fornisce esclusivamente indicazioni delle con-


figurazioni ritenute piú performanti in quel momento,
senza eseguire automaticamente le decisioni prese.

2.2.3 Clever Energy Manager [Connet]

Il Clever Energy Manager garantisce la gestione dell’im-


pianto fotovoltaico estendendolo alla gestione dell’impianto
nella sua interezza. Grazie a sensori amperometrici effettua
le misurazioni della energia prodotta e scambiata verso la
2.2. Prodotti commerciali 19

rete ed analizza l’energia consumata dalle utenze fornendo


un quadro completo della potenza prodotta e consumata,
l’energia prodotta o acquistata o venduta, indicazioni per
l’ottimizzazione dei consumi, permette inoltre di pilotare le
utenze anche da remoto, tutto questo tramite PC, Tablet o
Smartphone grazie ai software forniti nell’installazione.
A differenza del Domotic Coordinator, il Clever Energy
Manager:

• vincola all’utilizzo esclusivo delle componenti domoti-


che fornite dal produttore stesso;

• l’accesso al servizio é fornito esclusivamente tramite il


software proprietario;

• non prevede la possibilitá di separare il dominio in sot-


tosistemi indipendenti differenziando l’accesso a que-
sti;

• si limita a fornire indicazioni sull’ottimizzazione dei


consumi.
Capitolo 3

Descrizione
dell’architettura

In questo capitolo andremo a descrivere l’architettura pro-


gettata e sviluppata in questo lavoro di tesi, approfondendo
le componenti cardine del sistema, e descrivendo ove neces-
sario, eventuali protocolli e standard che sono stati utiliz-
zati.
In Figura 3.1 è possibile osservare una rappresentazione gra-
fica dell’architettura nella quale sono stati inseriti i blocchi
principali che la compongono: in ciascun sottosistema sa-

20
3. Descrizione dell’architettura 21

ranno presenti dei Gateway con lo scopo di disaccopiare le


reti di sensori e gli attuatori, dal piano di controllo; que-
sti si andranno ad interfacciare con il Domotic Coordinator
(DC) attraverso gli standard di comunicazione scelti; il DC
avrá un ulteriore serie di interfacce per la comunicazione
lato utenti, e conterrá al suo interno un inseme di moduli
atti all’analisi del sistema, cardine dei quali é il decisore che
avrá il compito di appunto decidere quali sono le attivitá da
autorizzare o meno, in accordo con le regole implementate
al suo interno.

Protocollo
1 DOMOTIC
HOME GATEWAY 1
COORDINATOR

Protocollo Protocollo
1 1

Protocollo
2
Protocollo Protocollo
HOME GATEWAY 2 2 2
DECISORE

Protocollo Protocollo
N N
DB

Protocollo
N
HOME GATEWAY N

Figura 3.1: Descrizione grafica dell’architettura


3.1. Home Gateway 22

3.1 Home Gateway

Nel Capitolo 2 abbiamo visto come siano nati diversi stan-


dard e tecnologie per l’implementazione delle Wireless Sen-
sors Network (allo scopo di facilitare l’integrazione tra di-
spositivi di differenti aziende produttrici); quello che manca
è però un piano di controllo comune che permetta la gestio-
ne dei componenti, sia che essi implementino tutti lo stesso
standard ma siano prodotti da aziende differenti, sia a mag-
gior ragione che implementino standard tra loro differenti.
Con l’implementazione di un Home Gateway si vuole anda-
re a realizzare un’architettura di tipo modulare nella quale
siano presenti tante interfacce quanti sono i protocolli uti-
lizzati nelle reti di sensori e attuatori DSAN (Domotics Sen-
sor and Actuator Network) integrate nel sottosistema. Una
ulteriore interfaccia che tramite uno specifico protocollo si
occupi di mantenere la connetività fra l’Home Gateway e
il DC, ed infine un livello intermedio di astrazione che per-
metta il disaccoppiamento tra i due domini del sistema e
che si occupi di tradurre i messaggi da e per il particolare
linguaggio della DSAN.
3.2. Domotic Coordinator 23

DOMOTIC HOME GATEWAY


COORDINATOR

Livello di astrazione

Interfaccia
Interfaccia Interfaccia Device
Domotic
Gateway DSAN DSAN
Coordinator

Rete di trasmissione Rete DSAN

Figura 3.2: Home Gateway

3.2 Domotic Coordinator

Il Domotic Coordinator è l’elemento principale di questo


lavoro di tesi, avrà il compito di interfacciarsi con i singoli
sistemi domotici che dovrà amministrare (ovvero con i sin-
goli Home Gateway installati in ogni sistema autonomo), ed
inoltre dovrà interfacciarsi con le applicazioni gestite dagli
utenti tramite le quali sarà possibile inviare e ricevere mes-
saggi al DC. Nucleo del Domotic Coordinator è il decisore;
questo, tramite le regole decise e impostate dall’amministra-
tore, dovrà effettuare delle scelte andando a determinare se
3.2. Domotic Coordinator 24

Figura 3.3: Domotic Coordinator

le richieste inviate dagli utenti rispettino o meno le regole


specificate e, in base a questo, decidere se soddisfare la ri-
chiesta, bocciarla oppure metterla in coda nel caso in cui
un cambio dello scenario potrebbe portare il comando a di-
ventare lecito successivamente.
Le funzioni che quindi il Domotic Coordinator dovrà svol-
gere saranno:

• Ricevere i messaggi di update contenenti il valore dei


sensori e lo stato degli attuatori, salvando la cronologia
di questi in un Database.
3.2. Domotic Coordinator 25

• Determinare la raggiungibilità e l’operatività dei sot-


tosistemi amministrati.

• Inviare comandi agli attuatori tramite gli Home Ga-


teway.

• Ricevere le richieste dagli utenti e gestire una coda di


queste.

• Effettuare le decisioni sulle richieste da soddisfare in


accordo con le regole implementate nel decisore.

• Comunicare agli utenti interessati ogni decisione presa


e ogni modifica effettuata nel sottosistema.

3.2.1 Decisore

Il ruolo del decisore deve essere quello di amministrare e


coordinare le richieste degli utenti affinchè queste non en-
trino in conflitto con le regole decise in fase di implementa-
zione; regole che devono essere formulate in base ai requisiti
che si vogliono soddisfare nel sistema globale come ad esem-
pio il risparmio energetico, consumo di potenza, sicurezza
dei sistemi etc... Il decisore, andando ad analizzare lo stato
dei sistemi in real time e la cronologia di questi memorizzata
3.2. Domotic Coordinator 26

nel database, potrà decidere se rigettare la richiesta, accet-


tarla o metterla in coda, oppure suggerire una soluzione
alternativa che soddisfi la domanda senza andare incontro
all’infrazione delle regole e dei requisiti di sistema.

3.2.2 Database

Nel database verranno memorizzati tutti quei dati utili al


funzionamento e all’operatività del DC; al suo interno do-
vranno essere inseriti i valori registrati nei sensori e gli stati
degli attuatori registrando la cronologia di questi, e diffe-
renziandoli per singolo sottosistema per facilitare una suc-
cessiva analisi, sia da parte del decisore, sia da parte di altri
elementi che debbano utilizzare questi dati (il DC control-
lerà che gli aggiornamenti arrivino con la cadenza prefissata
per verificare il corretto funzionamento del sistema e può
essere previsto un modulo che analizzi i dati per la stima
dei valori medi dei parametri di ciascun sensore). Nel da-
tabase dovranno inoltre essere definite: la lista dei sistemi
disponibili e la relativa interfaccia tramite la quale questi
potranno comunicare con il DC, la coda dei comandi in lista
d’attesa e la lista degli utenti interessati agli eventi in un
particolare sistema grazie al quale il multicast sender (vedi
3.2. Domotic Coordinator 27

3.2.6) potrà informare tutto il gruppo degli eventi occorsi


nel sottosistema.

3.2.3 Parser dati

Ogni Home Gateway dovrà comunicare al DC i valori dei


sensori e lo stato degli attuatori ad intervalli prefissati o nel
caso cambi lo stato di uno dei dispositivi; questi verranno
inseriti in un messaggio che il parser dati avrà il compito
di analizzare e, dopo averli estrapolati dalla stringa, dovrà
andare a memorizzare i parametri nel database inserendoli
nella tabella relativa a quel particolare sistema domotico.

3.2.4 Interprete comandi

Nel DC dovranno essere previste alcune funzioni tramite le


quali gli utenti potranno indicare la volontà di apportare
cambiamenti allo stato dei sistemi o richiedere informazioni
sullo stato di questi. L’interprete dei comandi dovrà quindi
analizzare il comando invitato dall’utente andando ad indi-
viduare che tipo di funzione questo vuole svolgere e qual è il
sistema destinatario della richiesta; una volta ricavati quin-
di il mittente, il tipo di comando, e il destinatario passerà i
3.2. Domotic Coordinator 28

dati al decisore per l’analisi della fattibilità della richiesta.

L’interprete dei comandi, cosı́ come il parser dati visto


nella sezione precedente, sono stati inseriti per permette-
re il disaccoppiamento del decisore e le specifiche inter-
facce implementate che possono cosı́ operare in maniera
indipendente.

3.2.5 Controllore dell’operatività dei sistemi

Il Domotic Coordinator tramite questo modulo esegue dei


controlli ciclici per verificare che i sottosistemi amministrati
siano raggiungibili e stiano effettivamente inviando gli up-
date sullo stato dei componenti; in caso contrario il control-
lore deve prevedere una procedura per ripristinare la conne-
tività tra l’Home Gateway e la relativa interfaccia presente
nel DC.

3.2.6 Multicast sender

Il DC utilizzerà questo modulo per inviare messaggi con-


tententi gli eventi che accadono all’interno di un sistema e
alle decisioni prese riguardo a questo a tutti quegli utenti
3.3. Interfacce utente 29

che, tramite una procedura di registrazione effettuata tra-


mite comando apposito, sono autorizzati a ricevere le notizie
riguardati quel particolare sottosistema domotico.

3.3 Interfacce utente

Data la natura multiprotocollare del DC sarà relativamente


semplice implementare una moltitudine di client differenti,
per permettere ad un utente di poter accedere alle funzio-
nalità offerte tramite differenti dispositivi, reti d’accesso e
protocollo di comunicazione; sarà quindi possibile inviare e
ricevere messaggi da e per il DC con un particolare pro-
tocollo, implementando il modulo relativo e fornendo agli
utenti un applicazione che lo supporti. A seconda dei casi,
e del protocollo in esame, gli utenti potranno usare delle
applicazioni di messaggistica già esistenti sul mercato (ad
esempio potrebbe essere implementato il protocollo SMTP
per permettere all’utente di controllare la casa tramite il
proprio programma di posta elettronica), oppure potrà es-
sere fornita all’utente un’applicazione specificatamente svi-
luppata per facilitare l’usabilità delle funzioni implementate
nel DC.
Capitolo 4

Implementazione

In questo capitolo verranno descritti i passi principali che


costituiscono la fase implementativa del lavoro. Verrá de-
scritto come, a partire da un precedente prototipo realizzato
dal TLC Net Group dell’Universitá di Pisa, siano stati rea-
lizzati gli Home Gateway; verrá descritta l’implementazione
delle classi principali che costituiscono il Domotic Coordina-
tor e come sia stata sviluppata un applicazione Android che
permettesse ad un utente di utilizzare, in modo semplice, le
funzionalitá offerte dal sistema.

30
4.1. Sip Home Gateway 31

4.1 Sip Home Gateway

Per l’implementazione di un Home Gateway si è utilizza-


to il SIP Home Gateway (SHG), sviluppato dal gruppo di
reti del Dipartimento di Ingegneria dell’Informazione del-
l’Università di Pisa [6]; in questo lavoro era stato deciso
di implementare con protocollo SIP un piano di control-
lo comune a tutte le tecnologie per poter sfruttare tutti i
vantaggi derivanti da questo:
• il SIP è un protocollo aperto e molto flessibile;

• sfruttando l’infrastruttura SIP esistente gli utenti han-


no la possibilità di accedere ai servizi forniti dal sistema
tramite qualsiasi Client SIP presente nel mercato;
Era stata cosı̀ realizzata una architettura di tipo modula-
re nel quale furono sviluppate delle interfacce (una per ogni
tipo di protocollo o tecnologia) che si occupassero di comu-
nicare con le reti di sensori e attuatori DSAN (Domotics
Sensor and Actuator Network); nello specifico erano state
implementate due interfacce, una ZigBee e una Bluetooth;
era stato poi sviluppato un Domotics facility abstration che
permettesse il disaccoppiamento tra i due domini del siste-
ma (il SIP e le DSAN), che potevano cosı̀ essere sviluppati
4.1. Sip Home Gateway 32

indipendentemente, e che si occupasse di tradurre i messaggi


ricevuti dagli utenti nel linguaggio specifico di quella parti-
colare DSAN e viceversa, ed infine era stata implementata
un’interfaccia SIP che si occupasse di mantenere la connet-
tività tra il SHG e l’utente. In Figura 4.2 é possibile osserva
la descrizione schematica di quanto appena detto.

Figura 4.1: Descrizione modulare del Sip Home Gateway

Per la realizzazione dell’intero sistema si è partiti da tut-


to questo, andando però a modificare il modo in cui gli
utenti interagiscono con i singoli SHG; questo perché scopo
del DC è creare un ulteriore piano di controllo intelligente
che coordini gli Home Gateway. I SHG quindi non comuni-
cheranno piú direttamente con gli utenti si interfacceranno
costantemente con il DC ricevendo i comandi degli utenti
solo dopo che il decisore inoltrerà la richiesta avendola mar-
cata come conforme alle regole definite nel decisore stesso.
4.1. Sip Home Gateway 33

Nelle due sottosezioni che seguono vedremo un po’ più


nel dettaglio SIP e ZigBee per l’importanza che questi avran-
no nell’implementazione dell’architettura del Domotic Coor-
dinator.

4.1.1 Session Initial Protocol

SIP (Session Initial Protocol) è un protocollo di segnalazio-


ne di livello applicativo, standardizzato dall’ Internet Enn-
gineering Task Force (IETF) nel 1999 [7]. Esso consente la
crezione, modifica o terminazione di una sessione tra uno o
più utenti. Il protocollo SIP permette una buona intergra-
zione con gli altri protocolli definiti per le reti IP come SDP
(Session Description Protocol), RTP (Real Time Transport
Protocol)/RTCP (RTP Control Protocol), ma non è dipen-
dente da essi e può quindi essere utilizzanto senza problemi
con protocolli diversi da questi. Altra caratteristica fonda-
mentale del SIP è l’indipendenza anche dal protocollo di
trasporto sottostante e per questo è possibile utilizzare sia
UDP che TCP.
4.1. Sip Home Gateway 34

Figura 4.2: Architettura SIP

SIP è un protocollo di tipo client-server e ha come ele-


menti principali:

• SIP User Agent (UA): detto anche SIP endpoint,


questo è un software, installato su PC, smartphone o
tablet, che interagisce direttamente con l’utilizzatore;
esso funziona sia come Client (UAC) quando deve in-
viare una richiesta, sia come Server (UAS) quando deve
rispondere.

• SIP Registrar Server: è un server che ha il com-


pito di accettare le richieste di registrazione da parte
degli User Agent presenti all’interno del dominio di re-
te a lui assegnato e deve provvedere a memorizzare le
4.1. Sip Home Gateway 35

informazioni in un Location Server.

• SIP Proxy Server: è un router con il compito di


inviare le richieste dall’UA al successivo SIP server o
ad un altro UA interno alla rete. Questi possono essere
di tipo stateful se ricorda le richieste inviate, le risposte
fornite e i messaggi inoltrati; viceversa si definisce di
tipo stateless.

• SIP Redirect Server: ha il compito di ricevere le


richieste fornendo l’indirizzo di un user agent o di un
server in grado di localizzare l’UA richiesto.

Il protocollo SIP, essendo un modello client-server de-


finisce dei metodi di richiesta e di risposta; la sintassi di
queste segue le specifiche dei messaggi HTTP, sono quindi
composti da tre elementi: la Request (o la Response nel caso
di messaggi di risposta), gli header e il corpo del messag-
gio. Per quanto riguarda i metodi base di richiesta abbiamo
l’INVITE che inizia una chiamata invitando un utente a
partecipare ad una sessione, il BYE che la chiude, l’ACK
per la conferma di ricezione di una risposta e altri metodi
come REGISTER,CANCEL,OPTIONS e INFO
Vi sono poi degli ulteriori metodi detti extension method
4.1. Sip Home Gateway 36

il più importante dei quali, ai fini del nostro lavoro, è il


metodo MESSAGE : questo consente di realizzare servizi di
Instant Messaging basati su SIP dove il corpo della richie-
sta inviata dal mittente è proprio il messaggio che si vuole
inviare al destinatario. Il metodo MESSAGE nel corso di
questo lavoro di tesi è stato utilizzato sia per inviare mes-
saggi di update sullo stato dei sensori e degli attuatori al
DC, che da parte del DC per inviare i comandi alle sin-
gole abitazioni, che da parte degli utilizzatori per inviare i
comandi al coordinator dal proprio client SIP.

4.1.1.1 ZigBee

Lo standard IEEE 802.15.4 [3] definisce il protocollo di


interconnessione, tramite comunicazioni radio, tra i diver-
si dispositivi facente parte di una Personal Area Network
(PAN). Le WPAN (Wireless PAN) vengono utilizzate per
distribuire informazioni su distanze relativamente brevi e
senza cavi di collegamento; scopo delle WPAN è connette-
re piccolo ambienti e infrastrutture favorendo lo sviluppo
di soluzioni economicamente ed energicamente efficienti. Lo
scopo dell’ 802.15.4 è proprio fornire una base per reti i cui
dispositivi sono caratterizzati da bassissimo costo, bassis-
4.1. Sip Home Gateway 37

simo consumo energetico e bassa complessità. Lo standard


definisce i primi due livelli dello stack ISO/OSI [4] : il li-
vello fisico (PHY) e il livello data link del Medium Access
Control (MAC); la definizione di questi due livelli fa sı̀ che
siano garantiti una connessione wireless a basso rate (Low
Rate WPAN) tra i dispositivi, che necessitano di basse po-
tenze di funzionamento offrendo cosı̀ una lunga durata delle
batterie. ZigBee estende i livelli definiti in precedenza soddi-
sfacendo allo standard 802.15.4; opera nelle frequenze radio
per scopi industriali, scientifici e medici, include diverse mi-
sure per evitare interferenze come ad esempio la scelta del
miglior canale durante la fase di inizializzazione, oppure il
cambiare il canale di trasmissione in maniera automatica
nel caso in cui si registri un eccessiva interferenza su quello
in uso.

4.1.1.2 Topologia di rete

Una WPAN deve necessariamente essere composta da al-


meno due dispositivi operanti in uno stessa POS (Personal
Operating Space); per ciascun POS solo uno dei dispositivi
deve essere configurato come PAN COORDINATOR, che
4.1. Sip Home Gateway 38

avrà il compito di iniziare, terminare e redirigire le comuni-


cazioni tra i diversi componenti. La topologia che si viene
cosı̀ a formare è dunque una tipica topologia a stella, dove
ciascun dispositivo può comunicare solo ed esclusivamente
con il coordinatore e sarà quest’ultimo ad inoltrare even-
tualmente i messaggi agli altri nodi; essendo il ruolo del
coordinator fondamentale per la corretta operatività della
WPAN, viene generalmente collegato ad un’alimentazione
fissa mentre gli altri dispositivi possono anche essere ali-
mentati a batteria.

SENSORE

COORDINATOR

SENSORE SENSORE

SENSORE

Figura 4.3: Topologia a stella in ZigBee


4.2. Domotic Coordinator 39

È anche possibile andare a costituire una topologia di ti-


po peer-to-peer che si differenzia da quella a stella in quanto
ogni dispositivo può comunicare direttamente con un altro
dispositivo interno alla rete senza ricorrere alla mediazione
del coordinatore; un topologia di questo tipo si presta mol-
to bene per la formazione di reti di sensori molto complesse
e dense, come ad esempio il controllo e il monitoraggio in
ambito industriale o ambientale.

4.2 Domotic Coordinator

Per lo sviluppo del Domotic Coordinator e di tutti i suoi


moduli è stato utilizzato il linguaggio di programmazione
JAVA. La scelta di questo linguaggio è dovuta principal-
mente ai vantaggi propri della programmazione a oggetti
affiancata alla natura portabile del JAVA che grazie alla
Java Virtual Machine (JVM) realizza infatti un ambiente
di esecuzione omogeneo, che nasconde al software Java (e
quindi al programmatore) qualsiasi specificità del sistema
operativo sottostante permettendo cosı̀ di poter sviluppare
un software eseguibile su qualsiasi piattaforma.
Per interconnettere il DC con il SIP Home Gateway vi-
4.2. Domotic Coordinator 40

sto nella sezione 4.1 è stata implementata una interfaccia


SIP, mentre per quanto riguarda il lato utenti è stata im-
plementata un ulteriore interfaccia SIP e un Web Service
REST che permette l’invio e la ricezione dei messaggi tra-
mite protocollo HTTP; il database infine è stato scelto di
tipo relazionale e nella fattispecie mysql.

4.2.1 Database

Il database denominato DB DOMOTIC COORDINATOR


è costituito da tutte quelle tabelle utili al funzionamento
del domotic coordinator a supporto delle interfacce che lo
compongono e del decisore.

4.2.1.1 Tabella SUBSYSTEMS

La tabella SUBSYSTEMS contiene la lista, riga per riga,


dei sottosistemi che il DC ha il compito di amministrare;
ogni tupla è composta dal campo NAME che identifica uni-
vocamente il particolare Home Gateway, PROTOCOL che
specifica il protocollo utilizzato, l’ID PROTOCOL che è l’i-
dentificativo specifico relativo al protocollo utilizzato (per
esempio il SIP URI se si utilizza il SIP o l’URL se si utilizza
4.2. Domotic Coordinator 41

un web service), ed infine il campo STATE nel quale viene


registrato lo stato ONLINE/OFFLINE di quel particolare
sottosistema.

Figura 4.4: Esempio di tabella SUBSYSTEMS

4.2.1.2 Tabella NOME SUBSYSTEMS

All’interno del Database è necessario creare una tabella


per ciascun sottosistema che raccoglierà al suo interno la
cronologia dei valori dei sensori e lo stato degli attuatori;
ogni tupla sarà quindi composta dal campo TIMESTAMP
che identifica l’istante di arrivo dell’update e da un campo
specifico per ciascun sensore o attuatore.
4.2. Domotic Coordinator 42

Figura 4.5: Esempio di tabella NOME SUBSYSTEMS

4.2.1.3 Tabella COMMANDS

La tabella COMMANDS continere tutti i comandi che il


decisore ha messo in lista d’attesa, in questo caso ogni tu-
pla è composta dal campo NAME che identifica il sot-
tosistema destinatario del comando da eseguire, il campo
COMMAND che specifica la funzione da svolgere, il cam-
po PROTOCOL che specifica da quale interfaccia è sta-
to ricevuto il comando e il campo ID USER che, come
nel caso dell’ID PROTOCOL visto in precedenza, definisce
l’identificativo dell’utente specifico al protocollo utilizzato.

Figura 4.6: Esempio di tabella COMMANDS


4.2. Domotic Coordinator 43

4.2.1.4 Tabella SUBSCRIBERS

All’interno di questa tabella vengono memorizzati, riga per


riga, gli utenti che effettuano una subscribe per essere infor-
mati istantaneamente nel caso un evento modifichi lo stato
del sottosistema per cui hanno effettuato la registrazione;
ogni tupla sarà composta del campo PROTOCOL per me-
morizzare da quale interfaccia è arrivata la subscribe e per-
mettere quindi di poter informare, tramite la stessa, che l’e-
vento è avvenuto, il campo ID USER con la stessa funzione
svolta nella tabella COMMANDS e il campo SUBSYSTEM
che specifica per quale sottosistema l’utente ha effettutato
la subscribe.

Figura 4.7: Esempio di tabella SUBSCRIBERS

4.2.2 DB connector

La classe DBConnector è stata implementata per fornire


alle altre classi uno strumento che permettesse l’astarazione
4.2. Domotic Coordinator 44

del database; i metodi implementati dal DBConnector sono:


• insert: accetta come parametri di ingresso delle strin-
ghe che identificano la tabella nella quale si vuole inse-
rire la riga e i valori dei relativi campi che la compon-
gono, esegue una connessione col database e invia il co-
mando INSERT mysql al server con la stringa costruita
a partire dai parametri in ingresso al metodo;

• delete: metodo molto simile all’insert con la differen-


za che il comando inviato al server mysql è di tipo
DELETE.

• query: accetta come parametri di ingresso la tabella


in cui fare la query e i campi di interesse, restituisce
un oggetto di tipo ResultSet;

• setState: accetta come parametri di ingresso il nome


del sottosistema e il tipo di stato che si vuole definire
(ONLINE o OFFLINE), ha il compito di connettersi
al database e andare a modificare il campo STATE
nella tabella SUBSYSTEMS con il relativo parametro
passato in ingresso;

• setAllOffline: metodo richiamato in fase di inizia-


lizzazione dal DC che serve per resettare la tabella
4.2. Domotic Coordinator 45

SUBSYSTEMS con tutti i campi state impostati su


OFFLINE.

4.2.3 Interfaccia SIP fra DC e SHG

Interfaccia SIP implementata nel DC per poter inviare e


ricevere messaggi con i SIP Home Gateway implementati
in ciascun sottosistema; per il suo sviluppo è stata utiliz-
zata la libreria MjSIP sviluppata dall’Università di Parma
e distribuita sotto licenza GNU GPL. L’interfaccia quindi,
denominata SIPCoordSHG fornisce una serie di metodi allo
scopo di interconnettersi con l’infrastruttura SIP e inviare
o ricevere messaggi attraverso questa:

• register: utilizzando la classe RegistrationClient forni-


ta da MjSIP esegue la registrazione del DC al Registrar
associando il SIP URI e la password e comunicando
l’indirizzo ip e la porta che verranno memorizzati nel
Location Server per garantire la raggiungibilità;

• onRegistrationFailure: nel caso la registrazione non


vada a buon fine comunica tramita una stringa nel
terminale il fatto avvenuto.
4.2. Domotic Coordinator 46

• onRegistrationSuccess: nel caso la registrazione va-


da a buon fine inizializza i database tramite il metodo
setAllOffline, successivamente richiama il metodo sub-
scribe della classe Subscriber descritta nel sottocapito-
lo 4.2.5 ed infine si mette in ascolto tramite il metodo
receive() in attesa di ricevere messaggi sull’interfaccia;
• sendMessage: richiamando questo metodo è possibi-
le inviare messaggi tramite SIP con l’extended method
MESSAGE e accetta come parametri di ingresso il de-
stinatario e il campo body contenente il messaggio; è
stato inoltre necessario implementare i metodi onMa-
DeliveryFailure e onMaDeliverySuccess per verificare
che il messaggio sia stato spedito correttamente o in
caso contrario segnalare il non corretto invio di questo;

• onMaReceivedMessage: richiamato dal metodo re-


ceive() quando un nuovo messaggio raggiunge l’inter-
faccia, questo metodo si occupa di distinguere se il mes-
saggio ricevuto sia un update da parte del SIP Home
Gateway, e in quel caso richiama il metodo parsing del-
la classe DataParser(vedi 4.2.4), oppure che il messag-
gio ricevuto sia la risposta di “subscription accepted”
fornita da SHG (vedi 4.2.5) e in quel caso richiama il
4.2. Domotic Coordinator 47

metodo setState della classe DBConnector per settare


lo stato ONLINE della riga corrispondente al sottosi-
stema che ha accettato la subscribe.

4.2.4 Parser dati

Ogni messaggio di update inviato dagli Home Gateway do-


vrà seguire un certo formato per la composizione della strin-
ga, essa è costituita dal nome del sottosistema e dalle se-
quenze di associazione dell’identificativo del sensore o del-
l’attuatore seguito dal valore di questo; la classe Parser tra-
mite il metodo parsing accetta in ingresso la stringa di up-
date da esaminare e un istanza della classe DBConnector;
andando ad analizzare le sottostringhe che compongono il
messaggio identificherà il sottosistema e i valori dei suoi di-
spositivi, e andrà ad inserire tramite il metodo insert della
classe DBConnector la nuova riga di update nella tabella
NOME SUBSYSTEM.

4.2.5 Subscriber

La classe Subscriber, tramite il metodo doSubscribe, si oc-


cupa di inviare la richiesta di Subscribe agli Home Gateway,
4.2. Domotic Coordinator 48

ovvero la volontà di ricevere da questi i messaggi di update


a intervalli costanti o nel caso cambino gli scenari al lo-
ro interno; il metoto doSubscribe esegue una query di tutta
la tabella SUBSYSTEM e, per ciascun sottosistema rappre-
sentato dalla riga della tabella, invia il messaggio di Subscri-
be all’Home Gateway rappresentato dal campo NAME, at-
traverso l’interfaccia identificata dal campo PROTOCOLL
specificando il realtivo ID PROTOCOL.

4.2.6 Controllore dello stato dei sistemi

Questa classe denominata CheckOffline estende TimerTask


in quanto sarà un Thread che tramite il suo metodo run()
verrà lanciato a intervalli regolari per verificare lo stato di
tutti i sottosistemi amministrati; il metodo run() si occu-
perà quindi di andare ad analizzare i dati conservati nel
database e in particolar modo andrà a verificare, tramite
il campo TIMESTAMP, se l’Home Gateway preso in esa-
me ha smesso di inviare i messaggi di update da più di un
certo tempo limite oltre il quale il sottosistema è dichia-
rato offline; una volta verificato questo andrà a modificare
il campo STATE nella tabella SUBSYSTEM impostandolo
su OFFLINE, e successivamente ripeterà la procedura di
4.2. Domotic Coordinator 49

Subscribe per tutti quei sistemi che a quell’istante abbiano


lo stato di OFFLINE nel campo STATE.

4.2.7 Interfaccia SIP fra DC e User Agent

L’interfaccia SIP lato utenti denominata SIPCoordClient è


un classe molto simile a quella vista in 4.2.3 con alcune
differenze sostanziali:

• una volta che la registrazione del DC lato utenti al SIP


Registrar è andata a buon fine si limita a rimanere in
ascolto su quella porta con il metodo receive, in attesa
di nuovi messaggi ricevuti che andranno poi ad essere
analizzati nel metodo onMaReceivedMessage ;

• questa volta andrà ad identificare i messaggi che de-


scrivono il comando che l’utente vuole eseguire, pas-
sandolo poi all’interprete dei comandi per l’analisi (ve-
di 4.2.9), e i messaggi di subscribe, questa volta da
parte degli utenti, che passera all’istanza del Multi-
castSender (vedi 4.2.10) per l’inserimento nella tabella
SUBSCRIBERS del database.
4.2. Domotic Coordinator 50

4.2.8 Interfaccia Web Service Rest

Dal lato utenti, oltre ad un interfaccia SIP, si è voluto an-


dare ad implentare nel DC un interfaccia Web Service che
tramite protocollo HTTP rendesse possibile una comunica-
zione DC - Utenti tramite un’applicazione Android (vedi
4.3), come esempio di ulteriore tecnologia di controllo.

4.2.8.1 Cenni ai Web Service

Un Web Service è un sistema software che rende possibile


l’interazione tra dispositivi attraverso la rete; esso possie-
de un’interfaccia che può essere descritta attraverso un file,
tipicamente nel formato Web Service Description Langua-
ge (WSDL), tramite il quale viene specificato l’insieme delle
funzionalità offerte. Esistono due tipologie principali di web
service: il SOAP (Simple Object Access Protocol) e il REST
(Representional State Transfer). In questo elaborato si è de-
ciso di utilizzare il REST in quanto il SOAP introduce dei
costi considerevoli in termini di performance in quanto pre-
vede connessioni di tipo stateful, e lo scambio e il parsing
di grandi file ti tipo XML. Il REST invece è un alterna-
tiva leggera alla classica tipologia di web service senza la
4.2. Domotic Coordinator 51

definizione di messaggi SOAP e di interfacce WSDL; nu-


cleo centrale del paradigma REST è il concetto di risorsa:
qualsiasi informazione che possa essere referenziata da un
identificatore URI (Uniform Resource Identifier) [5], può
infatti essere considerata una risorsa.
L’architettura REST prevede che l’interazione con le risorse
avvenga attraverso un limitato insieme di metodi; nel caso
HTTP, utilizzato nell’implementazione del Domotic Coor-
dinator, i metodi a disposizione sono GET, POST, PUT,
DELETE ; il formato usato per la rappresentazione delle
risorse è detto media type ed in genere a questo scopo ven-
gono utilizzati linguaggi come XML o, come fatto nel corso
del nostro lavoro, JSON.

4.2.8.2 Implementazione

L’interfaccia Web Service, in particolar modo REST, è stata


implementata in linguaggio PHP integrato in un web server
Apache, ed è stata poi garantita la comunicazione interpro-
cesso Java-PHP attraverso un socket implementato nel ser-
vizio PHP e nella classe RestListener (vedi 4.2.8.3). Il client
web service quindi, andando a richiamare lo script php da
remoto, tramite il metodo POST passerà come parametro
4.2. Domotic Coordinator 52

il messaggio al server, e questo verrà poi passato al socket


JAVA implementato nel RestListener (vedi sezione succes-
siva). Figura 4.8 è possibile osservare una rappresentazione
schematica della comunicazione interprocesso qui esposta.

Figura 4.8: Comunicazione interprocesso php-java tramite socket

4.2.8.3 REST listener

La classe RestListener estende la classe Threads in quanto


dovrà stare costantemente in ascolta sulla porta associa-
ta al socket in attesa di nuovi messaggi ricevuti; per ogni
messaggio ricevuto attraverso il socket Java-PHP il thread
avrà il compito, cosı̀ come parallelamente svolge l’interfaccia
utente del SIP, di andare a discriminare i messaggi ricevuti
4.2. Domotic Coordinator 53

andando a distinguere se questi si trattino di comandi da


eseguire al decisore oppure messaggi di richiesta di subscri-
be; come per quanto riguarda il SIP (vedi 4.2.7), nel primo
caso i messaggi verranno passati all’interprete dei comandi
(vedi 4.2.9), mentre nel secondo verranno invece passati al
MulticastSender (vedi 4.2.10) per le successive analisi.

4.2.9 Interprete dei comandi

La classe CommandParser, tramite il suo metodo parsing,


ha il compito di analizzare la stringa che compone il messag-
gio ricevuto, andando ad identificare qual è il tipo di coman-
do, l’utente che l’ha inviato (o meglio il suo ID PROTO-
COLL) e la casa destinataria; parametri di ingresso del me-
todo sono la stringa contenente il comando e l’identificativo
dell’interfaccia dalla quale tale metodo è stato richiama-
to, questo per memorizzare in una variabile di tipo String
il tipo di interfaccia che permetterà poi al decisore di co-
municare al richiedente la scelta effettutata su quella de-
terminata richiesta e l’eventuale corretto inserimento nella
tabella COMMANDS del comando messo in lista d’attesa.
Ricapitolande dunque, a partire dalla stringa messaggio, il
CommandParser andrà ad individuare le sottostringhe che
4.2. Domotic Coordinator 54

caratterizzano i vari campi e passerà poi queste informazioni


al costruttore della classe decisore (vedi 4.2.11).

4.2.10 Multicast Sender

La classe MulticastSender, tramite i sue due metodi subscri-


be e sendMessage, ha il compito di amministrare l’insieme
degli utenti, definiti per gruppi, che hanno dichiarato di es-
sere interessati a ricevere gli aggiornamenti sugli eventi che
accadono al sottosistema per cui hanno inviato la subscribe.
Nel specifico i due metodi hanno la funzione di:

• subscribe: inserire nella tabella SUBSCRIBERS una


riga contentente l’utente che ha effettutato la richiesta,
il sottosistema di interesse e l’interfaccia in cui il mes-
saggio di “subscribe” è arrivato che sono ovviamente
anche i tre parametri di ingresso che il metodo richiede;

• sendMessage: inviare a tutti gli utenti che ne hanno


fatto richiesta il messaggio passato come parametro di
ingresso a questo metodo; gli altri parametri richiesti
sono il sottosistema oggetto del messaggio e l’utente
che originariamente ha eventualmente ha inviato il co-
mando che ha causato l’evento che si vuole pubblicizza-
4.2. Domotic Coordinator 55

re; quest’ultimo particolare parametro è stato inserito


in quanto è stato previsto che un qualsiasi utente abbia
la facoltà di poter inviare un comando anche se non ri-
sulta subscriber per il sottosistema in cui vuole andare
ad agire, perciò l’utente attore viene sempre informato
separatamente dal decisore degli eventi che accadono
in conseguenza del suo comando e quindi, per evita-
re messaggi duplicati, il metodo sendMessage invia il
messaggio a tutti gli utenti presenti nella tabella SUB-
SCRIBERS registrati a quel particolare sottosistema
escludendo l’utente che ha originato il comando (nel
caso fosse anche lui subscriber), che verrà in ogni caso
informato dal decisore.

4.2.11 Decisore

La classe DecisionMaker, per come è stata progettata e pen-


sata l’architettura, non ha un implementazione definita e
specifica perchè questa deve essere analizzata caso per caso
in base alle esigenze e alle funzionalità che si vogliono offrire
agli utenti. Vi sono comunque delle linee guida e dei vin-
coli che possono aiutare lo sviluppatore ad implementare al
meglio il decisore:
4.2. Domotic Coordinator 56

• estendere la classe come Thread ed implementare quin-


di il metodo run();

• definire un costruttore nel quale sia possibile passare


all’oggetto dei parametri fondamentali per la succes-
siva analisi come i riferimenti alle interfacce utili per
l’invio dei messaggi agli utenti che hanno inviato i co-
mandi, l’utente che ha inviato il messaggio, l’interfac-
cia in cui il comando è arrivato, il tipo di comando e il
sottosistema destinatario della richiesta;

• per ciascun tipo di comando supportato prevedere un


metodo che compia la decisione, distinguendo se que-
sto metodo è stato lanciato in conseguenza di un nuo-
vo evento “comando ricevuto” oppure se è stato lan-
ciato da un timer task per il controllo periodico della
fattibilità dei comandi in lista d’attesa

• per ciascuna decisione presa, se questa risulta confor-


me alla richiesta comunicare la decisione presa sia al
richiedente sia a tutto il gruppo interessato tramite
MulticastSender, in caso contrario informare esclusi-
vamente il richiedente sia nell’eventualità che la sua
4.3. Applicazione Android 57

richiesta venga bocciata e scartata, sia nell’eventualità


che venga messa in lista d’attesa.

4.2.12 Main

La classe Main, che viene istanziata all’avvio del program-


ma, ha il compito di inizializzare tutte le interfacce imple-
mentate nel Domotic Coordinator, creare due timer task che
avranno il compito di istanziare a intervalli regolari un og-
getto di tipo Coordinator per il controllo dell’eseguibilità dei
comandi in lista d’attesa, e un oggetto di tipo CheckOffline
per la verifica periodica dello stato degli Home Gateway.

4.3 Applicazione Android

A differenza dell’applicazione SIP che verrá poi usata nel


prototipo, di cui non è stato necessario lo sviluppo in quan-
to ci si è serviti di uno dei tanti User Agent presenti sul
mercato (nel caso particolare è stato utilizzato Linphone),
per fornire agli utenti uno strumento in grado di sfrutta-
re le funzionalità del DC attraverso l’interfaccia che offre
il servizio web service, si è deciso di implementare un’ap-
plicazione per smartphone e tablet con sistema operativo
4.3. Applicazione Android 58

Android; l’applicazione avrà la struttura tipica dei servizi


di instant messaging, con una lista scorrevole contentente i
messaggi ricevuti e precedentemente inviati, un componente
editabile per la scrittura del testo da inviare e un pulsante
per l’invio del messaggio.
L’applicazione è stata sviluppata implementando due Acti-
vity, una per la registrazione al server push (vedi 4.3.0.1)
e una per l’invio e la ricezione dei messaggi al DC; è sta-
to inoltre necessario implementare un servizio di Brodacast
Receive per intercettare i messaggi ricevuti tramite il server
push e poterlo passare all’activity principale tramite notifi-
cation.
L’invio di messaggi avviene tramite un AsyncTask che vie-
ne lanciato nel momento in cui l’utente preme il pulsante
invia, il task esegue una richiesta di tipo HTTP al servi-
zio Rest integrato nel DC e tramite il metodo POST passa
come parametro il messaggio che l’utente vuole inviare; vie-
ne passato come parametro anche l’identificativo push che il
DC si occuperà di memorizzare nel campo ID PROTOCOL
delle tabelle per garantire la raggiungibilità dell’utente che
riceverà le risposte dal server push.
4.3. Applicazione Android 59

Figura 4.9: Applicazione Android Domotic Coordinator

4.3.0.1 Notifiche Push

Le notifiche push sono state implementate nei principali


sistemi operativi mobili (Android, iOS, Windows Phone,
BlackBerry OS) per evitare quello che viene generalmente
indicato con il termine polling, ovvero la necessità da parte
di un’applicazione di interrogare ciclicamente il server per
verificare l’eventualità che ci siano aggiornamenti sui dati di
suo interesse; ad esempio nel caso del REST l’applicazione
è obbligata ad eseguire periodicamente una chiamata GET
o POST per verificare se si siano modificati alcuni valori
4.3. Applicazione Android 60

in un determinato server, come per esempio se in un parti-


colare database siano presenti nuove entry di interesse per
l’applicazione stessa.
Quando si utilizzano le notifiche PUSH invece accade l’e-
satto contrario, cioè sarà il server, nel caso accadano nuovi
eventi di interesse per la particolare applicazione installata
in un determinato terminale, a comunicare all’applicazio-
ne il nuovo evento che si è venuto a verificare. Per quanto
riguarda il servizio di notifiche push per Android, che è sta-
to utilizzato nella nostra architettura, le notifiche vengono
inviate dal server al dispositivo, passando per un server in-
termedio di proprietà di Google denominato Google Cloud
Messaging (GCM), questo significa che tutte le notifiche
push di tutte le diverse applicazioni installate sul disposi-
tivo dovranno necessariamente passare per il GCM; si avrà
cosı̀ un dispositivo costantemente connesso ad un unico ser-
ver consentendo di risparmiare notevolmente in termini di
consumi energetici e traffico consumato, in particolar modo
se si confrontano gli stessi parametri nel caso in cui mol-
teplici applicazioni debbano fare altrettanti Polling ad un
numero consistente di server.
4.3. Applicazione Android 61

Figura 4.10: Architettura notifiche push Android


Capitolo 5

Validazione tramite lo
sviluppo di un prototipo

In questo capitolo si andrà a validare l’architettura descritta


nei capitoli precedenti, sviluppando un prototipo funzionan-
te del Domotic Coordinator, implementando un esempio di
decisore e andando ad utilizzare tutti gli strumenti forniti
dal nostro framework. Nel prototipo si emulerà l’esistenza di
quattro sottosistemi domotici e due utenti, che, tramite ap-
plicazioni SIP e Rest, invieranno comandi ed effettueranno
la subscribe ad alcuni dei sottosistemi in esame.

62
5.1. Implementazione del decisore 63

5.1 Implementazione del decisore

Nel caso in esame è stato deciso di implementare un deci-


sore che permettesse di accendere (o spegnere) un impian-
to nel sottosistema destinatario, esclusivamente nel caso in
cui l’avviamento di questo non provocasse il superamento
di una soglia complessiva di potenza; per semplicità, ma
senza per questo perdere di generalità, si è ipotizzato che
in ogni sottosistema fosse installato un unico impianto con
consumo di energia di 10 kWh, con un limite contrattua-
le di carico globale dei quattro sottosistemi di 30 kW. Di
conseguenza, affinchè il sistema non superi la soglia, è ne-
cessario che massimo tre dei quattro impianti siano accesi
contemporaneamente.
In questo scenario gli utenti avranno a disposizione due co-
mandi, il comando critico switch on che dovrá essere ese-
guito esclusivamente nel caso in cui questo non infranga
il limite dei 30kW, e il comando non critico switch off che
puó essere eseguito in ogni caso. In Figura 5.1 sono descritte,
tramite un diagramma di flusso, le operazioni implementate
nel decisore in accordo con lo scenario in esame.
Come si puó osservare in Figura 5.1, nel momento in cui
il decisore viene istanziato, tramite una variabile modificata
5.1. Implementazione del decisore 64

Figura 5.1: Diagramma di flusso del decisore


5.1. Implementazione del decisore 65

dal costruttore, andrá a discriminare se sia stato richiamato


dal timer task o dall’evento “comando ricevuto”.
Nel secondo caso, in principio, andrà ad analizzare il tipo
di comando ricevuto, e se questo si tratta del comando non
critico switch off, inoltrerá la richiesta all’Home Gateway di
destinazione comunicando la decisione al mittente e a tutti
i subscriber; viceversa se il comando è di tipo switch on,
verificherà prima di tutto se nella lista di comandi in coda
sono presenti altre richieste di quel tipo e, in caso affer-
mativo, inserisce il comando in coda (è stata implementata
una coda FIFO senza priorità); nell’eventualità invece che
la coda risulti vuota, andrà a valutare il consumo di ener-
gia presente in quel momento nei sottosistemi, e inoltrerà
la richiesta qualora la somma di questi non superi il limite
imposto di 30 kW; nel caso invece in cui questo limite risul-
ti raggiunto, il comando verrá messo in coda e la decisione
sará comunicata all’utente che aveva effettuato la richiesta;
qualora invece la richiesta venga accolta, il comando verrá
inoltrato al sottosistema destinatario e anche in questo ca-
so verrá comunicata la decisione presa, sia all’utente che ai
subscriber.
Nell’eventualitá in cui il decisore venga istanziato del timer-
5.2. Configurazione del Database 66

task per il controllo periodico della fattibilitá delle richie-


ste in coda, per prima cosa andrá ad estrarre dalla lista il
comando in cima alla coda (nel caso in esame sará esclu-
sivamente di tipo switch on in quanto i comandi in lista
d’attesa sono necessariamente di tipo critico) ed effettuerá
la decisione come visto in precedenza; se il comando risulta
lecito questo verrá eliminato dalla coda, in caso contrario
invece la lista rimarrá invariata.

5.2 Configurazione del Database

Il database va configurato inserendo i parametri richiesti


dal Domotic Coordinator per la fase di inizializzazione; in
particolar modo vanno inseriti nella tabella SUBSYSTEMS
i singoli sottosistemi come mostrato in Figura 5.2: inseren-
do il tipo di protocollo utilizzato (nel caso specifico il SIP)
e l’ID PROTOCOL (nel caso specifico i SIP URI di ciascun
SIP Home Gateway) si specifica al DC come e dove rag-
giungere gli Home Gateway, va inoltre inserito il Name per
permettere all’interprete dei comandi e al Multicast Sender
di ricavare il sottosistema a cui l’utente intende inviare il
comando o la subscribe.
5.3. Configurazione e adattamento Home Gateway 67

Figura 5.2: Configurazione tabella SUBSYSTEMS

5.3 Configurazione e adattamento Home


Gateway

Per il prototipo é stato deciso di utilizzare quattro SIP Ho-


me Gateway, di questi, tre hanno richiesto specifiche modi-
fiche per poter operare simulando al loro interno tre DSAN
nel quale i messaggi di update venivano costruiti andando
a leggere da file il valore di ciascun sensore; nella dimostra-
zione i tre sottosistemi simulati sono rispettivamente Bian-
chi,Verdi e Blu; per quanto riguarda invece il sottosistema
Rossi, il SIP Home Gateway ha il compito di interfacciarsi
con un Sensor Node ZigBee prodotto dalla Freescale Semi-
conductor (Figura 5.3), integrante un sensore di tempera-
tura, un sensore di pressione, un accelerometro e un rice-
5.4. Configurazione dei client 68

trasmettitore RF conforme allo standard 802.15.4. Il sensor


Node integra anche diversi led, e grazie alla possibilitá del-
la board di poter essere riprogrammata per modificarne il
comportamento, sono stati utilizzati i led di stato per si-
mulare l’impianto che é idealmente presente all’interno del
sottosistema: led accesi = impianto in funzione, led spenti
= impianto spento; nei messaggi di update, quindi, il sensor
node comunicherá periodicamente al SIP Home Gateway lo
stado dei led, e li accenderá o li spegnerá in base ai comandi
ricevuti, come illustrato in Figura 5.4

5.4 Configurazione dei client

Nella simulazione saranno presenti due utenti, uno che ac-


cederá al DC tramite PC con l’User Agent SIP Linphone
in un sistema operativo Linux; il secondo invece utilizzerá
l’applicazione Android Domotic Coordinator Messenger da
5.4. Configurazione dei client 69

Figura 5.3: Sensor Node Freescale Semiconductor modello MC1322x

Figura 5.4: Accensione e spegnimento led per simulare impianto


attivo/spento
5.5. Svolgimento demo 70

noi sviluppata, interfacciandosi con il DC tramite Web Ser-


vice. I due utenti per poter accedere dovranno effettuare
pochi passi di configurazione descritti nel seguito:

• l’utente SIP dovrá configurare il proprio user agent af-


finché questo possa effetturare la registrazione trami-
te il proprio SIP Registar dopo ciò potrà accedere al
Domotic Coordinator tramite il SIP-URI configurato
nell’interfaccia SIP lato utente.

• l’utente Android dovrà avviare l’applicazione effettuan-


do, esclusivamente la prima volta che l’app viene av-
viata, la registrazione al server push per ottenere l’i-
dentificativo utile alla sua raggiungibilitá nel prosieguo
della simulazione. Una volta effettutata la registrazione
comparirá l’Activity principale tramite la quale potrá
inviare e ricevere i messaggi.

5.5 Svolgimento demo

In questa sezione si descriveranno, passo per passo, i co-


mandi inviati agli utenti e gli effetti che questi avranno nel
Domotic Coordinator e nei sottosistemi emulati.
5.5. Svolgimento demo 71

5.5.1 Inizializzazione

L’inizializzazione dei sistemi avviene mediante la seguente


procedura:

1. accensione del Sensor Node e del Coordinator ZigBee


relativi al sottosistema Rossi;

2. avvio dei quattro SIP Home Gateway controllando che


le registrazioni SIP effettuate nel Registar Server sia-
no avvenute con successo e che tutti i sistemi siano
operativi;

3. avvio del Domotic Coordinator;

4. inizio fase di subscribe dove il DC comunica a ciascun


SHG la volontà di ricevere i messaggi di update;

Alla fine di questa fase, tutti i sistemi sono operativi e gli


impianti di ciascun sottosistema sono spenti. I SHG iniziano
l’invio periodico al DC dei messaggi di update contenenti
i valori e lo stato dei propri sensori grazie al quale il DC
popolerá le tabelle NOME SUBSYSTEMS.
5.5. Svolgimento demo 72

5.5.2 Invio comandi leciti

Dopo la fase di inizializzazione lo stato dei sistemi risulta


quello illustrato in Figura 5.5, nel quale i quattro impianti
sono spenti e gli utenti non hanno ancora inviato nessun
comando.

Figura 5.5: Stato dei sistemi dopo la fase di inizializzazione

In questa fase si andrá, tramite gli opportuni comandi,


ad accendere tre dei quattro impianti:

1. l’utente che utilizza il client SIP invia al DC il comando


5.5. Svolgimento demo 73

“switch on Bianchi”;

2. il DC, nel momento in cui riceve il messaggio, istanzia


il decisore che, essendo tutti gli impianti spenti, con-
sidera il comando lecito e lo inoltra al SHG di Bian-
chi, inviando all’utente SIP il messaggio con la risposta
“Bianchi switch on eseguito”;

3. l’utente SIP invia lo stesso identico comando per Verdi


ottenendo cosı́ l’accensione dell’impianto e ricevendo
la medesima risposta in quanto anche in questo caso il
comando risulta lecito;

4. l’utente Android invia il comando “switch on Blu” che


risulta ancora lecito ed ottiene a sua volta l’accensione
di Blu e la ricezione del messaggio di conferma;

5. si arriva cosı́ alla condizione critica di tre impianti ac-


cesi su quattro e da questo momento in poi il tentativo
di accendere l’impianto di Rossi porterebbe ad una ri-
sposta negativa da parte del decisore e alla messa in
coda del comando, come mostrato in Figura 5.6;
5.5. Svolgimento demo 74

Figura 5.6: Stato dei sistemi dopo la fase di accensione dei tre impianti
5.5. Svolgimento demo 75

5.5.3 Invio comandi di subscribe

In questa fase i due utenti inviano i comandi subscribe


rispettivamente:

• l’utente SIP invia il comando “subscribe Rossi” rice-


vendo in risposta il messaggio “Subscribe Rossi accet-
tata”;

• l’utente Android allo stesso tempo invia il comando di


subscribe per la casa Bianchi ottenendo il messaggio
di conferma.

Da questo momento quindi i due utenti riceveranno le


notifiche degli eventi del sottosistema per cui hanno effet-
tuato la subscribe e la tabella SUBSCRIBERS é ora com-
posta dalle righe come mostrato in Figura 5.7 dove è pos-
sibile osservare la riga riferita all’utente SIP subscriber di
Rossi dove nel campo ID user èstato memorizzato il rela-
tivo SIP-URI; mentre per quanto riguarda la riga relativa
all’utente Android è stato specificato che il messaggio è ar-
rivato dall’interfaccia REST, ed è stato memorizzato nel
campo ID user l’identificativo utile al server push per poter
inoltrare la notifica all’utente.
5.5. Svolgimento demo 76

Figura 5.7: Tabella SUBSCRIBERS conseguente ai due messaggi di


subscribe

5.5.4 Invio comando non lecito

A questo punto il sistema è in una situazione critica dove è


permessa l’accensione del quarto sistema. Viene inviato, da
parte dell’utente Android, il messaggio “switch on Rossi”, il
decisore quindi, non ritenendo la richiesta accettabile, inse-
risce la riga nella tabella COMMANDS ed invia all’utente
Android un messaggio per avvisarlo della decisione presa
contenente la stringa “Rossi: non é stato possibile esegui-
re lo switch on, il comando é stato messo in coda. Verrai
avvisato non appena sará possibile eseguirlo”; l’utente SIP
invece, nonostante avesse effettutato la subscribe per Rossi,
non riceve nessun messaggio perché dal punto di vista del
sottosistema nulla é cambiato.
5.5. Svolgimento demo 77

5.5.5 Uscita dalla configurazione critica

Il decisore, essendo in configurazione critica, continuerá ad


intervalli regolari a bocciare il comando in coda switch Rossi,
fino a quando uno dei tre sistemi avviati non venga spen-
to da uno degli utenti; con l’intento quindi di uscire dalla
criticitá si opera nella seguente maniera:

• l’utente SIP invia il comando “switch off Bianchi” e


questo, essendo un comando non critico, viene imme-
diatamente inoltrato dal DC verso il SHG di Bianchi;

• l’utente SIP riceve la conferma dello spegnimento tra-


mite il messaggio “Bianchi switch off eseguito”;

• l’utente Android, in quanto subscriber di quel sottosi-


stema, riceve da parte del Multicast Sender lo stesso
messaggio di avvenuto spegnimento ricevuto dall’uten-
te SIP.

5.5.6 Esecuzione automatica decisore

Infine, essendo ora il sistema uscito dalla configurazione


critica, all’avvio automatico del decisore per il controllo
periodico da parte del timer task accade che:
5.5. Svolgimento demo 78

• il decisore sommando ora i valori ricevuti dai quattro


sottosistemi rivela il cambiamento e considera questa
volta il comando in coda di switch on lecito;

• il DC inoltra quindi la richiesta di accensione dell’im-


pianto a Rossi, arrivando cosı́ alla situazione mostrata
in Figura 5.8 ;

• l’utente Android, mittente originario della richiesta, ri-


ceve il messaggio di avvenuta accensione “Rossi switch on
eseguito”;

• l’utente SIP, in quanto subscriber di Rossi, riceve da


parte del Multicast Sender lo stesso messaggio conte-
nenente la notizia che l’impianto di Rossi é ora acceso.
5.5. Svolgimento demo 79

Figura 5.8: Stato dei sistemi successivo alll’avvio automatico del


decisore
Capitolo 6

Conclusioni

Con questo lavoro di tesi abbiamo cercato di mostrare le


potenzialitá che può avere un’architettura come quella qui
proposta; attraverso la costruzione modulare delle compo-
nenti abbiamo reso possibile, in maniera relativamente sem-
plice, estendere l’architettura ad altri di protocolli di comu-
nicazione e ad altre tecnologie in ambito domotico e, come
abbiamo dimostrato nello sviluppo del prototipo, per poter
usufruire degli strumenti bisognerà limitarsi ad implemen-
tare l’Home Gateway opportuno all’interno dei sottosistemi
da amministrare, scegliere a quali regole il decisore dovrá

80
6. Conclusioni 81

fare riferimento e tramite quali comandi, quali interfacce


offrire lato client e tramite quali applicazioni.
Per quanto riguarda gli sviluppi futuri di cui la nostra
architettura può beneficiare, questi riguardano soprattut-
to l’estendere l’architettura ad un numero di protocolli di
comunicazione e di tecnologie domotiche sufficienti a copri-
re la maggior parte delle soluzioni proposte attualmente sul
mercato o in fase di sviluppo. È importante inoltre integrare
un livello aggiuntivo di sicurezza per garantire la riservatez-
za dei dati e il controllo degli accessi.

Ecco quindi alcuni sviluppi futuri da noi concepiti:

• estensione ad altri protocolli di comunicazione e ad al-


tri standard domotici (per esempio KNX, Z-Wave, Web
Service SOAP, XMPP...);

• implementazione di decisori con algoritmi piú sofistica-


ti (ottimizzazione consumi, risparmio energetico e sal-
vaguardia dell’ambiente, sicurezza degli occupanti...)

• sicurezza negli accessi sia al Domotic Coordinator che


ai singoli sottosistemi (accesso autenticato);

• riservatezza dei dati (cifratura dei dati).


Bibliografia

[1] Cei: 64-8/3:2012, impianti elettrici utilizzatori a tensione nominale non


superiore a 1 000 v in corrente alternata e a 1 500 v in corrente continua
parte 3: Caratteristiche generali.
[2] Cen-en15232:2011, energy performance of buildings -impact of building
automation, controls and building management.
[3] Ieee: 802.15.4, ieee standard for local and metropolitan area networks–
part 15.4: Low-rate wireless personal area networks (lr-wpans).
[4] Iso/iec: 7498-1, information tecnology - open systems interconnection -
basic reference model: The basic model.
[5] T. Berners-Lee, R. Fielding, and L. Masinter. Rfc 3986, uniform
resource identifier (uri): Generic syntax, 2005.
[6] R. G. Garroppo, L. Gazzarrini, S. Giordano, and L. Tavanti. Experi-
mental Evaluation of a SIP-Based Home Gateway with Multiple Wire-
less Interfaces for Domotics Systems. Journal of Computer Networks
and Communications, 2012:1–15, Nov. 2012. Article ID 190639.

82
BIBLIOGRAFIA 83

[7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson,


R. Sparks, M. Handley, and E. Schooler. Sip: Session initiation protocol,
2002.
[8] D. Trisciuoglio. Introduzione alla domotica. Tecniche nuove, 2005.