SpokenHouse: applicazione mobile cross-platform di supporto ai non vedenti per il controllo domotico. Interfacciamento con un framework domotico

1
UNIVERSITÀ DEGLI STUDI DEL SANNIO
DIPARTIMENTO DI INGEGNERIA
CORSO DI LAUREA MAGISTRALE IN INGEGNERIA INFORMATICA
Tesi di Laurea
SpokenHouse: applicazione mobile cross-platform di
supporto ai non vedenti per il controllo domotico.
Interfacciamento con un framework domotico
Relatore: Candidato:
Prof.ssa Lerina Aversano Marco Di Brino
Prof.ssa Maria Tortorella Mat. 399000052
Correlatore:
Dott. Manuel Parrella
Anno Accademico 2013/2014

2
A tutti quelli che mi supportano e sopportano.
E quindi, soprattutto, a me stesso

3
Ringraziamenti
I primi ringraziamenti vanno alle professoresse Lerina Aversano e Maria Tortorella che ci
hanno dato l’opportunità di svolgere questo lavoro di tesi. La loro professionalità, la loro
disponibilità, la loro presenza e i loro consigli in questi ultimi mesi sono stati degli elementi
fondamentali per la buona riuscita del lavoro.
Grazie a Informatici Senza Frontiere che, soprattutto nelle persone di Manuel Parrella e Adia
Barretta, ci ha dato l’opportunità di dare inizio a questo progetto cosi bello e affascinante, ma
soprattutto cosi utile per alcune persone più sfortunate di noi.
Un sentito ringraziamento va anche al team di produzione di FreeDomotic, e soprattutto a
Matteo Mazzoni e Mauro Cicolella. La loro pazienza e la loro disponibilità nel rispondere via
mail a tutti i nostri dubbi e ai nostri problemi sono stati fondamentali per il proseguo del nostro
progetto.
Grazie ai miei genitori, che nel corso di questi anni universitari non mi hanno mai fatto
mancare il loro sostegno morale e psicologico. Senza di loro non ce l’avrei potuta mai fare,
quindi questa laurea è anche vostra.
Un grazie speciale va a Daniela. Con lei ho condiviso questo lavoro di tesi, ma soprattutto ho
condiviso questi ultimi due anni di università. Le disavventure, le risate, il nervosismo, le
confidenze, le perdite di tempo, tutto. In qualsiasi situazione lei c’era. Per farla breve, sei stata
un’amica vera. E spero che tutto questo non si interrompa col finire di questo percorso di vita.
Un sentito ringraziamento va anche a tutti gli altri compagni di studio e vita che ho incontrato
in questi anni. Grazie a Fiorella, sempre pronta e disponibile a darmi una mano quando ce ne
era bisogno, anche quando non lo chiedevo; grazie a Chiara, che riesce sempre a rendere speciali
quei pochi momenti che riusciamo a passare assieme; grazie a Domenico, con il quale fin
dall’inizio ho condiviso tempo e studio di molti esami; grazie ad Antonio che, nonostante il
passare degli anni, è ancora al mio fianco quando ne ho bisogno; grazie a Enrico, Ermanno,

4
Paolo e tutti quanti gli altri ragazzi che ho incontrato durante il mio cammino universitario e
che mi hanno aiutato nel raggiungimento di questo traguardo.
Infine, ma non per ordine di importanza, un grazie eccezionale va alla mia ragazza Annarita.
Sempre pronta a darmi una mano, a sostenermi nelle difficoltà ed a esultare con me nei momenti
belli. Grazie per essere cosi paziente, per sopportarmi e per capire subito di cosa ho bisogno. Ora
è finito questo capitolo importante della mia vita, ma spero che tutto questo amore ci sia anche
nel prossimo, qualsiasi esso sia.

5
Sommario
SOMMARIO......................................................................................................................................5
ELENCO DELLE FIGURE......................................................................................................................9
ELENCO DELLE TABELLE ..................................................................................................................12
1 INTRODUZIONE......................................................................................................................13
1.1 ORGANIZZAZIONE DEL LAVORO....................................................................................................14
2 INFORMATICI SENZA FRONTIERE............................................................................................16
2.1 IL DIGITAL DIVIDE E LA DISABILITÀ................................................................................................17
2.2 I PROGETTI DI ISF .....................................................................................................................18
3 STATO DELL’ARTE...................................................................................................................20
3.1 CHE COS’È LA DOMOTICA ...........................................................................................................20
3.1.1 Interessi applicativi .........................................................................................................21
3.1.2 Elementi essenziali ..........................................................................................................22
3.1.3 Costi e diffusione.............................................................................................................23
3.1.4 Accessibilità per i non vedenti.........................................................................................25
3.1.4.1 Light Detector ...................................................................................................................... 25
3.1.4.2 Sicare Pilot ........................................................................................................................... 26
3.1.5 Internet of Things............................................................................................................27
3.2 FRAMEWORK DOMOTICI OPEN SOURCE.........................................................................................28
3.2.1 Souliss..............................................................................................................................29
3.2.1.1 Struttura software................................................................................................................31
3.2.2 Eclipse Smart Home ........................................................................................................33
3.2.3 FreeDomotic....................................................................................................................35
3.2.3.1 Framework........................................................................................................................... 36
3.2.3.2 Plugins..................................................................................................................................37
3.2.3.3 Sistema di messaggistica......................................................................................................38
3.2.3.4 Il percorso di un messaggio..................................................................................................39
3.2.3.5 Messaggi e regole ................................................................................................................39
3.2.3.6 Channel ................................................................................................................................ 41
3.2.4 Tabella comparativa .......................................................................................................42
3.3 HARDWARE.............................................................................................................................44
3.3.1 Arduino............................................................................................................................44
3.3.2 Raspberry Pi ....................................................................................................................45

6
3.4 APP MOBILE ............................................................................................................................46
3.4.1 Casa Domotica ExControl................................................................................................47
3.4.2 Souliss App ......................................................................................................................48
3.4.3 Winkhel Building Automation .........................................................................................49
3.4.4 Menu Domotico ..............................................................................................................51
3.5 CONCLUSIONI ..........................................................................................................................52
4 SISTEMA MOBILE DI SUPPORTO AI NON VEDENTI..................................................................53
4.1 SCOPO DELL’APPLICAZIONE.........................................................................................................53
4.1.1 Analisi degli utenti...........................................................................................................54
4.1.2 Accessibilità.....................................................................................................................55
4.2 ANALISI DEI REQUISITI ...............................................................................................................56
4.2.1 Attori del sistema............................................................................................................58
4.2.2 Casi d’uso ........................................................................................................................59
4.3 ARCHITETTURA A LIVELLI ............................................................................................................73
4.3.1 Design pattern MVC: Model View Controller..................................................................77
4.4 ARCHITETTURA DEL SISTEMA.......................................................................................................78
4.5 ARCHITETTURA DELL’APPLICAZIONE DI SPOKENHOUSE .....................................................................80
4.5.1 View ................................................................................................................................82
4.5.2 Controller ........................................................................................................................82
4.5.3 Model..............................................................................................................................84
4.5.4 Diagramma delle classi generico ....................................................................................84
4.5.5 Vincoli..............................................................................................................................85
4.6 TECNOLOGIE UTILIZZATE ............................................................................................................86
4.6.1 Cross Platform Computing ..............................................................................................86
4.6.1.1 Apache Cordova................................................................................................................... 87
4.6.1.2 Plugin di Apache Cordova ....................................................................................................89
4.6.2 HTML 5............................................................................................................................89
4.6.3 CSS 3................................................................................................................................91
4.6.4 JavaScript ........................................................................................................................91
4.6.4.1 JSON.....................................................................................................................................92
4.6.5 WebSQL...........................................................................................................................93
4.6.6 XML .................................................................................................................................93
4.6.7 REST.................................................................................................................................94
4.6.8 TCP/IP..............................................................................................................................96
4.6.9 HTTP................................................................................................................................97

7
4.7 AMBIENTI DI SVILUPPO ..............................................................................................................98
4.7.1 Configurazione Apache Cordova.....................................................................................98
4.7.2 Configurazione FreeDomotic.........................................................................................101
4.7.2.1 Connessione al framework.................................................................................................102
4.7.2.2 Personalizzazione dell’ambiente di lavoro.........................................................................103
4.7.2.3 Creazione di nuovi oggetti .................................................................................................105
4.7.3 Problemi progettuali .....................................................................................................107
5 VERIFICA E VALIDAZIONE .....................................................................................................108
5.1 SPOKENHOUSE: FUNZIONALITÀ E SOTTO-FUNZIONALITÀ.................................................................108
5.2 TEST DI USABILITÀ...................................................................................................................111
5.3 TEST FUNZIONALE...................................................................................................................113
5.3.1 Scenario di testing.........................................................................................................114
5.3.2 Piattaforma e configurazione ambiente .......................................................................115
5.4 CONFIGURAZIONE APPLICAZIONE ...............................................................................................115
5.4.1 Test funzionale: configurazione applicazione ...............................................................119
5.4.1.1 Esito dei test funzionali......................................................................................................122
5.4.2 Test di usabilità: configurazione applicazione ..............................................................123
5.5 ACCENSIONE DI UNA LUCE IN UNA STANZA...................................................................................123
5.5.1 Test funzionale: accensione luce...................................................................................126
5.5.1.1 Esito dei test....................................................................................................................... 126
5.5.2 Test di usabilità: accensione luce ..................................................................................127
5.6 IMPOSTAZIONE DELLA TEMPERATURA DI LAVAGGIO DELLA LAVATRICE................................................127
5.6.1 Test funzionale: temperatura di lavaggio della lavatrice..............................................129
5.6.1.1 Esito dei test....................................................................................................................... 130
5.6.2 Test di usabilità: temperatura di lavaggio della lavatrice.............................................131
5.7 ELENCO DEI DISPOSITIVI ACCESI .................................................................................................131
5.7.1 Test funzionale: dispositivi accesi..................................................................................133
5.7.1.1 Esito dei test....................................................................................................................... 134
5.7.2 Test di usabilità: dispositivi accesi.................................................................................134
5.8 PROBLEMI RISCONTRATI...........................................................................................................135
6 CONCLUSIONI E SVILUPPI FUTURI ........................................................................................137
6.1 CONCLUSIONI ........................................................................................................................137
6.2 SVILUPPI FUTURI ....................................................................................................................138
A. GLOSSARIO DEI TERMINI......................................................................................................139

8
B. TEST FUNZIONALE: SCRIPT PYTHON .....................................................................................142
BIBLIOGRAFIA...............................................................................................................................152

