wattsup: monitoraggio energetico su Android

Transcript

1 POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Tesi di Laurea Specialistica wattsup: monitoraggio energetico su Android Relatori: Prof. Fulvio Corno Dott. Luigi De Russis Candidato: Daniele Antoci Matr Dicembre 2012

2

3 Ringraziamenti Desidero innanzitutto ringraziare i miei relatori, il Prof. Fulvio Corno e il Dott. Luigi De Russis, per la disponibilità dimostratami e per avermi accompagnato durante il lavoro di tesi con preziosi ed efficaci consigli. Il ringraziamento più grande va a tutta la mia famiglia, per avermi sempre incoraggiato e sostenuto in questo lungo percorso universitario. Grazie ai miei genitori, punto di riferimento e maestri di vita. Grazie a Dario, fratello maggiore come pochi, sempre presente nei momenti più difficili, ma soprattutto in quelli più belli. Infine non posso dimenticare di ringraziare gli amici per aver condiviso sia momenti di serietà e studio, che momenti di divertimento. Grazie a quelli nuovi, che quest esperienza da studente fuori sede ha deciso di regalarmi, e a quelli di sempre, per essere costantemente presenti nonostante la distanza e il trascorrere degli anni. i

4 Indice 1 Introduzione Contesto generale La Domotica e la Building Automation Differenze tra impianti tradizionali ed impianti domotici Vantaggi e campi di applicazione Protocolli di comunicazione standard vs. protocolli proprietari Struttura della tesi Obiettivi 8 3 Tecnologia utilizzata Introduzione Ambiente domotico utilizzato Dog DogOnt Android Risorse per gli sviluppatori Android SDK XML-RPC Design Introduzione Scelte progettuali e funzionalità Le stanze Informazioni sui device più energivori Impostazioni Gestione della colorazione Visualizzazione allarme Realizzazione dell interfaccia utente La disposizione delle stanze Visualizzazione delle stanze Elementi grafici Interazione con Dog Organizzazione e riusabilità del codice Testing Svolgimento del test ii

5 INDICE 6 Risultati Ottenuti Analisi qualitativa Valutazione rispetto agli obiettivi preposti Conclusioni e sviluppi futuri Possibili sviluppi futuri I Appendici 72 A Test Plan 73 B Commenti utente 80 Elenco delle figure 82 Elenco delle tabelle 84 Bibliografia 85 iii

6 1 Introduzione 1.1 Contesto generale Negli ultimi anni, avvenimenti, come i cambiamenti climatici, l esaurimento delle fonti energetiche e delle risorse naturali, rendono l impiego intelligente ed efficace dell energia un tema di rilevante importanza e di notevole impatto sociale. Secondo alcuni studi sul consumo energetico, infatti, il settore privato incide per circa il 40% sul consumo finale di energia, valore che può raggiungere anche più del 70% se consideriamo esclusivamente il consumo elettrico nei locali residenziali e commerciali, motivato dalla continua maggiore richiesta di benessere e comfort da parte dell utente finale, come ad esempio il crescente utilizzo e la larga diffusione della climatizzazione. La situazione politica mondiale, la crisi economica e la diffusione di stili di vita sempre più green ed ecosostenibili, nonchè l esaurimento delle risorse, stanno fortunatamente spingendo verso un cambiamento globale, orientato sempre più allo sviluppo e alla diffusione di energie rinnovabili. Tra queste primeggiano nuove fonti energetiche quali il fotovoltaico, il geotermico, l eolico e l idroelettrico. Ma, oltre all utilizzo di energie rinnovabili, si stanno diffondendo anche interventi atti a incrementare le prestazioni energetiche sia degli edifici di nuova costruzione sia di quelli già esistenti, tramite opportuni progetti di ristrutturazione, utilizzando, ad esempio, materiali isolanti ad altissime prestazioni o installando pannelli solari sui tetti delle abitazioni. Nell immaginario collettivo vi è l idea, non del tutto corretta, che l attuazione di questo tipo di accorgimenti sia sufficiente a rendere il proprio ambiente domestico un luogo ad alto risparmio energetico e che non sia necessario fare altro per migliorarne l efficienza. Questo infatti è vero solo in parte, perchè per quanto possa essere necessario rendere la propria casa efficiente e ottimizzata dal punto di vista dell isolamento termico, o parzialmente autosufficiente energeticamente, bisogna an- 1

7 1.2. LA DOMOTICA E LA BUILDING AUTOMATION che gestire in modo opportuno gli impianti più energivori della casa, ovvero quello termico e quello elettrico. In questo contesto entra in gioco la domotica, come strumento capace di aiutarci a gestire e comprendere al meglio ciò che avviene in tempo reale nella nostra abitazione, e ad amministrarne, ad esempio, le potenzialità di risparmio energetico offerte dai vari dispositivi dislocati negli ambienti della casa. 1.2 La Domotica e la Building Automation La nascita dei sistemi di automazione per la casa e gli edifici è da ricondurre alla seconda metà degli anni 80 quando, sulla base di esperienze provenienti dall automazione di fabbrica, sono state sviluppate e rese fruibili alcune innovative tecnologie del settore informatico, elettronico e delle telecomunicazioni, con l obiettivo di rendere più intelligenti, integrati e coordinati gli impianti tecnici di un edificio (elettrico, condizionamento, antifurto, ecc.). Nei decenni successivi le stesse tecnologie sono state ulteriormente sviluppate per essere impiegate in edifici residenziali, ed è proprio in questo periodo che va affermandosi il termine domotica. Domotica deriva dal termine francese Domotique che unisce la radice latina di Domus (casa) al termine informatica, e riassume così esattamente il connubio fra i due ambiti: con domotica, infatti, si indica sommariamente l automazione tecnologica della casa, con sistemi informatici, elettronici e robotici. Anche se il termine casa è inteso in senso lato, in quanto ogni tipologia abitativa e non abitativa può essere domotizzata, anche gli uffici, i magazzini, gli alberghi, i centri congressi, e via discorrendo. Anzi, gli interi edifici possono essere predisposti per la domotica, nel qual caso si parla di Building Automation, mentre per il ramo dedicato alle singole unità (abitative e non) ci si riferisce alla Home Automation. In sintesi, è possibile considerare la domotica come quell insieme di tecnologie, di sistemi e di servizi atti a rendere intelligente ed integrato il funzionamento dei differenti tipi di impianti presenti in un abitazione Differenze tra impianti tradizionali ed impianti domotici Una volta chiarito per grandi linee cosa si intende, e di cosa si occupa la domotica, è bene precisare quale sia la differenza sostanziale tra un impian- 2

8 1.2. LA DOMOTICA E LA BUILDING AUTOMATION to tradizionale e uno domotico. Un impianto domotico differisce da uno tradizionale sia in base a come l impianto stesso viene comandato da parte dell utente, sia nella possibilità di integrazione completa degli impianti tecnici presenti nell ambiente da controllare, che come abbiamo già detto possono essere svariati: illuminazione, condizionamento, segnalazione d emergenza, movimentazione tapparelle e tende, ecc. Il coordinamento, in un impianto tradizionale, è costituito semplicemente dal collegamento fisico che è utilizzato per realizzare il circuito di comando: in altri termini, un interruttore deve il suo nome proprio alla funzione di interruzione del circuito che alimenta l utenza. In un impianto domotico, invece, il circuito di comando è fisicamente separato dal circuito di alimentazione: è costituito, quindi, da una rete di segnale con cui i dispositivi di comando e di attuazione, dotati di una propria elettronica di elaborazione e comunicazione, sono in grado di scambiare informazioni sotto forma di messaggi codificati in forma digitale, mentre il circuito di alimentazione collega le sole utenze che necessitano della tensione di rete (230 Volt) per il loro funzionamento. A differenza di un impianto tradizionale in cui le singole installazioni sono indipendenti e non possono comunicare tra loro, un sistema domotico, pertanto, consente la totale integrazione di tutti gli impianti presenti in un edificio, così come illustrato in Figura 1.1 Figura 1.1: Confronto tra impianto elettrico tradizionale e impianto domotico 3

9 1.2. LA DOMOTICA E LA BUILDING AUTOMATION Vantaggi e campi di applicazione L utilizzo di sistemi domotici permette di ottenere dei benefici per l utente finale che è difficile, se non impossibile, raggiungere con un impianto tradizionale, in primo luogo l incremento del comfort e della qualità della vita all interno dell ambiente automatizzato. Il classico interruttore di casa, ad esempio, che normalmente è dedicato all accensione o spegnimento delle luci può essere impiegato come comando dell impianto di irrigazione o per l attivazione dell antifurto. Il concetto chiave è quello di scenario : l esecuzione contemporanea e coordinata, tramite un solo comando, di molteplici funzioni che coinvolgono parti di impianti diversi. È possibile, infatti, far dialogare l impianto antifurto con l impianto di videosorveglianza e con tutti gli altri impianti della casa, e di integrare i dispositivi ad impatto visivo (come le telecamere di videosorveglianza). Le funzioni domotiche di un edificio possono essere comandate anche da remoto mediante l utilizzo di un collegamento Internet o di telefoni cellulari, così come eventuali allarmi o stati di allerta di un impianto (fughe di gas, intrusione di ladri in appartamento, ecc. ) possono essere inviati via o tramite SMS. Infine è bene menzionare l ausilio sociale che la domotica può offrire, potendo venire incontro alle esigenze delle persone con limitazioni motorie o con particolari esigenze di fruibilità dell impianto elettrico, come i bambini e gli anziani. Un esempio potrebbe essere l impiego di comandi vocali integrati che permettano l utilizzo dell impianto domotico senza agire fisicamente sui controlli Protocolli di comunicazione standard vs. protocolli proprietari Per poter comprendere quale sia la struttura di un impianto domotico può essere utile rifarsi ai principi costruttivi delle reti di calcolatori: un impianto domotico è in effetti assimilabile a una rete di comunicazione in cui i dispositivi sono collegati tra loro attraverso un mezzo trasmissivo. Per poter comunicare, i dispositivi devono poter parlare lo stesso linguaggio, ossia devono avere lo stesso protocollo di comunicazione. È possibile distinguere due tipologie di standard di comunicazione: 1. protocolli proprietari; 2. protocolli standard. I protocolli proprietari sono sviluppati da un singolo costruttore la cui tecnologia è soggetta a brevetti. Per questa tipologia di protocolli la compatibilità 4

10 1.2. LA DOMOTICA E LA BUILDING AUTOMATION con sistemi di altre aziende è parziale o inesistente, nonostante le funzionalità fornite potrebbero anche risultare superiori. I protocolli standard, invece, presuppongono che le specifiche siano pubbliche e accessibili a chiunque voglia costruire o integrare dispositivi comunicanti con il protocollo medesimo. In questo caso, prodotti di marche diverse, se condividono lo stesso protocollo di comunicazione, possono perfettamente funzionare tra loro nel medesimo impianto. Pertanto, per la realizzazione di un sistema domotico perfettamente integrato sarebbe preferibile orientarsi verso tecnologie standard. È tuttavia doveroso chiarire che realizzare un impianto domotico utilizzando solo dispositivi dello stesso produttore, o che si appoggino tutti sullo stesso standard, può rappresentare un limite sia per l impianto stesso che per chi ne usufruisce. Potrebbe infatti verificarsi un problema nel momento in cui avviene un guasto e non siano più disponibili ricambi in commercio, o semplicemente quando un nuovo componente di controllo è fornito da un solo produttore che utilizza un protocollo diverso da quello utilizzato nel resto dell impianto domotico. Figura 1.2: Esempio funzionalità gateway domotico 5

