POLITECNICO DI TORINO
III Facoltà di Ingegneria dell’Informazione
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea Specialistica
Z-Wave portable energy profiler
Relatori:
prof. Fulvio Corno
ing. Dario Bonino
Candidato:
Davide Aimone
matricola: 167138
Dicembre 2013
This work is subject to the Creative Commons Licence
A mia mamma e mio
papà che prima di
chiunque altro mi
hanno spinto a
realizzare i miei sogni
Sommario
Questa tesi di Laurea tratta la progettazione e lo sviluppo di un sistema portatile di
monitoraggio dei consumi tramite dispositivi Z-Wave. La soluzione qui proposta
si basa sul gateway domotico Dog e sulla piattaforma hardware Raspberry Pi.
Verranno illustrate le soluzioni adottate per lo sviluppo del sistema completo: dalla
stesura dei driver per la comunicazione con i sensori fino all’interfaccia utente per
la visualizzazione e l’analisi dei dati raccolti, passando per la definizione di un
sistema ad hoc per la memorizzazione degli stessi. Al momento della stesura di
questo documento parte del lavoro svolto è stato integrato nel progetto Dog stesso.
vi
Ringraziamenti
Grazie Papà, per tutto quello che hai fatto e che mi hai permesso di fare. Non so
come tu abbia fatto a sopportare me e mio fratello e a renderci ciò che siamo. Sei
sempre stato presente nonostante tutte le difficoltà che abbiamo dovuto affrontare
e non mi hai mai fatto mancare nulla. Senza il tuo aiuto e il tuo affetto non sarei
la persona che sono oggi.
Grazie ai miei nonni: fin da piccolo mi avete donato un affetto incondizionato
e siete sempre stati pronti a spronarmi e ad indicarmi la strada da seguire. Starei
giorni interi ad ascoltare i vostri racconti dai quali ho sempre tratto grande ispirazione. Grazie nonna Anna: da te ho imparato che non è mai troppo tardi e ancora
riesci a stupirmi con le tue mille risorse. Grazie nonno Piero e nonna Sarina per
avermi insegnato ad essere così determinato, anche nei momenti più duri.
Grazie a mio fratello Alessandro, che sto imparando a conoscere davvero solo
adesso, benché io ti voglia bene da sempre.
Grazie zio, da te ho preso la passione per la tecnologia e per tutto ciò che la
circonda, il sapermi arrangiare e che esiste sempre ‘un altro modo’. Grazie per il
primo PC e per i primi insegnamenti.
Grazie Monica, Santa Monica sostengono in molti, per come mi sopporti, per
come mi hai aiutato e per tutte le emozioni che mi hai regalato in questi anni. E
grazie per le nottate passate a correggere la mia tesi: se ha un filo logico è solo
merito tuo e delle tue pagine evidenziate (quasi del tutto, a dire il vero) per segnalarmi gli errori. Ho condiviso con te paure, tensioni e momenti tristi, ma non ti sei
mai tirata indietro. Per te, che con una parola riesci a farmi toccare il cielo con un
dito o farmi sprofondare all’inferno, non esistono parole per ringraziarti abbastanza.
Grazie Bea, perché sei stata paziente anche tu: adesso posso tenere fede alle
mille promesse che ti ho fatto in questi mesi. Niente più scuse! Ma soprattutto
vii
grazie per l’affetto sincero che mi doni tutti i giorni con i tuoi piccoli gesti.
Grazie Giuliana, unica ed insostituibile. Il tuo sorriso e la tua allegria sono un
punto fermo del mio mondo ed è inutile dirti quanto tu sia stata importante per
me e per mio fratello in tutti questi anni. Adesso sarà più semplice organizzare di
mangiare una pizza, credo.
Grazie Val, dove sarei senza di te? Le nostre mille nottate a parlare dei nostri
‘trip’ mentali, quasi mai ripetibili e spesso frutto delle mie paranoie. Grazie perché sei sempre riuscita a tirarmi su il morale e a strapparmi un sorriso anche nei
momenti più difficili.
Grazie Francesca, per avermi preso per i capelli tanti anni fa. Senza il tuo intervento non credo che oggi sarei qui a festeggiare il raggiungimento di questo mio
obiettivo. Senza contare il fatto che ogni volta che coniugo un verbo al congiuntivo
è solo grazie a te!
Grazie Davide e Francesco, compagni di vita ormai da tanti anni. Siamo cresciuti insieme e tra un litigio ed una ‘primizia’ mi avete dato molto più di quanto
possiate immaginare.
Grazie Luca e Silvano. Per me siete stati come una seconda famiglia in questi
anni di studi e tutta la mia esperienza lavorativa la devo a voi, ma prima di essere
colleghi siete stati amici e quello che ho vissuto con voi difficilmente si potrà ripetere.
Grazie Alessio e Luca, non posso scrivere ciò che penso di voi perché è pur sempre un documento ufficiale, ma grazie per l’amicizia che ci lega da sempre, siete stati
compagni di mille avventure e da voi ho imparato a prendere la vita con leggerezza.
Grazie Nonno Mauro: vorrei poterti dire quanto i tuoi insegnamenti siano stati
importanti e sono sicuro che se avessi potuto raccontarti dei miei studi saresti stata
la persona più entusiasta ed avresti studiato insieme a me.
Grazie Mamma, mille volte grazie. Tante volte ho desiderato tu fossi vicina a
me, ma oggi vorrei poter incrociare il tuo sguardo più di ogni altra cosa al mondo.
Semplicemente, grazie.
viii
Indice
Sommario
vi
Ringraziamenti
vii
1 Introduzione
1.1 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Scopo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Tecnologie utilizzate
2.1 Principi generali . . . .
2.2 Definizione componenti
2.3 Dog . . . . . . . . . . .
2.3.1 Architettura . .
2.3.2 spChains . . . .
2.4 Z-Wave . . . . . . . . .
2.4.1 RaZberry . . . .
2.5 H2 . . . . . . . . . . . .
2.6 AngularJS . . . . . . . .
2.6.1 HighChart . . . .
1
5
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
13
14
17
18
20
25
27
28
3 Sviluppo progetto
3.1 Introduzione . . . . . . . . . . . . .
3.2 Driver . . . . . . . . . . . . . . . .
3.2.1 Device Access Specification
3.2.2 Driver Z-Wave . . . . . . .
3.2.3 Network driver . . . . . . .
3.2.4 Gateway driver . . . . . . .
3.2.5 Driver dispositivi . . . . . .
3.3 Database . . . . . . . . . . . . . .
3.4 UI . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
31
31
34
34
37
38
39
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
4 Risultato finale
4.1 Possibili sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . .
53
54
A Guida all’uso
A.1 Aggiunta di un nuovo sensore . . . . . . . . . . . . . . . . . . . . .
A.2 Uso della UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Grafico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
60
61
Bibliografia
63
x
Capitolo 1
Introduzione
Con il continuo aumento dei costi dell’energia elettrica, risparmiare sui consumi
è diventato di fondamentale importanza. A motivazioni di carattere prettamente economico, si vanno ad aggiungere anche questioni di tutela e salvaguardia
dell’ambiente.
Il tenore di vita è in stretta correlazione con l’energia utilizzata, tuttavia esistono numerose tecniche per ridurre i consumi senza dovervici rinunciare. Alcune
di esse prevedono semplici accortezze pratiche legate a cattive abitudini, altre riguardano, invece, un investimento in quegli impianti che gli studi e la tecnologia
mettono oggi a disposizione e che consentono di avere una riduzione delle spese,
come l’adozione di pannelli solari o un miglior isolamento dell’edificio. In questo
secondo caso occorre naturalmente studiare e trovare la soluzione, in rapporto alle
possibilità economiche di ciascuno, più adatta alle esigenze di ogni abitazione: un
investimento maggiore, se ben pianificato, porterà a risultati migliori, ma potrebbe
non essere accessibile a chiunque.
Per poter concretizzare un progetto di risparmio energetico, prima dell’installazione di pannelli solari o del cambio di gestore, è consigliabile valutare in modo
oculato il consumo energetico degli elettrodomestici casalinghi ed eventualmente
provvedere alla loro sostituzione con nuovi modelli, che presentino una migliore
efficienza energetica.
La classificazione energetica degli elettrodomestici si basa sui valori dell’Indice
di Efficienza Energetica (Energy Efficiency Index: EEI ), che rappresenta in percentuale il rapporto tra il consumo annuale dell’apparecchio ed il consumo standard
di un modello analogo di riferimento. Tale valore viene riassunto tramite una scala
che va dalla A+++, nel caso di apparecchi molto efficienti, alla G e viene riportata
sull’etichetta energetica. Quest’ultima nasce per offrire all’acquirente una serie di
informazioni sulle caratteristiche essenziali, funzionalità offerte e consumi energetici dell’elettrodomestico. Inoltre, essa è uniforme per tutti gli elettrodomestici della
1
1 – Introduzione
stessa categoria, così da facilitare la comparazione tra i prodotti: in questo modo il
consumatore avrà tutti gli strumenti per fare la scelta migliore in base alle proprie
esigenze. [1].
Secondo un’indagine condotta dall’Istituto ISPO per ANIE Confindustria sul
territorio italiano [2], emerge che gli italiani siano molto sensibili al prezzo dell’energia e preoccupati dai continui rincari. Essi sono coscienti della necessità di mettere
in atto misure per giungere ad un vero risparmio energetico, ma al contempo poco
informati sulle tecnologie disponibili per diminuire la spesa.
La quasi totalità degli intervistati ha la percezione che negli ultimi 12 mesi le
bollette siano aumentate: il 79% ha notato una variazione al rialzo della bolletta del
gas, mentre l’81% lamenta una crescita del costo dell’elettricità. Le dichiarazioni
degli intervistati denotano anche un’elevata consapevolezza sull’importanza del
contributo personale al risparmio energetico. Per l’87% del campione, infatti, ogni
persona può contribuire con il proprio comportamento ad evitare sprechi di energia,
realizzando così una notevole riduzione dei consumi. In particolare, l’80% dichiara
di utilizzare sempre lampadine a risparmio energetico, il 76% di provvedere con
regolarità alla pulizia e manutenzione della caldaia, il 71% di usare lavatrici o
lavastoviglie a basse temperature, il 67% di contenere i consumi di acqua calda ed
il 66% di mantenere d’inverno la temperatura entro i 20 gradi. Molti affiancano ad
uno stile di vita sostenibile anche l’acquisto di prodotti efficienti dal punto di vista
energetico, in particolar modo elettrodomestici (72%) e/o climatizzatori a minor
consumo (46%).
Il tema dell’efficienza energetica si accompagna spesso a quello delle energie
rinnovabili: le più conosciute risultano essere la solare (il 78% afferma di sapere
bene di cosa si tratta) e l’eolica (73%). Sono, invece, meno note l’idroelettrica
(45%), la geotermica (28%), l’energia prodotta dalle biomasse (28%) e la marina
(24%).
Il quadro è un po’ diverso se si prendono in considerazione il grado di conoscenza ed il livello di informazione degli intervistati sul funzionamento del mercato
e sulle soluzioni tecnologiche da adottare. Innanzitutto le famiglie dimostrano ancora una conoscenza piuttosto limitata o distorta del primo, che ai loro occhi pare
concentrarsi solo su alcune delle soluzioni per l’efficienza energetica oggi disponibili: quelle basate sull’impiego dell’energia da fonti rinnovabili (specialmente solare
e eolica) e quelle legate al mercato degli elettrodomestici (frigoriferi, lavatrici, climatizzatori). Su altre soluzioni, come la domotica, si registra un interesse elevato,
in particolar modo quando il consumatore, attraverso esempi concreti, comprende
come applicarle al proprio ambiente domestico. Una comunicazione basata sulla
varietà e l’utilità delle soluzioni di efficienza energetica oggi disponibili potrebbe
dunque essere un elemento valorizzante sul quale si giocherà la futura competitività
dell’offerta di mercato. Un intervistato su 2 dichiara di conoscere bene la normativa sulla Dichiarazione di Conformità degli impianti elettrici domestici, tuttavia
2
quasi 1 su 4 ammette che il proprio non soddisfa nessuno dei requisiti di sicurezza
richiesti.
Sempre per quanto concerne la Dichiarazione di Conformità, gli intervistati ne
ricavano una percezione ‘a doppio taglio’: sebbene l’81% ritenga la sua presenza un’opportunità in un mondo in cui la riduzione dei consumi e degli sprechi è
sempre più importante, per il 60% del campione tale Dichiarazione non fa altro
che aumentare inutilmente la documentazione richiesta negli atti di compravendita
immobiliare. La stragrande maggioranza (81%), tuttavia, la considera anche una
buona occasione per incrementare il valore dell’intero immobile.
Il livello di conoscenza degli intervistati si abbassa quando s’introduce il tema della domotica, intesa come soluzione per rendere efficiente dal punto di vista
energetico la propria casa. Il 71% del campione non ha mai sentito parlare della
normativa che introduce il livello ’domotico’ degli impianti elettrici; tuttavia, la
percezione che si ha di essa è positiva. In particolare, ben il 77% degli intervistati
ritiene che possa essere considerata un aiuto per anziani o disabili. Il 74% del
campione riconosce poi alla domotica la possibilità di rendere più sicura la propria abitazione, mentre per il 69% rappresenta propriamente il futuro e crede che
sempre più persone vi faranno ricorso. Il 67% degli intervistati coglie tra i benefici riconoscibili dei sistemi domotici il fatto di consentire di risparmiare energia e
quindi di ridurre sprechi e consumi. Per il 60% del campione la domotica è comoda
ed aiuta a risparmiare tempo, di questi il 32% la considera una tecnologia fruibile e
facile da utilizzare. Entrando più nel dettaglio, gli intervistati esprimono curiosità
in particolare per quei sistemi di allarme che segnalano perdite d’acqua o fughe
di gas (85%), per i dispositivi che gestiscono il consumo energetico, spegnendo in
modo autonomo gli elettrodomestici che rischiano di far saltare la corrente (79%) e
per quei sistemi in grado di riattivare l’impianto elettrico saltato (80%). Suscitano
interesse anche il sistema che consente la gestione della termoregolazione differenziando gli ambienti in base al reale utilizzo degli spazi (70%) ed i dispositivi in
grado di gestire varie funzioni quando si è fuori casa (68%). Infine, per il 61%
degli intervistati è interessante poter controllare con un unico gesto più comandi
in contemporanea.
Una recente ricerca realizzata dall’Università di Oxford [3] su 1627 abitazioni
ha portato alla luce che solo il 9% delle variazioni sul consumo elettrico è attribuibile alle caratteristiche dell’edificio, il 17% è legato all’ambiente esterno, il 36% a
variabili di carattere sociale, mentre la parte rimanente, il 39%, è legato all’unione
degli elementi precedenti. Una soluzione che miri al contenimento dei consumi
elettrici deve quindi obbligatoriamente prevedere il coinvolgimento da parte degli
utenti: soluzioni puramente tecniche non possono determinare da sole un risparmio. Nell’immagine 1.1 sono mostrati i consumi elettrici di 11 abitazioni identiche,
costruite secondo i più recenti standard energetici: nonostante l’impiego degli stessi
elettrodomestici e delle stesse tecnologie costruttive, il consumo elettrico varia in
3
1 – Introduzione
maniera evidente da un’abitazione all’altra, denotando che il il nodo centrale del
risparmio energetico è l’utente stesso.
Figura 1.1.
Risultati di uno studio condotto nel 2004 in Sacramento, California
Uno dei problemi maggiori è che il consumo di corrente elettrica è ‘invisibile’: in un’automobile l’utente si accorge dell’indicatore che segnala un livello di
carburante via via più basso, nel caso di riscaldamento a legna o pellet sarà lo
svuotamento del magazzino a dare un feedback della quantità utilizzata, ma per
l’energia elettrica non c’è nulla di simile. Secondo un campione di 1219 intervistati,
le bollette elettriche sono le più complicate da capire e spesso non forniscono un
livello di dettaglio tale da attuare delle politiche di risparmio, rivelando che il 54%
sarebbe interessato all’adozione di un sistema di monitoraggio per poter conoscere
i consumi, i costi e le emissioni.
Una ricerca condotta in Nord Europa ed in Nord America ha portato alla luce
che un sistema di feedback adeguato può portare a risparmi del 5-15% nel caso
vengano utilizzati sistemi diretti, come un display con indicatore, ed un ulteriore
0-10% nel caso di quelli indiretti, quale un maggior dettaglio nella bolletta elettrica
o siti web dove è possibile effettuare un’analisi approfondita del proprio consumo.
4
1.1 – Stato dell’arte
L’adozione di tali sistemi porta inoltre ad un aumento ‘dell’alfabetizzazione elettrica’, con la creazione di nuove abitudini ed all’investimento in tecnologie efficienti
e sostenibili.
Per concludere, un sistema di monitoraggio energetico, per essere considerato
efficace, deve essere:
• basato sul consumo attuale;
• utilizzato frequentemente dall’utente finale;
• mostrare dati disaggregati per singolo elettrodomestico o gruppo di essi;
• utilizzato costantemente, non solo per un breve periodo;
• permettere confronti con periodi precedenti e con altre abitazioni;
• di facile comprensione ed utilizzo.
1.1
Stato dell’arte
Il termine ‘domotica’ indica l’integrazione nella vita domestica di diverse tecnologie quali l’elettrotecnica, l’elettronica, l’informatica, la comunicazione e, più in
generale, l’automazione.
Scopo della domotica è principalmente quello di migliorare le condizioni di esistenza dell’abitante della casa offrendogli comfort, sicurezza e benessere. Il comfort
si ottiene grazie a dispositivi, quali attuatori, telecomandi, sistemi di comunicazione, automatismi pre-programmati, che rendono più semplice la fruizione dei servizi,
degli elettrodomestici e degli apparecchi tecnologici. La sicurezza può essere assicurata da dispositivi o servizi attivi quali la chiusura automatica degli accessi ed il
loro controllo, i dispositivi antintrusione, segnalazioni che permettono di conoscere
lo stato della casa e dei suoi abitanti e di intervenire quando necessario.
Un altro concetto è il benessere degli abitanti, al quale si può ricondurre, ad
esempio, l’alleviamento delle condizioni di debilitazione di un malato, di un anziano
o di un disabile, realizzato sia con strumenti che ne riducano la fatica fisica ed
aumentino la mobilità, sia facilitandone l’accesso a mezzi di comunicazione. In
questa categoria si possono far rientrare anche i dispositivi che predispongono la
casa ad un uso più consapevole ed efficiente dell’ambiente e permettono ai suoi
abitanti un risparmio energetico.
La casa diventa intelligente non solo perché sono installati prodotti domotici,
ma perché dotata di un sistema attivo in grado di gestire e controllare facilmente
il funzionamento degli impianti presenti. Il bisogno e la convenienza del controllo
di climatizzazione, illuminazione ed automazione nascono dal continuo aumento
5
1 – Introduzione
delle attività connesse alla vita domestica ed alle loro funzioni. Attualmente gli
apparati tecnologici sono poco integrati tra loro ed il controllo di essi è ancora
ampiamente manuale. In una casa automatica gli apparati sono guidati da un
unico sistema centralizzato, che realizza un controllo intelligente di tutte le forme
di energia applicate all’abitazione attuando, ad esempio, interventi di termoregolazione domestica, in funzione dei mutamenti ambientali, e la verifica costante dei
consumi [4].
L’elevato numero di funzionalità che possono essere realizzate da un impianto
domotico ha portato i produttori ad approcciare il loro sviluppo in modi differenti,
proponendo delle soluzioni spesso estremamente diverse tra di loro. Alcuni hanno
fatto dell’economicità il requisito fondamentale del loro sistema, spesso rinunciando all’implementazione di caratteristiche che avrebbero aumentato la soddisfazione
dell’utente finale. Altri, invece, hanno sviluppato sistemi capaci di integrare un numero molto elevato di applicazioni, mettendo in secondo piano l’aspetto economico.
La conseguenza è che il prodotto di un’azienda è spesso incompatibile con quello di
una concorrente, dando vita ad uno scenario di mercato estremamente eterogeneo.
Questa discrepanza di vedute è, inoltre, una delle cause principali del mancato affermarsi di uno standard nel settore, nonostante si parli di automazione domestica
ormai da circa vent’anni. Una delle differenze sostanziali risiede nel metodo di
comunicazione adottato. Attualmente sul mercato esistono, infatti, differenti tecnologie di trasmissione: onde convogliate su linee di alimentazione, radiofrequenza
e sistemi BUS.
Le onde convogliate su linee di alimentazione permettono di sfruttare l’impianto
preesistente senza doverne installare di nuovi; l’inconveniente di questo sistema è
che possono verificarsi problemi relativi a rumori elettrici, interferenze, attenuazione, variazioni di impedenza e quindi riflessioni per disadattamento di impedenza.
Tali problemi possono essere risolti attraverso un buon progetto ed un’attenta
opera di rilevazione e correzione degli errori. Tecniche che prevedano la semplice
ritrasmissione del segnale risultano in questo caso non idonee ed occorrono delle
metodologie capaci di introdurre delle ridondanze nel pacchetto trasmesso, in modo da poter correggere eventuali errori. Una limitazione è, invece, la bassa velocità
di trasmissione, legata alla banda passante del cavo. Per questi motivi l’utilizzo
delle onde convogliate sui cavi di alimentazione è limitato ai casi in cui si voglia
controllare e monitorare apparecchiature, in particolare se collegate alla linea di
alimentazione, anche se ultimamente si stanno sviluppando delle tecnologie che
cercano di superare questi limiti.
La radiofrequenza è la tecnologia maggiormente utilizzata poiché fornisce una
soluzione conveniente ed economica per la realizzazione di una rete domestica o
in piccoli uffici. Questo mezzo copre facilmente l’intera casa senza bisogno di
ripetitori, ma occorre evitare di trasmettere segnali indesiderati alle abitazioni
adiacenti. Si incontra il medesimo problema delle onde convogliate, ma in questo
6
1.1 – Stato dell’arte
caso non si può adottare la soluzione del filtro. Si aggiunge, inoltre, una difficoltà
di standardizzazione poiché le bande di frequenza consentite variano da paese a
paese.
Nei sistemi BUS il mezzo di trasmissione delle informazioni tra i vari dispositivi
è costituito da un doppino telefonico intrecciato che provvede contemporaneamente
all’alimentazione ed allo scambio delle informazioni tra i vari dispositivi collegati
in parallelo [5].
Questo documento si concentrerà solamente sul monitoraggio del consumo elettrico dell’abitazione, nonostante la domotica si occupi, come accennato in precedenza, di numerose altre funzionalità.
Anche limitando lo studio a questo singolo campo, si trovano numerose soluzioni
commerciali dalle prestazioni e dai costi molto diversi tra di loro. Ad un estremo
troviamo dispositivi stand-alone che offrono funzionalità piuttosto limitate, come le
prese elettriche che, attraverso un display, informano l’utente del consumo attuale.
I modelli più avanzati forniscono anche la media delle misurazioni ed il costo, previo
inserimento dei dati di tariffazione ed il loro prezzo varia tra i 20 e i 40e. Nella
medesima categoria rientrano anche alcuni dispositivi che possono essere collegati
al quadro elettrico per fornire una lettura del consumo totale dell’abitazione invece
che di una singola presa. Le versioni più evolute possono fornire informazioni sotto
forma di grafici più o meno dettagliati, mentre altre hanno un semplice display che
mostra informazioni basilari similmente alle prese viste in precedenza. In questo
caso il costo può variare tra i 60 e i 200e in base alle funzionalità offerte.
Spostando l’attenzione su modelli più complessi, troviamo i sistemi di domotica vera e propria che permettono di utilizzare un numero arbitrario e variabile
di dispositivi. L’elemento che maggiormente distingue un sistema da un altro
è l’implementazione del gateway, ovvero il centro elaborativo del sistema. Alcuni
produttori privilegiano l’economicità, offrendo funzionalità limitate e compatibilità
solamente con i loro prodotti, altri invece implementano metodi di gestione avanzate e numerose feature. Per questo motivo i prezzi di questi componenti variano
moltissimo: dai 100e circa, fino ad oltre 500e per alcune tipologie di gateway
che implementano anche il supporto a più protocolli di comunicazione. I servizi offerti all’utente passano dal semplice comando remoto dei dispositivi tramite
telecomando, alla gestione intelligente dell’ambiente in cui si trovano.
Alcuni gateway prevedono, inoltre, la possibilità di definire un set di regole da
applicare al verificarsi di determinate condizioni e, in alcuni casi, l’utente stesso è
avvisato tramite un SMS o una mail. Anche l’interfaccia offerta varia molto in base
al prezzo: alcuni modelli economici non prevedono una UI accessibile ma fungono
solo da ‘ripetitori’ per i comandi ricevuti tramite telecomando, mentre versioni
più costose offrono interfacce grafiche rifinite attraverso cui è possibile monitorare
costantemente lo stato dell’abitazione, visualizzare statistiche e comandare i dispositivi. Spesso questi ultimi modelli sono accompagnati anche da un software
7
1 – Introduzione
compatibile con i più comuni modelli di smartphone e tablet, così da aumentare
maggiormente l’interazione da parte dell’utente.
Per quanto riguarda i sensori disponibili, le prestazioni ed i costi sono più o
meno comparabili tra i diversi produttori analizzati, in questo caso la differenza
di prezzo è principalmente dettata dal design. Oltre al consumo istantaneo, alcuni
modelli offrono anche la lettura dei kWh consumati dall’ultimo reset o degli indicatori luminosi che permettono di conoscere a colpo d’occhio il consumo attuale
senza accedere alla UI. E’ bene notare che vengono qui presi in considerazione solo
dispositivi facilmente installabili, mentre esiste una gamma completa di rilevatori
che possono essere integrati nell’abitazione che richiedono però l’installazione da
parte di utenti qualificati.
1.2
Scopo del progetto
Da questo contesto nasce l’idea di realizzare un sistema di monitoraggio dei consumi che non richieda nessun intervento invasivo, ma che, al contrario, possa essere
installato in pochi minuti e trasportato facilmente, dando la possibilità all’utilizzatore di cambiare la configurazione iniziale per poter modificare la granularità delle
misurazioni effettuate. Avendo come obiettivo finale il risparmio sulla fornitura
di energia elettrica, tale sistema dovrà avere dei costi contenuti ed esser facilmente fruibile: un costo troppo elevato o una difficile consultazione vanificherebbero,
infatti, il senso stesso della sua esistenza.
Il primo obiettivo da raggiungere è quindi la portabilità della soluzione e la semplicità di installazione: nessuno dei dispositivi utilizzati dovrà, pertanto, richiedere
l’intervento di un tecnico specializzato. Buona parte di essi possono essere visti
come semplici adattatori da collegare alle prese di corrente preesistenti, altri (i
sensori ambientali) sono auto-alimentati e possono essere posizionati a piacimento all’interno dell’ambiente da misurare. Da notare come anche questo aspetto si
traduca nuovamente in un contenimento dei costi, mentre i lati negativi si traducono perlopiù in fattori estetici e dalla copertura di più prese elettriche nel caso di
utilizzo di alcune tipologie adattatori dalle dimensioni poco contenute.
Altro target è la semplicità d’uso: per poter essere realmente fruibile dalle
masse, un sistema di questo tipo deve essere il più semplice possibile e richiedere una
conoscenza minima dei sistemi informatici. L’interfaccia finale dovrà quindi essere
il più intuitiva possibile evitando configurazioni complesse. Per questo motivo si è
scelto di orientarsi ad un’interfaccia web, tramite l’implementazione di un piccolo
server, così da rendere facilmente accessibili i dati misurati.
Da un punto di vista più tecnico, il sistema dovrà essere flessibile e facilmente
estendibile, permettendo un controllo fine del funzionamento tramite file di configurazione modificabili da utenti più esperti e lasciando spazio ad eventuali sviluppi
futuri.
8
1.2 – Scopo del progetto
Benché esistano già attualmente altre soluzioni per il monitoraggio dei consumi,
esse sono basate su software proprietario ed ogni gateway, il cui costo è tipicamente
molto elevato, può dialogare solo ed unicamente con dispositivi della stessa marca
(fatta eccezione per alcuni modelli molto costosi). Al contrario la soluzione qui
proposta si basa sul gateway domotico Dog, progetto open source del Politecnico
di Torino, tramite il quale è possibile utilizzare dispositivi di marche diverse, operanti su protocolli eterogenei. Benché in questo scritto vengano analizzati solo i
dispositivi operanti su protocollo Z-Wave, l’infrastruttura e le soluzioni adottate
sono assolutamente compatibili con qualsiasi altro protocollo o tipologia di device
rispetto a quelli qui trattati.
La parte successiva di questo scritto illustra lo sviluppo del progetto, ed in
particolare:
• nel capitolo 2 vengono analizzate nel dettaglio le tecnologie utilizzate ed i
motivi che hanno spinto a tali adozioni;
• nel capitolo 3 viene illustrata la parte di sviluppo e di design del sistema;
• il capitolo 4 presenta i risultati ottenuti;
• il capitolo 5 raccoglie le conclusioni alle quali si è arrivati ed elenca i possibili
sviluppi futuri.
9
10
Capitolo 2
Tecnologie utilizzate
2.1
Principi generali
In questo capitolo vengono presentate le principali tecnologie utilizzate per realizzare il progetto; contestualmente a queste vengono utilizzate numerose altre librerie
che saranno presentate più nel dettaglio nel prossimo capitolo dove verrà affrontato lo sviluppo. Prima di proseguire con l’analisi è bene definire alcuni parametri
comuni che sono stati presi in considerazione durante la selezione.
In primo luogo, per seguir la filosofia del gateway domotico Dog, rilasciato sotto
licenza Apache 2.0, e per contenere i costi, ogni software o tecnologia utilizzata
è fruibile gratuitamente, almeno in ambito non commerciale. In alcuni casi, in
particolare per la visualizzazione dei grafici, l’utilizzo di software licenziati avrebbe
aumentato la qualità delle rappresentazioni, ma proprio per i motivi sopra citati,
sono stati scartati.
Il progetto è pensato per essere integrato in Dog ed esteso con il passare del
tempo, ci si è quindi orientati verso soluzioni costantemente aggiornate ed in evoluzione poiché scegliere librerie poco mantenute o sviluppate da singoli soggetti
avrebbe potuto comportare la sostituzione di queste tecnologie in futuro. Diverse
soluzioni tra quelle prese in esame, benché interessanti ad una prima analisi, sono
state escluse per questo motivo.
Altro fattore preso in considerazione il sistema di elaborazione sul quale il sistema deve basarsi: il Raspberry Pi. Benché le sue caratteristiche tecniche siano
analizzate nel dettaglio successivamente, è bene notare fin da ora che la scelta di
un’unità di elaborazione dalle dimensioni e costi così contenuti porta inevitabilmente ad una limitazione nelle prestazioni. L’adozione di un altro sistema avrebbe
permesso di utilizzare software per la business intelligence più evoluti, ma avrebbe fatto lievitare i costi e l’ingombro del sistema inficiando quindi uno dei punti
11
2 – Tecnologie utilizzate
fondamentali.
Al termine di questa premessa possiamo analizzare i singoli componenti utilizzati.
2.2
Definizione componenti
La definizione del set di rilevatori utilizzati parte dall’analisi di un’abitazione composta da 3 camere, cucina e bagno ed abitata da una famiglia di 4 persone. E’
bene notare che questa è una stima di massima e dovrebbe essere adattata alle singole esigenze; non viene, inoltre, presa in considerazione una particolare marca o
modello, poiché tutte offrono caratteristiche analoghe da un punto di vista tecnico
(precisione misure, durata batterie, facilità di utilizzo e configurazione) e la scelta
è dettata, quindi, solo dal design e dal prezzo.
In primo luogo, poiché il monitoraggio di ogni singola presa e lampadina all’interno dell’abitazione non è possibile se non con un esborso esagerato, si è scelto di
adottare un misuratore da applicare al quadro elettrico che sia in grado di rilevare
il consumo totale dell’impianto. Il modello qui utilizzato è assimilabile ad una
pinza amperometrica: per la sua installazione è sufficiente posizionare le pinze del
sensore intorno ai cavi che arrivano al quadro elettrico, senza bisogno di lavorare
con fili scoperti. Analizzando le singole stanze questo è lo scenario che ne deriva:
• bagno: lavatrice e boiler elettrico;
• cucina: frigorifero, forno e presa per utensili da cucina;
• sala: impianto audio/video, postazione PC;
• 2 camere da letto: impianto audio/video;
In una configurazione del genere, si hanno quindi 9 prese monitorate, arrivando ad
avere una buona granularità.
Come detto in precedenza, questo è uno schema di massima: ad esempio il
boiler elettrico potrebbe non essere presente o essere collegato direttamente alla
linea elettrica, così come potrebbero esistere altre prese con un elevato assorbimento elettrico che potrebbe valer la pena monitorare, ad esempio in presenza di
riscaldamento elettrico.
A questo insieme potrebbe essere interessante affiancare altri tipi di sensori
come quelli per la temperatura, l’umidità ed i movimenti. Il sistema qui sviluppato
supporta tali sensori senza bisogno di alcuna modifica, a patto che esista un driver
compatibile con l’interfaccia di Dog.
Definito il set di sensori, è possibile spostare l’attenzione verso il cuore del
sistema ovvero il Raspberry Pi. Il Raspberry è un single-board computer, cioè un
calcolatore implementato su una sola scheda elettronica dal costo molto contenuto.
12
2.3 – Dog
Il sistema ruota attorno a un System-on-a-chip (SoC) Broadcom BCM2835, che
incorpora un processore ARM1176JZF-S a 700 MHz, una GPU VideoCore IV e
512 Megabyte di memoria. Non sono presenti né hard disk né unità a stato solido
ed il boot e la memoria non volatile sono affidati ad una scheda SD. Nella versione
utilizzata (modello B), si hanno inoltre: 2 prese USB, un ingresso ethernet, un
connettore RCA ed un’uscita HDMI. I consumi per questa versione sono di 700
mA (3,5 W).
L’anello di congiunzione tra il Raspberry Pi e i device Z-Wave è il RaZberry:
una piccola scheda di espansione collegata al connettore GPIO del Raspberry. La
comunicazione, che avviene tramite UART (Rx/Tx), è basata sul ricetrasmettitore
Z-Wave Sigma Design 3102 a cui si affiancano 32K di memoria flash per il traffico
di rete ed un’antenna PCBA. Il consumo della scheda è tipicamente di 18 mA @
3,3 V, ma può arrivare fino a 40 mA durante le fasi di trasmissione. Si rimanda
al paragrafo relativo al protocollo Z-Wave per una spiegazione più dettagliata del
suo funzionamento.
2.3
Dog
Dog (Domotic OSGi Gateway) nasce dal gruppo di ricerca del Politecnico di Torino e-Lite ed è un gateway in grado di esporre differenti network domotici come un
unico sistema neutro da un punto di vista tecnologico. Il framework su cui si basa,
OSGi, è definito dal consorzio Open Services Gateway Initiative nato nel 1999,
che raggruppa le più importanti società impegnate nel campo dell’Home Automation, con l’intento di definire le specifiche Service-Oriented Architecture (SOA) 1
per la diffusione e l’amministrazione dei servizi tipici di un Residential Gateway
(RG). L’architettura risultante ha preso il nome di OSGi Service Platform e, dalla
domotica, si è ora diffusa in molteplici campi. OSGi è quindi una piattaforma
Java-based che, secondo un approccio microkernel a plug-in, fornisce le specifiche
per sviluppare applicazioni che implementano servizi, permettendo di registrarne
di nuovi e di aggiornare o rimuovere gli esistenti on-the-fly. Il modello di cooperazione tra componenti prevede la possibilità di ricercare, individuare ed usare in
maniera condivisa i servizi forniti da diverse applicazioni nell’ambito della stessa
virtual machine, con conseguenti vantaggi in termini di prestazioni e consumo delle
risorse.
Tecnicamente, le specifiche della piattaforma OSGi introducono il concetto di
servizio, inteso come semplice interfaccia, e di bundle (componente), come archivio
1 Con Service-Oriented Architecture (SOA) si indica generalmente un’architettura software
adatta a supportare l’uso di servizi Web per garantire l’interoperabilità tra diversi sistemi così
da consentire l’utilizzo delle singole applicazioni come componenti del processo di business e
soddisfare le richieste degli utenti in modo integrato e trasparente.
13
2 – Tecnologie utilizzate
(JAR) contenente l’implementazione dei servizi e le direttive di distribuzione ed
installazione all’interno della piattaforma, oltre che le dipendenze da altri package
e servizi. Il framework OSGi è di fatto l’ambiente di esecuzione dei bundle.
La scelta di utilizzare un framework come OSGi, insieme ad una sofisticata
tecnica di modellazione (DogOnt), derivata dalla ‘Semantic Web research community’, permette a Dog di andare oltre il semplice controllo domotico e di gestire
l’ambiente in maniera intelligente tramite dispositivi eterogenei che si comportano
come un unico sistema attivo.
In questo progetto, ci concentreremo sulla sua capacità di fornire un’interfaccia
comune e neutra per qualsiasi dispositivo domotico e sull’interoperabilità tra i
dispositivi stessi. In altre parole, tramite Dog, avremo da una parte un’unica
interfaccia tramite la quale i dispositivi comunicheranno e, dall’altra, un unico set
di dati e comandi, astratti dall’architettura dei device, utilizzabile per controllare
i dispositivi stessi. La versione qui utilizzata è la 2.6.
Figura 2.1.
2.3.1
Rappresentazione schematica del sistema Dog
Architettura
L’architettura di Dog è basata sulla specifiche OSGi e i suoi bundle possono essere
divisi in tre gruppi: core, driver ed add-on.
14
2.3 – Dog
Core Bundle
Sono i bundle necessari al funzionamento del sistema stesso ed implementano le
funzionalità di base; ne fanno parte tutti quelli riportati in figura 2.2, vengono qui
di seguito dettagliati i principali.
Figura 2.2.
Componenti del core di Dog
• Dog REST EndPoint: implementa un’interfaccia REST, tramite JSON o
messaggi XML, che può essere utilizzata per interrogare Dog sullo stato del
sistema. In fase di sviluppo.
• Dog XML EndPoint: fornisce un’accesso XML-RPC a Dog tramite una
connessione bidirezionale tra client e server.
• DogStateMonitor: mantiene una fotografia dello stato di tutti i device, permettendo, inoltre, la registrazione dei vari listener sul cambio di stato.
• DogDeviceManager: implementa le specifiche OSGi di accesso ai driver e
gestisce la procedura di attachment tra driver e device.
• DogNotificationManager: implementa l’Event Admin Service Specification
v1.2 ed inoltra le notifiche ed i cambi di stato.
• DogConfigurator: gestisce le configurazioni dei singoli bundle.
• Dog2Library: espone classi di utility agli altri bundles.
• MeasureLibrary: esporta la libreria JScience e definisce altre unità di misura
non supportate dalla stessa.
15
2 – Tecnologie utilizzate
Driver Bundle
Sono l’anello di congiunzione tra il device fisico ed il core di Dog; possono essere
divisi a loro volta in tre tipologie distinte in base al ruolo svolto.
Figura 2.3.
Tipologie dei driver bundle di Dog
• Network Driver: si occupa della comunicazione a livello di rete e definisce le
API di accesso per tutti i driver con la stessa tecnologia.
• Gateway Driver: gestisce l’associazione tra device e gateway fisici consentendo il caricamento del driver solo se il corrispondente network gateway
è presente. Permette quindi di interfacciare reti domotiche controllate da
gateway diversi.
• Device Driver: implementa le feature di un singolo device, trasformando le
funzionalità e gli stati disponibili in messaggi di rete.
Add-on Bundle
Rientrano in questa categoria tutti i bundle che arricchiscono il core di Dog implementando funzionalità specifiche, come, ad esempio, DogRulesBundle che realizza
una rule-engine per la gestione automatica di alcuni scenari predeterminati.
Per meglio comprendere l’interazione tra questi elementi è possibile prendere
in esame il procedimento di start-up del sistema. In Dog non è definito un ordine
di avvio preciso per i bundle (eccetto che per il bundle DogAutoStart): ognuno di
essi attende che i servizi richiesti siano disponibili prima di iniziare la registrazione
sul framework OSGi, questo fa si che i primi ad essere avviati siano quelli che non
hanno dipendenze da altri bundle.
16
2.3 – Dog
Quando un House Model 2 provider diventa attivo vengono istanziati tutti i
Device in esso contenuti e il device manager si occupa di eseguire la procedura
di attachment tra Device e Driver. Se un Driver non può essere risolto il Device
viene messo in stato di idle e non è possibile usare quel dispositivo finché un driver compatibile non viene trovato. Tipicamente i Network driver vengono avviati
non appena viene istanziato il DogConfigurator, successivamente vengono inizializzati i corrispondenti Gateway driver ed infine i driver dei singoli sensori. Questa
procedura verrà spiegata in maniera esaustiva nel capitolo successivo.
2.3.2
spChains
Per il calcolo dei valori aggregati delle misure dei sensori è stato utilizzato l’add-on
bundle spChains. SpChains è uno stream-processing framework che supporta l’elaborazione, la combinazione e l’astrazione dei dati ambientali provenienti da più
fonti (ad esempio sensori) attraverso catene di elementi modulari e riconfigurabili, chiamati blocchi di stream-processing, di cui ne è fornito un set standard ed
estensibile.
Figura 2.4.
Schema di funzionamento di spChains
2 Un House Model è un provider che fornisce l’elenco dei dispositivi collegati a Dog. Esiste
un sistema di discovery automatico e molto potente all’interno di Dog, ma tale processo è molto
pesante da un punto di vista computazionale e non è possibile utilizzarlo in questo progetto. Al
suo posto sarà invece utilizzato un file xml che elenca i device collegati.
17
2 – Tecnologie utilizzate
Da un lato (figura 2.4, a destra) le applicazioni pervasive, che ascoltano gli
eventi forniti dai drain (ovvero i blocchi posti al fondo della catena), non devono occuparsi del peso del trattamento dei dati, ma hanno solo bisogno di definire
l’aggregazione e i modelli di rilevazione in forma di catene di stream-processing.
Dall’altro (figura 2.4, a sinistra), spChains può eseguire la correlazione e l’elaborazione di dati eterogenei derivanti dall’infrastruttura di comunicazione astratta
sottostante (in genere le reti di sensori wireless) in forma di eventi.
Ogni componente (filtro) ha un set di ingressi ed uscite e legge il flusso di
dati sui suoi ingressi fornendo uno stream di dati sulle sue uscite . Un connettore
(pipe) trasmette i dati da un’uscita del blocco ad un altro ingresso. Il flusso di dati
complessivo parte da una sorgente (event source) e raggiunge un collettore(event
drain) attraverso una serie di filtri e pipe, formando così un grafo aciclico (evitando
questioni relativi al trattamento ciclico).Gli event source e i drain astraggono quindi
i dati in ingresso, fornendo la definizione di un metodo standard (tramite interfacce
Java) per inserire ed estrarre gli eventi da spChains, mentre i blocchi e le catene
realizzano il core per il trattamento dei dati.
2.4
Z-Wave
Z-Wave è un protocollo di comunicazione wireless operante su una radiofrequenza
a bassa potenza creata specificatamente per il controllo remoto in ambito residenziale ed utilizzato da circa 250 produttori diversi nel mondo. Tale protocollo è
ottimizzato per essere affidabile ed offrire una bassa latenza nell’invio di piccoli
pacchetti ad una velocità di circa 100Kbps. Z-Wave è uno dei protocolli più affidabili in ambito wireless: ogni comando inviato è confermato dal destinatario tramite
ACK. Questo non garantisce che il messaggio sia trasmesso correttamente, ma il
mittente è in grado di sapere se la situazione è cambiata o se si è verificato un
errore. Un mittente prova ad inviare il suo messaggio fino a tre volte, prima di
restituire un messaggio di errore. Il numero delle trasmissioni fallite è anche un
buon indicatore della qualità della rete.
La frequenza di lavoro è intorno ai 900 Mhz, in questo modo viene garantito il
fatto che non ci siano interferenze con le reti Wi-Fi o Bluetooth che tipicamente
operano alla frequenza di 2.4 Ghz. Tale protocollo è inoltre stato progettato nell’ottica di essere facilmente incorporato in prodotti di elettronica di consumo anche
se alimentati tramite batterie, le quali, in condizioni normali, possono durare fino
ad un anno.
Ogni network basato su Z-Wave può includere fino a 232 nodi che sono divisibili
in controller e slave, a loro volta i controller possono essere primari (sempre e solo
18
2.4 – Z-Wave
uno) e secondari. La topologia adottata è di tipo source-routed3 mesh network4 , i
device possono cioè comunicare tra di loro utilizzando altri nodi intermedi, permettendo di aumentare l’area coperta dal segnale stesso e l’aggiramento di eventuali
ostacoli. Questa funzione però, per poter permettere un risparmio sui consumi, non
è offerta dai device alimentati a batteria . Se una route non è disponibile vengono
automaticamente selezionati altri percorsi per la consegna del messaggio. Proprio
per questa feature è necessario che i device rimangano nella stessa posizione dopo
il riconoscimento o che venga avviata una procedura per rimappare le route una
volta rimosso/spostato un device.
Ogni network Z-Wave è identificato da un Network ID (4 byte) assegnato al
controller primario in fase di costruzione e non modificabile dall’utente, così come
ogni nodo è identificato da un Node ID (1 byte) che gli viene assegnato dal controller
primario all’atto di inclusione di un nuovo device all’interno della rete. Da notare
che nodi con diversi Network ID non possono comunicare tra di loro a meno che
non venga eseguito un bridging tra le due reti.
Il protocollo Z-Wave è formato da tre layers:
• Radio Layer: definisce come il segnale è scambiato tra il livello network e
l’hardware fisico; include la frequenza, la codifica, ecc.
• Network Layer: stabilisce come i dati sono scambiati tra due nodi. Include
l’indirizzamento, l’organizzazione del network, il routing, ecc. Si divide in tre
sotto livelli:
– Media Access Layer (MAC): gestisce l’utilizzo dell’hardware wireless
tramite funzioni non visibili all’utente finale.
– Transport Layer: tratta il trasferimento dei messaggi, implementando
le logiche di gestione degli errori, tra due nodi. L’utente finale non può
modificare il funzionamento di questo layer, ma il suo risultato finale è
visibile.
– Routing Layer: si occupa di gestire la rete ‘Mesh’ di Z-Wave, massimizzando il range del segnale ed assicurandosi che il messaggio venga
consegnato, modificando eventualmente le route di consegna.
3 L’architettura di rete source routing permette a chi invia il pacchetto di specificare parzialmente o totalmente il percorso da seguire attraverso la rete per la consegna dello stesso. In
contrasto a questa esistono i protocolli non-source routing, dove il percorso è stabilito dai routers
di rete.
4 Mesh networking è un tipo di topologia di rete dove ogni nodo non si occupa solo di gestire
i suoi pacchetti, ma ha funzioni di relay per gli altri nodi, per i quali propaga i dati all’interno
della rete.
19
2 – Tecnologie utilizzate
Figura 2.5.
I tre layer del protocollo Z-Wave
• Application Layer: definisce quali messaggi devono essere processati da particolari applicazioni al fine di rendere possibile il funzionamento di determinati
task quale l’accensione di una lampadina.
2.4.1
RaZberry
Il RaZberry è composto da una scheda hardware equipaggiata con il proprio firmware ed una parte software che viene eseguita sul Raspberry Pi, denominata Z-Way.
Z-Way implementa lo stack del protocollo ed una API per lo sviluppo di interfacce
di terze parti, oltre che un’interfaccia utente di demo.
Il sistema di comunicazione può essere diviso in 6 componenti.
1. Il Raspberry Pi con il sistema operativo Raspbian, precedentemente installato.
2. La scheda RaZberry connessa al connettore GPIO del Raspberry Pi.
3. Il firmware di basso livello Z-Wave che viene eseguito sul ricetrasmettitore. Esso è compatibile con il firmware standard Sigma Design, ma contiene
numerosi miglioramenti.
4. Il server Z-Way, che implementa lo stack del protocollo di comunicazione ZWave, gestendo la comunicazione con i nodi e l’esecuzione dell’engine interno.
20
2.4 – Z-Wave
Figura 2.6.
Il sistema nel suo insieme
5. L’interfaccia utente dimostrativa di Z-Way, basata su JSON, permette di
avere una panoramica completa di tutte le funzionalità.
6. Applicazioni di terze parti.
Architettura software
La porzione software di Z-Way è fornita come eseguibile Linux e permette di:
• includere ed escludere nuovi device, modificare la loro configurazione e gestire
quella di rete;
• modificare lo stato degli attuatori come ad esempio: interruttori elettrici,
dimmers, attuatori per la chiusura di porte e finestre, termostati, ecc;
• accedere ai dati dei sensori quali sensori di movimento, temperatura, sensori
di fumo, ecc;
• visualizzare tutte le funzionalità disponibili nella rete analizzata;
• creare regole logiche tra gli eventi per permettere l’attuazione di determinate
azioni in conseguenza al verificarsi di un determinato scenario;
• accedere alle funzionalità per l’internazionalizzazione.
Z-Way comunica (southbound) con il firmware del ricetrasmettitore ZM3102
attraverso l’interfaccia seriale e offre (northbound) un’interfaccia che aderisce alle
specifiche JSON, che è utilizzata dalle applicazioni o dalle pagine web che operano
21
2 – Tecnologie utilizzate
Figura 2.7.
Architettura software Z-Way
sulla rete Z-Wave. E’ possibile che diverse applicazioni richiedano in parallelo l’uso
di tale interfaccia e questo non rappresenta un problema a meno che le due applicazioni non inviino messaggi contraddittori tra di loro (il primo invia il comando
per accendere una lampadina, il secondo per spegnerla). In questo caso il risultato
è impredicibile.
Z-Way consiste di diversi blocchi funzionali.
• Job Queue: è il core di Z-Way e tiene traccia di tutte le istruzioni da eseguire
e prende in carico le eventuali ritrasmissioni in caso di errore.
• Function Classes: definiscono tutti i comandi disponibili per controllare e
configurare la rete Z-Wave e il chip di trasmissione.
• Command Classes: implementano tutti i comandi a livello applicativo utilizzati per controllare i devices.
• JSON Web Server: specifica l’interfaccia di comunicazione per gli sviluppatori.
• Translation Functions: aiuta a tradurre i dati dal formato machine-readable
a quello human-readable.
• Automation and Scripting engine: gestisce il set di regole intelligenti per
comandare il sistema.
22
2.4 – Z-Wave
Il modello dati Z-Way
Z-Way mantiene tutti i dati del network Z-Wave in memoria, la cui struttura è
organizzata in un albero gerarchico. Seguendo il paradigma object-oriented i differenti comandi eseguibili su un dato device sono inglobati all’interno della struttura
stessa: ogni elemento, nella forma devices[id].data.id, è gestito come un oggetto
separato nella gerarchia e ad ognuno di essi sono associati alcuni dati accessori che
possono essere così divisi:
• value: il valore stesso;
• name: il nome dell’oggetto;
• updateTime: timestamp che indica l’ultimo update eseguito;
• invalidateTime: timestamp che indica quando il valore è stato invalidato a
seguito di una richiesta di aggiornamento, tramite get;
• updated: booleano che indica se il valore è valido o meno, lavora in combinazione con invalidateTime. E’ particolarmente utile dopo un’azione di set,
dopo la quale il valore presente nella struttura dati potrebbe non rispecchiare
il reale stato del device.
La root del data tree ha due nodi figli:
• controller: mantiene tutti i dati ed i comandi relativi al controller primario;
• devices: è l’array dei device installati, come il precedente mantiene tutte le
informazioni ed i comandi disponili su di essi.
Esempio di esecuzione di un comando dalla GUI al device fisico
La comunicazione tra i device reali e l’interfaccia utente coinvolge numerosi attori
e fasi. Si assuma che la GUI stia visualizzando lo stato di un interruttore e che
ne permetta la modifica. Quando l’utente cambia lo stato di tale interruttore si
aspetta di avere un feedback visivo sull’interfaccia stessa. Il primo step è l’invio di
un comando (SET) dall’interfaccia utente a Z-Way tramite le API JSON. Z-Way
riceve il comando e conferma la ricezione alla GUI e riconosce che tale comando
produrrà una variazione del valore, invalidando quello attualmente memorizzato,
poiché per il momento il device non è ancora stato contattato.
A questo punto Z-Way si occupa di inserire nella coda di esecuzione il comando,
processando eventuali priorità o logiche definite in precedenza. Inoltre, viene anche
schedulata una richiesta di update per il device in oggetto (GET), subito dopo la
richiesta di cambio di stato. Quando il comando è in cima alla coda di esecuzione
viene inviato al chip per la trasmissione, il quale manda conferma dell’avvenuta
23
2 – Tecnologie utilizzate
Figura 2.8.
Modello dati Z-Way
ricezione che viene annotata nella coda. Questa conferma indica semplicemente
che il chip ha accettato il comando, non che questo sia stato spedito al device.
A questo punto il comando viene effettivamente recapitato al nodo. Una conferma della ricezione è l’unico valido indicatore che il device abbia ricevuto il comando
(il che non vuol dire sia stato eseguito). Subito dopo viene inviato il secondo comando (GET) seguendo la medesima logica: questo farà si che il device risponda
con un REPORT command a Z-Way, indicando il suo stato che sarà registrato
da Z-Way, tramite la porta seriale, andando ad aggiornare il campo value e il flag
updated. Da questo momento in poi la GUI riceverà il valore aggiornato ad ogni
richiesta.
24
2.5 – H2
Figura 2.9.
2.5
Esempio di comunicazione tra la GUI ed il dispositivo fisico
H2
H2 è un ‘Relational Database Management System’ (RDBMS) sviluppato in Java
che può essere integrato all’interno di altre applicazioni o essere eseguito in modalità
client-server. In questo progetto il suo ruolo sarà quello di rendere persistenti i
dati raccolti dal sistema di monitoraggio oltre a permettere alcune customizzazioni
relative alla visualizzazione dei dati stessi.
H2 implementa un subset dei comandi SQL, mettendo a disposizione degli sviluppatori API SQL e JDBC. E’ possibile creare sia tabelle in-memory sia disk-based
e queste possono essere a loro volta persistenti o temporanee. Uno degli aspetti più
interessanti di H2 è la grandissima velocità di esecuzione delle query nonostante
il suo footprint su disco sia solamente di circa 1 MB. Sono possibili tre tipi di
connessione diverse.
• Embedded Mode: in questa modalità l’applicazione apre una connessione
JDBC verso il database all’interno della stessa JVM. Questo tipo di connessione offre la maggiore semplicità di implementazione e velocità. Lo
svantaggio è che è possibile avere il database aperto in una sola JVM alla
volta.
• Server Mode: è la modalità di funzionamento standard dei database. Il server, che può accettare diverse connessioni contemporaneamente, deve essere
avviato prima dell’esecuzione dell’applicazione e le performance sono inferiori
al metodo precedente poiché tutti i dati vengono trasferiti tramite TCP/IP.
• Mixed Mode: è la combinazione dei due metodi precedenti. La prima applicazione che si collega al database acquisirà una connessione di tipo embedded
25
2 – Tecnologie utilizzate
ed avvierà il server al quale si potranno collegare altri processi. Questa è la
modalità utilizzata per questo progetto: il sistema di monitoraggio avrà una
connessione veloce e di tipo embedded, ma al tempo stesso sarà possibile
collegarsi al database dall’esterno per eventuali future implementazioni.
Un veloce paragone con altre possibili tecnologie può essere eseguito esaminando
la tabella sottostante.5
Pure Java
Memory Mode
Encrypted Database
ODBC Driver
Fulltext Search
Multi Version Conc.
Footprint (jar/dll size)
H2
Si
Si
Si
Si
Si
Si
∼1 MB
Derby
Si
Si
Si
No
No
No
∼2 MB
HSQLDB
Si
Si
Si
No
No
Si
∼1 MB
MySQL
No
No
No
Si
Si
Si
∼4 MB
PostgreSQL
No
No
No
Si
Si
Si
∼6 MB
Eliminando le tecnologie che non supportano l’embedded mode, è possibile
concentrarsi sulle performance delle rimanenti.
Test Case
Simple: Init
Simple: Query (random)
Simple: Query (sequential)
Simple: Update (random)
Simple: Delete (sequential)
Simple: Memory Usage
BenchA: Init
BenchA: Transactions
BenchA: Memory Usage
BenchB: Init
BenchB: Transactions
BenchB: Memory Usage
BenchC: Init
BenchC: Transactions
BenchC: Memory Usage
Executed statements
Total time
Statements per second
Unit
ms
ms
ms
ms
ms
MB
ms
ms
MB
ms
ms
MB
ms
ms
MB
#
ms
#
H2
241
193
89
406
155
7
200
1071
8
787
465
17
348
1382
12
322929
5337
60507
HSQLDB
431
267
179
772
266
13
251
1458
14
1584
875
13
225
865
20
322929
7173
45020
Derby
1027
748
658
12175
6281
16
1075
8142
12
4163
2744
10
922
3527
11
322929
41462
7788
5 Le versioni prese in esame sono: H2 1.3, Apache Derby version 10.8, HSQLDB 2.2, MySQL
5.5, PostgreSQL 9.0
26
2.6 – AngularJS
Altro database preso in esame è SQLite. La sua esclusione dipende principalmente dal fatto che, sebbene fornisca prestazioni solitamente migliori rispetto
ad H2, impone alcuni forti vincoli in ottica futura: dimensioni massime inferiori,
nessuna criptazione dei dati, outer join non utilizzabili, funzioni e procedure non
disponibili.
In opposizione a queste feature troviamo un problema legato alla possibile perdita di dati di transazioni committate in caso di mancanza di corrente elettrica se
viene utilizzata la configurazione standard di H2. Bisogna in primo luogo notare che
molti database che avrebbero potuto rappresentare un’alternativa valida soffrono
dello stesso problema (HSQLDB, PostgreSQL e Derby), inoltre, in un’applicazione
come questa, la mancanza di corrente farebbe non solo perdere gli ultimissimi dati
raccolti, ma anche tutti i dati generati durante il blackout (derivanti ovviamente
solo dai device alimentati a batterie). Benché esistano delle opzioni per limitare
tale problema, si è deciso di non ricorrere al loro uso anche a causa del grosso
degrado di prestazioni che queste comportano.
2.6
AngularJS
AngularJS è un framework per la creazione di applicazioni web dinamiche sviluppato da Google; all’interno di questo progetto verrà utilizzato per la creazione
dell’interfaccia web tramite la quale sarà possibile visualizzare i dati raccolti. La
principale caratteristica di tale framework risiede nel fatto che permette l’utilizzo di
un pattern MVC6 tramite il solo utilizzo di codice JavaScript. AngularJS è costruito
seguendo una filosofia secondo cui la programmazione dichiarativa dovrebbe essere
utilizzata per la costruzione delle UI, mentre la programmazione imperativa è ottima per la definizone della business logic. Il framework adatta ed estende l’HTML
tradizionale per meglio realizzare la creazione dinamica di contenuti tramite un
data-binding a due vie, che permette la sincronizzazione della vista e del modello.
Come risultato AngularJS de-enfatizza la manipolazione del DOM e migliora la
testabilità. Tramite l’utilizzo della dependency injection, AngularJS permette di
spostare servizi tipicamente server-side sul client, come ad esempio la gestione dei
controller, permettendo la creazione di applicazioni web molto più leggere.
Una delle caratteristiche più interessanti è il two-way data binding che permette
di scrivere meno codice per ottenere lo stesso risultato: il template è renderizzato
6 Model-view-controller (MVC) è un pattern di architettura del software che separa la rappresentazione delle informazioni dall’interazione dell’utente con esse. Il modello consiste nei dati
dell’applicazione, la logica e le funzioni. Una vista è qualsiasi output che rappresenti tali dati.
Sono possibili diverse viste sullo stesso model. Il controller fa da link tra il model e la view,
traducendo i comandi da una parte all’altra.
27
2 – Tecnologie utilizzate
come plain HTML, in base ai dati contenuti nel model. Lo scope service, un componente di AngularJS, rileva le modifiche al model e le riflette sull’HTML della view
tramite il controller. Allo stesso modo, ogni modifica della view viene riportata nel
modello. In questo modo si ha uno sviluppo più veloce delle applicazioni e si evita
di dover lavorare direttamente sul DOM.
Figura 2.10. Rappresentazione schematica del funzionamento del TwoWay Data Binding
Il compilatore AngularJS compila il DOM, non le stringhe del template: questo
si traduce in una funzione di linking che, combinata allo scope model, crea una
view dinamica che lo sviluppatore non ha bisogno di aggiornare esplicitamente.
Inoltre AngularJS permette di aumentare il livello di astrazione nella scrittura di
applicazioni web, gestendo in automatico la manipolazione del DOM, il setup di
listener e notifier e la validazione dell’input, grazie a ciò gli sviluppatori possono
concentrarsi sulla logica dell’applicazione invece che su task ripetitivi e ad alto
rischio di errore.
Il risultato di tutto questo è una buona velocità di programmazione e la possibilità di concentrarsi più sugli aspetti critici che sulla programmazione di basso
livello. Inoltre, grazie alla sua struttura ed al fatto che quasi tutta l’elaborazione
venga eseguita client-side, si dimostra la scelta migliore per l’implementazione su
Raspberry Pi, permettendo di occupare meno risorse possibili. Bisogna però considerare che la curva di apprendimento è piuttosto ripida nel momento in cui ci si
sposta verso comportamenti più complessi e fuori dagli standard.
2.6.1
HighChart
HighChart è la libreria utilizzata per la creazione dei grafici che mostrano l’andamento dei consumi e, più in generale, degli eventi avvenuti nel sistema. A differenza
di altre librerie simili, HighChart permette di avere una vastissima gamma di grafici utilizzabili tramite delle API che permettono la customizzazione di qualsiasi
28
2.6 – AngularJS
aspetto. E’ inoltre possibile disegnare grafici con valori temporali non costanti ed
in generale diversi tra una serie di dati e l’altra, feature molto spesso assente in
altri software concorrenti. Questa scelta, fatta anche in ottica futura, è stata dettata anche dal fatto che le prestazioni rimangono molto buone anche in presenza di
una elevatissima quantità di dati da visualizzare e dalla possibilità di avere grafici
real-time, senza cioè la necessità di renderizzare nuovamente tutto il grafico, ma
solo aggiungere i nuovi valori.
L’immagine 2.11 riassume quanto presentato in questo capitolo.
Figura 2.11. Le componenti principali del sistema: 1 - i device Z-Wave utilizzati,
nella configurazione preferita; 2 - il RaZberry che si occupa di fare da interprete tra
Dog ed i device fisici; 3 - i driver Z-Wave sviluppati per ogni singolo dispositivo; 4
- il bundle spChains, usato per calcolare le medie dei dati raccolti; 5 - il database
H2, usato per rendere persistenti tutti i dati e le configurazioni; 6 - l’interfaccia
utente; 7 - i dispositivi utilizzati per accedere alla UI.
29
30
Capitolo 3
Sviluppo progetto
3.1
Introduzione
Dopo la panoramica sulle tecnologie utilizzate, viene qui illustrato lo sviluppo del
progetto, che è possibile dividere in tre fasi tra loro indipendenti. Una prima parte
analizzerà l’implementazione dei driver dei dispositivi Z-Wave per l’interfacciamento con Dog, la seconda tratterà lo sviluppo di un bundle atto a registrare su un
database gli eventi provenienti dal sistema, mentre l’ultima darà una spiegazione
sullo sviluppo del bundle relativo all’interfaccia utente.
3.2
Driver
Prima di analizzare la creazione dei Driver è necessario specificare il loro funzionamento all’interno del framework OSGi.
3.2.1
Device Access Specification
La Device Access Specification indica come un dispositivo si agganci alla piattaforma OSGi e come quest’ultima provveda a rilevarlo in modo automatico. Un Driver
può controllare un dispositivo se entrambe le entità rispettano le caratteristiche
definite nella device category cui appartiene il dispositivo stesso.
Una DeviceCategory specifica le regole e le interfacce che devono essere obbligatoriamente implementate per consentire la comunicazione tra Driver e Device.
Queste due ultime entità possono quindi dialogare tra loro soltanto se entrambe
appartengono a una stessa DeviceCategory. Inoltre, se un Device appartiene a una
DeviceCategory, allora vi è interoperabilità con tutti i Device conformi alle caratteristiche di quella categoria. Questo rappresenta l’unico vincolo e permette di
31
3 – Sviluppo progetto
disaccoppiare lo sviluppo del Driver da un particolare costruttore di dispositivi. Le
specifiche OSGi definiscono solo il processo di attachment (definito in seguito) tra
Driver e Device e sono quindi necessarie altre specifiche che definiscano la tecnologia
e i protocolli di comunicazione.
Il servizio Device
Un Device è un servizio della piattaforma che può rappresentare diverse forme di
dispositivi, non necessariamente fisici, potrebbe, infatti, essere usato per rappresentare un’intera rete.
Il processo di registrazione di un Device è uguale a quello di un normale servizio
nel framework OSGi; tuttavia è necessario compiere i seguenti passi per fare in
modo che il servizio aggiunto venga riconosciuto come Device e, quindi, possa
essere agganciato a un Driver:
1. registrare il servizio sotto l’interfaccia org.osgi.service.device.Device
2. impostare la proprietà DEVICE_CATEGORY che definisce il nome della device
category a cui appartiene il dispositivo.
Ogni servizio nel framework, quindi anche un Device, deve possedere un Service Persistent ID (PID o service.pid), che deve essere univoco tra tutti i servizi
registrati; nel caso dei Device tale ID viene assegnato direttamente dal framework.
Il servizio Driver
Il servizio Driver è responsabile del processo di aggancio ad un Device e deve essere
implementato in un bundle che prende il nome di ‘driver bundle’. Al momento
dell’associazione il device manager sceglie il Driver ‘più adatto’ al controllo del dispositivo, questo vuol dire che, prima di potersi associare ad un Device, il Driver
deve eventualmente competere con altri servizi dello stesso tipo. Ciascun Driver
può essere associato a più servizi Device anche appartenenti a categorie diverse.
L’interfaccia org.osgi.service.device.Driver definisce i seguenti metodi:
• match(ServiceReference): questo metodo viene invocato dal device manager
per sapere quanto il Driver sia adatto al servizio Device, indicato dall’argomento ServiceReference. Il valore ritornato dipende dall’affinità tra Device e
Driver; quando Device e Driver appartengono a due device category diverse
viene restituito Device.MATCH_NONE.
• attach(ServiceReference): questo metodo viene chiamato se il device manager
decide che un determinato Driver deve essere agganciato al Device referenziato
32
3.2 – Driver
mediante l’argomento ServiceReference. Se l’attachment va a buon fine, il metodo restituisce null ed il Device viene considerato come controllato soltanto
da quel particolare Driver.
Un servizio viene riconosciuto come Driver dal driver manager, soltanto se durante la registrazione viene definita la proprietà DRIVER_ID; il valore associato a
tale proprietà deve identificare in modo univoco il Driver, per evitare di installare
duplicati di uno stesso servizio. Il DRIVER_ID deve:
• dipendere soltanto dal particolare comportamento del Driver;
• iniziare con la forma inversa del dominio dell’azienda (o organizzazione) che
implementa il Driver;
• essere univoco e differente anche per ogni revisione dello stesso bundle.
Quando viene registrato un nuovo Driver, si attiva la contesa con altri eventuali
Driver per l’associazione di Device idle. Per poter essere agganciato a un dispositivo,
il Driver riceve delle chiamate ai suoi metodi match e attach. Una volta che un Driver
è stato agganciato a un Device, solo quest’ultimo può rilasciarlo.
Associazione di un Driver a un Device
Quando un Device viene registrato nel framework, il device manager, che è responsabile di attivare i processi opportuni in risposta alla registrazione, cerca di
individuare un Driver che sia adatto al dispositivo e lo associa al Device considerato. In questo processo il Device è passivo: registrato il servizio, rimane in attesa di
essere chiamato, poiché è compito del Driver scelto dal driver manager collegarsi al
dispositivo. Nel caso in cui il device manager non trovi un Driver adatto, il Device
rimane ‘unattacched’ e può compiere una delle seguenti azioni:
• rimanere in attesa che un nuovo Driver venga installato e ripetere la procedura
appena vista;
• de-registrarsi dal service registry ed eventualmente registrarsi nuovamente
con proprietà diverse che gli permettano di essere agganciato da un Driver.
Un Device è definito idle quando non è associato a nessuno dei Driver registrati dai
bundle.
L’interfaccia ManagedService
L’interfaccia org.osgi.service.cm.ManagedService è implementata da tutti i servizi
che devono ricevere una configurazione dal Configuration Admin service, che è
un particolare servizio che si occupa di registrare la configurazione dei bundle in
maniera persistente.
33
3 – Sviluppo progetto
Quando il ConfigurationAdmin rileva la registrazione di un nuovo ManagedService, verifica se ha a disposizione una configurazione il cui PID sia uguale a
quello del servizio. In caso affermativo viene attivata la funzione di callback updated(Configuration) che viene eseguita in maniera asincrona; altrimenti il parametro del metodo sarà null. Il ManagedService potrà a questo punto registrarsi
come servizio disponibile all’interno del framework e nel caso dei Driver sarà disponibile per iniziare la procedura di attachment quando richiesto. Il metodo
updated(Configuration) viene anche chiamato ogni volta che l’oggetto Configuration viene modificato, in modo tale da mantenere sincronizzato il servizio con la
configurazione stessa.
3.2.2
Driver Z-Wave
La realizzazione dei driver ha richiesto lo studio delle API del server Z-Way. Prima del rilascio di tale server era piuttosto complicato riuscire ad elaborare i dati
provenienti dai dispositivi operanti su protocollo Z-Wave, potendo lavorare solo a
livello di pacchetti di rete tramite l’interfaccia seriale. Al contrario, Z-Way mette a
disposizione un comodo set di comandi tramite i quali è possibile comandare tutti
gli aspetti dei dispositivi collegati al sistema.
In questo progetto sono state prese in considerazione solo le funzionalità di base
offerte dalle API: vengono quindi trattate solo quelle legate alla lettura dei sensori.
Si rimanda all’interfaccia web offerta dallo stesso Z-Way per tutte le funzioni di
configurazione dei singoli dispositivi e della rete che sono state intenzionalmente
ignorate. Questa scelta è stata dettata sia dalla necessità di limitare l’ambito di
lavoro sia dal fatto che l’implementazione di alcune di queste funzionalità avrebbe
richiesto una modifica anche al core di Dog per il loro supporto.
3.2.3
Network driver
Lo scopo del network driver è comunicare con il server Z-Way presente sul RaZberry tramite protocollo HTTP e gestire la comunicazione tra Dog ed i device
fisici. Il server Z-Way può essere interrogato tramite richieste POST nella forma
http://IPRaspberry:8083/<URL> dove <URL> si differenzia in base alla richiesta
eseguita e può essere diviso in tre categorie diverse.
• /ZWaveAPI/Run/<command>: questo tipo di comando può essere utilizzato per eseguire un’azione su un determinato dispositivo, come ad esempio
l’accensione o spegnimento di un interruttore. Command è nella forma devices[x].instances[y].commandClasses, dove x indica l’id del device all’interno
del sistema, y indica l’istanza di riferimento e commandClasses è specifico a
seconda dell’azione da eseguire e dal device in oggetto.
34
3.2 – Driver
• /ZWaveAPI/InspectQueue: utilizzato solo per scopi di debug, permette di
visualizzare la coda delle istruzioni del server.
• /ZWaveAPI/Data/<timestamp>: restituisce un flusso di dati in formato JSON
contenente le modifiche al sistema avvenuto dopo timestamp. Se viene utilizzato 0 come valore, il server restituisce l’intero albero rappresentante il
sistema.
Il network driver dipende solo da bundle che fanno parte del core di Dog e per
questo sarà il primo ad essere processato ed avviato all’interno di questo progetto. Nella fase di avvio, il bundle rimane in attesa di ricevere la configurazione
necessaria, nella quale è contenuto l’url del server Z-Way al quale collegarsi. Se la
connessione ha avuto esito positivo, il bundle viene registrato e diventa disponibile all’intero sistema. Contestualmente viene avviato un nuovo thread, denominato
ZWavePoller, che si occuperà di interrogare i dispositivi ad intervalli di tempo regolari, definiti nel file di configurazione, secondo le specifiche che saranno analizzate
successivamente.
A questo punto il Driver è registrato nel framework OSGi e le funzioni definite
nell’interfaccia ZWaveNetwork diventano disponibili per altri bundle che ne vogliono
fare uso. Le funzionalità esposte sono le seguenti.
• read(...): aggiorna lo stato interno del Device desiderato sincronizzandolo con
i dati contenuti nell’albero JSON proveniente da Z-Way. Questa funzionalità
è ottenuta tramite l’uso del metodo newMessageFromHouse(...) disponibile
su tutti i Driver.
• readAll(...): esegue le medesime operazioni della funzione precedente, ma su
tutti i Device.
• updateSensor(...): forza il sensore fisico ad aggiornare il suo stato presso il
server Z-Way.
• write(...) e controllerWrite(...): eseguono un comando specifico su un device
o sul controller. Sono equivalenti a /ZWaveAPI/Run/<command>
• addDriver(...) e removeDriver(...): aggiunge o rimuove un Driver dalla lista dei
driver installati.
La comunicazione a livello di chiamate POST viene fatta dalla classe ConnectionManager per mezzo delle librerie client Jersey, mentre tramite le librerie Jackson, viene effettuato il parsing dei dati JSON ricevuti dal server. La prima volta
che viene richiesto lo stato di un Driver (tramite read(...))viene usato il comando
/ZWaveAPI/Data/0 per ottenere lo stato dell’intero sistema che viene caricato in
memoria. Successivamente verrà utilizzato un valore diverso da 0, per ottenere
35
3 – Sviluppo progetto
solo le variazioni dall’ultima richiesta e minimizzare le elaborazioni e la quantità
di dati trasmessi.
Nel bundle del network driver si trova anche la classe astratta ZWaveDriver, che
deve essere implementata da tutti i Driver Z-Wave e che contiene alcune funzioni
di inizializzazione comuni ed un set di metodi astratti che devono successivamente
essere sviluppati in base alla natura del driver che si sta realizzando. In particolare,
ogni Device dovrà implementare un metodo ad hoc per gestire i messaggi provenienti dal device fisico newMessageFromHouse(...) ed un altro metodo per la creazione
del ZWaveNodeInfo ad esso associato, createNodeInfo(...). Lo ZWaveNodeInfo verrà
poi utilizzato dal poller per conoscere quali CommandClasses sono disponibili per
il device analizzato.
ZWavePoller
Il motore che mette in relazione tutte le funzioni fin qui definite è lo ZWavePoller.
Esso si occupa, secondo la cadenza definita dal file di configurazione del network
driver, di forzare l’update dei dispositivi fisici verso Z-Way.
Bisogna distinguere due tipi di comportamento tra i dispositivi collegati alla linea elettrica e quelli alimentati a batteria, che a loro volta si distinguono in
ambientali e triggerati dall’esterno. I primi sono sempre in ascolto sulla linea di
comunicazione con il server Z-Way e l’aggiornamento del loro valore può essere
considerato semi-istantaneo. I device della seconda categoria, al contrario, entrano
nello stato di sleep per limitare il consumo delle batterie e si svegliano ad intervalli
di tempo regolari. Questo tipo di comportamento fa si che una richiesta di update
non venga effettivamente mai eseguita fin tanto che il dispositivo non si sveglia e
risponde al server. Il periodo di sleep può essere definito tramite l’interfaccia web
di Z-Way, tenendo conto che minore è tale periodo, maggiore sarà il consumo delle
batterie. Per la terza categoria, invece, il problema non si pone poiché essi comunicheranno repentinamente a Z-Way ogni cambio di stato, rendendo la funzione di
update inutile.
Per ogni Driver caricato il poller terrà traccia dell’ultima richiesta di update
effettuata e dell’ora a cui rischedulare una nuova richiesta: ad ogni ciclo di polling,
se tale orario sarà stato superato, verrà effettuato un nuovo update verso quel
sensore. Poiché ogni singolo Driver ha definito ogni quanto tempo deve essere
forzato l’update, il caso peggiore viene dato da:
tempoSleepDispositivo + sleepThread + tempoUpdate.
Nella figura 3.1 viene riassunto il processo in inizializzazione del NetworkDriver.
Nella prima fase il bundle viene avviato dal framework (1), il quale riceve il file di
configurazione necessario per registrarsi come servizio disponibile (2). Prima che
questo avvenga, il bundle stabilisce una connessione con il server Z-Way, disponibile
sul RaZberry (3) e solo successivamente avvia il poller (4). A questo punto il bundle
36
3.2 – Driver
può registrarsi sul framework, esponendo i servizi e i metodi definiti nell’interfaccia
pubblica (5).
Figura 3.1.
3.2.4
Processo di inizializzazione del network driver
Gateway driver
Il gateway driver implementa le funzionalità specifiche del RaZberry. In questo
contesto ci si è limitati a creare le funzioni necessarie per l’associazione e la disassociazione di un nuovo dispositivo ed il reset del controller. Le prime due funzionalità sono state realizzate avviando un thread separato che comunica al controller
di entrare nello stato di pairing per 20 secondi. Al termine di questo periodo il
controller ritorna a funzionare nella sua modalità normale.
37
3 – Sviluppo progetto
Benché si occupi di comunicare con un nodo particolare del sistema, la sua
struttura è molto simile a quelli dei driver generici analizzati più avanti. Si hanno
prevalentemente due classi: la prima, ZWaveGatewayDriver, implementa l’interfaccia OSGi Driver, mentre la seconda, ZWaveGatewayDriverInstance, le funzionalità
specifiche del nodo trattato. Come visto nella sezione precedente, l’interfaccia
Driver deve essere implementata da tutti i servizi che desiderano effettuare una
procedura di attachment con un Device. Ogni volta che il sistema rileva un nuovo
Device viene infatti avviata tale procedura, al cui termine viene istanziato l’oggetto che si occuperà di gestire le funzionalità specifiche del nodo, che in questo caso
prende il nome di ZWaveGatewayDriverInstance.
3.2.5
Driver dispositivi
I Driver dei dispositivi fisici seguono tutti lo stesso schema del gateway driver: si ha
una prima classe che implementa l’interfaccia org.osgi.service.device.Driver di OSGi
ed una seconda che implementa una o più interfacce di Dog di tipo DeviceCategory.
Le DeviceCategory sono l’anello di congiunzione tra il Driver specifico ed il core di
Dog, che in questo modo può conoscere quali funzioni sono utilizzabili per un dato
Device. E’ immediato notare che, in base a questa struttura, Dog potrebbe non
poter accedere a tutte le funzioni reali del dispositivo: ad esempio molti dispositivi
Z-Wave hanno delle funzioni per controllare il livello delle batterie, ma le interfacce
utilizzate, che devono essere più generiche possibile, non hanno nessuna funzione
a questo proposito.
Ogni Driver di questa categoria implementa anche l’interfaccia ManagedService,
necessaria per poter configurare in maniera dinamica e separata il tempo che deve
intercorrere tra due update forzati dello stato del dispositivo. Poiché non per tutti
i device è sensato un comportamento simile è possibile impostare tale valore a 0.
I Driver si differenziano tra di loro prevalentemente per la gestione dei messaggi
provenienti dal device fisico: la funzione newMessageFromHouse(...) è responsabile di aggiornare lo stato della struttura dati interna in base ai valori ricevuti
dall’esterno. Questa particolare operazione ha creato diversi problemi in fase di
implementazione: dato che non tutti produttori seguono alla lettera le specifiche
del protocollo, in alcuni casi, la lettura dei dati dei sensori ha richiesto dei workaround per ottenere correttamente tali valori. Per questo motivo, benché in linea
teorica sia possibile collegare qualsiasi device di cui esista già un Driver, non è
possibile assicurare il corretto funzionamento con alcuni modelli.
Per lo sviluppo di questo progetto sono stati implementati i seguenti Driver:
• DimmableDevice: per controllare device dimmerabili, come lampade alogene;
• DoorWindowSensor: per l’utilizzo dei sensori di apertura e chiusura di porte
e finestre;
38
3.3 – Database
• LightSensor: per la misurazione della luminosità;
• MeteringPowerOutlet: per le prese che forniscono la lettura dei kW istantanei
e dei kWh;
• MovementSensor: per i sensori di movimento;
• OnOffDevice: per ogni dispositivo che abbia la funzionalità di acceso /
spento: lampadine, interruttori, ecc;
• SinglePhaseElectricityMeter: per l’utilizzo dei misuratori monofase;
• TemperatureAndHumiditySensor: per la rilevazione della temperatura ed
umidità di un ambiente.
Nell’immagine 3.2 viene mostrato lo schema completo del funzionamento di
un Driver. Dopo l’esecuzione di match e attach, Dog istanzia il Driver che ha
restituito il valore maggiore (1). Prima di essere registrato sul sistema, il Driver
deve ricevere il proprio file di configurazione (2), creare l’oggetto NodeInfo che lo
rappresenta e fornirlo allo Z-Wave Network Driver (3). Successivamente il NodeInfo
verrà registrato tra i dispositivi disponibili dello ZWavePoller (4).
Durante le fasi successive, quando il sistema sarà operativo, lo ZWavePoller
utilizzerà il Network Driver per chiedere al server Z-Way di aggiornare lo stato
del dispositivo(5). Z-Way aggiornerà il proprio stato interno in funzione della
risposta del dispositivo (6). Contestualmente il poller forzerà il Network Driver ad
aggiornare la struttura dati rappresentante il sistema, chiedendo al server Z-Way
i dati appena raccolti (7). Questo aggiornamento verrà poi propagato al Driver
bundle con il metodo newMessageFromHouse(...) (8) e, se necessario, l’evento sarà
propagato a Dog tramite la notifyEvent(...) (9).
3.3
Database
Dopo la creazione dei Driver il sistema è in grado di comunicare con i device in
maniera autonoma: il cambio dello stato di uno di loro verrà processato dai Driver
permettendo all’utente di sapere in ogni momento lo stato del sistema.
Poiché ciò che si vuole realizzare è una storicizzazione degli eventi per poterne
permettere un’analisi ed una visualizzazione a posteriori, è necessario introdurre
l’uso di un database per il salvataggio dei dati. Tale database non conterrà solo
il log degli eventi, ma verrà utilizzato anche per permettere la memorizzazione di
alcune preferenze dell’utente relative all’interfaccia grafica.
Per evitare di introdurre un legame forte tra i bundle dei driver e del database,
quest’ultimo è stato implementato come modulo a sé stante, solo ed unicamente
dipendente dal core di Dog. Il framework OSGi mette a disposizione un’interfaccia tramite la quale è possibile registrare un listener su un determinato insieme di
39
3 – Sviluppo progetto
Figura 3.2.
Funzionamento di un Driver bundle
eventi: org.osgi.service.event.EventHandler. In questo modo il suo funzionamento è
completamente astratto dalle tipologie di device presenti nel sistema ed il design
utilizzato permetterà di registrare qualsiasi tipo di evento proveniente da un dispositivo reale. Il file di configurazione necessario al suo funzionamento permette
40
3.3 – Database
inoltre di definire un sub-set di device che si desidera monitorare o lasciare che il
bundle registri tutti gli eventi.
Figura 3.3.
Diagramma ER del database
Nella figura 3.3 è illustrata la struttura del database, mentre qui di seguito
vengono analizzate in dettaglio le tabelle.
Nella tabella Event sono memorizzati tutti gli eventi generati dal sistema.
• Event ID: chiave primaria della tabella.
• Created: data ed ora dell’evento.
• Notification: il tipo di notifica ricevuta. Indica la tipologia dell’evento registrato come potenza, temperatura, ecc.
• State: lo stato del dispositivo. Popolato solo nel caso di dispositivi binari
come interruttori o sensori di movimento.
• Unit: l’unità di misura associata alla misurazione, se presente.
• Value: il valore della misurazione.
• Time Measure ID: indica l’intervallo di tempo a cui si riferisce la misurazione.
Real-time, valore accorpato degli ultimi 10 minuti, ecc.
• Device ID: indica il dispositivo che ha generato l’evento.
La tabella TimeMeasure memorizza le unità di tempo disponibili nel sistema e la
loro definizione è fortemente legata alla configurazione di spChains.
41
3 – Sviluppo progetto
• Time Measure ID: chiave primaria della tabella.
• Code: codice univoco utilizzato nella configurazione del bundle per mappare
gli eventi generati da spChains con l’unità di tempo stessa.
• Delete After: indica dopo quanti minuti gli eventi che ne fanno riferimento
possono essere eliminati.
• Name: nome user-friendly utilizzato nell’interfaccia del grafico.
• Sequence: indica l’ordinamento tra le voci della tabella stessa ed è usato nel
processo di cancellazione degli eventi.
Ogni record nella tabella Device identifica la singola tipologia di notifica che un
dispositivo può generare.
• Device ID: chiave primaria della tabella. In questo caso non è un valore numerico, ma la concatenazione dell’URI del dispositivo con una delle notifiche
che può generare. Per un sensore di temperatura ed umidità, ad esempio, si
avranno quindi due record separati.
• Description: campo di testo liberamente utilizzabile.
• Device URI: URI univoco all’interno del sistema.
• Name: nome user-friendly utilizzato nell’interfaccia del grafico
• Chart Type: permette di definire come devono essere disegnati i dati relativi
al record in oggetto.
• Graph Panel ID: riferimento al pannello nel quale i dati devono essere disegnati.
Infine, nella tabella GraphPanel, vengono memorizzati i dati necessari a definire le
zone del grafico, permettendo di avere aree separate a seconda della tipologia di
sensore visualizzato.
• Graph Panel ID: chiave primaria della tabella.
• Name: nome user-friendly utilizzato come label per l’area del grafico.
• Sequence: ordinamento di visualizzazione delle zone.
• Proportion: definisce la dimensione dell’area stessa.
42
3.3 – Database
Quando è disponibile un nuovo evento, questo viene passato come parametro
alla funzione handleEvent(Event). Gli eventi ricevuti si suddividono in quelli realtime, inviati dai dispositivi, e quelli generati da spChains, che rappresentano le
medie delle misurazioni precedenti. La prima categoria si divide a sua volta in
due casi particolari: eventi di tipo parametrico e non parametrico. Quelli di tipo
parametrico sono eventi che hanno al loro interno i valori delle misurazioni dei
sensori, mentre quelli non parametrici sono legati al cambio di stato di un dispositivo, ad esempio l’accensione di un interruttore o la rilevazione di un movimento.
Indipendentemente dalla loro natura vengono processati in maniera simile: viene
risolto il Device che ha generato l’evento, creandolo se non esiste già nel database
ed il suo valore è salvato, insieme agli altri dati necessari, nella tabella relativa.
La creazione del Device nel database non ha un vero e proprio scopo in questa
fase, ma permetterà l’associazione di un alias nell’interfaccia grafica più semplice
da riconoscere per l’utente.
Gli eventi generati da spChains hanno invece la necessità di essere elaborati in
maniera completamente diversa rispetto a quelli real-time. Ciò è dovuto al fatto
che spChains genera eventi che hanno come source spChains stesso e non il Device
che li ha generati, inoltre è necessario anche poter riconoscere se la misurazione
ricevuta è relativa, ad esempio, all’ultima ora o alla giornata passata. Poiché
anche spChains deve rimanere un bundle astratto rispetto al resto del sistema, è
necessario definire nel file di configurazione di H2 una serie di parametri che ne
permettano la decodifica.
Come si può vedere nella figura 3.4 sono definiti differenti punti di drain per
ogni catena. Quando un set di dati viene generato da un drain (il cui nome deve
essere univoco), questo è a tutti gli effetti un oggetto di tipo Event, intercettato dal
bundle di H2, che ha come source il nome del drain definito nell’XML. E’ quindi
necessario definire una mappatura tra:
• il drain ed il device relativo;
• il drain ed il tipo di notifica generato (lo stesso device può misurare umidità
e temperatura, ad esempio);
• il drain e l’unità di misura alla quale si riferisce il valore contenuto nell’oggetto
Event, tramite la quale sarà possibile riconoscere se i dati aggregati sono la
media degli ultimi 10 minuti o dell’ultima ora.
Quando il bundle di H2 riceverà un evento da spChains sarà a questo punto in
grado di decodificarlo ed inserirlo nel database insieme a tutti i dati accessori. E’ da
notare che, a differenza degli eventi real-time, che verranno salvati in automatico
senza nessun intervento da parte dell’utente, quelli legati al calcolo delle medie
richiedono un setup che deve essere ragionato per poter funzionare correttamente.
Inoltre l’aggiunta di un nuovo tipo di raggruppamento temporale richiede anche la
definizione della voce relativa nella tabella TimeMeasure.
43
3 – Sviluppo progetto
Figura 3.4.
Una catena di elaborazione definita in spChains
Poiché l’intero sistema sarà elaborato su una piattaforma dalla limitata disponibilità di memoria è stato introdotto un metodo, facilmente configurabile dall’utente
finale, per permettere la cancellazione degli eventi quando questi sono antecedenti
ad una certa data. I campi DeleteAfter e Sequence, nella tabella TimeMeasure, hanno esattamente questo scopo. All’inserimento di un nuovo Event rappresentante
una media di valori, vengono eliminati tutti gli eventi legati ad una TimeMeasure con sequenza minore di una unità rispetto alla TimeMeasure dell’evento che si
sta inserendo, registrati da più di DeleteAfter minuti. In questo modo, anche se
il sistema viene lasciato online per lunghi periodi, l’utilizzo della memoria viene
limitato. E’ comunque possibile disabilitare questa funzionalità inserendo 0 come
valore della colonna DeleteAfter.
Poiché non sarebbe stato corretto da un punto di vista dell’architettura del sistema permettere che bundle esterni possano lavorare direttamente sul database, si
è definita l’interfaccia it.polito.elite.dog.addons.h2eventstore.api.H2Store che espone
all’esterno tutti i metodi per recuperare i dati offerti dal bundle . Ovviamente
tali metodi saranno sviluppati in base alle esigenze dei bundle esterni, ma si evita di esporre all’intero sistema le primitive per accedere al db, cosa che avrebbe
facilmente portato ad una cattiva gestione delle transazioni e dei dati stessi. Per
facilitare la realizzazione di questa parte si è utilizzato il framework JPA che permette di lavorare con le entità, e quindi a livello più alto, senza doversi occupare
direttamente dell’architettura del database. Inoltre JPA consente di annotare le
44
3.4 – UI
entità create con una serie di parole chiave, grazie alle quali è possibile passare da
oggetto Java a stringa JSON senza nessun lavoro addizionale.
Figura 3.5. Rappresentazione schematica del bundle H2. Dog (1) e SpChains
(2) generano una serie di eventi che vengono intercettati dal bundle e inseriti nel
database (3). I dati vengono resi disponibili al resto del sistema tramite l’interfaccia
registrata sotto forma di modelli JPA (4)
3.4
UI
Grazie al lavoro svolto fino a questo punto il sistema è in grado di comunicare
con i device Z-Wave registrando gli eventi da loro generati. L’ultima parte di
questo capitolo riguarda l’implementazione di un’interfaccia grafica che permetta
all’utente la visualizzazione di quanto è stato registrato dal sistema. Oltre alla
semplice visualizzazione dei dati raccolti è stata anche prevista la possibilità da
parte dell’utente finale di personalizzare la stessa, implementando funzionalità ad
hoc.
45
3 – Sviluppo progetto
La base di partenza è un server Jetty che sarà raggiungibile da qualsiasi dispositivo facente parte della rete locale. Nell’ottica di poter utilizzare tale interfaccia
anche su dispositivi con schermo ridotto, si è deciso di ricorrere all’uso del framework Twitter Bootstrap, che è una collezione di diversi elementi grafici che
possono essere facilmente utilizzati per la composizione di pagine web. Inoltre,
dalla versione 2.0, esso permette di realizzare pagine web fluide, ovvero in grado di
adattarsi automaticamente alla dimensione dello schermo, agendo sulla posizione
dei singoli elementi.
Il server, già presente nell’architettura di Dog, è di tipo REST (REpresentational State Transfer). Tale tipo di architettura, a differenza di quella SOAP (Simple
Object Access Protocol), permette di ricevere come risposta uno stream in formato
sia XML sia JSON. In base al metodo HTTP utilizzato è possibile accedere alle
azioni tipiche dei modelli CRUD.
REST
POST
GET
PUT
DELETE
CRUD(Create, Read, Update, Delete)
Create
Read
Update or Create
Delete
Grazie all’utilizzo della libreria client di Jersey, è stata create un’interfaccia,
it.polito.elite.dog.admin.system.powermonitor.api.PowerMonitorInterface, nella quale
sono registrati una serie di metodi associati ad un URL. Quando il server rileva
una richiesta del client mappata sul metodo, si occupa di invocare il metodo stesso
e restituire i dati nel formato prefissato che in questo caso deriva dalla definizione
del model utilizzato nel bundle del database. Grazie alle notazioni JPA utilizzate
nella definizione del modello, è sufficiente restituire l’oggetto stesso: sarà la libreria ad occuparsi di trasformare tale oggetto nella stringa JSON che lo rappresenta,
senza nessun intervento da parte del programmatore.
L’anello di congiunzione tra il codice Java e la pagina HTML è rappresentato da
AngularJS. Grazie a questo framework è possibile implementare il pattern MVC,
dove i Model sono gli stessi utilizzati a livello di database, le View sono le pagine
web, mentre i Controller sono implementati tramite Javascript seguendo le logiche
di AngularJS stesso. Al suo interno sono inoltre disponibili diversi comandi per
la validazione dei dati, che non devono quindi essere definite a parte, ma possono
essere incluse nel file HTML stesso, limitando di molto gli errori tipici di questa fase.
Tramite questi strumenti è stato quindi possibile definire facilmente le tre pagine
utilizzate per leggere e modificare le tabelle Device (figura 3.7 e 3.8), GraphPanel
(figura 3.9) e TimeMeasure (figura 3.10).
Nella pagina relativa ai Device viene mostrato un elenco di tutti i dispositivi
monitorati. La loro creazione avviene in automatico dopo il primo evento, ma qui
46
3.4 – UI
Figura 3.6. I dati, registrati sul database (1) sono esposti nel framework dal
bundle H2 tramite modelli JPA (2). Tali modelli sono utilizzati da AngularJS per
popolare l’interfaccia utente basata su Bootstrap (3).
è possibile definire un nome più significativo per l’utente, il tipo di grafico che si
vuole realizzare per questo Device ed in quale zona tale grafico deve essere posizionato (GraphPanel). Anche le TimeMeasure non possono essere create direttamente
dall’utente (per quanto visto nella capitoletto precedente non avrebbe senso se non
viene modificata anche la parte relativa ad spChains), ma anche qui è possibile
definire un nome più significativo per l’utente e per quanto tempo i dati devono
essere conservati (DeleteAfter). L’ultima pagina è quella dei GraphPanel: qui è
possibile creare e definire le varie zone del grafico dove verranno riportati i dati.
Oltre al nome è necessario specificare l’ordinamento e la sua dimensione espressa
47
3 – Sviluppo progetto
in multipli di 100px. Tale struttura rende facilmente configurabile l’eventuale aggiunta di un nuovo device, benché si traduca in un’elaborazione più complessa in
fase di realizzazione del grafico.
Figura 3.7.
Finestra per la gestione dei Device
Figura 3.8.
Finestra per la modifica dei Device
48
3.4 – UI
Figura 3.9.
Figura 3.10.
Finestra per la gestione dei Graph Panel
Finestra per la gestione delle Time Measure
A questo punto è possibile analizzare la creazione del grafico vero e proprio.
A differenza delle pagine web analizzate fino ad ora, dove era sufficiente restituire
l’oggetto Java per avere il JSON corrispondente, qui è necessario costruire manualmente la stringa desiderata in base alla libreria utilizzata per la creazione del
grafico stesso, in questo caso HighCharts. Tramite l’interfaccia è possibile filtrare i risultati per data e tipo permettendo così un maggior controllo sull’output
finale. Bisogna notare che, come detto in precedenza, non tutti i dispositivi restituiscono un valore numerico, per questo è prevista la possibilità di mappare tale
valore nel file di configurazione del bundle powerMonitor. Il bundle fornisce quindi
un JSON che rappresenta completamente il grafico: dai valori delle singole serie
filtrate secondo interfaccia, all’aspetto grafico finale.
La libreria HighCharts mette a disposizione numerose funzionalità di default,
come lo zoom su una zona del grafico e la scelta di quali dispositivi visualizzare. Più
in generale, permette di customizzare ogni singolo aspetto del grafico visualizzato,
ma si è preferito focalizzarsi sugli aspetti più inerenti all’obiettivo del progetto,
lasciando tali valori inalterati rispetto alle configurazione base.
49
3 – Sviluppo progetto
Figura 3.11.
Dettaglio del filtro per la selezione del range temporale.
Al termine dello sviluppo di quest’ultimo bundle il sistema è pronto per entrare
in funzione: i bundle dei driver si occuperanno di comunicare con i dispositivi fisici,
creando eventi ogni qualvolta il loro stato cambierà. Il bundle di H2 intercetterà tali
eventi e si occuperà di salvarli in una base dati insieme alle medie delle misurazioni
derivanti dalle elaborazione del bundle spChains; infine il bundle powerMonitor,
grazie al server Jetty, alle librerie Jersey ed ai framework utilizzati, permetterà
all’utente di analizzare i dati raccolti in maniera semplice ed intuitiva.
50
Figura 3.12.
Esempio di grafico visualizzato.
3.4 – UI
51
52
Capitolo 4
Risultato finale
Lo sviluppo di questo progetto ha portato ad ottenere degli ottimi risultati ed il
raggiungimento di tutti gli obiettivi prefissati. Se si guarda al sistema nel suo
complesso, si sono unite diverse tecnologie per arrivare ad avere una struttura utilizzabile effettivamente come sistema di monitoraggio energetico portatile, anzi si è
andati oltre integrando nello sviluppo la scrittura dei driver per alcuni dispositivi
non direttamente collegati al concetto di monitoraggio energetico, ma che possono
dare un’idea più precisa dell’ambiente in cui gli stessi dispositivi operano. Tali
driver sono completamente indipendenti dal resto del sistema e vanno a colmare
l’assenza di driver per i dispositivi Z-Wave all’interno di Dog, anche grazie all’impiego di un’interfaccia semplice come quella messa a disposizione da Z-Way. Per
questo i driver qui sviluppati sono già stati inglobati all’interno di Dog stesso e
sono attualmente oggetto di ulteriori sviluppi per aderire alle specifiche di Dog 3.0.
Anche il modulo del database, grazie alla sua definizione indipendente dal resto
del sistema, può essere utilizzato fin da subito per catalogare e loggare gli eventi
del sistema, non solo quelli derivanti da dispositivi Z-Wave, ma qualsiasi device
che disponga dei driver Dog, senza alcuna modifica. La scelta di un database come
H2 si è rivelata vincente per il suo utilizzo su un sistema embedded: le prestazioni
si sono rilevate assolutamente soddisfacenti anche quando il sistema opera a pieno
regime, sia per quanto riguarda la scrittura sia per la lettura dei dati.
Infine, il modulo relativo all’interfaccia si rivela efficace e di facile utilizzo anche
da parte di coloro hanno poca dimestichezza con i sistemi informatici, permettendo
in maniera semplice ed intuitiva la modifica di alcuni parametri di visualizzazione.
AngularJS ha consentito inoltre di sviluppare un’interfaccia snella sia da un punto
di vista pratico sia da quello di sviluppo informatico.
53
4 – Risultato finale
4.1
Possibili sviluppi futuri
Il sistema permette la raccolta di un elevato numero di dati che al momento vengono visualizzati all’utente finale tramite una sola tipologia di grafico. Parte di
questa scelta ricade sul fatto che il Raspberry Pi ha una potenza di calcolo limitata e difficilmente sarebbe stato possibile sviluppare una vera e propria logica di
Business Intelligence su un dispositivo simile. Si potrebbe quindi pensare di affiancare ad un sistema così configurato un centro di elaborazione più performante
per il calcolo e la visualizzazione di grafici più complessi e talvolta più significativi.
Ad esempio, potrebbe essere molto interessante vedere l’andamento dei consumi
per fasce orarie o per giorni della settimana nel lungo periodo. Anche continuando
ad utilizzare il Raspberry Pi come centro di elaborazione, si potrebbe pensare di
aggiungere un set di grafici per fornire informazioni più complete e fruibili.
Altro punto che potrebbe essere sviluppato e migliorato è l’aggiunta di un nuovo
dispositivo al sistema. Benché la sua installazione sia semplice se eseguita seguendo
la procedura fornita (vedi Appendice A), questa è senza ombra di dubbio complicata per una persona non abituata all’utilizzo di certi sistemi. A questo proposito
bisogna però distinguere la differenza presente tra Dog, spChains ed il modulo del
database. In Dog esiste già un processo che genera in automatico tutti i file necessari quando si installa un nuovo dispositivo, ma è una procedura molto pesante da
un punto di vista elaborativo e non è quindi adatta a funzionare sul Raspberry Pi.
Al contrario spChains ed il modulo del database non hanno una funzionalità simile
al momento, benché per il primo sia probabile che venga sviluppata un’interfaccia
user-friendly nel prossimo futuro. Più in generale l’interfaccia qui sviluppata rappresenta un primo tentativo di rendere facilmente fruibile le enormi potenzialità di
Dog, finora gestibili solo tramite file o interfacce piuttosto complicate.
Nei sistemi attualmente in commercio spesso si ha la possibilità di definire il
costo dell’energia in base alle diverse fasce orarie. Un indicatore di questo tipo
renderebbe ancora più chiara la lettura dei consumi, con un feedback di maggiore
impatto soprattutto su soggetti non abituati alla lettura di grafici o indicatori.
D’altra parte l’implementazione di un sistema simile avrebbe richiesto la necessità
di uno studio approfondito delle tipologie di contratto disponibili nel mondo.
Nel primo capitolo si è accennato anche al fatto che diverse ricerche hanno evidenziato come una parte importante del sistema sia quella ‘sociale’. La possibilità
di comparare i propri consumi con quelli di abitazioni simili o di avere accesso a
dati di altri utenti, può essere vista come un’aggiunta sostanziale al sistema. Sviluppare un sistema simile è tutt’altro che banale, ma può essere molto interessante
per il futuro.
54
4.1 – Possibili sviluppi futuri
Un tema non affrontato a nessun livello durante questo progetto è quello relativo
alla sicurezza informatica del sistema: l’interfaccia fornita è accessibile a chiunque
conosca l’indirizzo IP del Raspberry Pi. Questo potrebbe non rappresentare un
problema nel caso di una rete privata, ma non sarebbe sicuramente adatta ad
un’infrastruttura pubblica.
55
56
Appendice A
Guida all’uso
A.1
Aggiunta di un nuovo sensore
Per aggiungere un nuovo elemento al sistema di monitoraggio occorre:
1. Avviare la procedura di pairing tra Z-Way ed il device, seguendo le istruzioni
specifiche del dispositivo. Se necessario collegarsi all’interfaccia di demo di
Z-Way per impostare un valore di sleep corretto.
2. Modificare il file zwave.xml o, in generale, il file che rappresenta l’House Model
inserendo la definizione del device da aggiungere. Si raccomanda di copiare
una delle definizioni già presenti nel file andando a modificare il valore della
proprietà name, gli id dei comandi ed il valore del parametro NodeID. Si
riporta come esempio la definizione di un MeteringPowerOutlet
<dhc : d e v i c e domoticSystem ="ZWave " name="ZW_MeteringPowerOutlet_8 "
c l a s s =" M e t e r i n g P o w e r O u t l e t " gateway ="zwave−gateway">
<dhc : d e s c r i p t i o n ></dhc : d e s c r i p t i o n >
<dhc : i s I n >s t o r a g e r o o m </dhc : i s I n >
<dhc : param v a l u e ="13" name="NodeID " />
<dhc : param v a l u e ="0" name=" I n s t a n c e I D " />
<dhc : c o n t r o l F u n c t i o n a l i t y c l a s s =" O n O f f F u n c t i o n a l i t y ">
<dhc : commands>
<dhc : command i d ="OffCommand_ZW8" name="OffCommand_ZW8"
c l a s s ="OffCommand">
<dhc : param v a l u e =" o f f " name="realCommandName"/>
</dhc : command>
<dhc : command i d ="OnCommand_ZW8" name="OnCommand_ZW8"
c l a s s ="OnCommand">
<dhc : param v a l u e ="on " name="realCommandName"/>
</dhc : command>
</dhc : commands>
</dhc : c o n t r o l F u n c t i o n a l i t y >
<dhc : c o n t r o l F u n c t i o n a l i t y
c l a s s =" A c t i v e P o w e r M e a s u r e m e n t F u n c t i o n a l i t y ">
<dhc : commands>
<dhc : command i d ="GetActivePowerCommand_ZW8 "
57
A – Guida all’uso
name="GetActivePowerCommand_ZW8 "
c l a s s ="GetActivePowerCommand">
<dhc : param v a l u e =" g e t A c t i v e P o w e r " name="realCommandName " />
<dhc : param v a l u e ="Measure " name=" r e t u r n T y p e " />
</dhc : command>
</dhc : commands>
</dhc : c o n t r o l F u n c t i o n a l i t y >
<dhc : c o n t r o l F u n c t i o n a l i t y
c l a s s =" A c t i v e P o w e r M e a s u r e m e n t F u n c t i o n a l i t y ">
<dhc : commands>
<dhc : command i d ="GetActiveEnergyValueCommand_ZW8 "
name="GetActiveEnergyValueCommand_ZW8 "
c l a s s ="GetActiveEnergyCommand">
<dhc : param v a l u e =" g e t A c t i v e E n e r g y V a l u e "
name="realCommandName " />
<dhc : param v a l u e ="Measure " name=" r e t u r n T y p e " />
</dhc : command>
</dhc : commands>
</dhc : c o n t r o l F u n c t i o n a l i t y >
<dhc : n o t i f i c a t i o n F u n c t i o n a l i t y
c l a s s =" S t a t e C h a n g e N o t i f i c a t i o n F u n c t i o n a l i t y ">
<dhc : n o t i f i c a t i o n s >
<dhc : n o t i f i c a t i o n name=" S t a t e C h a n g e N o t i f i c a t i o n _ Z W 8 "
c l a s s =" S t a t e C h a n g e N o t i f i c a t i o n ">
<dhc : param v a l u e =" s t a t e C h a n g e d " name=" n o t i f i c a t i o n N a m e " />
<dhc : param t y p e =" S t a t e " v a l u e =" n e w S t a t e "
name=" n o t i f i c a t i o n P a r a m N a m e " />
</dhc : n o t i f i c a t i o n >
</dhc : n o t i f i c a t i o n s >
</dhc : n o t i f i c a t i o n F u n c t i o n a l i t y >
<dhc : n o t i f i c a t i o n F u n c t i o n a l i t y
c l a s s =" A c t i v e P o w e r M e a s u r e m e n t N o t i f i c a t i o n F u n c t i o n a l i t y ">
<dhc : n o t i f i c a t i o n s >
<dhc : n o t i f i c a t i o n name=" ActivePowerMeasurementNotification_ZW8 "
c l a s s =" A c t i v e P o w e r M e a s u r e m e n t N o t i f i c a t i o n ">
<dhc : param v a l u e ="2" name="nParams " />
<dhc : param v a l u e =" newActivePowerValue "
name=" n o t i f i c a t i o n N a m e " />
<dhc : param name=" u n i t O f M e a s u r e " v a l u e ="W" />
<dhc : param t y p e ="Measure " v a l u e =" v a l u e "
name=" n o t i f i c a t i o n P a r a m N a m e " />
</dhc : n o t i f i c a t i o n >
</dhc : n o t i f i c a t i o n s >
</dhc : n o t i f i c a t i o n F u n c t i o n a l i t y >
<dhc : n o t i f i c a t i o n F u n c t i o n a l i t y
c l a s s =" A c t i v e E n e r g y M e a s u r e m e n t N o t i f i c a t i o n F u n c t i o n a l i t y ">
<dhc : n o t i f i c a t i o n s >
<dhc : n o t i f i c a t i o n
name=" A c t i v e E n e r g y M e a s u r e m e n t N o t i f i c a t i o n _ Z W 8 "
c l a s s =" A c t i v e E n e r g y M e a s u r e m e n t N o t i f i c a t i o n ">
<dhc : param v a l u e ="2" name="nParams " />
<dhc : param v a l u e =" ne wAct ive Ene rgy Val ue "
name=" n o t i f i c a t i o n N a m e " />
<dhc : param name=" u n i t O f M e a s u r e " v a l u e ="Wh" />
<dhc : param t y p e ="Measure " v a l u e =" v a l u e "
name=" n o t i f i c a t i o n P a r a m N a m e " />
</dhc : n o t i f i c a t i o n >
</dhc : n o t i f i c a t i o n s >
</dhc : n o t i f i c a t i o n F u n c t i o n a l i t y >
<dhc : s t a t e c l a s s =" O n O f f S t a t e ">
<dhc : s t a t e v a l u e s >
<dhc : s t a t e v a l u e name=" o f f " c l a s s =" O f f S t a t e V a l u e "/>
58
A.1 – Aggiunta di un nuovo sensore
<dhc : s t a t e v a l u e name="on " c l a s s =" OnStateValue "/>
</dhc : s t a t e v a l u e s >
</dhc : s t a t e >
<dhc : s t a t e c l a s s =" EnergyMeasurementState ">
<dhc : s t a t e v a l u e s >
<dhc : s t a t e v a l u e name="" c l a s s =" A c t i v e E n e r g y S t a t e V a l u e " />
</dhc : s t a t e v a l u e s >
</dhc : s t a t e >
<dhc : s t a t e c l a s s =" A c t i v e P o w e r M e a s u r e m e n t S t a t e ">
<dhc : s t a t e v a l u e s >
<dhc : s t a t e v a l u e name="" c l a s s =" A c t i v e P o w e r S t a t e V a l u e " />
</dhc : s t a t e v a l u e s >
</dhc : s t a t e >
</dhc : d e v i c e >
3. Aprire il file sourceDeviceMapping.xml ed inserire i riferimenti al nuovo device.
Questo file definisce quali device vengono presi in considerazione da spChains
per la creazione degli eventi aggregati; nel caso in cui non sia necessaria questa
funzionalità è possibile saltare alla sezione sull’uso della UI.
Inserire le righe seguenti per ogni tipo di notifica che si vuole far intercettare
a spChains. Il sensorURI deve essere uguale al campo name del dhc:device
definito in precedenza.
<sdm : s e n s o r sensorQFParams =""
s e n s o r Q F u n c t i o n a l i t y =" A c t i v e P o w e r M e a s u r e m e n t N o t i f i c a t i o n "
s ens or U R I ="ZW_MeteringPowerOutlet_8 " u i d ="zwave−8−ActivePower " />
4. Definire, nel file spProcessor.xml, la catena di elaborazione per spChains
legata al nuovo sensore inserito (una per ogni notifica). Si rimanda alla
documentazione di spChains stesso per le istruzioni dettagliate.
5. Nel file di configurazione di H2, h2.config, definire il mapping tra i vari blocchi
della catena di elaborazione e gli elementi di sistema. Con la parola chiave
‘map.’ si definiscono le mappatura tra il campo blockId di ogni blocco e
l’unità di misura contenuta nella tabella TimeMeasure. Tali chiavi devono
iniziare con ‘map.’. Ad esempio:
map . 8 _ActivePower_15m=15m
map . 8 _ActivePower_30m=30m
map . 8 _ActivePower_1h=1h
map . 8 _ActivePower_4h=4h
map . 8 _ActivePower_1g=1g
Con la parola chiave ‘drain.’ si definiscono, invece, le mappature tra ogni
drain ed il corrispondente device:
drain
drain
drain
drain
drain
. ZW_8_ActivePowerDrain#1=ZW_MeteringPowerOutlet_8
. ZW_8_ActivePowerDrain#2=ZW_MeteringPowerOutlet_8
. ZW_8_ActivePowerDrain#3=ZW_MeteringPowerOutlet_8
. ZW_8_ActivePowerDrain#4=ZW_MeteringPowerOutlet_8
. ZW_8_ActivePowerDrain#5=ZW_MeteringPowerOutlet_8
Infine con ‘notification.’ si indica la corrispondenza tra un drain e il suo tipo
di notifica:
59
A – Guida all’uso
n o t i f i c a t i o n . ZW_8_ActivePowerDrain#1=
ActivePowerMeasurementNotification
n o t i f i c a t i o n . ZW_8_ActivePowerDrain#2=
ActivePowerMeasurementNotification
n o t i f i c a t i o n . ZW_8_ActivePowerDrain#3=
ActivePowerMeasurementNotification
n o t i f i c a t i o n . ZW_8_ActivePowerDrain#4=
ActivePowerMeasurementNotification
n o t i f i c a t i o n . ZW_8_ActivePowerDrain#5=
ActivePowerMeasurementNotification
6. Nel caso di sensori binari, se non è già stato definito in precedenza, aggiungere al file powermonitor.config la mappatura tra il valore del sensore binario
espresso in parole ed il valore numerico per la visualizzazione nel grafico.
Deve essere utilizzato il prefisso ‘value.’:
v a l u e . on=1
v a l u e . o f f =0
A.2
Uso della UI
Collegandosi all’indirizzo http://IPRaspberry:8080 si accede all’interfaccia grafica
del sistema. Allo stato attuale sono disponibili 5 finestre di gestione diverse.
Nel tab ‘Status’, vengono riportate alcune informazioni sullo stato del sistema: la
memoria disponibile e quella utilizzata, i dispositivi collegati e lo stato dei bundle.
Il tab ‘Devices’ elenca i dispositivi che hanno generato almeno un evento;
la loro creazione è infatti automatica ed avviene in concomitanza con la prima
registrazione. I campi modificabili sono:
• name: usato nel grafico per identificare facilmente il device;
• description: campo di testo libero;
• chart type: definisce come i dati di questo device devono essere visualizzati
nel grafico; se non viene definito un valore viene assunto il tipo ‘lines’;
• graph panel: stabilisce dove devono essere tracciati i dati di questo dispositivo; questo campo deve essere obbligatoriamente definito prima di poter
visualizzare il grafico;
Il tab ‘Time Measure’ mostra i vari livelli di aggregazione per i dati disponibili.
I dati modificabili in questo caso sono solamente:
• name: usato nel grafico per identificare facilmente il livello di raggruppamento;
• delete after: dopo quanti minuti gli eventi che ne fanno riferimento possono
essere cancellati dal sistema;
60
A.3 – Grafico
Per la modifica degli altri valori o la creazione di nuovi livelli di aggregazione
bisogna agire direttamente sul database. Questo processo è stato volutamente reso
più complesso poiché l’aggiunta di nuovi record in questa tabella deve essere seguita
dalla revisione della definizione di spChains e dei file di configurazione collegati e
non è quindi un’operazione eseguibile da utenti senza le necessarie conoscenze del
sistema.
Il tab ‘Graph Panel’ permette la definizione di nuove aree del grafico e la loro
modifica. E’ possibile modificare i seguenti dati:
• name: usato nel grafico come label della zona;
• proportion: definisce la dimensione della zona di visualizzazione;
• sequence: l’ordinamento dei pannelli nel grafico;
A.3
Grafico
L’ultimo tab disponibile,‘Graph’, è quello per la visualizzazione dei dati raccolti.
In alto a sinistra si trova un menù a tendina per la scelta della tipologia dei dati
che si desiderano visualizzare. Nel caso si stiano visualizzando i dati in realt-time,
il grafico si aggiornerà automaticamente, mentre per gli altri raggruppamenti è
necessario agire manualmente tramite il tasto ‘Update’.
A destra è disponibile un filtro per selezionare un range di date da visualizzare:
alcuni intervalli sono predefiniti, ma è possibile agire manualmente e selezionare
qualsiasi orario e data.
Nella parte dedicata al grafico si trova la legenda ed i vari pannelli definiti nella
sezione ‘Graph Panel’: cliccando su uno dei nomi dei dispositivi nella legenda è
possibile nascondere la serie relativa. E’ inoltre possibile esportare il grafico in vari
formati tra cui JPG e PDF, oppure procedere alla stampa diretta dello stesso.
Infine, selezionando una particolare misurazione verrà mostrato un tooltip con
le informazioni dettagliate, mentre evidenziando una sezione del grafico è possibile
effettuare uno zoom sullo stesso.
61
62
Bibliografia
[1] ENEA.
L’etichetta energetica, 2013.
http://www.enea.it/it/
produzione-scientifica/pdf-opuscoli/OpuscoloEtichettaEnergetica.
pdf.
[2] Industria Energia. Italiani: attenti al risparmio energetico, ma poco informati
sulle soluzioni, Maggio 2013. http://www.industriaenergia.it.
[3] Sarah Darby. Demand response: the effectiveness of feedback on energy
consumption, Settembre 2009.
[4] Voltimum. Domotica: stato dell’arte, terminologia, protocolli, 2013. http:
//www.voltimum.it/techarea.php?dyntype=gie&hsid=66.
[5] Simone Pecchenino. Standard domotico z-wave nel gateway dog2.0: Integrazione e sperimentazione.
Master’s thesis, Politecnico di Torino,
2010.
[6] Dario Bonino, Fulvio Corno, Luigi De Russis. Home energy consumption
feedback: A user survey, Dicembre 2011.
[7] FindTheBest.
Compare h2 vs sqlite,
2013.
http://
database-management-systems.findthebest.com/compare/16-53/
H2-vs-SQLite.
[8] Google. Angularjs, 2013. http://angularjs.org/.
[9] Gruppo e-Lite. Dog, 2012. http://elite.polito.it/dog-tools-72.
[10] Gruppo e-Lite. spchains: A declarative framework for data stream processing
in pervasive applications, 2012. http://elite.polito.it/spchains.
[11] H2 Group. H2 database engine, 2013. http://www.h2database.com.
[12] Highsoft. Highcharts, 2013. http://www.highcharts.com/.
[13] Gianluca Moretti. Osgi platform, 2008. http://www.programmazione.it/
index.php?entity=eitem&idItem=39127.
[14] Vesternet Ltd.
Understanding z-wave networks, nodes & devices, 2012. http://www.vesternet.com/resources/technology-indepth/
understanding-z-wave-networks.
[15] Wikipedia. Angularjs, 2013. http://en.wikipedia.org/wiki/AngularJS.
[16] Wikipedia. H2 (dbms), 2013. http://en.wikipedia.org/wiki/H2_(DBMS).
63
Bibliografia
[17] Wikipedia. Model-view-controller, 2013. http://en.wikipedia.org/wiki/
Model-view-controller.
[18] Wikipedia. Service-oriented architecture, 2013. http://it.wikipedia.org/
wiki/Service-oriented_architecture.
[19] Wikipedia. Z-wave, 2013. http://en.wikipedia.org/wiki/Z-Wave.
[20] Z-Wave.Me Team. Razberry, 2013. http://razberry.z-wave.me/.
[21] Z-Wave.Me Team. Razberry user and developers documentation, 2013. http:
//razberry.z-wave.me/docs/razberry.pdf.
[22] Z-Wave.Me Team.
Z-way developers documentation, 2013.
http://
razberry.z-wave.me/docs/zwayDev.pdf.
64