9 Elenco delle figure
Elenco delle figure
Figura 3-1 Sistema domotico completo..................................................................... 24
Figura 3-2 Sicare Pilot .................................................................................................. 26
Figura 3-3 Architettura di Souliss ............................................................................... 30
Figura 3-4 Souliss App ................................................................................................. 31
Figura 3-5 Struttura della memoria in Souliss ........................................................... 32
Figura 3-6 Eclipse Smart Home.................................................................................. 34
Figura 3-7 Interfaccia grafica di FreeDomotic.......................................................... 36
Figura 3-8 Interazioni tra le varie componenti di FreeDomotic ............................ 37
Figura 3-9 Caratterizzazione di una reaction............................................................. 39
Figura 3-10 Arduino Diecimila ................................................................................... 45
Figura 3-11 Raspberry Pi.............................................................................................. 46
Figura 3-12 Interfaccia grafica di Casa Domotica ExControl ................................ 47
Figura 3-13 Interfaccia grafica di Souliss App .......................................................... 49
Figura 3-14 Interfaccia grafica di Winkhel Build Automation................................ 50
Figura 3-15 Interfaccia grafica di Menu Domotico.................................................. 52
Figura 4-1 Interfaccia grafica di Strillone................................................................... 55
Figura 4-2 Diagramma dei casi d'uso ......................................................................... 58
Figura 4-3 Sequence diagram del caso d’uso 1: configurazione applicazione....... 62
Figura 4-4 Sequence diagram del caso d’uso 2: impostazione temperatura
termostato...................................................................................................................... 64

Figura 4-5 Sequence diagram del caso d'uso 3: accensione luce............................. 66
Figura 4-6 Sequence diagram del caso d'uso 4: impostazione temperatura di
lavaggio della lavatrice .................................................................................................. 69
Figura 4-7 Sequence diagram del caso d'uso 5: accensione luci nella zona notte. 71
Figura 4-8 Sequence diagram del caso d’uso 6: verifica dispositivi accesi............. 73
Figura 4-9 Architettura a livelli.................................................................................... 74
Figura 4-10 Architettura two-tier................................................................................ 76
Figura 4-11 Architettura three-tier.............................................................................. 76
Figura 4-12 Model View Controller ........................................................................... 77
Figura 4-13 Architettura del sistema SpokenHouse................................................. 79
Figura 4-14 Porzione dell’architettura del sistema sviluppata................................. 80
Figura 4-15 Logica di Apache Cordova ..................................................................... 81
Figura 4-16 Architettura dell’applicazione di SpokenHouse................................... 81
Figura 4-17 Funzionamento dei plugin di Apache Cordova................................... 83
Figura 4-18 Diagramma delle classi generico............................................................ 85
Figura 4-19 Applicazione della cross platform ......................................................... 86
Figura 4-20 Funzionamento di Apache Cordova..................................................... 88
Figura 4-21 Caratteristiche di HTML 5 ..................................................................... 90
Figura 4-22 API di FreeDomotic................................................................................ 95
Figura 4-23 Oggetti di default forniti da FreeDomotic ......................................... 105
Figura 4-24 Esempio di command ........................................................................... 106

Figura 5-1 Menu dell'applicazione di SpokenHouse.............................................. 109
Figura 5-2 Utenti durante i test................................................................................. 112
Figura 5-3 Screenshot relativi al caso d’uso 1 ......................................................... 117
Figura 5-4 Porzione di codice relativo alla gestione del DB del device............... 118
Figura 5-5 Screenshot relativi al caso d'uso 3.......................................................... 124
Figura 5-6 Porzione di codice relativo all'autenticazione su FreeDomotic......... 125
Figura 5-9 Porzione di codice relativo alla visualizzazione dei dispositivi accesi133
Figura 5-10 Rotazioni consentite su Android ......................................................... 135
Figura 5-11 Rotazione non consentita su Android ................................................ 136

12 Elenco delle tabelle
Elenco delle tabelle
Tabella 1 Tabella comparativa dei framework domotici ......................................... 43
Tabella 2 Attori del sistema ......................................................................................... 59
Tabella 3 Caso d'uso 1: configurazione applicazione............................................... 62
Tabella 4 Caso d'uso 2: impostazione temperatura termostato.............................. 64
Tabella 5 Caso d'uso 3: accensione luce..................................................................... 66
Tabella 6 Caso d'uso 4: impostazione temperatura di lavaggio della lavatrice...... 69
Tabella 7 Caso d'uso 5: accensione luci nella zona notte ........................................ 71
Tabella 8 Caso d'uso 6: verifica dispositivi accesi..................................................... 73
Tabella 9 Vincoli relativi al caso d’uso 1.................................................................. 121
Tabella 10 Test frame relativo al caso d'uso 1 ........................................................ 122
Tabella 11 Esito del test del caso d'uso 1 ................................................................ 122
Tabella 12 Test frame relativo al caso d’uso 3 ........................................................ 126
Tabella 13 Esito del test relativo al caso d'uso 3 .................................................... 127
Tabella 18 Glossario dei termini............................................................................... 141

13 Introduzione
CAPITOLO 1
1 Introduzione
Questo lavoro di tesi nasce dalla volontà dei volontari di Informatici Senza Frontiere
ONLUS (ISF) di fornire uno strumento utile per aiutare le persone emarginate o in
difficoltà a superare il cosiddetto digital divide (divario digitale).
Grazie alle moderne tecnologie e agli strumenti informatici, il gruppo ISF vuole rendere
accessibile l’Internet Of Things, ed in particolare la gestione di un sistema domotico, a
persone non vedenti, ipovedenti (o con gravi problemi di vista) e non udenti.
L’obiettivo principale di questo lavoro di tesi è quindi quello di abbattere o comunque
tentare di diminuire il digital divide. Questo progetto intende realizzare un sistema per il
controllo dei dispositivi elettronici presenti in un’abitazione; questo sistema prevede la
realizzazione di un’applicazione mobile, avente un’interfaccia grafica che vada il più
possibile incontro alle esigenze di queste persone, usufruendo inoltre di tecnologie che
permettano lo sviluppo di un’applicazione mobile.
Tutti i progetti di ISF realizzati finora, in ambito applicazioni mobile e desktop, sono
open-source, quindi distribuiti gratuitamente; al fine di proseguire questo modus-
operandi, è stato scelto quindi di utilizzare tecnologie di supporto open-source per la
realizzazione di questo progetto.
L’interfaccia grafica dell’applicazione, inoltre, si intende realizzarla in maniera cross-
platform, in modo da rendere accessibile l’applicazione al target utente selezionato, a
prescindere dalla tipologia di sistema operativo installato sullo smartphone.
Il sistema realizzato prevede anche la presenza di un framework domotico, installato su
di un PC o su una board programmabile, con il quale l’applicazione mobile si dovrà
interfacciare e inviare i comandi richiesti dall’utente del sistema.

14 Introduzione
La realizzazione di questo sistema, denominato SpokenHouse, è stato suddiviso in due
lavori di tesi.
In questo verranno trattati approfonditamente gli argomenti riguardanti il framework di
controllo domotico che è stato scelto di utilizzare, dopo una fase di ricerca, che più si
adatta alle esigenze del progetto; inoltre, verranno trattati alcuni aspetti riguardanti
l’implementazione dell’applicazione mobile realizzata, prestando attenzione a come essa
interagisce, comunica e si interfaccia con il framework di domotica utilizzato.
L’altro lavoro di tesi, svolto in parallelo a questo, è stato svolto da Daniela
Guardabascio, la quale si è occupata della progettazione dell’interfaccia grafica
dell’applicazione, focalizzandosi particolarmente sulle esigenze di queste persone con
difficoltà visive e/o uditive e permettendo lo sviluppo di codesta applicazione in
maniera cross-platform.
1.1 Organizzazione del lavoro
Questa tesi è composta dalla seguente introduzione e da altri 5 capitoli.
Nel secondo capitolo verrà effettuata una panoramica sul gruppo ISF e sui loro progetti
realizzati nel corso degli anni; verrà inoltre argomentata la loro mission e il loro impegno
atto ad introdurre gli strumenti tecnologici come supporto al tenore di vita dei soggetti
disagiati.
Nel terzo capitolo verrà effettuata un’analisi dello stato dell’arte riguardante il concetto
di domotica e sui principali framework domotici presenti sul mercato; inoltre, verranno
caratterizzati alcuni hardware programmabili e alcune applicazioni mobile presenti sul
mercato, sempre nel contesto domotico.
Nel quarto capitolo verrà descritto più nel dettaglio lo scopo di questo lavoro di tesi
(ovvero il sistema mobile di supporto ai non vedenti realizzato), descrivendo
dettagliatamente la tipologia di utenza alla quale l'applicazione è orientata, i requisiti
funzionali che l’applicazione deve soddisfare, i principali scenari e casi d’uso

15 Introduzione
dell’applicazione. Inoltre, verrà descritta l’architettura del sistema intero, ponendo
l’attenzione sulle principali tecnologie utilizzate durante lo sviluppo.
Nel quinto capitolo sarà fatta una panoramica sulla fase di verifica e validazione di
SpokenHouse, descrivendo quindi più particolarmente alcune funzionalità
dell’applicazione realizzata; per ognuna di queste, sono presentati i test effettuati, sia
funzionali che quelli direttamente sul campo in collaborazione con la sede di Benevento
dell’Unione Italiana Ciechi.
Nell’ultimo capitolo, infine, verranno descritte le conclusioni a cui si è giunti e i possibili
ampliamenti del lavoro svolto.

16 Informatici Senza Frontiere
CAPITOLO 2
Alla fine del 2005, un gruppo di manager veneti che lavorano nel settore informatico ha
deciso di investire le proprie conoscenze in un aiuto concreto contro il digital divide. E’
nata così una Onlus che ha come primo obiettivo quello di utilizzare conoscenze e
strumenti informatici per portare un aiuto concreto a chi vive situazioni di
emarginazione e difficoltà. La mission di ISF è infatti quella di aiutare, tramite
l’applicazione pratica e consapevole dell’ICT (Information and Communication
Technology), i “soggetti deboli” ad essere più liberi.
Per i fondatori e i volontari di Informatici Senza Frontiere, l'accesso alle tecnologie
dell'informazione e della comunicazione rappresenta un prerequisito essenziale allo
sviluppo economico e sociale: l'Information Technology dovrebbe essere considerata un
bene di primaria necessità, per questo si impegnano concretamente, in Italia e nel
mondo, per facilitare a soggetti che vivono realtà disagiate l'accesso agli strumenti
tecnologici.
ISF realizza progetti in Italia e nei paesi in via di sviluppo, offrendo l’opportunità di far
conoscere l’informatica e i vantaggi che anche una piccola tecnologia può portare a
realtà come ospedali, carceri, case di accoglienza e scuole. ISF crede nell’uso abilitante
delle ICT come modo per migliorare la qualità della vita.
Oggi Informatici Senza Frontiere conta dieci sezioni regionali e più di 300 soci e socie,
informatici e non, che contribuiscono alla vita dell’associazione. Secondo la nostra
vision, ISF crescerà, mantenendo intatti i valori di fondo, come associazione
caratterizzata dalla piacevolezza dello stare assieme e dall’affidabilità del suo operato.