11 1.3. STRUTTURA DELLA TESI Si dovrebbero a tal punto sostituire tutti gli altri dispositivi, comportando un notevole disagio economico, oppure far convivere due sistemi diversi che lavorino in parallelo, o altresì rinunciare all installazione di quel dispositivo. In realtà l utilizzo di un gateway domotico, mostrato in figura 1.2, proprio come quello impiegato durante la tesi riesce a risolvere il problema di comunicazione fra protocolli differenti, portando la comunicazione fra i vari dispositivi ad un livello di astrazione più elevato e permettendo quindi di utilizzare protocolli non standard, o di fare un upgrade dell impianto introducendo nuove tecnologie come ad esempio delle prese wireless. Il gateway permette infatti di gestire a basso livello, per mezzo di specifici driver, tutte le apparecchiature ad esso collegato, occupandosi, tra le altre cose, della traduzione dei messaggi da e verso i dispositivi, che potranno pertanto utilizzare protocolli di comunicazione differenti. Si potranno quindi installare sullo stesso impianto domotico dispositivi di varie marche, purchè sia possibile fornire il driver di connessione con il gateway. 1.3 Struttura della tesi In questo primo capitolo, si è cercato di introdurre il contesto e fornire alcuni strumenti base per comprendere il punto da cui è partita la realizzazione dell applicazione che è il prodotto finale di questo progetto. Nei prossimi tre capitoli, la tesi è organizzata per presentare gli obiettivi e approfondire alcuni aspetti, seppur di background, necessari a comprendere appieno il come e il perchè si è realizzata l interfaccia utente; nei capitoli seguenti, invece, si mostreranno le fasi di progettazione e di implementazione del progetto e si presenteranno i risultati ottenuti. In dettaglio: nel capitolo DUE Obiettivi si illustrerà uno studio sui prodotti commerciali esistenti relativi alla visualizzazione e il monitoraggio energetico per mezzo di display informativi dislocati in opportuni punti dell abitazione. Questo, insieme ai risultati di una ricerca esistente sulle preferenze dell utente in merito all utilizzo di tali dispositivi, aiuteranno a tracciare dei requisiti minimi per la realizzazione di un interfaccia utente semplice e intuitiva da utilizzare per l applicazione da sviluppare. nel capitolo TRE Tecnologia utilizzata, verrà descritto il gateway domotico proposto dal Politecnico di Torino, cioè Dog, analizzando brevemente l ontologia che racchiude lo schema della casa e i suoi dispositivi. 6

12 1.3. STRUTTURA DELLA TESI Inoltre si presenterà il sistema operativo per dispositivi mobili Android e l ambiente di sviluppo Eclipse, riassumendone, per quanto possibile, le principali caratteristiche. nel capitolo QUATTRO Design, si presenteranno le varie scelte progettuali fatte, si parlerà di come è stata realizzata l interfaccia utente, e di come questa interagisce con Dog. Si discuterà anche dell organizzazione del codice e del suo possibile riutilizzo. nel capitolo CINQUE Risultati ottenuti, si presenterà qualche risultato qualitativo e quantitativo derivato dall utilizzo dell interfaccia, soffermandosi in particolare ad analizzare l effettivo miglioramento ottenuto rispetto agli studi svolti in precedenza e su quali ci si è basati come punto di partenza. nel capitolo SEI Conclusione e sviluppi futuri, verranno elencati alcuni sviluppi futuri che il progetto descritto in questa tesi potrà avere. 7

13 2 Obiettivi L obiettivo principale della tesi è lo studio, la progettazione e la realizzazione di un interfaccia grafica per il monitoraggio energetico in ambito domestico. Si consideri, a tal proposito, la seguente immagine: Figura 2.1: Vista, ad alto livello, del contesto in cui si colloca l interfaccia utente da realizzare Essa mostra un utente che interagisce con la propria casa (ambiente domotico) attraverso un tablet su cui è installata l applicazione sviluppata. Per interagire con efficacia, però, necessita di un interfaccia utente che, da una 8

14 parte, si possa collegare all ambiente domotico e dall altra sia gestibile facilmente dal tablet. Assumendo di non avere alcun tipo di problema nel collegare una qualsiasi interfaccia utente al sistema di controllo domotico Dog, si può notare che qualche problema potrebbe sorgere proprio nel trovare un interfaccia utente utilizzabile con un dispositivo touchscreen, che sia al contempo intuitiva, funzionale, e che risponda a determinati principi di usabilità. A tale scopo, si è approfondito l argomento della visualizzazione su display di informazioni riguardanti il consumo energetico, effettuando svariate ricerche sul Web, visitando i siti dei maggiori produttori di impianti domotici e confrontando alcune delle soluzioni proposte in merito. Un esempio per tutte viene riportato in figura 2.2 dove viene visualizzata un interfaccia che mostra i consumi di alcune stanze presenti in un ambiente domotico della NNOX Domotics 1. Figura 2.2: Esempio visualizzazione livelli energetici in un sistema della NNOX Domotics Come si può vedere dalla figura 2.2, per questa interfaccia utente è stato deciso di fornire sia un informazione numerica, che una grafica. L informazione numerica sta ad indicare il consumo energetico attuale, replicato tramite 1 NNOX Domotics: 9

15 una rappresentazione grafica di un manometro digitale, che ne indica il livello per mezzo di una lancetta. Si può anche notare come la lancetta di tale manometro indichi oltre che un valore, se pur approssimativo, anche un colore di sfondo che varia col consumo energetico, virando dal verde al rosso e passando dall arancio, per indicare il passaggio da valori bassi a valori alti di assorbimento. Informazioni, queste, replicate per ogni stanza presente nell ambiente controllato. Da un analisi più approfondita si nota però come i valori massimi siano identici per tutti gli ambienti controllati, supponendo quindi che in soggiorno (Living Room) come in sala da pranzo (Dining Room) o in camera da letto (Bedroom) vi sia un consumo massimo di 8kW e rapportandone quindi la visualizzazione grafica rispetto a quei valori. Stiamo ovviamente parlando di un solo esempio, ma che in quanto tale, mette in evidenza la necessità di avere per ogni ambiente una regola di visualizzazione rapportata all effettiva capacità massima della stanza supponendo di avere tutti i dispositivi attivi. In particolare, le varie interfacce esistenti prese in considerazione durante la fase di ricerca, seppur con alcuni aspetti positivi come l indicazione con colori diversi in base al consumo, o il mostrare a video il consumo attuale per ogni stanza, non rispettano alcune delle richieste emerse fuori da uno studio pubblicato precedentemente e da cui l obiettivo principale della tesi prende spunto. Lo studio in questione è Home energy consumption feedback: A user survey che ha l obiettivo di valutare due differenti modalità di visualizzazione dei dati energetici e l interazione da parte dell utente con esse, per mezzo di un In-Home Display 2 (IHD), testandone l effettivo funzionamento su un considerevole numero di persone abituate ad utilizzare apparecchi elettronici. Per mezzo quindi di un apposito questionario proposto agli intervistati, si sono raccolti dati sulle attitudini al risparmio di queste persone, sulla comprensione delle visualizzazioni proposte, ed eventuali suggerimenti in merito a modifiche e miglioramenti da apportare. Le due modalità di interazione prese in considerazione si suddividono in: 1. visualizzazione di consumi energetici periodici, ad esempio giornalieri o mensili; 2. feedback visivo immediato di quanto sta avvenendo nell ambiente domestico. 2 In-Home Display: è un dispositivo di visualizzazione dedicato, progettato per fornire informazioni relative al settore energetico, quali consumi, costi o messaggi di servizio forniti direttamente dal distributore di energia o per mezzo di applicazioni di terze parti. 10

16 Per fare ciò sono stati realizzati due prototipi di interfaccia che implementano rispettivamente le due differenti tipologie di visualizzazione sopra citate e successivamente sono stati registrati due brevi video in time-lapse 3 che mostrano i cambiamenti di queste interfacce, quali variazioni di colori e dati riguardanti i consumi, in base all utilizzo di vari dispositivi di uso quotidiano in un appartamento nell arco di una giornata. È stato quindi chiesto ad un migliaio di persone di guardare i due video e successivamente rispondere a un questionario, per valutare quanto queste due visualizzazioni fossero state comprese ed apprezzate. Nello specifico si mirava a: verificare/confermare la volontà degli utenti intervistati di adottare effettivamente un sistema di visualizzazione dei consumi; valutare se le persone comprendevano e accettavano di più l idea di un interfaccia basata su degli obiettivi prefissati di consumo energetico, o sulla visualizzazione immediata dei consumi e di come questi influisco globalmente sull abitazione; verificare la validità di un feedback basato sulla variazione dei colori in parallelo con l utilizzo di valori espliciti riguardanti i consumi energetici; verificare se le informazioni fornite sono di facile comprensione per gli utenti, se sono utili e se sono necessari più o meno dettagli; indagare sulle preferenze riguardanti il posizionamento dell in-home display (IHD) in uno specifico punto dell appartamento. I risultati di questo studio hanno indicato come la maggior parte delle persone vorrebbe effettivamente adottare un sistema IHD, dimostrando un importante interesse verso l argomento risparmio energetico. Circa la metà degli intervistati vorrebbe un sistema che integrasse entrambe le visualizzazioni, ma preferirebbe la visualizzazione ad obiettivi periodici se lo scopo fosse solo quello di incrementare le propria attitudine al risparmio energetico. Tuttavia il sistema di feedback immediato dell attività energetica sembra essere compreso meglio, appunto perchè riesce a rappresentare i consumi in tempo reale. 3 Time-lapse: è una tecnica cinematografica nella quale la frequenza di cattura di ogni fotogramma è molto inferiore a quella di riproduzione. A causa di questa discrepanza, la proiezione con un frame rate standard di 24 fps fa sì che il tempo, nel filmato, sembri scorrere più velocemente del normale. 11

17 Nonostante quindi la visualizzazione ad obiettivi sia più indicata per migliorare il consumo di energia globale sul medio/lungo periodo, il feedback diretto è più utile per visualizzare informazioni relative all immediato, come ad esempio verificare la presenza di dispositivi in funzione che nessuno sta utilizzando. Inoltre i dati raccolti indicano anche che la visualizzazione basata sui colori è semplice da capire e molto apprezzata. Per quanto riguarda invece il posizionamento del display in una specifica posizione dell abitazione, i risultati suggeriscono cucina o ingresso come luoghi preferiti, esito quest ultimo di interesse ai fini del posizionamento di una dock station piuttosto che del tablet stesso, proprio per la natura mobile del tablet, per quanto riguarda la tesi in esame. Infine si è tenuto conto, per quanto possibile, dei suggerimenti estratti dai questionari delle persone intervistate, che possono essere sintetizzati in questi punti principali: riportare il consumo parziale per ogni stanza, anche numericamente; realizzare un interfaccia utente che unisce entrambe le visualizzazioni; aggiungere un allarme per avvisare quando il sistema di sicurezza potrebbe essere in procinto di disattivare l erogazione di energia; fornire il dettaglio istantaneo del consumo elettrico per gli elettrodomestici. Dai risultati ottenuti dallo studio e dai suggerimenti sopra elencati, si evince quindi la necessità di creare un applicazione con un interfaccia utente chiara, e con informazioni utili ed a portata di mano. Risulta utile a tale scopo riassumere gli obiettivi principali riguardanti lo sviluppo dell applicazione in oggetto nella seguente tabella: 12

