Invio comandi leciti

Dopo la fase di inizializzazione lo stato dei sistemi risulta quello illustrato in Figura 5.5, nel quale i quattro impianti sono spenti e gli utenti non hanno ancora inviato nessun comando.

Figura 5.5: Stato dei sistemi dopo la fase di inizializzazione

In questa fase si andr´a, tramite gli opportuni comandi, ad accendere tre dei quattro impianti:

5.5. Svolgimento demo 73

“switch on Bianchi”;

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

3. l’utente SIP invia lo stesso identico comando per Verdi ottenendo cos´ı l’accensione dell’impianto e ricevendo la medesima risposta in quanto anche in questo caso il comando risulta lecito;

4. l’utente Android invia il comando “switch on Blu” che risulta ancora lecito ed ottiene a sua volta l’accensione di Blu e la ricezione del messaggio di conferma; 5. si arriva cos´ı alla condizione critica di tre impianti ac-

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

5.5. Svolgimento demo 74

5.5. Svolgimento demo 75

5.5.3 Invio comandi di subscribe

In questa fase i due utenti inviano i comandi subscribe rispettivamente:

• l’utente SIP invia il comando “subscribe Rossi” rice- vendo in risposta il messaggio “Subscribe Rossi accet- tata”;

• l’utente Android allo stesso tempo invia il comando di subscribe per la casa Bianchi ottenendo il messaggio di conferma.

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

5.5. Svolgimento demo 76

Figura 5.7: Tabella SUBSCRIBERS conseguente ai due messaggi di subscribe

5.5.4 Invio comando non lecito

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

5.5. Svolgimento demo 77

5.5.5 Uscita dalla configurazione critica

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

• l’utente SIP invia il comando “switch off Bianchi” e questo, essendo un comando non critico, viene imme- diatamente inoltrato dal DC verso il SHG di Bianchi; • l’utente SIP riceve la conferma dello spegnimento tra-

mite il messaggio “Bianchi switch off eseguito”; • l’utente Android, in quanto subscriber di quel sottosi-

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

5.5.6 Esecuzione automatica decisore

Infine, essendo ora il sistema uscito dalla configurazione critica, all’avvio automatico del decisore per il controllo periodico da parte del timer task accade che:

5.5. Svolgimento demo 78

• il decisore sommando ora i valori ricevuti dai quattro sottosistemi rivela il cambiamento e considera questa volta il comando in coda di switch on lecito;

• il DC inoltra quindi la richiesta di accensione dell’im- pianto a Rossi, arrivando cos´ı alla situazione mostrata in Figura 5.8 ;

• l’utente Android, mittente originario della richiesta, ri- ceve il messaggio di avvenuta accensione “Rossi switch on eseguito”;

• l’utente SIP, in quanto subscriber di Rossi, riceve da parte del Multicast Sender lo stesso messaggio conte- nenente la notizia che l’impianto di Rossi ´e ora acceso.

5.5. Svolgimento demo 79

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

Capitolo 6

Conclusioni

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

6. Conclusioni 81

fare riferimento e tramite quali comandi, quali interfacce offrire lato client e tramite quali applicazioni.

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

Ecco quindi alcuni sviluppi futuri da noi concepiti: • estensione ad altri protocolli di comunicazione e ad al-

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

• implementazione di decisori con algoritmi pi´u sofistica- ti (ottimizzazione consumi, risparmio energetico e sal- vaguardia dell’ambiente, sicurezza degli occupanti...) • sicurezza negli accessi sia al Domotic Coordinator che

ai singoli sottosistemi (accesso autenticato); • riservatezza dei dati (cifratura dei dati).

Bibliografia

[1] Cei: 64-8/3:2012, impianti elettrici utilizzatori a tensione nominale non superiore a 1 000 v in corrente alternata e a 1 500 v in corrente continua parte 3: Caratteristiche generali.

[2] Cen-en15232:2011, energy performance of buildings -impact of building automation, controls and building management.

[3] Ieee: 802.15.4, ieee standard for local and metropolitan area networks– part 15.4: Low-rate wireless personal area networks (lr-wpans). [4] Iso/iec: 7498-1, information tecnology - open systems interconnection -

basic reference model: The basic model.

[5] T. Berners-Lee, R. Fielding, and L. Masinter. Rfc 3986, uniform resource identifier (uri): Generic syntax, 2005.

[6] R. G. Garroppo, L. Gazzarrini, S. Giordano, and L. Tavanti. Experi- mental Evaluation of a SIP-Based Home Gateway with Multiple Wire- less Interfaces for Domotics Systems. Journal of Computer Networks and Communications, 2012:1–15, Nov. 2012. Article ID 190639.

BIBLIOGRAFIA 83

[7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. Sip: Session initiation protocol, 2002.