Interfaces Inteligentes para Casas Inteligentes
José Luis Domingues Góis
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Orientador: Prof. Renato Jorge Caleira Nunes
Júri
Presidente: Prof. Alberto Manuel Rodrigues da SilvaOrientador: Prof. Renato Jorge Caleira NunesVogal: Prof. Alberto Manuel Ramos da Cunha
Novembro 2015
ii
Agradecimentos
Em primeiro lugar gostaria de agradecer a todos os meus familiares, amigos e colegas de faculdade que
me acompanharam ao logo de todo o meu percurso academico e me ajudaram a ultrapassar inumeros
obstaculos. Sem eles nao seria possıvel ter chegado a este ponto.
Quero agradecer em especial aos meus pais por me terem sempre disponibilizado todos os meios,
mediante do possıvel, para que nunca me faltasse nada, mesmo durante os momentos mais difıceis.
Por todo o apoio que me deram e por me encorajarem a seguir em frente no meu percurso academico.
Gostaria de agradecer em especial ao Professor Renato Jorge Caleira Nunes por ter mostrado um
grande interesse e vontade que este projeto se realizasse da melhor forma, mostrando-se sempre
disponıvel para reunioes presenciais ou mesmo via Skype. Por todo o cuidado em explicar os detalhes
da infraestrutura DomoBus para que pudesse ter uma visao o mais completa possıvel. Para mim revelou
ser uma pessoa extremamente dedicada e que tem fe no seu projeto. Por isso mesmo mostra um
grande entusiasmo e tenta transmiti-lo a quem esta envolvido nele.
Por fim gostaria de deixar um especial obrigado a todas as pessoas que, voluntariamente, se dis-
ponibilizaram para realizar os testes da interface desenvolvida, mostrando um grande entusiasmo e
contribuindo com novas ideias e sugestoes.
iii
iv
Resumo
A domotica e uma area que tem vindo a crescer, embora seja notoria a falta de solucoes flexıveis e
que permitam a interoperacao entre diferentes tecnologias. O sistema DomoBus procura dar resposta
a estas questoes.
Nesta dissertacao apresenta-se uma proposta de uma interface com o utilizador, adaptavel e flexıvel,
para o sistema DomoBus. Este sistema preve a utilizacao de dispositivos sensıveis ao toque em qual-
quer divisao de um habitacao, podendo funcionar como substituto dos tradicionais interruptores ou
outros dispositivos. O aparecimento de tablets de muito baixo custo torna esta abordagem viavel,
permitindo uma solucao de grande flexibilidade e ate mais economica que outras solucoes de outras
tecnologias.
Ao longo deste trabalho foram analisadas diferentes solucoes disponıveis no mercado, de modo
a desenvolver uma solucao inovadora. A interface desenvolvida adapta-se automaticamente a cada
sistema DomoBus necessitando apenas aceder a sua especificacao em XML. Adicionalmente, e confi-
guravel e ajustavel as preferencias de cada utilizador, permitindo uma interacao local a uma divisao ou
global a toda a habitacao.
Durante o desenvolvimento, e para simplificar o teste, foi criado um simulador simples de dispositivos
DomoBus e uma biblioteca de comunicacao que implementa o protocolo DomoBus. A interface foi
testada e validada, usando diversas configuracoes, tendo-se concluıdo que satisfazia aos requisitos
definidos. Adicionalmente, foram realizados testes com utilizadores. A analise dos resultados permitiu
concluir que a interface e funcional e de uso facil. Como base nos resultados e opinioes obtidas foram
identificadas algumas melhorias passıveis de serem implementadas no futuro.
Palavras-chave: domotica, interface com o utilizador, interface adaptavel, tablet, Android,
XML
v
vi
Abstract
Home automation is an area that has been growing, although the lack of flexible solutions that allow
interoperation between different technologies is evident. The DomoBus system aims to address these
issues. This dissertation presents a proposal of a user interface, adaptable and flexible, for the Domo-
Bus system. This system provides for the use of touchscreen devices in any room of a housing, allowing
them to work as a replacement of traditional switches or other devices. The emergence of very low cost
tablets makes this approach feasible, contributing for a hight flexibility solution that can be less costly
than other technological solutions. Throughout this work, there were analyzed different solutions avai-
lable on the market, in order to develop an innovative solution. The developed interface automatically
adapts to each DomoBus system requiring only access to its XML specification. Additionally, it is con-
figurable and adjustable to individual preferences, allowing a local interaction relatively to a division or
an overall housing access. During the development, and to facilitate testing, a simple simulator of Do-
moBus devices and a communication library that implements the DomoBus protocol were implemented.
The interface was tested and validated using several settings, and it was found that it met the defined
requirements. Additionally user tests were conducted. The results showed that the interface is functio-
nal and easy to use. Based on results and the collected user points of view there were identified some
improvements that can be implemented in the future.
Keywords: domotics, user interface, adaptable interface, tablet, Android, XML
vii
viii
Conteudo
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
1 Introducao 1
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organizacao da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Estado da Arte 7
2.1 Loxone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 OpenHab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Computer Zen Home Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 HEIMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Analise Crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Solucao Proposta 21
3.1 DomoBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Arquitetura da Solucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Processamento de XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Modos de operacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 Modo Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 Modo de Configuracao de Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 Modo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Estrutura da Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5 Simulador de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 Resultados 45
4.1 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
ix
4.2 Teste com utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Conclusoes 53
Referencias 55
A Testes de Usabilidade e Questionario 57
B Resultados dos Testes de Usabilidade 61
x
Lista de Tabelas
4.1 Resultados dos Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
xi
xii
Lista de Figuras
2.1 Historico de temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Pagina inicial - Aplicacao Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Grafico fornecimento de energia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 OpenHab - Interface Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Interface HAI Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Interface HEIMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Interface HEIMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Interface HEIMA - dispositivos de parede . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Arquitetura DomoBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Integracao da aplicacao no sistema DomoBus . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Quota de mercado das diferentes versoes do Android . . . . . . . . . . . . . . . . . . . . 26
3.4 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Modo Operacional - Exemplo de uma grelha . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Estrutura de um pacote de dados DomoBus do nıvel de supervisao . . . . . . . . . . . . 33
3.7 Biblioteca - classe Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8 Modo Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 Modo de Configuracao de Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.10 Modo Geral - Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.11 Modo Geral - Propriedade do tipo Escalar . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.12 Modo Operacional - Propriedade do tipo Escalar . . . . . . . . . . . . . . . . . . . . . . . 41
3.13 Propriedade do tipo Enumerado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.14 Modo Geral - Propriedade do tipo Escalar . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.15 Simulador de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
xiii
xiv
Capıtulo 1
Introducao
Os avancos tecnologicos dos ultimos anos tem trazido para a sociedade um conjunto de novas formas
de interagir com o mundo exterior, contribuindo para uma melhoria significativa da qualidade de vida.
Para alem dos avancos na medicina e outros, a informatica e uma area aplicacional que tambem tem
potenciado muitas dessas melhorias. Hoje em dia os dispositivos informaticos sao praticamente omni-
presentes fazendo parte das nossas vidas de tal forma que muitos deles passam despercebidos e/ou
sao tomados como garantidos.
As habitacoes foram tambem evoluindo com o surgir de novas tecnologias e, atualmente, albergam
uma quantidade de dispositivos consideravel. Alem disso, estas tem vindo a tornar-se cada vez mais
inteligentes e automatizadas em prol da qualidade de vida. No caso especifico das habitacoes e outros
edifıcios surgiu entao a domotica.
A domotica e uma area tecnologica que visa o controlo e gestao dos recursos de uma habitacao.
O termo domotica apareceu nos finais do seculo XX e deriva da juncao da palavra latina Domus, que
significa casa e de telematica que se refere a informatica e comunicacoes. O termo apareceu inicial-
mente na Franca, domotique, e apenas posteriormente foi adaptado. Na lıngua inglesa sao comuns
designacoes como Home Automation e Smart Homes.
Hoje em dia um sistema domotico pode ser mais ou menos complexo consoante a complexidade do
edifıcio e das necessidades dos utilizadores, no entanto as principais funcionalidades de um sistema
domotico sao a Automacao, a Iluminacao, a Climatizacao, a Seguranca e a Comunicacao.
1. Automacao
A automacao tem como principal objetivo permitir ao utilizador programar tarefas e/ou regras para
que possam ser realizadas acoes automaticamente com base em dados relativos a temporizado-
res, condicoes climatericas, luminosidade, e outros. Esta funcionalidade traz ao sistema domotico
um nıvel de inteligencia superior uma vez que o sistema torna-se capaz de realizar acoes auto-
maticamente.
2. Iluminacao
As funcionalidades relativas a iluminacao permitem, por exemplo, controlar a intensidade de
lampadas ou gerir definicoes de temporizadores, sensores de movimento e presenca.
1
3. Climatizacao
O controlo de aparelhos de climatizacao como o aquecimento ou ar condicionado permite, por
exemplo, manter uma temperatura constante e estavel no interior da habitacao, podendo levar a
uma reducao de custos energeticos. Em sistemas mais complexos, pode ser feita uma gestao de
recursos renovaveis de forma mais eficiente. Por exemplo, um coletor solar pode ser utilizado para
auxiliar o aquecimento do interior da habitacao em algumas situacoes especıficos. Nestes casos
o sistema deve ser capaz de analisar essas situacoes com base em parametros potenciando uma
melhor gestao de recursos.
4. Seguranca
A seguranca e um aspeto bastante importante nos dias de hoje. A domotica pode ajudar a identifi-
car intrusos atraves de fontes de vıdeo e/ou audio, sensores de movimento e outros mecanismos.
No que diz respeito a prevencao, um sistema domotico pode facilmente identificar situacoes que
comprometem a seguranca, como por exemplo portas e janelas abertas e alertar o utilizador au-
tomaticamente. De igual modo, pode ajudar a identificar incendios, inundacoes, fugas de gas e,
com base em parametros de automacao, ativar medidas de seguranca e informar as autoridades
competentes.
5. Comunicacao
Este tipo de sistemas costumam oferecer uma forma de comunicacao com o exterior permitindo
que os utilizadores interajam com a habitacao atraves da Internet. Estas interacoes podem servir,
por exemplo, para visualizar cameras de vigilancia, controlar os aparelhos, etc. Ao mesmo tempo
este modulo completa o modulo da Seguranca mencionado anteriormente. Por exemplo, no caso
de um alerta ser despoletado, este pode ser automaticamente reportado, por exemplo, via SMS.
1.1 Motivacao
Os primeiros anos apos o aparecimento da domotica nao despertaram muito interesse aos consumi-
dores principalmente devido aos elevados custos associados. No entanto, com o evoluir da tecnologia
e a diminuicao dos custos dos dispositivos, cada vez mais a domotica tem vindo a ser aceite pelos
consumidores.
Atualmente, as habitacoes albergam um conjunto enorme de aparelhos que facilitam as nossas
vidas. Acontece que com o elevado numero de aparelhos e muito facil, por distracao ou descuido
ficarem ligados desnecessariamente, podendo provocar gastos inesperados de energia que no final
do mes pesam nas contas. Um dos exemplos mais banais e comuns e, por exemplo, deixar luzes de
corredores ou outras divisoes ligadas durante horas a fio e sem qualquer utilidade ou ate mesmo a
televisao ligada sem ninguem a assistir. E facil reconhecer que o avanco da tecnologia nos facilitou
e melhorou a qualidade de vida. No entanto, como se pode constatar, muitas das vezes tambem nos
podem trazer alguns desagrados como o exemplo anterior.
Um sistema domotico apenas e conseguido com a interacao entre os diversos dispositivos. Esta
2
interacao e conseguida atraves da implementacao de protocolos e tecnologias normalizadas tais como
o X10[1], o CEBus (ANSI/EIA600)[2] (Consumer Eletronics Bus), o LonWorks (ANSI/EIA 709.1-A)[3],
o KNX[4], sucessor do EIB[5] (European Installation Bus) e outros protocolos standard. Existem ainda
protocolos proprietarios desenvolvidos por algumas empresas que oferecem solucoes integrais. Grande
parte das vezes, estas solucoes proprietarias tendem a nao oferecer compatibilidade com outros siste-
mas por questoes de marketing o que se torna numa desvantagem para o consumidor final pois este
fica dependente de um conjunto limitado de fabricantes. Alem disso estas solucoes sao, na maioria das
vezes, concebidas de raiz para uma determinada tecnologia, requerendo para isso a intervencao de
tecnicos especializados. Estes factos podem condicionar futuras alteracoes ao sistema, sendo por isso
pouco flexıveis.
Assim sendo o mercado carece essencialmente de solucoes flexıveis e compatıveis entre si. Por isso
mesmo muitos utilizadores idealizam os sistemas domoticos como algo complexo e difıcil de usar. A
flexibilidade e um fator extremamente importante neste tipo de sistemas uma vez que, por exemplo, num
ambiente domestico os dispositivos e as necessidades do utilizador podem mudar com o tempo, sendo
que o sistema pode ser adaptado de uma forma mais simples e economica as novas necessidades.
Por forma a colmatar algumas dessas falhas no mercado existem solucoes como o DomoBus[6]
(solucao descrita no capıtulo 3.1). Com um vasto conjunto de protocolos, torna-se muitas das vezes
complicado quando se pretendem implementar solucoes que integram varias tecnologias uma vez que
os protocolos referidos sao incompatıveis entre si. Estas solucoes visam entao facilitar a comunicacao
entre componentes que implementam protocolos de comunicacao diferentes e ao mesmo tempo dispo-
nibilizar uma camada de abstracao permitindo o desenvolvimento de novas funcionalidades. Alem disso
o DomoBus assenta numa descricao dinamica do sistema domotico recorrendo a tecnologias como o
XML - eXtensible Markup Language, proporcionando uma maior flexibilidade.
Tal como o proprio sistema, a sua interface e de igual ou maior importancia. E atraves da interface
que o utilizador interage com o sistema domotico e, por isso, esta necessita de ser funcional. Na
maioria das solucoes domoticas existentes a interface e igualmente inflexıvel, sendo muitas das vezes
construida para uma determinada situacao ou oferecendo poucas funcionalidades.
Por outro lado, nos sistemas mais flexıveis, como o DomoBus, para manter a flexibilidade, a sua
interface deve, de igual modo, ser dinamica e adaptavel. Esta situacao provoca um aumento do grau
de complexidade aquando do desenvolvimento da interface. Isto acontece dado que esta deve refletir
de uma forma dinamica as alteracoes que o utilizador possa querer fazer ao sistema, mantendo a
funcionalidade e simplicidade.
A geracao dinamica de interfaces e o tema deste trabalho, focado-se num sistema em particular,
nomeadamente o DomoBus.
1.2 Objetivos
Com este trabalho pretende-se, em primeiro lugar, perceber qual o estado da arte na area da domotica.
Pretende-se analisar um conjunto de sistemas disponıveis no mercado e perceber quais os seus pontos
3
fortes e as suas fraquezas e quais as funcionalidades que oferecem aos utilizadores. E ainda impor-
tante perceber que tipo de interfaces estes sistemas oferecem e qual o seu grau de personalizacao e
flexibilidade.
A posteriori pretende-se especificar e desenvolver uma interface para o sistema domotico Domo-
Bus. Esta interface deve ser capaz de se construir de uma forma dinamica e ser capaz de se adaptar
a qualquer sistema DomoBus, no sentido em que, basta fornecer uma descricao generica do sistema
atraves de XML e a interface se auto-constroi e configura. A interface deve ainda obedecer a regras
de personalizacao especificadas pelo utilizador. Para que a capacidade de personalizacao seja eficaz,
pretende-se ainda especificar um modelo XML que expresse uma quantidade finita de regras corres-
pondentes determinados elementos da interface, sendo que estas regras devem ser especificadas pelo
utilizador.
Alem disso esta interface deve ser capaz de comunicar, enviar e receber mensagens, bem como
fazer a sua retransmissao no caso de detecao de erros, utilizando para isso um protocolo bem definido
do sistema DomoBus.
Pretende-se entao que esta interface juntamente com o sistema DomoBus sejam altamente flexıveis
e personalizaveis podendo mais facilmente ir ao encontro das necessidades dos utilizadores, colma-
tando falhas atualmente existentes no mercado da domotica.
Por forma a aferir a funcionalidade da interface pretende-se ainda realizar um conjunto de testes
com utilizadores reais e assim perceber em que sentido a interface deve ser melhorada.
Este trabalho contribui para a concecao de um sistema domotico robusto e flexıvel permitindo-lhe
ainda um nıvel superior de usabilidade e interacao com o utilizador. Deixa-se ainda, como contri-
buto, uma nova analogia para a utilizacao dos dispositivos moveis nos sistemas domoticos, atraves da
introducao de um novo modo de interacao do utilizador com a interface. Este modo de interacao po-
dera encorajar os utilizadores a substituir os controlos de parede, como os termostatos ou interruptores
inteligentes que facilmente podem ascender a centenas de euros, por uma solucao mais economica e
com um grau de funcionalidade superior.
1.3 Organizacao da Tese
Este documento encontra-se ainda subdividido em outros quatro capıtulos.
No segundo capıtulo e dado a conhecer o estado da arte no que diz respeito a alguns dos sistemas
domoticos disponıveis no mercado. Para cada sistema e feita uma analise das suas funcionalidades e,
no final, e feita uma apreciacao crıtica dos sistemas analisados.
Posteriormente, no terceiro capıtulo e apresentada a solucao proposta que visa colmatar as falhas
existentes no mercado dos sistemas domoticos. E apresentado o DomoBus, sistema este que servira
de base a todo o trabalho desenvolvido. De seguida e apresentada a solucao proposta. Qual a sua
arquitetura e funcionalidades. Sao descritos os seus modos de operacao, o processo da construcao da
interface e ainda e abordado um simulador de teste desenvolvido.
No capıtulo quatro sao apresentados os resultados obtidos com a solucao proposta. Sao analisados
4
alguns aspetos relacionados com o desempenho da solucao e posteriormente feita uma analise dos
testes realizados com os utilizadores. No fim sao apresentadas um conjunto de melhorias para a
solucao desenvolvida.
Por fim, no capıtulo cinco sao apresentadas as conclusoes deste trabalho e quais os objetivos
atingidos. E ainda feita uma analise do possıvel trabalho futuro, nao so da aplicacao mas de todo o
sistema DomoBus.
5
6
Capıtulo 2
Estado da Arte
Ao longo dos anos foram aparecendo alguns protocolos de comunicacao para os sistemas domoticos,
trazendo mais funcionalidades e melhores caracterısticas. Alguns destes sao protocolos de comunicacao
abertos, como por exemplo o X10[1], o CEBus (ANSI/EIA 600)[2] (Consumer Eletronics Bus), o LonWorks
(ANSI/EIA 709.1-A)[3], o KNX[4], sucessor do EIB[5] (European Instalation Bus) e outros protocolos
standard. A par destes protocolos, existem no mercado solucoes proprietarias, desenvolvidas por algu-
mas empresas.
Com um vasto conjunto de protocolos, torna-se muitas das vezes complicado quando se preten-
dem implementar solucoes que integram varias tecnologias uma vez que os protocolos referidos sao
incompatıveis entre si. Neste sentido existem solucoes como o OpenHab[7] ou o DomoBus[6] que fa-
cilitam a comunicacao entre componentes que implementam protocolos de comunicacao diferentes e
ao mesmo tempo disponibilizam uma camada de abstracao permitindo o desenvolvimento de novas
funcionalidades.
Num sistema domotico, tal como em muitos outros sistemas, a interface com o utilizador desempe-
nha um papel bastante importante. De um certo modo ela tenta esconder a complexidade do sistema
tentando torna-lo mais facil de utilizar. Com os avancos tecnologicos temos vindo a assistir a uma
evolucao das interfaces com que lidamos no dia-a-dia. Um bom exemplo disso sao as interfaces que
recorrem a touchscreens que, em muitos casos, proporcionam um grau maior de comodidade ao uti-
lizador. Dada a natureza deste tipo de interfaces e bastante comum encontrarem-se solucoes para
sistemas domoticos que recorrem as mesmas, tal como se vai poder verificar ao longo desta seccao.
Um dos fatores mais importantes para a disseminacao deste tipo de interfaces foi o aparecimento dos
smartphones e por isso e bastante comum serem apresentadas aplicacoes moveis para o controlo de
Sistemas Domoticos.
Outro tipo de interface que tambem e largamente utilizado por estes tipos de sistema sao as In-
terfaces web-based. Muitos dos sistemas possibilitam o acesso atraves da Internet recorrendo a este
tipo de interfaces uma vez que sao bastante versateis. Geralmente, neste tipo de interfaces e apenas
necessaria uma ligacao a Internet e um dispositivo que possua um browser, seja um dispositivo movel
ou nao.
7
No decorrer deste capıtulo sao entao apresentadas algumas solucoes de interfaces para Sistemas
Domoticos existentes no mercado. Para cada solucao sao apresentados os componentes principais
que a constituem como, por exemplo, modulos de controlo e feita uma apresentacao da(s) interface(s)
disponibilizada(s). De notar que alguns sistemas disponibilizam interfaces web based, interfaces locais
touchscreen ou interfaces para dispositivos moveis.
Dado que a maioria das solucoes domoticas existentes sao proprietarias, torna-se complicado obter
detalhes relativamente a sua forma de implementacao ou mesmo dos componentes que as constituem.
No entanto, uma vez que o foco deste trabalho sao as interfaces, esse fator nao impede que se faca
uma analise da interface.
Desta forma o objetivo deste estudo passou por perceber o funcionamento e a implementacao das
solucoes, caso existisse informacao disponıvel, e, de certa forma, avaliar a interface com o sistema
salientando os pros e contras de cada uma. No estudo foram analisados alguns sistemas funcionais e
uma proposta de um design de uma interface.
No final da seccao e feita uma analise crıtica relativa as solucoes apresentadas neste capıtulo por
forma a sumarizar as qualidades e falhas de cada uma.
2.1 Loxone
O Loxone[8] e uma solucao domotica proprietaria baseada em modulos. O seu componente principal e
denominado por miniserver, um controlador eletronico que funciona como centro de controlo de todo o
sistema.
Estao a disposicao duas versoes deste controlador. Uma delas, denominada por Miniserver Go,
e a mais indicada para instalacoes em habitacoes ja existentes e que nao possuam infraestruturas
dedicadas para este tipo de sistemas. Esta versao pode utilizar a tecnologia Loxone Air que permite
fazer a comunicacao com os dispositivos atraves de radio frequencia.
A outra versao e mais orientada para habitacoes que foram construidas tendo em conta as neces-
sidades deste tipo de sistemas, como por exemplo estarem equipadas com infraestruturas eletricas e
de comunicacao proprias. Por isso esta e uma solucao mais robusta e capaz de se integrar melhor na
habitacao. Este miniserver pode, por exemplo, ser instalado dentro de um quadro eletrico preparado
para o efeito.
A este controlador podem ser adicionados modulos, obtidos separadamente. Estes modulos tem
como principal funcao acrescentar novas funcionalidades e capacidades de comunicacao, como por
exemplo o Loxone Air mencionado anteriormente. Outros modulos podem, por exemplo, ser modulos
de controlo de iluminacao como e o caso do RGBW Dimmer Air que pode controlar um conjunto de
Leds RGBW (Red Green Blue White) e modulos de controlo atraves de Infravermelhos.
Uma das funcionalidades disponıveis e a ligacao dos dispositivos de controlo a rede de casa e poder
utilizar servidores de musica ou posteriormente fazer a ligacao com servicos cloud da propria empresa
e que disponibilizam dados acerca da meteorologia, servicos de chamadas, E-mail e outros.
Por forma a interagir com estes componentes sao disponibilizadas gratuitamente interfaces com o
8
Figura 2.1: Historico de temperatura
utilizador distintas. Uma delas e uma interface web e pode aceder-se a uma demonstracao atraves de
um endereco1, usando como utilizador web e password web.
Logo apos efetuar o login o utilizador e redirecionado para uma pagina principal onde se destaca
uma area que permite explorar a habitacao por divisoes e uma outra area que permite explorar por
categorias, como por exemplo aquecimento ou iluminacao. Existe ainda uma zona mais abaixo onde
sao apresentados os favoritos do utilizador, permitindo um acesso mais rapido aos mesmos. Nesta
versao de demonstracao nao se consegue perceber como e feita a alteracao dos itens que se encontram
nos favoritos. Podem ainda personalizar-se cenarios pre-configurados, como por exemplo apagar todas
as luzes.
Um aspeto interessante desta interface e, por exemplo, consultar historicos por dia, mes ou ano,
sob a forma de um grafico como e o caso da temperatura, tal como ilustra a Figura 2.1. Na figura pode
ver-se que durante um determinado perıodo de tempo a temperatura se manteve constante uma vez
que o grafico nao mostra flutuacoes.
A aplicacao permite tambem programar tarefas simples. Tomando como exemplo o aquecimento,
podem definir-se os intervalos dos dias da semana e a temperatura desejada. Podem ainda definir-se
temperaturas desejaveis para determinadas situacoes, por exemplo quando se esta de ferias fora de
casa.
Para alem desta interface web e tambem disponibilizada uma aplicacao movel para Android e iOS.
Para estas plataformas existem duas versoes, uma classica, muito parecida a aplicacao web e outra
em versao beta com um design diferente.
Apresenta-se em seguida a versao mais recente da aplicacao e as suas principais caracterısticas.
No caso do Android, esta versao esta disponıvel apenas para versoes iguais ou superiores ao Android
4.4.
Talvez por ser uma versao beta, uma grande barreira no inıcio da utilizacao da aplicacao e o facto
desta nao ter suporte para nenhuma outra lıngua que nao o Alemao. No entanto esse fator nao impediu
que fosse feita uma exploracao da interface.
Comparativamente com a interface web, esta e muito mais interativa e personalizavel. Por outro lado
1http://demominiserver.loxone.com:7778/
9
Figura 2.2: Pagina inicial - Aplicacao Android
Figura 2.3: Grafico fornecimento de energia
as funcionalidades sao essencialmente as mesmas.
Numa fase inicial e feita uma ligacao a um Loxone miniserver atraves do seu endereco. Neste caso
pode utilizar-se a versao de demonstracao, anteriormente utilizada na interface web. Posteriormente e
permitido ao utilizador que personalize a sua pagina inicial escolhendo de uma lista o tipo de habitacao
que mais se assemelhe com a sua, bem como a paisagem que a envolve.
Nesta pagina inicial e entao mostrada a habitacao escolhida inserida na paisagem, bem como alguns
itens informativos, como por exemplo a temperatura exterior, meteorologia, a hora no nascer e por do
sol, tal como ilustrado na Figura 2.2. Em baixo e apresentada uma especie de barra da tarefas que
e comum a todos os ecras e que permite um acesso rapido a pagina inicial, aos favoritos, e aceder
rapidamente a uma listagem de recursos por divisao ou categoria tal como na interface web.
Um exemplo interessante de representacao da informacao sobre o estado dos dispositivos nesta
interface verifica-se para o caso dos recursos renovaveis. Tal como se pode analisar na Figura 2.3 a
aplicacao faz uma representacao das fontes de energia que abastecem a habitacao, neste caso a partir
da energia solar. O diagrama representado indica o sentido do fluxo de energia e a quantidade de
energia que cada componente fornece/consome. Desta forma o utilizador pode facilmente visualizar a
eficiencia dos seus recursos renovaveis e ate mesmo identificar se esta a produzir mais energia que o
necessario e possivelmente estar a obter lucros com a venda de energia.
Tal como na versao web, esta versao tambem permite visualizar estatısticas atraves de graficos.
10
A interacao com o grafico e feita da mesma forma, utilizando um marcador que pode ser deslocado
para a esquerda e para a direita mostrando o valor do grafico naquela posicao. Apesar disso, uma cara-
terıstica importante que nao esta disponıvel e a apresentacao de valores acumulados por determinadas
unidades de tempo como o dia, mes ou ano.
Uma outra limitacao, presente em ambas as versoes, e a definicao de favoritos, sendo que nao
existe forma de adicionar ou remover itens da lista de favoritos.
Nesta versao existem certas funcionalidades da interface que se revelam complicadas de utilizar, ou
pelo menos mais confusas. Um dos exemplos e o controlo da temperatura de uma divisao. Na interface
e mostrada a temperatura da divisao sobre um fundo que varia a sua cor consoante o desvio que existe
entre essa temperatura e a temperatura desejada na habitacao. Por baixo existe uma especie de regua
que representa as horas do dia e cada segmento de tempo tem como fundo a cor correspondente a
variacao de temperatura nessa altura. Um dos problemas e que nao existe uma forma de interagir
com esta informacao. Outro problema nesta seccao e a consulta de informacao e das temporizacoes.
Do lado esquerdo estao uns ıcones que servem de menu. Num dispositivo mais pequeno, como por
exemplo um smartphone, podem revelar-se difıceis de aceder. Alem disso, quando se acede a um
destes ıcones, nao existe uma forma eficaz para voltar atras ou aceder aos outros ıcones. Aliado a
estas dificuldades, um dos problemas conhecidos pela empresa e o funcionamento menos correto do
botao back em algumas situacoes. Durante os testes foi possıvel verificar situacoes destas.
De uma forma geral esta solucao aparenta ser bastante completa sendo que a principal desvan-
tagem se prende com o facto de que para expandir as funcionalidades do sistema, e necessario o
investimento em modulos especıficos para o efeito. Um exemplo e a existencia de modulos proprios
para a utilizacao de chaves eletronicas em detrimento das chaves tradicionais.
Uma das grandes vantagens e o facto de existirem duas solucoes relativamente equivalentes, onde
uma delas e mais indicada para habitacoes onde foi feito planeamento previo antes da construcao
e outra para novas instalacoes em habitacoes sem qualquer tipo de preparacao previa. A primeira
pode ser expandida com a utilizacao de modulos e, por isso apresenta mais vantagens do que a se-
gunda. As aplicacoes necessarias para a utilizacao do sistema sao disponibilizadas gratuitamente e em
varias plataformas. Dado que neste momento algumas dessas aplicacoes ainda se encontram em de-
senvolvimento, algumas funcionalidades podem nao funcionar corretamente. No entanto, com futuras
atualizacoes, espera-se que as funcionalidades das mesmas melhorem.
2.2 OpenHab
O OpenHab[7] e uma solucao open-source que visa integrar varias tecnologias da area da domotica,
permitindo definir regras de automacao e de certa forma, disponibilizar uma interface de monitorizacao
e controlo ao utilizador. O sistema e implementado na linguagem Java, o que o torna bastante portavel,
sendo que e capaz de correr em qualquer dispositivo compatıvel com JVM (JAVA Virtual Machine),
como por exemplo o Raspberry Pi2. Uma caracterıstica interessante desta solucao e o facto de ser
2http://www.raspberrypi.org/
11
disponibilizada uma API3 - Application Programming Interface que possibilita a integracao de outros
sistemas.
Na maioria dos sistemas disponibilizados por outras empresas a forma de como se podem configurar
os dispositivos e os casos de uso mais comuns vem predefinidos, o que se pode tornar um entrave
a configuracoes que sirvam as necessidades menos comuns dos utilizadores. Para evitar este tipo
de entraves, esta solucao disponibiliza uma ferramenta designada OpenHab Designer que permite ao
utilizador configurar todo o tipo de regras que deseje, eliminando assim as restricoes. No entanto, o
utilizador necessita de ter conhecimentos avancados para criar ou modificar regras.
Um exemplo de uma regra pode ver-se a seguir:
import org.openhab.core.library.types.*
rule demo
when
Item lights received command OFF
then
say(‘‘Lights off.’’)
end
Por ser uma solucao open-source podem existir colaboracoes por parte de utilizadores mais ex-
perientes, o que ajuda a identificar novas funcionalidades que possam ser uteis a um conjunto mais
alargado de utilizadores. Desta forma o software tende a evoluir de acordo com a necessidade e as
experiencias dos utilizadores. Alem disso, utilizadores mais experientes podem desenvolver interfa-
ces com outros dispositivos, aumentando assim a compatibilidade com os dispositivos existentes no
mercado.
Ao nıvel da arquitetura, o OpenHab utiliza um servidor central que fica responsavel pela logica da
aplicacao, de disponibilizar uma forma de comunicacao com a(s) interface(s) com o(s) utilizador(es) e
de armazenar o estado dos dispositivos. Alem disso necessita ainda de interagir com uma rede de
dispositivos de controlo, sendo que estes estao associados a dispositivos reais. Estes dispositivos de
controlo servem de abstracao ao nıvel da comunicacao uma vez que estes podem comunicar utilizando
protocolos diferentes, como por exemplo o KNX ou o x10. Esta abstracao e conseguida atraves da
implementacao de componentes para a inclusao de cada um dos protocolos, sendo que estes compo-
nentes comunicam com um bus designado OpenHab Event Bus, atraves de mensagens normalizadas.
Quanto ao nıvel de interface esta solucao oferece duas abordagens sendo elas para dispositivos
moveis (Android e iOS) e baseadas em web. Ambas as interfaces necessitam de se ligar ao servidor
central atraves de um URL. Por omissao as interfaces trazem uma versao de demonstracao com al-
guns dispositivos, permitindo que se explore um pouco a aplicacao. Estas versoes moveis e baseadas
em web sao bastante semelhantes pelo que de seguida apenas sao mostrados conteudos da versao
Android.3https://github.com/openhab/openhab/wiki/REST-API
12
Figura 2.4: OpenHab - Interface Android
A Figura 2.4 ajuda na percecao do tipo de interface deste sistema, sendo que nesta sao mostrados
diferentes estados. No menu principal (primeiro ecra da Figura 2.4), para alem de serem mostradas a
data e temperatura exterior, e feito um agrupamento de recursos por pisos ou por recursos do exterior.
A aplicacao nao permite mudar esta forma de agrupar os recursos, por exemplo por categorias como
iluminacao, climatizacao, etc, fazendo com que a aplicacao seja um pouco menos flexıvel que outras
analisadas.
Ao escolher uma das categorias, por exemplo o primeiro piso, a aplicacao mostra ao utilizador
uma listagem de todas as divisoes existentes (nao esta ilustrado na figura) e, a partir daı o utilizador
pode aceder aos recursos por divisao. Os recursos sao entao todos listados no mesmo ecra o que
pode dificultar o acesso a alguns dispositivos uma vez que a lista pode ser extensa. Para melhorar
a organizacao, os dispositivos sao agrupados por tipo, por exemplo, todos os que se relacionam com
iluminacao, estao todos juntos e assim sucessivamente para outros tipos. A apresentacao dos grupos
aparenta ser feita por ordem alfabetica, nao permitindo outro tipo de personalizacao.
A forma como o utilizador pode interagir com os dispositivos e bastante simples. Essencialmente
existem propriedades que apenas suportam dois estados (on e off ), outras propriedades, como e o
caso da temperatura, onde o utilizador pode utilizar botoes + e - para aumentar ou diminuir o valor,
respetivamente. Quando existem cenarios que podem ser aplicados, por exemplo o modo de jantar,
estes podem aparecer sob a forma de um botao ou de uma lista do estilo dropdown. No caso de
algumas propriedades que variam de acordo com uma percentagem, como por exemplo o ajuste da
intensidade da luz, existe uma slide bar onde se pode ajustar o valor de uma forma mais interativa.
Uma outra funcionalidade interessante e, por exemplo, no caso de se utilizar iluminacao RGBW (Red,
Green, Blue, White) ser possıvel utilizar um controlo especıfico com um seletor de cor onde o utilizador
pode escolher a cor, bem como o brilho e a saturacao. Este tipo de iluminacao pode ser util em
algumas situacoes, por exemplo, definir uma luz ambiente para uma sessao de cinema, ou personalizar
a iluminacao de espacos exteriores.
Nesta versao de demonstracao a aplicacao permite, de uma forma automatica identificar grupos, no
13
sentido em que agrupa, por exemplo, todas as luzes ligadas, todos os sistemas de climatizacao ligados,
entre outros. Desta forma o acesso aos dispositivos ativos torna-se bastante mais facil e rapido. Alem
disso, existem opcoes para desligar todos os dispositivos de um dado grupo, o que permite, por exem-
plo, que todas as luzes sejam desligadas de uma forma muito rapida. Nesta versao de demonstracao
nao se percebe se estes grupos estao pre-definidos, ou se sao grupos geridos automaticamente pelo
sistema de controlo e nao pela aplicacao. Caso nao sejam geridos pelo sistema, a aplicacao tambem
nao oferece forma de personalizar ou criar novos grupos.
De uma forma geral esta solucao esta bem estruturada e permite a integracao de varias tecnolo-
gias existentes no mercado atraves de componentes que permitem a comunicacao utilizando varios
protocolos. Apesar de nao ter custos, os utilizadores necessitam de ter bastante experiencia, principal-
mente ao nıvel da programacao e logica para poder construir regras no sistema, obtendo assim alguma
automacao.
Quanto ao nıvel das interfaces com o utilizador disponibilizadas, estas sao bastante simples e de
alguma forma mais limitadas, no entanto sao funcionais.
De destacar que todo o software disponibilizado e livre e open-source.
2.3 Computer Zen Home Automation
Ao contrario das solucoes ate agora analisadas, esta solucao[9] e construida a medida para cada
cliente. Uma das justificacoes para a utilizacao desta metodologia pode encontrar-se no seu web-
site: “Since no two people are the same, we individualize our home automation systems to your uni-
que needs.” (Uma vez que nao ha duas pessoas iguais, nos individualizamos os nossos sistemas de
automacao de acordo com as suas necessidades).
As opinioes podem diferir a cerca desta afirmacao. Esta abordagem pode trazer algumas van-
tagens, no entanto tambem existem desvantagens. Um sistema desenvolvido a medida do cliente
consegue abranger as necessidades mais especificas de um utilizador, proporcionando-lhe maior co-
modidade. Um dos maiores problemas que este tipo de solucoes feitas a medida trazem e o facto de
que o desenvolvimento e concecao inicial ser muito mais demorado e mais dispendioso, precisamente
por serem desenvolvidos a medida. Analogamente, e muito mais difıcil fazer alteracoes ao sistema,
por exemplo em caso de remodelacoes. Nestas situacoes e necessario repensar num novo sistema e
instala-lo, o que traz mais custos. Um outro exemplo e no caso de o utilizador necessitar de modificar
o comportamento do sistema. Nestes casos pode ser necessaria a intervencao por parte de tecnicos
especializados levando tambem a custos adicionais.
De uma forma geral, o servico prestado foca-se essencialmente no desenho e instalacao do sistema.
Os dispositivos domoticos utilizados sao desenvolvidos por outras empresas, como por exemplo HAI
(Leviton)[10] e Control4[11] para as interfaces com o utilizador, Crestron[12] para sistemas multimedia,
NuVo[13] para audio, entre outros.
No caso da interface com o utilizador disponibilizada pela HAI existem 3 abordagens possıveis. Exis-
tem aparelhos touchscreen que podem ser fixos ou moveis, existem aplicacoes para PC e aplicacoes
14
Figura 2.5: Interface HAI Android
para dispositivos moveis. Nenhum destes produtos esta disponıvel para demonstracao e todo o soft-
ware disponibilizado para o cliente e pago, o que dificulta o processo de avaliacao. Em seguida e feita
uma descricao muito geral do que foi possıvel apreciar das interfaces disponıveis.
As aplicacoes disponibilizadas para PC contemplam versoes para os vendedores, possivelmente
para poderem configurar o sistema e versoes para os utilizadores. Dentro das versoes para os utiliza-
dores, existe uma com uma interface mais generica, onde o utilizador pode fazer configuracoes no seu
sistema, como por exemplo alterar temporizadores e outras regras. Existe ainda outro software apenas
dedicado a personalizacao da interface. Neste sentido o utilizador pode, de uma forma muito basica,
alterar o aspeto da interface dos aparelhos touchscreen.
Existem ainda aplicacoes moveis, disponibilizadas tanto para Android como para iOS e Kindle. A
aplicacao que proporciona o controlo de todo o sistema tambem e paga (15.37epara Android, 24.99epara
iOS e 15.95epara o Kindle), no entanto existem outras aplicacoes gratis para o controlo de alguns
modulos especıficos como, por exemplo, sistemas de audio de alta fidelidade.
De uma forma muito geral pode ver-se na Figura 2.5 que e feita uma divisao por categorias e posteri-
ormente pode aceder-se aos controlos, por cada divisao. Neste caso, no controlo da temperatura, pode
notar-se que existem opcoes rapidas para ativar ou desativar o controlo automatico da temperatura,
definir temperaturas mınimas e maximas para o inicio automatico dos sistemas de ar-condicionado e
outras funcionalidades ativar a ventilacao ou colocar em standby.
Por forma a que estas aplicacoes funcionem e necessario ainda que seja instalado um sistema de
domotico proprio, desenvolvido pela mesma empresa.
Existe ainda a possibilidade de utilizar equipamentos touchscreen de 7 polegadas designados pela
empresa por OmniTouch. O software destes dispositivos pode ser personalizado utilizando as aplicacoes
para PC.
Analisando a solucao descrita pode ver-se que esta e um pouco diferente das restantes. Em pri-
meiro lugar foca-se num sistema desenvolvido a medida do cliente, o que por um lado pode ser mais
vantajoso caso este necessite de requisitos muito especıficos. Por outro lado o sistema pode tornar-se
mais adverso a alteracoes e necessitar de intervencoes especializadas. Quanto as interfaces dispo-
15
nibilizadas, o conceito de dispositivos touchscreen fixos na parede torna-se interessante caso existam
varios numa habitacao. Caso contrario torna-se incomodo para o utilizador ter de se deslocar sempre a
um ponto da habitacao para fazer o controlo. As interfaces destes dispositivos podem ser modificadas
pelo utilizador, no entanto requer que este adquira outras aplicacoes e ao mesmo tempo necessita de
alguns conceitos considerados avancados para a maioria dos utilizadores.
Este sistema tem algumas desvantagens comparativamente com outros sistemas, no sentido em
que o utilizador, para alem de ter de adquirir todo o sistema de controlo, tambem tera de pagar por
aplicacoes que lhe permitem interagir com o sistema. Alem disso nao estao disponıveis versoes de
teste para que os utilizadores possam avaliar a qualidade das aplicacoes ou perceber o funcionamento
do sistema.
2.4 HEIMA
Para alem destes sistemas, o estudo efetuado inclui ainda um sistema nao funcional, ou seja, que nao
esta implementado. Este e apenas um draft de um designer para uma interface para um sistema de
controlo domotico.
Este draft denomina-se HEIMA[14], palavra islandesa que designa casa. E apenas uma interface me-
ramente ilustrativa, mas pode vir a ser aplicada numa aplicacao real. Foi desenvolvida pelo designer
Dimitrij Paskevic no ambito do seu projeto de licenciatura.
Apesar de ser apenas um design considera-se que este pode trazer algumas novas ideias para as
interfaces dos sistemas domoticos, desde o embelezamento a algumas novas formas de interacao e
controlo.
A figura seguinte ajuda a perceber a interface concebida onde se podem facilmente identificar tres
zonas principais. A zona de notificacoes no topo, uma zona de interacao ou controlo no centro e no
fundo uma zona de acesso rapido a varias categorias. As categorias listadas incluem, por exemplo, o
acesso rapido ao controlo de ar condicionado, iluminacao, dispositivos de seguranca e outros.
Na zona de notificacoes para alem de aparecerem as notificacoes e dar acesso a um painel para a
leitura das mesmas, ha ainda um acesso rapido no canto superior direito a comandos de voz.
Na zona de controlo (zona central) o sistema permite ter acesso de forma rapida ao controlo da tem-
peratura ambiente, bem como a outros dispositivos ou informacoes, como por exemplo a meteorologia.
A barra que se localiza por baixo da informacao da temperatura funciona como um elevador horizontal
que, a medida que e deslocado, revela mais informacoes. O design nao revela se e ou nao possıvel
personalizar esta zona, no entanto seria uma funcionalidade util no ponto de vista do utilizador.
No fundo da zona central existe ainda uma area reservada ao controlo da entrada e saıda de pes-
soas. Ou seja, o sistema seria capaz de indicar quais as pessoas que estao em casa ou nao e indicar
ha quanto tempo saıram.
Ao aceder a uma zona de acesso rapido das diversas categorias, na zona inferior, por exemplo a
iluminacao, entra-se numa zona com mais detalhes de configuracao tal como e mostrado na Figura 2.7.
Na interface podem destacar-se claramente 3 zonas principais, sendo elas a mesma zona de acesso
16
Figura 2.6: Interface HEIMA
Figura 2.7: Interface HEIMA
rapido as diferentes categorias disponıveis, no fundo, uma zona no lado esquerdo para a escolha de
uma divisao e a direita a zona de controlo. Existe ainda acesso ao painel de notificacoes no topo da
interface.
No caso particular da iluminacao o utilizador pode escolher, por exemplo, divisoes que possuam
elementos de iluminacao como e o caso do quarto. Ao selecionar a divisao a area de controlo mais a
direita mostra os dispositivos desta categoria para que se possam fazer ajustes. De notar que o ajuste
da iluminacao e feito atraves de sliding bars que ajustam a variacao da iluminacao em percentagem.
Cada conjunto de iluminacao pode estar associado um dispositivo de controlo automatico como, por
exemplo, sensores de movimento ou iluminacao e, nesses casos, estes podem ser controlados atraves
da alteracao de estados on e off. Esta situacao pode ser util, por exemplo, se o utilizador necessitar
que um determinado elemento de iluminacao deixe de ser controlado por um sensor de iluminacao e
passe a ser controlado de forma manual.
Esta interface foi tambem pensada para ser incluıda em dispositivos que podem estar fixos numa
parede da habitacao, tal como nos revela a Figura 2.8. Neste modo a interface e um pouco mais discreta
e com menos opcoes de controlo e da a ideia de que apenas disponibiliza o acesso a algumas opcoes
17
Figura 2.8: Interface HEIMA - dispositivos de parede
rapidas. Na figura nao se percebe se e permitido algum tipo de acesso a outros dispositivos ou se
apenas servira para controlar a temperatura de uma forma rapida.
A forma de controlar a temperatura e bastante original e intuitiva. Basta fazer um movimento circular
e a temperatura desejada sobe ou desce consoante o movimento se faz no sentido horario ou anti-
horario, respetivamente. Imediatamente ao lado aparece qual o valor que a temperatura vai subir ou
descer por forma a que o utilizador tenha sempre a percecao do que esta a fazer.
Uma outra vertente bastante interessante desta interface e a sua utilizacao em dispositivos moveis
como, por exemplo, smartphones evitando que o utilizador tenha de se deslocar sempre a uma unidade
de controlo para fazer algumas configuracoes ou simplesmente para consultar notificacoes. Desta
forma garante-se uma maior comodidade no ponto de vista do utilizador. Para esta versao da interface
nao estao disponıveis detalhes suficientes para que se possam retirar conclusoes.
2.5 Analise Crıtica
Na seccao anterior foram apresentadas tres solucoes domoticas disponıveis no mercado e ainda um
design de uma interface. Por forma a que se consigam perceber quais as vantagens e desvantagens
de cada uma e feita uma analise crıtica. Esta avaliacao tera em conta aspetos relacionados com a
arquitetura da solucao bem como o nıvel de funcionalidade das interfaces disponıveis.
A primeira solucao apresentada, o Loxone, apresenta uma arquitetura centralizada baseada na
adicao de modulos por forma a estender as funcionalidades do sistema. Alem disso disponibiliza duas
versoes equivalentes, uma mais orientada para habitacoes com infraestruturas eletricas e de rede bem
planeadas e outra para integracao em habitacoes ja existentes sem qualquer tipo de planeamento.
Por ser baseada em modulos, esta pode tornar-se uma solucao mais cara, ja que alguns modulos
ultrapassam facilmente os 200e. Disponibiliza interfaces tanto para web como para dispositivos moveis
onde, em ambas, se podem destacar a capacidade de visualizacao de historicos sob a forma de graficos
18
e o acesso aos dispositivos por categorias e por divisoes. Na aplicacao movel analisada ainda existem
algumas funcionalidades nao completas e nao tem suporte para outras lınguas que nao o Alemao.
No entanto destacam-se funcionalidades interessantes como a apresentacao de fluxos de energia e a
interacao com os historicos sob a forma de grafico.
O OpenHab e uma solucao bastante interessante, principalmente por ser open-source e gratuita.
Tal como o Loxone, esta tambem e uma solucao centralizada o que pode comprometer a escalabilidade
do sistema. Uma grande vantagem deste sistema e a criacao de regras bastante flexıveis, no entanto,
tal como referido, esse processo exige que os utilizadores tenham conhecimentos sobre programacao
e logica, o que pode ser um entrave a utilizacao desta solucao. O facto deste sistema ser desenvolvido
em JAVA permite que o utilizador tenha maior liberdade na construcao do sistema uma vez que o JAVA
foi desenhado para ser multi-plataforma. Contudo, por requerer uma maquina virtual, o JAVA exige
mais recursos. A interface analisada e bastante simples e pouco personalizavel. Os dispositivos estao
estruturados de acordo com o piso a que pertencem e posteriormente pela divisao. Uma funcionalidade
interessante desta aplicacao e o agrupamento de dispositivos por categorias, por exemplo, os que se
encontram ligados, podendo ser realizadas acoes conjuntas nesse grupo, por exemplo, desligar todos
os dispositivos de uma so vez.
A solucao Computer Zen - Home Automation e um pouco diferente das restantes uma vez que esta
e uma solucao feita a medida do cliente. Tal como discutido anteriormente, podem haver algumas van-
tagens no sentido em que se consegue desenvolver um sistema que vai ao encontro das necessidades
do utilizador. No entanto, esta abordagem induz novos custos, nomeadamente na fase de planeamento
ou, eventualmente numa modificacao do sistema. Nesta solucao sao disponibilizadas varias aborda-
gens para a interface com o utilizador, no entanto e de salientar que todas elas tem um custo extra. A
personalizacao das interfaces pode ser um pouco complexa e exige que o utilizador adquira software
extra.
Por fim, o HEIMA e um conceito de uma interface que se destaca pela sua simplicidade e por
ser minimalista, no sentido em que apresenta poucos itens de cada vez, evitando saturar a interface.
Um aspeto positivo desta interface e que esta sempre presente uma zona de notificacoes e um menu
que permite um acesso rapido as diferentes categorias de equipamentos. Como aspetos menos bons
destacam-se o facto de nao ser possıvel filtrar os equipamentos por divisoes e nao aparentar permitir
personalizacao.
Das solucoes analisadas conclui-se que grande parte delas disponibiliza interfaces com maior ou
menor nıvel de funcionalidade e algumas caracterısticas interessantes. A unica flexibilidade oferecida
por estas interfaces consiste na utilizacao de algumas formas de agrupamento e de diferentes modos
de navegar pelos dispositivos, nomeadamente por categorias ou divisoes. Alem disso, a capacidade de
personalizacao das interfaces analisadas e igualmente reduzida. Em alguns casos essa capacidade de
personalizacao e apenas disponibilizada mediante da aquisicao de programas pagos.
19
20
Capıtulo 3
Solucao Proposta
As solucoes analisadas no capıtulo anterior falham essencialmente em alguns pormenores bastante
importantes - a flexibilidade e a facilidade de adaptacao ao utilizador. Apesar de disponibilizarem ao
utilizador um conjunto bastante alargado de funcionalidades tanto de controlo como de visualizacao,
as solucoes analisadas apenas permitem que se adicionem favoritos sob a forma de atalhos. Mais
ainda, essas solucoes disponibilizam interfaces de controlo que sao genericas, no sentido que existe
um conjunto pequeno de dispositivos que correm essas interfaces, como os tablets, e a habitacao e
controlada sempre do mesmo modo em todas as interfaces.
A solucao proposta tenta chegar mais longe. Dado que os dispositivos moveis estao cada vez mais
acessıveis, pretende-se que exista um conjunto muito maior de dispositivos de interface que podem
estar localizados, idealmente, em todas as divisoes da habitacao, podendo mesmo haver mais do
que um em cada divisao. Desta forma, a aplicacao desenvolvida, para alem de permitir o controlo
da habitacao de uma forma generica tal como as outras solucoes, incorpora tambem um modo de
operacao dedicado a cada divisao. Neste modo de operacao, a aplicacao mostraria os controlos mais
frequentes numa dada divisao, como por exemplo ligar as luzes ou controlar os estores. Na interface,
seriam representados componentes fısicos, como por exemplo interruptores e, imaginando um pequeno
tablet colocado a entrada da divisao de forma analoga a um interruptor normal, o utilizador apenas teria
de tocar no interruptor virtual para ligar ou desligar as luzes como se fosse um interruptor comum. Alem
disso, este tablet seria movel, pelo que o utilizador poderia deslocar-se com ele para um local mais
comodo, e, por ventura, controlar outros dispositivos da habitacao.
Uma das grandes motivacoes para que se usem tablets de baixo custo em cada divisao para o con-
trolo de dispositivos ao inves de controlos fısicos como os interruptores, prende-se essencialmente com
a relacao entre o preco e as funcionalidades oferecidas. Imaginando que numa divisao se pretendem
controlar a temperatura, iluminacao e os estores, no caso de ser utilizado, por exemplo, um sistema
KNX seriam necessarios pelo menos tres modulos diferentes. Alguns desses modulos, por exemplo,
no caso de controladores da temperatura, ascendem facilmente a centenas de euros1. Facilmente se
conclui que o custo um conjunto de tres modulos de controlo pode muito facilmente ascender aos 300e.
1http://www.eibmarkt.com/cgi-bin/eibmarkt.storefront/560ecc040010820e274c4debae380615/Product/View/
NS0813709, acedido em Setembro 2015. (Termostato digital com programador: 101.53e)
21
Figura 3.1: Arquitetura DomoBus
Assim, esta solucao permite, com um tablet de baixo custo, conseguir um nıvel de funcionalidade muito
superior e com custos mais baixos. No caso dos tablets, o mercado oferece uma quantidade enorme
de escolhas comecando em precos tao baixos como 40e.
Esta solucao foi desenvolvida com foco no sistema DomoBus. A seccao seguinte pretende fazer
uma descricao deste sistema e quais as suas caracterısticas que lhe permitem atingir um nıvel de flexi-
bilidade superior as solucoes existentes no mercado. As restantes seccoes realcam as funcionalidades
e caracterısticas da interface desenvolvida.
3.1 DomoBus
O DomoBus e uma framework desenvolvida no ambito academico que permite integrar de forma dis-
tribuıda um vasto conjunto de dispositivos, sensores e atuadores e que tem servido de plataforma
para o desenvolvimento de novas ideias e aplicacoes. O DomoBus possui uma arquitetura distribuıda
permitindo assim uma maior escalabilidade relativamente a outras tecnologias existentes no mercado.
Desta forma, pretende-se que este sistema permita abordar as Super Automated Homes. Este con-
ceito prende-se com a principal nocao de que numa habitacao possa existir um numero muito elevado
de pontos de controlo e sensores, podendo formar uma rede de gestao complexa.
A arquitetura do DomoBus divide-se essencialmente em dois grandes nıveis, sendo eles o nıvel de
Controlo (CL) e o nıvel de Supervisao (SL). A Figura 3.1 ilustra estes dois nıveis.
O nıvel de Controlo baseia-se essencialmente em pequenos modulos de controlo (CM) que podem
22
ser instalados em cada divisao de uma habitacao, controlando um dado conjunto de dispositivos como,
por exemplo, sensores de temperatura ou eletrodomesticos. Num nıvel superior existem os gateways
que sao modulos de hardware responsaveis por um determinado conjunto de modulos de controlo. E
atraves destes geteways que e feita a ligacao dos dispositivos reais ao sistema de supervisao. Por
sua vez, o nıvel de Supervisao que tambem pode ser implementado de forma distribuıda, permite
comunicar com um conjunto de dispositivos do nıvel de Controlo. Alem disso o nıvel de supervisao visa
controlar o comportamento do sistema atraves de um conjunto de regras que podem ser definidas pelo
utilizador. Este nıvel permite ainda a interacao com dispositivos que implementem outros protocolos
como, por exemplo o X10 ou o KNX, tornando o DomoBus um sistema mais flexıvel e que promove a
interoperabilidade entre sistemas.
O facto deste poder ser implementado de forma distribuıda permite atingir um maior nıvel de balan-
ceamento de carga e fiabilidade.
Para a operacao no nıvel de Controlo esta especificado um modelo generico de mensagens [15].
Estas mensagens podem ser de tres tipos, sendo eles o get, set e notify.
A mensagem get e util para quando existe algum tipo de pedido sobre o estado de uma propriedade
de um dado dispositivo em qualquer momento. Um exemplo simples e obter a luminosidade atual de
um dado sensor.
A mensagem set e utilizada no sentido inverso, ou seja, quando o sistema necessita de alterar a
propriedade de um dado dispositivo, por exemplo, desligar uma luz.
Por ultimo, a mensagem notify e transmitida automaticamente pelos dispositivos quando existe uma
variacao no estado de uma propriedade. Considerando um sensor de temperatura, cada vez que exista
uma variacao da mesma, e gerada uma mensagem notify para informar o nıvel de controlo. Desta
forma evita-se o envio sistematico de mensagens get para a obtencao do valor da propriedade.
O DomoBus segue um modelo generico para a descricao de uma habitacao bem como dos apare-
lhos que nela se encontram [16]. Este modelo generico e representado no formato XML onde os dis-
positivos podem conter diversas propriedades e classes sendo que estes sao descritos como atributos
XML. Um aspeto importante sao as propriedades dos dispositivos. O modelo preve que as proprie-
dades possam assumir tres tipos de valor, sendo eles um escalar, enumerados que correspondem a
opcoes, por exemplo ligar/desligar, subir/descer e DomoBus arrays que podem conter qualquer tipo de
dado sob a forma de arrays de bytes. Um exemplo da definicao de um conjunto de propriedades do tipo
enum pode ser visto a seguir.
<EnumValueTypeList>
<EnumValueType ID="1" Name="On-Off">
<Enumerated Name="Off" Value="0" />
<Enumerated Name="On" Value="1" />
</EnumValueType>
<EnumValueType ID="2" Name="Comandos do Ar Condicionado">
<Enumerated Name="Off" Value="0" />
<Enumerated Name="Aquecer" Value="1" />
23
<Enumerated Name="Arrefecer" Value="2" />
<Enumerated Name="Ventilar" Value="3" />
</EnumValueType>
</EnumValueTypeList>
A cada propriedade e associado um ID bem como um nome. Os valores que a propriedade pode
assumir sao declarados imediatamente a seguir, utilizando um nome que serve de descricao do valor
que sera utilizado pelo sistema. A declaracao de propriedades dos restantes tipos segue a mesma
logica.
Um aspeto bastante vantajoso desta definicao do modelo sistema diz respeito a especificacao de
dispositivos. Ao inves de especificar cada dispositivo com as suas propriedades, sao declarados ti-
pos de dispositivos (DeviceType). Posteriormente, quando se especificam dispositivos, deixa de ser
necessario especificar as suas propriedades, bastando para isso utilizar uma referencia para um Devi-
ceType. Isto torna-se bastante vantajoso na medida em que evita a duplicacao de informacao e facilita
a especificacao do sistema. Um exemplo bastante claro pode ser a especificacao de uma televisao
que pode conter um conjunto de propriedades alargado. Com esta abordagem e apenas criada uma
especificacao para um DeviceType que descreve todas as propriedades de uma televisao. Posterior-
mente podem ser definidos inumeras televisoes (Devices) utilizando uma referencia (RefDeviceType)
para o DeviceType criado, desde que as propriedades sejam respeitadas. O exemplo seguinte ilustra a
situacao descrita.
[...]
<DeviceType ID="3" Name="TV" Description="Televis~ao">
<PropertyTypeList>
<PropertyType ID="1" Name="Canal" AccessMode="RW" ValueType="ENUM" RefValueType="3"/>
<PropertyType ID="2" Name="Volume" AccessMode="RW" ValueType="SCALAR" RefValueType="1"/>
<PropertyType ID="3" Name="On-Off" AccessMode="RW" ValueType="ENUM" RefValueType="1"/>
</PropertyTypeList>
</DeviceType>
[...]
<Device ID="1" RefDeviceType="3" Name="TV Sala" Address="#0100" RefDivision="2" [...] />
[...]
</Device>
<Device ID="24" RefDeviceType="3" Name="TV Quarto" Address="#0100" RefDivision="6" [...] />
[...]
</Device>
[...]
A utilizacao de um modelo generico, expresso na linguagem XML, permite atingir um maior grau de
flexibilidade do sistema, podendo adaptar-se a um vasto conjunto de situacoes. Alem disso qualquer
24
Figura 3.2: Integracao da aplicacao no sistema DomoBus
alteracao da descricao do sistema apenas necessita de ser feita no XML. As aplicacoes aplicadas neste
contexto sao desenvolvidas de forma generica podendo adaptar-se a qualquer sistema, bastando para
isso interpretar a respetiva especificacao XML.
Este nıvel de flexibilidade e um fator bastante importante nos sistemas domoticos por forma a que
estes reflitam uma solucao o mais proxima possıvel das necessidades do utilizador. Alem disso as
necessidades do utilizador, bem como os dispositivos, por exemplo, de uma casa, mudam ao longo do
tempo, pelo que e vantajoso que o sistema seja flexıvel.
3.2 Arquitetura da Solucao
A interface grafica a desenvolver tem como principal objetivo ser integrada no sistema DomoBus pro-
porcionando uma ligacao entre o utilizador e o sistema. A mesma aplicacao podera ser representada
por varias GUI (Graphical User Interface) e comunicaria diretamente com os supervisores do sistema
DomoBus, sendo que estes, por sua vez, comunicariam com os gateways acedendo a uma rede de
controlo e, por fim, refletindo as acoes em dispositivos reais, tal como demonstrado na Figura 3.2. Por
varias GUI entende-se que esta interface poder ser adaptavel. Apesar de ser a mesma aplicacao, a
interacao com o utilizador pode variar consoante as configuracoes especificadas pelo utilizador.
A interface foi desenvolvida para o sistema operativo Android com foco para os dispositivos tablet.
A escolha desta plataforma movel prende-se essencialmente por dois factos. Em primeiro lugar e uma
plataforma livre, nao acarreta quaisquer custos de desenvolvimento e sao disponibilizadas gratuita-
mente todas as ferramentas necessarias. Este e um fator importante e que ajuda a reduzir o custo
da implementacao do sistema do ponto de vista do consumidor final. Em segundo lugar, o Android e
a plataforma movel com maior quota de mercado, chegando aos 82.8% no segundo quadrimestre do
25
presente ano[17]. Alem disso a quota de mercado tem vindo a crescer ao longo dos anos.
Dentro da plataforma Android, existem varias versoes sendo que as mais relevantes para o mer-
cado estao compreendidas entre a versao 4.1.x e 5.0 (Jelly Bean, KitKat e Lollipop, respetivamente),
prefazendo um total de 86.9%[18] (Figura 3.3). A aplicacao foi desenvolvida por forma a que seja
compatıvel com estas versoes, pelo que nao devem existir restricoes de compatibilidade para a maio-
ria dos possıveis utilizadores. Alem disso, assegura-se a longevidade da aplicacao pois e oferecida a
compatibilidade para o conjunto de versoes mais recentes deste sistema operativo movel.
Figura 3.3: Quota de mercado das diferentes versoes do
Android
A interface desenvolvida assenta es-
sencialmente em dois grandes com-
ponentes, sendo eles um modulo de
Comunicacao e um Interpretador XML.
O interpretador XML esta dividido em
duas partes, sendo quem uma esta en-
carregue de processar toda a definicao
XML do sistema domotico e construir uma
representacao mais facil e mais eficiente
de todo o sistema. A segunda parte esta
encarregue de processar as definicoes da
interface especificadas pelo utilizador, ou
seja, interpreta, por exemplo, quais os ele-
mentos que devem aparecer na interface, como estes sao personalizados e quais as funcoes associa-
das.
As seccoes seguintes descrevem com maior detalhe estes componentes.
3.2.1 Processamento de XML
Por forma a que a interface interaja com o sistema, e necessario que esta esteja configurada da mesma
forma. Ou seja, a interface necessita de processar a mesma descricao do sistema por forma a que
saiba exatamente as caracterısticas do mesmo. Assim quando e feita a referencia ao dispositivo A,
tanto a interface como o sistema domotico sabem exatamente de que dispositivo se trata e quais as
suas caracterısticas.
A descricao XML do sistema, apesar de bem construida e de utilizar algumas tecnicas para reduzir
a duplicacao de informacao e consequentemente o tamanho do ficheiro, pode crescer muito facilmente
consoante o tamanho e complexidade do edifıcio a que se aplica. Alem disso, a descricao do sis-
tema tem de ser processada antes da interface ser iniciada, o que pode provocar alguns problemas,
nomeadamente de usabilidade, caso o processamento demore demasiado tempo. Deve ainda ter-se
em consideracao que a capacidade de processamento e autonomia dos dispositivos moveis e muito
mais limitada. Estes sao fatores bastante importantes e devem ser tomados em consideracao. Por
isso todos os processadores XML implementados recorrem ao XmlPullParser [19]. Este parser e in-
26
dicado pela documentacao Android por ser eficiente e de facil manutencao. Essencialmente este tipo
de parsers itera o documento de forma sequencial, obtendo os atributos de cada no e mapeando-as
em variaveis. Desta forma conseguem-se otimizar alguns recursos, principalmente memoria, pois ao
contrario do DOM - Document Object Model [20] o documento nao e todo carregado para memoria.
A interface necessita entao que sejam especificados dois ficheiros XML num diretorio especıfico.
No disco de armazenamento principal deve constar um diretorio com a seguinte estrutura: Domo-
Bus/System/system.xml para especificar o ficheiro de descricao de sistema e um outro diretorio: Do-
moBus/Interface/interface.xml para a especificacao das definicoes da interface. Posteriormente podem
ser adicionados novos diretorios que auxiliam na personalizacao da interface, no entanto, estes podem
variar e, por isso devem estar indicados no ficheiro XML de personalizacao.
A medida que o documento e processado uma representacao do sistema vai sendo construida com
a ajuda de modelos de classes que representam cada elemento na descricao em XML. Os elementos
sao representados segundo as classes presentes na Figura 3.4.
Todas as classes presentes contem uma ligacao direta ou indireta a classe principal DomoBusSys-
tem uma vez que esta mantem uma lista de todos os elementos existentes. As duas principais classes
DomoBusSystem e DomoBusSystemInterface agregam toda a informacao relativamente ao sistema e
a interface, respetivamente. Alem disso disponibilizam um conjunto de metodos que permitem fazer
consultas sobre os dados armazenados. No diagrama e ainda representado o modulo de comunicacao,
designado por ComunicationService. Este modulo de comunicacao sera detalhado mais a diante.
A classe Device, tal como o proprio nome indica descreve um dispositivo do sistema. Esta classe
mantem uma referencia para a divisao em que se encontra e por sua vez uma referencia ao piso, utili-
zando para isso as classes Division e Floor. Um Device refere um DeviceType que contem a descricao
de todas as propriedades.
As propriedades dos dispositivos sao de um determinado tipo (DevicePropertyType) que por sua
vez fazem referencia a um tipo de valor descrito pela classe ValueType.
Um dispositivo pode ainda pertencer a um conjunto de acoes que dizem respeito a um determinado
cenario descrito pela classe Scenario. A classe Action permite armazenar cada acao a realizar. Alem
disso a classe Item que esta relacionada com o Modo Operacional, mantem uma relacao direta com
um Device.
Algumas classes como EnumPair permitem auxiliar na definicao das propriedades do tipo enume-
rado, onde e necessario associar um valor e uma chave. Os servicos sao representados com a classe
Service, permitindo que cada dispositivo pertenca a um conjunto de servicos. De forma semelhante, a
classe DeviceClass permite agrupar os dispositivos por classes.
Por fim a classe House permite armazenar toda a estrutura de pisos e divisoes.
Este modelo de classes e de elevada importancia para que se consiga manter a flexibilidade exis-
tente na especificacao XML. Durante a construcao do modelo de classes as referencias para os dis-
positivos sao atualizadas automaticamente, por exemplo, quando na especificacao de um dispositivo
se encontra o atributo RefDeviceType=“1”, a referencia para esse DeviceType e automaticamente re-
solvida. Para isso e necessario que estas referencias ja existam e esse requisito e obtido pois, na
27
Figura 3.4: Diagrama de classes28
especificacao em XML, estes aparecem em primeiro lugar. Uma das limitacoes obvias e o caso des-
tas referencias nao serem encontradas. Isto significa entao que a definicao XML do sistema esta mal
formada.
Apos o processamento correto de todo o ficheiro, e devolvida a estrutura de classes ao Domo-
BusSystem que representa todo o sistema e permite acesso rapido as diversas listas de dispositivos,
divisoes, cenarios, e outros. Caso, durante o processamento, exista algum erro, o utilizador e informado
atraves de uma notificacao e a aplicacao e encerrada. Nao faz sentido que a aplicacao funcione com
uma descricao do sistema mal formada.
Apos o processamento do XML do sistema e necessario processar as definicoes do utilizador. Estas
definicoes encontram-se guardadas no mesmo formato de dados. O processamento das definicoes e
identico ao anterior, utilizando o mesmo tipo de parser. E de notar que a especificacao da estrutura
destas definicoes nao existia e, por isso, teve de ser criada de raiz, tendo em conta as funcionalidades
disponibilizadas pela aplicacao.
A especificacao criada tem como base o elemento <DomoBusSystemInterface>. Este elemento
raiz contem um conjunto de atributos obrigatorios sendo eles um ID que serve de identificacao para a
configuracao e um Nome. Alem disso sao contempladas mais dois atributos. O primeiro, designado
por DomoBusSystemRef, tem como objetivo indicar qual o sistema domotico a que esta configuracao
diz respeito. A segunda propriedade serve para indicar a interface qual e o modo da interface que o
utilizador considera como principal e e designada por DefaultInterfaceMode. Este atributo pode tomar
dois valores (1 ou 2) e indica os modos Operacional e Geral, respetivamente. Estes modos serao deta-
lhados na seccao 3.3. Isto pode ser particularmente util quando o utilizador pretende utilizar a interface
para aceder aos dispositivos de toda a habitacao, recorrendo para isso ao Modo Geral ou quando a
utilizacao da interface e mais focada apenas numa divisao, sendo que nessa situacao o utilizador es-
pecifica o Modo Operacional como principal. Cada vez que a interface e iniciada, automaticamente e
redirecionada para o modo desejado. O exemplo seguinte ilustra uma situacao concreta.
<DomoBusSystemInterface ID="1" Name="Interface da Sala"
DomoBusSystemRef="1" DefaultInterfaceMode="1">
</DomoBusSystemInterface>
Todas os restantes elementos devem ser definidos dentro deste elemento raiz e nao tem uma or-
dem especıfica. A interface permite que o utilizador personalize os ıcones associados a determinados
elementos do sistema DomoBus, nomeadamente os dispositivos, os pisos, as divisoes, os servicos
e os cenarios. Para todos estes elementos, a especificacao faz-se de forma semelhante. Tomando
como exemplo a personalizacao dos dispositivos, e obrigatoria a introducao do elemento <Devices>
que serve de indicacao que vao ser especificadas um conjunto de propriedades relativas aos dispositi-
vos do sistema. Dentro deste elemento deve ser especificado o elemento <Device> com os atributos
RefDeviceType e BitmapDir. No primeiro deve ser indicado o ID do dispositivo no sistema por forma a
obter uma referencia ao mesmo. O segundo especifica o endereco do ıcone desejado. Este segundo
atributo permite ao utilizador especificar qualquer diretorio dentro do diretorio predefinido referido anteri-
ormente (DomoBus/Interface/), permitindo que este organize os conteudos da forma mais conveniente.
29
O exemplo seguinte ilustra esta situacao de uma forma concreta.
<Devices>
<Device RefDeviceType="1" BitmapDir="Devices/lamp.png"></Device>
<Device RefDeviceType="3" BitmapDir="Devices/tv.png"></Device>
</Devices>
De notar que o utilizador nao necessita de efetuar estas personalizacoes. Caso nao estejam de-
claradas, e assumido um valor por omissao. Alem disso, o utilizador pode apenas personalizar os
dispositivos que pretende. Os restantes elementos sao personalizados segundo o princıpio indicado,
variando apenas o nome das tags XML e um atributo. Para os pisos sao utilizadas as tags Floors, Floor
e o atributo RefFloor. Para as divisoes sao utilizadas as tags Divisions, Division e o atributo RefDivision.
Para os servicos sao utilizadas as tags Services, Service e o atributo RefService. Por fim, no caso dos
cenarios devem ser utilizadas as tags Scenarios, Scenario e o atributo RefScenario.
Estas configuracoes, ate agora analisadas, dizem apenas respeito ao Modo Geral da interface. No
que diz respeito ao Modo Operacional o nıvel de personalizacao e mais completo e, para que este
funcione, obriga a que o utilizador especifique um conjunto de elementos. Este modo de operacao e
apresentado com maior detalhe na seccao 3.3.1.
Este modo da interface, de uma forma bastante resumida, baseia-se numa grelha, onde em cada
posicao da grelha, designada por Item, e especificado pelo utilizador qual o dispositivo que deve ser
representado. Esta grelha e totalmente personalizavel, permitindo ao utilizador especificar quantas
linhas e colunas ela contem, qual a margem entre os diferentes Items da grelha, bem como se um Item
ocupa mais do que uma linha ou nao. A Figura 3.5 ilustra uma possıvel divisao da interface sob a forma
de uma grelha.
Figura 3.5: Modo Operacional - Exemplo de uma grelha
A construcao desta grelha comeca com a definicao da tag Grid. Aqui sao especificados tres atribu-
tos, nomeadamente o numero de linhas (Rows), o numero de colunas (Columns) e as margens entre
30
os diferentes Items (ItemMargins). Este ultimo atributo utiliza como unidade de medida o dp (Density-
independent pixel) que, tal como o proprio nome indica nao e influenciada pela densidade do ecra do
dispositivo, o que faz com que a medida seja igual num ecra de grande resolucao como num ecra
de menor resolucao, melhorando a portabilidade. Alem disso esta e a unidade recomendada pela
documentacao Android para a construcao de interfaces.
Dentro da definicao da grelha devem constar os diferentes Items. Cada Item contem quatro atributos
obrigatorios e dois nao obrigatorios. O primeiro atributo designa-se RefDevice e , tal como no restante
sistema indica uma referencia para um dispositivo. Aqui, o utilizador deve indicar qual o ID do dispositivo
que quer que este Item represente. De seguida sao indicados os atributos Row e Column que indicam
a posicao do Item na grelha. O atributo Rowspan funciona de forma analoga a propriedade das tabelas
em HTML - HyperText Markup Language [21]. Este atributo serve para indicar quantas linhas o Item
ocupa na grelha. Este atributo nao e obrigatorio especificar, caso nao se pretenda ocupar mais do que
uma linha. O proximo atributo designa-se QuickSettings. E um atributo booleano, o que significa que
apenas aceita os valores true ou false. Este atributo serve para indicar se sera representado, ou nao,
um atalho para o Modo de Configuracao de Dispositivo. Em alguns casos pode nao fazer sentido para
o utilizador a utilizacao desta funcionalidade para determinado dispositivo. Sendo assim, este pode
escolher nao a ativar, evitando sobrecarregar a interface. O atributo ShowName tambem e booleano e
a sua utilizacao permite indicar se o utilizador pretende ou nao que o nome do dispositivo seja mostrado.
Tal como o atributo anterior, este tem como objetivo evitar sobrecarregar a interface com informacao.
Por fim existe ainda um atributo opcional que permite especificar uma imagem de fundo para o Item,
designado por BitmapDir.
Para cada Item deve ainda ser escolhido um conjunto de propriedades a mostrar. Para especificar
esta lista utiliza-se a tag PropertiesToShow e dentro desta especificam-se um conjunto de propriedades.
Estas propriedades sao definidas recorrendo a dois atributos denominados refProperty que indica o ID
da propriedade que se quer representar e o atributo setOnClick. Este ultimo atributo e do tipo booleano
e, quando o seu valor e true, indica que aquela propriedade vai estar associada ao evento quando o
utilizador faz um toque no Item. Ou seja, ao inves de ser representada na diretamente na interface
como <Propriedade, Valor>, esta passa a ser controlada apenas por um toque. Um exemplo muito
simples e o controlo de uma lampada que tenha a propriedade On-Off. Ao fazer um clique, o valor
desta propriedade e automaticamente comutado. Isto permite fazer uma analogia direta aos tradicionais
interruptores de parede. E de notar que apenas uma propriedade pode estar associada a este evento
de clique.
O exemplo seguinte ilustra a definicao de uma grelha com os respetivos Items e propriedades para
um caso concreto.
<Grid Rows="2" Columns="2" ItemMargins="11">
<Item RefDevice="22" Row="0" Column="0" QuickSettings="true" ShowName="true">
<PropertiesToShow>
<Property refProperty="1" setOnClick="false"> </Property>
</PropertiesToShow>
31
</Item>
<Item RefDevice="1" Row="1" Column="0" QuickSettings="false" ShowName="true"
BitmapDir="switch.png">
<PropertiesToShow>
<Property refProperty="1" setOnClick="true"> </Property>
</PropertiesToShow>
</Item>
<Item RefDevice="26" Row="0" Column="1" Rowspan="2" QuickSettings="true" ShowName="true">
<PropertiesToShow>
<Property refProperty="3" setOnClick="true"> </Property>
<Property refProperty="1" setOnClick="false"> </Property>
<Property refProperty="2" setOnClick="false"> </Property>
</PropertiesToShow>
</Item>
</Grid>
3.2.2 Comunicacao
Para efeitos de comunicacao, a interface recorre a tecnologia IEEE 802.11 (Wi-Fi) que esta presente
numa grande maioria, se nao mesmo em todos, os dispositivos moveis existentes no mercado. Alem
disso esta e uma tecnologia que e largamente utilizada em ambientes domesticos, pelo que os utiliza-
dores nao necessitam de investimentos extra para uma rede de comunicacao.
O modelo de comunicacao implementado e assıncrono e utiliza o protocolo UDP - User Datagram
Protocol. A utilizacao deste protocolo de comunicacao em detrimento do protocolo TCP - Transmission
Control Protocol deve-se ao facto do primeiro necessitar de menos recursos, principalmente por parte
dos Supervisores, criando assim uma solucao com melhor desempenho de comunicacao.
Todas as mensagens enviadas devem seguir uma estrutura especıfica representada na Figura 3.6.
Na figura estao representados os campos da mensagem, sendo que o Tlen indica o tamanho total
da mensagem, o AppDest e AppOrig indicam o destino e a origem da mensagem, respetivamente. O
campo SNum representa o numero de sequencia do pacote de dados, o CTR permite especificar que
tipo de mensagem e e indicar algumas flags que podem sinalizar a ocorrencia de erros, retransmissoes
e outros. O campo Data contem os dados a transmitir e, por fim, o campo CRC serve para o controlo de
erros. Cada tipo de mensagem (get, set, notify e exec) tem ainda o seu formato proprio e e especificado
dentro do campo Data.
Por forma a facilitar o processamento das mensagens sob a forma de bytes foi criada uma biblioteca
(Ver Figura 3.7). Esta biblioteca permite, em primeiro lugar, serializar e desserializar as mensagens, ou
seja traduzi-las de um objeto para um conjunto de bytes e vice-versa, por forma a que seja compatıvel
com a especificacao do DomoBus. Apos a serializacao, a mensagem fica pronta a ser enviada pela
thread competente. Depois da desserializacao torna-se muito mais facil fazer a leitura das diferentes
32
Figura 3.6: Estrutura de um pacote de dados DomoBus do nıvel de supervisao
propriedades da mensagem e, com isso, determinar que tipo de mensagem se trata, qual a sua origem,
qual a informacao contida no campo Data e outros. Alem disso a biblioteca visa facilitar o processo
de criacao de novas mensagens, definindo os campos da mensagem de uma forma transparente e
permitindo a ativacao de flags. Ao criar uma mensagem nova, a biblioteca preenche automaticamente
um conjunto de campos, por exemplo, os campos Tlen e CRC que correspondem ao tamanho da men-
sagem e ao controlo de erros, respetivamente. Uma outra funcionalidade importante desta biblioteca e
determinar se uma dada mensagem recebida e um ACK - Acknowledgement de uma dada mensagem.
Isto e, a biblioteca, compara os campos necessarios e descobre se existe uma relacao entre as duas,
nomeadamente se a segunda mensagem e uma confirmacao de chegada da primeira.
Na interface, o servico de comunicacao regista um socket atraves de um IP - Internet Protocol e de
um Porto bem definido (9001) sendo que este e utilizado para receber e enviar mensagens de forma
concorrente. Todas as mensagens sao processadas em paralelo atraves de um conjunto de threads e
podem ser do tipo get, set ou notify. As duas principais threads designam-se por sender e listener.
A primeira tem como funcao esperar por possıveis mensagens que sejam enviadas para a interface.
Estas mensagens podem ser provenientes de um proprio dispositivo ou de um supervisor. A mensagem
chega sob a forma de um conjunto de bytes e e necessario processa-los por forma a traduzi-los sob
a forma de um objeto facilitando o acesso aos seus campos. Este processo e agilizado recorrendo
a biblioteca criada. Por fim a mensagem, ja traduzida, e colocada numa lista de mensagens para
processar.
A segunda thread principal e responsavel por enviar as mensagens e denomina-se sender. Esta
thread monitoriza uma lista de mensagens a enviar. Enquanto essa lista estiver vazia a a thread espera.
Quando e adicionada alguma nova mensagem, a thread e sinalizada e envia todas as mensagens
existentes.
33
Figura 3.7: Biblioteca - classe Packet
34
Existe ainda um conjunto de tres threads que estao relacionadas com o pos processamento das
mensagens. Este pos processamento diz respeito ao reenvio de mensagens, processamento de erros
e controlo de mensagens de confirmacao.
A primeira thread designa-se por ackChecker e visa controlar quais as mensagens que ja receberam
confirmacao sem erros. Assim que se recebe uma mensagem de ACK sem erros, esta e colocada
numa lista propria. Esta thread e notificada e processa as mensagens existentes na lista. Quando
a mensagem diz respeito a um comando get ou set os valores das propriedades especificadas na
mensagem sao atualizados na interface. Alem disso compete a thread remover a mensagem original
que originou o ACK da lista de mensagens enviadas, ja que nao sera necessario reenvia-la novamente.
A segunda thread designa-se por errorAckProcessor e tem como principal objetivo processar todas
as mensagens ACK que contenham algum tipo de erro. Para isso, com base nessa mensagem e
identificada a original que se encontra guardada numa lista de mensagens enviadas. A mensagem
original e atualizada com novas flags, nomeadamente a flag que indica retransmissao, e incrementado
o numero de sequencia e no final e colocada numa lista de mensagens a enviar. Alem disto esta thread
controla o numero de vezes que a mensagem foi reenviada com base no numero de sequencia, evitando
assim que mensagens que causem constantemente erro, sejam retransmitidas indefinidamente. As
mensagens sao retransmitidas no maximo tres vezes. Caso continuem a causar erros, sao descartadas.
Por fim existe o resender. Esta thread e responsavel por controlar o envio de mensagens que nao
receberam confirmacao de chegada. Apos um perıodo de tempo sem receber qualquer resposta, seja
com ou sem erros, a mensagem original e colocada numa lista de mensagens a enviar e e reenviada
ate um limite maximo de tentativas.
O mecanismo de sinalizacao de threads utilizado e bastante importante por forma a otimizar os
recursos do dispositivo. Caso este nao existisse seria utilizado um mecanismo de espera ativa que con-
sumiria bastantes recursos do sistema, principalmente tempo de processamento e, consequentemente,
a reducao de autonomia.
3.3 Modos de operacao
Tal como o sistema, a interface com o utilizador deve de igual forma ser flexıvel por forma adaptar-se
a novas preferencias ou alteracoes do sistema sem requerer que esta seja totalmente redesenhada.
Para isso, podera tirar partido modelo generico do DomoBus tanto para a interpretacao da estrutura
da habitacao, como como forma de armazenamento de detalhes acerca da propria interface. Alem
disso a interface comporta diferentes modos de operacao por forma a garantir uma melhor navegacao
pelo sistema, facilitar o controlo dos dispositivos e o acesso a informacao. Os diferentes modos de
funcionamento passarao a ser designados por Modo Operacional, Modo de Configuracao de Dispositivo
e Modo Geral. A alteracao entre os diferentes modos deve ser feita de forma facil e rapida, com excecao
da entrada no modo Geral que e mais indicado para utilizadores experientes. De seguida e feita uma
descricao de cada um dos modos de operacao.
35
3.3.1 Modo Operacional
O modo operacional, e um dos grandes destaques da interface. Este modo foi pensado para funcionar
de forma analoga a realidade. Suponhamos que existe um dispositivo que tem configurada uma inter-
face para controlar uma sala de estar. Numa situacao mais enquadrada no dia-a-dia, as acoes mais
frequentes, sao certamente ligar/desligar luzes, controlar a altura dos estores ou, por ventura, ajustar a
temperatura ambiente. Dado que os dispositivos que correm a interface possuem um baixo custo, nao
se descarta a possibilidade da existencia de um tablet, por exemplo a entrada de uma divisao e que es-
teja de alguma forma localizado na parede no lugar onde normalmente se encontram os interruptores.
Instintivamente, ao chegar a divisao, o utilizador saberia o sıtio onde estaria o controlo para as luzes.
Posteriormente poderia levar o dispositivo consigo para um lugar mais comodo e realizar outras acoes.
Por forma a que este comportamento seja possıvel, a interface implementaria um modo operacional
que simplesmente e uma representacao fictıcia de controlos reais como, por exemplo, os interruptores.
A abordagem tomada para a organizacao desta interface baseia-se numa disposicao sob a forma de
matriz, onde as celulas, designadas Items, representam um dispositivo.
Da mesma forma que na realidade, os casos mais comuns sao, por exemplo, a utilizacao de um
interruptor singular, um duplo, um singular e um duplo ou dois duplos, pelo que a interface a apresentar
nao deve ser muito mais complexa do que estas situacoes. Alem disso e necessario que a interface
seja simples pelo facto de que este modo serve para possibilitar um acesso rapido e praticamente
inconsciente aos controlos.
Figura 3.8: Modo Operacional
Um dos outros objetivos desta interface e que esta seja personalizavel, permitindo ao utilizador de-
finir quais os dispositivos que pretende controlar. A declaracao e personalizacao dos Items da interface
foi abordada na seccao 3.2 deste capıtulo. Uma vez que a personalizacao da interface fica sob criterio
36
do utilizador, esta pode ser mais ou menos complexa de acordo com as suas necessidades, no entanto,
tal como referido, o objetivo e que esta nao seja complexa.
A Figura 3.8 mostra uma possıvel configuracao do Modo Operacional. Neste caso foi utilizada uma
grelha 4x2 elementos, onde um dos elementos ocupa duas linhas utilizando para isso a propriedade
rowspan=“2”. Como pode ser analisado, os Items podem ser configurados com ou sem imagem de
fundo e podem mostrar mais ou menos propriedades. Por forma a construir uma interface que funci-
one de forma analoga aos controlos reais seria apenas necessario configurar a interface para que os
Items tivessem uma imagem de fundo, utilizando para isso o atributo BitmapDir ; Nao mostrar o nome
do dispositivo nem o acesso ao Modo de Configuracao de Dispositivo, utilizando os atributos show-
Name=“false” e quickSettings=“false”, respetivamente; Por fim, adicionar apenas uma propriedade que
se deseje controlar e especificar o atributo setOnclik=“true”. Um exemplo de configuracao para um Item
com essas caracterısticas pode ser visualizado a seguir.
<Grid Rows="1" Columns="1" ItemMargins="5">
<Item RefDevice="1" Row="0" Column="0" QuickSettings="false" ShowName="false">
<PropertiesToShow>
<Property refProperty="1" setOnClick="true"> </Property>
</PropertiesToShow>
</Item>
</Grid>
Desta forma pode conseguir-se construir uma interface de tal modo simples que possa ser utilizada
de forma analoga a realidade utilizando apenas um toque e, com alguma pratica, o utilizador pode
conseguir faze-lo de forma inconsciente.
Por forma a melhorar a experiencia de utilizacao, a interface responde as acoes definidas com
o atributo setOnclik=“true”. Estas propriedades nao sao representadas visualmente na interface, no
entanto o utilizador sabe que ao fazer um clique sera realizada uma acao em determinada propriedade
do dispositivo. Por for forma a informar o utilizador de que foi realizada uma acao o tablet vibra, nos
dispositivos compatıveis, e faz um som de toque.
Este modo permite aceder aos restantes e e o unico modo que permite aceder ao Modo de Configuracao
de Dispositivo. Esse acesso e especificado pelo utilizador durante a configuracao ativando para isso
o atributo quickSettings=“true”. Desta forma e mostrado no canto superior direito do Item um ıcone de
configuracao que lembra uma engrenagem, dando acesso a esse modo.
O acesso ao Modo Geral nao deve ser feito de forma acidental, nem por utilizadores menos experi-
entes. Por isso o processo de mudanca de modo e um pouco mais complicado, evitando assim acessos
inesperados. O acesso e feito atraves de um toque longo numa area do ecra nao atribuıda a nenhum
controlo. Apos esse toque longo e sobreposta a interface um ambiente onde o utilizador necessita de
clicar nos cantos de uma das diagonais do ecra, por forma a validar que realmente pretende mudar de
modo. Caso o comportamento especificado nao se verifique este ambiente desaparece. E de salientar
que nao se pretende bloquear o acesso ao Modo Geral, mas sim, prevenir que o acesso se faca de
forma acidental por utilizadores menos experientes.
37
Figura 3.9: Modo de Configuracao de Dispositivo
3.3.2 Modo de Configuracao de Dispositivo
O modo de configuracao de dispositivo acaba por ser uma extensao as capacidades de controlo de
um determinado dispositivo real. Tomando como exemplo um temporizador ou sensor de movimento
que esta associado a um conjunto de lampadas pode existir, por ventura, alguma situacao em que o
utilizador pretende desligar o temporizador ou o sensor por um perıodo de tempo.
Uma situacao em que isso pode acontecer e, por exemplo, num corredor onde geralmente as luzes
estao ligadas por um curto perıodo de tempo. No caso de alguem necessitar de estar sentado num
sıtio do corredor, o que acontece e que o sensor vai deixar de detetar essa pessoa porque nao existe
movimento e a luz desliga-se ao fim de um tempo, obrigando a que a pessoa faca alguns gestos
para o sensor a detetar. Se o utilizador entrar no modo de configuracao de dispositivo e definir que o
temporizador deixa de estar ativo por um perıodo de 10 minutos, entao estas situacoes nao acontecem,
deixando o utilizador com uma maior sensacao de controlo e ao mesmo tempo evitando situacoes de
frustracao. A Figura 3.9 ilustra este modo, onde sao apresentadas todas as propriedades do dispositivo,
incluindo uma propriedade que permite repor as definicoes originais apos um determinado tempo. O
utilizador apenas pode definir uma regra de cada vez para cada dispositivo, ou seja, enquanto estiver
uma regra ativa apenas lhe e permitido cancelar a acao da mesma.
Decorrido o tempo definido na regra pelo utilizador, a interface lanca uma notificacao. Caso esta seja
ignorada, trinta segundos depois, as definicoes sao repostas, caso contrario, o utilizador pode redefinir
a regra. Esta notificacao alerta o utilizador atraves de um som igual ao som de notificacao configurado
no dispositivo.
Seguindo o exemplo descrito no inicio desta seccao, o utilizador pode querer sair do local. Nesta
situacao existem duas opcoes. Ou acede novamente a este modo e cancela a regra, sendo que os
38
Figura 3.10: Modo Geral - Servicos
valores originais das propriedades sao repostos, ou simplesmente ignora a regra e sai do local. Nesta
ultima situacao, a interface repoe automaticamente o estado das propriedades ja que a notificacao e
ignorada.
3.3.3 Modo Geral
Por fim, de forma analoga aos sistemas existentes no mercado, existe o Modo Geral. Com este modo
pretende-se que o utilizador possa aceder rapidamente a qualquer dispositivo do sistema que esteja
localizado em qualquer parte da habitacao.
Este modo esta dividido em duas seccoes. No lado esquerdo e apresentado um menu de navegacao
que serve essencialmente para filtrar os dispositivos. No lado direito aparecem os dispositivos conso-
ante as opcoes selecionadas. No inicio, sem qualquer filtro, sao mostrados todos os dispositivos da
habitacao. Pode ser conveniente ao utilizador aceder diretamente ao dispositivo sem ter de utilizar os
filtros do menu. A medida que o utilizador navega pelo menu, sao aplicados os filtros aos dispositivos e a
sua selecao vai sendo cada vez mais refinada. Por forma a facilitar a navegacao, sao oferecidas formas
de filtrar os dispositivos (por Pisos e por Servicos). Por omissao, a interface oferece uma navegacao
por Pisos, acendendo posteriormente as divisoes do piso e por fim aos dispositivos da divisao. Caso
o utilizador pretenda, pode filtrar os dispositivos por Servicos, por exemplo Iluminacao, Aquecimento,
Seguranca e outros. Estes servicos sao variaveis e estao especificados na definicao do sistema, o
que permite, por exemplo que um dispositivo pertenca a mais do que um servico. Escolhendo um dos
servicos, apenas sao mostrados dispositivos que pertencam a essa categoria, sendo que o utilizador
pode ainda continuar a refinar a sua procura por Pisos e Divisoes. Neste ponto sao apenas mostrados
os dispositivos da dada divisao que pertencam ao servico escolhido. Tal como referido na seccao 3.2
39
deste capıtulo, estes elementos sao personalizaveis na medida em que o utilizador pode definir um
ıcone personalizado recorrendo a definicao do ficheiro de personalizacao XML. A Figura 3.10 ilustra
este modo, filtrando os dispositivos por Servicos.
Uma outra funcionalidade presente neste modo e o aceso aos diferentes Cenarios. Num sistema
domotico, um cenario e interpretado como um conjunto de acoes que sao aplicadas em determinadas
situacoes. Um exemplo pratico da utilizacao de cenarios e por exemplo o modo de filme. Neste caso
concreto o utilizador pode querer as luzes desligadas, a televisao ligada num determinado canal, as per-
sianas fechadas, etc. Estes cenarios sao especificados na definicao XML do sistema e visam descrever
qual o estado de determinados propriedades de determinados dispositivos. Para aceder aos cenarios
o utilizador deve recorrer ao menu de opcoes e escolher Cenarios. Automaticamente e apresentada
a lista de todos os cenarios disponıveis no lado esquerdo e, no lado direito, aparecem os detalhes de
cada cenario, podendo ativar-lo ou desativa-lo.
3.4 Estrutura da Interface
Uma vez que a interface e completamente dinamica e personalizavel, e necessario que exista um
processo de construcao automatico consoante as descricoes XML fornecidas. Nas seccoes anteriores
ja foi analisada a forma como e feito o processamento destas descricoes e quais as estruturas de
dados que sao devolvidas. Com base nessas estruturas e entao gerada a interface. Nesta seccao e
importante referir as opcoes tomadas quanto a utilizacao de determinados controlos para cada tipo de
propriedade dos dispositivos.
O DomoBus, tal como analisado anteriormente, contempla a utilizacao de tres tipos de propriedades.
Os escalares (SCALAR), os enumerados (ENUM) e os DomoBus arrays (ARRAY ). Estes parametros
devem ser considerados quando a interface e construida e, por forma a obter uma solucao generica,
foi definida uma forma de representar cada um deste tipo de dados e dependendo do seu modo de
acesso.
No Modo Geral, quando e necessario representar uma propriedade do tipo escalar, para alem de
mostrar o seu nome, sao utilizados dois controlos que permitem mostrar ao utilizador o valor da propri-
edade e qual a sua unidade. Por forma a controlar os valores da propriedade, e utilizada uma barra de
progresso. Segundo a nomenclatura do Android e designada como seekbar.
Figura 3.11: Modo Geral - Propriedade do tipo Escalar
As propriedades do tipo escalar incluem a definicao de um valor mınimo e maximo. Os valores espe-
cificados devem ser respeitados e, uma vez que as barras de progresso apenas permitem valores entre
zero e um limite maximo, e necessario realizar um calculo por forma a contemplar valores negativos,
como e o caso da Figura 3.11.
40
Quando a propriedade e indicada como apenas de leitura, a barra de progresso nao aparece, nao
permitindo que o utilizador altere os valores.
Figura 3.12: Modo Operacional
- Propriedade do tipo Escalar
Ja no Modo Operacional, uma vez que se trata de uma interface
mais simples e onde e necessario otimizar o espaco os controlos
aparecem configurados de uma forma diferente. A barra de pro-
gresso, passa a ser circular e o nome e valor da propriedade apa-
recem no centro desta. A barra de progresso nativa do Android nao
permite, de uma forma direta configurar que esta seja circular, no en-
tanto foi utilizada uma implementacao ja existente desse tipo de con-
trolo denominado por SeekArc2 Algumas das funcionalidades nao
tinham o comportamento correto, nomeadamente o facto desta nao
permitir ser desabilitada. Esses comportamentos tiveram de ser cor-
rigidos.
A Figura 3.12 ilustra a utilizacao deste tipo de controlo no Modo
Operacional. Como se pode analisar, o perımetro desta barra de
progresso e muito superior a qualquer barra de progresso horizontal
ou vertical que se utilizasse no mesmo espaco. Assim consegue-se aumentar o grau de precisao
quando o utilizador pretende ajustar o valor. O tamanho deste componente e determinado pelo espaco
disponıvel. E analisado o espaco disponıvel em largura e altura e o menor valor e utilizado para a
construcao do elemento. Assim maximiza-se a utilizacao da area disponıvel.
Quando a propriedade e indicada como apenas de leitura, a barra de progresso aparece desativada,
nao permitindo alterar o valor.
As propriedades do tipo enumerado sao processadas da mesma forma nos dois modos. Uma vez
que um enumerado pode assumir diferentes numeros de opcoes optou-se por utilizar uma caixa de
combinacao, mais vulgarmente conhecida pelo termo em ingles combobox e denominada por spinner
no contexto Android.
Figura 3.13: Propriedade do tipo
Enumerado
De forma analoga ao tipo de dados descrito anteriormente,
aqui e apresentado o nome da propriedade e a respetiva caixa de
combinacao. Esta caixa e preenchida de acordo com as proprieda-
des descritas para um enumerado e, alem disso, e necessario guar-
dar os IDs associados a cada opcao por forma a que esta possa ser
processada corretamente. Quando a propriedade e definida como
apenas de leitura as caixas de combinacao aparecem desativadas.
A Figura 3.13 mostra a utilizacao deste tipo de controlo no Modo
Operacional.
Existe uma situacao que ocorre com bastante frequencia nos dispositivos e diz respeito a definicao
de uma propriedade Ligado e Desligado. Este parece ser um dos casos particulares da utilizacao desta
propriedade e e tratado da mesma forma que os restantes. Acontece que nao e tao comodo para2https://github.com/neild001/SeekArc, acedido em Outubro 2015.
41
o utilizador quando pretende apenas ligar ou desligar um dispositivo ter de selecionar uma opcao da
caixa de combinacao. Por forma a melhorar a acessibilidade podiam ser utilizados controlos proprios
para este tipo de situacao. Acontece que a definicao XML corrente nao permite identificar este tipo
de propriedades particular, ou seja sabe-se apenas quantas opcoes existem, quais os seus nomes
e valores. Poderia ser feita uma abordagem onde se avaliasse o numero de opcoes. Caso fossem
duas utilizava-se um controlo diferente, no entanto, esta situacao nem sempre pode ser verdade. Um
exemplo e a definicao de uma propriedade com os valores subir e descer. Por este motivo optou-se
por seguir a abordagem mais generica descrita no inicio. No capıtulo 4 pode verificar-se que alguns
utilizadores sugeriram esta alteracao.
O tipo de dados DomoBus array permite ao utilizador enviar qualquer tipo de informacao. Para
representar uma propriedade deste tipo e apresentado o seu valor numa caixa de texto. Seguido da
caixa de texto existe um botao Confirmar que permite ao utilizador enviar a informacao quando acaba
de a escrever. A Figura 3.14 ilustra a utilizacao de caixas de texto para as propriedades DomoBus
array.
Figura 3.14: Modo Geral - Propriedade do tipo Escalar
Quando esta propriedade e apenas de leitura a caixa de texto e o botao confirmar aparecem desa-
tivados.
No Modo Operacional, nao e permitido alterar este tipo de propriedades uma vez que iria trazer
complexidade a interface. No entanto e possıvel ver qual o valor da mesma.
A interface permite ao utilizador especificar imagens como ıcones para os dispositivos, pisos, di-
visoes, servicos, cenarios e ainda permite que se especifiquem imagens de fundo para o diferentes
Items do Modo Operacional. Todas as imagens especificadas pelo utilizador nao necessitam de ter um
tamanho especıfico pois estas sao redimensionadas automaticamente em todas as situacoes. Contudo,
deve ter-se particular atencao ao tamanho e a qualidade das mesmas pois podem afetar o desempenho
da interface.
3.5 Simulador de teste
Por forma a validar a implementacao da comunicacao da aplicacao e o funcionamento correto de todo
o sistema de mensagens, foi implementado um simulador. Este simulador permite entao emular o
comportamento de um supervisor de uma forma simplificada e, uma vez que nao existem dispositivos
reais, permite representa-los de uma forma virtual.
Este simulador necessita apenas que seja fornecida a descricao XML do sistema e gera a sua inter-
face automaticamente e onde os dispositivos sao apenas filtrados por divisao. Todas as propriedades
42
dos dispositivos sao mostradas. O processamento do ficheiro XML e feito de forma diferente uma vez
que a implementacao utilizada no Android nao existe de forma nativa no Java. No entanto e utilizado um
parser do mesmo tipo devido a sua eficiencia. A Figura 3.15 ilustra o simulador desenvolvido. Na inter-
face pode ser escolhida a divisao e, automaticamente todos os dispositivos que nela estejam contidos
sao mostrados.
Figura 3.15: Simulador de teste
Ao gerar a interface sao tambem gerados valores aleatorios para todas as propriedades, respeitando
todas as caracterısticas das propriedades definidas no ficheiro XML. Para os enumerados e escolhido
um dos valores possıveis, para os escalares e gerado um valor aleatorio dentro dos limites mınimo e
maximo especificados na propriedade e para os DomoBus arrays e colocada uma cadeia de carateres.
Este simulador, alem de mostrar as propriedades, permite ainda alterar os valores das mesmas,
mesmo que esta seja apenas de leitura. Desta forma e possıvel simular a alteracao de propriedades
de qualquer dispositivo real do sistema, por exemplo, um sensor de tempera. Neste caso particular
o utilizador nao define um valor para a propriedade temperatura por esta ser apenas de leitura. A
propriedade e alterada por fatores externos e, ao mesmo tempo, e enviada automaticamente uma
mensagem do tipo notify com os valores adequados.
De forma analoga a interface, o simulador implementa um sistema de comunicacao, na medida em
que funciona de forma concorrente e utilizando apenas um socket de comunicacao. Alem disso este e
43
capaz de fazer todo o processamento de mensagens, bem como retransmissoes em caso de erro ou
caso nao receba resposta.
44
Capıtulo 4
Resultados
Neste capıtulo pretende-se avaliar os resultados obtidos com o desenvolvimento da interface, nome-
adamente relativos ao desempenho e a usabilidade. Pretende-se analisar alguns dos aspetos menos
positivos, de acordo com as opinioes dos utilizadores que realizaram os testes.
4.1 Desempenho
O desempenho da interface nao esta estritamente dependente da implementacao, mas tambem da
infraestrutura de rede onde esta esta inserida e das caracterısticas do tablet utilizado. O desempenho
da interface foi testado recorrendo a um tablet de baixo custo com as seguintes especificacoes.
• Processador Allwiner A33 ARM Cortex-A7
• Processador grafico Mali400MP2
• 1GB de memoria RAM
• Sistema Operativo Android 4.4.2 (KitKat)
• Ecra 7” TFT 800x444 pıxeis, 120dpi
• Modelo Dyno 7.69
O tempo de processamento de uma descricao XML depende essencialmente da complexidade do
sistema descrito e da resolucao de referencias entre os diferentes elementos. No entanto, utilizando um
tablet de baixo custo, uma descricao com cem dispositivos com multiplas propriedades e processada
em cerca de cem milissegundos o que nao traz impacto para o utilizador final. A utilizacao de memoria
esta diretamente dependente da qualidade dos ıcones que o utilizador especifique no entanto, por
cada 100 dispositivos no sistema espera-se uma utilizacao de memoria que ronde os 10MB. Um dos
aspetos que permite poupar recursos de memoria deve-se ao facto de que os ıcones nao sao alocados
diretamente na criacao do elemento, mas sim apenas quando estes estao a ser mostrados na interface.
45
O processamento de mensagens nao causa um atraso significativo no ponto de vista do utilizador.
A situacao onde ha maior congestionamento de mensagens ocorre ao iniciar a aplicacao onde sao pe-
didos todos os valores das propriedades dos dispositivos. Quanto aos erros de comunicacao, estes sao
extremamente raros no ambiente em que foi testado, sendo que os unicos existentes foram provocados
intencionalmente por forma a validar o comportamento de retransmissao de mensagens. A transmissao
de mensagens foi testada numa rede WiFi com uma latencia media de 12ms.
Tal como referido, estes valores estao altamente dependentes de inumeros fatores nomeadamente
pelas caracterısticas do tablet, pela qualidade da infraestrutura de rede em que se insere e pela comple-
xidade da definicao XML. Por isso mesmo estes valores sao difıceis de quantificar de forma concreta.
4.2 Teste com utilizadores
Por forma a aferir a funcionalidade da interface foi realizado um conjunto de testes a um conjunto de
utilizadores. De acordo com modelos matematicos presentes na bibliografia consta-se que existe uma
relacao entre o numero de utilizadores que realizam testes e a percentagem entre os problemas de usa-
bilidade encontrados [22]. Este modelo permite determinar a percentagem de problemas encontrados
consoante o numero de utilizadores utilizados no teste. O modelo preve que com cinco utilizadores se
descubram 85% dos problemas de usabilidade. Recomenda ainda que se siga um modelo iterativo, ou
seja, que se facam testes com cinco utilizadores e que se implementem as correcoes. Posteriormente
volta-se a testar e a implementar alteracoes e assim sucessivamente. Desta forma o processo de testes
torna-se mais eficiente do que a realizacao de apenas um teste com dez utilizadores.
O processo de teste da interface foi iterativo, sendo que os problemas e usabilidade encontrados
foram corrigidos na medida do possıvel apos cada iteracao.
A interface foi testada com treze utilizadores. Uma vez que a interface pode ser utilizada num
ambiente domestico, os possıveis utilizadores podem pertencer a diferentes grupos etarios. Por isso
mesmo os utilizadores que realizaram o teste pertencem a faixas etarias entre os 15 e 25 anos, entre
os 34 e os 50 anos e entre 70 e 72 anos. Sete dos utilizadores pertencem ao primeiro grupo etario e
os restantes aos outros grupos. Do primeiro grupo apenas dois utilizadores nao estavam familiarizados
com a utilizacao de tablets embora tivessem pratica noutro tipo de dispositivos. No segundo grupo
apenas um dos utilizadores nao tinha qualquer experiencia com dispositivos moveis tateis. No terceiro
grupo, um dos utilizadores ja tinha tido contacto com estes dispositivos e outro utilizador nao tinha
qualquer experiencia.
O teste a realizar por cada utilizador inclui oito tarefas distintas e um conjunto de tres perguntas
no final por forma a perceber que motivos tornaram determinadas tarefas complicadas, se existem
sugestoes para melhorar essas atividades e uma pergunta final que pretende avaliar que detalhes o
utilizador mudaria. O modelo do teste pode ser consultado no anexo A. O conjunto de oito tarefas
pretende avaliar o tempo ou o numero de erros para a realizacao de cada tarefa bem como obter uma
apreciacao crıtica relativa a facilidade de execucao.
Os resultados obtidos nos testes podem ser consultados no anexo B. Apos a analise destes resul-
46
Tabela 4.1: Resultados dos Testes de Usabilidade
tados pode construir-se a tabela 4.1.
Na tabela e indicado qual a unidade de medida para cada teste sendo que pode ser tempo em
segundos ou numero de erros. Em alguns testes, como no caso do teste numero 5 faz mais sen-
tido perceber quantas vezes o utilizador erra ao tentar realizar a tarefa do que propriamente o tempo
demorado.
Analisando o conteudo da tabela relativamente ao tempo demorado e aos erros por cada tarefa
percebe-se que em todos os testes os valores estao de acordo com os esperados. Como excecao
encontram-se os testes numero 2, 5 e 6 onde os valores foram ligeiramente piores do que o esperado,
ainda assim dentro do limite aceitavel.
O teste numero 2 demora em media 21,7 segundos a ser completado quando o valor alvo seria de
15 segundos. Uma justificacao possıvel para este resultado relaciona-se com o facto dos utilizadores
necessitarem de aceder a um menu para poder filtrar os dispositivos e demoram um pouco mais a
procurar o sıtio correto.
No teste numero 5 existe uma media de 1,7 erros e onde o valor alvo seria 1 erro. Este e o teste
com maior numero de erros e pretende avaliar a mudanca do Modo Operacional para o Modo Geral. O
utilizador necessita de fazer um clique longo numa area desocupada do ecra e clicar nos cantos de uma
diagonal. Este e suposto ser um processo um pouco mais complicado por forma a evitar que se mude
de modo acidentalmente. Por esta razao o valor medio de erros e completamente aceitavel. Apesar
do valor medio ser ligeiramente superior ao esperado, constatando o valor da moda percebe-se que a
maior parte dos utilizadores nao faz qualquer erro na execucao da tarefa.
O teste numero 6 pretende avaliar a facilidade com que o utilizador interage com diferentes tipos de
propriedades no Modo Operacional. O numero medio de erros e de 1,3 e, face ao valor esperado 1, e
aceitavel. O maior numero de erros deve-se ao facto de alguns utilizadores nao se terem apercebido
que a televisao podia ser controlada naquele modo e por isso, tentam aceder ao Modo Geral. De forma
analoga ao teste numero 5, o valor da moda e 0 o que indica que a maior parte dos utilizadores nao
erra a fazer a tarefa.
No que diz respeito a facilidade em realizar as tarefas os valores sao classificados de 1 a 5, sendo
que o valor 1 corresponde a “Muito Difıcil” e o valor 5 corresponde a “Muito Facil”. Os valores medios
47
apurados sao a cima de 4, o que significa que as tarefas foram de uma forma geral faceis de realizar.
Como excecao encontram-se as tarefas numero 5 e 8. A tarefa do teste numero 5, com o valor medio
de 3,8, ainda que perto do valor 4, foi complicada para alguns dos utilizadores pelos motivos referidos
anteriormente. Alguns dos utilizadores nao conseguiam fazer um toque com a precisao necessaria e
por isso enganavam-se.
O teste numero 8 foi considerado o mais complicado. Este era o teste que obrigava a mais passos,
desde o acesso ao Modo de Configuracao de Dispositivo, a troca do valor da propriedade, a definicao
do tempo especificado e o adiamento. Neste teste notou-se que alguns dos utilizadores nao tinham a
certeza se era necessario ou nao clicar em Adiar uma vez que o teste nao o especificava diretamente.
Relativamente ao valores maximos e mınimos dos tempos/erros percebe-se que existem diferencas
acentuadas entre eles. O mesmo acontece relativamente a facilidade onde em todos os casos pelo
menos um utilizador considerou a tarefa “Muito Facil” e pelo menos um utilizador a considerou “Muito
Difıcil”. Estas discrepancias de valores podem ser mais facilmente entendidas se os diferentes grupos
etarios forem considerados. O grupo etario dos 70 aos 72 anos considerou a utilizacao de uma forma
geral mais difıcil, em especial um dos utilizadores, nao porque a interface era complicada, mas devido
a limitacoes fısicas. O utilizador tinha muito pouca precisao no toque e a utilizacao de um dispositivo
de toque revelou-se bastante complicada. Com especial atencao nos testes numero 5 e 8, constata-se
que a maioria dos utilizadores considerou a tarefa “Facil” ou “Muito Facil” o que, analisado juntamente
com o valor medio de cada teste, confirma o facto de haver um numero muito reduzido de utilizadores
que consideraram essas tarefas “Muito Difıceis”.
Os testes contemplam tres perguntas no final. Na primeira pretende-se perceber qual o verdadeiro
motivo que tornou determinada tarefa complicada. A segunda pretende obter informacao acerca de uma
possıvel forma de melhorar a execucao dessas tarefas e, por fim, a ultima pretende saber a opiniao geral
dos utilizadores sobre quais os detalhes que mudariam ou novas funcionalidades que lhes possam ser
uteis.
Para as duas primeiras perguntas quatro utilizadores referem que, no teste numero 5, e difıcil mudar
de modo devido a precisao necessaria e pelo facto de nao ser intuitivo e nao se lembrarem como se
fazia. Alguns utilizadores referem ainda que, para quem tem os dedos maiores, torna-se complicado ter
alguma precisao. Para melhorar a mudanca de modo, alguns sugerem que se crie uma area dedicada
para o efeito, por exemplo um botao especıfico num dos lados do ecra.
Outros utilizadores referem que, no teste numero 7, apesar da tarefa ser facil, nao perceberam se a
lampada desligou ou nao pelo facto do feedback nao ser o melhor. Neste modo, tal como descrito no
capıtulo 3, o tablet gera um som e vibra caso exista compatibilidade. Isso nao foi o suficiente pois os
utilizadores esperavam que algo mudasse na interface. Se o teste fosse realizado num ambiente real, o
utilizador, ao desligar a lampada, iria efetivamente ver que a lampada desligou. Como os testes foram
realizados com um ambiente simulado, a percecao do utilizador foi prejudicada. Contudo alguns utiliza-
dores sugeriram mudar a imagem de fundo quando e feito o clique por forma a melhorar o feedback e
essa seria a solucao mais indicada para este tipo de situacao.
Os utilizadores, especialmente os de mais idade, referem que, para eles, e bastante complicado
48
utilizar um dispositivo tatil devido a falta de precisao. Sugerem entao, que de um modo geral se utilizem
controlos maiores.
Alguns deles referem ainda que a utilizacao da interface nao e difıcil, apenas algumas situacoes sao
mais complicadas devido ao nao conhecimento da interface e por se tratar da primeira utilizacao.
Relativamente a ultima pergunta os utilizadores, de uma forma geral, contribuıram com entusiasmo
e referiam algumas ideias interessantes nomeadamente, adicionar uma forma mais direta para especifi-
car os valores das propriedades. Por exemplo no caso das propriedades do tipo escalar, poder introduzir
valores pelo teclado; As propriedades enumeradas que contenham apenas os valores ligado-desligado
poderem ser representadas como um switch on e off ; No Modo Geral, em vez de um menu, colocar
diretamente as opcoes na barra de menu por forma a serem mais visıveis e de melhor acesso; Adici-
onar suporte a stocks para os frigorıficos e poder comprar os produtos automaticamente; Implementar
um comando para a televisao, ou seja, poder ter um modo especıfico para o controlo de dispositivos
de multimedia em que o aspeto seja semelhante aos comandos tradicionais, facilitando a interacao;
Adicionar suporte a geracao de alertas tanto relacionados com detecao de intrusos como detecao de
choro de bebes ou mesmo doentes acamados.
Outras funcionalidades referidas e interessantes sao o acesso atraves da Internet, apesar de que
esta funcionalidade nao esta dependente desta interface; Poder visualizar os consumos energeticos
e estimar o valor final das faturas(agua, gas e eletricidade); Permitir que se definam alertas para a
manutencao de determinados dispositivos como, por exemplo, os de ar condicionado; Poder utilizar
comandos de voz; Criar um modo exclusivamente dedicado a seguranca da habitacao; Criar, eventual-
mente, um modo inicial de ajuda que funcione como um tutorial da utilizacao da aplicacao.
4.3 Trabalho Futuro
Para alem das ideias deixadas pelos utilizadores, existem outras que foram discutidas antes e durante o
desenvolvimento da interface. Acontece que nem todas elas puderam ser implementadas nesta solucao
por diversos motivos, principalmente o limite de tempo. Algumas destas ideias sao simples tais como a
alteracao das imagens de fundo dos Items do Modo Operacional que alguns dos utilizadores referiram.
Esta ideia apesar de simples nao foi introduzida pois surgiu um pouco tarde e, de facto, revelou-se
necessaria para a melhoria da acessibilidade da solucao.
A mudanca para o Modo Geral, revela-se, em alguns casos, complicada. Uma possıvel alteracao e
a utilizacao de um gesto a escolha do utilizador ao inves deste ter de clicar numa zona nao ocupada do
ecra.
O controlo de acessos e uma funcionalidade que esta especificada na definicao do DomoBus, no
entanto a interface nao faz qualquer autenticacao de utilizadores. Esta autenticacao, se necessaria,
deve ser feita apenas para o acesso ao Modo Geral e, os dispositivos sao filtrados consoante o nıvel
de acesso do utilizador. Esta sessao seria automaticamente desligada ao fim de um determinado
tempo por forma a reduzir a probabilidade de acessos ilıcitos. Apesar de especificada, esta funcionali-
49
dade deve ainda amadurecer, nomeadamente em aspetos como a seguranca na troca de mensagens,
autenticacao de dispositivos e outros, por forma a minimizar ao maximo possıveis falhas de seguranca.
A implementacao de um sistema de localizacao local e uma das ideias mais interessantes para
este projeto. Este sistema de localizacao permitiria detetar em que divisao o tablet se encontrava e,
automaticamente, a interface do Modo Operacional era mudada. Isto tornar-se-ia bastante comodo para
o utilizador e, de uma forma indireta poderia reduzir o custo de investimento nesta solucao, na medida
em que o utilizador poderia encontrar um balanco entre colocar tablets em todas as divisoes e nao
colocar em determinadas divisoes que sejam menos frequentadas. Sem utilizar os servicos de GPS -
Global Positioning System que requerem muitos recursos do dispositivo e podem induzir a problemas
de privacidade, poderia recorrer-se a tecnologia NFC1 - Near Field Communication que permite a troca
de informacao sem fios entre dispositivos proximos, permitindo assim identificar cada divisao.
Uma funcionalidade interessante seria a troca automatica dos ficheiros de configuracao e de descricao
do sistema entre a interface e os supervisores. Nesta situacao teria de existir um Supervisor res-
ponsavel por armazenar todos os ficheiros relativos a cada interface e, caso o utilizador necessite de
substituir um tablet os ficheiros necessarios seriam enviados automaticamente para a interface. No
entanto, esta abordagem apresenta um pequeno problema que se prende com a transmissao de todos
os ficheiros relativos a configuracao da interface, nomeadamente as imagens, que, em conjunto, podem
aumentar consideravelmente o tempo de transmissao dos dados.
Em sistemas mais complexos o processamento da definicao XML pode ser mais morosa. Por forma
a evitar que os ficheiros sejam processados sempre que a aplicacao e iniciada poderia ser utilizado um
sistema de serializacao de dados, onde todas as informacoes processadas das definicoes XML seriam
guardadas. Quando a aplicacao fosse iniciada novamente e os ficheiros de configuracao nao fossem
alterados (implica verificar uma versao nos ficheiros XML) seriam utilizados os dados serializados dis-
pensando assim o processamento das definicoes XML.
Para alem das funcionalidades que poderiam ser implementadas na interface, existe ainda um con-
junto de ideias que, na minha opiniao, devem ser os proximos passos a tomar por forma a potenciar
este projeto.
Em primeiro lugar considero que e de extrema importancia construir um mini sistema domotico
isolado, com base na atual especificacao. Quer isto dizer, colocar uma determinada quantidade de
variados dispositivos ligados a um sistema e permitir que estes sejam controlados por uma interface. A
partir deste momento devem ser construidas novas funcionalidades de forma incremental. Desta forma
o projeto pode ganhar uma maior visibilidade potenciando-se a si mesmo, encorajando o aparecimento
de novas ideias e projetos.
Em segundo lugar deve ser implementada uma aplicacao para computador e de interacao sim-
ples por forma a que possam ser geradas e editadas definicoes de sistema XML mais facilmente. A
construcao manual desse tipo de ficheiro torna-se bastante complicada de gerir quando a complexidade
do sistema comeca a aumentar. Com esta aplicacao seria mais facil especificar as diferentes partes da
habitacao, bem como quais os dispositivos e suas caracterısticas. O resultado deste programa seria
1http://www.nearfieldcommunication.org/technology.html, acedido em Outubro 2015.
50
apenas uma definicao do sistema XML de acordo com o formato DomoBus. Esta aplicacao facilitaria
imenso os desenvolvedores e permitiria construir sistemas mais complexos para a realizacao de tes-
tes e outros. Alem disso esta aplicacao sera necessaria para o consumidor final. Como extra, esta
aplicacao podera tambem permitir ao utilizador gerar o ficheiro de configuracao XML da interface.
Por fim a criacao de APIs e bibliotecas como esta que sera disponibilizada, por forma a facilitar e
uniformizar a criacao de aplicacoes que interajam com o sistema.
Estes sao os tres principais passos, que considero que devem ser tomados num futuro proximo para
que o DomoBus ganhe uma maior visibilidade e se torne um sistema viavel e atraente.
51
52
Capıtulo 5
Conclusoes
A domotica e uma area das tecnologias que tem ganho notoriedade nos ultimos anos. Por falta de
normalizacao, numa fase inicial, foram surgindo varios protocolos divergentes, o que dificultou a intero-
perabilidade entre os sistemas domoticos. Estes sistemas sao, em geral, pouco flexıveis tanto a nıvel
da sua arquitetura como a nıvel da interface com o utilizador. Por estes motivos, foram desenvolvidas
solucoes como o DomoBus que visam facilitar a interoperabilidade entre os diferentes sistemas.
O DomoBus e uma solucao que assenta numa definicao generica de um sistema domotico. Tal
princıpio permite-lhe que este seja bastante flexıvel. Este segue uma arquitetura em que se considera
que um sistema pode ser decomposto em dois nıveis: o nıvel de supervisao e o nıvel de controlo. O
nıvel de controlo pode integrar varias tecnologias como, por exemplo o X10 ou o KNX e e responsavel
pela interacao direta com dispositivos, por exemplo, sensores e atuadores. O nıvel de supervisao e
responsavel pela gestao e inteligencia de todo o sistema. Este nıvel e independente de protocolos e
dispositivos uma vez que segue uma abordagem generica para a representacao de todo o sistema.
Por forma a que o sistema seja aceite pelos utilizadores este deve disponibilizar uma interface atra-
ente, funcional e de interacao facil. Deste modo foi desenvolvida uma interface para o sistema Do-
moBus. Ao contrario das existentes atualmente no mercado, pretende-se oferecer um conjunto de
caracterısticas inovadoras que oferecam uma maior flexibilidade, capacidade de adaptacao a diferentes
ambientes e preferencias dos utilizadores. Por forma a obter tais caracterısticas, a interface suporta
varios modos de interacao, dos quais se destaca o Modo Operacional. Neste modo sao mostrados
no ecra principal um conjunto de comandos, por exemplo, interruptores que permitem controlar os dis-
positivos mais comuns, proporcionando um acesso mais rapido e tao simples quanto os interruptores
vulgares. Alem disso estes controlos podem ser personalizados pelo utilizador por forma a que este
consiga construir uma solucao a sua medida. Este modo de interface foi desenvolvido por forma a
mostrar os controlos mais comuns da divisao onde o utilizador se encontra, tornando a utilizacao mais
comoda. A abordagem tomada torna-se viavel com a banalizacao recente de tablets de muito baixo
custo. Neste caso, estes podem ser substitutos para os controlos mais tradicionais como, por exemplo,
os KNX que possuem uma relacao entre o preco e as funcionalidades oferecidas muito mais baixa.
Desta forma torna-se economicamente mais viavel a utilizacao de tablets em detrimento dos comandos
53
mais tradicionais, trazendo vantagens para os utilizadores do sistema.
A interface desenvolvida implementa um protocolo bem definido do DomoBus para a comunicacao
por forma a que esta possa comunicar com os diferentes dispositivos do sistema domotico. Devido a
ausencia de um sistema completamente implementado e funcional, foi necessaria a implementacao de
um simulador onde sao emuladas algumas das funcionalidades de um Supervisor do sistema DomoBus
e emuladas as alteracoes a propriedades de dispositivos.
Com o desenvolvimento desta interface conseguiu-se trazer uma solucao flexıvel e completamente
adaptavel a qualquer sistema domotico DomoBus e que nao existe atualmente disponıvel no mercado.
Esta solucao e inovadora no sentido que disponibiliza uma nova analogia para a utilizacao dos dispo-
sitivos moveis, tais como os tablets, nos sistemas domoticos. Essa analogia visa a substituicao dos
tradicionais controlos de parede que tendem a ser muito mais dispendiosos e oferecem um menor grau
de funcionalidade face ao seu custo associado, permitindo ainda controlar todos os dispositivos da
habitacao.
Esta interface provou ser de simples utilizacao e funcional, tal como mostram os testes com utiliza-
dores. Apesar disso, existem melhorias na interface bem como novas funcionalidades que podem ser
implementadas. A aceitacao por parte dos utilizadores e um dos primeiros passos para que o sistema
se torne viavel e para que este possa evoluir na direcao correta.
Foi possıvel ainda criar uma definicao XML que visa personalizar a interface de uma forma sim-
ples e igualmente flexıvel. Esta definicao podera ser estendida e melhorada a medida que a interface
suporte novas funcionalidades. Alem disso foi gerado um contributo para todo o sistema DomoBus e
para futuras implementacoes de aplicacoes, na medida em que foi criada uma biblioteca na linguagem
Java que permite facilitar o tratamento de mensagens entre, neste caso, a interface e supervisores. A
criacao de uma estrutura de classes que representa uma definicao de um sistema domotico DomoBus
e implementacao de parsing dos ficheiros e igualmente importante, pelo que futuras aplicacoes podem
tirar partido destas estruturas de dados e funcionalidades.
A solucao apresentada contribui para a concecao de um sistema domotico robusto e flexıvel, disponi-
bilizando uma interface adaptavel as necessidades de cada utilizador e que ao mesmo tempo funcional.
54
Referencias
[1] I. P. O. T. e. D. G. Vijay Saraswat, Bard Bloom. X10 language specification. Technical report, IBM,
Junho 2015. Version 2.5.
[2] J. Hofmann. The Consumer Electronic Bus: An Integrated Multi-media LAN for the Home. Comu-
nication Systems Tecnology Laboratory, Panasonic Tecnologies, Inc, Abril 1991.
[3] Introduction to the LonWorks Plataform. Echelon Corporation. Revision 2, http://www.enerlon.
com/JobAids/Intro%20LonWorks%20V2.0.pdf.
[4] S. D. M. Joachim Goeminne. Domotics@home with KNX Flexible, total and educational. KaHo St.
Lieven - Technologiecampus Gent, 2008.
[5] M. Goossens. The EIB System for Home & Building Electronics. The EIB Association, 1998.
[6] R. Nunes. Domobus - a new approach to home automation. 8CLEEE - 8th International Congress
on Electrical Engineering, pages pp.2.19–2.24, Julho 2003.
[7] Openhab. http://www.openhab.org/features.html. Acedido: Setembro 2015.
[8] Loxone. http://www.loxone.com/enuk/start.html. Acedido: Setembro 2015.
[9] Computer zen - home automation. http://computer-z.com/hmautomation/learn_more.html.
Acedido em: Setembro 2015.
[10] Hai leviton. http://www.leviton.com/OA_HTML/SectionDisplay.jsp?section=61270&
minisite=10251. Acedido em: Setembro 2015.
[11] Control4. http://www.control4.com/solutions/catalog. Acedido em: Setembro 2015.
[12] Crestron. http://www.crestron.com/default.asp. Acedido em: Setembro 2015.
[13] Nuvo. http://www.legrand.us/nuvo.aspx. Acedido em: Setembro 2015.
[14] Heima smart home autmation. https://www.behance.net/gallery/9080423/
HEIMA-Smart-Home-Automation-UI. Acedido em: Setembro 2015.
[15] R. Nunes. A communication infrastructure for home automation. International Conference on Com-
puter, Communications and Control Technologies, Austin, USA, pages pp. 56–61, Agosto 2004.
55
[16] R. Nunes. The DomoBus System Specification Language. Instituto Superior Tecnico, Novembro
2014.
[17] Android quota de mercado. http://www.idc.com/prodserv/smartphone-os-market-share.jsp,
. Acedido: Setembro 2015.
[18] Android versoes android. https://developer.android.com/about/dashboards/index.html, .
Acedido: Setembro 2015.
[19] Android Developer xmlpullparser. http://developer.android.com/training/basics/
network-ops/xml.html. Acedido: Setembro 2015.
[20] L. W. e. a. Arnaud Le Hors, Philippe Le Hegaret. Document Object Model (DOM) Level 3 Core
Specification. W3C, Abril 2004.
[21] I. J. Dave Raggett, Arnaud Le Hors. HTML 4.0 Specification. W3C, Abril 1998. W3C Recommen-
dation, revised on 24-Apr-1998.
[22] J. N. e Thomas k. Landauer. A mathematical model of the finding of usability problems. Proceedings
of ACM INTERCHI’93 Conference, Amsterdam, Netherlands, pages pp. 206–213, Abril 1993.
56
Anexo A
Testes de Usabilidade e Questionario
57
Teste de usabilidade #1
Atributo: Facilidade em alterar propriedades de um dispositivo;
Medir: Tempo despendido para navegar pelas divisões da casa e alterar um atributo de um dispositivo;
Método para medir: Altere a altura da persiana da cozinha para 50%;
Mínimo: 1 min.; Alvo: 35 seg.; Ótimo: 20 seg.;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Teste de Usabilidade #2
Atributo: Facilidade em ordenar dispositivos por serviços;
Medir: Tempo despendido pelo utilizador para ordenar os dispositivos por serviços;
Método para medir: Ordene os dispositivos por serviços;
Mínimo: 40s.; Alvo: 15 seg. ; Ótimo: 5 seg.;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Teste de Usabilidade #3
Atributo: Facilidade na consulta dos cenários;
Medir: Tempo despendido para aceder e ativar um cenário;
Método para medir: Aceda aos cenários disponíveis. Ative o cenário “Filme”.;
Mínimo: 40 seg.; Alvo: 25 seg.; Ótimo: 10 seg.;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Teste de Usabilidade #4
Atributo: Facilidade de acesso ao Modo Operacional;
Medir: Número de erros durante o acesso ao Modo Operacional;
Método para medir: A partir do Modo Geral, aceda ao Modo Operacional;
Mínimo: 5 erros; Alvo: 1 erro; Ótimo: 0 erros;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Teste de Usabilidade #5
Atributo: Facilidade de acesso ao Modo Geral;
Medir: Número de erros para o acesso ao Modo Geral;
Método para medir: A partir do Modo Operacional, aceda ao Modo Geral;
Mínimo: 5 erros; Alvo: 1 erro; Ótimo: 0 erros;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Teste de Usabilidade #6
Atributo: Facilidade de uso dos controlos do Modo Operacional;
Medir: Número de erros na alteração de propriedades no Modo Operacional;
Método para medir: Altere o volume da TV e mude o canal;
Mínimo: 3 erros; Alvo: 1 erro; Ótimo: 0 erros;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Teste de Usabilidade #7
Atributo: Facilidade na utilização de toques para alterar propriedades no Modo Operacional;
Medir: Erros ao alterar a propriedade;
Método para medir: Desligue uma lâmpada do teto a partir do Modo Operacional;
Mínimo: 3 erros; Alvo: 1 erro; Ótimo: 0 erros;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Teste de Usabilidade #8 Atributo: Facilidade de uso do Modo de Configuração do Dispositivo;
Medir: Tempo despendido para adiar a alteração de propriedades;
Método para medir: Aceda ao Modo de Configuração de Dispositivo do Ar condicionado:
O seu estado deve passar para Ventilar;
A propriedade deve ser reposta em 2 minutos.
Mínimo: 2 min.; Alvo: 1 min.; Ótimo: 25seg.;
Atual: ____
Classifique a dificuldade que encontrou nesta tarefa:
Muito Difícil ⃝ ⃝ ⃝ ⃝ ⃝ Muito Fácil
Da(s) tarefa(s) mais difícil/difíceis, quais os motivos que a(s) tornaram de facto difícil/difíceis?
__________________________________________________________________________________________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________
Como podemos facilitar a execução da tarefa?
__________________________________________________________________________________________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________
Detalhes que mudaria.
_____________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________
_____________________________________________________________________________
Anexo B
Resultados dos Testes de Usabilidade
61
Utilizador 1 Utilizador 2 Utilizador 3 Utilizador 4 Utilizador 5 Utilizador 6 Utilizador 7 Utilizador 8 Utilizador 9 Utilizador 10 Utilizador 11 Utilizador 12 Utilizador 13
Média Moda MAX MIN
Teste #1 Tempo (s) 30 25 30 30 50 30 30 30 30 60 10 10 25 34,5 30 60 25
Dificuldade 4 5 5 4 3 4 4 5 4 2 4 5 5 4 4 5 2
Teste #2 Tempo (s) 5 20 10 10 30 7 30 10 35 60 20 7 10 21,7 10 60 5
Dificuldade 5 5 5 5 4 5 4 5 3 1 3 4 5 4,2 5 5 1
Teste #3 Tempo (s) 30 15 10 15 35 15 25 10 35 40 25 10 15 23 15 40 10
Dificuldade 5 5 5 5 2 4 5 5 3 1 4 5 5 4 5 5 1
Teste #4 Erros 0 0 0 5 0 1 0 1 0 2 0 0 0 0,9 0 5 0
Dificuldade 5 5 5 3 5 5 5 5 4 3 4 5 5 4,5 5 5 3
Teste #5 Erros 0 0 3 0 0 7 3 2 0 2 1 1 0 1,7 0 7 0
Dificuldade 4 5 4 5 5 1 3 5 3 3 4 4 5 3,8 5 5 1
Teste #6 Erros 0 0 0 1 0 0 5 0 4 3 2 1 0 1,3 0 5 0
Dificuldade 5 5 5 4 3 5 3 5 2 3 4 4 5 4 5 5 2
Tste #7 Erros 0 0 0 0 5 0 0 0 1 0 0 0 1 0,6 0 5 0
Dificuldade 5 5 5 5 2 5 5 5 4 4 5 5 4 4,5 5 5 2
Tste #8 Tempo (s) 25 30 30 35 35 30 30 60 35 120 40 30 35 43 30 120 25
Dificuldade 4 5 4 5 4 3 4 4 3 1 4 4 5 3,7 4 5 1
Resultados Testes Usabilidade
Nota: Dificuldade Muito Dificil = 1 Muito fácil = 5