18 Tabella 2.1: Linee guida per lo sviluppo dell interfaccia utente dell applicazione Requisito Descrizione Priorità Interfaccia a feedback diretto Interfaccia a goal energetici Si implementerà l interfaccia a feedback diretto in quanto è risultata maggiormente Richiesto comprensibile e di immediato effetto sui consumi energetici. Si pensi che un metodo simile è ormai adottato su quasi tutte le autovetture di ultima generazione, dove viene mostrato il consumo istantaneo di carburante, rendendo effettivamente il guidatore consapevole e capace di gestire al meglio i consumi adattando la propria guida all autovettura. In modo simile quindi l utente dovrà essere in grado di adattare il proprio stile di vita in casa osservando le proprie cattive abitudini da un punto di vista diverso, ovvero quello di un interfaccia grafica che ti da informazioni in tempo reale sullo stato dell abitazione. Come si evince dai risultati dell indagine, lo Richiesto sviluppo di un interfaccia a obiettivi periodici sarebbe preferibile per quanto concerne il risparmio energetico sui lunghi periodi, ad esempio settimanali o mensili. Un ulteriore sviluppo sarà quello di realizzare un interfaccia che unisca entrambe le modalità di visualizzazione. Continua... 13

19 Tabella 2.1 Continua dalla pagina precedente Requisito Descrizione Priorità Visualizzazione dei consumi basta sulla variazione dei colori Consumo parziale per ogni stanza Consumo elettrico dei dispositivi Il software dovrà accostare la visualizzazione dei consumi tramite feedback numerici, ad una rappresentazione grafica che gestisce la variazione di potenza associandola a dei colori. Nello specifico verde, il giallo/arancio e rosso, colori che facilmente vengono associati a qualcosa di positivo o negativo, perchè utilizzati largamente nella quotidianità, come in un semaforo. Il verde viene comunemente associato a qualcosa di positivo, ovvero la possibiltà di attraversare l incrocio in questione, quindi nella nostra applicazione rappresenterà bassi consumi e più in generale uno stato non preoccupante della situazione energetica; il rosso invece è spesso associato ad un disagio, nel caso del semaforo a un attesa, e nel nostro caso a un consumo eccessivo dovuto magari a troppi dispositivi attivi contemporaneamente. Risulterà altresì utile fornire informazioni sul dettaglio dei consumi per ogni stanza, fornendo i dati sia numericamente che graficamente. Potrebbe inoltre essere di interesse, come effettivamente richiesto, fornire la possibilità di visualizzare il consumo di ogni dispositivo in tempo reale, aprendo le porte così a varie opportunità di sviluppo dell applicazione ad un livello piú basso, controllando il singolo dispositivo piuttosto che intere aree della casa. Richiesto Opzionale Opzionale Continua... 14

20 Tabella 2.1 Continua dalla pagina precedente Requisito Descrizione Priorità Possibilità di controllare i dispositivi Allarme disattivazione contatore elettrico Gestione razionale dei vari ambienti Nonostante l applicazione sia orientata maggiormente alla visualizzazione dei dettagli ri- Opzionale guardanti i consumi energetici, sarà opportuno dare la possibilità all utente di controllare i dispositivi presenti in casa tramite i comandi di cui essi dispongono, e che dovranno essere integrati nell interfaccia sviluppata. Una funzionalità fortemente richiesta risulta Richiesto essere la possibità di visualizzare un avviso nel caso in cui ci si avvicini al limite energetico consentito dal proprio contratto di fornitura elettrica, in modo tale da disattivare qualche elettrodomestico non necessario al momento, o evitare di accenderne altri e provocare un interruzione di corrente in tutta la casa. Come si è potuto notare dall esempio riportato in figura 2.2, i vari ambienti controllati Richiesto erano trattati egualmente, considerando un consumo standard per tutte le stanze e riportandolo graficamente tramite un manometro digitale. Tale rappresentazione non può andare bene in quanto difficilmente una cucina dove sono presenti forno, lavastoviglie e frigo potrà avere un consumo massimo uguale ad un soggiorno, dove invece i consumi energetici difficilmente saranno elevatissimi. Motivo per cui, tramite opportune formule, si dovrà trattare la visualizzazione dei consumi associata alla colorazione dei vari ambienti controllati, in modo razionale e diversificato, riuscendo a mantenere un elevato livello di comprensibilità. Continua... 15

21 Tabella 2.1 Continua dalla pagina precedente Requisito Descrizione Priorità Mobilità Flessibilità I dati raccolti indicano che l utente preferisce avere uno o più IHD dislocati nei luoghi maggiormente frequentati o di passaggio, come ad esempio la cucina o l ingresso. Il compromesso verrà raggiunto fornendo un applicazione per tablet. Il dispositivo mobile sarà in grado quindi di essere spostato in un qualsiasi punto dell abitazione, installando eventualmente più postazioni di ricarica negli ambienti desiderati. È importante infatti oltre che realizzare le richieste esposte nei precendenti punti, offrire la possibilità, tramite una schermata di impostazioni, di agire su alcuni settaggi, come la portata massima del contatore elettrico, o le soglie che gestiscono la colorazione delle stanze. Opzionale Richiesto Definite quindi le principali linee guida per l implementazione dell interfaccia grafica, ci si pone un altro obiettivo ai fini dello sviluppo dell applicazione, che è quello di realizzare software che sia compatibile sulla maggior parte dei tablet Android. Motivo per cui si è deciso di utilizzare le API di Android 4.x, che è appunto la versione di tale sistema operativo mobile più diffusa sui tablet attualmente in commercio. Grazie alla decisione di utilizzare Android, di cui si parlerà più approfonditamente nei prossimi capitoli, si possono realizzare interfacce utente in maniera semplice e potente, creando codice estremamente leggibile e permettendo la separazione quasi totale della parte di design (cioè, come l interfaccia appare) dalla parte di logica (quali sono i meccanismi per far sì che svolga i suoi compiti). La parte di design, infatti, viene realizzata interamente in XML, mentre la parte di logica viene realizzata con una versione particolare di Java, che differisce solo per alcuni dettagli che verranno chiariti anch essi successivamente. Infine d ora in poi, faremo riferimento all applicazione sviluppata con il nome di wattsup. 16

22 3 Tecnologia utilizzata 3.1 Introduzione Prima di parlare del progetto sviluppato, del suo design e delle scelte progettuali adottate, è doveroso dedicare un po di tempo per presentare sufficientemente nel dettaglio le soluzioni tecniche con cui l applicativo deve interagire. Nel capitolo introduttivo si è parlato di domotica, e si è accennato, in particolare, ad un sistema di controllo dell ambiente domotico, sviluppato dal gruppo di ricerca del Politecnico e-lite, chiamato Dog. Si è menzionato, inoltre, il sistema operativo mobile Android, per cui l applicazione è stata progettata, nello specifico per la distribuzione Android ICS (Ice Cream Sandwich) e successive, riconoscibili anche dal numero di versione 4.x. Possiamo vedere in figura 3.1 come le varie componenti sono relazionate tra di loro, mentre nei paragrafi seguenti si spiegherà, più dettagliatamente, come questi componenti funzionano e come interagiscono con l applicazione sviluppata. 3.2 Ambiente domotico utilizzato Come si è precedentemente detto, la domotica è la disciplina che si occupa di studiare tecnologie informatiche e appartenenti all area dell automazione e della telecomunicazione, per poterle utilizzarle negli ambienti domestici, al fine di migliorarne il comfort, l abitabilità e di semplificare la vita delle persone mentre vivono in questi ambienti. Con la domotica, quindi, si possono automatizzare semplici funzioni della casa come, per esempio, l accensione e lo spegnimento delle luci, oppure sviluppare servizi più intelligenti come, per esempio, gli scenari, cioè un 17

23 3.2. AMBIENTE DOMOTICO UTILIZZATO Figura 3.1: Come l interfaccia utente è connessa a Dog elenco di attività riguardanti determinati dispositivi domestici che possono venire attivati o disattivati tutti insieme in un certo momento della giornata, a scelta dell utilizzatore. Un ambiente domotico, pertanto, è un ambiente opportunamente progettato e tecnologicamente attrezzato, in cui sono presenti impianti e dispositivi che sfruttano tecnologie che li rendono controllabili da remoto ed eventualmente anche in grado di comunicare tra di loro. Anche se il termine da remoto può dare l idea che la casa venga controllata da un altro posto, al di fuori dell abitazione, in questo contesto si intende semplicemente che un oggetto o una funzionalità della casa può essere controllata senza il bisogno di maneggiare o toccare fisicamente l oggetto in questione. Quindi, l oggetto può anche trovarsi di fronte all utente ma esso lo controlla in remoto grazie all applicazione sviluppata durante questo progetto e resa fruibile su un tablet, che può essere dislocato in un luogo strategico della casa, o semplicemente usato in qualsiasi punto dell abitazione, dal soggiorno al giardino. Inoltre, un ambiente domotico come quello mostrato in figura 18

24 3.2. AMBIENTE DOMOTICO UTILIZZATO Figura 3.2: esempio di architettura domotica 3.2 è composto da una serie di componenti hardware e software. Le componenti hardware sono gli impianti domotici, che comprendono alcuni dispositivi e un gateway, che gestisce la comunicazione con ogni dispositivo appartenente al proprio impianto e con l House Manager. I gateway dei vari impianti domotici, a loro volta, sono collegati con un Domotic House Gateway che gestisce la rete di comunicazione tra i diversi gateway. La componente software, invece, è il cuore del sistema domotico perchè ha il compito di gestire i dispositivi della casa, non importa in quale impianto essi si trovino: tale componente prende il nome di House Manager. L House Manager si occupa anche di fornire servizi intelligenti e alcune applicazioni che permettano all utente di interagire con la casa. L House Manager, nel contesto che stiamo considerando, altro non è che Dog. 19

25 3.2. AMBIENTE DOMOTICO UTILIZZATO Dog Dog (Domotic OSGi Gateway) è una piattaforma che permette l interfacciamento, la gestione e l integrazione di dispositivi domotici di diversi costruttori in un singolo sistema software. Realizzato con tecnologia OSGi, fornisce un ambiente per gli sviluppatori orientato ai servizi e basato su componenti, offrendo così modi standardizzati di gestire il ciclo di vita del software stesso. Fornisce un framework Java stabile, sicuro e general-purpose che supporta lo sviluppo di applicazioni di servizio estensibili chiamate bundle o, in italiano, moduli, che sono facili da integrare: basta, infatti, che siano conformi ai vincoli di comunicazione definiti nel framework stesso. Come illustrato nella figura 3.3, Dog è composto da differenti moduli, che Figura 3.3: L architettura logica di Dog hanno i vari usi e ruoli descritti di seguito: Network Drivers permette l interazione diretta con le componenti hardware dell ambiente domotico. È necessario un driver differente per ogni protocollo di basso livello utilizzato dalle varie componenti. Attualmente è formato da tre bundle: Konnex per i sistemi KNX/- Net IP, BTicino per i sistemi MyHome BTicino, Elite che permette di 20