2.1 Il Digital Divide e la disabilità
Il Digital Divide (divario digitale) è un fenomeno che riguarda il divario esistente tra chi
ha la possibilità di accedere ai servizi della tecnologia dell'informazione, grazie ad un
computer (o un dispositivo mobile) e tramite una connessione alla rete, e chi invece ne
resta escluso.
I motivi che portano all'esclusione dai servizi in questione riguardano principalmente
differenze socio-demografiche come condizione economica, livello d'istruzione,
differenza di età o di sesso, qualità delle infrastrutture e appartenenza a diversi gruppi
etnici ma anche la disparità nelle capacità e nelle conoscenze necessarie per l'accesso e la
partecipazione alla società dell'informazione. In questo ultimo caso si può anche parlare
di analfabetismo digitale.
Il mobile dà certamente un contributo al superamento del digital devide e della social
exclusion (esclusione sociale). Esso consente, infatti, alla persona con disabilità sia una
maggiore facilità di accesso a contenuti e servizi di vario genere, sia il miglioramento
della sua "partecipazione" alla vita sociale con amici, familiari e colleghi. Questo è
possibile grazie alla possibilità di accedere tramite i dispositivi mobile e le reti wireless al
grande mondo delle applicazioni Internet ed in particolare, ai contenuti del web, grazie
all'offerta di contenuti e servizi specifici.
Il forte valore aggiuntivo del mobile rispetto al PC è l'accesso ai contenuti in mobilità
“everywhere” e “everytime”: chiunque, anche chi non possiede un computer, ha la
possibilità di avere uno strumento di navigazione ed informazione. Lo scenario delle
opportunità che il mobile può offrire a un utente disabile è ricco e variegato, ovviamente
a patto che terminali, applicazioni e servizi offerti siano progettati e realizzati seguendo
le linee guida dell'accessibilità e dell'usabilità. Il mobile può consentire ad un non
vedente o ad un ipovedente, per esempio, di accedere ad informazioni in tutti quei
contesti in cui vi è una comunicazione esclusivamente visiva, come informazioni sul
binario di partenza dei treni delle stazioni, gli orari e le indicazioni sui tragitti e ritardi
degli autobus alle fermate, le informazioni di servizio in un hotel, ecc.

