Gateway domótico com sistema de “messaging”
José Miguel Alfaiate Pereira
Dissertação para obtenção do Grau de Mestre em
Mestrado Bolonha em Engenharia Informática e de
Computadores – Alameda
Júri
Presidente: Prof. José Carlos Martins Delgado
Orientador: Prof. Renato Jorge Caleira Nunes
Vogais: Prof. Alberto Manuel Ramos da Cunha
Outubro 2009
Resumo
Neste trabalho é apresentado um gateway domótico dotado de uma interface de messaging,
o que possibilita a monitorização e controlo de uma habitação remotamente a partir de comuns
clientes de instant messaging. Este conceito inovador não só expande o leque de dispositivos a
partir dos quais se pode interagir com a casa, como melhora bastante a usabilidade do sistema,
na medida em que os serviços de instant messaging estão largamente disseminados e são de
fácil utilização. Além de proporcionar este tipo de interacção de forma simples e natural, o
gateway disponibiliza algumas funcionalidades que o tornam mais dinâmico e interessante.
Uma delas é a videovigilância, crucial quando a questão é a segurança. Outras funcionalidade,
que podem ser aglomeradas e intituladas de “perfis”, influenciam o comportamento do gateway
em função do utilizador. Com efeito, cada utilizador pode definir quais as ocorrências do
sistema sobre as quais deseja ser notificado, construir uma lista de favoritos para acesso mais
rápido e criar macros que desencadeiam sequências de acções. A estrutura do gateway foi
desenvolvida de forma independente das tecnologias domóticas com que comunica, o que lhe
permite apresentar uma interface comum para todas elas. Relativamente à avaliação do
sistema, foi definido um conjunto de testes funcionais que comprovam o correcto
funcionamento do gateway. Adicionalmente, foram testados o desempenho e segurança
oferecidos pelo mesmo.
Palavras-chave
Domótica, Automção de casas, Instant Messaging, Home gateway, DomoBus, Interoperação
Abstract
This paper presents a domotic gateway enabled with a messaging interface which allows
controlling and monitoring a house remotely using common instant messaging clients. Not only
this brand-new concept expands the range of devices from which one can interact with the
house but also it greatly improves the system’s usability, given that instant messaging services
are widely known and easy to use. Besides providing this type of interaction in a simple and
natural way, the gateway offers some features which make it more dynamic and interesting.
One of those, important to security, is video surveillance. Other functions make the gateway
behave accordingly to user preferences and can be clustered and named “profiles”. Indeed
each user may define the events about which he wants to be notified, build a favorites list to
speed-up access and create macros which trigger series of actions. The gateway’s structure
was developed independent from the underlying domotic technologies, resulting in a common
interface for all of them. Concerning system evaluation, a series of functional tests were defined
and proved the gateway’s functionalities. Additionally, performance and security tests were also
performed.
Keywords
Domotics, Home Automation, DomoBus, Instant Messaging, Home gateway, Interoperation
3
Índice
Pág.
1
Introdução ........................................................................................................................... 8
1.1 Objectivos do trabalho ................................................................................................... 9
1.2 Estrutura deste documento ............................................................................................ 9
2
Soluções existentes ou relacionadas ................................................................................ 10
3
Arquitectura da solução .................................................................................................... 13
3.1 Modelo do sistema domótico ....................................................................................... 16
3.2 Interface IM .................................................................................................................. 19
4
Estrutura interna da aplicação gateway ............................................................................ 25
4.1 Camada inferior ........................................................................................................... 26
4.2 Camada intermédia ...................................................................................................... 27
4.3 Camada superior ......................................................................................................... 35
4.4 Comandos e Menus ..................................................................................................... 36
4.4.1 Comandos ............................................................................................................ 37
4.4.2 Menus ................................................................................................................... 38
4.5 Estruturas de dados do Gateway ................................................................................ 40
5
Metodologia de avaliação do trabalho .............................................................................. 42
5.1 Definição de testes e casos de uso ............................................................................. 43
5.2 Resultados ................................................................................................................... 46
6
Conclusões........................................................................................................................ 52
7
Referências ....................................................................................................................... 54
4
Lista de quadros
Pág.
Quadro 1 – Comandos disponíveis no cliente IM ................................................................... 23
Quadro 2 – Tabela de operadores .......................................................................................... 30
Quadro 3 – Resultados dos testes de leitura e de escrita ...................................................... 47
Quadro 4 – Resultados dos testes de criação ........................................................................ 48
Quadro 5 – Resultados dos testes de remoção...................................................................... 49
Quadro 6 – Tempos médios de resposta do gateway para vários serviços de IM ................. 49
Quadro 7 – Respostas do gateway aos vários tipos de contactos ......................................... 50
Quadro 8 – Modo de envio de mensagens dos vários serviços de IM ................................... 50
Quadro 9 – Tempos medidos na execução dos vários casos de uso .................................... 51
5
Lista de figuras
Pág.
Figura 1 – Vista geral da arquitectura de todo o sistema ....................................................... 13
Figura 2 – Enquadramento do gateway no sistema domótico ................................................ 14
Figura 3 – Interfaces de comunicação do gateway ................................................................ 15
Figura 4 – Diagrama de classes UML para o modelo dos dispositivos domóticos. ............... 16
Figura 5 – Diagrama de classes UML dos tipos de valores para uma propriedade ............... 17
Figura 6 – Diagrama de classes UML para o modelo da estrutura da casa........................... 18
Figura 7 – Exemplo de interacção através de comandos ....................................................... 20
Figura 8 – Exemplo de interacção através de menus............................................................. 21
Figura 9 – Arquitectura geral do gateway domótico ............................................................... 25
Figura 10 – Estrutura da cache de estados de dispositivos ................................................... 27
Figura 11 – Exemplo de lista de favoritos ............................................................................... 29
Figura 12 – Estrutura dos testes para notificações ................................................................. 30
Figura 13 – Exemplo de uma notificação ................................................................................ 31
Figura 14 – Exemplo de um alarme e de uma notificação...................................................... 31
Figura 15 – Interacção “Ver filme” sem recurso à funcionalidade de macros ........................ 32
Figura 16 – Interacção “Ver filme” com recurso à utilização de uma macro .......................... 33
Figura 17 – Janela de selecção de fonte para imagem .......................................................... 34
Figura 18 – Exemplo de interacção de pedido de imagem de uma câmara .......................... 34
Figura 19 – Exemplo de verificação de um contacto .............................................................. 36
Figura 20 – Diagrama de classes UML do padrão de desenho Factory method ................... 37
Figura 21 – Diagrama de classes UML do padrão de desenho Command ............................ 38
Figura 22 – Diagrama de sequência UML de uma possível execução do menu ................... 40
Figura 23 – Estrutura do ambiente de testes utilizado............................................................ 42
Figura 24 – Diagrama UML geral de casos de uso do gateway ............................................. 45
6
Lista de abreviaturas
IM ........................................................................................................................ Instant messaging
IP ........................................................................................................................... Internet Protocol
PC ..................................................................................................................... Personal Computer
PDA ......................................................................................................... Personal digital assistant
RO .................................................................................................................................. Read Only
RW ............................................................................................................................... Read / Write
UDP ...........................................................................................................User Datagram Protocol
UML ..................................................................................................... Unified Modeling Language
WO ..................................................................................................................................Write Only
XML .................................................................................................. Extensible Markup Language
XMPP ......................................................................Extensible Messaging and Presence Protocol
7
1 Introdução
A domótica é uma área em clara expansão e com um grande potencial. Apesar disso, não se
encontra ainda integrada nas nossas casas, em geral, não fazendo parte do dia-a-dia de cada
um de nós. Isto deve-se, provavelmente, ao facto de haver várias tecnologias disponíveis,
muitas delas proprietárias, não sendo nenhuma dominante em relação a todas as outras. A
solução passa claramente por “uni-las”, oferecendo ao utilizador uma interface única,
independente da tecnologia em uso na casa. Deve ser também suficientemente dinâmica não
só para se adaptar a novas tecnologias sem que o utilizador sinta uma mudança abrupta mas
também para lidar com várias em simultâneo (numa casa devem poder coexistir várias
tecnologias, quer por a instalação ter sido faseada, quer por se ter chegado à conclusão que
uma só tecnologia não preenche totalmente os requisitos estabelecidos). Por outro lado, a
solução deve também ter em conta o utilizador alvo. Neste âmbito, inicialmente poder-se-á
considerar apenas utilizadores mais experientes no que toca à informática e electrónica, pois
serão estes os que terão maior propensão à instalação de um sistema deste tipo nas suas
casas. Contudo, olhando um pouco mais à frente no tempo, podemos ver a domótica como
uma tecnologia generalizada, presente em casas de pessoas de vários níveis sociais e com
diferentes graus / especializações de formação. Assim, torna-se pertinente desenvolver uma
interface que facilite ao máximo a interacção com a casa, utilizável por todos e, muito
importante, que não obrigue necessariamente à interacção com um computador. Uma forma de
interacção a que praticamente toda a gente está habituada e que é bastante difundida é o
conjunto dos vários serviços de instant messaging (daqui em diante, IM). Este tipo de serviços
não só é fácil de utilizar, sendo conhecido por todos, como chega à grande maioria de
dispositivos, móveis ou não – PC, PDA, telemóvel. Neste contexto, o protocolo XMPP [7] e a
tecnologia Jabber [6] têm um papel preponderante, possibilitando não só a criação de novos
serviços de IM mas também a fácil interligação entre estes e os vários já existentes.
O Extensible Messaging and Presence Protocol (XMPP) é um protocolo aberto inspirado no
XML para sistemas de IM. Dado que é um standard aberto, é possível a qualquer um utilizá-lo
para criar o seu próprio serviço de IM, correndo o seu próprio servidor onde todos os clientes
se ligam. Este protocolo é a base a partir da qual a tecnologia Jabber foi desenvolvida. Esta
tecnologia foi o grande motor para a criação de muitos clientes de IM de código aberto e com
suporte para vários protocolos, que possibilitam a criação de aplicações que interactuam com
os sistemas de IM, abrindo espaço para um novo modo de interacção através da Internet.
O trabalho aqui apresentado preenche os requisitos anteriormente descritos – interligação
entre tecnologias domóticas e facilitação na interface. Por um lado, suporta a utilização de
8
várias tecnologias, de forma indiferenciada. Por outro, o facto de ter suporte para messaging
permite controlar e monitorizar habitações de forma simples, utilizando uma vasta gama de
dispositivos que não apenas um PC (por exemplo, um telemóvel) e a partir de qualquer lugar,
local ou remoto.
1.1 Objectivos do trabalho
Este trabalho tem por objectivo o desenvolvimento de um gateway domótico com um sistema
de messaging, ou seja, um conjunto de software capaz de controlar e monitorizar
equipamentos domóticos (de várias tecnologias) através da utilização não só do próprio
software, mas também de sistemas de messaging (por exemplo, MSN, Google talk, ICQ,
Yahoo, AIM).
O software desenvolvido deverá ter as seguintes capacidades:
• Interacção com vários tipos de tecnologias domóticas (DomoBus [3] [16], X10 [12], KNX
[13], LonWorks [14], ZigBee [15] e outras), utilizando para tal a infra-estrutura de
comunicação DomoBus – existem apenas as mensagens SET, GET e Notify, que seguem
o modelo DomoBus para dispositivos (cada um tem um conjunto de propriedades cujo
valor pode ser lido ou escrito);
• Comportamento ajustável por utilizador, sendo que cada um define o seu perfil com os
aspectos mais relevantes para si;
• Videovigilância;
• Monitorização e controlo através de sistemas de IM, permitindo ao utilizador interagir com
o sistema sob a forma de digitação de comandos ou de navegação em menus.
1.2 Estrutura deste documento
No capítulo que se segue – capítulo 2 – é feita uma análise crítica e comparativa sobre
algumas soluções relacionadas com este trabalho e apresentam-se as principais tecnologias a
ele associadas. A arquitectura geral, estruturada em 3 camadas, é descrita no capítulo 3. De
seguida, os componentes de cada uma são apresentados com todo o detalhe de desenho e
também algum detalhe de implementação – capítulo 4. O gateway suporta dois métodos de
interacção com o utilizador, sendo ambos descritos de forma exaustiva e exemplificados. No
capítulo 5 é descrito o modo como o sistema foi testado tirando partido de casos de uso e de
testes funcionais, sendo apresentados os respectivos resultados. No último capítulo tecem-se
as conclusões finais.
9
2 Soluções existentes ou relacionadas
Existe algum trabalho desenvolvido nesta área, maioritariamente académico ou de
investigação. De facto, não existe um gateway domótico que cumpra com os objectivos
anteriormente enunciados e com utilização prática.
Tecnologias mais simples, como o X10, baseiam-se na simplicidade extrema de instalação e
configuração, sendo necessário apenas ligar o novo dispositivo à corrente eléctrica da casa
(numa tomada comum) e escolher qual o seu número de identificação no próprio dispositivo.
Por outro lado, tecnologias mais complexas como o EIB pressupõem uma instalação mais
complexa, com passagem de fios pela casa, e uma configuração mais técnica, sendo
necessária a intervenção de pessoal especializado. Apesar de existirem programas
desenvolvidos especificamente para algumas tecnologias, estes não cumprem a função de
gateway, nem os objectivos enunciados anteriormente: não só por serem específicos a uma
única tecnologia mas também por serem, em geral, meros “portais” para as funcionalidades já
disponibilizadas pelos próprios dispositivos, não adicionando qualquer dinamismo à casa. Por
outro lado, nenhuma delas suporta o sistema de messaging, requisito fundamental para este
trabalho.
Passando para o panorama académico, há uma série de artigos que têm sido publicados
nos últimos anos, os quais vão mais de encontro aos presentes objectivos. Exemplos são o
Domotic House Gateway [4] e o DOG: an Ontology-Powered OSGi Domotic Gateway [5].
Apesar de não contemplarem a característica do messaging, ambos são bons exemplos de
gateways domóticos que acrescentam valor ao sistema instalado na casa. De facto, esta
característica é inovadora e apesar de conceptualmente simples, pode fazer uma grande
diferença no que toca à usabilidade.
Avançando mais na análise destes dois gateways, torna-se relevante tecer algumas
considerações. Quanto ao Domotic House Gateway, revela-se um pouco limitado no que toca a
tecnologias de domótica. Apesar de suportar integração de device drivers para controlo de
qualquer dispositivo domótico, este processo é feito dispositivo a dispositivo. Isto implica o
desenvolvimento de um número grande de device drivers: para uma casa em que existam
controladores de lâmpadas e de estores tanto de X10 como EIB, por exemplo, será necessário
desenvolver 4 diferentes. Grande parte do código presente em cada um será, possivelmente,
repetido ou muito semelhante ao dos outros. Com efeito, foram desenvolvidos apenas 3 device
drivers para testar o sistema: BTicino MyHome System, porta paralela com 8 LEDs e servidor
de música (MServ). Os dois últimos, apesar de serem interessantes como características extra,
não têm muita relevância para demonstrar as capacidades do gateway; a porta paralela não
representa uma situação real nem actual e o servidor de música é uma simples aplicação que
aceita ligações num porto TCP. Por sua vez, o primeiro controla todo um conjunto de
10
dispositivos de uma dada tecnologia (BTicino), permitindo testar uma situação real. Este device
driver acaba por não ir de encontro à metodologia de desenvolvimento anteriormente
enunciada, já que controla toda uma gama de dispositivos, apesar de ter sido ainda necessário
desenvolver pequenos módulos independentes. Há que notar, contudo, que tal foi possível
devido ao facto de a tecnologia testada disponibilizar um control sub-system, que estabelece
um ponto único de comunicação com todos os dispositivos. Isto não pode, no entanto, ser
assumido para qualquer tecnologia. Um módulo presente neste gateway, não contemplado no
presente trabalho, é o rule miner. Este encarrega-se de inferir novas regras com base na
análise do registo de eventos passados. De qualquer forma, tal como é dito na secção de
resultados [4], há que ter cuidado com as regras que se permite ao sistema inferir. Por
exemplo, o sistema pode inferir que um forno deve ser ligado quando a sua porta é aberta e
novamente fechada. Apesar de útil, esta regra inferida pode também revelar-se perigosa, pois
pode dar-se o caso de uma criança colocar um objecto impróprio dentro do forno, sendo que
este se liga automaticamente, podendo provocar uma explosão. Aliando este risco ao facto de
não haver perfis de utilizadores no gateway, este módulo torna-se pouco apetecível, sendo a
alternativa do presente trabalho – perfis de utilizadores definidos pelos próprios – bastante
completa e segura. Finalmente, apesar de os resultados dos testes terem sido satisfatórios,
eles não representam interacção entre vários tipos de tecnologias domóticas, o que lhes retira
alguma importância.
O outro gateway, DOG: an Ontology-Powered OSGi Domotic Gateway, resolve o problema
das várias tecnologias, sendo necessário apenas um device driver por cada uma. Não
contempla, contudo, nenhum módulo do género do rule miner. De facto, este gateway, apesar
de muito bem estruturado em vários rings, simplifica um pouco demais. Não contempla
qualquer sistema de regras ou personalização por utilizador ou qualquer outro sistema
dinamizador. Apesar de possuir um modelo de abstracção de alto nível que lhe dá a
capacidade de criar interacções entre dispositivos de várias tecnologias, tal é apenas referido
vagamente, sem detalhes, dando a ideia de que existem capacidades por explorar ou
desenvolver. Não foram documentados quaisquer testes ao gateway, pelo que não existem
resultados para mostrar o seu funcionamento.
É também pertinente mencionar neste capítulo o trabalho referido em [3]: DomoBus. Apesar
de não se tratar de um gateway tal como os dois trabalhos anteriores, está bastante ligado ao
trabalho apresentado neste documento. De facto, o DomoBus, tal como o nome sugere, é mais
uma tecnologia, tal como as anteriormente referidas (X10, KNX e outras). O que o torna
interessante é toda a lógica em que está envolvido e a tentativa de generalização na
representação e comunicação com dispositivos, definindo-os como sendo uma série de
propriedades que podem ser lidas e escritas utilizando apenas mensagens GET e SET para
obter ou escrever valores nas ditas propriedades. A sua abordagem muito simples mas muito
flexível não é específica a nenhuma tecnologia já existente, sendo contudo facilmente
11
adaptável a qualquer uma. De facto, as mensagens definidas pelo DomoBus são intuitivamente
traduzidas para qualquer tecnologia, uma vez que representam fielmente o funcionamento de
um sistema domótico da forma mais simples possível. Por outro lado, o facto de todas as
especificações e representações serem explicitadas em XML leva a que a alteração ou adição
de novos componentes seja trivial e obrigue apenas a alterações de código pontuais. Posto
isto, o DomoBus, apesar de não resolver o problema da não existência de dominância de uma
tecnologia domótica que se instale e se torne num standard, é um passo no caminho a seguir
para interligar as várias tecnologias, estabelecendo um excelente modelo de representação e
de comunicação domótica a ser utilizado por softwares domóticos como o gateway
apresentado neste trabalho. Ainda no âmbito do DomoBus, é de referir o Módulo de
comunicações DomoBus – COMM-API [9] [10] – que implementa o respectivo modelo de
comunicação e permite desenvolver programas que funcionem de acordo com este modelo de
forma simples e despreocupada.
Concluindo esta secção, é de notar que o suporte para sistemas de messaging é algo
inovador nesta área e também que, apesar de existirem alguns trabalhos com objectivos muito
semelhantes, têm algumas falhas ou limitações que este trabalho resolve, tais como a
capacidade para lidar com várias tecnologias da forma mais simples e abstraída ou para
acrescentar dinamismo ao sistema domótico através da definição de perfis de utilizador.
12
3 Arquitectura da solução
Internet
Home gateway
Gateway domótico
Sistema domótico
Figura 1 – Vista geral da arquitectura de todo o sistema
Tomando o ponto de vista do utilizador e olhando para todo o sistema, tendo em conta a sua
funcionalidade, a arquitectura geral pode ser representada pela imagem da Figura 1. A ideia
básica consiste na utilização da internet para estabelecer a ligação entre comuns clientes de IM
e o gateway domótico, sendo que este se encontra também ligado aos dispositivos domóticos
instalados na casa. Este gateway desempenha, portanto, o papel de intermediário entre os
utilizadores e a casa, permitindo que notificações de dispositivos fluam destes até aos
13
utilizadores e que comandos fluam no sentido contrário. O gateway encontra-se instalado no
home gateway, um simples PC que pode também disponibilizar outros serviços com interesse
numa casa (por exemplo: partilha de ficheiros / multimédia). Como se pode depreender do
esquema, podem ser utilizados vários tipos não só de dispositivos – desktop, laptop, PDA mas também de sistemas de IM – MSN, Google Talk, ICQ.
Logger
Directório
Verificação
de cenários
Gateway
domótico
Aplicação DomoBus
Módulo COMMM-API
Comunicação
Pedido de endereço de aplicação
Figura 2 – Enquadramento do gateway no sistema domótico
Em termos de enquadramento, o gateway domótico situa-se na posição evidenciada na
Figura 2. Como já foi referido, o gateway é um mero intermediário, sendo que existem outras
aplicações DomoBus a correr na mesma ou noutra máquina com o intuito de gerir todo o
sistema. O directório DomoBus é uma aplicação crucial para que se possa estabelecer
comunicação entre os vários elementos. A sua utilidade será mostrada mais à frente, na
secção 4.1.
Entrando um pouco mais em detalhe, torna-se óbvia a necessidade de especificação das
duas interfaces através das quais o gateway comunica com cada tipo de interveniente do
sistema. A solução serve-se de protocolos já estabelecidos e de fácil utilização, como está
evidenciado na Figura 3. Por um lado, para estabelecer a ligação e comunicação com serviços
de IM, é utilizado o protocolo XMPP. Por outro, para a comunicação com o sistema domótico,
tira-se proveito do módulo de comunicação COMM-API. Este último simplifica e generaliza toda
a comunicação, disponibilizando, essencialmente, as funções send e receive. Toda a
responsabilidade não só de encaminhar as mensagens para o gateway correcto mas também
de oferecer alguma garantia na sua entrega fica depositada neste módulo, tornando a
programação do gateway muito mais limpa e lógica. Em relação à comunicação com os
14
serviços de IM, na prática não será usado exclusivamente o protocolo XMPP, mas sim todo o
leque de protocolos disponibilizados pelo cliente de fonte aberta utilizado. Para intermediar a
comunicação entre o gateway e os dispositivos propriamente ditos, existe um gateway por
tecnologia. Estes gateways não são abrangidos pelo âmbito do presente trabalho, podendo ser
aproveitados de trabalho já desenvolvido (integrando o módulo COMM-API) ou desenvolvidos
de raiz. É de notar que o facto de utilizar esta hierarquização de gateways torna o sistema mais
dinâmico, sendo possível ter gateways de tecnologias a correr em máquinas que não o home
gateway1.
XMPP
Gateway
domótico
COMM-API
COMM-API
COMM-API
Gateway
X10
Gateway
DomoBus
Figura 3 – Interfaces de comunicação do gateway
1
O módulo COMM-API estabelece as comunicações enviando datagramas UDP, pelo que é possível
utilizá-lo em qualquer rede IP.
15
Será necessário especificar um modelo de comunicação para cada uma das interfaces
enunciadas, o que será feito nas duas secções seguintes: 3.1 e 3.2.
3.1 Modelo do sistema domótico
Para interpretar a estrutura do sistema domótico e entender as mensagens dele proveniente,
o gateway deve acordar um modelo de representação. Esse modelo é adoptado do documento
referido em [1] e é descrito de seguida.
Figura 4 – Diagrama de classes UML para o modelo dos dispositivos domóticos.
Na Figura 4 é apresentado o diagrama de classes UML [11] que expressa como são
representados os dispositivos e suas propriedades. Como se pode perceber, esta
representação, apesar de simples, é bastante eficaz e completa. Os dispositivos estão divididos
em tipos, que são representados pela classe Tipo de dispositivo. Cada Tipo de dispositivo tem
uma designação – o Nome – que pode assumir valores como “lâmpada”, “tomada”, “motor de
estore”, “televisão” ou “motor de portão”. Associadas a cada Tipo de dispositivo, existem um ou
mais tipos de propriedades, representadas pela classe Tipo de propriedade. Os tipos de
propriedades não são específicos a um só tipo de dispositivo, podendo ser partilhados por
vários. Tipos de propriedades como intensidade-luminosa e temperatura serão muito
provavelmente utilizadas apenas por um tipo de dispositivo, respectivamente, lâmpada e
sensor-temperatura. Por outro lado, estado-ligado-desligado é um grande candidato a partilha.
Cada Tipo de propriedade, além do Nome, dispõe também de um Modo de acesso e um Tipo
de Valor. O modo de acesso especifica se o tipo de propriedade em causa pode ser apenas
lido, escrito ou ambos. Utilizando os exemplos já mencionados, faria sentido atribuir leitura-
16
escrita a estado-ligado-desligado e só-leitura a temperatura. O Tipo de valor especifica o tipo
de dados que o tipo de propriedade representa.
Para mostrar quais as possibilidades para tipos de valores, é apresentado o diagrama de
classes da Figura 5. O valor de uma propriedade pode ser do tipo Escalar, Enumerado ou
Vector. Um valor escalar pode variar entre ValorMin e ValorMax, tem as Unidades
representadas no atributo com o mesmo nome e é convertido pela Expressão2 contida na
Conversão a ele associada. Se o tipo de um valor for Enumerado, este deve ter pelo menos
dois elementos Enumerado associados a ele, cada um com a respectiva Designação e Valor.
Finalmente, valores do tipo Vector especificam apenas a Dimensão do mesmo.
Figura 5 – Diagrama de classes UML dos tipos de valores para uma propriedade
A propriedade intensidade-luminosa, por exemplo, terá um valor do tipo Escalar (inteiro),
tendo como ValorMin e ValorMax, respectivamente, 0 e 100. As Unidades desta propriedade
serão, como é óbvio, percentagem. Finalmente, dado que os valores são guardados tal como
devem ser interpretados pelo gateway, a Expressão de Conversão será apenas x. Um outro
exemplo para propriedades com valores do tipo Escalar é a temperatura. Assumindo que a
temperatura é medida com uma casa decimal de precisão e representada por um inteiro, os
seus ValorMin e ValorMax serão, por exemplo, -250 e 650, sendo as Unidades graus Celsius.
2
A Expressão de Conversão é escrita em função do valor guardado no modelo – x.
17
Consequentemente, a Expressão de Conversão será 0,1x. Caso fosse necessário converter
esta mesma representação (entre -250 e 650) para graus Fahrenheit, bastaria utilizar a
Expressão 0,1x * 9⁄5 + 32. Por outro lado, a propriedade estado-ligado-desligado tem um valor
do tipo Enumerado, tendo associados dois elementos Enumerado: um com Valor 0 e
Designação “Desligado” e outro com Valor 1 e Designação “Ligado”. O tipo de valor Vector
pode ser útil para propriedades que representem uma string (cadeia de caracteres) ou algum
tipo de informação estruturada em vários elementos.
Vendo as classes Tipo de dispositivo e Tipo de propriedade como a definição de
dispositivos, podemos ver as duas seguintes como instâncias dos mesmos. Por conseguinte, a
classe Dispositivo representa um dispositivo real no sistema, com os respectivos Nome e
Endereço3. Associadas a cada Dispositivo, existem uma ou mais propriedades – classe
Propriedade - de um certo tipo (ou seja, cada uma está associada a um e um só Tipo de
propriedade).
Cada propriedade contém apenas o Valor, com os dados por ela representados. Finalmente,
a classe Serviço visa agrupar os dispositivos com finalidades semelhantes. Ar-condicionado e
sensor-temperatura poderão pertencer ao serviço Climatização enquanto câmara-vigilância e
alarme serão incluídos no serviço Segurança. Note-se que um dispositivo pode pertencer a
vários serviços, como por exemplo um sensor de presença, que se insere tanto no serviço de
segurança, para detectar intrusos, como no serviço de iluminação, para activar a iluminação em
divisões ocupadas. Utilizar este tipo de associação pode revelar-se bastante útil, pois permite
ao utilizador aceder a todos os dispositivos de um dado serviço como, por exemplo, verificar o
estado de todos os dispositivos de segurança quando se está fora de casa durante algum
tempo.
Figura 6 – Diagrama de classes UML para o modelo da estrutura da casa
Para expressar a distribuição dos dispositivos pela casa, é utilizado o modelo representado
pelo diagrama de classes da Figura 6. Este modelo segue fielmente a estrutura de uma casa,
que está dividida em um ou mais pisos, estando cada um destes dividido em uma ou mais
divisões. Finalmente, cada uma destas divisões contém um número arbitrário de dispositivos
domóticos. Apesar de estarem fortemente ligadas à estrutura da casa, as classes Piso e
Divisão podem representar espaços lógicos diferentes, podendo os pisos dividir a casa em
3
O endereço de cada dispositivo deve ser constituído por duas partes: a primeira com a identificação da
tecnologia e a segunda com a identificação do dispositivo dentro dessa tecnologia.
18
áreas sociais e privativas - salas, entrada, casa de banho social / quartos, casas de banho
privativas - e as divisões separar uma divisão como uma sala em área de jantar e uma outra de
lazer.
3.2 Interface IM
No que toca à interface com o utilizador através de IM, são disponibilizados dois métodos de
interacção: comandos e menus. O 1º consiste, basicamente, numa linha de comandos à
distância. O 2º consiste em, em cada momento, listar todas as opções possíveis no contexto
em questão, numerando-as. Basta, portanto, ao utilizador escolher a opção desejada,
escrevendo o número correspondente. Na prática, os menus são uma forma estruturada e mais
visual de aceder às funcionalidades dos comandos. Tendo em conta que o utilizador poderá a
interagir com o gateway a partir de um dispositivo que tanto pode ser um comum PC como um
telemóvel / PDA, é dada ao utilizador a liberdade para escolher quantas opções de menu lhe
são mostradas de cada vez. Se o menu tiver mais opções do que a quantidade que o utilizador
escolheu, a última servirá de ligação para as seguintes e assim sucessivamente. Um utilizador
menos experiente poderá sempre navegar pelos menus para aceder a todas as
funcionalidades, enquanto um utilizador mais experiente poderá tirar partido da utilização de
comandos, pois já conhece bem a sintaxe de cada um, poupando o tempo de navegação nos
menus. Na Figura 7 e na Figura 8 são demonstradas, respectivamente, a utilização dos
comandos e dos menus.
19
Figura 7 – Exemplo de interacção através de comandos
20
Figura 8 – Exemplo de interacção através de menus
21
Através do cliente IM deve ser possível não só consultar e alterar (através de acções simples
ou macros) o estado de dispositivos mas também criar ou eliminar macros e editar o perfil
pessoal. Adicionalmente, deve ser disponibilizada também ajuda geral e referente à sintaxe de
cada comando.
No Quadro 1 são apresentados os comandos disponíveis, juntamente com a sua descrição e
sintaxe. Os elementos entre os sinais de maior e menor - < > - são parâmetros do comando em
causa e os elementos entre parêntesis rectos – [ ] - são opcionais. Com este conjunto de
comandos, ficam asseguradas todas as funcionalidades as quais compete ao gateway
disponibilizar.
Alguns parâmetros de alguns comandos necessitam de uma especificação adicional, o que
será feito de seguida.
O comando list aceita para o argumento tipo os seguintes valores:
• macro – para listar os nomes de todas as macros
• device – para listar os nomes de todos os dispositivos
• F:<piso> - para listar os nomes de todos os dispositivos pertencentes ao piso indicado
em <piso>
• D:<divisão> - para listar os nomes de todos os dispositivos pertencentes à divisão
indicada em <divisão>
• S:<serviço> - para listar os nomes de todos os dispositivos pertencentes ao serviço
indicado em <serviço>
Para o argumento especificação, os valores aceites dependem do valor passado em tipo, de
acordo com o que se segue: quando é passado macro para o argumento tipo, a especificação
é o nome de uma macro, sendo o resultado do comando a listagem de todas as acções que
constituem a macro indicada; caso contrário, a especificação é um tipo de dispositivo, refinando
a listagem de nomes de dispositivos aos do tipo indicado.
O parâmetro acesso do comando createmacro visa definir o tipo de acesso que a macro a
ser criada terá e aceita apenas dois valores: P (private – privado) ou S (shared – partilhado).
Uma macro privada será visível apenas para o utilizador que a criou enquanto uma macro
partilhada será visível para todos os utilizadores. Cada uma das acções (<acção 1> … <acção
n>) representa uma acção da macro, sendo da forma:
<nome> <comando set>
Em <nome> deve ser passado o nome da acção enquanto em <comando set> é passado
um normal comando set.
22
Comando
Sintaxe
Descrição
help / ?
help|? [<comando>]
menu
list
menu
list <tipo>
[<especificação>]
get
get <dispositivo>
[<propriedade>]
set
set <dispositivo>
<propriedade> <valor>
run
createmacro
run <macro>
createmacro <nome>
<acesso> <acção 1> …
<acção n>
alarm <entidade>
[<propriedade>
[<operador> <valor>]]
notify <entidade>
[<propriedade>
[<operador> <valor>]]
addfavourite <entidade>
Fornece ajuda geral ou da sintaxe do
comando indicado em <comando>, caso
seja fornecido
Iniciar / mostrar menu
Lista todas as instâncias do tipo indicado
em <tipo>, restringindo à especificação
indicada em <especificação>, caso seja
fornecida
Lista os valores de todas as propriedades
do dispositivo indicado em <dispositivo> ou
apenas o valor da propriedade indicada em
<propriedade>, caso seja fornecida
Escreve na propriedade indicada em
<propriedade> do dispositivo indicado em
<dispositivo> o valor indicado em <valor>
Corre a macro indicada em < macro>
Cria uma nova macro com o nome
indicado em <nome> e acções indicadas
em <acção 1> … <acção n>
Regista o interesse no alarme especificado
pelos parâmetros indicados
alarm
notify
addfavourite
removemacro
removealarm
removenotification
removefavourite
camera
removemacro <macro>
removealarm <entidade>
[<propriedade>
[<operador> <valor>]]
removenotification
<entidade> [<propriedade>
[<operador> <valor>]]
removefavourite
<entidade>
camera <câmara>
Regista o interesse na notificação
especificada pelos parâmetros indicados
Adiciona a entidade indicada em
<entidade> aos favoritos
Elimina a macro indicada em <macro>
Elimina o interesse no alarme especificado
pelos parâmetros indicados
Elimina o interesse na notificação
especificada pelos parâmetros indicados
Elimina dos favoritos a entidade indicada
em <entidade>
Pede uma imagem da câmara indicada em
<câmara>
Quadro 1 – Comandos disponíveis no cliente IM
Os comandos alarm e notify criam interesses, respectivamente, em alarmes e notificações e
têm a mesma sintaxe. Em ambos, o parâmetro entidade se refere à entidade-alvo do alarme ou
notificação e pode assumir os seguintes valores:
• <dispositivo> - o alvo é o dispositivo indicado em <dispositivo>
• T:<tipo de dispositivo> - os alvos são todos os dispositivos do tipo indicado em <tipo de
dispositivo>
• P:<piso> - os alvos são todos os dispositivos pertencentes ao piso indicado em <piso>
23
• D:<divisão> - os alvos são todos os dispositivos pertencentes à divisão indicada em
<divisão>
• S:<serviço> - os alvos são todos os dispositivos pertencentes ao serviço indicado em
<serviço>
Se for indicado apenas o parâmetro entidade, o alarme ou notificação será accionado
sempre que um qualquer novo valor chegar para qualquer uma das propriedades de qualquer
um dos alvos. Para um comportamento mais específico, poderá ser passado, para o caso de a
entidade ser um dispositivo ou um tipo de dispositivo, o parâmetro propriedade e,
opcionalmente, os parâmetros operador e valor. No caso de ser indicada uma propriedade, o
alarme ou notificação só será accionado para novos valores dessa propriedade e, caso o
operador e valor sejam indicados, se passar o teste:
<novo valor> operador valor
O comando addfavourite aceita para o seu parâmetro entidade os seguintes valores:
• <dispositivo> - o dispositivo indicado em <dispositivo> é adicionado à lista de favoritos
• D:<divisão> - a divisão indicada em <divisão> é adicionada à lista de favoritos
• M:<macro> - a macro indicada em <macro> é adicionada à lista de favoritos
Os comandos removealarm, removenotification e removefavourite funcionam de forma
análoga, respectivamente, aos comandos registeralarm, registernotification e addfavourite, mas
eliminando as respectivas entidades (caso existam) em vez de as criar.
Finda esta aproximação mais abrangente ao sistema, é detalhada a estrutura interna da
aplicação gateway no capítulo seguinte – 4.
24
4 Estrutura interna da aplicação gateway
O gateway domótico é constituído por 3 camadas, cada uma responsável por tarefas
diferentes, tal como se pode ver na Figura 9.
Gateway domótico
Cliente Jabber alterado
Reencaminhamento de mensagens
Contactos registados
Validação e interpretação de comandos
Modelo do
sistema domótico
Lógica / execução de comandos
Macros
Perfis de
utilizadores
Videovigilância
Interacção com dispositivos domóticos
Cache de estados de dispositivos
COMM-API
Camada
Componente
Sub-componente
Recurso externo
Figura 9 – Arquitectura geral do gateway domótico
A camada inferior trata de toda a comunicação com os dispositivos domóticos dos vários
tipos. Para efectivamente comunicar com um dispositivo, esta camada utiliza o módulo COMMAPI, que permite que a comunicação seja independente do tipo de tecnologia a que cada
dispositivo pertence.
A camada intermédia é responsável pela lógica da aplicação, interpretando os comandos
vindos da camada superior e encaminhando-os para a inferior mas também fazendo chegar as
notificações da camada inferior à superior. É esta a camada responsável por manter não só as
preferências dos utilizadores sob a forma de perfis, mas também a representação da casa,
25
organizada por pisos, divisões e dispositivos. O modelo para a representação do sistema
domótico e seu comportamento segue, como já foi dito, o do documento referido em [1].
Finalmente, é também na camada intermédia que são oferecidas as funcionalidades de
macros, que permitem a execução sequencial de várias acções, e de videovigilância.
Por último, a camada de topo é a que suporta a interacção com sistemas de IM, consistindo
num cliente Jabber alterado. As mensagens recebidas, em vez de apresentadas na interface
gráfica, devem ser passadas à camada de baixo para validação e interpretação do comando.
Além disso, as mensagens a enviar devem ser recebidas uma vez mais, não pela interface
gráfica, mas sim pela camada de baixo.
De seguida são detalhados os vários componentes de cada uma das camadas nas secções
4.1, 4.2 e 4.3.
4.1 Camada inferior
O módulo COMM-API, como já foi referido, abstrai a comunicação com o sistema domótico,
encarregando-se de encaminhar as mensagens para os dispositivos correctamente.
Representa, portanto, o componente do gateway que está mais próximo conceptualmente do
sistema domótico. Para traduzir o endereço DomoBus do dispositivo num endereço de rede
(endereço IP + porto) utilizável para comunicação, contacta o serviço de directório DomoBus.
Os endereços DomoBus são estruturados, tendo uma primeira parte identificadora da
tecnologia e uma segunda identificadora do dispositivo dentro da tecnologia. Na realidade, a
primeira parte do endereço representa o endereço de uma aplicação DomoBus, que pode ser,
ou não, um gateway de uma dada tecnologia. Um exemplo de uma aplicação DomoBus que
não é um gateway de tecnologia é uma aplicação que regista o histórico das mensagens
trocadas no sistema (logger). O directório DomoBus extrai a parte do endereço identificadora
da aplicação e utiliza-a para indexar a sua tabela interna de associações entre endereços
DomoBus e endereços de rede. O resultado é devolvido ao módulo COMM-API requerente,
que estabelece a comunicação directamente com a aplicação destino.
O componente principal, interacção com dispositivos domóticos, processa toda a
comunicação de alto nível (indiferenciada por tecnologia) com os dispositivos domóticos
instalados na casa, servindo-se para tal do módulo COMM-API. Além disso, é responsável por
garantir o funcionamento do sistema de notificações. Este sistema informa os utilizadores da
alteração de estados de dispositivos com interesse registado. Os interesses podem ser
registados em duas variantes: notificação ou alarme. Apesar de apresentarem comportamentos
diferentes, neste componente são tratados de igual modo. Assume-se que os gateways de
tecnologias têm a capacidade de reportar alterações no estado dos dispositivos sem terem que
26
ser necessariamente interrogados. Neste âmbito, torna-se útil a cache de estados de
dispositivos, já que é garantido que o estado de um dispositivo permanece igual até à
chegada de nova mensagem de notificação. Assim, pode-se usar esta cache aquando de uma
consulta de estado por parte da camada superior, diminuindo o tráfego entre dispositivos
domóticos. Quando uma mensagem de notificação chega, o estado do dispositivo em causa é
actualizado na cache e, pedindo para tal à camada superior, são notificados os utilizadores
cujos interesses em notificações passam a estar activos. Mais à frente será detalhado o
funcionamento do sistema de notificações. A estrutura básica da cache pode ser consultada na
Figura 10 e conta com uma entrada por cada propriedade de cada dispositivo. Contém
identificadores para o dispositivo e sua propriedade, o valor associado e também uma lista de
estruturas contendo informação sobre os interesses em notificações de utilizadores referentes
à propriedade em causa.
Dispositivo
Propriedade
Valor
Luz da sala
estado-ligado-desligado
1
Luz da sala
intensidade
75
…
…
…
Testes
…
Teste
1
Teste
n
Teste
1
Teste
n
Figura 10 – Estrutura da cache de estados de dispositivos
Esta é uma representação conceptual da cache, sendo que, na realidade, será criado em
run-time um objecto por cada dispositivo domótico ao qual estarão associadas todas as suas
propriedades, com os respectivos valores armazenados. As estruturas de dados do gateway
serão descritas mais à frente, na secção 4.5.
4.2 Camada intermédia
Esta é a camada que atribui ao gateway o funcionamento que dele esperamos. Estabelece a
ligação entre a camada superior – que comunica com os utilizadores – e a inferior – que
comunica com o sistema domótico.
A validação e interpretação de comandos toma lugar sempre que os mesmos chegam de
qualquer uma das interfaces disponíveis. Apesar de apenas ser planeada a utilização de
clientes de messaging como interface para o gateway, é possível desenvolver uma linha de
comandos ou mesmo uma interface gráfica. Todas as possíveis interfaces devem, contudo,
estar sujeitas ao mesmo módulo de validação. Assim, por exemplo, a validação sintáctica é
processada para comandos provenientes de uma linha de comandos ou de um cliente de
messaging. Por sua vez, a validação semântica é processada para comandos provenientes de
27
qualquer fonte, porque, mesmo que o comando tenha uma sintaxe correcta, pode estar
semanticamente errado, tentando, por exemplo, atribuir um valor inválido a uma propriedade de
um dispositivo. Na realidade, a interface IM suporta um outro modo de interacção – menus – já
referido e descrito mais à frente, que também está sujeito apenas à validação semântica. Após
a validação terminar com sucesso, o pedido de execução da acção correspondente é passada
ao módulo que se segue.
O módulo lógica / execução de comandos é o centro da funcionalidade do gateway
domótico. Desencadeia as acções necessárias de acordo com os pedidos recebidos, quer
alterando o estado de um dispositivo quando solicitado pelo utilizador quer notificando os
utilizadores interessados de uma alteração de estado recebida. Além desta tarefa mais óbvia,
este módulo está ainda encarregue de mais 4 tarefas - manter o modelo do sistema domótico,
manter os perfis dos utilizadores, oferecer a funcionalidade de macros e oferecer a
funcionalidade de videovigilância – que são descritas em maior detalhe de seguida.
No arranque da aplicação, é responsabilidade desta camada carregar toda a configuração
da habitação de acordo com o modelo do sistema domótico, que já foi descrito no capítulo
anterior. Para armazenar os dados em memória, são instanciadas as estruturas descritas na
secção 4.5 referentes às entidades em causa.
Também os perfis de utilizadores são carregados no arranque, sendo utilizadas para
armazenamento estruturas que são definidas na mesma secção. Por cada utilizador, é
guardado um conjunto de informação que é constituído por quatro listas: favoritos, macros
privadas, interesses em notificações e interesses em alarmes.
Os favoritos de cada utilizador contemplam os dispositivos, divisões e macros que este
tenha escolhido para acesso mais rápido e frequente e estão-lhe acessíveis a partir de uma
opção do menu principal. Na Figura 11 é ilustrado um exemplo da referida lista.
As macros podem pertencer ao perfil de um utilizador na medida em que, quando um
utilizador cria uma nova macro, pode escolher se a quer partilhar ou não com os outros
utilizadores. Caso escolha não partilhar, a macro será considerada privada e apenas o
utilizador que a criou lhe terá acesso, pertencendo assim ao seu perfil.
Finalmente, os interesses em notificações e em alarmes representam o interesse do
utilizador em ser informado de uma dada alteração no sistema domótico. Apesar de serem
definidos da mesma forma, apresentam comportamentos diferentes. Uma notificação é enviada
aos contactos do utilizador que estejam online; caso nenhum esteja, nada acontece. Por outro
lado, um alarme representa um acontecimento algo grave, pelo que, caso nenhum contacto
esteja online, é enviado um email com a informação do alarme para o endereço do utilizador.
Adicionalmente, o alarme é guardado e apresentado quando algum contacto passar a estar
28
online. Cada interesse pode referir-se a um serviço, piso, divisão, tipo de dispositivo ou
dispositivo concreto.
Figura 11 – Exemplo de lista de favoritos
Nestes dois últimos casos pode ainda ser especificada a propriedade com interesse e uma
condição. Quando a aplicação é iniciada, todos os dados de perfis de utilizador são
carregados. Na prática, os interesses em notificações e alarmes são inseridos na cache
mantida pela camada inferior, como foi já ilustrado na secção anterior. Cada interesse é
inserido na cache sob a forma de um teste, que tem a estrutura simples evidenciada na Figura
12. Deverá ser possível notificar um utilizador apenas quando a propriedade com interesse
29
atingir um certo valor, pelo que os únicos dados guardados são um identificador de um
operador, um valor para comparação e o identificador do utilizador a notificar. Quando o valor
de uma propriedade é alterado na cache, devem ser corridos todos os testes associados a
essa propriedade, notificando os utilizadores referidos nos que passarem, utilizando para tal a
camada acima.
Valor
Significado
0
=
1
≠
2
>
3
≥
Operador
4
<
Valor para comparação
5
≤
Utilizador a notificar
6
* (any)
Figura 12 – Estrutura dos testes para
notificações
Quadro 2 – Tabela de operadores
No Quadro 2 é apresentada uma tabela com os significados dos vários valores do campo
operador. O operador * (any) faz com que o teste passe para qualquer valor presente na cache
e qualquer valor para comparação. Todos os interesses em dispositivos concretos terão um
mapeamento directo para um teste na cache, enquanto para os restantes será necessário criar
testes para todos os dispositivos abrangidos, utilizando o operador * (o valor para comparação
é indiferente) quando não houver condição. Com esta especificação, torna-se simples definir
notificações e alarmes que representam interesses condicionais em propriedades de
dispositivos. Tomemos o seguinte exemplo: um utilizador define que quer receber uma
notificação quando a temperatura de uma dada sala for igual ou superior a 25ºC e um alarme
quando for igual ou superior a 30ºC. Para a situação deste exemplo, serão criadas duas
estruturas de teste, uma para a notificação e outra para o alarme. Ambas se referem ao mesmo
utilizador e utilizam para comparação o mesmo operador, logo, terão a mesma referência de
utilizador e mesmo operador – ≥ / 3. Quanto ao campo “valor para comparação”, o teste da
notificação terá, obviamente, o valor 25 enquanto o teste para o alarme terá o valor 30. A
alteração da referida temperatura para 26.4ºC e 32.1ºC resulta, respectivamente, nos avisos
mostrados na Figura 13 e na Figura 14.
30
Figura 13 – Exemplo de uma notificação
Figura 14 – Exemplo de um alarme e de uma notificação
Para o valor 32.1ºC, tanto a notificação como o alarme são gerados, uma vez que ambos
são activados por este valor.
31
As macros facilitam bastante a tarefa de colocar a casa ou mesmo uma divisão num certo
estado. São constituídas por sequências de acções simples, representando cada uma dessas
acções a atribuição de um valor a uma propriedade de um dispositivo. É muito mais simples,
por exemplo, invocar a macro Ver filme, que liga a televisão, baixa os estores a 25% e deixa
apenas uma luz acesa, a 25%, do que colocar manualmente todos estes valores nas
propriedades dos respectivos dispositivos. As diferentes sequências de interacção são
mostradas na Figura 15 e na Figura 16.
Figura 15 – Interacção “Ver filme” sem recurso à funcionalidade de macros
32
Figura 16 – Interacção “Ver filme” com recurso à utilização de uma macro
Para capacitar o gateway de realizar videovigilância, foi criado o componente com o
mesmo nome. É da sua responsabilidade, perante um pedido de envio de imagem, contactar a
câmara em causa, obter uma imagem e enviá-la. Na prática, este componente foi desenvolvido
com o principal intuito de testar o funcionamento do gateway, sendo que não obtém as
imagens de câmaras reais.
Como se pode ver na Figura 17, sempre que lhe é pedida uma imagem de uma qualquer
câmara, disponibiliza, no gateway, uma interface gráfica para selecção de um ficheiro de
imagem ou obtenção de uma imagem a partir de uma das câmaras que eventualmente esteja
directamente ligada ao home gateway – máquina onde está a correr a aplicação gateway.
Na Figura 18 é mostrado um exemplo de interacção de pedido de imagem de uma câmara.
Como se pode constatar, a imagem é enviada servindo-se dos mecanismos para envio de
ficheiros já presentes nos clientes de IM.
O tipo de comunicação necessário para efectivamente obter imagens a partir de câmaras do
sistema domótico não encaixa no modelo de comunicação DomoBus e, portanto, teria que ser
feito à sua margem, utilizando métodos alternativos que as câmaras disponibilizam.
Não só seria impossível fazê-lo sem acesso aos dispositivos reais como não acrescentaria
muito interesse no que toca ao âmbito deste trabalho, que se baseia em toda a lógica
DomoBus. Mesmo assim, será possível constatar um comportamento mínimo simulado de
videovigilância, podendo-se obter imagens de qualquer uma das câmaras virtuais.
33
Figura 17 – Janela de selecção de fonte para imagem
Figura 18 – Exemplo de interacção de pedido de imagem de uma câmara
34
No futuro poderá ser explorada a possibilidade de incluir no DomoBus funcionalidades de
streaming, que suportarão a transferência de vídeo, imagens ou áudio. Com tais
funcionalidades, seria interessante explorar a videoconferência com os clientes de IM que o
suportem, o que, no entanto, não é abrangido por este trabalho.
4.3 Camada superior
Esta camada serve o objectivo de tornar o gateway usável a partir de serviços de IM. Como
tal, consiste apenas num cliente Jabber alterado. Foi então escolhido um cliente com código
de fonte aberta para que se pudesse utilizar e alterar o seu código livremente. Após alguma
pesquisa, o cliente Miranda IM [8] foi seleccionado pela sua completude em termos de
protocolos suportados e aparente robustez e estabilidade denotados pelos seus 8 anos de
existência com lançamentos de novas versões periodicamente. A modificação necessária
consiste em redireccionar a entrada e saída de mensagens. Para tal, é utilizado o componente
reencaminhamento de mensagens, que actua como a pessoa que habitualmente estaria a ler
e escrever. Todas as mensagens chegadas ao cliente Jabber deverão ser passadas ao módulo
de reencaminhamento em vez de apresentadas na interface gráfica. Este, por sua vez, deve
passar a informação à camada inferior, indicando qual o utilizador que originou a mensagem.
Deve também estar à escuta de mensagens que essa mesma camada lhe transmita,
juntamente com o utilizador a ser informado, para desempenhar de seguida o papel do teclado
ao enviar a mensagem para o utilizador pretendido.
Dado que cada utilizador pode ter vários contactos de IM e que o seu identificador dentro do
gateway poderá não corresponder a nenhum deles, é da responsabilidade deste componente
manter a associação entre eles, armazenando-a em contactos registados. Para um utilizador
existente registar um novo contacto, tal deverá ser feito directamente no gateway, sendo este a
adicionar o novo contacto à sua lista. Seguidamente, o cliente deve, obviamente, aceitar a
adição do contacto do gateway à sua lista de contactos, utilizando para tal os métodos
disponibilizados pelo seu cliente de IM. Após este passo, o novo contacto já estará adicionado
ao gateway e associado ao utilizador, no entanto, não estará verificado. A verificação é um
passo adicional que visa aumentar a garantia de autenticidade dos contactos e que consiste
em pedir ao utilizador que escreva a sua password antes de poder interagir com o gateway, o
que é exemplificado na Figura 19. Perante a figura, torna-se óbvio um possível problema de
segurança em relação ao envio da password. Mais à frente, na secção 5.2, será testada a
existência de tal problema de segurança.
35
Figura 19 – Exemplo de verificação de um contacto
4.4 Comandos e Menus
O funcionamento dos comandos e menus exigiu o envolvimento de técnicas específicas,
pelo que é pertinente expor os detalhes do seu desenho e implementação. Em termos de
arquitectura geral, ambos pertencem ao componente Lógica / execução de comandos
evidenciado na Figura 9.
Quando uma nova mensagem de IM chega ao gateway, supondo que é verificada a
identidade do utilizador, é sujeita a um processo inicial de triagem. Assim, se houver um menu
36
a correr para o contacto e a mensagem consistir num número inteiro positivo, esta é
encaminhada para o respectivo menu que a processará, indexando a sua entrada
correspondente. É de notar que os menus são criados um por contacto (e não utilizador), sendo
que cada utilizador pode ter várias interacções simultâneas com o gateway através dos seus
vários diferentes contactos. Por outro lado, se ainda não existir um menu para o contacto ou a
mensagem não consistir num número inteiro positivo apenas, esta será interpretada como um
comando seguido dos seus argumentos.
O funcionamento específico de cada um dos modos de interacção do gateway será descrito
de seguida nas sub-secções 4.4.1 e 4.4.2.
4.4.1 Comandos
Após ter sido identificada como um comando, a mensagem é dividida nos seus vários
elementos pelo método Tokenize, desenvolvido para essa mesma finalidade. A particularidade
deste método, face a um qualquer método de split ou explode de uma string em várias, prendese com o facto de receber como parâmetro não só o elemento separador mas também o
elemento agregador. Na prática, isto significa que é possível passar vários argumentos a um
comando separados por espaços, mas também argumentos que contenham espaços,
bastando para tal colocar o elemento agregador – a plica – antes do seu início e depois do seu
fim. Estando a mensagem dividida, os seus elementos são passados ao método
CreateCommand, que, juntamente com a estrutura de classes Commad e suas subclasses,
implementa o padrão de desenho Factory method, cujo diagrama de classes está ilustrado na
Figura 20.
Figura 20 – Diagrama de classes UML do padrão de desenho Factory method
A classe Command representa o Criador do diagrama, e as suas subclasses representam
tanto o CriadorConcreto como o Produto. Com efeito, será construído e devolvido um comando
37
(uma subclasse de Command) com base no primeiro elemento. Obviamente que, caso o nome
enviado na mensagem não corresponda a nenhum comando, será lançada uma excepção que
acabará por resultar no envio de numa mensagem de erro para o contacto.
Tendo o comando sido identificado e criado com sucesso, segue-se a sua execução.
Também para este passo foi adoptado um padrão de desenho, desta vez o padrão Command,
cujo diagrama de classes se pode ver na Figura 21.
Figura 21 – Diagrama de classes UML do padrão de desenho Command
A associação dos seus elementos com as classes do gateway torna-se óbvia: a classe
Command
representa
o
Comando
enquanto
as
suas
subclasses
representam
o
ComandoConcreto. O chamador é representado pelo despacho de comandos. Como já foi
referido, a classe Command é super classe de todas as classes que representam comandos
concretos, obrigando-as, através da declaração virtual de métodos, a implementarem o método
que executa o funcionamento do comando - execute. Assim, qualquer comando tem a mesma
interface – método execute – mas funcionamento específico, sendo que o chamador não tem
que se preocupar com qual o comando que está a invocar, fazendo-o sempre de forma igual.
A combinação dos dois padrões de desenho anteriormente enunciados torna o despacho de
comandos bastante simples e limpo, uma vez que basta sequenciar uma chamada ao método
CreateCommand com uma chamada ao método execute no seu resultado.
4.4.2 Menus
Como já foi referido, os menus não são mais do que uma camada de funcionalidade
depositada em cima da dos comandos. Consequentemente, não há nenhuma acção que se
consiga efectuar através da utilização de menus que não se consiga através da utilização de
comandos, e vice-versa.
38
Para criar um menu, é necessário um conjunto de dados que são agrupados numa estrutura
própria (ver secção 4.5). Um dos elementos desse conjunto é um vector de comandos
(objectos que pertencem a subclasses da classe Command anteriormente referida), o qual
define as opções do menu. Como se pode então deduzir, cada uma das opções de um menu é
um comando, tal como os que são criados pelo método CreateCommand referido na subsecção anterior. Contudo, dentro de um menu, os comandos são criados de forma estática, em
função do contexto. Assim, por exemplo, um menu de um piso listará sempre um comando de
divisão por cada divisão, sendo que cada um destes criará um novo menu com um comando de
dispositivo por cada dispositivo que pertença a essa divisão. O funcionamento do menu tornase assim recursivo, permitindo navegar a maior e menor profundidade, até se chegar a uma
“folha” do menu, a qual é representada por um comando que efectivamente executa alguma
acção no sistema domótico.
Na Figura 22 é exemplificado uma possível execução do menu do gateway através de um
diagrama de sequência UML.
Como se pode depreender, os menus vão chamando os seus submenus através de uma
chamada a execute. Chegando a um menu com comandos “folha” (neste exemplo, chamadas 6
e 11), o método execute actua sobre o sistema domótico e retorna para o mesmo menu.
Posteriormente, à medida que o utilizador regressa até ao menu principal (chamadas 7 a 8 e 12
a 16), os métodos execute terminam a sua execução e retornam para o menu que os chamou.
Posto isto, os traços gerais do algoritmo dos menus tornam-se claros:
• Listar opções disponíveis, numerando-as;
• Aguardar que o utilizador introduza uma opção;
o
Caso a opção seja inválida, informar utilizador;
o
Caso seja igual a 0, retornar (para o menu acima);
o
Caso contrário (a opção indexa um comando), chamar o método execute
correspondente;
• Voltar ao início.
39
Figura 22 – Diagrama de sequência UML de uma possível execução do menu
4.5 Estruturas de dados do Gateway
Para suportar o carregamento de toda a configuração do sistema domótico para o gateway,
foram criadas várias estruturas de dados à medida. Nesta secção serão abordadas as mais
pertinentes.
O gateway carrega a referida configuração a partir de dois ficheiros XML diferentes:
• domotic system.xml;
• settings.xml;
O primeiro contém informação que o gateway apenas lê; assume-se que é criada e editada
por uma ferramenta externa. Nele encontra-se descrita toda a tipificação de dispositivos e suas
propriedades e também a estrutura da casa. Neste âmbito, as estruturas mais relevantes são
as seguintes:
• scalarValueType, enumValueType e arrayValueType, nas quais são armazenados os
vários tipos de valores definidos;
• deviceType e propertyType, para armazenar, respectivamente, tipos de dispositivos e
tipos de propriedades;
40
• device e property, que representam os dispositivos reais existentes na casa e suas
propriedades;
• floor e division, com os quais fica definida a estrutura física da casa.
Por outro lado, no segundo ficheiro, settings.xml, encontra-se todo o tipo de configurações
que podem ser alteradas pelo gateway: perfis de utilizadores e seus contactos. Eis as principais
estruturas:
• contact, que guarda os dados de cada um dos contactos de cada utilizador, contendo
informação sobre o respectivo estado de verificação;
• alarm e notification, que contêm informação para cada alarme ou notificação,
respectivamente, registada no sistema. Estas estruturas, quando criadas, são
associadas à estrutura property (anteriormente enunciada) a que se referem;
• macro, que, como o nome indica, serve para carregar todas as macros;
• favouriteList, que representa os favoritos de um dado utilizador e contem três listas
internas:
o
DeviceList;
o
DivisionList;
o
MacroList;
Finalmente, falta referir que foi criada uma estrutura genérica denominada entity que
representa uma qualquer entidade e que contempla os campos ID e Name. Todas as estruturas
anteriormente referidas que representem entidades e que, portanto, contemplem estes mesmos
campos, herdam-nos de entity.
À parte do sistema domótico propriamente dito, vale a pena ainda referir uma última
estrutura de dados: menuData. Esta é a estrutura que contém todos os dados necessários para
a criação de um novo menu:
• title – o título a apresentar quando o menu for utilizado;
• commands – um vector de comandos que representa as opções do menu;
• contact – uma referência para o contacto ao qual o menu está associado4;
• root – um booleano que indica se o menu é ou não a raiz.
4
Este campo é indispensável não só para utilizar no envio de mensagens de IM mas também para
obtenção da identidade do utilizador e posterior verificação de permissões
41
5 Metodologia de avaliação do trabalho
Para testar a fiabilidade real do gateway, foi definida uma série de testes que cobrem por
completo as suas funcionalidades mas também casos de uso que representam situações reais
da sua utilização, combinando várias funcionalidades. Dado que o gateway assenta todo o seu
funcionamento em comunicações de IM, encontra-se um pouco limitado no que toca a
imposições de requisitos não funcionais como desempenho, disponibilidade ou segurança.
Contudo, poderá ser útil registar algumas informações de desempenho – tempos de resposta –
e testar minimamente o quão seguro o sistema consegue ser. O ambiente de testes é igual ao
que foi apresentado na Figura 3, exceptuando o facto de que não serão usados gateways de
tecnologias nem dispositivos domóticos mas sim um gateway simulador, já que para as
funcionalidades a testar é irrelevante a utilização de um ou outros. O ambiente de testes tem
então a estrutura representada na Figura 23.
XMPP
Gateway
domótico
COMM-API
COMM-API
Gateway
simulador
Figura 23 – Estrutura do ambiente de testes utilizado
A interface do gateway simulador consiste numa consola na qual aparecerão as mensagens
recebidas do gateway domótico e através da qual se poderá alterar qualquer propriedade de
42
qualquer dispositivo, simulando o comportamento de um sistema real. Quanto à estrutura do
sistema domótico utilizada no ambiente de testes, pode ser consultada no Anexo I.
Findada esta apresentação ao ambiente de avaliação, segue-se a definição dos testes e
casos de uso.
5.1 Definição de testes e casos de uso
Quanto aos testes, estes visam testar cada uma das funcionalidades individuais do gateway,
podendo ser agrupados em seis categorias:
• Leitura (utilizador com permissão)
o
Leitura de uma propriedade do tipo escalar;
Para propriedades do tipo RO, WO e RW;
o
Leitura de uma propriedade do tipo enumerado;
Para propriedades do tipo RO, WO e RW;
o
Leitura de uma propriedade do tipo array;
Para propriedades do tipo RO, WO e RW.
• Leitura (utilizador sem permissão)
o
(mesmos testes que no ponto anterior);
• Escrita (utilizador com permissão)
o
Escrita de uma propriedade do tipo escalar;
Para propriedades do tipo RO, WO e RW;
o
Escrita de uma propriedade do tipo enumerado;
Para propriedades do tipo RO, WO e RW;
o
Escrita de uma propriedade do tipo array;
Para propriedades do tipo RO, WO e RW.
• Escrita (utilizador sem permissão)
o
(mesmos testes que no ponto anterior);
• Criação
o
Criação de uma nova macro privada;
Verificando que foi criada apenas para o utilizador que a criou;
o
Criação de uma nova macro partilhada;
Verificando que foi criada para todos os utilizadores;
o
Criação de uma nova notificação;
E posterior verificação da sua geração.
43
o
Criação de um novo alarme;
E posterior verificação da sua geração;
•
Verificando que é enviado por email se o utilizador não
estiver online no momento em que o alarme é gerado.
• Remoção
o
Remoção de uma macro privada;
o
Remoção de uma macro partilhada;
Verificando que foi removida para todos os utilizadores;
o
Remoção de uma notificação;
E posterior verificação da sua não geração;
o
Remoção de um alarme;
E posterior verificação da sua não geração.
Como preparação para os testes de leitura, foram introduzidos, a partir da consola do
gateway simulador, valores tão aleatórios quanto possível nas propriedades a ler. Os testes de
remoção visam eliminar as entidades respectivas criadas nos testes de criação.
Adicionalmente, foram definidos alguns testes para verificar a segurança alcançada pelo
sistema:
• Testar a resposta do gateway perante uma mensagem de contacto desconhecido;
• Testar a resposta do gateway perante um contacto conhecido mas não verificado;
• Testar se as mensagens enviadas pelo utilizador passam “em branco” na rede ou se
vão de alguma forma cifradas5 (teste ao sistema de IM);
o
5
Testar com diferentes serviços de IM.
Para obter e analisar o tráfego gerado pelo cliente de IM e pelo gateway, foi utilizado o programa
Wireshark [17]
44
Figura 24 – Diagrama UML geral de casos de uso do gateway
Os casos de uso, como já foi dito, têm por objectivo simular uma situação real de interacção
com o gateway, englobando várias funcionalidades. De um modo geral, a interacção dos
utilizadores com o gateway pode ser representada pelo diagrama de casos de uso da Figura
24. Como é perceptível, o tipo de interacção possível depende do tipo de utilizador:
• Um utilizador cujo contacto é desconhecido pelo gateway pode apenas ser actor do
caso de uso “Ignorar mensagens do utilizador”. Por outras palavras, todas as suas
mensagens serão ignoradas;
• Um utilizador com contacto conhecido, mas ainda não verificado fica também
restringido a um só caso de uso: “Pedir password para autenticação”. Até que o
utilizador introduza a sua password, este será o único comportamento do gateway.
Após introdução correcta da password, o utilizador torna-se no enunciado de seguida;
45
• Um utilizador com contacto conhecido e verificado pode protagonizar os dois casos de
uso que representam a utilização efectiva do gateway: “Interpretar, validar e executar
opção do menu” e “Interpretar, validar e executar comando”;
Feita esta apresentação inicial, definem-se os casos de uso específicos que efectivamente
avaliam a interacção com o gateway:
• Utilizador vai de férias
o
Cria a macro “Ir de férias” que:
Fecha todos os estores;
Desliga todas as lâmpadas;
Desliga todas as televisões;
Liga o alarme.
o
Corre a macro que acabou de criar
o
Faz uma simples verificação ao estado do alarme
• Utilizador é segurança de um edifício e pretende monitorizar todos os equipamentos
relacionados com segurança:
o
Cria interesse em notificação em todos os dispositivos pertencentes ao
serviço “Segurança”;
• Utilizador é empregado de um restaurante e pretende ligar o ar condicionado nas salas
em que a temperatura seja igual ou superior a 26º:
o
Para cada sala (divisão), verifica se existe alguém na sala (sensor de
presença);
Se existir, verifica a temperatura (sensor temperatura);
•
Se esta for superior a 26º, liga o ar condicionado;
• Utilizador é recepcionista num hotel e pretende avisar um hóspede que alguém na
recepção o quer contactar:
o
Verifica se é detectada a presença de alguém no quarto do hóspede em
questão (sensor de presença);
Em caso afirmativo, utiliza a respectiva televisão para lhe fazer um
breve sinal sonoro, disponibilizando a informação no canto do ecrã;
5.2 Resultados
Nesta secção são apresentados os resultados da execução dos testes e casos de uso
enunciados na secção anterior.
46
No que toca à funcionalidade, o gateway foi aprovado, uma vez que todos os testes tiveram
o resultado esperado. O resumo dos resultados dos testes de leitura e de escrita pode ser
consultado no Quadro 3.
Propriedade enumerado
Propriedade escalar
RO
WO
RW
RO
WO
RW
Propriedade array
RO
WO
RW
Leitura
Leitura
(com
(sem
permissão)
permissão)
Valor OK
Valor OK
Valor OK
(sem permissão)
Valor
Valor
Valor
Valor
válido
inválido
válido
inválido
Erro de escrita
Valor
OK
Permissão
Valor
negada
OK
Permissão
Erro de
valor
Permissão negada
inválido
Erro de
valor
Permissão negada
inválido
Erro de escrita
negada
Valor
OK
Permissão
Valor
negada
OK
Permissão
Erro de
valor
Permissão negada
inválido
Erro de
valor
Permissão negada
inválido
Erro de escrita
negada
Erro de leitura
Valor OK
(com permissão)
negada
Erro de leitura
Valor OK
Escrita
Permissão
Erro de leitura
Valor OK
Escrita
Valor
OK
Permissão
Valor
negada
OK
Erro de
valor
Permissão negada
inválido
Erro de
valor
Permissão negada
inválido
Quadro 3 – Resultados dos testes de leitura e de escrita
Como seria de esperar, numa leitura, para propriedades do tipo WO, foi retornado um erro
de leitura. Caso contrário, se não se verificou a permissão do utilizador, foi mostrada uma
47
mensagem de permissão negada. Por último, não sendo verdade nenhuma das condições
anteriores, foi apresentado correctamente o valor presente no gateway simulador.
Quanto aos testes de escrita, o comportamento foi análogo, sendo que foi apresentada uma
mensagem de erro de escrita para as propriedades do tipo RO e uma mensagem de erro de
valor inválido para as restantes no caso de o utilizador ter permissão e fornecer um valor
inválido.
Criação
Criação
macro
macro
privada
partilhada
Quando
está
Resultado
Nova macro disponível
Online
para o
utilizador
Criação
notificação
Criação alarme
Notificação
Alarme recebido
recebida aquando
aquando do
do acontecimento
acontecimento
com interesse
com interesse
Email com alarme
Quando
está
recebido aquando
Nenhuma alteração
do acontecimento
Offline
com interesse
Resultado para
Nenhuma
Nova macro
restantes utilizadores
alteração
disponível
Nenhuma alteração
Quadro 4 – Resultados dos testes de criação
Os resultados do conjunto de testes seguinte, testes de criação, são mostrados no Quadro 4.
Ficou confirmada, portanto, a privacidade no modo de acesso às macros e o bom
funcionamento do sistema de notificações e alarmes, incluindo o envio de alarmes por email
quando o utilizador interessado está offline.
Mais uma vez de forma análoga, em relação aos resultados dos testes de criação, os
resultados dos testes de remoção são apresentados no Quadro 5, que completa os resultados
de testes funcionais do gateway.
Quanto aos testes não funcionais, foram realizados de dois tipos: desempenho e segurança.
Como já foi referido, os testes não funcionais reflectem mais o funcionamento dos sistemas de
IM do que o do gateway propriamente dito. Contudo, vale a pena analisar.
48
Remoção
Remoção
macro
macro
privada
partilhada
Remoção
notificação
Nenhuma
Quando
está
Resultado
Macro removida deixou de
estar disponível
Online
recebida aquando
do acontecimento
com interesse
para o
utilizador
notificação
Remoção alarme
Nenhum alarme
recebido aquando
do acontecimento
com interesse
Nenhum email
Quando
com alarme
está
Nenhuma alteração
recebido aquando
do acontecimento
Offline
com interesse
Macro
Resultado para
Nenhuma
restantes utilizadores
alteração
removida
deixou de
Nenhuma alteração
estar
disponível
Quadro 5 – Resultados dos testes de remoção
Para medir o desempenho, foi cronometrado o tempo que cada uma das interacções com o
gateway demora a retornar uma resposta. Foram capturados os pacotes gerados na rede
resultantes da interacção, utilizado o programa Wireshark [17]. De seguida, foi calculada a
diferença entre o momento em que saiu um pacote com um comando e o momento em que
chegou o pacote com a resposta. Os resultados – valores médios para o conjunto dos
resultados de testar cada um dos comandos – constam no Quadro 6, por serviço de IM.
MSN
Google talk
AIM
ICQ
Jabber
0,8 s
0,5 s
0,5 s
0,5 s
0,5 s
Quadro 6 – Tempos médios de resposta do gateway para vários serviços de IM
Como é óbvio, esta duração prende-se com o atraso introduzido pelos sistemas de IM, não
sendo representativo do real desempenho do gateway. Neste sentido, é notório o
distanciamento do MSN em relação aos outros serviços testados.
No que toca à segurança, os resultados são apresentados de seguida. No Quadro 7 são
sintetizadas as respostas do gateway para cada tipo de contacto.
49
Contacto
Contacto conhecido
desconhecido
Não verificado
Verificado
Nenhuma resposta
Pedido para introdução da
Resultado do comando / opção
respectiva password
do menu
Quadro 7 – Respostas do gateway aos vários tipos de contactos
Estes testes contemplaram a tentativa de execução de cada um dos comandos e de
navegação no menu. Como se poderia esperar – e está evidenciado no Quadro 7 – as
mensagens de um contacto desconhecido são simplesmente ignoradas, enquanto as de um
contacto não verificado obtêm sempre como resposta um pedido de introdução de password.
Finalmente, apenas um contacto verificado pode executar comandos e navegar nos menus,
obtendo o resultado respectivo.
Ainda no âmbito da segurança do gateway, é apresentado o Quadro 8, onde se pode
verificar a forma como cada serviço de IM envia as mensagens pela rede.
MSN
Google
talk
AIM
ICQ
Jabber
Em
Em
Em
Em
Em branco / cifradas (dependente da
branco
branco
branco
branco
configuração do servidor)
Quadro 8 – Modo de envio de mensagens dos vários serviços de IM
De um modo geral, os serviços de IM não cifram as mensagens a enviar. O Jabber constitui
uma excepção, oferecendo tal funcionalidade, ainda que de forma opcional. Podemos então
detectar aqui uma falha na segurança do gateway, causada pelo modo de funcionamento dos
serviços de IM. Exceptuando o Jabber em modo de cifra, todos os serviços de IM enviam as
mensagens em branco na rede, podendo qualquer atacante capturar os respectivos pacotes e
reconstruí-las.
Para concluir a secção de resultados, basta sumarizar os tempos medidos aquando da
execução de cada um dos casos de uso, o que se pode ver no Quadro 9. Os tempos foram
medidos em duas vertentes: menus e comandos. Na primeira, cada caso de uso foi executado
50
tirando partido apenas da utilização de menus; na segunda, foi executado através da utilização
de comandos6.
Utilizador
vai de férias
Utilizador é
Utilizador é
Utilizador é
segurança de um
empregado de um
recepcionista de
edifício
restaurante
um hotel
Menus
5m 40s
22s
1m 13s
40s
Comandos
3m 41s
5s
47s
26s
Quadro 9 – Tempos medidos na execução dos vários casos de uso
Como já foi referido antes, os menus são mais adequados a um utilizador inexperiente,
perdendo em desempenho. Por sua vez, os comandos obrigam a conhecer bem a sua sintaxe,
ganhando, porém, onde os menus perdem. Esta dicotomia está reflectida no Quadro 9.
6
Na prática, também foram utilizados os menus, uma vez que alguns comandos teriam uma quantidade
de caracteres superior ao suportado pelo cliente de IM
51
6 Conclusões
Neste trabalho foram apresentadas a arquitectura e estrutura interna de um gateway
domótico com suporte para sistemas de messaging. O foco principal deste trabalho prende-se
com a característica inovadora introduzida: a capacidade de utilizar um sistema de IM para
comunicar com o gateway e, consequentemente, monitorizar e controlar o sistema domótico.
Tendo também em conta a relevância das funcionalidades referidas como “perfis”, foi dada
especial ênfase à descrição das partes da arquitectura responsáveis pela lógica e pela
interacção com sistemas de messaging. A metodologia de avaliação foi planeada em função do
mesmo foco, utilizando um simulador em vez de um sistema com dispositivos reais.
O gateway mostrou-se fiel à especificação do seu funcionamento, o que corrobora as
decisões tomadas no desenho da sua arquitectura. De facto, a sua divisão em três camadas
assemelha-se a um padrão de desenho de software bastante comum e com provas dadas “Three-tier”, que se divide em “apresentação”, “lógica” e “dados”. As tecnologias domóticas
utilizadas pelo sistema podem então ser vistas como uma “base de dados” que é controlada
pela camada inferior – “dados” – do gateway. A camada intermédia representa, obviamente, a
“lógica” do sistema. Por fim, a camada superior constitui parte da “apresentação”, uma vez que,
para ser concluída a sua finalidade, é necessária a intervenção do cliente de IM do lado do
utilizador.
Os dois modos de interacção descritos, comandos e menus, são, em conjunto, uma maisvalia, uma vez que se combinam para oferecer ao utilizador o melhor de cada um: rapidez dos
comandos e facilidade de utilização dos menus. Esta dicotomia torna a utilização do gateway
bastante versátil, permitindo a existência de utilizadores com vários níveis de experiência em
simultâneo. Um utilizador sem experiência descobre o sistema utilizando menus; um utilizador
com experiência média faz uma utilização equilibrada dos dois tipos interacção; um utilizador
experiente interage, essencialmente, através de comandos, tirando partido da sua rapidez.
O suporte para vários protocolos de IM representa outra mais-valia. Pode dizer-se que esta é
oferecida pelo cliente de IM englobado no gateway, o que, contudo, concede mérito à escolha
feita. O valor acrescentado reside na possibilidade que o utilizador tem em poder utilizar o
sistema com o seu cliente de IM preferido. Para um utilizador típico é comum, por exemplo, a
utilização exclusiva do Windows Live Messenger. Apesar de disponíveis para a instalação de
novos clientes de IM, os utilizadores não se sentem completamente à vontade ao utilizá-los, o
que pode prejudicar a experiência de utilização do sistema. Há que ressalvar, contudo, que
para situações em que os requisitos de segurança não possam ser aliviados, é aconselhada a
instalação e utilização de um servidor Jabber com rede de IM própria, configurando-o para o
modo de cifra de todas as mensagens.
52
Como nota para trabalho futuro, fica a possibilidade de explorar a funcionalidade de
videochamada oferecida pela maioria dos clientes e serviços de IM. Seria interessante poder
observar, em tempo real, as zonas de uma habitação cobertas por câmaras de vigilância ou
webcams. Na prática, esta funcionalidade obrigará ao desenvolvimento de módulos de
comunicação específicos para cada tipo de câmara. Como alternativa, poderá ser explorada a
possibilidade de inclusão de mecanismos de streaming no DomoBus. Apesar de não oferecer
este tipo de interacção mais interessante, o gateway simula-o minimamente, recorrendo a
câmaras reais conectadas à máquina onde está instalado.
Para finalizar, o gateway apresentado mostrou-se capaz de representar o seu papel num
sistema domótico, oferecendo funcionalidades personalizadas e inovadoras e estando à altura
das necessidades dos utilizadores.
53
7 Referências
[1] Renato Nunes, Modelo de Especificação e Programação de um Sistema Domótico,
IADIS Conferência Ibero-Americana WWW/Internet 2004, Madrid, Spain, October 2004,
pp. 377-384
[2] Renato Nunes, Análise Comparativa de Tecnologias para Domótica, JEACI 2002- III
Jornadas de Engenharia de Automação, Controlo e Instrumentação, EST Setúbal, Maio
2002
[3] Renato Nunes, DomoBus - A New Approach to Home Automation, 8CLEEE - 8th
International Congress on Electrical Engineering, Portugal, July 2003, pp.2.19-2.24
[4] Paolo Pellegrino, Dario Bonino, Fulvio Corno, Politecnico di Torino, Domotic House
Gateway
[5] Dario Bonino, Emiliano Castellina, Fulvio Corno, Politecnico di Torino, DOG: an
Ontology-Powered OSGi Domotic Gateway
[6] Jabber, http://www.jabber.org/ (data de última consulta – 21/10/2009)
[7] XMPP - Extensible Messaging and Presence Protocol, http://xmpp.org/ (data de última
consulta – 21/10/2009)
[8] Miranda IM - http://www.miranda-im.org/ (data de última consulta – 21/10/2009)
[9] Bruno Miguel Nunes Almeida, Sérgio Alexandre Bento Esteves Gomes, Módulo de
Comunicação DomoBus, Relatório da cadeira de Ambientes Inteligentes, MEIC IST,
Janeiro 2009
[10] Renato Nunes, API de Comunicação do sistema DomoBus, Relatório Técnico, IST,
Outubro 2005
[11] UML – Unified Modeling Language, http://www.uml.org/ (data de última consulta –
21/10/2009)
[12] X10, http://www.x10.com (data de última consulta – 21/10/2009)
[13] KNX (EN 50090,ISO/IEC 14543), http://www.knx.org (data de última consulta –
21/10/2009)
[14] LonWorks, http://www.echelon.com (data de última consulta – 21/10/2009)
[15] ZigBee, http://www.zigbee.org (data de última consulta – 21/10/2009)
[16] Domobus, http://www.domobus.net (data de última consulta – 21/10/2009)
[17] Wireshark, http://www.wireshark.org/ (data de última consulta – 21/10/2009)
54
Anexo I
Conteúdo do ficheiro domotic system.xml:
<DomoBusSystem ID="1" Name="Test House" Version="1.0">
<ConversionFormulaList>
<ConversionFormula ID="1" Name="Double" UserToSystem="2*X" SystemToUser="X/2" DecimalPlaces="0" />
<ConversionFormula ID="2" Name="10*X+200" UserToSystem="10*X+200" SystemToUser="(X-200)/10"
DecimalPlaces="1" />
</ConversionFormulaList>
<ScalarValueTypeList>
<ScalarValueType ID="1" Name="Percentage (0-100)" NumBits="8" MinValue="0" MaxValue="100" Step="1">
<ValueConversion Type="NONE" Ref="" />
</ScalarValueType>
<ScalarValueType ID="2" Name="Temperature" NumBits="16" MinValue="0" MaxValue="800" Step="1">
<ValueConversion Type="FORMULA" Ref="2" />
</ScalarValueType>
<ScalarValueType ID="3" Name="Test scalar value" NumBits="16" MinValue="0" MaxValue="1000" Step="1">
<ValueConversion Type="NONE" Ref="" />
</ScalarValueType>
</ScalarValueTypeList>
<EnumValueTypeList>
<EnumValueType ID="1" Name="On-Off">
<Enumerated Name="Off" Value="0" />
<Enumerated Name="On" Value="1" />
</EnumValueType>
<EnumValueType ID="2" Name="Air conditioner">
<Enumerated Name="Off" Value="0" />
<Enumerated Name="Heat" Value="1" />
<Enumerated Name="Cool" Value="2" />
</EnumValueType>
<EnumValueType ID="3" Name="Test enum value">
<Enumerated Name="Enum 0" Value="0" />
<Enumerated Name="Enum 1" Value="1" />
<Enumerated Name="Enum 2" Value="2" />
<Enumerated Name="Enum 3" Value="3" />
</EnumValueType>
</EnumValueTypeList>
<ArrayValueTypeList>
<ArrayValueType ID="1" Name="Description" MaxLen="50">
<ValueConversion Type="NONE" Ref="" />
</ArrayValueType>
<ArrayValueType ID="2" Name="Test array value" MaxLen="10">
<ValueConversion Type="NONE" Ref="" />
</ArrayValueType>
</ArrayValueTypeList>
<DeviceTypeList>
<DeviceType ID="1" Name="Dim-Lamp" Description="-">
<PropertyTypeList>
<PropertyType ID="1" Name="On-Off" AccessMode="RW" ValueType="ENUM" RefValueType="1" />
<PropertyType ID="2" Name="Intensity" AccessMode="RW" ValueType="SCALAR" RefValueType="1" />
</PropertyTypeList>
</DeviceType>
<DeviceType ID="2" Name="Temperature-Sensor" Description="-">
<PropertyTypeList>
<PropertyType ID="1" Name="Temperature" AccessMode="RO" ValueType="SCALAR" RefValueType="2" />
</PropertyTypeList>
</DeviceType>
<DeviceType ID="3" Name="Blind" Description="-">
<PropertyTypeList>
55
<PropertyType ID="1" Name="Height" AccessMode="RW" ValueType="SCALAR" RefValueType="1" />
</PropertyTypeList>
</DeviceType>
<DeviceType ID="4" Name="Camera" Description="-">
<PropertyTypeList>
<PropertyType ID="1" Name="On-Off" AccessMode="RW" ValueType="ENUM" RefValueType="1" />
</PropertyTypeList>
</DeviceType>
<DeviceType ID="5" Name="Alarm" Description="-">
<PropertyTypeList>
<PropertyType ID="1" Name="On-Off" AccessMode="RW" ValueType="ENUM" RefValueType="1" />
</PropertyTypeList>
</DeviceType>
<DeviceType ID="6" Name="Test device" Description="-">
<PropertyTypeList>
<PropertyType ID="1" Name="Scalar RO" AccessMode="RO" ValueType="SCALAR" RefValueType="3" />
<PropertyType ID="2" Name="Scalar RW" AccessMode="RW" ValueType="SCALAR" RefValueType="3" />
<PropertyType ID="3" Name="Scalar WO" AccessMode="WO" ValueType="SCALAR" RefValueType="3" />
<PropertyType ID="4" Name="Enum RO" AccessMode="RO" ValueType="ENUM" RefValueType="3" />
<PropertyType ID="5" Name="Enum RW" AccessMode="RW" ValueType="ENUM" RefValueType="3" />
<PropertyType ID="6" Name="Enum WO" AccessMode="WO" ValueType="ENUM" RefValueType="3" />
<PropertyType ID="7" Name="Array RO" AccessMode="RO" ValueType="ARRAY" RefValueType="2" />
<PropertyType ID="8" Name="Array RW" AccessMode="RW" ValueType="ARRAY" RefValueType="2" />
<PropertyType ID="9" Name="Array WO" AccessMode="WO" ValueType="ARRAY" RefValueType="2" />
</PropertyTypeList>
</DeviceType>
</DeviceTypeList>
<AccessLevelList>
<AccessLevel Level="0" Name="Free Access" />
<AccessLevel Level="1" Name="Guest" />
<AccessLevel Level="2" Name="Common User - Child" />
<AccessLevel Level="3" Name="Common User - Parent" />
<AccessLevel Level="10" Name="Administrator" />
</AccessLevelList>
<UserList>
<User ID="1" Name="admin" Password="admin" Email ="[email protected]" AccessLevel="2" />
</UserList>
<House ID="1" Name="Test House" Address="xxxxx" Phone="xxxx">
<FloorList>
<Floor ID="1" Name="Garage" HeightOrder="-1">
<DivisionList>
<Division ID="1" Name="Garage" AccessLevel="1" />
</DivisionList>
</Floor>
<Floor ID="2" Name="First floor" HeightOrder="0">
<DivisionList>
<Division ID="2" Name="Kitchen" AccessLevel="3" />
<Division ID="3" Name="Living room" AccessLevel="2" />
<Division ID="4" Name="Room 1" AccessLevel="3" />
<Division ID="5" Name="Room 2" AccessLevel="3" />
<Division ID="6" Name="Bathroom 1" AccessLevel="3" />
<Division ID="7" Name="Bathroom 2" AccessLevel="3" />
<Division ID="8" Name="Hall" AccessLevel="2" />
</DivisionList>
</Floor>
<Floor ID="3" Name="Attic" HeightOrder="1">
<DivisionList>
<Division ID="9" Name="Attic" AccessLevel="2" />
</DivisionList>
</Floor>
</FloorList>
</House>
<ServiceList>
<Service ID="1" Name="Heating" />
<Service ID="2" Name="Illumination" />
<Service ID="3" Name="Alarm" />
<Service ID="4" Name="Plugs" />
56
<Service ID="5" Name="Irrigation" />
<Service ID="6" Name="Security" />
</ServiceList>
<DeviceList>
<Device ID="1" RefDeviceType="1" Name="Living room Table Lamp" Address="0x30000001" RefDivision="3"
MonAccessLevel="3" ControlAccessLevel="5">
<DeviceServiceList>
<DeviceService RefService="2" />
</DeviceServiceList>
</Device>
<Device ID="2" RefDeviceType="1" Name="Living room Ceiling Lamp" Address="0x30000002" RefDivision="3"
MonAccessLevel="3" ControlAccessLevel="5">
<DeviceServiceList>
<DeviceService RefService="2" />
</DeviceServiceList>
</Device>
<Device ID="3" RefDeviceType="3" Name="Living room blinds 1" Address="0x30000003" RefDivision="3"
MonAccessLevel="3" ControlAccessLevel="5">
</Device>
<Device ID="4" RefDeviceType="3" Name="Living room blinds 2" Address="0x30000004" RefDivision="3"
MonAccessLevel="3" ControlAccessLevel="5">
</Device>
<Device ID="5" RefDeviceType="1" Name="Room 1 Ceiling Lamp" Address="0x30000005" RefDivision="4"
MonAccessLevel="3" ControlAccessLevel="5">
<DeviceServiceList>
<DeviceService RefService="2" />
</DeviceServiceList>
</Device>
<Device ID="6" RefDeviceType="1" Name="Room 2 Ceiling Lamp" Address="0x30000006" RefDivision="5"
MonAccessLevel="3" ControlAccessLevel="5">
<DeviceServiceList>
<DeviceService RefService="2" />
</DeviceServiceList>
</Device>
<Device ID="7" RefDeviceType="3" Name="Room 1 blinds" Address="0x30000007" RefDivision="4"
MonAccessLevel="3" ControlAccessLevel="5">
</Device>
<Device ID="8" RefDeviceType="3" Name="Room 2 blinds" Address="0x30000008" RefDivision="5"
MonAccessLevel="3" ControlAccessLevel="5">
</Device>
<Device ID="9" RefDeviceType="2" Name="Thermometer" Address="0x30000009" RefDivision="3"
MonAccessLevel="1" ControlAccessLevel="10">
</Device>
<Device ID="10" RefDeviceType="1" Name="Bathroom 1 Ceiling Lamp" Address="0x3000000A" RefDivision="6"
MonAccessLevel="3" ControlAccessLevel="5">
<DeviceServiceList>
<DeviceService RefService="2" />
</DeviceServiceList>
</Device>
<Device ID="11" RefDeviceType="1" Name="Bathroom 2 Ceiling Lamp" Address="0x3000000B" RefDivision="7"
MonAccessLevel="3" ControlAccessLevel="5">
<DeviceServiceList>
<DeviceService RefService="2" />
</DeviceServiceList>
</Device>
<Device ID="12" RefDeviceType="4" Name="Camera 1" Address="0x3000000C" RefDivision="3"
MonAccessLevel="8" ControlAccessLevel="10">
<DeviceServiceList>
<DeviceService RefService="6" />
</DeviceServiceList>
</Device>
<Device ID="13" RefDeviceType="5" Name="Alarm" Address="0x3000000D" RefDivision="3" MonAccessLevel="8"
ControlAccessLevel="10">
<DeviceServiceList>
<DeviceService RefService="6" />
</DeviceServiceList>
</Device>
<Device ID="14" RefDeviceType="6" Name="Test device" Address="0x3000000E" RefDivision="3"
MonAccessLevel="3" ControlAccessLevel="3">
</Device>
</DeviceList>
57
</DomoBusSystem>
58
Conteúdo do ficheiro settings.xml:
<DomoBusSystem ID="1" Name="Test House" Version="1.0">
<SMTPSettings ServerAddress="smtp.sapo.pt" ServerPort="25" Username="[email protected]"
Password="mgs2sol" SourceAddress="[email protected]"/>
<ContactList>
<Contact ID="5" Protocol="MSN_1" Name="[email protected]" RefUser="2" Verified="1"/>
</ContactList>
<MacroList>
<Macro ID="1" Name="Watch TV" RefUser="2">
<ActionList>
<Action ID="1" Name="Close blinds" RefDevice="3" RefProperty="1"
Value="0"/>
<Action ID="2" Name="Table Lamp 50%" RefDevice="1" RefProperty="2"
Value="50"/>
<Action ID="3" Name="Ceiling Lamp 40%" RefDevice="2" RefProperty="2"
Value="40"/>
</ActionList>
</Macro>
</MacroList>
<AlarmList>
<Alarm ID="1" RefUser="1" RefDevice="4" RefProperty="1" Operator="3" Value="30"/>
</AlarmList>
<NotificationList>
<Notification ID="1" RefUser="1" RefDevice="4" RefProperty="1" Operator="3" Value="25"/>
</NotificationList>
<Favourites>
<FavouriteList RefUser="1">
<FavouriteDevice RefDevice="1"/>
<FavouriteDivision RefDivision="3"/>
<FavouriteMacro RefMacro="1"/>
</FavouriteList>
</Favourites>
</DomoBusSystem>
59