26 3.2. AMBIENTE DOMOTICO UTILIZZATO emulare i dispositivi fisicamente non disponibili, consentendo così di utilizzare il software anche in assenza di un ambiente domotico reale, cioè in simulazione, nodbus, echlor e z-wave; Message Dispatcher effettua il routing degli eventi in arrivo dai Network Drivers e i comandi in arrivo dall Executor; contiene, quindi, una tabella di routing per mappare la corrispondenza tra i dispositivi e i Network Drivers che possono comandarli; Executor riceve i comandi dal modulo API, ne controlla la correttezza interagendo con il modulo Status e li esegue inviando i nuovi comandi al Command Dispatcher; House Model contiene la rappresentazione della casa e dei dispositivi appartenenti all ontologia DogOnt, descritta nel prossimo sottoparagrafo; Status è una sorta di cache che contiene lo status dei dispositivi presenti nel sistema; risponde alle richieste mandate dal modulo API, restituendo informazioni sui vari dispositivi; Platform Manager gestisce l installazione, l avvio e la sospensione dei bundle all interno della piattaforma OSGi, fornisce informazioni sullo stato dei bundle e gestisce la sequenza di bootstrap di sistema; Configurator Registry fornisce i dati di configurazione necessari al funzionamento dei singoli moduli; API è il punto di accesso esterno al sistema; fornisce una serie di servizi come l elenco dei dispositivi presenti nella casa, la possibilità di eseguire comandi e quella di registrarsi come listener per ricevere determinati eventi e conoscere lo stato di uno o più dispositivi; XmlRpcConnector espone i servizi offerti dal modello API sotto forma di end-point XML-RPC: l interfaccia utente utilizzerà questo modulo e il protocollo XML-RPC per interagire con Dog; Dog2Library, infine, specifica le interfacce dei servizi offerti dai bundle, definendo e implementando le classi di sistema e le eccezioni. L interfaccia utente comunicherà con Dog principalmente durante due fasi, quella iniziale in cui l interfaccia riceverà il modello della casa con tutti i suoi dispositivi, insieme con il loro stato e la loro descrizione; e quella operativa in 21

27 3.2. AMBIENTE DOMOTICO UTILIZZATO cui l interfaccia comunicherà a Dog i comandi che vuole compiere (per esempio, accendere una luce) e Dog risponderà restituendo l esito dell operazione che gli è stata richiesta ( la luce si è accesa ). Sempre nella fase operativa, Dog potrebbe comunicare all interfaccia che il verificarsi di un evento (qualcuno ha premuto un pulsante e la luce si è accesa) e l interfaccia tratterà questa informazione di conseguenza, generalmente producendo una notifica destinata all utente. La fase operativa, come è facile intuire, è una fase che viene ripetuta diverse volte, fintanto che Dog e l interfaccia sono entrambi in funzione e qualcosa capita all interno dell ambiente domotico DogOnt DogOnt è il modello formale per la rappresentazione di un ambiente domotico, composto da due elementi: un ontologia e un insieme di regole. Una ontologia è una rappresentazione formale di una interpretazione condivisa di uno specifico dominio di conoscenza. Non esistendo l ontologia perfetta, la rappresentazione di un determinato dominio può essere formalizzata in una moltitudine di modi e dipende dallo scopo per cui viene creata. Un ontologia assume normalmente una struttura a grafo connesso con concetti e relazioni che li collegano. Le componenti fondamentali di una ontologia sono: Classi - insiemi, collezioni o tipi di oggetti; Attributi - proprietà, caratteristiche o parametri che gli oggetti possono avere e condividere; Relazioni - modi in cui gli oggetti possono essere messi in relazione gli uni con gli altri; Individui - istanze del modello, che sono gli elementi di base. Le classi di un ontologia sono concetti astratti che esprimono una classificazione delle entità rilevanti del dominio. L ontologia ha generalmente una classe radice chiamata Thing da cui discendono tutte le altre. Le classi nell ontologia seguono il principio dell ereditarietà padre-figlio a livello di classe e proprietà. Analizzando la figura 3.4, si può notare che l ontologia di DogOnt si sviluppa lungo cinque rami principali: 22

28 3.2. AMBIENTE DOMOTICO UTILIZZATO Figura 3.4: L ontologia di DogOnt Building Thing: rappresenta gli oggetti disponibili (controllabili, come una luce, oppure no); Building Environment: rappresenta dove gli oggetti sono collocati; State: rappresenta le configurazioni stabili (gli stati, come acceso o spento ) che gli oggetti controllabili possono assumere; Functionality: rappresenta cosa gli oggetti controllabili possono fare (accendersi e spegnersi, per esempio); la maggior parte degli oggetti istanziabili non ha funzionalità comandabili con più di tre comandi. Domotic Network Component: rappresenta delle caratteristiche peculiari di ogni impianto domotico. 23

29 3.3. ANDROID Ogni ramo, a sua volta, avrà un certo numero di altri rami figli, a seconda di cosa deve rappresentare: Building Thing, che è uno dei rami dell ontologia più interessanti poichè contiene tutti i dispositivi, gli elementi di mobilio e quelli architetturali che ci possono essere nella casa, si divide in Controllable e Uncontrollable, per separare gli oggetti che sono controllabili da quelli che, come il tavolo del soggiorno, non lo sono. DogOnt, inoltre, rappresenta ogni dispositivo come un oggetto che possiede un insieme di funzionalità e di stati. Le funzionalità sono automaticamente aggiunte a ogni istanza del dispositivo, in base alle restrizioni definite al livello di classe. Esse sono condivise da tutti i dispositivi della stessa classe: pertanto, diversi tipi di lampade appartenenti alla stessa classe potranno avere delle funzionalità in comune. D altra parte, invece, gli stati sono peculiari a ogni dispositivo. Quindi, se si volesse ottenere un modello della casa personalizzato e virtuale, per esempio per eseguire alcune simulazioni, basterebbe creare una istanza per ogni camera che si vuole avere nella casa (le stanze si trovano nel ramo Building Environment ); dopodichè basterebbe creare le istanze dei dispositivi che si vogliono avere nelle singole stanze, come luci, interruttori o elettrodomestici (si trovano tutti in Building Thing > Controllable > White Goods ) e assegnargli i tipi di funzionalità e i tipi di stato che sono previsti nelle loro classi. Fornendo alcune modalità di ragionamento, inoltre, DogOnt è in grado di fornire la posizione di un dispositivo domotico nella casa, elencare l insieme delle sue caratteristiche, fornire le caratteristiche tecnologie necessarie per interfacciarsi con quel dispositivo, dire come è composto l ambiente domestico e presentare gli elementi architetturali e di mobilio che sono presenti nella casa. Ci sarebbe ancora molto da dire riguardo questo argomento ma, per gli obiettivi di questa tesi non è necessario sapere altro: l interfaccia utente si collega direttamente con Dog che gli fornisce il modello della casa con tutti i suoi dispositivi e non ha bisogno di modificare nè l ontologia nè le regole di DogOnt. è sufficiente sapere cos è un ontologia, che i vari dispositivi hanno delle funzionalità e degli stati e che Dog prende da qui il modello della casa, senza il quale nulla potrebbe funzionare. 3.3 Android Conclusa la parte riguardante la domotica e in particolare Dog, focalizziamo l attenzione su Android, cercando di spiegare cosa è e come funziona, senza 24

30 3.3. ANDROID scendere troppo nel dettaglio. Android è un sistema operativo open-source basato su kernel Linux e pensato per operare esclusivamente su dispositivi mobili come smartphone e tablet, anche se negli ultimi tempi l enorme successo di questa piattaforma, e l estrema versatilità che essa sta dimostrando, stanno portando i maggiori produttori di gadget tecnologici a pensare di espanderne l utilizzo su dispositivi come fotocamere, navigatori ed altri accessori di quotidiano utilizzo. Android è distribuito da Google, ma la paternità del progetto è di una piccola società, Android Inc., acquisita nel 2005 proprio da Google che aveva intuito l enorme potenzialità del progetto. La prima release è datata novembre 2007 anche se si dovette però aspettare fino al 23 settembre 2008 per il lancio della versione 1.0 Apple Pie. Da lì in poi si sono succedute versioni su versioni, sviluppate con dei nomi in codice, rilasciate in ordine alfabetico ed identificate ognuna da una differente rappresentazione grafica, che hanno reso questo simpatico sistema operativo, il punto di riferimento per tutti i produttori intenzionati ad affacciarsi al mondo dei dispositivi mobili. In figura 3.5 troviamo le maggiori distribuzioni commerciali di Android Risorse per gli sviluppatori Le applicazioni per Android si possono differenziare per aspetto, utilità e per il modo in cui vengono gestite dal sistema stesso. Abbiamo infatti: Attività (Activity) Le attività sono quelle applicazioni destinate a una interazione diretta con l utente. Un esempio sono l applicazione sviluppata per il progetto che si stà discutendo in questa tesi, i videogiochi, i software per l ufficio o i visualizzatori di E-book. Le attività vengono generalmente distribuite sotto forma di file.apk, vengono poi installate in delle cartelle nella memoria del dispositivo o in una memoria esterna (MicroSD card), infine viene creata una icona per l utente, che gli permetterà di eseguirla in qualsiasi momento. Le attività vengono create come oggetti di classe Activity da cui ereditano proprietà e metodi. Servizio (Service) I servizi sono, al contrario, quelle applicazioni che per loro natura svolgono delle operazioni autonome e che vengono richiamati dalle attività al bisogno. Il sistema operativo fornisce alle applicazioni vari servizi già pronti all uso, per ottenere l accesso all hardware o a risorse esterne (ad esempio dei web services di messaggistica). I servizi sono oggetti di classe Services. Un esempio di 25

31 3.3. ANDROID Figura 3.5: Maggiori distribuzioni commerciali di Android servizio com.android.inputmethod.latin, ossia il componente che fa comparire la tastiera quando si seleziona (con i tasti o con un tocco sul touch-screen) un campo di input testuale. I servizi possono essere eseguiti o interrotti direttamente dall utente, sebbene siano eventualità alquanto rare. Fornitori di contenuti (Content provider) I fornitori di contenuti sono dei contenitori di dati generati dalle applicazioni che ne forniscono una condivisione; i dati possono essere contenuti nel file System, in un database SQLite, sul web o in una qualunque locazione di dati. La classe alla quale appartengono questi oggetti è ContentProvider. Ricevitori di trasmissioni diffuse (Broadcast receivers): I Broadcast receivers, di cui si fa ampio uso in wattsup, permettono di ricevere segnali rivolti a tutte le apps in esecuzione, per la condivisione di dati o di segnali di servizio (come ad esempio quello di batteria scarica). I broadcast receivers, sebbene non usino l interfaccia del sistema, pos- 26