Tuttavia, lo smartphone può anche sostituire un PC: le maggiori opportunità sono state
riscontrate nel caso delle persone non vedenti. Esso ha infatti, caratteristiche di usabilità
preferibili rispetto ad un computer, grazie alle ridotte dimensioni e alla garanzia di
maggiore praticità di utilizzo (il cellulare è “senza fili”, non presenta problematiche di
connessione alla rete e nella maggior parte dei casi è già acceso nel momento dell'uso).
In aggiunta una persona non vedente con un basso livello di informatizzazione presenta
mediamente molte difficoltà nell'utilizzo della tastiera del PC, mentre non ha problemi
con l'uso dello smartphone.
L’elenco delle applicazioni potrebbe continuare a lungo. L’eliminazione del digital
divide, non è un meta da raggiungere, ma più un obiettivo mobile, visto che le
tecnologie cambiano di continuo e che occorre garantire anche una formazione continua
alle persone. Una maggiore sensibilizzazione di imprese, provider, società civile e
Pubblica Amministrazione potrebbe evitare e ridurre i rischi del digital divide.
2.2 I progetti di ISF
L’attività di ISF è iniziata con la realizzazione di "Open Hospital" (OH), un software
open source, che permette a piccole realtà ospedaliere di gestire il flusso dei pazienti e
dei medicinali con una certa sistematicità: OH è stato installato la prima volta ad Angal,
in Uganda, e poi in moltissimi altri ospedali africani e non solo. L’installazione è seguita
dai volontari di ISF, che si occupano di creare piccoli sistemi informativi nell’ospedale e
della formazione del personale.
Un altro importante progetto è quello realizzato all’Ospedale di Brescia, dove, al reparto
di oncologia pediatrica, è stato installato un sistema informativo che permette ai piccoli
pazienti, ricoverati per lunghi periodi, di comunicare con le loro famiglie, giocare, e
seguire un percorso scolastico. Questo progetto è stato poi replicato in altre città, dando
vita al progetto "Bambini al PC".
Fra gli altri progetti lanciati ci sono "Shashamane", per informatizzare alcune aule di una
scuola rurale dell'Etiopia, “Progetto scuole senza Frontiere” per aiutare un ragazzo con

una grave malattia di Forlì a seguire le lezioni scolastiche, “Progetto Il giardino dai mille
colori” a Scampia, uno dei quartieri più “difficili” di Napoli, dove è stato realizzato un
laboratorio informatico e un corso di introduzione all’informatica per i bambini del
quartiere. I volontari di ISF inoltre sono intervenuti nelle zone colpite dal terremoto in
Emilia, nel carcere di Treviso per il recupero sociale dei detenuti, in casi speciali come
per i malati di SLA (Sclerosi Laterale Amiotrofica) con il progetto ISA “I speak again”.
Una applicazione progettata e realizzata dai volontari di ISF è Strillone; questa è stata
pensata per persone con disabilità visive affinché possano ascoltare notizie provenienti
dalle testate giornalistiche. Una delle caratteristiche più importanti di Strillone è la sua
interfaccia: essa infatti è divisa orizzontalmente e verticalmente, in modo da creare 4
parti perfettamente uguali, cosi che l’utente possa sfruttare gli angoli fisici del device per
poter navigare facilmente all’interno del menù dell’applicazione. Attualmente Strillone è
disponibile gratuitamente nelle versioni per le principali piattaforme: Android, iOS per i
dispositivi Apple, Windows Phone e in versione Web Application utilizzabile su tutti i
dispositivi con connessione ad Internet.
ISF si occupa anche di offrire corsi e strumenti di alfabetizzazione informatica nelle
carceri, negli ospedali e tra persone che vivono situazioni di emarginazione e disagio.

20 Stato dell’arte
CAPITOLO 3
3 Stato dell’arte
3.1 Che cos’è la domotica
Il termine domotica [21] deriva dalla parola latina domus, che significa casa. La
domotica, infatti, si occupa di migliorare la qualità della vita all’interno delle abitazioni e,
più in generale, in tutti gli ambienti in cui vivono gli uomini. Fa riferimento a quella
scienza interdisciplinare che sfrutta i computer e l’elettronica per il controllo intelligente
di dispositivi in un ambiente domestico.
I sistemi domotici, per poter essere presentati al grande pubblico, devono essere
affidabili, semplici da usare e non devono mettere in pericolo l’utilizzatore anche in caso
di guasto o danneggiamento accidentale. Il target di destinazione di queste tecnologie
non è un professionista ma bensì l’utente medio, pertanto l’interfaccia deve essere
necessariamente user-friendly.
I sistemi domotici attualmente in uso sono molti e spaziano dal semplice controllo
remoto di luci ad un più intelligente network di micro-controllori e sensori sparsi per
casa [22]. I benefici possono essere tanti e maggiori nei casi di persone con particolari
disabilità motorie. Molti compiti e processi quotidiani sono automatizzati da macchine
sempre più specializzate: si pensi, ad esempio, alle lavatrici sviluppate per semplificare e
ridurre la quantità di lavoro manuale nel lavaggio della biancheria o ai sistemi di allarme
che sostituiscono le sentinelle nelle mansioni di guardia e sicurezza. Questi sono tutti
esempi d’automazione, piccoli tasselli di domotica a cui nessuno riesce più a rinunciare.

3.1.1 Interessi applicativi
La domotica è adottata per ragioni di semplificazione, sicurezza ed efficienza energetica:
si pensi al controllo di ambienti climatizzati, ai sistemi d’allarme, all’irrigazione
automatica o alle serrature elettroniche. Nelle semplici installazioni, “domotica” può
essere considerata dall’illuminazione automatica di una stanza al rilevamento di una
presenza. Nelle installazioni più avanzate, invece, la stanza può rilevare non solo la
presenza, ma sapere esattamente chi è entrato, settando una luce appropriata, una
temperatura adeguata, il volume della musica; può elencare persino le notizie del giorno.
Altre operazioni automatizzate potrebbero riguardare il risparmio energetico: è possibile
immaginare lo scenario in cui la casa rimane vuota e le luci vengono spente, i dispositivi
d’allarme attivati e i sistemi di climatizzazione settati nelle modalità di basso consumo.
Le aree di gestione di una casa e quindi le aree in cui viene applicata la domotica
possono essere suddivise in quattro settori:
 Gestione dell’ambiente: è a sua volta suddivisa in climatizzazione, riscaldamento,
illuminazione, distribuzione dell’energia, azionamento di sistemi d’apertura e
d’ingresso etc. Il controllo dell’ambiente viene automatizzato grazie alla presenza
di sensori e attuatori e ciò permette la termoregolazione dei locali e un consumo
più oculato delle risorse.
 Gestione degli apparecchi: sempre più spesso i più comuni elettrodomestici,
dalla lavatrice al frigorifero o al forno, montano dispositivi elettronici che ne
consentono la tele-gestione, sia a scopo diagnostico sia per regolare e attivare gli
apparecchi domestici.
 Comunicazione e informazione: questo settore spazia dai telefoni analogici o
voip al citofono o all’accesso a internet. Ma può anche comprendere la semplice
trasmissione di dati per il controllo remoto.
 Sicurezza: questa si occupa della gestione degli accessi, della protezione antifurto
e antintrusione e del videocontrollo. Tuttavia, la sicurezza non si occupa solo
degli agenti esterni ma anche di guasti domestici come fughe di gas, incendi o

allagamenti, eventi dannosi che se non controllati in tempo potrebbero
compromettere o distruggere la casa.
3.1.2 Elementi essenziali
Gli elementi essenziali di un sistema domotico includono:
 Sensori:
o sensori di temperatura;
o sensori fotocellule (per la luce ambientale);
o sensori di movimento (PIR);
o sensori di fumo;
o sensori di gas;
o sensori di pressione.
 Controllori:
o centraline;
o micro-controllori per elaborazione;
o unità centralizzata di calcolo (un PC di servizio preposto ad alcuni
compiti).
 Attuatori:
o valvole motorizzate;
o interruttori;
o motori;
o relè (meccanici o solidi);

o attuatori lineari.
 Interfacce:
o radiocomandi / telecomandi;
o interfaccia vocale;
o interfaccia smartphone / web;
o monitor grafico preinstallato.
 Network:
o bus cablato;
o comunicazione radio.
3.1.3 Costi e diffusione
Una casa automatizzata può essere un semplice raggruppamento di “controlli” oppure
può essere pesantemente automatizzata al punto da poter controllare ogni apparecchio
collegato in casa.
I costi variano largamente in base alle soluzioni adottate, alla fornitura, ai componenti e
all’installazione. I costi nel tempo, invece, possono riguardare il consumo di elettricità da
parte del sistema, i costi di manutenzione dei componenti o di aggiornamento e upgrade
di questi ultimi. Imparare ad usare un sistema domotico complesso può effettivamente
richiedere tempo e gli addetti all’installazione devono essere adeguatamente preparati
con training specifici per il sistema che si installa.
I sistemi domotici, di cui un esempio è mostrato in Figura 3-1, possono variare molto
l’uno dall’altro, e così la loro installazione: questo influisce molto sulla diffusione dei
sistemi domotici nel mondo. Un buon sistema richiede che l’abitazione su cui venga
installato sia predisposta per l’installazione: questo comporta il tenere in conto a priori
della messa in funzione di un sistema di questo tipo nella propria casa. E’ durante la

progettazione edile che il sistema trova già una collocazione. Per la stragrande
maggioranza dei casi invece, è necessario adeguarsi ad abitazioni già costruite che non
prevedevano in origine la messa in funzione di un sistema del genere. Sistemi meno
invasivi, che si adattino senza predisposizione, esistono, pur rinunciando all’eleganza
nell’installazione e talvolta a qualche funzionalità. Grazie inoltre al Decreto Sviluppo,
varato dal Governo, sarà economicamente vantaggioso riparare e mettere in regola gli
impianti elettrici domestici usufruendo del comfort e della sicurezza di un impianto
domotico allo stesso prezzo di un impianto tradizionale.
Figura 3-1 Sistema domotico completo

Secondo una ricerca di “ABI Research”, il mercato della domotica dovrebbe salire dal
suo valore stimato nel 2014 di 570 milioni di dollari a 2,6 miliardi di dollari nel 2017, con
un numero di impianti installati che prevede di raggiungere gli 8 milioni.
3.1.4 Accessibilità per i non vedenti
Per le persone non vedenti, o disabili in generale, operazioni quali telefonare, accendere
la luce e aprire una porta possono rappresentare una grande difficoltà. In questi ultimi
anni, si è registrato lo sviluppo di tecnologie avanzate o il netto miglioramento di quelle
già esistenti per permettere una facile e comoda accessibilità agli apparecchi domotici
anche a persone con disabilità di qualsiasi tipo.
3.1.4.1 Light Detector
Sul mercato delle applicazioni mobili, non è ancora presente un’applicazione, rivolta
soprattutto a persone non vedenti, capace di controllare tutti i dispositivi domotici
presenti in casa.
Al contrario, sono presenti delle applicazioni che aiutano il non vedente in alcune delle
piccole azioni quotidiane che si possono svolgere in casa. Una di queste è Light
Detector [1], applicazione a pagamento sviluppata per un qualsiasi dispositivo Apple.
Lo scopo principale di questa applicazione è quello di trasformare in suono qualsiasi
sorgente di luce naturale o artificiale che incontra. Il suo punto forte è l’utilizzo: una
volta attivata l’applicazione, basta puntare la telecamera del dispositivo nella direzione
desiderata e Light Detector emetterà un suono, la cui altezza aumenta o diminuisce al
variare dell’intensità della luce.
Negli ultimi aggiornamenti, sono stati inseriti anche altre funzionalità:
 se la fotocamera viene puntata verso il soffitto, l’applicazione aiuterà il non
vedente a trovare i lampadari della stanza e a capire se essi sono accesi o spenti;

 se la fotocamera viene mossa lungo una parete, l’applicazione avviserà l’utente
della presenza di finestre e della loro posizione; in più, muovendo il dispositivo
verticalmente, è anche possibile sapere se le tapparelle sono alzate, abbassate o a
mezza altezza.
Light Detector, nella sezione “accessibilità” del sito della Apple, è stata nominata come
una delle migliori applicazioni progettate per persone non vedenti.
3.1.4.2 Sicare Pilot
Al contrario delle applicazioni mobile, sul mercato sono presenti molti dispositivi
hardware, i quali, soprattutto tramite comandi vocali, aiutano le persone non vedenti
nella gestione di tutti i dispositivi domotici. Uno tra questi è il Sicare Pilot, il quale
permette di controllare agevolmente molte funzioni che sono indispensabili per una vita
autonoma e sicura.
Figura 3-2 Sicare Pilot

Esso è semplicemente un comune telecomando a raggi infrarossi, ma può anche
memorizzare e riconoscere sino a 64 comandi vocali, dai più semplici comandi “on/off”
di accensione di un apparecchio di illuminazione fino a comandi del tipo
“aumenta/diminuisci” per la regolazione dell’inclinazione della testata del letto. Il Sicare
Pilot converte questi comandi vocali in segnali a raggi infrarossi e comunica con un
ricevitore a infrarossi del sistema di controllo degli edifici instabus (sistemi open
decentralizzati) oppure con altri ricevitori a infrarossi come quello della televisione o
dello stereo.
Le caratteristiche fondamentali di Sicare Pilot sono:
 sistema di riconoscimento vocale per il controllo ambientale con struttura
programmabile;
 fino a 64 comandi individuali utilizzabili mediante un menù ad albero;
 rilevazione della voce mediante microfono interno o esterno;
 comando visivo mediante un display multifunzionale per menù e diagnosi;
 possibilità di controllo acustico mediante ripetizione vocale dei comandi
mediante altoparlante integrato o esterno.
3.1.5 Internet of Things
La domotica è uno di quei domini ed ambiti applicativi interessati negli ultimi anni allo
sviluppo di quegli strumenti e applicazioni che vanno sotto il nome di Internet of
Things.
“Internet of Things” permette non solo alle persone di parlare con le macchine, quanto
agli oggetti di dialogare direttamente tra loro. Non si tratta quindi solo di comandare e
monitorare a distanza, instaurando una rete di comunicazione fra essi: il passaggio da
IPv4 a IPv6, avvenuto di recente, permette un’incredibile svolta, in quanto ogni
dispositivo domestico potrebbe potenzialmente essere dotato di un indirizzo IP univoco
che lo contraddistingue e gli fornisce un accesso per comunicare sulla rete. Un altro
fattore fondamentale per la diffusione dell’Internet of Things sono i costi delle
componenti elettroniche in continuo calo. Con pochissimi euro, infatti, è possibile

acquistare dispositivi elettronici sempre più potenti e veloci, come ad esempio Arduino
e Xenyx [2]. Questi dispositivi, configurati in modo opportuno, permettono di integrare
oggetti domestici nati prima di questa rivoluzione fornendo un indirizzo IP a quasi tutti
gli oggetti comuni: dalle semplici lampade ad oggetti più complessi, come le lavatrici [3].
Ultime, ma non meno importanti, sono alcune caratteristiche degli attuali dispositivi
mobili, come la diffusione, le ridotte dimensioni e la potenza di calcolo. Quest’ultima è
diventata paragonabile a quella di computer e addirittura superiore nel caso di alcuni
modelli in circolazione. Ciò fornisce una spinta enorme al progetto di Internet of Things
in quanto fa degli smartphones uno strumento di controllo completo e versatile ma
soprattutto sempre disponibile. Le ridotte dimensioni, infatti, ne fanno i compagni di
viaggio ideali ed il costo ridotto ne favorisce la diffusione sul mercato. Gli smartphones
sono la chiave di volta di questo sistema: non essendo oggetti dedicati ad una funzione
possono offrire interfacce giuste per controllare ogni apparecchio domestico. Internet of
Things è molto di più che scambiare messaggi tra dispositivi: è la possibilità di mettere
in comunicazione e far sì che si comprendano differenti interfacce e differenti
dispositivi, la possibilità che svariati oggetti comunichino tra di loro per un obiettivo
comune, acquisendo in questo modo un comportamento “intelligente” in modo da
migliorare la nostra esperienza di vita [4].
In una casa domotica è fondamentale la complicità tra tutti gli apparecchi: non si parla
più di un singolo dispositivo ma ogni dispositivo acquisisce consapevolezza
dell’ambiente che lo circonda, ciascuno secondo le proprie caratteristiche. La possibilità
quindi di comunicare tra i vari dispositivi è la grande forza di questo sistema, un sistema
olistico che si rafforza più che linearmente all’aumentare dei dispositivi connessi e che è
in grado di offrire sempre maggiori servizi.
3.2 Framework domotici open source
In questa fase di lavoro di tesi, sono state effettuate delle ricerche tra i sistemi open
source di controllo domotico allo scopo di sviluppare un’applicazione liberamente
utilizzabile.

Di seguito ne saranno analizzati alcuni, per poi confrontarli in base alle loro
caratteristiche.
3.2.1 Souliss
Souliss [5] è un framework open-source completo, basato su schede Arduino con
interfaccia Android, progettato per le case intelligenti e Internet of Things. Esso
permette di controllare, gestire e programmare i dispositivi elettrici presenti nelle case
attraverso classici pulsanti o smartphone e tablet.
A differenza degli impianti domotici commerciali, Souliss permette di realizzare un
sistema distribuito e non centralizzato, ovvero un sistema che non necessita di un nodo
centrale. Si tratta quindi di una struttura logica di rete P2P (peer to peer) in cui ciascun
nodo della rete è in grado di scambiare dati attraverso una comunicazione wireless o
cablata con gli altri e di eseguire la propria logica da sé.
Come mostrato in Errore. L'origine riferimento non è stata trovata., il framework
completo è composto da tre livelli:
 Vnet, ovvero un protocollo di virtualizzazione di rete, che permette di
comunicare attraverso mezzi diversi (cablato o wireless) senza la necessità di
alcuna configurazione specifica per la rete;
 Macaco, ovvero un protocollo dati per la comunicazione P2P progettato per
microcontrollori con pochi byte di RAM;
 Souliss, ovvero l’insieme delle librerie utente scritte in C/C++ usate per gestire
la comunicazione tra i nodi.
Tale architettura a strati permette all’utente di interagire soltanto con le Souliss API, le
quali sfruttando i protocolli sopra citati (vNet e Macaco) rendono la programmazione
dei nodi estremamente semplice.
Inoltre, il sistema di automazione Souliss prevede una serie di codici già scritti (typicals)
per gestire alcuni soliti comportamenti hardware come l’accensione e spegnimento delle

luci, il monitoraggio energetico, la gestione della sicurezza etc. Grazie ai typicals è
potenzialmente possibile realizzare un impianto domotico di base senza scrivere alcuna
riga di codice.
Figura 3-3 Architettura di Souliss
Il lato client del progetto è rappresentato dalla SoulissApp, mostrata in Figura 3-4. Le
caratteristiche principali dell’applicazione, come riportato su Google Play, sono le
seguenti:
 rilevamento automatico dei dispositivi controllabili;
 scenari personalizzabili per raggruppare i comandi;
 programmi personalizzabili (temporali, geo-referenziati o basati su sensori);
 database locale per la raccolta di dati storici;
 servizio in background per la raccolta di informazioni;

 implementazione UDP per risparmiare connettività e batteria;
 supporto ed ottimizzazioni su tablet;
 look&feel personalizzabile.
Figura 3-4 Souliss App
Una caratteristica importante di Souliss è che non si limita a controllare una scheda
Arduino da un dispositivo Android, ma permette di creare una rete fatta da più
microcontrollori e dispositivi Android che comunicano tra di loro.
L’architettura della rete Souliss è fatta in modo che il malfunzionamento di un nodo non
comprometta il funzionamento degli altri nodi.
3.2.1.1 Struttura software
L’utente che usa Souliss non interagisce direttamente con vNet e MaCaco; queste due
librerie sono usate in metodi di Souliss al fine di creare un “home automation
environments”. Un nodo Souliss ha un’area di memoria condivisa, un array diviso in 3
parti: typical, input, output. Ogni parte contiene 8 byte, ognuno dei quali è uno “slot”.

L’idea base che caratterizza Souliss è la sua struttura a slot rappresentata in Errore.
L'origine riferimento non è stata trovata.; ogni sua funzionalità (luci, garage, ecc...) è
associata ad uno slot. Tutte le informazioni sono contenute nei relativi slot, in modo tale
che ogni nodo può richiedere le sole informazioni associate all’indirizzo ed al numero di
slot.
Figura 3-5 Struttura della memoria in Souliss
Ad esempio, se si usa “porta garage” sullo slot numero 1:
 nello slot 1 di Typical si trova il codice identificativo della logica;
 in Input1 ci sono i valori in input;
 in output ci sono i valori in output.
Se la logica dovesse agire su parole reali, gli ingressi e le uscite dell’area di memoria
condivisa devono essere collegate ad hardware e I/O seriale/parallelo.
In Souliss ci sono due tipi di metodi:
 hardware e seriali di Input/Output;

 typical logic.
3.2.2 Eclipse Smart Home
Eclipse Smart Home [6] è un framework flessibile che consente alle case e agli edifici di
condividere informazioni su condizioni di alto livello.
I principali obiettivi di Eclipse Smart Home sono riassunti come segue:
 fornire un quadro flessibile per la smart home e per soluzioni domotiche
quotidiane (AAL - Ambient Assisted Living);
 specificare punti di estensione per le possibilità di integrazione e per servizi di
alto livello; estensione e quindi personalizzazione della soluzione che deve essere
il più semplice possibile e ciò richiede interfacce concise e dedicate;
 fornire le implementazioni delle estensioni per i sistemi rilevanti, protocolli o
standard. Le estensioni possono anche essere nella forma di una libreria Java o
di un pacchetto OSGi, in modo tale da poter essere utilizzate
indipendentemente dal resto del progetto;
 fornire sia l’ambiente di sviluppo che gli strumenti per favorire le
implementazioni delle estensioni.
Il progetto Eclipse SmartHome, mostrato in Figura 3-6, è un framework che permette
la creazione di soluzioni intelligenti per la casa che si focalizzano sugli ambienti
eterogenei, ovvero soluzioni che si occupano dell'integrazione di diversi protocolli o
standard.
Lo stack è destinato ad essere utilizzabile su qualsiasi tipo di sistema in grado di eseguire
uno stack OSGi (Open Service Gateway Initiative), sia esso un server multi-core, un
gateway o un Raspberry Pi.
Il progetto si concentra sui seguenti argomenti che riguardano sia i servizi erogati che le
API:

 Data Handling: gestione dei dati e comandi per l’accesso al dispositivo nonché
meccanismi basati su eventi per inviare tali informazioni. È l'argomento più
importante per l'integrazione con altri sistemi, che avviene attraverso i cosiddetti
bindings, un tipo speciale di estensione;
 Rule Engines: un “engine” flessibile che permette di cambiare le regole durante il
runtime; definisce, inoltre, i tipi di estensione che permettono di rompere le
regole in pezzi più piccoli, come trigger, azioni, moduli logici e modelli;
 Declarative User Interfaces: un framework munito di estensioni che permettono
di descrivere il contenuto dell'interfaccia utente in modo dichiarativo. Questo
include widget, icone, tabelle etc.
 Persistence Management: infrastruttura, che permette l'elaborazione automatica
dei dati sulla base di una configurazione semplice e unificata.
Figura 3-6 Eclipse Smart Home

Oltre al framework a runtime e all’implementazione, i progetti Eclipse SmartHome
forniscono anche diversi tipi di strumenti:
 editor di Eclipse per la modifica dei modelli e delle regole di configurazione;
questi forniscono il pieno supporto che si ha da un IDE, come , ad esempio,
l’assistenza nei contenuti e nella sintassi;
 archetipi Maven per creare facilmente gli scheletri delle estensioni;
 demo con altri progetti Eclipse Internet of Things.
3.2.3 FreeDomotic
FreeDomotic, come affermato nella pagina ufficiale del progetto [7], é un software
aperto, flessibile, scalabile e orientato al mashup (ovvero applicazione tale da includere
dinamicamente informazioni o contenuti provenienti da più fonti), in grado di interagire
con i più comuni e utilizzati standard domotici, ma anche con soluzioni fai da te. Tutto
in FreeDomotic (web, social network, frontends) é considerato come un sensore o un
attuatore all’interno di un sistema di automazione.
FreeDomotic può gestire sia piccoli appartamenti che interi edifici come musei, scuole,
campus universitari, per citarne solo alcuni. Per gli installatori e i programmatori é la
soluzione più semplice per creare sistemi di automazione, ambienti intelligenti, servizi di
home automation e innovative applicazioni in grado di interagire con l’ambiente
circostante riducendo drasticamente gli sforzi di sviluppo e il time to market.
L’architettura modulare di FreeDomotic prevede un core (framework) e una serie di
estensioni (plugins).

3.2.3.1 Framework
Il framework di FreeDomotic, la cui interfaccia grafica è mostrata in Figura 3-7, include
delle strutture dati interne per la rappresentazione degli ambienti (topologia, stanze,
connessioni ecc), degli oggetti presenti e del relativo stato (on, off, open, closed etc).
Figura 3-7 Interfaccia grafica di FreeDomotic
Inoltre, rende disponibili tali dati ai client esterni utilizzando formati come XML, JSON,
RESTlet, in modo da poter utilizzare un tipo di logica come “accendi la luce della cucina”
invece di “invia alla porta COM1 la stringa #*A01AON##”. Gli sviluppatori non devono
conoscere i dettagli di basso livello relativi all’hardware, ma possono servirsi di un
qualsiasi linguaggio di programmazione per connettersi al framework e scambiare
semplici messaggi di testo.
FreeDomotic fornisce anche un motore per la generazione di regole (rules) con un
sistema di elaborazione del linguaggio naturale che consente all’utente di scrivere
automazioni in plain english come “if outside is dark turn on livingroom light” (“se fuori é buio
accendi la luce del soggiorno”). Si possono aggiungere, modificare o cancellare automazioni a
runtime attraverso una semplice interfaccia grafica senza scrivere alcuna riga di codice.

3.2.3.2 Plugins
I plugin all’interno di FreeDomotic si dividono principalmente in:
 device plugins: permettono di estendere le funzionalità del framework e possono
essere sviluppati e distribuiti come pacchetti indipendenti attraverso il
marketplace ufficiale [8]. Di solito sono creati per comunicare con specifiche
tipologie di hardware come X10, KNX ecc., ma anche gli stessi client (grafici o
web) sono a tutti gli effetti dei plugin.
 object plugins: questi plugin modellano gli oggetti del mondo reale (come
lampade, porte, tv, sensori, ecc.) con tutte le loro proprietà “istruendo”
opportunamente il framework. Ad esempio, un plugin per una lampada indica al
framework che l’oggetto ha una proprietà (behavior) chiamata powered e
un’altra dimmed che può assumere valori interi tra 0 e 100. Una lampada può
essere accesa (turn on) o spenta (turn off) e la sua luminosità regolata
opportunamente (set brightness). Se la proprietà dimmed assume il valore 0
allora la lampada é spenta (powered=false) altrimenti é accesa (powered=true).
Figura 3-8 Interazioni tra le varie componenti di FreeDomotic

3.2.3.3 Sistema di messaggistica
FreeDomotic adotta un sistema di messaggistica costituito da un MOM (Message
Oriented Middleware) che utilizza il protocollo AMQP (Advanced Message Queuing
Protocol) per la gestione degli eventi provenienti dai sensori ambientali e l’invio di
comandi agli attuatori che, a loro volta, li inoltrano ai dispositivi hardware in grado di
eseguirli.
FreeDomotic é basato interamente su eventi ed ogni cambiamento nell’ambiente o
interazione con il software da parte degli utenti (per esempio, il click sull’interfaccia
grafica) genera un evento. Questi ultimi sono pubblicati sui channels e intercettati dai
triggers, ovvero dei filtro di eventi in ascolto.
A sua volta, ciascun trigger può essere associato ad uno o più comandi definendo cosi
una reaction. Tutto ciò consente al programma di modificare dinamicamente il proprio
comportamento rendendolo estremamente flessibile ed adattabile ad ogni possibile
utilizzo nell’ambito dell’automazione.
In altre parole, un sensore comunica qualsiasi cambiamento nell’ambiente notificando
un evento su uno specifico canale (channel). Se l’evento é consistente con il trigger, uno
o più comandi possono essere inviati all’attuatore in grado di eseguirli. I trigger e i
comandi sono definiti dall’utente utilizzando l’EventEditor grafico e salvati in formato
XML così come le reaction.
Riepilogando quindi il processo, si eseguono i seguenti passi:
 un sensore può essere un dispositivo hardware come un sensore di luminosità;
 un evento é notificato da un sensore, ad esempio “luminosità nella cucina pari al
30%”;
 un trigger può definire espressioni del tipo “if luminosity is less than 50%” (“se
la luminosità é minore del 50%”);

 un comando può essere qualcosa del tipo “turn on the light in the kitchen”
(“accendi la luce nella cucina”);
 un attuatore può essere un modulo X10 o qualsiasi altro dispositivo
controllabile.
Il risultato dell’interazione tra eventi, trigger e comandi é una reaction (automazione),
come mostrato in Figura 3-9. Nel nostro esempio, la reaction é “if luminosity is less
than 50% turn on kitchen light” (“se la luminosità é minore del 50% accendi la luce
nella cucina”).
Figura 3-9 Caratterizzazione di una reaction
3.2.3.4 Il percorso di un messaggio
Il processo di comunicazione, dalla notifica di un evento all’esecuzione di un comando,
prevede la seguente serie di passi:
1. notifica di un evento da parte di plugin o dallo stesso Freedomotic;
2. esecuzione del trigger (filtro di eventi);
3. esecuzione di un comando da parte di un attuatore.
3.2.3.5 Messaggi e regole
Questo meccanismo, apparentemente complicato, permette invece di creare regole per
le automazioni in maniera del tutto semplice e molto vicina al linguaggio naturale. Le
regole, infatti, sono del tipo “if THIS than THAT”, in cui la parte THIS corrisponde ad
un trigger, mentre quella THAT é costituita da uno o più comandi eseguiti in sequenza.

La stessa regola rappresenta un’automazione in grado di associare tra loro trigger e
comandi.
Ciascun trigger é in attesa di eventi che vengono valutati da FreeDomotic, in base alle
condizioni imposte, per decidere se eseguire o meno le automazioni.
Ci sono tre diverse modalità per creare trigger, comandi e automazioni:
 attraverso l’interfaccia desktop;
 via codice;
 collocando un file .xtrg nella specifica cartella; infatti ogni plugin ha la propria
cartella “data” che ospita trigger, comandi e automazioni (da questo momento
indicati come TCA).
I TCA distribuiti con i plugin sono “read only” e si possono utilizzare come template da
cui crearne dei nuovi. Di seguito sono elencati in breve i vari passi da seguire:
 all’avvio, Freedomotic carica tutti i file xml presenti nella cartella
freedomotic/data;
 all’avvio di un plugin, anche i suoi file data (in formato XML) sono caricati e resi
disponibili;
 tutti i dati sono semplici POJO che possono essere creati, letti, aggiornati e
cancellati come le più comuni strutture dati (List, Map, …);
 il desktop front end consente la creazione di oggetti con un semplice form
Swing;
 alla chiusura di Freedomotic tutti i dati sono salvati come file XML nella cartella
freedomotic/data garantendone la persistenza.

3.2.3.6 Channel
Il concetto di channel (canale) é alla base di tutte le operazioni del sistema di
messaggistica in quanto é su ciascuno di essi che vengono pubblicati eventi e comandi.
Gli eventi sono notificati da un plugin sensore. Dal punto di vista di Freedomotic un
sensore é costituito da un dispositivo fisico dotato di una componente software in grado
di interagire con il middleware (framework).
Gli eventi possono essere scambiati utilizzando i formati più comuni (es. POJO, JSON,
XML) e sono distribuiti ai triggers utilizzando una modalità di tipo publish-subscribe,
ovvero ciascun trigger deve sottoscrivere uno specifico canale per ricevere tutti gli eventi
che transitano attraverso di esso.
E’ possibile utilizzare nella sottoscrizione delle wildcards, in modo da includere
automaticamente un ampio insieme di eventi. Per esempio, se un sensore genera eventi
sul canale “app.events.sensors.moving.person.*” riceverà le informazioni relative a tutti i
movimenti delle persone individuate nell’ambiente.
La semantica delle wildcards é la seguente:
 punto (.) per separare i nomi in un percorso (path)
 asterisco (*) per confrontare qualsiasi nome in un percorso (path)
 simbolo maggiore di (>) per confrontare ricorsivamente ogni destinazione a
partire dal nome corrente
Un trigger é un filtro utilizzato per decidere se un evento notificato deve essere
processato o meno. Nel primo caso la reaction (automazione) ad esso associata é
eseguita. Quest’ultima rappresenta un collegamento tra un trigger ed uno o più comandi
eseguiti da un attuatore.
Una reaction consente un controllo del flusso di elaborazione dei comandi, acquisendo i
valori di ritorno della loro esecuzione. Ciascuna lista di comandi é eseguita in parallelo
all’interno di uno specifico thread, utilizzando un pattern request/reply. Si osservi che
trigger e comandi sono componenti riusabili in quanto non definiti all’interno di una
reaction (che si limita a specificare il flusso di esecuzione).

Un comando rappresenta un messaggio in uscita dal middleware e consente
l’indicazione di un destinatario, un canale per l’appunto (es.
app.plugins.protocols.modbus.in). Inoltre sono presenti tutti i parametri eventualmente
necessari per la sua esecuzione. I comandi sono inoltrati utilizzando il pattern
request/reply mentre gli eventi adottano il cosiddetto send-and-forget. L’attuatore é il
terminale di tutto il processo di comunicazione e può eseguire fisicamente il comando
nell’ambiente (es. accendere la luce o aprire una finestra). Inoltre può essere interrogato
alla stregua di un sensore per conoscere il suo stato.
Trigger, reaction e comandi sono definiti all’interno di file XML automaticamente
caricati e salvati dal middleware in modo da garantire la consistenza dei dati.
3.2.4 Tabella comparativa
In conclusione, si confrontano direttamente i framework sopra descritti in base ad
alcuni parametri che sono fondamentali nella scelta dell’ambiente con cui lavorare.
Questa comparazione avviene nella tabella X, nella quale ogni cella è stata riempita con
una descrizione della caratteristica corrente oppure con un segno (“X”) per indicarne la
presenza.
In base a quanto riportato nella Tabella 1, il framework che utilizzeremo per il
proseguimento del lavoro sarà FreeDomotic: esso infatti riesce a interfacciarsi con molti
più dispositivi hardware rispetto agli altri, prevede la presenza e la creazione di plugin e
supporta il multilinguaggio. Per questa serie di motivi, FreeDomotic risulta essere più
completo e più adatto per le esigenze di sviluppo di questo lavoro di tesi.

Souliss FreeDomotic
Eclipse Smart
Home
Api X X X
Interfaccia Utente X
Community attiva X X X
Dispositivi
hardware
supportati
FreekArduino,
Arduino Ethernet
Arduino, Raspberry
Pi, Udoo,
BeagleBone,
ShevaPlug
Arduino,
BeagleBone,
Raspberry Pi
Disponibilità app
client
X X
Protocollo di
comunicazione
RestApi /XML/
P2P
RestApi/ JSON/
HTTP
RestAPI
Simulatore X
Plugin X
Disponibilità
software
Java/Android
Multilinguaggio /
Multipiattaforma
Java/
multipiattaforma
Tabella 1 Tabella comparativa dei framework domotici

3.3 Hardware
L’arrivo sul mercato dei circuiti integrati e dei microcontrollori aprì nuove possibilità di
realizzazioni elettroniche “intelligenti” incrementando l’interesse e la necessità di
competenze informatiche anche da parte dei sistemisti elettronici, che dovettero
occuparsi anche di programmazione per la scrittura del firmware in esecuzione
permanente sull’hardware computazionale inserito nel sistema. Il processo di
avvicinamento è avvenuto anche nell’altro senso con una sempre maggior complessità e
miniaturizzazione dei computer che portò gli informatici ad una analoga necessità di
aggiornamento nei confronti delle architetture hardware su cui programmare. Il punto di
contatto tra le due realtà è sempre più vicino nei sistemi embedded: se da una parte i
microcontrollori si evolvono mettendo a disposizione strumenti per comunicare sempre
più facilmente con i computer, dall’altra compaiono schede PC-embedded dotate di pin
di input/output per interfacciarsi con circuiti esterni.
Al fine di poter interfacciare il sistema software con il sistema domotico, si ha bisogno
proprio di queste board programmabili. Ne esistono diverse in circolazione, le più
diffuse sono Arduino e Raspberry Pi: entrambi sono delle board con installate una serie
di componenti tra cui un’unità logica e una serie di porte, come la USB, o la porta
Ethernet per la Raspberry e per alcune varianti di Arduino. Entrambe le board, inoltre,
sono compatibili con FreeDomotic, ovvero il software di domotica scelto per questo
lavoro di tesi.
3.3.1 Arduino
“Arduino is an open-source electronics prototyping platform based on flexible, easy- to-
use hardware and software. It's intended for artists, designers, hobbyists and anyone
interested in creating interactive objects or environments.” [9].
Arduino è una piattaforma hardware di prototipazione rapida basata su microcontrollore
ATMEL: sostanzialmente è una scheda di input/output di semplice e immediato
utilizzo, grazie anche ad un ambiente di sviluppo dedicato (Arduino IDE) che fa uso di
una libreria Wiring (ambiente di programmazione open-source per impieghi su schede

elettroniche) per semplificare la scrittura di programmi in C e C++. Lo schema di
progetto dell’hardware è open-source. Lo scopo era di rendere disponibile a progettisti,
studenti e hobbisti un dispositivo di sviluppo semplice (che non richiedesse cioè
competenze di elettronica approfondite) e al contempo più economico rispetto ai
sistemi di prototipazione allora presenti sul mercato. Tra tutti ricordiamo Basic Stamp,
diffuso tra gli hobbisti già dagli anni ’90, basato su linguaggio di programmazione Basic.
Arduino, la cui scheda compare in Figura 3-10, è funzionalmente molto simile a Stamp,
ma introduce maggiore semplicità e un costo nettamente inferiore (quasi un quarto del
prezzo a parità di caratteristiche).
Figura 3-10 Arduino Diecimila
Gli schemi hardware di Arduino vengono distribuiti, in modo da poter essere utilizzati
nei termini legali con una licenza Creative Commons Attribution Share-Alike 2.5 e sono
disponibili sul sito ufficiale Arduino. Per alcune versioni della scheda sono disponibili
anche il layout e i files di produzione. Il codice sorgente per l’ambiente di sviluppo
integrato e la libreria residente sono disponibili, e concessi in uso, secondo i termini
legali contenuti nella licenza GPLv2 (GPL è un acronimo e sta per General Public
License ed è una licenza per software libero).
3.3.2 Raspberry Pi
La scheda Raspberry PI è un vero e proprio computer su scheda singola che rende
disponibili direttamente sulla scheda una serie di elementi tra cui dei pin di I/O, una
interfaccia seriale e un’alimentazione a 3,3V e 5V.

Raspberry PI, la cui scheda compare in Figura 3-11, è stato sviluppato nel Regno Unito
dalla Raspberry PI Foundation con l’intento di realizzare un computer a basso costo per
stimolare l’insegnamento dell’informatica nelle scuole, in modo particolare nei Paesi in
via di sviluppo. Il cuore del computer è il SoC Broadcom BCM2835, che include un
processore ARM da 700 MHz, un processore grafico VideoCore IV, un processore di
segnali digitali e 256 Mb di memoria RAM condivisi con la GPU. Non sono previsti
dispositivi dischi fissi o allo stato solido, in quanto il sistema operativo e la memoria di
massa sono allocati su SD Card, che svolge anche il ruolo di unico device di boot.
Figura 3-11 Raspberry Pi
3.4 App mobile
Al fine di permettere un’utilizzabilità migliore di quella offerta da un framework, che il
più delle volte si rende accessibile ed utilizzabile solo da utenti con un livello di
alfabetizzazione informatica medio-alta, vengono incontro le applicazioni per device
mobili [23]. Queste rendono possibile il controllo domotico a tutti gli utenti muniti di
smartphone, aventi sul proprio device una linea dati attiva. Tramite i device mobili è
possibile il controllo remoto della propria abitazione.
Di seguito verranno elencate alcune applicazioni mobile, giudicate tra le migliori dagli
esperti.

3.4.1 Casa Domotica ExControl
L’applicazione Casa Domotica ExControl [10] è stata progettata da alcuni ragazzi
spagnoli e permette di controllare a distanza qualsiasi dispositivo; inoltre da la possibilità
di controllare una rete locale che non possiede un indirizzo IP fisso. La Figura 3-12
mostra un esempio di interfaccia grafica.
Figura 3-12 Interfaccia grafica di Casa Domotica ExControl
Sul computer di casa deve essere installato il programma ExControlConfiguration, il
quale si interfaccia direttamente con i dispositivi Arduino presenti in casa e quindi
presenti in rete; questi poi andranno a comunicare con l’applicazione Android la quale
può essere utilizzato solamente come visualizzatore di notifiche oppure proprio come
controllore, cioè per settare orari, scenari e circuiti da gestire.
Questa applicazione, tra le funzionalità che mette a disposizione, permette ad esempio:
 controllo di potenza erogata nelle zone di illuminazione;
 controllo del riscaldamento e le relative temperature nominali;

 controllo delle zone di irrigazione automatica;
 controllo sugli infissi e porte;
 programmazione scene e ambienti;
 segnalazione di allarmi tramite terminale Android;
 controllo vocale;
 controllo condizionatore.
3.4.2 Souliss App
SoulissApp [11], la cui interfaccia è mostrata in Figura 3-13, è il client del progetto
Souliss, un software domotico completamente gratuito che permette di controllare la
propria casa dallo smartphone.
E' necessario disporre di un'installazione Souliss per usare questa applicazione, costruita
con hardware Arduino compatibile. Souliss supporta l'automazione dell'illuminazione,
riscaldamento, antifurto, condizionatore, finestre e molto altro.
Questo framework di domotica è probabilmente il più economico. Tutto il software è
gratuito e open-source; si può costruire il proprio sistema di automazione con poche
decine di euro. Bisogna comunque tener presente che è necessario un po' di tempo per
capire come configurare e mettere in funzione il sistema di home automation.
Le feature più importanti di questa applicazioni sono:
 rilevamento automatico dei dispositivi controllati;
 scenari personalizzabili per raggruppare i comandi;
 programmi personalizzabili (temporali, geo-referenziati o basati su sensori);
 database locale per la raccolta di dati storici;

 servizio in background per la raccolta di informazioni;
 implementazione UDP per risparmiare connettività e batteria;
 supporto ed ottimizzazioni su tablet;
 gruppi di dispositivi personalizzabili.
Figura 3-13 Interfaccia grafica di Souliss App
3.4.3 Winkhel Building Automation
Winkhel Building Automation [12] è un'applicazione che consente ad un utente di
controllare gli impianti di automazione (abitazioni, uffici, alberghi, etc.). L'applicazione
gratuita è stata creata esclusivamente per scopi dimostrativi, limitando gli strumenti
disponibili e simulando le sue prestazioni in abitazioni a più piani.
L'applicazione per comunicare utilizza il protocollo TCP MODBUS, basato su
tecnologie di installazione Winkhel: una serie di dispositivi che ereditano caratteristiche
Arduino e quindi compatibili con esso. Questi dispositivi consentono di monitorare e
agire su diversi elementi di domotica, come ad esempio: tende, termostati, porte,
finestre, illuminazione LED RGB, valvole, sistemi di irrigazione, luci.

L'applicazione dispone di meccanismi di autenticazione per impedirne un suo uso
improprio. Una volta che l'utente si è autenticato accede al menu principale dove si
mostrano diverse opzioni: configurazione, elementi di controllo e gruppi di controllo.
Gli elementi di automazione sono classificati per livelli e tipi ed è possibile modificare il
nome di un oggetto, controllare lo stato e agire di conseguenza. Tutto ciò è trasparente.
Dal menu impostazioni è possibile modificare la password, impostare il tempo di
automazione del sistema (per garantire il corretto funzionamento dei programmi
temporizzati), impostare e/o modificare i parametri di connessione remota e, una volta
stabilito questo, si può procedere anche alla sincronizzazione con il sistema. In questo
modo è possibile creare un insieme di automazioni anticipatamente alla reale
installazione.
Figura 3-14 Interfaccia grafica di Winkhel Build Automation
Tra le caratteristiche principali del sistema reale l'utente troverà:
 meccanismi di autenticazione;
 utilizzo di protocolli robusti e affidabili (MODBUS TCP);
 supporto hardware Arduino;

 comunicazione tramite WiFi, 3G, GPRS etc.;
 interfaccia semplice, intuitiva e trasparente all’utente, come si può notare dalla
Figura 3-14;
 aggiornamento automatico e personalizzato;
 soluzione di domotica facile da implementare;
 domotica all'avanguardia della tecnologia.
3.4.4 Menu Domotico
Menu Domotico [13] è l’applicazione che consente di gestire in modo rapido ed
intuitivo l’impianto di sicurezza e automazione della propria casa.
Con Menu Domotico, utilizzando dei semplici comandi, tutte le principali funzioni dell’
abitazione sono a portata di mano. Dall’antifurto alla termoregolazione, dal controllo
delle luci a quello delle tapparelle, bastano pochi clic per ottenere l’effetto desiderato. La
funzionalità “Richiesta Stato” permette inoltre di conoscere in qualunque momento lo
stato di attivazione dell’antifurto, le temperature rilevate e le utenze elettriche attive.
L’applicazione, la cui interfaccia grafica è mostrata in Errore. L'origine riferimento
non è stata trovata., consente in particolare di:
 attivare l’antifurto in modo totale o parziale;
 gestire in modo indipendente 4 zone climatiche attraverso il sistema Mylos
Home Automation;
 gestire più impianti tramite specifica rubrica integrabile con quella generale del
telefono.
L’applicazione è completamente configurabile: è possibile selezionare tra i diversi
comandi solo quelli di uso corrente denominandoli nel modo desiderato, pre-impostare
una tantum il codice personale (PIN) e il numero di telefono della centrale.

Figura 3-15 Interfaccia grafica di Menu Domotico
3.5 Conclusioni
In conclusione, il mercato offre delle buone tecnologie per rendere più accessibili i
dispositivi elettronici presenti in una abitazione, ma ci sono degli evidenti limiti.
Per quanto riguarda gli strumenti di aiuto domotico specifici per il target di utenti a cui è
rivolto questo progetto, ci sono delle grosse limitazioni, come ad esempio la dipendenza
dall’hardware (Sicare Pilot) oppure l’incompletezza dell’insieme dei dispositivi
controllabili (Light Detector).
Il mercato offre molti framework e applicazioni mobile rivolte alla domotica, ma
ognuno di essi, senza l’aiuto di un opportuno supporto, non è in grado di offrire un
servizio completo e accessibile a persone che hanno difficoltà visive e/o uditive.
Il sistema che si vuole progettare in questo lavoro di tesi, quindi, mira a superare gli
evidenti limiti di queste tecnologie attualmente offerte dai mercati, sfruttando le
potenzialità di un framework (FreeDomotic) che è risultato il migliore dopo un’attenta
analisi (Tabella 1).

53 Sistema mobile di supporto ai non vedenti
CAPITOLO 4
4 Sistema mobile di supporto ai non
vedenti
In questo capitolo verrà presentata una descrizione dettagliata del processo di analisi che
ha portato alla realizzazione dell’applicazione di SpokenHouse. Verrà descritto il
processo di raccolta dei requisiti, una panoramica su alcuni casi d’uso più significativi,
l’architettura del sistema in cui si colloca l’applicazione. Infine viene fatta una
panoramica sulle tecnologie che sono state utilizzate durante l’implementazione.
4.1 Scopo dell’applicazione
Sulla base di quanto detto nei capitoli 2 e 3 e sulla base delle ricerche effettuate nel
lavoro svolto nella tesi di Daniela Guardabascio, si è giunti alla conclusione che il digital
divide nell’ambito domotico è ancora molto accentuato.
Il sistema denominato SpokenHouse, quindi, nasce con l’idea di sviluppare tutto quanto
concerne l’interfacciamento del target utente con il sistema domotico; a fronte di ciò, il
sistema prevede l’implementazione di un’applicazione multi-piattaforma mobile
(Android, Windows Phone, iOs, ecc…), in grado di interfacciarsi con il framework
domotico selezionato (in base ai parametri espressi nella Tabella 1), ovvero
FreeDomotic, che si farà carico di instradare le comunicazioni tra l’applicazione e il
sistema domotico.
L’applicazione di SpokenHouse deve essere munita di un’interfaccia funzionale
(facilmente fruibile da persone non vedenti, ipovedenti e/o non udenti) grazie alla quale

è possibile ottenere le informazioni d’interesse, gestire gli apparecchi elettronici presenti
nell’abitazione e garantire sicurezza, consistenza e persistenza dei dati dell’utente.
4.1.1 Analisi degli utenti
Le tipologie di utenti a cui il sistema è rivolto sono i "disabili visivi e/o uditivi".
I "disabili visivi" comprendono sia i non vedenti o i ciechi assoluti, che gli ipovedenti. I
primi non sono in grado di cogliere attraverso la vista nessuna informazione significativa
in ordine all'ambiente esterno, i secondi, invece, possono avvalersi del loro residuo
visivo, anche se non con molte limitazioni e trovandosi in situazioni percettive
estremamente differenziate, sia sotto il profilo dell'acuità che sotto quello dell'ampiezza
del campo visivo. La persona ipovedente non è semplicemente un individuo che ha una
riduzione delle capacità visive, a volte manifesta difficoltà notevoli nella fissazione, nei
movimenti oculari, nell’esplorazione visiva, nell’ampiezza del campo di fissazione, nella
sensibilità al contrasto, nella percezione del colore.
I “disabili uditivi” comprendono sia i non udenti che gli ipoacusici. I primi hanno una
completa disfunzione dell’intero apparato uditivo, mentre i secondi hanno un
indebolimento dell'apparato uditivo dovuto a un danno o alla degenerazione di uno o
più dei suoi componenti.
L’interfaccia dell'applicazione è stata realizzata in modo tale da ottenere un prodotto
finale semplice e facilmente utilizzabile. A causa della vasta gamma della sensibilità visiva
e uditiva individuabile tra coloro che sono non vedenti o non udenti, un'interfaccia ben
progettata dovrebbe supporre che l'utente finale potrebbe avere difficoltà visive ed
uditive ed allo stesso tempo dovrebbe garantire l'utilizzo della stessa anche ad una
persona con limitazioni di disabilità di almeno uno dei due sensi in questione.
Sulla base degli studi fatti da Informatici senza Frontiere nel progetto denominato
Strillone, l’idea di base utilizzata per la creazione dell’interfaccia è stata quella di dividere
lo schermo in quattro aree uguali, corrispondenti agli angoli del dispositivo, il quale è
stato tagliato virtualmente in due (sia verticalmente che orizzontalmente).

Figura 4-1 Interfaccia grafica di Strillone
Come in Strillone, mostrata in Figura 4-1, anche in SpokenHouse gli utenti possono
esplorare le varie aree dell'interfaccia semplicemente spostando il dito sullo schermo e
cliccando su un'area specifica per confermare una specifica opzione.
4.1.2 Accessibilità
L’interazione con i dispositivi mobili non è univoca, ma può variare secondo il profilo
d’utente, il dispositivo o il contesto nel quale si opera. Particolare importanza assume
quest'aspetto per le persone con limitazioni di disabilità. Essi devono interagire con il
proprio dispositivo mobile usando modalità alternative che si adattino alle loro esigenze.
Questi utenti possono avere limitazioni visive, uditive, fisiche o legate all'età, che
impediscono loro l’accesso quando questo è fornito solo in modalità predefinite quali
quella grafica.
Ogni sistema operativo dispone di alcune funzionalità integrate, per garantire
l'accessibilità che permettono di personalizzare il proprio dispositivo e avere funzioni
che rendono più semplice vedere, ascoltare e usare al meglio il dispositivo.
Le funzionalità rivolte soprattutto ad una utenza ipovedente sono:

 diverse dimensioni del testo;
 temi ad alto contrasto, modificando lo sfondo e le scritte, facendoli diventare
rispettivamente nero e bianche;
 ingrandimento dello schermo, il quale consente di ingrandire la porzione dello
schermo in cui si trova il cursore.
Un’altra funzionalità per l'accessibilità molto importante è lo screen reader: si tratta di
un software che permette di ascoltare (invece di leggere) un contenuto presente a video.
Infatti, scorrendo il dito sullo schermo, lo screen reader legge ad alta voce i contenuti
selezionati o una loro descrizione. Inoltre, le notifiche come sveglie, eventi del
calendario e avvisi sull'esaurimento della batteria saranno lette ad alta voce.
A seconda del sistema operativo dello smartphone, viene messo a disposizione uno
screen reader diverso:
 per i dispositivi Android, TalkBack che aggiunge feedback vocali, sonori con
vibrazioni al dispositivo;
 per i dispositivi Apple, lo screen reader Voice Over con cui è possibile
controllare il dispositivo iOS con alcune gesture oltre al normale funzionamento
di lettura dello schermo;
 per i dispositivi Windows Phone, è disponibile solo per i dispositivi più
aggiornati ed è limitato alla sola lingua inglese (Stati Uniti).
4.2 Analisi dei requisiti
L’applicazione di SpokenHouse deve soddisfare determinati requisiti, funzionali e non;
essi sono esplicitati attraverso gli scenari d’utilizzo.
Essi sono elencati di seguito, con le relative operazioni rese disponibili dall’applicazione
all’utente:

 configurazione dell’applicazione;
 accensione/spegnimento della luce in uno degli ambienti domestici;
 apertura/chiusura della porta in uno dei locali domestici;
 accensione/spegnimento delle luci nella zona notte/giorno della casa;
 attivazione sul device della vibrazione, utilizzata per codificare eventuali
notifiche audio in linguaggio Morse;
 accensione/spegnimento e regolazione del condizionatore;
 impostazione della temperatura predefinita del termostato;
 attivazione/disattivazione dei dispositivi di riscaldamento nell’ambiente
domestico;
 apertura/chiusura della porta del garage;
 apertura/chiusura del cancello automatico;
 controllo elettrodomestici (es: lavastoviglie, lavatrice, forno, etc.);
 controllo dell’allarme;
 controllo real time delle videocamere di sorveglianza;
 apertura/chiusura cancello;
 controllo delle tapparelle;
 scelta tema dell’interfaccia;
 attivazione/disattivazione del Text To Speech in base alla
attivazione/disattivazione della modalità Morse;
 aggiunta di azioni programmate (es. all’apertura del cancello segue: accensione
luci garage, accensione luci ingresso, apertura porta garage, accensione
dispositivi riscaldamento...);
 modifica grandezza dei caratteri;
 attivazione/disattivazione tutorial di navigazione;
 verifica dispositivi accesi all’interno dell’ambiente domestico.
La Figura 4-2 mostra i suddetti requisiti e le loro dipendenze.

Figura 4-2 Diagramma dei casi d'uso
4.2.1 Attori del sistema
A monte della definizione dei casi d’uso, di seguito saranno individuati, in modo
opportuno, tutti gli attori del sistema.
Gli attori sono i soggetti esterni al sistema che interagiscono con esso, tramite scambio
di messaggi (richieste, comunicazioni, risposte). In altre parole, gli attori modellano i
ruoli che persone, sistemi software e device possono assumere nel momento in cui
prendono parte ad un determinato caso d’uso. Il sistema, invece, è l’entità i cui utilizzi
vengono descritti dall’insieme dei casi d’uso. Più precisamente, un insieme completo di
casi d’uso descrive in modo completo gli utilizzi del sistema dall’esterno, ossia dal punto
di vista degli attori che interagiscono con esso, senza rivelare la struttura interna del
sistema.
La Tabella 2 descrive i vari attori del sistema.

Nome attore Descrizione
User Non udente, non vedente, ipovedente. Coloro che
intendono controllare la loro abitazione.
Installatore Persona esperta, addetta all’installazione e alla
configurazione dell’ambiente domotico, del framework e
dell’applicazione.
FreeDomotic Framework open source distribuito per l’automazione di
edifici. Esso è costituito da una serie di moduli cross-
language a basso accoppiamento che comunicano
attraverso un middleware message oriented,
scambiandosi messaggi.
Tabella 2 Attori del sistema
4.2.2 Casi d’uso
Per capire al meglio come sviluppare e comprendere i requisiti del progetto, quest’ultimi
sono stati analizzati attraverso le descrizioni dei casi d’uso. Il caso d'uso in informatica è
una tecnica usata nei processi di ingegneria del software per effettuare in maniera
esaustiva e non ambigua la raccolta dei requisiti al fine di produrre software di qualità.
Vengono utilizzati per l’individuazione e la registrazione dei requisiti funzionali
descrivendo come un sistema possa essere utilizzato per consentire agli utenti di
raggiungere i loro obiettivi. In questo paragrafo vengono descritti alcuni dei casi d’uso
più rappresentativi tra quelli elencati nel paragrafo precedente, per la realizzazione
dell’applicazione; in aggiunta a questi, inoltre, sono riportati i sequence diagram, i quali
andranno a esplicitare le interazioni e la comunicazione tra i vari oggetti del sistema,
seguendo un ordine temporale ben preciso.
La specifica di un caso d’uso dovrebbe includere almeno un nome, gli attori principali e
secondari, un obiettivo (il motivo per il quale gli attori principali avviano il caso d’uso),
la precondizione nella quale è eseguibile, la sequenza delle azioni svolte dagli attori e dal
sistema (considerato come una scatola nera, quindi senza entrare nel dettaglio del suo
funzionamento interno), le eventuali eccezioni e come esse devono essere gestite.

1. Configurazione dell’applicazione
Descrizione L’installatore, al primo avvio dell’applicazione, fornisce
una serie di informazioni necessarie al fine di garantire
la corretta comunicazione con il FreeDomotic.
Attori Installatore, utente
Input Dati dell’utente, indirizzo IP, porta
Precondizione L’utente deve avere un dispositivo smartphone con
qualsiasi sistema operativo che utilizzerà nel ruolo di
dispositivo controllante. Un installatore deve aver
configurato l’ambiente domotico al fine di permettere
l’interfacciamento con il device.
Output Notifica di connessione avvenuta con successo sul
dispositivo controllante, tramite notifica audio (Text To
Speech).
Postcondizione L’utente può controllare l’ambiente domotico.
Scenario
Principale
1. L’installatore, una volta scaricato il servizio dalla rete,
avvia installazione.
2. Il sistema, all’avvio dell’applicazione, richiede i dati ai
fini della comunicazione.
3. Il primo parametro richiesto, tramite messaggio
vocale e tramite alert sul device, è l’indirizzo IP
necessario alla connessione tra device e FreeDomotic.
4. L’installatore inserisce l’indirizzo IP, e conferma per
mezzo della pressione del tasto “ok”.
5. Il sistema, riconosciuto il parametro inserito come
corretto, richiede all’installatore, tramite notifica
vocale e alert sul device, il secondo parametro, ovvero
la porta su cui è in esecuzione il framework
FreeDomotic (necessario per la connessione tra device
e FreeDomotic).
6. L’installatore inserisce la porta, il cui valore numerico
deve prevedere al più di 4 cifre, e conferma per mezzo
della pressione sul tasto “ok”.

vocale e alert sul device, il terzo parametro, ovvero
l’username, necessario al fine di autentificare l’utente
nel framework di FreeDomotic.
8. L’installatore inserisce l’username e conferma per
mezzo della pressione sul tasto “ok”.
vocale e alert sul device, il quarto parametro, ovvero la
password, necessaria al fine di autentificare l’utente nel
framework FreeDomotic.
10. L’installatore inserisce la password e conferma per
11. A valle del corretto inserimento dei dati inseriti, il
sistema permette la comunicazione tra device e
FreeDomotic, comunicando, tramite notifica vocale, la
corretta configurazione dell’applicazione;
Scenario
Alternativo
1. L’installatore, una volta scaricato il servizio dalla rete,
avvia installazione.
2. Il sistema, all’avvio dell’applicazione, richiede i dati ai
fini della comunicazione.
3. Il primo parametro richiesto, tramite messaggio
vocale e tramite alert sul device, è l’indirizzo IP,
necessario la connessione tra device e FreeDomotic.
4. L’installatore inserisce l’indirizzo IP, e conferma per
vocale e alert sul device, il secondo parametro, ovvero
la porta su cui è in esecuzione il framework
FreeDomotic (necessario per la connessione tra device
e FreeDomotic).
6. L’installatore inserisce la porta che deve avere al più
di 4 cifre, e conferma per mezzo della pressione sul
tasto “ok”.
7. il sistema emette una notifica di errore nonché una
richiesta di nuovo inserimento del valore della “porta”,
in quanto l’utente ha inserito un valore con corretto;
8. L’installatore inserisce nuovamente il valore della
porta e conferma per mezzo della pressione sul tasto
“ok”.

vocale e alert sul device, il terzo parametro, ovvero
l’username, necessario al fine di autentificare l’utente
nel framework di FreeDomotic.
10. L’installatore inserisce l’username e conferma per
vocale e alert sul device, il quarto parametro, ovvero la
password, necessaria al fine di autentificare l’utente nel
framework di FreeDomotic.
12. L’installatore inserisce la password e conferma per
13. A valle del corretto inserimento dei dati inseriti, il
sistema permette la comunicazione tra device e
FreeDomotic, comunicando, tramite notifica vocale, la
corretta configurazione dell’applicazione;
Tabella 3 Caso d'uso 1: configurazione applicazione
Figura 4-3 Sequence diagram del caso d’uso 1: configurazione applicazione

SpokenHouse: applicazione mobile cross-platform di supporto ai non vedenti per il controllo domotico. Interfacciamento con un framework domotico

SpokenHouse: applicazione mobile cross-platform di supporto ai non vedenti per il controllo domotico. Interfacciamento con un framework domotico

Recommandé

Recommandé

Contenu connexe

Plus de freedomotic

Plus de freedomotic (14)

SpokenHouse: applicazione mobile cross-platform di supporto ai non vedenti per il controllo domotico. Interfacciamento con un framework domotico