32 3.3. ANDROID sono far apparire messaggi informativi che si sovrappongono all output dell activity corrente. Il kernel e le librerie di base Questi componenti non sono sostituibili; al massimo sono aggiornabili alcune parti per correggere eventuali problemi di sicurezza. Quando viene rilasciata una nuova versione di Android, significa che alcune di queste parti sono state aggiornate o sostituite. Il file APK Il software viene solitamente distribuito sotto forma di pacchetto autoinstallante, quindi un file con estensione.apk. Questo non è altro che un file compresso, contenente il software (file con estensione.dex), le sue risorse (immagini, suoni ecc...) e alcuni file XML. L utente medio non ha necessariamente bisogno di conoscere tale tipologia di file, dato che il dispositivo gestisce tutta la parte di installazione mediante web services come Google Play. All interno di questo file c è anche un certificato che permette l installazione di un pacchetto.apk su un dispositivo Android se questo non è stato compromesso o revocato. Il certificato deve essere presente in qualsiasi pacchetto, altrimenti Android non installerà l applicazione al suo interno. Il certificato viene creato dallo sviluppatore dell applicazione, che può scegliere di crearne uno di debugging (quindi a uso interno) o di mercato (per la distribuzione) e può deciderne la sua diffusione delle copie (libera o limitata). Il distributore (per esempio Google Play) ci aggiungerà poi una sua chiave, che potrà successivamente revocare, se necessario. In caso di revoca, l applicazione non è più installabile nè eseguibile in nessun dispositivo Android. Se uno sviluppatore indipendente vuole poter distribuire un suo software con pacchetto.apk, senza passare per un web service certificato, può autocertificarsi il certificato. In tal caso, l utente riceverà un avviso che sta installando un software di questo tipo (self-signed); a questo punto potrà annullare l installazione o farla proseguire a suo rischio. Le classi La classe è un concetto della programmazione ad oggetti. Per semplificare, consiste nella suddivisione di un software in componenti, questo per evitare di usare il vecchio paradigma della programmazione lineare, che consiste nello stilare una lista di istruzioni sequenziali che possono essere poco adattabili per l aggiunta di ulteriori funzionalità in futuro. Su Android tutti i componenti sono catalogati come classi e richiamabili da altri componenti se il programmatore ne permette questa possibilità. Per fare qualche esempio, le classi del package android.bluetooth 27

33 3.3. ANDROID permettono a uno sviluppatore indipendente di includere nella sua applicazione la possibilità di comunicare con un applicazione (la stessa o un altra) installata su un altro dispositivo mobile, utilizzando il Bluetooth. Esiste anche il package android.gesture, con al suo interno le classi che permettono a una applicazione di ricevere le gestures, ossia i tracciamenti di un dito che sfiora il touch-screen. Internamente, tutti i processi dei servizi in esecuzione vengono eseguiti con tali nomi e sono visibili nel menu Impostazioni Android SDK Dopo aver parlato della suddivisione e della tipologia delle applicazioni che possiamo ritrovare in Android, ci soffermiamo su alcuni aspetti leggermente più tecnici riguardanti ciò che stà alla base del software che viene sviluppato per questo sistema operativo. Le applicazioni di Android sono sviluppate, infatti, all interno di un framework, ossia di una struttura dati specifica. La struttura del framework è molto chiara se si utilizza l ambiente di sviluppo (SDK) con Eclipse 1 ; il mancato utilizzo di Eclipse, tuttavia, non impedisce di scrivere applicazioni Android funzionanti. Le applicazioni Android sono caratterizzate da una certa dualità: parti dinamiche scritte in Java e parti statiche scritte in XML. Tipico delle parti statiche possono essere quelle caratteristiche che non cambiano durante l esecuzione dell applicazione, come per esempio il colore dello sfondo. Tipico delle parti dinamiche sono gli aspetti programmatici come per esempio la gestione degli eventi. Questa dualità è però solo apparente. Durante l esecuzione, infatti, la Dalvik Virtual Machine (DVM) esegue sempre un programma. Per lo sviluppo delle applicazioni è disponibile una completa documentazione la quale, anche graficamente, riprende la struttura tipica della documentazione Java del sito Oracle. La Dalvik Virtual Machine Tramite l SDK (o meglio tramite gli strumenti utilizzati mediante l SDK) trasformiamo la nostra applicazione Android in un codice intermedio chiamato bytecode. Questo ad esempio è esattamente quello che accade abitualmente in Java, ossia: 1 Eclipse: eclipse è un ambiente di sviluppo integrato multi-linguaggio e multipiattaforma ideato da un consorzio di grandi società quali Ericsson, HP, IBM, Intel, MontaVista Software, QNX, SAP e Serena Software, chiamato Eclipse Foundation sullo stile dell open source. 28

34 3.3. ANDROID Codice Java: compilazione: bytecode: VM -> esecuzione reale del programma Questo bytecode viene eseguito dal un programma chiamato macchina virtuale (Virtual Machine, VM). Negli ambienti Android non viene utilizzata la macchina virtuale Java, bensì è stata scritta una nuova VM chiamata Dalvik Virtual Machine (DVM). Ogni terminale Android ha la sua DVM, come descritto nell architettura del sistema, e il suo compito è solo quello di eseguire il bytecode. Avremo quindi la seguente catena di esecuzione: Applicazione Android: compilazione: bytecode: DVM -> esecuzione reale dell applicazione Android L idea è questa: essendo la DVM uguale per tutti i dispositivi Android, ogni applicazione può essere eseguita su ogni terminale, indipendentemente dal costruttore e dall implementazione. La conseguenza di questa idea, che è anche una visione, è stata che molti costruttori di dispositivi mobili hanno scelto Android, fornendo in questo modo ai propri utenti un ambiente condiviso da moltissimi altri utenti. Creazione, compilazione, emulazione Sempre tramite l SDK possiamo passare dalla descrizione della nostra applicazione alla sua effettiva esecuzione sia in emulazione, sia su un dispositivo concreto. Per descrivere l applicazione al dispositivo prescelto si utilizza il file Manifest.xml Possiamo quindi affermare che un applicazione è descritta completamente da una tripletta: Codice Java Risorse statiche xml Manifest.xml Il codice Java viene compilato insieme all xml per generare un file con estensione.apk: esso contiene il bytecode per la DVM. I passi successivi servono per installare il bytecode nel dispositivo (ed eseguirlo in emulazione). Java Il linguaggio per applicazioni Android è un dialetto del linguaggio Java e come abbiamo già detto anche la virtual machine è diversa (Dalvik). Nella tipica applicazione Android non c è un entry point (metodo main) da dove normalmente un programma comincia a caricare le sue parti software 29

35 3.3. ANDROID e avviarsi. Tutto è pensato per essere un componente pilotato dagli eventi (Event Driven) dell hardware o di altri componenti. Questo paradigma fa sì che il programmatore sviluppi per ogni hardware delle routine il più possibile indipendenti. Un vantaggio è che il sistema operativo potrà ottimizzare le risorse, ad esempio rinunciando a caricare componenti (e hardware) non supportati o non prioritari perchè inutilizzati. Inoltre, i componenti possono condividere le loro funzionalità: se ad esempio un videogioco trova installato nel dispositivo un programma che ritocca le fotografie appena scattate con la fotocamera del dispositivo, può avviarlo (se l utente glielo consente) per permettere all utente di ritoccare tali foto, sceglierne una e farsela passare per scopi ludici. Il tutto con una interfaccia grafica perfettamente integrata e quindi senza tante aperture e chiusure di programmi. Ma soprattutto, il programmatore è cosè sollevato dall onere di dover creare un sottoprogetto per implementare una funzionalità già esistente sotto altra forma. Risorse XML I file con estensione.xml contengono esclusivamente parte dichiarativa contenente principalmente informazioni di tipo grafico o di supporto. Si suddividono quindi in: informazioni di layout supporto multilingue Android Manifest XML File che descrive l applicazione al dispositivo. Il Manifest elenca la lista delle necessità del programma per poter operare nel sistema. Per esempio, se una apk richiede la connessione alla rete, lo notifica nel Manifest e, qualora la connessione non sia disponibile, l applicazione verrà bloccata a runtime 2. In generale è opportuno ai fini della sicurezza vagliare attentamente il contenuto del Manifest, soprattutto se proviene da fonte non verificabile, e non installare il programma qualora le richieste del Manifest non siano congrue con gli obbiettivi dichiarati del programma stesso, soprattutto nel caso di richieste di connessione a linee di telefonia. 2 Runtime: in informatica, il termine runtime o run-time (spesso reso in italiano come tempo di esecuzione) indica il momento in cui un programma per computer viene eseguito. 30

36 3.4. XML-RPC 3.4 XML-RPC Terminata anche la descrizione di Android, è necessario spendere qualche parola su XML-RPC, che come si è già detto, è il protocollo che ci permette di far interagire Dog con wattsup. Più precisamente XML-RPC è un protocollo utilizzato in informatica, che permette di eseguire delle chiamate a procedure remote (RPC - Remote Procedure Call), attraverso lo standard XML, per codificare le richieste, e il protocollo HTTP come meccanismo di trasporto. Nonostante la sua semplicità permette di trasmettere strutture dati complesse, chiedendone l esecuzione ed avendone il risultato indietro. XML-RPC lavora mandando richieste HTTP al server che implementa il protocollo. Il cliente in questi casi è tipicamente un software che vuole chiamare un metodo di un sistema remoto, a cui possono essere passati uno o più parametri in ingresso, e che ritorna un solo valore. I tipi di parametri permettono l annidamento in mappe o liste, in modo da poter trasportare strutture dati di grandi dimensioni. Pertanto XML-RPC può essere utilizzato per trasportare oggetti o strutture sia come parametri di ingresso che di uscita. L identificazione dei client allo scopo di autorizzare gli accessi, può essere raggiunto mediante i popolari metodi di sicurezza HTTP. L autenticazione base di accesso è usata per l identificazione, e HTTPS è usato quando identificazione (per mezzo di certificati) e crittografia sono necessari, inoltre entrambe i metodi possono essere combinati. Nell applicazione sviluppata è stata integrata ed ottimizzata per l uso con Android, una versione delle librerie XML-RPC utilizzata in un precedente progetto sviluppato in Java, che utilizzava lo stesso ambiente domotico gestito da wattsup, ma in una versione meno recente dell attuale. Alcuni esempi di messaggi scambiati fra Dog e l applicazione: Richiesta esecuzione comando set con valore 50 per il device DimmerLam1: <?xml version="1.0" encoding="utf-8"?> <dogmessage xmlns=" xmlns:xsi=" xsi:schemalocation= " DogMessage.xsd" > <commandmessage> <commanddevice> <devices> 31

37 3.4. XML-RPC <device uri="dimmerlamp1" /> </devices> <command name="set"> <param>50.0</param> </command> </commanddevice> </commandmessage> <session>without this code DOG2 will not response</session> </dogmessage> Risposta da parte di Dog al comando STATE per il device SimpleLamp1: <?xml version="1.0" encoding="utf-8"?> <dogmessage id="idmessage" date=" t11:00:00" xmlns= " xmlns:xsi= " xsi:schemalocation= " DogMessage.xsd" > <statenotification uri="simplelamp1"> <currentstate name="onoffstate" value="on"/> </statenotification> </dogmessage> 32

38 4Design Dopo aver introdotto gli obiettivi di questa tesi, ed aver parlato degli strumenti necessari alla realizzazione dell applicazione, in questo capitolo verranno presentate le varie fasi che porteranno alla realizzazione dell interfaccia utente di wattsup, mostrando l architettura dell ambiente in cui andrà a collocarsi, esponendo e motivando le scelte progettuali fatte e analizzando gli aspetti più interessanti della sua realizzazione dal punto di vista della programmazione Android. 4.1 Introduzione Dal capitolo 2, Obiettivi, si evince la necessità di avere alcune funzionalità minime da implementare durante lo sviluppo dell applicazione, che sono state indicate con priorità Richiesto in tabella 2.1. Questa tabella risulta essere infatti il sunto di studi effettuati in merito agli IHD e del survey di cui si è già ampiamente discusso in precedenza, e riporta alcuni obiettivi con diverse priorità. Ai fini della tesi sarebbe stato necessario implementare solo le funzionalità richieste, tuttavia sono state sviluppate molte funzionalità opzionali, in modo da rendere l applicazione più completa possibile e dare la possibiltà all utente di avere un controllo maggiore sulla propria abitazione, permettendo di controllare il singolo dispositivo quando possibile, piuttosto che soffermarsi al semplice monitoraggio dei consumi per le stanze della casa. Avremo quindi un applicazione che da una parte dovrà interagire con il gateway Dog, e dall altra dovrà rispettare le linee guida di cui sopra. La realizzazione della versione finale di wattsup presentata come risultato finale di questo progetto, inoltre, ha richiesto diverse fasi preliminari: 33

39 4.1. INTRODUZIONE lo studio delle caratteristiche di Dog, le modalità di connessione con esso e di come fosse possibile scambiare messaggi fra Dog e l applicazione; la realizzazione di versioni preliminari dell interfaccia; la realizzazione del mock-up di wattsup. Per capire il funzionamento di Dog quindi è stata realizzata un interfaccia molto scarna, come mostrata in figura 4.1. Questa interfaccia, quasi del tutto testuale, permette infatti di realizzare lo scambio di messaggi essenziali, come quello di connessione o quello per la ricezione della configurazione della casa, per poterne studiare quindi la struttura e realizzare un parser da inserire successivamente nell applicazione finale. Figura 4.1: Interfaccia per i test di connessione con Dog Il collegamento con Dog, effettuato grazie a XML-RPC, non ha presentato particolari difficoltà, anche grazie all utilizzo di alcune librerie importate nel progetto, create per il linguaggio Java. Tuttavia proprio la traduzione da Java al dialetto utilizzato in Android, non è stata priva di problemi, ed ha fatto sì che fosse necessaria un attenta e scrupolosa analisi del codice, soprattutto per evitare di ricadere in qualche errore di gestione dei messaggi scambiati o della connessione con Dog. Viceversa, la realizzazione dell interfaccia finale ha presentato qualche difficoltà, non tanto nell implementazione della stessa, ma piuttosto nel riuscire a 34

40 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ trovare una combinazione grafica tra la semplicità d utilizzo e la funzionalità effettiva. Il risultato finale infatti, è stato il frutto di diversi step implementativi e versioni valutative intermedie, dovute soprattutto all integrazione di nuove funzionalità in corso d opera, cercando sempre di mantenere fede all obiettivo principale di realizzare un interfaccia semplice e al contempo intuitiva. Si è iniziato infatti abbozzando alcuni disegni di come l interfaccia avrebbe dovuto presentarsi, per poi passare alla realizzazione grafica su Android, ottenendo infine l interfaccia mostrata in figura 4.2, che rappresenta la schermata principale della versione finale di wattsup. Figura 4.2: Schermata principale wattsup 4.2 Scelte progettuali e funzionalità Come si può osservare in figura 4.2, si è cercato di fornire all utente un informazione immediata in merito alla situazione energetica attuale, e al contempo di fornire dati in tempo reale su eventuali cambiamenti di stato o variazioni di potenza per qualche dispositivo presente in casa. Era necessario quindi dare alla visualizzazione dell appartamento una porzione importante dello spazio a disposizione sullo schermo, che fosse di immediato effetto all occhio dell utente nel caso di un cambiamento, soprattutto se di natura rilevante, 35

41 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ come può essere l accensione o lo spegnimento di un elettrodomestico che influisce pesantemente sui consumi. È il caso di spendere due parole per descrivere le caratteristiche essenziali dell interfaccia principale di wattsup. Sulla sinistra, mostrato sempre in figura 4.2 e occupante circa l 80% dello schermo, troviamo l area dedicata alla visualizzazione delle stanze presenti nella descrizione dell appartamento, ricevuta da Dog in fase di connessione, ognuna con un colore, come spiegheremo meglio più avanti, determinato dal consumo attuale dei dispositivi attivi all interno di esse. Nella restante porzione di schermo troviamo una colonna divisa in due parti: 1. la parte superiore contiene un semaforo che indica lo stato energetico della casa associandolo ad un colore, come si può osservare in figura 4.3. La stessa indicazione è poi replicata in termini numerici e indica lo stato di consumo globale; 2. la parte inferiore ci indica invece quale dei dispositivi attivi sta attualmente consumando più energia nell intero appartamento (mostrato in figura 4.4). Sono presenti inoltre, sempre nella colonna di destra, in base al consumo attuale della casa, 2 o 3 pulsanti: 1. situato al di sotto dell indicatore numerico di consumo, il pulsante warning che avvisa del pericolo dell attivazione del sistema di sicurezza (disattivazione contatore elettrico) in caso di accensione di uno dei dispositivi opportunamente elencati tramite la pressione del pulsante stesso; questo appare solo in caso esista almeno un dispositivo tale che, se attivato, il suo consumo, sommato a quello attuale della casa, ecceda il limite massimo dell appartamento, ad esempio 3kW, come mostrato in figura 4.3; 2. pulsate info, sovrapposto all icona del dispositivo più energivoro della casa, visibile in figura 4.4, che se premuto ci mostra una finestra a popup con l elenco dei 10 dispositivi che consumano di più; 3. pulsante settings in basso a destra, che fa apparire una finestra di popup utile a modificare alcuni settaggi dell app. 36

42 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ (a) Consumo nella norma (b) Avviso attivato Figura 4.3: Esempio attivazione automatica pulsante warning (a) Dispositivo più energivoro in primo piano (b) Pulsante Info selezionato Figura 4.4: Dispositivo più energivoro e pulsante Info 37

43 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ Dopo aver parlato delle funzionalità principali della schermata iniziale, è il caso di descrivere più dettagliatamente cosa avviene quando si tocca il display in una delle zone che definiscono le varie funzioni disponibili Le stanze Toccando lo schermo in una delle stanze presenti in casa verremo proiettati al suo interno, tramite la comparsa di una finestra di popup, come mostrato in figura 4.5. Figura 4.5: Finestra di popup per la visualizzazione di una stanza Al suo interno troveremo quindi tutti i dispostivi presenti in quella stanza, ottenuti in fase di connessione da Dog. La visualizzazione della stanza è suddivisa in quattro parti: 1. la prima parte dove sono mostrati tutti i dispositivi della stanza presa in considerazione; questi sono raffigurati tramite un icona, rappresentativa della tipologia del device, da un nome, unico per ogni dispositivo, e da un bollino opportunamente colorato che ne dà una prima indicazione sul consumo attuale, senza bisogno di doverci cliccare sopra; 2. un piccolo pannello informativo che riassume i consumi istantanei di: stanza presa in considerazione; 38

44 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ intero appartamento; dispositivo, se selezionato; 3. un grafico situato in alto a destra che ci mostra in tempo reale, tramite l animazione della dimensione verticale delle barre e della colorazione, se qualche consumo varia mentre ci troviamo all interno della camera; 4. un pannello informativo a comparsa, che ci fornisce tutti i dettagli del dispositivo selezionato, e ci dà la possibilità di comandare il dispositivo nel caso in cui questo abbia a disposizione dei comandi azionabili Informazioni sui device più energivori Il pulsante Info, già menzionato, e mostrato in figura 4.4, dà la possibilità di accedere, tramite finestra a comparsa, ad una lista di dispositivi che stanno consumando più energia in casa. Figura 4.6: Lista dispositivi più energivori 39

45 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ L elenco degli elettrodomestici più energivori è limitato, per scelta progettuale, a dieci dispositivi. Nel caso ce ne siano di più, infatti, verranno elencati solo quelli con i consumi più alti, in quanto in un appartamento difficilmente si avranno, contemporaneamente attivi, un numero elevato di dispositivi con un consumo energetico eccessivo, in quanto si arriverebbe facilmente a superare il limite massimo di potenza consentito dal proprio contratto di fornitura energetica. Espandere l elenco a più dispositivi, inoltre, lo farebbe diventare semplicemente un elenco di tutti device attivi, e si perderebbe quindi la funzionalità che si voleva implementare. Questo popup informativo, mostrato in figura 4.6, ci dà per ogni dispositivo informazioni sul nome, sulla posizione, ovvero in quale stanza è situato, e sul consumo attuale. Inoltre cliccando su un qualsiasi dispositivo della lista, verremo portati nella vista della stanza in cui esso si trova, con il device già selezionato, avendo così la possibilità di disattivarlo, o eventualmente abbassarne la potenza se è consentito dal tipo di dispositivo Impostazioni Fra gli obiettivi preposti compare anche quello di dotare l appliczione di una certa flessibilità nella gestione dell interfaccia utente. Per questo motivo è stata implementata una schermata per la modifica di alcune impostazioni, basilari, ma che consentono all utente di modificare, ad esempio, i tempi di notifica della variazione energetica, abbassando o alzando le soglie α e β, di cui si spiegherà nel dettaglio il funzionamento nel prossimo paragrafo. Tramite la pressione quindi del pulsante settings, situato in basso a destra nella schermata principale, si accede ad una finestra di impostazioni, mostrata in figura 4.7. La schermata è suddivisa in due parti: in alto troviamo una sezione informativa, con dati non modificabili, quale il proprio indirizzo IP, quello del gateway domotico e il consumo attuale dell appartamento; in basso invece abbiamo due slider per modificare le soglie con cui tutti gli elementi dell applicazione gestiscono la colorazione (indicazioni numeriche dei consumi, colorazione delle stanze, indicatore di consumo sui dispositivi, ecc.) e un campo di testo che consente la modifica del valore di potenza massima gestito del contatore di energia. Infine più in basso troviamo il tasto Save per salvare le impostazioni modificate, e il tasto Reset per caricare i dati di default dell applicazione: alpha = 0.4 beta =

46 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ Figura 4.7: Finestra impostazioni wattup max home power = 3.0 kw Gestione della colorazione Come si è già avuto modo di accennare, all interno dell app che si stà illustrando vi è una gestione accurata dei vari elementi della casa, dalle stanze ai dispositivi, dal consumo totale della casa a quello parziale degli elettrodomestici. Questa gestione riguarda soprattuto il modo in cui dispositivi, stanze e notifiche di consumo rappresentano le variazioni di potenza che avvengono all interno dell appartamento. Si può osservare per esempio come in figura 4.2 vi siano alcune stanze colorate diversamente. In dettaglio la gestione della colorazione delle stanze in questa interfaccia basata sulla visualizzazione a feedback diretto, viene trattata considerando la potenza assorbita dalla stanza in tempo reale, rapportata sia al consumo dell intera casa, che al massimo consumo teorico nominale di ogni stanza. Quando si parla di consumo nominale, si intende il massimo consumo che la stanza potrebbe avere nel caso in cui tutti i dispositivi connessi (o quelli che potrebbero essere utilizzati in quella stanza), fossero attivi e consumassero il loro massimo consumo nominale. Il forno ad esempio (Electrical Oven in tabella 4.1) ha un consumo nominale di 2200W; questo non significa che se lo accendiamo debba assorbire tutti 2200W, dipende ad esempio da quanti 41

47 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ gradi vogliamo che raggiunga, ma per calcolare la frazione di potenza assorbita dalla cucina rispetto a tutte le altre, F(cucina), verrà considerato questo valore. Tabella 4.1: Consumi nominali dispositivi gestiti da Dog Stanza Dispositivo Consumo nominale Kitchen Electric oven 2200W Microwave oven 700W Fridge 150W Neon lamp 11W Dishwasher 1200W Coffee maker 1000W TV 60W Bathroom Washing machine 2250W Lamp 15W Living room Stereo 80W Lamp 15W DVD Reader 20W TV 60W Lobby Lamp 15W Bedroom Ceiling lamp 80W Alarm Clock 7W Notebook 70W La formula per calcolare questa frazione per ogni stanza, risulta essere la seguente: d D F (r) = f (r) P D(d) d D P, D(d) dove r indica la stanza che si sta considerando per il calcalo; al numeratore troviamo la sommatoria di tutte le potenze nominali dei dispositivi d appartenenti a D f (r), cioè all insieme dei dispositivi installati in r, mentre al denominatore abbiamo la sommatoria delle potenze nominali di tutti i decive d D, con D insieme di tutti i dispositivi presenti in casa. Ad ogni stanza viene quindi assegnata una parte della massima potenza P R (r), ottenuta moltiplicando la potenza massima della casa P M per le 42

48 4.2. SCELTE PROGETTUALI E FUNZIONALITÀ frazioni precedentemente calcolate: P R (r) = P M F r A runtime quindi a ogni stanza viene assegnato un colore (verde, giallo o rosso) in base al rapporto fra il consumo attuale della stanza P A (r) e la quota massima di potenza per ogni stanza P R (r); il colore assegnato dipenderà dal valore di questo rapporto, secondo i seguenti valori di soglia: P A (r) P R (r) [0, α), verde [α, β), giallo [β, 1], rosso Per scelta progettuale la soglia inferiore di α è impostata a 0.1, mentre quella superiore di β a 0.9, secondo la seguente relazione: 0.1 α < β 0.9, inoltre la differenza minima fra le due soglie è impostata a 0.1. I valori α e β sono anche utilizzati per determinare il colore dell indicatore visivo di consumo associato ad ogni dispositivo, seguendo la stessa suddivisione a soglie, ma considerando il rapporto P A(d), dove P P N (d) A(d) è il consumo attuale del dispositivo d, e P N (d) è la potenza nominale dello stesso. Tutte le indicazioni numeriche dei consumi presenti nell applicazione, seguono le regole di gestione della colorazione appena esposte, differenti quindi per stanze e dispositivi. Come si è già detto α e β presentano dei valori di default di 0.4 e 0.8 rispettivamente, tuttavia tramite gli slider presenti nella finestra delle impostazioni, osservabili in figura 4.7, è possibile modificare questi valori, dando la possibilità all utente di modificare le soglie con cui avvengono le assegnazioni dei colori Visualizzazione allarme Un altra caratteristica di cui è bene illustrare la funzionalità, è la visualizzazione di un allarme visivo nel caso in cui esista almeno un dispositivo in casa, non attivo, il cui valore di potenza nominale, sommato al consumo attuale di tutta l abitazione, superi la potenza massima consentita. Il programma infatti, ogni qual volta arriva una notifica di potenza da Dog, verifica fra tutti i dispositivi non attivi, che la somma dei due valori non superi al soglia di 43

49 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE potenza della casa; se ne viene trovato almeno uno, il software inizia a creare una lista di tutti questi dispositivi, facilmente visualizzabile premendo sul pulsante di avviso che viene mostrato sotto il consumo totale della casa nella schermata principale, come è possibile vedere in figura 4.3. Lo scopo di questo avviso quindi, è quello di dare all utente l informazione di essere in pericolo di disattivazione del contatore energetico, che è quello che avverrebbe, infatti, se si accendesse uno dei dispositivi mostrati nella lista, come mostrato in figura 4.8. Figura 4.8: Lista dispositivi da non accendere 4.3 Realizzazione dell interfaccia utente Dopo aver descritto le principali funzionalità dell applicazione sviluppata, si vuole spostare l attenzione sulla realizzazione dell interfaccia utente. Come è stato già detto, con Android si ha una separazione netta, quasi totale, fra la parte logica e quella grafica. Infatti, mentre la parte algoritmica viene implementata in Java, la realizzazione dell interfaccia avviene tramite codice XML, o quantomeno è quello che accade per le parti statiche di un applica- 44

50 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE zione. In wattsup, come in molti altri software, sono presenti spesso elementi fissi che non dovranno subire cambiamenti durante l uso dell applicazione stessa; tale immutabilità li rende i soggetti ideali per essere descritti per mezzo di codice XML. Ma per altri elementi grafici dell applicazione sarebbe impossibile una gestione statica, in quanto renderebbe l app stessa inutilizzabile nel caso in cui la descrizione della casa, il numero di stanze o dei dispositivi, variasse nel corso del tempo, o se l applicazione venisse usata in un diverso contesto domotico La disposizione delle stanze Prendiamo ad esempio proprio il numero di stanze presenti nell interfaccia principale di wattsup, mostrato in figura 4.2. Tale numero, in questo caso sei, è determinato a runtime e si ottiene dalla configurazione iniziale dell abitazione, richiesta a Dog in fase di connessione e quindi variabile in base all ambiente controllato. La disposizione delle camere quindi avviene per mezzo di un algoritmo appositamente elaborato, che permette di inserire nello porzione dedicata dello schermo, un numero qualsiasi di stanze, in modo da ottenere un risultato sempre gradevole e bilanciato. In figura 4.9 possiamo osservare quattro esempi di disposizione delle stanze, variando solo il numero di stanze qrooms passato al metodo paintrooms(). In questo caso quindi abbiamo variato manualmente il valore di qrooms, ma nella realtà questo viene ricavato automaticamente dalla descrizione dell ambiente controllato ricevuto da Dog, insieme ad altre informazioni, quali nome della stanza, dispositivi presenti all interno, ecc. A seguire alcune porzioni di codice del metodo paintrooms(), contenenti le righe essenziali per il calcolo della disposizione delle stanze: int qrooms = myhome.size(); int nrows = 1; while (((float) qrooms / (float) nrows) > nrows) { nrows++; } //number of rooms for each row int quoz = (int) (qrooms / nrows); //rows with one more room int mod = qrooms % nrows; 45

51 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE (a) qrooms = 4 (b) qrooms = 8 (c) qrooms = 10 (d) qrooms = 13 Figura 4.9: Esempio disposizione automatica stanze Si parte assegnando a qrooms la dimensione di myhome, che è la struttura dati contenente la descrizione dell intera abitazione. Successivamente si crea la variabile nrows inizializzandone il valore a 1. Quindi per mezzo di un ciclo while, si itera l operazione di incremento del valore di nrows, fintanto che il valore del rapporto qrooms continua ad essere maggiore di nrows stesso. Non nrows appena questa diseguaglianza non è più verificata, si esce dal ciclo. Dopodichè si calcolano il quoziente quoz ed il modulo mod, del rapporto menzionato, che rappresenteranno rispettivamente il numero di stanze per ogni riga, e il numero di righe che dovranno avere una stanza in più rispetto alle altre righe. Cerchiamo di chiarire il concetto illustrato con un esempio numerico: se si hanno per esempio 10 stanze, quindi qrooms = 10, avremo che nrows risulterà essere 4, mentre quoz e mod avranno rispettivamente i valori 2 e 2. Ciò significa che avremo mod righe con quoz + 1 stanze (2 righe con 3 stanze nell esempio) e le rimanenti righe con quoz stanze, cioè 2, come mostrato anche in figura 4.9(c). Definita quindi la disposizione delle camere, per mezzo di altri controlli vengono assegnati colore, nome e bordo esterno per ogni stanza. La scelta infatti 46

52 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE di fornire un bordo arrotondato per le stanze situate negli angoli della schermata, ha comportato uno sforzo notevole nell implementazione del codice. Nella fase di disegno di ogni stanza infatti, se ne controlla la posizione (laterale sinistra o destra, centrale, bordo superiore o inferiore) per mezzo di variabili d appoggio, collegate ai valori trovati precedentemente. Bisogna ricordare che non conosciamo a prescindere il numero di stanze, tantomeno il consumo, quindi sarebbe impossibile un assegnazione statica del contorno presente per ogni stanza. Sono stati descritte quindi tutte le tipologie di stanze possibili, per mezzo del linguaggio XML, con le diverse colorazioni ammesse, e poi assegnati dinamicamente durante la fase di creazione della disposizione delle camere. A seguire un esempio di codice riguardante la rappresentazione di una stanza, nello specifico shape_room_topl_amber.xml shape_room prefisso comune a tutte le descrizioni di stanze; topl indica la stanza in alto a sinistra; amber indica che è la descrizione per una stanza gialla. <?xml version="1.0" encoding="utf-8"?> <layer-list xmlns:android= " > <item> <shape android:shape="rectangle" > <stroke android:width="5dp" android:color="@color/strokecolor" /> <solid android:color="@color/amberroom"/> <corners android:bottomleftradius="0dp" android:bottomrightradius="0dp" android:topleftradius="10dp" android:toprightradius="0dp" /> </shape> </item> </layer-list> 47

53 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE Visualizzazione delle stanze Dopo aver parlato dell implementazione della struttura della casa, si spenderà qualche parola per descrivere come vengono rappresentate le stanze al loro interno. Si è già detto come ogni stanza sia suddivisa in quattro aree, osservabile in figura 4.5: 1. dispositivi; 2. riepilogo consumi; 3. grafico situazione energetica della casa; 4. comandi dispositivi. La prima parte, dove vengono rappresentati i dispositivi è realizzata mediante una gridview. La gridview è un elemento grafico di Android, che permette di visualizzare degli oggetti in una griglia bidimensionale scorribile. Ogni volta che si fà accesso ad una camera, il metodo contenente il codice atto a popolare tale gridview, riceve in ingresso la lista dei dispositivi presenti in quella stanza, e la trasforma in una rappresentazione in griglia, suddividendola quindi in righe e colonne. Il numero di colonne dipende dalla grandezza dell aria dedicata alla gridview stessa e alla dimensione del layout rappresentante ogni dispositivo, mentre il numero di righe chiaramente dipende da quante colonne si riesce a inserire per ogni riga. Nel caso in cui dovessero esserci un numero di dispositivi, tali da non rientrare nello spazio dedicato, la gridview fornisce già un controllo di scrolling per visualizzare così un numero di oggetti indipendente dalla grandezza del area di visualizzazione dedicata. Ogni dispositivo quindi viene rappresentato mediante un layout fisso, creato appositamente per dare le informazioni necessarie. Questo layout contiene: un icona rappresentante il dispositivo, categorizzato per tipologia e localizzata all interno dell applicazione; nel caso in cui un nuovo dispositivo di una tipologia sconosciuta venisse aggiunto alla descrizione della casa, questo verrà rappresentato mediante un icona standard, fornita appositamente per questo tipo di evenienze; un campo di testo mediante il quale viene visualizzato il nome del dispositivo; un indicatore di consumo gestito sempre tramite l alternarsi dei colori verde, giallo e rosso secondo la metodologia di calcolo già approfondita. 48

54 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE (a) device riconosciuto (b) device selezionato (c) device sconosciuto Figura 4.10: Differenti rappresentazioni device In figura 4.10 possiamo osservare alcuni esempi di rappresentazione e gestione dei device noti e nel dettaglio 4.10(c), cosa accade se il device è di un tipo non riconosciuto dall applicazione. Per quanto riguarda invece l area della finestra dedicata al grafico dei consumi, inizialmente si era ingrato un servizio web based, Google Chart Editor Beta 1. Per mezzo di un url generato ad hoc, che integrava i consumi e i dati di cui si voleva ottenere il grafico, si effettuavano delle richieste http, che come risposta fornivano il grafico sotto forma di immagine. Nonostante il risultato fosse molto gradevole, questa soluzione è stata scartata per più di un motivo: in primo luogo necessitava di Internet, ma non si voleva che l applicazione avesse questo vincolo progettuale; inoltre bisognava mandare una richiesta per un nuovo grafico ogni qual volta avveniva un cambiamento energetico. Considerando poi che il servizio è in fase Beta, quindi passibile di annullamento del progetto stesso, si è optato per creare dei metodi personalizzati per la gestione della visualizzazione mediante un grafico dei consumi. Il risultato, osservabile in figura, mostra per mezzo di un animazione a comparsa orizzontale delle barre, da sinistra verso destra, i consumi energetici della stanza in analisi, la somma dei consumi delle altre stanze, ed il totale della casa. Ogni volta che una notifica energetica arriva all applicazione, anche il grafico viene automaticamente aggiornato. Il metodo che gestisce la creazione si chiama getgraph(), mentre quello che si cura dell aggiornamento in caso di variazioni dei consumi è updategraph(). Entrambe i metodi non fanno altro che calcolare dei valori di iniziali e finali da dove far deve partire e arrivare il grafico per creare l animazione, rappor- 1 Google Chart Editor Beta: 49

55 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE (a) (b) Figura 4.11: Esempio variazione grafico dopo l attivazione di un dispositivo in stanza tandoli però sia allo spazio a disposizione che al valore di potenza massima. Calcolati quindi questi parametri si utilizza un terzo metodo, getanimation() per ottenere l animazione del tutto. L ultima area della stanza di cui ci occuperemo è quella riservata alla gestione dei comandi dei dispositivi. Selezionando infatti un dispositivo qualsiasi, apparirà in basso a destra un pannello informativo. Questo presenta alcuni dettagli del dispositivo selezionato, quali il tipo di sistema domotico (Elite, Konnex, ecc.), il consumo nominale e lo stato attuale del dispositivo, come mostrato in figura Sulla sinistra di questo pannello si trova un selettore, che se premuto ci porta alla visualizzazione del pannello dei comandi, differenti per ogni tipologia di dispositivo, e in alcuni casi assente se il controllo di quel dispositivo non è stato ancora implementato in Dog. (a) Informazioni device (b) Comandi device Figura 4.12: Esempio pannello informativo e di comando di due device 50

56 4.3. REALIZZAZIONE DELL INTERFACCIA UTENTE Elementi grafici Per quanto concerne quindi la raffigurazione dei comandi, come si è anche potuto notare dalle immagini precedenti, si è lavorato molto sulla personalizzazione grafica, evitando di utilizzare pulsanti, slider o qualsiasi altro elemento grafico standard fornito da Android. Si è cercato quindi di dare una sensazione di uniformità all applicazione, modificando le strutture che l SDK di Android ci fornisce quando possibile, come nel caso dello slider, o creando dei controlli ex-novo. Nelle immagini di seguito sono mostrati alcuni esempi della grafica creata e delle differenze con gli elementi standard di Android. (a) Slider personalizzato (b) Slider standard Figura 4.13: Personalizzazione slider (a) Switch personalizzato (b) Switch standard Figura 4.14: Personalizzazione switch (a) UP normale (b) UP premuto Figura 4.15: Personalizzazione pulsante UP 51

57 4.4. INTERAZIONE CON DOG Altri esempi di personalizzazione sono già stati visti nei paragrafi precedenti durante la spiegazione delle funzionalità dei pulsanti settings, info e warning. 4.4 Interazione con Dog Descritte quindi tutte le funzionalità principali e gli elementi grafici che compongono l applicazione wattsup, rimane solo da chiarire come questa comunica con il gateway domotico Dog. Figura 4.16: Ciclo di vita applicazione Android 52

58 4.4. INTERAZIONE CON DOG Le comunicazioni sono concettualmente divise in due parti: 1. connessione; 2. attesa/invio informazioni di stato. Non appena si avvia l applicazione infatti, si controlla in quale stadio del ciclo di vita si trova e se è quello inerente al primo avvio di quella sessione, si lancia l activity dedicata alla connessione. Il ciclo di vita di un applicazione Android, infatti, è composto da vari stadi, come mostrato in figura 4.16, motivo per cui si può riconoscere facilmente se l applicazione si sta avviando o se si trovava già in background per esempio. Quando si lancia wattsup, all interno del metodo oncreate() essa verifica se è il primo avvio per quella sessione e in caso affermativo lancia una seconda activity, ConnectionActivity, dedicata a stabilire una connessione con Dog, altrimenti prosegue il suo ciclo di vita normalmente. Di seguito la sezione di codice dedicata alla connessione: public final BroadcastReceiver onconnect = new BroadcastReceiver() public void onreceive(context ctxt, Intent i) { Log.d("loggingActivity", i.getaction()); if (i.getaction().equalsignorecase("connected")) { connected = true; progresstext.settext("connected..."); String[] message = {"describe_device"}; dog.sendmessage(message); progresstext.settext("getting Home description..."); } if (i.getaction().equalsignorecase("describe_device")) { progresstext.settext("parsing Data..."); String xml = dog.getxmlmessage(); try { InputStream description = new ByteArrayInputStream(xml.getBytes("UTF-8")); parser.parsexml(description);// usiamo il parser myhome = parser.getparseddata_room(); String[] message = {"consumptions"}; dog.sendmessage(message); progresstext.settext("retrieving consumptions..."); } catch (UnsupportedEncodingException e) { e.printstacktrace(); 53

59 4.4. INTERAZIONE CON DOG } } if (i.getaction().equalsignorecase("consumptions")) { progresstext.settext("parsing Data..."); String xml = dog.getxmlmessage(); try { InputStream consumptions = new ByteArrayInputStream(xml.getBytes("UTF-8")); parser.parsexmlconfiguratio(consumptions, myhome); gs.sethome(myhome); progresstext.settext("get Devices State..."); String[] message = {"state"}; dog.sendmessage(message); } catch (UnsupportedEncodingException e) { e.printstacktrace(); } } if(i.getaction().equalsignorecase("state")){ progresstext.settext("parsing Data..."); String xml = dog.getxmlmessage(); try { InputStream state = new ByteArrayInputStream(xml.getBytes("UTF-8")); parser.parsexmlstate(state, myhome); String[] message = {"notificationlistener"}; dog.sendmessage(message); progresstext.settext("set Notification Linstener..."); gs.setdoglg(dog); Intent mainactivity = new Intent(getApplicationContext(), MainActivity.class); connected = false; float totcons = 0.0f; for (int i1=0; i1<myhome.size();i1++){ for(int j=0;j<myhome.get(i1).listdevice.size();j++){ totcons = totcons + myhome.get(i1).listdevice.get(j).getinstcons(); } } if(totcons > gs.getmaxhomepower()) gs.setmaxhomepower((int)totcons+400); Editor prefseditor = prefs.edit(); prefseditor.putboolean("first_start", false); prefseditor. 54

60 4.4. INTERAZIONE CON DOG } }; putstring("server_ip_address", gs.getserverip()); prefseditor. putstring("client_ip_address", gs.getclientip()); prefseditor.putfloat("alpha", gs.getalpha()); prefseditor.putfloat("beta", gs.getbeta()); prefseditor.putint("max_power", gs.getmaxhomepower()); prefseditor.commit(); startactivity(mainactivity); progresslayout.setvisibility(view.gone); unregisterreceiver(onconnect); registered = false; gs.setfirststart(false); finish(); } catch (UnsupportedEncodingException e) { e.printstacktrace(); } } if (i.getaction().equalsignorecase("notification")) { ; } if(i.getaction().equalsignorecase("connection_error")){ String xmlmessage = i.getextras().getstring("xml"); Toast.makeText(getApplicationContext(), xmlmessage, Toast.LENGTH_LONG).show(); progresslayout.setvisibility(view.gone); unregisterreceiver(onconnect); registered = false; connected = false; showsettingspopup(); } Come si può osservare, tramite l utilizzo della classe BroadcastReceiver, si effettua lo scambio di messaggi con Dog, effettuando in ordine le richieste di: connessione descrizione dell ambiente e dei dispositivi consumi nominali stato attuale registrazione di un listener alla fine di questa sequenza di passaggi, vengono salvati tutti i dati ottenuti, si lancia nuovamente l activity principale e si distrugge quella corrente richiamando il metodo finish(). 55

61 4.4. INTERAZIONE CON DOG Nella schermata iniziale, come mostrato in figura 4.17, viene visualizzato il nome dell applicazione e l informazione sul progresso dello stato di ricezione dei dati da Dog. L ultimo passaggio effettuato prima di tornare all activity principale è sta- Figura 4.17: Schermata di connessione to quello di registrare un listener, utile per ricevere informazioni sugli stati e sui comandi da impartire ai vari dispositivi. Il listener, quindi, registrato su Dog resterà in attesa di messaggi da parte dell applicazione, come ad esempio un comando di accensione o spegnimento di un dispositivo, o qualsiasi altro messaggio di variazione di stato. Tuttavia anche l applicazione avrà il suo listener, implementato sempre tramite l utilizzo della classe BroadcastReceiver. Bisogna infatti ricordarsi che la possibiltà di comandare i dispositivi tramite l applicazione non esclude che l utente possa attivare o disattivare qualsiasi elettrodomestico manualmente. Questi comandi manuali saranno gestiti dal gateway domotico, che dovrà comunicare all applicazione l avvenuto cambiamento di stato ed energetico, motivo per cui bisogna che il software sia capace di gestire questo tipo di informazioni sia in entrata che in uscita, e questo avviene appunto tramite il codice implementato all interno del BroadcastReceiver. 56