mecanismo de supervisão para sistemas domóticos · v resumo a domótica veio trazer variados...

Mecanismo de Supervisão para Sistemas Domóticos

André Filipe Costa Maciel e Silva

Dissertação para Obtenção do Grau de Mestre em

Engenharia Electrotécnica e Computadores

Orientadores: Prof. Renato Jorge Caleira Nunes

Prof. Paulo Rogério Barreiros D’Almeida Pereira

Júri

Presidente: Prof. Nuno Cavaco Gomes Horta

Orientador: Prof. Renato Jorge Caleira Nunes

Vogal: Prof. Alberto Manuel Ramos da Cunha

Abril 2014

iii

Agradecimentos

À minha família, em especial aos meus pais e namorada, por todo o apoio que me deram e paciência

que tiveram ao longo deste meu percurso universitário.

Um especial agradecimento ao Professor Renato Nunes, por todo o apoio e orientação que

demonstrou, principalmente nas longas reuniões que tivemos.

v

Resumo

A domótica veio trazer variados benefícios à nossa interacção com as habitações, melhorando o

nosso conforto, segurança e permitindo um controlo dos gastos energéticos.

Estas e outras vantagens fazem com que a procura por sistemas domóticos tenha aumentado.

Mas o facto de os sistemas actuais serem, ou fáceis de instalar e configurar, mas possuírem muitas

limitações funcionais, ou oferecerem uma elevada funcionalidade mas serem difíceis de configurar,

cria problemas em escolher o sistema mais adequado.

Torna-se assim necessário desenvolver um sistema que consiga realizar as mais exigentes tarefas,

mas que seja fácil de configurar, podendo ser programado por qualquer utilizador.

Esta dissertação tem como objectivo a criação de um software de gestão domótica, que tem por base

o sistema DomoBus. Este software servirá para testar a funcionalidade do sistema DomoBus e a sua

possível implementação em ambientes reais.

Foram definidos três cenários de utilização e foi testado o funcionamento do nosso software.

Conseguiu-se apurar que o sistema é bastante flexível e poderoso, pois oferece todas as ferramentas

base para se poder configurar a maior parte dos cenários.

O software mostrou também poder ser operado por uma pessoa não especializada, pois é fácil de

configurar e operar.

No entanto foram identificadas algumas limitações, em particular, a dificuldade que surge ao

configurar cenários mais complexos. Esses cenários são perfeitamente suportados pelo sistema mas

exigem um esforço maior por parte do utilizador. No entanto considera-se que futuras versões do

software poderão colmatar estes aspectos oferecendo, por exemplo, padrões pré-definidos de

configuração.

Palavras-chave: Domótica, Automação Residencial, Supervisão, Configuração, DomoBus.

vii

Abstract

Home automation has brought many benefits to our interaction with homes, improving comfort, safety

and allowing greater energy efficiency.

These and other advantages increase the demand for home automation systems.

But the fact that current systems are, or easy to install and configure, but have many functional

limitations, or offering high functionality but are difficult to configure, creates problems in choosing the

most suitable system.

So it becomes necessary to develop a system that can be powerful, accomplishing the most

demanding tasks and, at the same time, be easy to configure and program by any user.

This dissertation aims to develop a home automation management software, which is based on the

DomoBus system. This software will allow testing the functionality of the DomoBus system and its

possible application in real environments.

Three usage scenarios were defined and the operation of our software was tested. We concluded that

the system is very flexible and powerful, and it offers all the basic tools to manage most usage

scenarios.

The software also showed it can be operated by an unskilled person, as it is easy to configure and

operate.

However some limitations were identified regarding, in particular, the difficulty to configure complex

scenarios. These scenarios are fully supported by the system but require more effort from the user to

configure them. However, we believe future versions of the software may address these issues by

offering, for example, predefined configuration patterns.

Keywords: Domotics, Home automation, supervision, configuration, DomoBus.

ix

Índice

1. Introdução ............................................................................................................ 1

2. Edifícios Inteligentes ........................................................................................... 3

2.1. Domótica .................................................................................................... 3

2.2. Protocolos Existentes ............................................................................... 4

2.2.1. X10 ................................................................................................. 5

2.2.2. KNX ................................................................................................ 7

2.2.3. Lonworks ..................................................................................... 10

2.2.4. Resumo ....................................................................................... 11

3. Sistema DomoBus ............................................................................................. 13

3.1. Casas Superautomatizadas .................................................................... 13

3.2. Arquitectura DomoBus ........................................................................... 15

3.3. Módulo de Supervisão ............................................................................ 17

3.4. Hardware do Módulo de Supervisão ..................................................... 17

3.5. Dispositivos e Propriedades .................................................................. 18

4. Mecanismo de Supervisão ............................................................................... 21

4.1. Programações ......................................................................................... 21

4.1.1. Programa simples ...................................................................... 22

4.1.2. Programa Complexo .................................................................. 22

4.1.3. Programa Horário ...................................................................... 23

4.1.4. Sequência ................................................................................... 24

4.2. Aplicação de Supervisão ....................................................................... 25

4.3. Aplicação Programador ......................................................................... 26

4.3.1. Novos Dispositivos .................................................................... 28

4.3.2. Programa Simples ..................................................................... 29

4.3.3. Programa Complexo .................................................................. 31

4.3.4. Programa Horário ...................................................................... 33

4.3.5. Sequência ................................................................................... 34

5. Implementação .................................................................................................. 37

5.1. Aplicação Programador ......................................................................... 37

5.2. Aplicação Supervisor ............................................................................. 40

5.2.1. Ficheiros de texto ...................................................................... 42

5.2.1.1. Listas.txt ..................................................................... 43

5.2.1.2 Programas.txt ............................................................. 43

x

6. Exemplos de Aplicação .................................................................................... 57

6.1. Cenário Simples ...................................................................................... 58

6.2. Cenário Moderado .................................................................................. 61

6.3. Cenário Complexo .................................................................................. 65

7. Conclusão .......................................................................................................... 71

8. Bibliografia ........................................................................................................ 75

xi

Lista de figuras

Figura 2.1 - Exemplo de ligação usando módulos X10. .................................................................... 6

Figura 2.2 - Método de envio de bits. ................................................................................................ 7

Figura 2.3 - Modelo de ligação do sistema KNX . ............................................................................. 8

Figura 2.4 - Exemplo de uma instalação de iluminação real, com módulos KNX da Schneider Electric. ........................................................................................................................... 9

Figura 2.5 - Esquema exemplificativo de uma rede Lonworks. ......................................................... 11

Figura 3.1 - Exemplo da disposição de aparelhos e dispositivos numa sala. ................................... 14

Figura 3.2 - Representação do sistema DomoBus. ........................................................................... 16

Figura 3.3 - Modelo dos dispositivos do sistema DomoBus. ............................................................. 19

Figura 4.1 - Modelo de interacção entre a aplicação Programador e a aplicação Supervisor. ......... 25

Figura 4.2 - Menu inicial da aplicação Programador. ......................................................................... 26

Figura 5.1 - Estrutura de dados, usada na comunicação entre Programador e Supervisor. ............. 38

Figura 5.2 - Estrutura do módulo supervisor. .................................................................................... 41

Figura 6.1 - Exemplo da disposição de aparelhos e dispositivos numa sala. ................................... 57

xiii

Lista de Tabelas

Tabela 2.1 - Tabela de comparação dos vários protocolos. ............................................................... 12

Tabela 3.1 - Descrição dos dispositivos da figura 6. .......................................................................... 14

Tabela 4.1 - Condições possíveis para os programas simples. ......................................................... 22

Tabela 4.2 - Operadores possíveis para os programas complexos. .................................................. 23

Tabela 5.1 - Comandos enviados entre as aplicações Programador e Supervisor. ........................... 39

Tabela 6.1 - Representação dos dispositivos da figura 5.1. ............................................................... 58

Tabela 6.2 - Tabela XOR entre os valores dos interruptores 2 e 3. ................................................... 63

Tabela 6.3 - Tabela AND entre os valores das condições 1 e 2. ....................................................... 67

1

1. Introdução

Existe um crescente interesse na automação doméstica, o que leva a um aumento na procura e

instalação de sistemas domóticos por parte dos proprietários de habitações e de pequenos espaços

comerciais. Este aumento leva à procura de soluções tecnológicas cada vez mais baratas e fáceis de

utilizar.

É a partir desta necessidade que surge a oportunidade de criar um novo sistema domótico. Um

sistema que por um lado mantenha os custos reduzidos e que por outro lado seja fácil de instalar,

fácil de configurar e fácil de operar.

Os sistemas domóticos normalizados existentes actualmente no mercado (KNX, X10, LonWorks,

etc…) além de muito dispendiosos, são normalmente difíceis de instalar e configurar. No caso dos

sistemas KNX e LonWorks, por exemplo, é necessária a intervenção de técnicos especializados para

a sua instalação e o uso de aplicações próprias para esse fim. O sistema X10 é uma excepção pois

pode ser instalado por uma pessoa comum. No entanto, a fácil instalação é directamente

comprometida pela limitação e capacidade do próprio sistema.

O objectivo final é então o de criarmos um sistema que possa ser configurado pelo utilizador final,

sem que este tenha que ter conhecimentos ou competências específicas, além da simples operação

de um computador, ao mesmo tempo que criamos um sistema muito dinâmico, modular e robusto.

O sistema DomoBus está a ser desenvolvido oferecendo um modelo abstracto dos dispositivos

domóticos que é independente de qualquer tecnologia. Em particular considera-se que o sistema

DomoBus pode funcionar como plataforma de integração de diferentes tecnologias (através do uso de

gateways adequados). Assim há interesse em desenvolver mecanismos de supervisão poderosos

para a plataforma DomoBus, que permitam gerir e definir o comportamento desejado para um

sistema. Face às características de interoperabilidade do sistema DomoBus, esses mecanismos

podem depois ser usados para gerir um sistema heterogéneo que use diferentes tecnologias. Esses

mecanismos devem ser os mais genéricos e flexíveis possíveis, pretendendo-se que usem uma

abordagem fácil de entender por qualquer pessoa, permitindo assim que, através de uma aplicação

adequada, um utilizador comum possa definir como a sua habitação se comporta.

Ao mesmo tempo, pretende-se seguir um modelo em que a definição e alteração das regras de

funcionamento do sistema possam ser efectuadas em qualquer momento, sem necessidade de parar

o sistema para o reconfigurar. Deste modo o utilizador pode alterar o sistema sempre que deseje,

facilitando a adequação às suas preferências ou necessidades.

Os mecanismos de supervisão serão baseados em três conceitos base: regras, sequências

temporizadas de acções e agendamento de acções.

As regras correspondem essencialmente á implementação de uma lógica de tipo “IF condição THEN

lista-acções ELSE lista-acções”. As sequências temporizadas indicam ao sistema para aguardar um

certo tempo e depois desencadear uma lista de acções. E o agendamento corresponde a

programações horárias, permitindo ligar ou desligar equipamentos a determinada hora de

2

determinado dia, ou então repetir essas actuações que podem verificar-se, por exemplo, em vários

dias da semana ou vários dias do mês.

Ao longo desta dissertação, começamos por explicar e comparar o nosso sistema com os principais

protocolos de domótica que serão seus concorrentes, isto no capítulo 2.

No capítulo 3, explica-se o que é e como funciona o sistema DomoBus. Começa-se por definir o

conceito de casa superautomatizada, apresentando para o efeito um exemplo, que será usado ao

longo dos restantes capítulos. Se seguida define-se o que é o sistema DomoBus e em que consiste o

módulo de supervisão. Finalmente explica-se em que consistem os dispositivos e propriedades.

No capítulo 4, ainda sobre o sistema DomoBus, explica-se em que consiste o Mecanismo de

Supervisão, objectivo desta dissertação. Começamos por explicar em que consistem as

programações, explicitando os diferentes tipos de programações que podem ser usadas neste

sistema. Finalmente explica-se o que é, e como funciona a aplicação de supervisão, em particular o

funcionamento da aplicação Programador, aplicação que será usada pelo utilizador para parametrizar

o sistema.

No capítulo 5, explica-se todo o funcionamento do Mecanismo de supervisão, expõe-se em detalhe

as diferentes aplicações, a aplicação Programador e aplicação Supervisor. Explica-se também a

função e funcionamento dos ficheiros de texto.

No capítulo 6 apresentam-se três exemplos de funcionamento com a aplicação de supervisão criada

ao abrigo desta dissertação de mestrado. Começamos por um exemplo fácil, passamos por um

intermédio e terminamos com um exemplo complexo que usa as propriedades horárias do sistema.

Finalmente, no capítulo 7, apresentam-se as conclusões da presente dissertação.

3

2. Edifícios Inteligentes

Com uma crescente consciencialização por parte da sociedade para a necessidade da poupança

energética, seja para reduzir os custos do funcionamento dos edifícios ou para proteger o meio

ambiente, tornou-se necessário habilitar os edifícios, quer comerciais (escritórios, lojas, centros

comerciais) quer habitacionais, de capacidades gestoras do consumo e do seu funcionamento,

procurando aumentar a eficiência no uso da energia.

Ao mesmo tempo que a tecnologia vai evoluindo, e novas soluções são desenvolvidas existe também

uma cada vez maior procura de sistemas que melhorem os níveis de conforto e de segurança das

habitações e edifícios.

Por outras palavras, é hoje possível controlar activamente os gastos de uma habitação, protegendo

assim o meio ambiente ao evitar gastos energéticos desnecessários, ao mesmo tempo que se

fortalece a relação entre as casas e os seus habitantes.

2.1. Domótica

O termo “Domótica” resulta da junção da palavra “Domus”, termo latim que significa Casa, com

“Telemática”, que significa a junção entre electrónica e informática.

No dicionário a palavra domótica significa:

“Conjunto das técnicas e dos estudos tendentes a integrar no habitat todos os automatismos em

matéria de segurança, de gestão de energia, de comunicação, etc.”

In, Dicionário Priberam da Língua Portuguesa (http://www.priberam.pt)

Trata-se de um conceito de automação que procura encontrar soluções que dêem resposta à

necessidade do homem de querer despender o mínimo de esforço nas actividades diárias e

rotineiras. Assim a domótica, para além de introduzir conforto e melhoria de vida aos seus

utilizadores, introduz ainda novos conceitos, tais como comunicação e segurança.

Obviamente que este melhoramento de vida e comodidade apenas se consegue associando

tecnologia. Mas é importante garantir que a utilização dessa tecnologia seja fácil para o utilizador

comum.

A domótica consegue ir ao encontro dessa linha de raciocínio, dando cada vez maiores passos para

melhorar a vida do ser humano.

4

A domótica utiliza e associa as vantagens dos meios electrónicos e informáticos, de forma a obter

uma utilização e uma gestão integrada dos diversos equipamentos de um edifício, seja ele residencial

ou comercial.

A utilização de um sistema domótico pode ser feita activa ou passivamente.

No funcionamento passivo, um elemento reage só quando lhe é transmitida uma ordem, dada

directamente pelo utilizador, podendo ser utilizados todos os recursos disponíveis, botões de pressão,

painéis tácteis, telecomandos, ordens vocais, etc.

No funcionamento activo, mais avançado e com mais inteligência, o sistema não só interpreta

parâmetros, como reage às circunstâncias (informação transmitida pelos sensores). Por exemplo,

pode detectar que uma janela se encontra aberta e avisar o utilizador, ou pode detectar a temperatura

e manter uma temperatura constante na divisão, ligando e desligando o aquecimento sempre que

necessário.

Hoje é possível controlar remotamente os sistemas domóticos, podendo utilizar o telemóvel ou a

internet, para aceder às funções vitais da casa (ou comércio), para ligar ou desligar o sistema de rega

do quintal, ou para ligar o aquecimento momentos antes de se chegar a casa. Podemos também

utilizar estes sistemas como sistemas anti furto, garantindo assim a segurança do lar ou da empresa.

2.2. Protocolos Existentes

A variedade de protocolos normalizados direccionados para a domótica é grande.

No mercado, os sistemas mais usuais utilizam o protocolo X10 por ser mais económico, mas este tem

a grande desvantagem de ser pouco robusto e ter muitas limitações. Sistemas que utilizam este

protocolo são facilmente encontrados, quer por utilizarem a rede eléctrica como meio de

comunicação, quer por não necessitarem de instaladores experientes, nem da instalação de mais

cablagem porque a instalação eléctrica existente é aproveitada. Estes sistemas são aconselhados

quando apenas se necessita de um controlo simples e pouco exigente.

Um protocolo normalizado muito utilizado em sistemas domésticos é o KNX. Este protocolo oferece

muita robustez e flexibilidade. Contudo seus os produtos possuem um elevado custo. O protocolo

KNX permite a utilização de vários meios físicos de comunicação, mas o mais utilizado é o par

entrançado onde todos os dispositivos estão ligados a um Bus. Notar que esta solução de par

entrançado obriga à existência de uma fonte de alimentação para o barramento, o que acaba por

encarecer ainda mais a instalação deste sistema.

O KNX é um protocolo aberto e por esta razão, existem no mercado diversos fabricantes que têm

produtos que utilizam este protocolo, o que acaba por ser uma vantagem, garantindo a continuidade

na existência destes sistemas.

5

Existe ainda o protocolo Lonworks que apesar de estar desenhado para cobrir todos os requisitos da

maior parte das aplicações de controlo, só tem tido êxito na sua implementação em edifícios

administrativos, hotéis e indústrias. Devido ao seu custo, os dispositivos LonWorks não têm tido

grande implementação nas casas, sobretudo porque existem outras tecnologias com prestações

iguais e mais baratas.

2.2.1. X10

A tecnologia X10 foi inventada e patenteada no final da década de 70 por uma empresa chamada

PICO Electronics. Esta empresa pretendia desenvolver uma tecnologia de controlo remoto, que

usasse a rede eléctrica já existente, ou seja as linhas de baixa tensão (230V na europa, 110V nos

EUA) para enviar os sinais de controlo. A empresa já tinha tentado e desistido 9 vezes, até que à

décima tentativa conseguiu obter sucesso, assim vem o nome (X10) [26].

A tecnologia X10 usa a rede de distribuição de energia eléctrica como meio de comunicação entre os

vários dispositivos. Este é um aspecto chave desta tecnologia e a sua maior vantagem face a outras

soluções pois permite o seu uso em qualquer casa, sem necessidade de passar cabos adicionais, ao

mesmo tempo que reduz o custo da instalação. Este método de comando abriu todo um novo mundo

relativo ao controlo remoto de dispositivos, podendo controlar praticamente qualquer aparelho que

esteja ligado à rede eléctrica sem que seja necessário passar nova cablagem tornando-se assim

muito menos dispendioso. Este é o factor chave para que esta tecnologia se tenha tornado um

sucesso comercial.

O baixo custo e principalmente a fácil instalação, uma vez que a instalação pode ser feita por

qualquer electricista sem conhecimentos de automação ou informática, ou até mesmo pelos próprios

utilizadores, fez com que actualmente seja um dos sistemas mais utilizados no mundo em relação ao

mercado habitacional, sendo líder no mercado norte-americano.

Os dispositivos podem ser ligados directamente nas tomadas e ser usados para ligar ou desligar

equipamentos, ligar ou desligar lâmpadas ou regular a sua intensidade luminosa.

Basicamente, o sistema X10 consiste na transmissão de sinais codificados através da rede eléctrica

de 50Hz ou 60Hz. Usam-se dispositivos transmissores para enviar o sinal através da rede, e

dispositivos receptores que captam esses sinais, como se pode ver na figura 2.1.

6

Figura 2.1 – Exemplo de ligação usando módulos X10.

O envio de informação através da rede eléctrica é feito através do uso de impulsos na frequência de

120kHz. Esses impulsos têm a duração de 1 ms e ocorrem em sincronismo com a passagem por zero

da onda sinusoidal da rede eléctrica. Esta particularidade é usada pelos receptores para saberem

quando devem escutar a linha. O valor binário 1 corresponde à presença do sinal de 120kHz e o valor

binário 0 corresponde à ausência desse sinal.

No caso de instalações eléctricas trifásicas, os impulsos de 120kHz são enviadas 3 vezes em cada

ciclo da rede eléctrica, em momentos que coincidem com a passagem por zero de cada uma das

fases da rede. Assim, usando dispositivos chamados de acopladores é possível, dentro de um

mesmo edifício, os dispositivos comunicarem entre si independentemente de estarem na mesma fase

ou não.

Como o meio de distribuição de energia é muito ruidoso electricamente, foi adoptada a política de

nunca enviar um bit isolado, sendo sempre enviado o bit e o seu complemento. Na prática, quando se

quer enviar o bit 1, é enviado um impulso (1), seguida de ausência de sinal (0). Quando se quer

enviar o bit 0, é feito o inverso, primeiro uma ausência de sinal (0), e depois enviada um impulso (1).

Pode-se verificar este método na figura 2.2.

Assim reduz-se a probabilidade do ruido eléctrico interferir no envio de sinais, pois o ruído podia ser

confundido com um sinal não enviado [1].

7

Figura 2.2 – Método de envio de bits.

A transmissão completa de uma mensagem X10 necessita então de onze ciclos de corrente. A

mensagem divide-se em três campos de informação:

1. Dois ciclos representam o Código de Início – Sequência de 4 bits, sempre 1110, que identifica

o início da mensagem.

2. Quatro ciclos representam o Código de Casa (letras de A-Z) – Conjunto de 4 bits que

identifica a casa onde o sistema está instalado. Evita-se assim problemas de interferências nos

comandos entre casas vizinhas.

3. Cinco ciclos representam o Código do dispositivo (1-16) ou o Código de Função (acender a

luz, apagar a luz, variar a luz, etc...) – Conjunto de 4 + 1 bits que identificam o dispositivo ou a

função a ser executada, mais um bit extra que identifica se a mensagem se refere a um

dispositivo ou a uma função.

Para aumentar a fiabilidade do sistema, esta mensagem, (Código de inicio, código de casa e código

de dispositivo ou função) é transmitida sempre duas vezes, separadas por três ciclos completos de

corrente. Há uma excepção, nas funções de variação de intensidade, em que é transmitido de forma

contínua, sem separação entre mensagens.

Como principais vantagens do X10 apontam-se a sua simplicidade, a facilidade de instalação e uso, e

o custo acessível. Como principais desvantagens refere-se o baixo ritmo de comunicação, a baixa

fiabilidade do protocolo e um número limitado de funções que essencialmente se restringem ao

controlo de iluminação e à capacidade de ligar ou desligar dispositivos.

2.2.2. KNX

O sistema KNX, abreviatura para Konnex, resultou da fusão dos maiores sistemas europeus que

utilizavam a tecnologia de bus, incluindo o bem-sucedido sistema EIB (European Installation Bus).

8

Esta fusão resultou da necessidade de enfrentar a concorrência vinda dos Estados Unidos, com os

sistemas X10 e Lonworks.

O sistema KNX tornou-se então o único sistema normalizado globalmente para a automação

residencial e não residencial, passando a estar definido pelas principais normas internacionais.

Assim criou-se um sistema claramente definido onde todos os produtos KNX mesmo de diferentes

fabricantes podem interagir e funcionar em conjunto. Assim garante-se a uniformização, a

interoperabilidade e um fácil funcionamento em rede com todos os dispositivos, tanto os dispositivos

actuais quer os futuros.

Este é um protocolo já enraizado no mercado onde constam mais de 170 fabricantes e se estimam

mais de 10 milhões de sistemas já instalados [17].

O KNX interliga todos os componentes de uma instalação eléctrica de maneira a formarem uma rede

e assim garantir a transparência e fiabilidade na transferência de informação ao longo da rede.

Neste sistema todos os dispositivos comunicam através de um cabo de BUS, sendo possível

interligar todos os subsistemas dentro de um edifício usando a mesma rede. Na figura 2.3 pode-se

observar um exemplo da forma de ligação do sistema KNX.

As aplicações deste sistema abrangem a iluminação, estores, sistemas de segurança, gestão de

energia, aquecimento, ventilação e ar-condicionado, sistemas de monitorização e sinalização,

controlo remoto, controlo de áudio/vídeo, electrodomésticos, etc [14].

Trata-se de um sistema bastante abrangente e completo podendo todas estas funções ser

controladas, monitorizadas e sinalizadas através de um sistema único sem necessidade de uma

unidade de controlo central, uma das vantagens do KNX.

Figura 2.3 – Modelo de ligação do sistema KNX.

9

Todos os sensores (botões pressão, interruptores, detectores de movimento) encontram-se ligados

aos actuadores (controladores de estores e persianas, controladores de lâmpadas) através de um

cabo de dados, alimentado a 30V, em oposição ao que acontece num sistema convencional, onde

interruptores e lâmpadas, por exemplo, se encontram ligados directamente pela rede eléctrica de

230V.

O cabo de bus pode interligar até 50.000 dispositivos, embora o bus necessite ser dividido em

segmentos, interligados por “line-couplers”. Além do cabo de bus, a tecnologia KNX já permite a

utilização de redes IP/Ethernet, radiofrequência e da própria rede eléctrica para a comunicação entre

dispositivos.

Os actuadores são os dispositivos que ligam ao circuito de potência, e portanto que irão alimentar os

dispositivos finais (lâmpadas, tomadas, estores), como podemos ver no exemplo da figura 2.4.

Figura 2.4 – Exemplo de uma instalação de iluminação real, com módulos KNX da Schneider Electric

[16].

A comunicação entre dispositivos é feita usando “mensagens”. Os sensores enviam comandos aos

actuadores que os “escutam” e executam a função programada. Essa função pode ir de um simples

comando on/off, até sequências logicas, passando por funções de controlo ou regulação.

Em termos de instalação e configuração, existem duas modalidades [14]:

S-Mode (system mode) – Este modo de configuração é destinado a ser implementado por

técnicos especializados e permite realizar as funções mais complexas permitidas pelo

10

sistema. A instalação através deste modo é feita usando um software especializado,

designado de ETS (Engineering Tool Software).

E-Mode (Easy Mode) – Este modo de configuração é destinado a utilizadores sem grandes

conhecimentos do sistema KNX. Este modo oferece menos funções, em comparação com

sistemas configurados atraves do S-Mode. Os componentes do sistema que usam este modo

de configuração, já vêm pré-programados, bastando configurar um pequeno conjunto de

parâmetros para colocar o sistema a funcionar.

Uma das desvantagens do sistema KNX é precisamente a necessidade de recorrer a técnicos

especializados para parametrizar os sistemas e implementar estas funções. Quanto maior a

dimensão das instalações do KNX, maior será a complexidade da sua programação.

2.2.3. Lonworks

Passemos agora ao protocolo Lonworks, que na realidade não é um protocolo mas sim uma

tecnologia, visto que inclui tanto o hardware como o software para a operação de uma rede de

controlo, que será denominada Local Operating Network (LON). Trata-se de uma tecnologia livre para

controlo distribuído, projectada para implementar a interoperabilidade de redes de controlo.

O protocolo utilizado é denominado LonTalk e foi projectado para aplicações que envolvam funções

de leitura de sensores, controlo, monitorização e identificação.

São permitidos seis meios de transmissão dos sinais: rede eléctrica, par entrançado, cabo coaxial,

infravermelhos, radiofrequência e fibra óptica.

O principal constituinte de uma rede Lonworks é um circuito integrado chamado Neuron Chip, que

actua como um nó da rede, incluindo o hardware que possibilita a comunicação e o protocolo

LonTalk.

Uma rede Lonworks é composta por [12]:

Módulos de controlo Lonworks que incluem o Neuron Chip, e firmware associado.

Transceivers que permitem a conexão aos vários meios físicos de comunicação.

Routers que interligam as diferentes sub-redes e/ou meios de transmissão.

Interfaces de rede onde se podem ligar outros elementos baseados no protocolo LonTalk, tais

como computadores, controladores lógicos programáveis (PLC) etc.

Ferramentas de instalação, configuração e diagnóstico tanto dos nós como das redes de

controlo.

11

Ferramentas de desenvolvimento de aplicações, compilador Neuron C. etc.

A figura 2.5 mostra um exemplo de uma rede de controlo Lonworks típica.

Figura 2.5 – Esquema exemplificativo de uma rede Lonworks.

O sistema Lonworks é programável, podendo ser a qualquer momento adicionadas novas funções, ou

alteradas as existentes, bastando para isso programar e compilar novos programas e de seguida

carregá-los no Neuron Chip respectivo. Esta é uma das características que faz deste sistema um dos

mais completos no mercado, e é por isso que são bastante usados nas áreas industrial e comercial,

onde os requisitos de automação são maiores que os possibilitados por outros sistemas domóticos.

O facto de ser um sistema bastante robusto e muito programável também o torna dispendioso, outra

das razões porque é mais utilizado nas áreas industrial e comercial, tendo pouca expressão na área

habitacional.

2.2.4. Resumo

Para finalizar este capítulo, apresenta-se uma comparação entre os 3 protocolos/sistemas domóticos

descritos anteriormente.

12

Na Tabela 2.1 encontram-se representadas as principais características destes protocolos, com as

vantagens e desvantagens, bem como os meios de transmissão e finalmente uma comparação do

custo dos vários sistemas.

Tabela 2.1 – Tabela de comparação dos vários protocolos.

Protocolo Meios de

Transmissão Vantagens Desvantagens Preço

X10 - Rede eléctrica

- Radiofrequência

- Facilidade de

instalação

- Preço

- Reduzidas

Funcionalidades

- Reduzido número

de dispositivos

permitido

Reduzido

KNX

- Par Entrançado

- Rede Ethernet

- Radiofrequência

- Rede Eléctrica

- Elevado número de

funções

- Instalação Complexa

- Preço Médio

LonWorks

- Rede Eléctrica

- Par Entrançado

- Cabo Coaxial

- Infravermelhos

- Radiofrequência

- Fibra Óptica

- Muito configurável

- Elevado número de

Funções

- Instalação Complexa

- Preço Alto

Após observação da tabela anterior não se pode dizer que um protocolo seja melhor que o outro. Um

protocolo será tanto melhor quanto mais se aproximar das necessidades do seu utilizador. Assim

podemos concluir que não existe um protocolo ou sistema perfeito.

O nosso sistema DomoBus que será descrito no próximo capítulo procurará assim conjugar o melhor

que cada protocolo terá para oferecer: muito configurável, elevado número de dispositivos aceites,

baixo preço, facilidade de configuração.

13

3. Sistema DomoBus

Neste capítulo faz-se a descrição da tecnologia DomoBus, começando por introduzir as razões que

motivaram o desenvolvimento de uma nova tecnologia de automação residencial. Para isso

apresenta-se o conceito de casa Superautomatizada e em seguida, descreve-se a tecnologia, a sua

arquitectura, as diferenças e semelhanças com as restantes tecnologias e o seu modo de

funcionamento.

Finalmente introduz-se o mecanismo de supervisão, o coração por detrás do funcionamento do nosso

sistema.

3.1. Casas Superautomatizadas

O conceito de casa Superautomatizada [8] surge com a evolução da tecnologia presente nas nossas

casas, nos dias de hoje.

Antigamente numa divisão, digamos, numa sala de estar, podíamos encontrar uma lâmpada no tecto,

um interruptor, uma televisão, talvez um vídeo (VHS), mas pouco mais.

Hoje em dia nas casas modernas, temos na mesma sala, vários interruptores para vários pontos de

luz, televisão, leitor de DVD, estores eléctricos, ar condicionado, sensores de movimento, sensores

de temperatura e muitos mais dispositivos.

Ora quando se pretende controlar todos estes dispositivos de uma forma automática, é aqui que nos

damos conta do enorme desafio que a automatização dessa divisão e consequentemente dessa casa

representam. É assim que nasce o conceito de casa Superautomatizada.

Vejamos um exemplo de uma divisão, digamos novamente uma sala. Na figura 3.1 encontra-se uma

representação dessa sala e na tabela 3.1 os dispositivos nela contida.

14

Figura 3.1 – Exemplo da disposição de aparelhos e dispositivos numa sala.

Tabela 3.1 – Descrição dos dispositivos da figura 6.

# DISPOSITIVO

1 - Interruptor 1

2 - Interruptor 2

3 - Interruptor 3

4 - Lâmpada 1

5 - Lâmpada 2

6 - Detector de Movimentos

7 - Botão de Estore 1


9 - Estore 1

10 - Estore 2

11 - Termostato

12 - Ar Condicionado

13 - Televisor

15

Podíamos adicionar muitos mais dispositivos mas por questões de simplicidade vamos restringir o

exemplo a estes.

Temos presente nesta divisão três interruptores genéricos, cuja função é apenas ligar/desligar, existe

um sensor de movimento, um sensor de temperatura, designado como termostato, existem 2 estores

eléctricos e respectivos botões, duas lâmpadas no tecto e finalmente uma unidade de ar

condicionado e uma televisão LCD.

Vendo este exemplo podemos imaginar a complexidade que será automatizar esta divisão, para que

se possam efectuar tarefas complexas, ou até controlo à distância. Estamos a falar de funções, que

podem ser tão simples como colocar o interruptor 1 a acender e apagar a lâmpada 1. Podemos

também fazer o interruptor 2 e o interruptor 3 trabalharem em conjunto para acender e apagar a

lâmpada 2 de modo complementar, ou seja, quando um acende a seguir o outro apaga, ou quando

um apaga, a seguir o outro acende.

Mas tarefas mais complexas podem ser exigidas, imagine-se a possibilidade do utilizador do sistema

poder sair do emprego a caminho de casa num inverno rigoroso e pelo caminho poder dar ordem ao

ar condicionado para começar a aquecer a divisão, para quando chegar poder desfrutar do conforto.

Ou então poder-se programar o sistema para que quando as luzes estiverem ligadas mas o detector

de movimentos não detecte ninguém na divisão, as luzes se apaguem, mas isto apenas passado

algum tempo, evitando que as luzes estejam sempre a acender e a apagar, sempre que a pessoa se

ausenta temporariamente.

Podemos imaginar inúmeros cenários diferentes, que seriam possíveis se esta divisão possuísse um

sistema automatizado.

Na próxima secção demonstra-se como automatizar esta e outras divisões, usando o sistema

DomoBus.

3.2. Arquitectura DomoBus

O sistema DomoBus é um sistema que aborda a domótica a dois níveis distintos. Contempla uma

camada de interacção de baixo nível, que está associada à leitura de sensores e ao comando de

actuadores, e uma camada de alto nível que consiste na gestão e supervisão do sistema domótico.

O sistema DomoBus está organizado como se demonstra na figura 3.2, no topo temos presente o

módulo de supervisão, é ele que gere os módulos de controlo, ao coordenar os comandos enviados e

recebidos dos dispositivos físicos (sensores e actuadores) [8].

Embora a figura ilustre apenas um módulo de supervisão, num sistema com uma dimensão

significativa podem existir múltiplos módulos, interligados por uma rede TCP/IP.

Os módulos de controlo fazem a ponte entre o módulo de supervisão e os dispositivos físicos. Estes

módulos não estão ainda concluídos, existindo alguns protótipos em fase de desenvolvimento. De

salientar que os módulos de supervisão se podem ligar a dispositivos de outras tecnologias (X10,

KNX, etc) através de adaptadores adequados.

16

Figura 3.2 – Representação do sistema DomoBus.

O nível de gestão e supervisão do sistema, onde são definidas a localização e configuração de

dispositivos, segue uma abordagem genérica independente da tecnologia utilizada. Um elemento

chave desta abordagem é o modelo que é seguido para os dispositivos domóticos [6]. Neste modelo,

um dispositivo domótico é uma entidade genérica, descrita por um conjunto de propriedades,

existindo um conjunto base de operações para ler ou alterar essas propriedades, ou para os próprios

dispositivos notificarem o supervisor sempre que ocorre uma alteração nos seus valores.

A solução DomoBus inclui uma linguagem de especificação baseada em XML, como pode ser visto

em [11], que permite descrever a constituição de qualquer sistema, explicitando que dispositivos

existem e quais as suas características. Essa linguagem permite também descrever a estrutura de

qualquer habitação e identificar a localização de cada dispositivo. Permite ainda a definição de

cenários, que correspondem a uma lista de acções a serem executadas sobre diversos dispositivos.

Futuramente a linguagem será expandida para permitir especificar o comportamento e as

programações desejadas para o sistema (que está directamente relacionado com o trabalho desta

dissertação).

Esta componente de alto nível pretende ser o mais genérica e flexível possível, podendo ser usada

para supervisionar partes de um sistema que use outra tecnologia, dando assim suporte à integração

de sistemas heterogéneos, permitindo explorar o que cada tecnologia específica possa ter de melhor

em cada contexto de utilização.

17

3.3. Módulo de Supervisão

É o módulo de supervisão que terá a tarefa de controlar todo o sistema domótico. É nele que corre o

software de controlo, denominado Supervisor, criado no âmbito desta dissertação e que inclui a

Biblioteca de Supervisão.

A Biblioteca de Supervisão é constituída por uma biblioteca de funções em linguagem C, que permite

gerir em tempo real uma dada divisão, uma casa, um escritório ou até mesmo um edifício inteiro. A

escolha da linguagem C teve como objectivo facilitar a portabilidade para diferentes plataformas

hardware, mesmo de reduzida capacidade de memória e processamento.

Essas funções permitem a criação de programas que fazem interagir os diversos dispositivos

presentes no sistema. Um exemplo de uma programação será por exemplo, ordenar ao sistema que,

ao pressionar um determinado botão, deverá acender uma determinada lâmpada (sem que essa

lâmpada tenha que estar fisicamente ligada a esse botão, ao contrário das instalações eléctricas

convencionais).

Este sistema permite outros tipos de programação muito mais complexos, como veremos mais à

frente. Permite também programações horárias, pois incorpora um módulo de gestão do tempo.

Com estes programas e com a gestão do tempo é possível fazer quase tudo com este sistema,

relativamente á automatização residencial.

Num sistema podem existir vários módulos de supervisão, criando assim um sistema descentralizado,

em que diferentes módulos poderão estar localizados e a controlar, diferentes zonas da residência,

diferentes pisos, ou diferentes edifícios, mas podendo interagir entre si, permitindo por exemplo,

controlar a partir do edifício A, um dispositivo do edifício B.

No contexto da presente dissertação foi testado um sistema com apenas um módulo de supervisão.

Em relação à capacidade de processamento, o módulo de supervisão não precisa de grande poder

de processamento, podendo ser constituído por um “Single Board Computer”, (SBC). Dada a

constante evolução deste tipo de equipamento, tomou-se a opção de recorrer a um SBC que

disponha do sistema operativo Linux e capacidade de ligação em rede, suportando TCP/IP.

Existe um grande número de SBCs que satisfazem estes requisitos. No entanto destaca-se em

particular o modelo Raspberry Pi [2, 23], que tem um custo na ordem de 30 euros e possui

capacidades mais do que suficientes para controlar a maioria das instalações que usam o sistema

DomoBus.

3.4. Hardware do Módulo de Supervisão

Um Raspberry Pi é um pequeno mas poderoso computador [23]. Resume-se a apenas uma pequena

placa que contém todos os elementos centrais de um PC, com o tamanho próximo de um cartão de

18

crédito e que pesa 45g. Torna-se assim perfeito para ser usado em automação residencial, onde

pode ser colocado dentro de uma caixa de derivação dentro da própria parede. Ainda para mais, o

seu preço reduzido, cerca de 30 euros, ajuda a atingir o objectivo de tornar o sistema o menos

dispendioso possível.

Para interacção com o exterior vem equipado com duas portas USB, conector para um cartão SD, e

uma ficha RJ45 para ligação à rede. Essa Ligação pode ser reforçada através de dispositivos Wi-Fi

ligados a uma das portas USB. Tem ainda saídas para vídeo, áudio e HDMI, o que pode ser útil para

implementar interfaces sofisticadas com o utilizador.

O Raspberry Pi vem preparado para correr Linux e a sua distribuição é feita sem restrições, tem

também uma larga variedade de drivers disponíveis.

Outras vantagens do Raspberry Pi são o seu baixo consumo, apenas 3,5W e não fazer barulho pois o

processador não necessita de ventoinha e não existem outros componentes em movimento.

Face a todas estas características, em especial o tamanho e preço, neste momento é a escolha de

eleição para implementar o módulo de supervisão.

3.5. Dispositivos e Propriedades

Todos os mecanismos eléctricos presentes numa habitação e que estejam ligados tanto à rede

eléctrica como ao sistema domótico, são definidos como dispositivos no sistema domobus.

O sistema DomoBus permite representar genericamente cada dispositivo, essa representação é

simples, mas ao mesmo tempo poderosa o suficiente para descrever as capacidades essenciais de

um dispositivo, independentemente da sua tecnologia.

Assim o sistema DomoBus propõe uma solução (detalhada em [6]), em que cada dispositivo é

caracterizado por um conjunto de propriedades, tendo cada propriedade um valor. Por exemplo um

termostato pode ter apenas uma propriedade, Temperatura, que contém o valor actual da

temperatura da divisão, medida pelo dispositivo. No caso de uma lâmpada, ela pode possuir duas

propriedades: Ligado/Desligado e Luminosidade. A primeira propriedade indica se a lâmpada está

ligada ou desligada e a segunda propriedade indica a sua intensidade (numa escala de 0 a 100, por

exemplo). O uso de duas propriedades permite desligar a lâmpada sem alterar a intensidade

previamente definida. Deste modo, quando se voltar a ligar a lâmpada, esta pode assumir o valor de

intensidade anterior.

Os dispositivos mencionados são simples mas é fácil descrever dispositivos mais complexos como,

por exemplo, um televisor. Neste caso, e considerando apenas as funções mais óbvias e úteis, faz

sentido considerar quatro propriedades: Ligado/Desligado, Canal, Volume e ModoSilencioso (mute).

No entanto, seria muito simples adicionar mais propriedades para representar, por exemplo, o brilho,

a cor ou agudos e graves.

Os exemplos anteriores ilustram a abordagem seguida pelo DomoBus, que se detalha em seguida.

19

Figura 3.3 – Modelo dos dispositivos do sistema DomoBus.

A entidade Tipo Dispositivo abstrai dispositivos de um dado tipo, tais como lâmpadas de intensidade

ajustável, sensores de temperatura, ar-condicionado, interruptores comuns, tomadas de energia,

motores de estores, electroválvulas, detectores de fumo, sensores de presença, aparelhagem de alta-

fidelidade, TV, DVD, etc. Convém notar que é possível, a qualquer momento, adicionar novos tipos de

dispositivos, desde que seja possível descrever as suas características usando propriedades tal como

descrito anteriormente.

A caracterização de um Tipo Dispositivo é efectuada usando uma ou mais Propriedade (ver figura

3.3). A mesma Propriedade pode ser usada por qualquer número de Tipo Dispositivo. Esta

particularidade é útil pois permite partilhar propriedades que são comuns a múltiplos dispositivos

como, por exemplo, Ligado/Desligado.

Na figura 3.3 estão representados os principais atributos da classe Propriedades. O atributo Nome

contém a designação da propriedade. Para cada tipo de propriedade é possível definir um modo de

acesso que pode assumir os valores, só-leitura, só-escrita ou leitura-escrita. Para exemplificar o uso

deste atributo, refere-se que a propriedade temperatura de um termostato faz todo o sentido que seja

só-leitura, enquanto a propriedade intensidade-luminosa de uma lâmpada regulável é de leitura-

escrita. Neste último caso, é possível ler o valor da propriedade para conhecer a intensidade actual

da lâmpada em questão e é possível escrever nessa propriedade para alterar a sua intensidade.

20

Todas as interacções com os dispositivos físicos são realizadas exclusivamente lendo ou escrevendo

valores em propriedades.

Outro atributo de Propriedade é Tipo de Valor, que permite distinguir três tipos de valores: Escalar,

Enumerado e Vector.

O tipo Escalar identifica um valor que pode variar entre um valor mínimo e um valor máximo. Esse

valor pode representar uma determinada unidade (por exemplo, graus Celsius, Watt, Lux), pode

corresponder a uma percentagem (escala entre 0 e 100) ou simplesmente não possuir unidades.

Como nalguns casos uma propriedade pode ter apenas um pequeno número de valores. Por

exemplo, a propriedade Ligado/Desligado pode assumir apenas os valores 0 (desligado) e 1 (ligado).

Ou relativamente ao estado de funcionamento de um ar-condicionado, podem-se considerar quatro

possibilidades: desligado (0), ventilar (1), arrefecer (2) e aquecer (3). Para estes casos, e outros

semelhantes, foi criado o tipo Enumerado.

Uma propriedade pode também ser do tipo Vector. Este tipo é usado em propriedades que contêm

uma lista de caracteres (representando um texto ou outro tipo de informação), por exemplo, o código

de um alarme.

Até ao momento foi ilustrado como definir os tipos base de dispositivos, cada um caracterizado por

um conjunto de propriedades. O passo seguinte consiste na definição dos dispositivos concretos

existentes numa habitação. É esse o objectivo da classe Dispositivo.

Por exemplo, um dispositivo designado Lampada_Quarto pode ser criado, sendo explicitado que é do

tipo Lampada_Regulada definido anteriormente. Deste modo, torna-se imediatamente conhecido

quais as propriedades que possui. Neste caso terá as propriedades Ligado/Desligado e

Luminosidade.

O dispositivo específico será associado com tantas propriedades, quantas as que foram definidas

aquando da criação do Tipo Dispositivo.

O modelo apresentado é pois muito flexível e eficaz. Após a definição dos tipos de dispositivos

existentes, torna-se simples adicionar os dispositivos concretos que se pretendem instalar numa dada

habitação.

21

4. Mecanismo de Supervisão

No capítulo anterior foram descritos os aspectos essenciais da arquitectura e modelo seguido no

DomoBus. Finalizou-se o capítulo descrevendo os dispositivos e suas propriedades. Neste capítulo

explica-se como o sistema utiliza estes dispositivos e a suas propriedades para criar a tão desejada

automação residencial.

4.1. Programações

O sistema DomoBus propõe uma abordagem baseada no conceito de cenário, segundo [6].

A referência a cenário será substituída daqui em diante por programa ou programação, de modo a

uma mais fácil compreensão do sistema.

O conceito de programa consiste basicamente no uso de cláusulas do tipo:

IF condição THEN lista-acções ELSE lista-acções

O termo condição pode ser uma expressão tão complexa quanto se queira, a qual pode envolver o

tempo ou o valor de qualquer propriedade de um dispositivo. O valor da propriedade de um

dispositivo é avaliado e se a condição for verdadeira então activará a lista-acções. As acções, de

activação, consistem na atribuição de um valor a uma propriedade de um dispositivo. Na secção 4.3

serão apresentados alguns exemplos.

Esta forma de especificar o comportamento de uma habitação é simples mas eficaz. É fácil de

compreender por uma pessoa comum e simplifica o processo de manter o comportamento desejado,

uma vez que, tipicamente, os cenários são entidades independentes e não interagem ou dependem

uns dos outros.

Para além do que foi definido, os cenários podem também possuir uma lista de acções de

desactivação. Esta lista contém acções que são executadas quando uma condição de activação de

um cenário deixa de se verificar. Ou seja, havendo uma lista de acções de activação, e uma lista de

acções de desactivação, quando a condição passa a verdadeira, serão executadas as acções de

activação, quando a condição passa a falsa, são executadas as condições de desactivação.

As programações possíveis são de vários tipos, existem programações simples, programações

complexas, programações horárias e ainda a utilização de sequências.

22

4.1.1. Programa simples

Sempre que a programação exige apenas o teste de uma propriedade de um dispositivo, é designada

de programa simples.

As condições possíveis encontram-se na tabela seguinte.

Tabela 4.1 – Condições possíveis para os programas simples.

Condição Descrição

= Igual a

≠ Diferente de

< Menor que

≤ Menor ou Igual a

> Maior que

≥ Maior ou igual a

DO Agir Sempre

Assim se o valor de uma propriedade fizer activar a condição escolhida, seguir-se-á a execução das

acções programadas.

A condição “DO” implica que as acções serão executadas sempre que o valor da propriedade muda.

Exemplo:

IF on/off_botão=1 THEN lâmpada_on/off=1

Se a propriedade on/off do botão for igual ao valor 1, então a propriedade on/off da lâmpada será

colocada a 1. Ou seja, se o botão for pressionado a lâmpada será acesa.

4.1.2. Programa Complexo

Quando a programação exige uma interacção entre várias condições, é designada programa

complexo. Os programas complexos utilizam várias condições que são avaliadas utilizando

operadores entre elas. Os operadores são os indicados na tabela 4.2.

23

Tabela 4.2 – Operadores possíveis para os programas complexos.

OPERADOR Descrição

EQUAL Igual (A == B)

NOT Negação (! 𝑨)

AND E Lógico (𝑨&&𝑩)

OR OU Lógico (𝑨||𝑩)

XOR OU Exclusivo (𝑨⨁𝑩)

XNOR Equivalente (𝑨⨁𝑩̅̅ ̅̅ ̅̅ ̅)

O modo de funcionamento é em tudo semelhante ao dos programas simples, ou seja, quando a

condição geral passa a verdadeira, as acções são executadas.

Exemplo:

IF (on/off_botão_1=1) OR (on/off_botão_2=1) THEN lâmpada_on/off=1

Se a propriedade on/off do botao_1 tiver o valor 1, OU a propriedade on/off do botao_2 tiver o valor 1,

a lâmpada acenderá. Ou seja, esta programação permitirá acender a lâmpada, qualquer que seja o

botão pressionado.

4.1.3. Programa Horário

Os programas horários, como o nome indica, utilizam a informação dada pelo relógio para activar ou

desactivar determinadas acções.

A condição aqui é representada por um horário: ano, mês, dia, horas, minutos e segundos. Quando o

horário é atingido, as acções são desencadeadas.

Os programas horários são classificados consoante o seu nível de repetição:

Evento Único – Quando ocorre apenas uma vez.

Diário – Quando ocorre diariamente, sendo definido apenas as horas, minutos e segundos.

Semanal – Quando ocorre no mesmo dia (de semana) todas as semanas.

Mensal, Dia do mês – Quando ocorre no mesmo dia todos os meses.

Mensal, Dia da semana – Quando ocorre todos os meses num mesmo dia da semana. (p.ex. todas

as primeiras 5ªf de cada mês).

Anual – Quando ocorre anualmente no mesmo dia, mês, horas, minutos e segundos.

24

Exemplo:

IF time=1394493000 (Evento Único) THEN on/off_lampada=1

Se o tempo for igual ao tempo programado, a lâmpada será acesa.

Aqui o tempo está representado em segundos, pois é o formato utilizado pelo sistema DomoBus,

sendo que 1394493000 corresponderá a 2014/02/10 23:10:00.

4.1.4. Sequência

Uma sequência é um formato de programação que utiliza pausas dadas em segundos, até activar as

acções definidas. Ou seja, imaginando que queremos activar um determinado dispositivo durante 10

segundos, e de seguida desactivá-lo. Então programa-se uma sequência com período de 10

segundos, em que no final dos 10 segundos será desactivado o dispositivo. Sendo necessário antes

criar um programa que active o dispositivo e active a sequência, isto porque as sequências funcionam

juntamente com as programações, sejam simples, complexas ou horárias. Assim será um dos

programas a activar a sequência desejada.

Exemplo:

Sequencia_1: WAIT 10s THEN lâmpada=0

IF on/off_botão=1 THEN (lâmpada=1; START sequencia_1)

A lâmpada é acesa e a sequencia_1 é activada.

10 Segundos depois, a lâmpada será apagada.

Com este tipo de programações, torna-se fácil e bastante intuitivo qualquer utilizador conseguir

colocar em funcionamento todas as configurações de automação que deseje no seu sistema.

Esta fórmula, que conjuga a abstracção dos dispositivos físicos com os dispositivos virtuais, com a

ampla variedade de programações, permite assim fazer-se quase tudo com este sistema. As

possibilidades de automação dependem na sua maioria da imaginação do utilizador, ou quanto muito

da sua familiaridade com o sistema.

25

4.2. Aplicação de Supervisão

Quando esta tese teve inicio, a biblioteca que implementa os mecanismos de suporte à supervisão

era apenas uma colecção de funções em linguagem C, que implementam o essencial dos programas

descritos (simples e complexos), os programas horários e as sequências.

Foi então necessário criar toda a infra-estrutura exterior a essa biblioteca, de modo a criar um

software real que conseguisse efectivamente fazer a automação de uma habitação.

A aplicação de supervisão, foi então o software criado no âmbito desta tese, de maneira a conseguir

testar o bom funcionamento da biblioteca de funções do DomoBus.

Este software consistiu num programa em linguagem C que fornece as ferramentas necessárias para

que seja possível interagir com o DomoBus, tanto a nível de criar os programas necessários ao seu

funcionamento, como a nível da adição de novos dispositivos e propriedades.

A aplicação de supervisão permite também a passagem de comandos do DomoBus para os

dispositivos a controlar.

O software está dividido em duas aplicações, Programador e Supervisor, que interagem entre si,

como pode ser visto na figura 4.1. Cada uma estará instalada num computador diferente e entre elas

comunicarão através da rede TCP/IP.

O Supervisor é o cérebro do sistema, pois contém a biblioteca DomoBus, e é ele que toma todas as

decisões e faz todo o processamento. Na secção 5.2, explica-se em detalhe, como funciona. Em

seguida vamos focar-nos na aplicação Programador, visto ser ela que interage com o utilizador, e ser

ela e apenas ela que o utilizador de facto utiliza.

Figura 4.1 – Modelo de interacção entre a aplicação Programador e a aplicação Supervisor.

26

4.3. Aplicação Programador

Como foi dito e pode ser visto na figura 4.1, é com a aplicação programador que o utilizador interage.

É através dela que o utilizador irá adicionar novos tipos de dispositivos e propriedades às instâncias

concretas dos dispositivos de um dado sistema. Será também através desta aplicação que o

utilizador irá criar as programações que depois permitirão ao sistema funcionar e controlar os

dispositivos, fazendo aquilo que o utilizador pretende.

Nesta secção iremos explicar em detalhe como o utilizador deverá utilizar a aplicação Programador

para adicionar os dispositivos e criar as programações. Esta secção permite ilustrar as

potencialidades do Programador, e perceber como se configura um sistema.

Figura 4.2 – Menu inicial da aplicação Programador.

O utilizador ao iniciar o programa encontrará um menu, e será a partir desse menu que passará todo

o controlo do sistema. O menu pode ser visto na figura 4.2.

Futuramente seria ideal desenvolver um interface gráfico para esta aplicação, de modo a torna-la

mais fácil e agradável de usar. De momento, não foi essa a nossa prioridade, a prioridade centrou-se

mais no funcionamento e teste do programa.

De relembrar que esta aplicação serve apenas para configurar o sistema, assim ela é meramente

uma ferramenta para se conseguir parametrizar todo o sistema e assim poder efectuar todos os

testes necessários para se poder validar o sistema.

27

Podem ser feitos 8 tipos de operações com o Programador:

Criar algo NOVO – quer seja adicionar um novo dispositivo, uma nova propriedade, ou criar uma

nova programação. Sempre que seja escolhida uma das operações NOVO, será criado e

adicionado à memória do sistema, um novo elemento.

Podemos criar Novos (as):

- Propriedades

- Tipos de Dispositivos

- Dispositivos

- Programas Simples

- Programas Complexos

- Programas Horários

- Sequências

Adicionar Acções – Este tipo de operação adiciona uma acção a um determinado programa,

esta pode ser uma acção de activação ou desactivação.

Podemos adicionar acções a:

- Programas Simples



- Sequências

Adicionar Condições – Esta operação é exclusiva dos programas complexos, e tal como o

nome indica, adiciona uma nova condição a um programa complexo.

Adicionar Operadores – Esta operação é também exclusiva dos programas complexos, ela

adiciona um novo operador a um programa complexo.

Adicionar Período – Esta operação é exclusiva dos programas horários, ela cria e adiciona um

novo período horário, a um programa horário.

Adicionar item – Esta operação é exclusiva das sequências, ela irá adicionar um novo item a

uma sequência.

Listar elementos – Esta operação faz com que sejam impressos no ecrã todos os elementos

pertencentes ao grupo e instalados no sistema. Ou seja, se for pedido para listar os dispositivos,

todos os dispositivos que existirem no sistema serão impressos no ecrã.

28

Podemos Listar:

- Propriedades

- Tipos de dispositivos

- Dispositivos

- Programas Simples



- Sequências

Eliminar elemento – Esta operação apaga um elemento de um determinado grupo.

Podemos Eliminar:

- Programas Simples


Nota: à data da conclusão desta dissertação as funções do DomoBus apenas permitiam eliminar

programas simples e programas complexos. De Futuro espera-se que seja possível eliminar qualquer

um dos tipos de programa (sequências incluídas) e também acções de activação e desactivação.

Nas secções seguintes faz-se uma descrição detalhada das principais operações que podem ser

desenvolvidas no Programador.

4.3.1. Novos Dispositivos

O procedimento para a adição de novos dispositivos segue a ordem dada de seguida:

Propriedade → Tipo de Dispositivo → Dispositivo

Para configurar o sistema é primeiramente necessário definir os dispositivos do sistema. Para isso, a

primeira coisa a fazer é definir as propriedades. Como foi dito antes, existem 3 tipos diferentes de

propriedades, escalar, enumerados e arrays. Ao adicionar uma nova propriedade teremos que

escolher qual o tipo dessa propriedade, bem como o nome e o modo de acesso à propriedade (só

leitura, só escrita e leitura-escrita), seguindo sempre o modelo explicado na secção 3.5.

Depois de adicionadas as propriedades precisamos de adicionar os tipos de dispositivos. Para isso

teremos que definir o nome, e seleccionar todas as propriedades associadas a esse tipo de

dispositivo.

29

Finalizado este passo podemos então adicionar os dispositivos que compõem o sistema, sendo

necessário, o nome do dispositivo, bem como o seu ID. O ID será o número identificador do

dispositivo. Neste momento o ID é apenas um número, mas numa próxima versão o ID poderá servir

para endereçar o dispositivo dentro da rede, de modo a permitir uma comunicação real com ele.

Depois de inserir o ID, serão listados os diversos tipos de dispositivos existentes e teremos de

seleccionar o mais indicado.

Segue-se um resumo de todas as operações necessárias para adicionar dispositivos:

1- Adicionar Propriedades

1.1- Escolher o nome

1.2- Escolher modo de acesso

1.3- Escolher Tipo de valor

2- Adicionar Tipos de Dispositivos


2.2- Escolher as propriedades

3- Adicionar Dispositivo


3.2- Definir o ID do dispositivo

3.3- Escolher o Tipo de dispositivo associado

4.3.2. Programa Simples

Para podermos configurar um programa simples é necessário ter em mente, qual o dispositivo

activador, e qual o activado. Ou seja, teremos uma propriedade de um dispositivo que estará a ser

monitorizada. Quando o valor dessa propriedade atingir o valor definido, irá provocar a activação de

outra propriedade, de outro ou do mesmo dispositivo.

Assim no menu inicial depois de escolhermos criar um novo programa simples, teremos que escolher

o nome do programa e de seguida identificamos qual o dispositivo e a propriedade que irão ser

avaliados. Depois escolhemos a condição a implementar (Igual a, Diferente de, Menor que, Menor ou

Igual a, Maior que, Maior ou igual a, Agir sempre) e finalmente o valor a usar na comparação.

Depois de criado o programa, há que adicionar as acções a serem executadas. Quando a condição

que foi definida passar a verdadeira, irá desencadear as acções de activação. Quando a condição

passar a falsa, serão desencadeadas as acções de desactivação.

Assim, para adicionar uma acção é necessário escolher qual o programa onde será adicionada essa

30

acção, depois escolhemos o dispositivo e a propriedade desse dispositivo que serão activadas,

finalmente adicionamos a mensagem de activação ou desactivação conforme o tipo de acção.

Antes de prosseguir convém explicar o conceito das mensagens de acção. As mensagens de acção

servem numa primeira fase para interagir directamente com os dispositivos. Elas contêm a

informação relativa ao número do dispositivo, a sua localização na rede, a propriedade a ser alterada,

e o valor a inserir na propriedade. Neste momento essa mensagem é inserida pelo utilizador, mas

numa próxima versão do software poderá ser gerada automaticamente, visto que neste momento as

mensagens não têm qualquer utilidade prática pois não existe uma ligação verdadeira aos

dispositivos.

Outra coisa de salientar em relação às mensagens é o facto de existirem mensagens internas e

mensagens externas ao sistema.

As mensagens externas são as mensagens de que falámos em cima, são as mensagens que

informam os dispositivos da alteração de propriedades, ou seja, mandam ligar ou desligar, subir ou

descer, aquecer ou arrefecer, etc.

As mensagens internas, são mensagens internas do programa, são mensagens que são usadas por

exemplo para chamar funções dentro do programa. Podem ser usadas para alterar o valor de

propriedades de dispositivos, ou podem ser usadas para invocar sequências por exemplo, como

veremos mais à frente.

As mensagens internas obedecem a um formato específico e, de momento, necessitam ser definidas

em formato binário. Este formato permite usar constates hexadecimais, as quais necessitam ser

precedidas por “\x”.

Vejamos um exemplo:

\x0F\x36\x00\x00\x00\x41\x02\x00 será o comando que colocará o valor 2 na propriedade número 1

do dispositivo 54. Vejamos então por partes: \x0F é 15 em valor decimal, que corresponde ao

comando SPV (Set Property Value) do DomoBus. Este é o comando usado para definir o valor de

uma propriedade. \x36\x00\x00\x00 representa um inteiro de 32 bits correspondendo ao valor 54 em

decimal, identificando assim, o dispositivo 54; \x41 corresponde ao valor 65 em decimal. Este valor

corresponde à soma 64+1, ou seja o valor de 64 indica que se trata de uma propriedade do tipo

escalar e o valor 1 é o número da propriedade. Para os 3 tipos de propriedades existentes, o valor a

somar ao número da propriedade será, 0 se for uma propriedade do tipo escalar, 64 se for do tipo

enumerado e 128 se for um vector.

Finalmente o valor \x02\x00 corresponde ao valor 2 em decimal, e corresponde ao valor que se quer

colocar na propriedade.

Em suma, sempre que haja necessidade de usar este tipo de comandos, é necessário fazer a

conversão dos valores decimais para valores hexadecimais.

Pretendia-se automatizar a forma como se criavam este tipo de mensagens internas. A ideia era criar

um sistema automático que a partir do numero do dispositivo, numero da propriedade e valor a ser

inserido cria-se automaticamente a mensagem a ser enviada dentro do sistema. Mas no final acabou

por não haver tempo para uma tarefa que era algo complexa e trabalhosa. Acabamos por trabalhar

31

com os comandos a serem criados manualmente com as constantes hexadecimais. Fica aqui para

um trabalho futuro, melhorar este aspecto.

Resumo dos procedimentos para a criação de um programa simples:

1- Criar Programa simples


1.2- Escolher dispositivo activador

1.3- Escolher a propriedade a ser monitorizada

1.4- Escolher condição a implementar

1.5- Escolher valor de comparação

2- Adicionar Acção de activação

2.1- Escolher programa onde adicionar a acção

2.2- Escolher dispositivo a activar

2.3- Escolher propriedade a activar

2.4- Escrever mensagem de activação

3- Adicionar Acção de desactivação


3.2- Escolher dispositivo a desactivar

3.3- Escolher propriedade a desactivar

3.4- Escrever mensagem de desactivação

4.3.3. Programa Complexo

À semelhança dos programas simples, nos programas complexos também haverá dispositivos e

propriedades activadoras, a única diferença é que teremos vários dispositivos e propriedades

activadoras.

Cada condição define um dispositivo activador, com a devida propriedade. Cada condição pode ser

vista como um programa simples, semelhante aos vistos na secção anterior. Assim quando queremos

comparar o resultado entre duas condições, teremos que criar um operador, um operador pode

também comparar o resultado de dois operadores, ou de uma condição e um operador.

Em resumo, começamos por criar o programa complexo onde precisamos apenas de escolher o

nome. De seguida adicionamos as condições ao programa, começamos por escolher qual o

programa onde vamos adicionar, depois escolhemos o nome para a condição, depois o dispositivo e

propriedade activadores, por fim a condição (Igual a, Diferente de, Menor que, Menor ou Igual a,

Maior que, Maior ou igual a, Agir sempre) e o valor, tudo semelhante aos programas simples. De

32

salientar que as condições podem ser criadas em qualquer momento, haja operadores já criados ou

não, no entanto é necessário que as condições estejam criadas para que possam ser adicionadas

aos operadores.

Para adicionar um operador, teremos que escolher qual o programa onde será acrescentado, depois

escolhemos o 1º operador, é necessário identificar primeiro se se trata de uma condição ou de um

operador, depois faremos o mesmo para o 2º operador e finalmente escolhemos o operador logico a

ser implementado entre os dois operadores (EQUAL, NOT, AND, OR, XOR, XNOR).

No final basta adicionar as acções tal como faríamos num programa simples, os procedimentos são

os mesmos.

Resumo dos procedimentos para adição de um programa complexo:

1- Criar Programa complexo


2- Adicionar Condição

2.1- Escolher programa onde adicionar a condição


2.3- Escolher o dispositivo a programar

2.4- Escolher a propriedade a programar

2.5- Escolher a condição a implementar

2.6- Escolher valor para a condição

3- Adicionar operador

2.1- Escolher programa onde adicionar o operador

2.2- Escolher 1º operador

2.3- Escolher 2º operador

2.4- Escolher operador lógico



4.2- Escolher dispositivo a activar

4.3- Escolher propriedade a activar




5.2- Escolher dispositivo a desactivar

5.3- Escolher propriedade a desactivar


33

4.3.4. Programa Horário

Para criar um programa horário é necessário escolher o nome e o ID pelo qual será conhecido e

identificado. Depois definimos o tipo de repetição que será efectuada (Evento Único, Diário, Semanal,

Mensal - Dia do mês, Mensal - Dia da semana, Anual). Se o tipo de repetição for semanal, teremos

que escolher o dia da semana a repetir. Se for um evento único teremos que definir a data de início e

a data de final, em que teremos que definir o ano, mês e dia, bem como as horas, minutos e

segundos.

Para os outros casos, em que o evento não ocorre apenas uma vez, teremos que escolher o período

de repetição, em que o valor 1 irá repetir todos os dias, ou todos os meses, ou todos os anos, em que

o valor 2 irá repetir de 2 em 2 dias, ou de 2 em dois meses, e em que o valor 3 irá repetir de 3 em 3

dias ou 3 em 3 meses, e por ai adiante.

Finalmente definimos a data de início e de final do período, em ano, mês e dias. Ou seja de que data

até que data é que o programa horário estará activo.

Nos programas que exigem repetição (todos excepto os eventos únicos), teremos que adicionar

períodos ao programa. Serão estes períodos que irão fazer activar as acções ou desactivar as

acções. Assim, definindo um período entre as 13:00:00 e as 14:00:00, quando forem 13:00:00 as

acções de activação serão desencadeadas e, quando forem 14:00:00, serão desencadeadas as

acções de desactivação.

Para adicionar um novo período, teremos que escolher o programa onde adicionar o período, de

seguida escolhemos a data de início (horas, minutos e segundos) e depois a data de fim, (horas,

minutos e segundos).

Finalmente adicionamos as acções. Teremos que escolher o programa onde adicionar a acção e

depois definir a mensagem de activação ou desactivação consoante for o caso.

1- Criar Programa horário


1.2- Definir o ID do programa

1.3- Escolher o tipo de repetição

(*) 1.4- Escolher os dias de semana a programar

(**) 1.5- Escolher data de início (ano/mês/dia – h/m/s) e data de final (ano/mês/dia – h/m/s)

1.6- Escolher período de repetição

1.7- Escolher data de início do período (ano/mês/dia) e data de final do período (ano/mês/dia)

(*)- Só será necessário escolher os dias de semana, se o tipo de repetição for do tipo semanal

(**)- No caso do tipo de ser um evento único

34

2- Adicionar período ao programa horário (condicional)

2.1- Escolher programa onde adicionar o período

2.2- Escolher data de início (horas/minutos/segundos)

2.3- Escolher data de final (horas/minutos/segundos)







4.3.5. Sequência

As sequências são invocadas por outros programas sempre que se quer impor algum tipo de

restrição temporal, ou seja, quando queremos impor uma pausa, dada em segundos, a algum tipo de

dispositivo. Por exemplo se quisermos que uma lâmpada ligue ou desligue algum tempo depois de se

pressionar um botão, se tivermos um detector de movimento e quisermos evitar que a luz se acenda

e apague demasiadas vezes, por exemplo sempre que nos ausentemos da divisão. Assim programa-

se um tempo mínimo em que a luz tem que estar ligada mesmo que não haja movimento a ser

detectado na divisão.

Cada sequência poderá ter vários itens, cada item tem um tempo de pausa diferente e desencadeia

acções diferentes. Assim quando uma sequência for chamada, começa a contabilizar o tempo e a

activar as acções conforme os tempos dos respectivos itens forem atingidos. Por exemplo, considere-

se uma sequência com 3 itens, um com 10 segundos, outro com 5 segundos e outro com 35

segundos, assim 10 segundos depois da sequência ter sido activada ela irá desencadear as acções

do primeiro item, 5 segundos depois são activadas as acções do segundo item e, finalmente, 35

segundos depois são activadas as acções do terceiro e último item.

Nesta versão do software ainda não está perfeitamente implementada a forma de chamar as

sequências. Assim, para invocar uma sequência é necessário introduzir manualmente, em

hexadecimal, as mensagens de activação ou desactivação da sequência.

Por exemplo, para invocar a sequência numero 3, deve ser usada o código binário:

\x15\x03\x00\x00\x00 consoante foi explicado na secção 4.3.2, em que \x15 corresponde ao valor

decimal 21 correspondente ao comando Start Sequence e \x03\x00\x00\x00 que corresponde ao valor

3 decimal e que indica o ID da sequência a ser desencadeada.

35

Então para adicionar uma nova sequência ao sistema, começamos por criar a sequência, onde

teremos que escolher um ID pelo qual passará a ser conhecida. Seguidamente adicionamos os itens:

escolhemos a sequência onde iremos adicionar o item e definimos o tempo a esperar em segundos.

Finalmente adicionamos as acções, escolhendo qual a sequência e qual o item onde adicionar. Para

finalizar, escrevemos a acção a executar.

Segue-se um resumo dos procedimentos:

1- Criar Sequencia

1.1- Escolher ID da sequência

2- Adicionar Item á sequencia

2.1- Escolher sequencia onde adicionar

2.2- Definir tempo a esperar (segundos)

3- Adicionar Acção ao item

3.1- Escolher sequencia onde adicionar

3.2- Escolher item onde adicionar

3.3- Escrever acção a executar

37

5. Implementação

O software que foi criado no âmbito desta tese de mestrado consiste fundamentalmente em duas

aplicações distintas, a aplicação de supervisão, chamada Supervisor e a aplicação de programação

chamada Programador.

O Programador, como o nome indica servirá para configurar todas as funções desejadas para a

automação, quer seja a criação dos programas que irão comandar as variadas funções, quer seja a

adição de novos dispositivos e propriedades ao sistema.

O Supervisor será uma espécie de cérebro do software, sendo dele que partem todas as ordens

relativas à gestão dos diferentes dispositivos presentes no sistema. É ele que recebe a informação de

estado dos dispositivos e desencadeia o envio de comandos para realizar acções. É também ele que

faz a gestão do tempo, activando ou desactivando os diferentes dispositivos conforme as ordens

presentes nas programações horárias, como veremos mais à frente.

Nesta primeira versão do mecanismo de supervisão, a comunicação com os dispositivos não está

totalmente implementada, a transferência de ordens entre o Supervisor e os dispositivos não existe,

sendo que apenas são geradas ordens num formato genérico a fim de testar o bom funcionamento do

Supervisor. Não seria possível concluir o envio de ordens, pois os módulos físicos que estarão

ligados aos dispositivos, lâmpadas, tomadas, interruptores, etc ainda estão em desenvolvimento.

No entanto, poucas alterações serão necessárias ao código para que a comunicação possa ser

totalmente instaurada, e esses módulos físicos possam ser controlados pelo Supervisor.

5.1. Aplicação Programador

A aplicação Programador liga-se com o Supervisor através do protocolo TCP/IP, bastando conhecer o

endereço IP do Supervisor. Isto permite que o utilizador se possa ligar ao sistema e configurá-lo a

partir de qualquer computador onde a aplicação Programador esteja instalada.

Numa próxima versão do software uma das mudanças possíveis seria a criação de uma página web,

onde a aplicação Programador estivesse em funcionamento, o que permitiria que o utilizador pudesse

aceder ao seu sistema e programá-lo, sem necessidade de ter o software instalado no seu

computador. Ou ainda, com a generalização da utilização de smartphones, poderia ser criada uma

aplicação para os mesmos, que permitisse a gestão da habitação, o que permitiria por exemplo, ligar

ou desligar aparelhos à distância através do telemóvel.

A comunicação com o Supervisor é feita recorrendo a um socket TCP/IP, o Programador envia um

pacote de dados pré-determinado para o Supervisor e fica a aguardar uma resposta do mesmo

confirmando a boa recepção dos dados. Este pacote de dados, que corresponde a uma estrutura de

dados e que pode ser vista na figura seguinte, possui 10 variáveis do tipo inteiro, uma string e um

38

vector de inteiros.

Figura 5.1 – Estrutura de dados, usada na comunicação entre Programador e Supervisor.

A variável tipo guarda um número inteiro positivo que define qual o comando a ser executado. Tanto o

programador como o supervisor seguem uma lista pré-definida de comandos, que estão

representados na tabela 5.1. O Programador insere na variável tipo o comando a ser executado pelo

supervisor, e envia-o nessa estrutura juntamente com os outros dados.

Os outros dados, que podem ser mensagens ou nomes seguirão na string mensagem, que tem um

tamanho limite de 50 caracteres e que será necessária quando se inserem novos dispositivos ou

programas, ou quando se adicionam novas acções a esses programas.

Temos também 8 variáveis de nome valor_# (em que # estará numerado de 1 a 8), que guardarão

valores inteiros variados, necessários à adição de dispositivos ou à criação de programas, sendo

utilizados para diversas funções. Além destas oito variáveis, existe ainda um vector de inteiros com

100 posições, que será usado sempre que seja necessário enviar um vector, ou uma quantidade

maior de dados.

Finalmente resta a variável size_vector, que como o nome indica serve para enviar o tamanho do

vector de inteiros, de modo a simplificar o processamento dos dados, que é facilitado por se saber em

antemão o tamanho do vector.

typedef struct{

int tipo;

char mensagem[DIM];

int valor_1;

int valor_2;

int valor_3;

int valor_4;

int valor_5;

int valor_6;

int valor_7;

int valor_8;

int size_vector;

int vector[MAX];

}envio_socket;

39

Tabela 5.1 – Comandos enviados entre as aplicações Programador e Supervisor.

# COMANDOS # COMANDOS

0 - Encerrar 40 - Imprimir acção de desactivação -

programa complexo

1 - Reservado 41 - Imprimir condição - programa complexo

2 - Confirmar recepção de dados 42 - Imprimir operadores - programa

complexo

3 - Reservado 43 - Imprimir operador - programa complexo

4 - Nova propriedade 44 - Reservado

5 - Novo tipo de dispositivo 45 - Reservado

6 - Novo dispositivo 46 - Reservado

7 - Pedido de lista de dispositivos 47 - Apagar programa complexo

8 - Imprimir lista 48 - Reservado

9 - Termina recepção de dados 49 - Reservado

10 - Sem dados 50 - Validar número - programa complexo

11 - Pedido de lista de propriedades 51 - Validar número de condição complexa

12 - Pedido de lista de tipos de

dispositivos 52 - Validar número do operador complexo

13 - Procura tipo de dispositivo de um

dispositivo 53 - Novo programa horário

14 - Numero errado 54 - Pedido de lista de programas horários

15 - Novo programa simples 55 - Novo período de programa horário

16 - Procura propriedades de um tipo de

dispositivo 56 -

Nova acção de activação de programa

horário

17 - Validar número da propriedade 57 - Nova acção de desactivação de

programa horário

18 - Pedido lista de programas simples 58 - Verificar disponibilidade de ID de

programa horário

19 - Nova acção de activação 59 - Validar Id de programa horário

20 - Nova acção de desactivação 60 - Nova sequência

21 - Eliminar acção de activação 61 - Novo item – sequência

22 - Eliminar acção de desactivação 62 - Nova acção de um item – sequência

23 - Eliminar programa simples 63 - Pedido/impressão de uma sequência

24 - Validar Id de dispositivo 64 - Pedido/impressão de item de uma sequência

40

25 - Pedido de lista de programas

simples 65 -

Pedido/impressão de acção de uma

sequência

26 - Imprimir acção de activação -

programa simples 66 -

Verificar disponibilidade de Id de uma

sequência

27 - Imprimir acção de desactivação -

programa simples 67 - Validar ID de uma sequência

28 - Validar número de programa simples 68 - Validar número de um item – sequência

29 - Validar número de acção de

activação - programa simples 69 - Reservado

30 - Validar número de acção de

desactivação - programa simples 70 - Reservado

31 - Novo programa complexo 71 - Reservado

32 - Imprimir lista de programas

complexos 72 - Reservado

33 - Nova condição - programa complexo 73 - Reservado

34 - Novo operador - programa complexo 74 - Reservado

35 - Nova acção de activação - programa

complexo 75 - Reservado

36 - Nova acção de desactivação -

programa complexo

37 - Imprimir programas complexos

38 - Imprimir condição - programa

complexo

39 - Imprimir acção de activação -

programa complexo

Na tabela 5.1 alguns dos comandos apresentam-se como “Reservado”, são comandos aos quais

ainda não foi atribuída uma função. São comandos “livres”, onde de futuro podem ser atribuídas

funções.

5.2. Aplicação Supervisor

É no Supervisor que estão presentes as funções da biblioteca de supervisão, que actua como cérebro

do sistema.

O Supervisor sendo o cérebro de toda a operação, é por ele que passam todos os comandos, é ele

que faz todo o processamento e toma todas as decisões, finalmente será ele que comunicará com

todos os dispositivos.

Existem três acções a serem executadas em concorrência no servidor, sendo usadas threads. Na

figura 5.2 encontra-se representada a estrutura do servidor.

41

Figura 5.2 – Estrutura da aplicação Supervisor.

A primeira thread trata do tempo. Esta thread está constantemente a informar a biblioteca do tempo

actual, em segundos. A thread corre uma vez em cada segundo.

Outra das threads faz a gestão do teclado, identifica os comandos inseridos e os comandos que

terminam o programa. Quando o programa ficar totalmente funcional, com uma total interacção com

os dispositivos reais, esta thread deixa de ser necessária, bastando apenas detectar o comando para

terminar o programa. Isto porque toda a interacção do utilizador com o sistema está planeada para

ser feita através da aplicação Programador, que comunica com o Supervisor. Isto porque o Supervisor

está planeado para estar inserido num pequeno computador, possivelmente um Raspberry Pi, sem

necessidade de monitor, teclado ou rato, nem qualquer outro dispositivo de interacção externa.

De momento ainda é necessária esta thread e a possibilidade de leitura dos comandos do teclado

que interagem com o DomoBus pois é preciso testar o programa exaustivamente, sendo por isso

indispensável total acesso aos comandos lidos do teclado.

Finalmente, a última das threads e também a mais importante, é a thread que faz a gestão dos

utilizadores e dispositivos. Esta thread está continuamente á escuta para aceitar a ligação da

aplicação Programador, ou futuramente de qualquer outro dispositivo, estando preparada para lidar

com um número virtualmente infinito de dispositivos, ou de ligações do Programador, apesar de

tipicamente existir um só Programador.

Apesar de o número de ligações poder ser muito grande, estando apenas limitado pela memória e

capacidade de processamento do módulo físico onde o Supervisor está instalado, nesta primeira

versão do software, esse número foi limitado a 100 ligações, sendo mais do que suficiente para todos

os testes que foram efectuados.

42

Aceitando a ligação do Programador, cabe a esta thread ficar continuamente à escuta de novas

mensagens. A cada nova mensagem que chega, o Supervisor procura primeiro ler a variável tipo, e

comparar o seu conteúdo com a lista de comandos presentes na tabela 5.1. Consoante o tipo de

comando enviado pelo Programador, o Supervisor irá agir em conformidade.

Se o comando for do tipo adição, seja adição de novas propriedades, dispositivos ou programações,

o programa irá ler os dados das restantes variáveis, fará o processamento dos dados e depois

chamará a função adequada da biblioteca para executar o comando. Ao chamar a função da

biblioteca o programa envia os respectivos dados que foram recebidos do Programador.

Outra das acções que o programa faz quando recebe um destes comandos, é adicionar os dados já

processados aos ficheiros de texto, como veremos mais à frente na secção 5.3.

Nos outros tipos de comandos, que são maioritariamente de pedido de informações ou validação de

dados, o Supervisor depois de analisar qual o comando a ser executado e ler os restantes dados, irá

processar a informação e enviar de volta a resposta para o Programador. Por exemplo, se for pedido

para validar uma propriedade, o Supervisor procura na sua base de dados se essa propriedade existe

ou não e envia a resposta para o Programador, informando se a propriedade está correcta e portanto

existe ou não.

5.2.1. Ficheiros de texto

A aplicação de Supervisão usa dois ficheiros de texto. Estes ficheiros de texto servem como backup

para todas as operações que envolvem interacção do utilizador através da aplicação Programador,

sejam operações que envolvem a criação de novos dispositivos ou propriedades, ou a adição de

novos programas ao sistema.

A necessidade de haver um backup deste tipo prende-se com o facto de que se houver a

necessidade de reiniciar o sistema, ou mesmo se este for encerrado abruptamente por falta de

energia, quando se iniciar novamente o sistema dispõe de todas as programações efectuadas

anteriormente as quais serão inseridas automaticamente, poupando muito tempo e esforço.

Outra razão para a existência deste sistema de backup, e relembrando que este software serviu

essencialmente para testar exaustivamente a biblioteca DomoBus e a sua viabilidade futura, foi a

capacidade de pré-programar o sistema, quer com todos os seus dispositivos e propriedades, quer

com os vários e diferentes tipos de programações, tornando assim mais fácil e rápido o teste ao

software.

Os dois ficheiros de texto mencionados têm o nome listas.txt e programas.txt.

43

5.2.1.1. Listas.txt

O ficheiro listas.txt guarda toda a informação respeitante aos tipos de dispositivos, dispositivos e

propriedades.

Todas as linhas deste ficheiro começam com um número que define qual o tipo de informação dessa

linha, indica se se trata de um tipo de dispositivo, um dispositivo ou uma propriedade. Todas as

linhas, terminam com -100, que é usado como terminador de linha, não tendo qualquer informação

associada.

Nas secções seguintes explicita-se o significado de cada elemento presente neste ficheiro.

Propriedades

4 <n_propriedade> <nome_propriedade> <modo_acesso> <tipo_valor> -100

<n_propriedade> - Número ou posição da propriedade.

<nome_propriedade> - Nome da propriedade.

<modo_acesso> - Modo de acesso á propriedade:

1- Só-leitura

2- Só-escrita

3- Leitura-Escrita

<tipo_valor> - Tipo de valor da propriedade:

1- Enumerado

2- Escalar

3- Vector

Exemplo:

4 1 on_off 3 1 -100

4 - Indica que se trata de uma propriedade.

1 - Propriedade número 1.

on_off - Nome da propriedade.

3 - Modo de acesso à propriedade: Leitura-Escrita.

1 - Propriedade do tipo Enumerado.

44

Tipos de dispositivos

2 <n_tipo_dispositivo> <nome_tipo_dispositivo> [propriedades] -100

<n_tipo_dispositivo> - Número ou posição do tipo de dispositivo.

<nome_tipo_dispositivo> - Nome do tipo de dispositivo.

[propriedades] - Lista das propriedades associadas ao tipo de dispositivo.

Exemplo:

2 2 lâmpada_regulável 3 -100

2 - Indica que se trata de um Tipo de Dispositivo.

2 - Tipo de dispositivo número 2.

lâmpada_regulável - Nome do tipo de dispositivo.

3 - Propriedade associada a este Tipo de Dispositivo.

Dispositivos

3 <Id_dispositivo> <Nome_dispositivo> <tipo_dispositivo> -1 [propriedades] -100

<Id_dispositivo> - Número ou Id que identifica o dispositivo.

<Nome_dispositivo> - Nome do dispositivo.

<tipo_dispositivo> - Tipo de dispositivo associado ao dispositivo.

[propriedades] - Lista das propriedades associadas ao dispositivo.

Nota: O número -1 age aqui como limitador para a lista de propriedades, que fica limitada entre o

número -1 e o -100, facilitando assim a sua leitura.

Exemplo:

3 11 Interruptor_sala 11 -1 1 -100

3 - Indica que se trata de um Dispositivo.

11 - Dispositivo com ID 11.

Interruptor_sala - Nome do dispositivo.

11 - Dispositivo associado ao tipo de dispositivo número 11.

1 - Propriedade associada a este dispositivo.

45

5.2.1.2. Programas.txt

O ficheiro programas.txt guarda a informação relativa às programações que são configuradas pelo

utilizador. Todos os programas feitos pelo utilizador e por sua vez enviados através da aplicação

Programador são aqui guardados. Estamos a falar em programações simples, programas complexos,

com as várias condições associadas, programas horários e os diversos períodos, bem como as várias

acções associadas aos programas. Guarda ainda as sequências e respectivos itens.

Programa simples

1 <n_programa> <nome_programa> <dispositivo> <propriedade> <condição> <valor>

[acções_activação] -1 [acções_desactivação] -100

<n_programa> - Posição/numero do programa.

<nome_programa> - Nome do programa.

<dispositivo> - Dispositivo associado ao programa.

<propriedade> - Propriedade associada ao programa.

<condição> - Condição associada ao programa:

0- Igual a ...

1- Diferente de ...

2- Menor que ...

3- Menor ou Igual a ...

4- Maior que ...

5- Maior ou Igual a ...

6- Agir Sempre ...

<valor> - Valor que activa a condição.

[acções_activação] - Acções de activação associadas ao programa.

[acções_desactivação] - Acções de desactivação associadas ao programa.

Exemplo:

1 1 luz_sala_1 11 1 0 1 1 2 3 4 -1 1 2 3 4 -100

1 - Indica que se trata de programa simples.

1 - Programa simples número 1

luz_sala_1 - Nome do programa.

11 - Dispositivo com ID 11 associado a este programa.

1 - Propriedade número 1 associada ao programa.

0 - Condição “igual a...” associada a este programa.

1 - Valor que activa a condição.

46

1 2 3 4 - Número das acções de activação associadas a este programa.

1 2 3 4 - Número das acções de desactivação associadas a este programa.

Acção activação de programa simples

2 <n_acção_act> <mensagem_activação> <n_programa> <dispositivo> <propriedade>

-100

<n_acção_act> - Numero/posição da acção de activação.

<mensagem_activação> - Mensagem de activação a ser gerada.

<n_programa> - Numero do programa que activará a acção.

<dispositivo> - Dispositivo que será activado.

<propriedade> - Propriedade que será activada.

Exemplo:

2 1 @on_21_1_lâmpada_sala_1 1 21 1 -100

2 - Indica que se trata de uma acção de activação de programa simples.

1 - Acção de activação número 1

@on_21_1_lâmpada_sala_1 - Acção a ser desencadeada.

1 - Número do programa simples associado a esta acção.

21 - Dispositivo a ser activado.

1 - Propriedade a ser activada.

Acção Desactivação de programa simples

2 <n_acção_desact> <mensagem_desactivação> <n_programa> <dispositivo> <propriedade>

-100

<n_acção_desact> - Número/posição da acção de desactivação.

<mensagem_desactivação> - Mensagem de desactivação a ser gerada.

<n_programa> - Número do programa que activará a acção.

<dispositivo> - Dispositivo que será desactivado.

<propriedade> - Propriedade que será desactivada.

47

Exemplo:

3 1 @off_21_1_lâmpada_sala_1 1 21 1 -100

3 - Indica que se trata de uma acção de desactivação de programa simples.

1 - Acção de desactivação número 1

@off_21_1_lâmpada_sala_1 - Acção a ser desencadeada.

1 - Número do programa simples associado a esta acção.

21 - Dispositivo a ser desactivado.

1 - Propriedade a ser desactivada.

Nota: O símbolo '@' no inicio de uma mensagem de acção, quer seja de activação ou de

desactivação, significa que a mensagem se trata de uma mensagem externa ao programa.

Programa complexo

4 <n_prog_compl> <nome_prog_compl> [cond_complex] -1 [operadores_complex] -2

[acções_activ_compl] -3 [acções_desactiv_compl] -100

<n_prog_compl> - Número/posição do programa complexo.

<nome_prog_compl> - Nome do programa complexo.

[cond_complex] - Condições complexas associadas ao programa.

[operadores_complex] - Operadores complexos associados ao programa complexo.

[acções_activ_compl] - Acções de activação do programa complexo

[acções_desactiv_compl] - Acções de desactivação do programa complexo

Exemplo:

4 1 Iluminação_corredor 3 2 1 -1 2 1 -2 1 -3 1 -100

4 - Indica que se trata de um programa complexo.

1 - Número do programa complexo.

Iluminação_corredor - Nome do programa complexo.

3 2 1 - Número das condições complexas associadas ao programa complexo.

48

2 1 - Número dos operadores complexos associados ao programa complexo.

1 - Número das acções de activação associadas a este programa.

1 - Número das acções de desactivação associadas a este programa.

Nota: Os números -1, -2 e -3 servem aqui como separadores entre os vários grupos de dados,

tornam assim fácil a separação e identificação dos dados.

Condição de programa complexo

5 <n_condição> <nome_condição> <n_prog_complex> <dispositivo> <propriedade>

<condição> <valor> -100

<n_condição> - Número/posição da condição complexa.

<nome_condição> - Nome da condição complexa.

<n_prog_complex> - Programa complexo a que pertence a condição.

<dispositivo> - Dispositivo associado á condição complexa.

<propriedade> - Propriedade associada á condição complexa.

<condição> - Condição a ser testada:

0 - Igual a ...

1 - Diferente de ...

2 - Menor que ...

3 - Menor ou Igual a ...

4 - Maior que ...

5 - Maior ou Igual a ...

6 - Agir Sempre ...

<valor> - Valor que activa a condição.

Exemplo:

5 5 sensor>60 3 6 1 4 60 -100

5 - Indica que se trata de uma condição de programa complexo.

5 - Número da condição.

sensor>60 - Nome da condição.

3 - Número do programa complexo associado a esta condição.

6 - Dispositivo associado a esta condição.

49

1 - Propriedade associada a esta condição.

4 - Condição a ser usada : “maior que...”.

60 - Valor que activa a condição.

Operador de programa complexo

6 <n_operador> operador <prog_complex> <oper_1> <oper_2> <tipo_oper_1> <tipo_oper_2>

<oper_logic> -100

<n_operador> - Número/posição do operador.

<prog_complex> - Programa complexo associado ao operador.

<oper_1> - Operador 1.

<oper_2> - Operador 2.

<tipo_oper_1> - Tipo do operador 1:

0 - Condição.

1 - Operador.

<tipo_oper_2> - Tipo do operador 2:

0 - Condição.

1 - Operador.

<oper_logic> - Operador logico:

0 - EQ

1 - NOT

2 - AND

3 - OR

4 - XOR

5 - XNOR

Exemplo:

6 4 operador 3 5 13 0 0 2 -100

6 - Indica que se trata de um operador de programa complexo.

4 - Número do operador.

3 - Número do programa complexo associado a este operador.

5 - Operador 1.

13 - Operador 2.

0 - Indica que o operador 1 é uma condição.

0 - Indica que o operador 2 é uma condição.

2 - Operador lógico usado: “AND”.

50

Nota: A palavra “operador” neste caso não tem qualquer significado a ela associado, serve apenas

para manter o formalismo ao longo da lista, onde existe sempre dois números, seguidos de uma

palavra.

Acção activação de programa complexo

7 <n_acção_act_complex> <mensagem_activação> <n_prog_complex> <dispositivo>

<propriedade> -100

<n_acção_act_complex> - Número/posição da acção de activação do programa complexo.

<mensagem_activação> - Mensagem de activação a ser gerada.

<n_prog_complex> - Número do programa complexo que activará a acção.

<dispositivo> - Dispositivo que será activado.

<propriedade> - Propriedade que será activada.

Exemplo:

7 1 @on_220_1_candeeiro_corredor 1 220 1 -100

7 - Indica que se trata de uma acção de activação de programa complexo.

1 - Acção de activação complexa número 1.

@on_220_1_candeeiro_corredor - Acção a ser desencadeada.

1 - Número do programa complexo associado a esta acção.

220 - Dispositivo a ser activado.

1 - Propriedade a ser activada.

Acção desactivação de programa complexo

8 <n_acção_desact_complex> <mensagem_desactivação> <n_prog_complex> <dispositivo>

<propriedade> -100

<n_acção_desact_complex> - Número/posição da acção de desactivação do programa complexo.

<mensagem_desactivaçao> - Mensagem de desactivação a ser gerada.

<n_prog_complex> - Número do programa complexo que activará a acção.

51

<dispositivo> Dispositivo que será desactivado.

<propriedade> Propriedade que será desactivada.

Exemplo:

8 1 @off_220_1_candeeiro_corredor 1 220 1 -100

8 - Indica que se trata de uma acção de desactivação de programa complexo.

1 - Acção de desactivação complexa número 1.

@off_220_1_candeeiro_corredor - Acção a ser desencadeada.

1 - Número do programa complexo associado a esta acção.

220 - Dispositivo a ser desactivado.

1 - Propriedade a ser desactivada.

Programa horário

9 <Id_prog_horario> <nome_prog_horario> <tipo_repetição> <dia_semana>

<periodo_repetição> <ano_inicio> <mes_inicio> <dia_inicio> <horas_inicio> <minutos_inicio>

<segundos_inicio> <ano_fim> <mes_fim> <dia_fim> <horas_fim> <minutos_fim>

<segundos_fim> -1 [periodos_horar] -2 [acções_activ_horar] -3 [acções_desactiv_horar] -100

<Id_prog_horario> - ID do programa horário.

<nome_prog_horario> - Nome do programa horário.

<tipo_repetição> - Tipo de repetição da programação:

0-Evento Único

1-Diaria

2-Semanal

3-Mensal, Dia do mês

4-Mensal, Dia da semana

5-Anual

<dia_semana> - Dia da semana, em caso de programação semanal:

0-Sem programação semanal

1-Domingo

2-Segunda-feira

4-Terça-feira

52

8-Quarta-feira

16-Quinta-feira

32-Sexta-feira

64-Sábado

<periodo_repetição> - Período de repetição.

<ano_inicio> - Ano do inicio do programa horário.

<mes_inicio> - Mês do inicio do programa horário.

<dia_inicio> - Dia do inicio do programa horário.

<horas_inicio> - Horas do inicio do programa horário.

<minutos_inicio> - Minutos do inicio do programa horário.

<segundos_inicio> - Segundos do inicio do programa horário.

<ano_fim> - Ano do final do programa horário.

<mes_fim> - Mês do final do programa horário.

<dia_fim> - Dia do final do programa horário.

<horas_fim> - Horas do final do programa horário.

<minutos_fim> - Minutos do final do programa horário.

<segundos_fim> - Segundos do final do programa horário.

[periodos_horar] - Períodos associados ao programa horário.

[acções_activ_horar] - Acções de activação associadas ao programa horário.

[acções_desactiv_horar] - Acções de desactivação associadas ao programa horário.

Exemplo:

9 1 luz_rua 0 0 0 2013 12 20 1 30 0 2013 12 20 1 35 0 -1 -2 2 1 -3 -100

9 - Indica que se trata de um programa horário.

1 - ID do programa horário.

luz_rua - Nome do programa horário.

0 - Tipo de repetição do programa: “Evento Único”.

0 - Dia da semana: 0 – Sem programação semanal.

0 - Período de repetição: 0 – Sem repetição.

2013 12 20 1 30 0 - Data de início: 2013/12/20 – 1:30:00.

2013 12 20 1 35 0 - Data de final: 2013/12/20 – 1:35:00.

2 1 - Acções de activação associadas ao programa horário.

Nota: Os números -1, -2 e -3 servem aqui como separadores entre os vários grupos de dados,

tornam assim fácil a separação e identificação dos dados.

53

Período de programa horário

10 <n_periodo_prog_horário> PERIODO <prog_horário> <horas_início> <minutos_início>

<segundos_início> <horas_fim> <minutos_fim> <segundos_fim> -100

<n_periodo_prog_horário> - Número/posição do período do programa horário

<prog_horário> - Programa horário correspondente.

<horas_início> - Horas de inicio do período.

<minutos_início> - Minutos de inicio do período.

<segundos_início> - Segundos de inicio do período.

<horas_fim> - Horas do final do período.

<minutos_fim> - Minutos do final do período.

<segundos_fim> - Segundos do final do período.

Exemplo:

10 1 PERIODO 1 23 1 0 23 59 59 -100

10 - Indica que se trata de um período de programa horário.

1 - Número do período.

1 - ID do programa horário a que pertence o período.

23 1 0 - Horas de início: 23:01:00.

23 59 59 - Horas de final: 23:59:59.

Nota: a palavra “PERIODO” neste caso não tem novamente qualquer significado a ela associado,

serve apenas para manter o formalismo ao longo da lista.

Acção activação de programa horário

11 <n_acção_activ_prog_horário> <mensagem_act_prog_horário> <prog_horário> -100

<n_acção_activ_prog_horário> - Número/posição da acção de activação.

<mensagem_act_prog_horário> - Mensagem de activação.


Exemplo:

11 1 @on_230_1_luz_rua 1 -100

54

11 - Indica que se trata de uma acção de activação de programa horário.

1 - Número da acção de activação.

@on_230_1_luz_rua - Acção de activação a ser desencadeada.

1 - ID do programa horário a que pertence a acção.

Acção desactivação de programa horario

12 <n_acção_desactiv_prog_horário> <mensagem_desact_prog_horário> <prog_horário> -100

<n_acção_desactiv_prog_horário> - Número/posição da acção de desactivação.

<mensagem_desact_prog_horário> - Mensagem de desactivação.


Exemplo:

12 1 @off_230_1_luz_rua 1 -100

12 - Indica que se trata de uma acção de desactivação de programa horário.

1 - Número da acção de desactivação.

@off_230_1_luz_rua - Acção de desactivação a ser desencadeada.

1 - ID do programa horário a que pertence a acção.

Sequência

13 <Id_sequência> SEQUENCIA [item_sequência] -100

<Id_sequência> - ID da sequência.

[item_sequência] - Itens pertencentes a sequência.

Exemplo:

13 2 SEQUENCIA 2 3 4 -100

55

13 - Indica que se trata de uma sequência.

1 - ID da sequência.

2 3 4 - Itens pertencentes à sequência.

Nota: a palavra “SEQUENCIA” neste caso não tem novamente qualquer significado a ela associado,

serve apenas para manter o formalismo ao longo da lista.

Item de sequência

14 <n_item_seq> ITEM <sequência> <tempo> [acções_item_seq] -100

<n_item_seq> - Número/posição do item.

<sequência> - Sequência correspondente.

<tempo> - Tempo do item.

[acções_item_seq] - Lista de acções de activação/desactivação do item.

Exemplo:

14 1 ITEM 1 10 1 -100

14 - Indica que se trata de um item de uma sequência.

1 - Número do item.

1 - ID da sequência correspondente.

10 - Tempo de espera em segundos.

1 - Acções pertencentes a este item.

Nota: a palavra “ITEM” neste caso não tem novamente qualquer significado a ela associado, serve

apenas para manter o formalismo ao longo da lista.

Acção de item de sequencia

15 <n_acção_item_seq> <mens_acção_item_seq> <sequência> <item> -100

56

<n_acção_item_seq> - Número/posição da acção do item da sequencia.

<mens_acção_item_seq> - Mensagem de acção de activação/desactivação do item da sequência.

<sequência> - Sequência correspondente.

<item> - Item correspondente.

Exemplo:

15 1 @off_luz_corredor 1 1 -100

15 - Indica que se trata de uma acção de um item.

1 - Número da acção.

@off_luz_corredor - Acção a ser desencadeada.

1 - ID da sequência correspondente.

1 - Número do item correspondente.

57

6. Exemplos de Aplicação

Neste capítulo iremos demonstrar o uso do nosso sistema em situações concretas.

Utilizaremos o exemplo dado na secção 3.1 o qual, por comodidade, se volta a representar na figura

6.1. Com essa divisão e usando os dispositivos presentes nela, iremos criar três cenários distintos,

que permitirão exemplificar três tipos de programação. O primeiro exemplo será bastante simples, o

segundo terá uma complexidade moderada e, finalmente, um terceiro exemplo que será um pouco

mais complexo.

Figura 6.1 – Exemplo da disposição de aparelhos e dispositivos numa sala.

58

Tabela 6.1 – Representação dos dispositivos da figura 6.1.

# DISPOSITIVO

1 - Interruptor 1

2 - Interruptor 2

3 - Interruptor 3

4 - Lâmpada 1

5 - Lâmpada 2

6 - Detector de Movimento



8 - Estore 1

10 - Estore 2

11 - Termostato

12 - Ar Condicionado

13 - Televisor

6.1. Cenário Simples

O exemplo mais simples e que poderá ser mais facilmente entendido é também a situação mais

comum em qualquer habitação. Estamos a falar de um interruptor ligado a uma lâmpada.

Um interruptor é um dispositivo que ou está aberto (desligado) ou fechado (ligado). Assim, é fácil

compreender que quando o interruptor está desligado, e portanto interrompe o circuito, ele estará

com o valor 0 e, quando está ligado, completando o circuito ele estará com o valor 1.

O mesmo se adequa à lâmpada; quando está ligada, terá o valor 1, e quando está desligada o valor

0. Pensamos que a descrição acima é simples e intuitiva.

Imaginemos então que queremos utilizar o interruptor número 1 da figura 6.1, para fazer ligar a

lâmpada 1, correspondente ao número 4 da tabela de dispositivos.

Então para configurar e colocar em funcionamento este interruptor e esta lâmpada e relembrando que

os procedimentos em questão já foram explicitados na secção 4.3, teremos que começar por criar a

propriedade em questão. Será a propriedade on/off, do tipo enumerado e terá como modo de acesso

59

leitura-escrita. Esta propriedade por coincidência será usada para os dois tipos de dispositivos (deve-

se apenas a uma coincidência visto que noutras configurações poderá não acontecer o mesmo).

Criada a propriedade, teremos que criar os dois tipos de dispositivos, o tipo interruptor e o tipo

lâmpada. Para o tipo interruptor é seleccionada a propriedade on/off criada anteriormente, o mesmo é

feito para o tipo lâmpada, ambos têm a mesma propriedade, obviamente que depois terão valores

diferentes.

Finalmente criamos os dois dispositivos, que chamaremos interruptor_1 e lâmpada_1. Para isso, ao

criar o dispositivo interruptor_1, escolhemos como ID, o número 1 e o tipo de dispositivo será

obviamente um interruptor.

Um breve resumo, antes de seguirmos para a criação do programa, que será o que fará funcionar o

sistema:


Nome On/Off

Modo acesso Leitura e Escrita

Tipo de valor Enumerado


Nome Interruptor Lâmpada

Propriedades On/Off On/Off


Nome Interruptor_1 Lâmpada_1

ID 1 2

Tipo de dispositivo Interruptor Lâmpada

A partir deste momento, sempre que se queira adicionar novos interruptores ou lâmpadas, o

procedimento fica muito mais simples, visto que neste momento os tipos de dispositivo, interruptor e

lâmpada já estão criados. Assim basta adicionar os novos interruptores ou lâmpadas (procedimento 3

do resumo anterior), sem necessidade de estarmos a repetir o processo de adicionar propriedades e

tipos de dispositivos.

A partir do momento em que uma propriedade ou tipo de dispositivo estão criados, podem ser

continuamente reutilizados em vários dispositivos.

60

Agora passaremos à programação. Como apenas pretendemos avaliar o valor de uma propriedade

de um dispositivo, basta-nos criar um programa simples.

Para isso vamos então escolher um nome para o programa, pode ser, iluminação_sala_1. De seguida

escolhemos o dispositivo activador, que neste caso será o interruptor_1, será ele que irá fazer

acender ou apagar a lâmpada. Neste dispositivo é necessário escolher qual a propriedade que irá

activar a condição, o que, neste caso, será obviamente a propriedade On/Off.

Em seguida é necessário explicitar que teste será realizado. Como o interruptor apenas tem dois

valores, 0 se estiver Off, 1 se estiver On, existem dois testes que poderiam ser aplicados neste caso:

“igual a 1” ou “maior que 0”. Salienta-se que esta situação acontece apenas neste caso particular e

não é garantido que possa ocorrer noutros casos. É por isso mais seguro escolher a condição “igual

a…” e o valor 1.

Finalmente teremos que adicionar as acções de activação e de desactivação que serão associadas

ao programa simples. Escolhemos o número do programa onde adicionar a acção, neste caso

apenas existindo um programa, será o número 1, o dispositivo a activar e propriedade a activar serão

a lâmpada_1, propriedade On/Off. A mensagem de activação propriamente dita será,

“@ON_2_1_1_lampada_1” e a de desactivação será “@OFF_2_1_0_lampada_1”.

O formato destas mensagens não está ainda definido. Ao longo desta dissertação foi convencionado

este formato para as mensagens. Mas futuramente poderá ser usado outro formato, visto que as

mensagens serão enviadas para os dispositivos reais.

Novamente um resumo dos procedimentos:

1- Criar Programa simples

Nome Iluminação_sala_1

Dispositivo Activador 1 – Interruptor_1

Propriedade Activadora 1 – On/Off

Condição “Igual a…”

Valor 1


Programa 1 – Iluminaçao_sala_1

Dispositivo a Activar 2 – Lâmpada_1

Propriedade a Activar 1 – On/Off

Mensagem de Activação @ON_2_1_1_lampada_1

61



Dispositivo a Desactivar 2 – Lâmpada_1

Propriedade a Desactivar 1 – On/Off

Mensagem de Desactivação @OFF_2_1_0_lampada_1

Conclusão, quando se carregar no interruptor_1, o valor da propriedade On/Off deste passará para o

valor 1, o que colocará a condição “igual a 1” a verdadeiro e portanto dará origem á mensagem de

activação que fará ligar a lâmpada_1. Por outro lado, quando for novamente pressionado o

interruptor, o valor passará para 0, o que colocará a condição “igual a 1” a falso, e portanto dará

origem a mensagem de desactivação e portanto desligará a lâmpada_1.

Faz sentido salientar que a qualquer momento podem ser adicionadas novas acções tanto de

activação ou desactivação a este programa, sem necessidade de criar um novo programa. Assim se

for instalada uma nova lâmpada, ou outro dispositivo na divisão e se quiser associá-lo ao

interruptor_1, basta adicionar uma nova acção ao programa iluminaçao_sala_1.

6.2. Cenário Moderado

Como exemplo de uma programação um pouco mais complexa, escolhemos como exemplo o caso

em que temos dois interruptores a trabalhar em conjunto para fazer ligar uma lâmpada.

Numa instalação tradicional, para que dois interruptores pudessem funcionar em conjunto, teriam que

ser substituídos por comutadores de escada. Um comutador de escada é um dispositivo que funciona

como um interruptor, mas que está preparado para ser interligado com outros comutadores de

escada, de modo a funcionarem de forma complementar, ou seja, quando um liga, o outro a seguir

desliga, e quando um desliga o outro liga.

No caso do nosso sistema, não são necessários comutadores de escada para que dois interruptores

possam interagir com a mesma lâmpada (ou qualquer dispositivo) de forma complementar, basta-nos

para isso possuir dois interruptores vulgares, como os do exemplo simples, mas que são

programados de forma a ter um comportamento complementar.

Vamos então programar o sistema para que o interruptor 2 e o interruptor 3, da figura 6.1, façam

acender ou apagar a lâmpada 2 da mesma figura.

Em termos de propriedades, tipos de dispositivos e dispositivos, os procedimentos são os mesmos do

exemplo simples, portanto vamos deixar aqui apenas o resumo dos procedimentos. De salientar

62

apenas, que em termos de nomes e IDs, se mantêm aqueles que já foram adicionados no exemplo

simples, portanto, continua-se a numeração a partir desses valores.


Nome On/Off

Modo acesso Leitura e Escrita

Tipo de valor Enumerado


Nome Interruptor Lâmpada

Propriedades On/Off On/Off


Nome Interruptor_2 Interruptor_3 Lâmpada_2

ID 3 4 5

Tipo de dispositivo Interruptor Interruptor Lâmpada

Agora a programação, como neste caso temos duas propriedades de dois dispositivos a interagir,

teremos que utilizar uma programação complexa.

Este programa complexo terá duas condições, ligadas por um operador.

Vamos então estudar o problema.

Temos dois interruptores, que podem ter o valor 1 ou 0, de início ambos estão com o valor 0, ou seja

off. O que queremos é que quando um deles esteja On, ou seja com o valor 1, a lâmpada acenda e

quando o outro interruptor passe a estar On também (valor 1), a lâmpada apague, e por ai adiante.

Então o que necessitaremos é de um operador XOR, como podemos comprovar na tabela 6.2.

63

Tabela 6.2 – Tabela XOR entre os valores dos interruptores 2 e 3.

Interruptor_3

Inte

rru

pto

r_2

XOR 0 1

0 0 1

1 1 0

Assim, de acordo com a tabela 6.2, sempre que um dos interruptores esteja On (valor 1), mas o outro

esteja Off (valor 0), então a lâmpada será acesa. Caso contrário, sempre que os dois interruptores

estejam ON ou Off, a lâmpada será apagada.

Vejamos então como configurar o programa complexo. Começamos por criar o programa complexo

com o nome de Iluminaçao_sala_2. De seguida criamos as duas condições, cada uma

correspondente a cada um dos interruptores, escolhemos o programa complexo número 1,

iluminação_sala_2, escolhemos o nome para a condição, estamos a programar sobre o interruptor 2

portanto chamaremos a esta condição, interruptor_2_igual_1, de seguida escolhemos o dispositivo e

propriedade que activará a condição, serão o interruptor_2, propriedade On/Off. Finalmente

escolhemos a condição a implementar e o valor, será a condição, “igual a”, com o valor 1.

Como se pode observar a criação de uma condição de um programa complexo é em tudo semelhante

á criação de um programa simples. O conceito de funcionamento é igual.

Criadas as duas condições, a segunda condição é igual á primeira, basta mudar o nome do

dispositivo para interruptor_3.

De seguida vamos então criar o operador que irá fazer interagir as duas condições, para isso

escolhemos o programa complexo numero 1 (o único existente), seleccionamos as duas condições

criadas anteriormente, e finalmente escolhemos o operador desejado, neste caso, como vimos

anteriormente, será o operador XOR.

Para finalizar adicionamos as acções de activação e desactivação, a criação e adição destas acções

e suas mensagens é em tudo semelhante aos procedimentos adoptados no exemplo simples, pelo

que apenas faremos um resumo:


Nome Iluminaçao_sala_2

64


Programa 1 - Iluminaçao_sala_2 1 - Iluminaçao_sala_2

Nome Interruptor_2_igual_1 Interruptor_3_igual_1

Dispositivo a Programar 3 – Interruptor_2 4 – Interruptor_3

Propriedade a Programar 1 – On/Off 1 – On/Off

Condição Igual a Igual a

Valor 1 1


Programa Iluminaçao_sala_2

1º Operador Interruptor_2_igual_1

2º Operador Interruptor_3_igual_1

Operador Lógico XOR





Mensagem de Activação @ON_5_1_1_lampada_2



Dispositivo a Desactivar 5 – Lâmpada_2

Propriedade a Desactivar 1 – On/Off

Mensagem de Desactivação @OFF_5_1_0_lampada_2

Conclui-se assim, que sem ser necessário usar equipamentos físicos específicos, como comutadores

de escada, é possível programar o sistema para que se comporte da mesma forma e tenha as

mesmas funções.

Neste caso são usados 2 interruptores, mas é possível alterar o sistema para que sejam

programados três, quatro ou mais interruptores de modo a funcionarem de modo complementar.

65

Basta para isso criar uma condição para cada um dos interruptores, e depois usar novamente o

operador XOR, entre as várias condições.

6.3. Cenário Complexo

Faz sentido finalmente, depois de termos apresentado dois exemplos de programações, todas elas

accionadas directamente pelo utilizador, apresentar um exemplo de como utilizar as programações do

tipo horário. Estamos a falar tanto das programações horárias, como das sequências.

Assim vejamos o seguinte exemplo, na figura 6.1 está presente um detector de movimento.

Consideremos útil que durante o período nocturno o detector de movimento possa ligar e desligar a

iluminação da sala, caso haja ou não, pessoas presentes na divisão.

Então é necessário criar uma programação horária que vai definir o período em que o detector estará

ligado, vamos definir o período que vai das 20h às 6h.

A seguir é necessário definir quanto tempo queremos a iluminação ligada sem que haja movimento a

ser detectado, vamos definir 5 minutos. Como o tempo é dado em segundos para o sistema, vamos

ter que definir 5x60=300 segundos. Isto é, teremos que criar uma sequência com um item de 300

segundos, que passados os 300 segundos irá desligar a lâmpada em questão.

Finalmente teremos de criar um programa complexo, que irá definir que quando o detector de

movimento estiver activo e der sinal de movimento, irá dar ordem para que a iluminação seja ligada e

a sequência seja activada.

Vejamos então como configurar o sistema. Começamos por adicionar os dispositivos e suas

propriedades, tal como fizemos nos exemplos anteriores.


Nome On/Off Detecta/Nao_Detecta

Modo acesso Leitura e Escrita Leitura

Tipo de valor Enumerado Enumerado


Nome Detector Movimento Lâmpada

Propriedades - On/Off

- Detecta/Não_Detecta

- On/Off

66


Nome Detector_Movimento_1 Lampada_1

ID 6 4

Tipo de dispositivo Detector Movimento Lâmpada

Em relação às programações, teremos que começar por criar e definir a sequência. Como se disse

anteriormente, terá um só item, com 300 segundos de tempo de espera. Passados esses 300

segundos, a acção a ser activada será @OFF_4_1_0_lampada_1, ou seja, ordena á lâmpada_1 que

se desligue.

Resumo dos procedimentos:

1- Criar Sequencia

ID 1

2- Adicionar Item á sequencia

Sequencia 1

Tempo 300

3- Adicionar Acção ao item

Sequencia 1

Item 1

Acção @OFF_4_1_0_lampada_1

De seguida vamos definir o programa complexo. Vamos então criar um programa complexo que terá

duas condições, uma será a condição do detector de movimento estar ligado, outra será a condição

do detector de movimento detectar ou não algum movimento.

No meio destas duas condições estará o operador AND, ou seja, as acções só serão activadas

quando as duas e apenas as duas condições estiverem activas ao mesmo tempo, tal como se pode

observar na tabela 6.3, que explica o funcionamento do operador AND.

De salientar, que neste programa não haverá acção de desactivação, apenas de activação, a

desactivação será desempenhada pela sequência. Teremos duas acções de activação para este

67

programa, a primeira irá ligar a lâmpada e a segunda acção irá activar a sequência, que passará a

contar a partir daquele momento.

De salientar que quando se está a definir a segunda acção de activação, será pedido o dispositivo e

propriedade a programar, neste caso deve-se definir o mesmo que na primeira acção, apesar de não

ter qualquer significado, visto que não será um dispositivo a ser activado mas sim uma sequência,

através de uma mensagem interna do sistema.

Tabela 6.3 – Tabela AND entre os valores das condições 1 e 2.

Condição 2

Co

nd

ição

1 AND 0 1

0 0 0

1 0 1

Resumo da programação:


Nome Detector_sala_1


Programa 2 - Detector_sala_1 2 - Detector_sala_1

Nome Detector_on/off_igual_1 Detector_detecta_igual_1

Dispositivo a Programar 6 – Detector_movimento_1 6 – Detector_movimento_1

Propriedade a Programar 1 – On/Off 2 – Detecta/Nao_Detecta

Condição Igual a Igual a

Valor 1 1


Programa 2 - Detector_sala_1

1º Operador Detector_on/off_igual_1

2º Operador Detector_detecta_igual_1

Operador Lógico AND

68


Acção 1:




Mensagem de Activação - @ON_4_1_1_lampada_1

Acção 2:




Mensagem de Activação - \x15\x01\x00\x00\x00

Para finalizar, precisamos apenas criar o programa horário que irá ligar e desligar o detector de

movimento.

Este programa terá como nome, Horas_detector_movimento_1 e ID 1, a repetição será diária, pelo

que não precisaremos definir dias de semana a programar e o período de repetição será de 1, ou seja

repetirá todos os dias, dia sim, dia sim.

De seguida teremos que escolher a data de início e a de final. Para este exemplo escolhemos

2014/02/01 como inicio e 2014/03/01 como final. As horas serão adicionadas, com o período horário.

Escolhemos, como dissemos anteriormente, as 20:00:00h para o início e as 06:00:00h para o final.

Finalmente resta adicionar as acções. Como mensagem da acção de activação teremos,

@ON_6_1_1_Detector_movimento_1, que fará ligar o detector. E como mensagem de desactivação

teremos @OFF_6_1_0_Detector_movimento_1, que fará desligar o detector.

1- Criar Programa horário

Nome Horas_detector_movimento_1

ID 1

Tipo Repetição Diária

Período de Repetição 1

Data de Inicio 2014/02/01

Data de Final 2014/03/01

69

2- Adicionar período ao programa horário

Programa Horas_detector_movimento_1

Data de Inicio 20:00:00

Data de Final 06:00:00



Mensagem de Activação @ON_6_1_1_Detector_movimento_1



Mensagem de Activação @OFF_6_1_0_Detector_movimento_1

Depois de todos estes procedimentos, temos o nosso sistema configurado.

Assim, durante o mês de Fevereiro, que foi o mês que configurámos, sempre que haja movimento na

sala, durante a noite, ou seja entre as 20h e as 6h da manha, a iluminação estará ligada, pelo período

mínimo de 5 minutos, sendo que sempre que haja movimento este tempo dos 5 minutos é reiniciado.

Temos assim uma configuração do sistema que pode diminuir o consumo energético, pois sempre

que nos ausentarmos desta sala, por mais de 5 minutos a iluminação será desligada, poupando

assim energia.

71

7. Conclusão

Esta dissertação teve como objectivo a criação e teste de um software que permite efectuar a

supervisão de um sistema domótico. A aplicação de supervisão desenvolvida usa o sistema

DomoBus, tirando partido do seu modelo genérico de dispositivo domótico, o que permite o

desenvolvimento de aplicações muito flexíveis, independentes de qualquer tecnologia específica.

Este modelo genérico permite descrever um dispositivo físico através de um conjunto de

propriedades, em que cada propriedade assumirá um valor consoante o seu estado real.

Os mecanismos de supervisão desenvolvidos baseiam-se em três conceitos fundamentais: regras,

sequências temporizadas de acções e agendamento de acções. As regras implementam uma lógica

do tipo “IF condição THEN lista-acções ELSE lista-acções”. As sequências temporizadas permitem

realizar pausas, após o que desencadeiam uma lista de acções. E o agendamento corresponde à

implementação de programas horários, permitindo ligar ou desligar equipamentos a determinada hora

de determinado dia, ou repetir essas actuações, por exemplo, em vários dias da semana ou vários

dias do mês.

As acções correspondem ao envio de mensagens que modificam o valor das propriedades dos

dispositivos, o que desencadeia alterações no seu estado físico.

O sistema utiliza uma arquitectura baseada num módulo de supervisão que age como cérebro do

sistema, controlando todos os dispositivos presentes na habitação. Ligado a este módulo de

supervisão encontram-se variados módulos de controlo espalhados pela residência que interagem

com os dispositivos físicos reais.

Este módulo de supervisão consiste num pequeno computador, que pode ser implementado com um

Raspberry Pi e que corre a aplicação de supervisão. Esta aplicação, chamada Supervisor, foi

desenvolvida na linguagem de programação C por razões de eficiência e de portabilidade, sendo ela

que controla todo o sistema.

Para interagir com a aplicação Supervisor foi desenvolvida a aplicação Programador. O Programador

corre noutro computador, ligado por rede TCP/IP ao Supervisor. O utilizador usa o Programador para

parametrizar todo o sistema e para definir como quer que ele se comporte. O utilizador pode modificar

o funcionamento do sistema em qualquer momento, seja para adicionar novos dispositivos ou

condições, ou para alterar os existentes.

Face às características deste sistema, confirma-se que se trata de um sistema poderoso e robusto,

mas ao mesmo tempo bastante flexível, sendo possível alterar as configurações do sistema sempre

que desejado, sem interrupções no seu funcionamento. E possibilitando integrar dispositivos de

várias tecnologias.

A juntar a isto, mantém-se o objectivo de assegurar um custo reduzido para o sistema, tanto ao nível

dos módulos de supervisão, em que basta recorrer a um Raspberry Pi, quer ao nível dos módulos de

controlo. Os módulos de controlo, ainda em desenvolvimento, podem ser implementados usando

microcontroladores de custo reduzido pois não exigem grandes capacidades de memória nem de

72

processamento. Ao nível da instalação e configuração de um sistema, não é necessário o recurso a

técnicos especializados nem a aplicações pagas, o que contribui também para uma redução de

custos. Considera-se assim que a abordagem DomoBus pode ser economicamente vantajosa face a

outros sistemas.

No entanto, apesar de poder ser configurado por um utilizador comum, sem conhecimentos

específicos, a configuração pode tornar-se complicada quando se pretendem comportamentos

complexos, envolvendo diversos sensores e actuadores a realizarem acções conjuntas. Para estes

cenários mais complexos, a lógica envolvida começa a requerer competências de programador, o que

não estará, tipicamente, ao alcance do utilizador comum. Apesar disso, as vantagens são em muito

superiores às dos sistemas comerciais disponíveis actualmente.

O objectivo deste trabalho não era o de resolver estes problemas de complexidade, mas sim testar

todas as capacidades do sistema, validar o seu modelo e a lógica seguida e assim confirmar se a

abordagem proposta é poderosa e oferece o nível de funcionalidade requerido.

Foram realizados múltiplos testes e foram apresentados três exemplos que permitiram validar o

correcto funcionamento das aplicações desenvolvidas. Concluiu-se que a abordagem seguida,

baseada em regras, sequências temporizadas de acções e agendamento de acções, mostrou ser

funcional, permitindo definir qualquer comportamento, tão complexo quanto se deseje, para uma

habitação.

Embora as conclusões obtidas permitam demonstrar que foram atingidos os objectivos da

dissertação, foram identificados vários aspectos que podem ser melhorados para que o sistema se

torne num verdadeiro sistema domótico, podendo assim ser usado em qualquer tipo de habitação e

por qualquer tipo de utilizador:

Desenvolvimento de uma interface gráfica para o sofware, de modo a torná-lo mais amigo do

utilizador. Juntamente com esta interface gráfica, deve ser também automatizado o processo

de criação de programações, de modo a facilitar a interacção do utilizador com o sistema.

Apesar do sistema DomoBus suportar a existência de diversos supervisores, isso tem que ser

configurado manualmente. De futuro será útil criar ferramentas que permitam automatizar o

processo, evitando eventuais erros do utilizador.

Desenvolver mais funções para a biblioteca de supervisão, nomeadamente no que diz

respeito á gestão dos programas e dispositivos. No presente momento, em termos das

programações, apenas é possível apagar programas simples e complexos. É necessário criar

funções que permitam apagar os programas horários e sequências. Bem como permitir que

se possam modificar programas já existentes. Neste momento é possível adicionar novas

acções, condições, períodos ou itens, mas não é possível apagar as já existentes ou

modificá-las, sem apagar todo o programa. Seria útil desenvolver estas funções.

73

Automatizar o processo de criação de mensagens que desencadeiam acções sobre os

dispositivos ou sobre o próprio supervisor, evitando o uso de códigos hexadecimais e

permitindo o uso de comandos intuitivos.

Identificar casos de uso típicos como a iluminação de escadas (com ou sem temporização),

de corredores (envolvendo sensores de luminosidade e de movimento), de casas de banho

(incluindo sensores de presença e temporizações), entre outros, oferecendo padrões

predefinidos de comportamentos para esses cenários. Deste modo, o utilizador apenas teria

de seleccionar o padrão a usar e fazer a respectiva configuração para cada caso particular.

Este mecanismo poderia conduzir a uma grande simplificação da programação de alguns

cenários complexos.

75

8. Bibliografia

[1] Renato Nunes, "Análise Comparativa de Tecnologias para Domótica", JEACI 2002- III

Jornadas de Engenharia de Automação, Controlo e Instrumentação, EST Setúbal, Maio 2002.

[2] Andrew K. Dennis, “Raspberry Pi Home Automation with Arduino”, Packt Publishing, 2013.

[3] Steven Goodwin, “Smart Home Automation With Linux”, Apress, 2010.

[4] Robert C. Elsenpeter, Toby J. Velte, “Build Your Own Smart Home”, McGraw-Hill, 2003.

[5] http://www.smarthomeusa.com/info/customer_service (Março 2014)

[6] Renato Nunes, "Modelo de Especificação e Programação de um Sistema Domótico", IADIS

Conferência Ibero-Americana, Madrid, Espanha, 2004.

[7] Renato Nunes, "A Communication Infrastructure for Home Automation", International

Conference on Computer, Communications and Control Technologies, Austin, EUA, Agosto

2004.

[8] Renato Nunes, "DomoBus - A New Approach to Home Automation", 8CLEEE - 8th

International Congress on Electrical Engineering, Portugal, Julho 2003.

[9] Renato Nunes, "Implementing Tiny Embedded Systems with Networking Capabilities", IADIS

International Conference on Applied Computing 2005, Algarve, Portugal, Fevereiro 2005.

[10] Renato Nunes, "Decentralized Supervision for Home Automation", MELECON 2006 - The

13th IEEE Mediterranean Electrotechnical Conference, Ben Almádena, Espanha, Maio 2006.

[11] Renato Nunes, “Especificação XML de um Sistema DomoBus - V1.6”, Dezembro 2006.

[12] IgeiP.J.,Garcia J.I., CugnascaC.E., “Modelagem de Redes de Controle LonWorks em Edifícios

Inteligentes”, 8º Congresso Ibero-americano de Engenharia Mecânica, Outubro 2007.

[13] Mahmoud A. Al-Qutayri, “Smart Home Systems”, In-Teh, Fevereiro 2010.

[14] http://www.knx.org/knx-en/knx/association/what-is-knx/index.php (Abril 2014).

[15] http://www.hager.pt (Março 2014).

76

[16] http://www.schneiderelectric.pt/sites/portugal/pt/produtos-servicos/product-

launch/knx/knx.page (Abril 2014).

[17] “KNX-Flash ABB i-bus KNX”, 2011. (Abril 2014).

Disponível em:

http://www.knx-gebaeudesysteme.de/sto_g/English/GENERAL_DOCUMENTATION/2CDC500043B0202_KNX_Flash_EN.pdf

[18] http://www.smarthome.com (Março 2014).

[19] https://www.smarthomeusa.com/info/x10theory (Março 2014).

[20] http://www.echelon.com/technology/lonworks (Março 2014).

[21] http://www.rtaautomation.com/lonworks (Março 2014).

[22] http://www.circon.com/resources/documentation (Março 2014).

[23] http://www.raspberrypi.org/help/faqs (Março 2014).

[24] http://www.arduino.cc (Março 2014).

[25] http://www.comfortclick.com (Março 2014).

[26] http://www.smarthomeusa.com/info/x10story#story (Abril 2014).

[27] J. P. Sucena Paiva, “Redes de Energia Eléctrica: uma Análise Sistemática”, IST Press, 2005.

mecanismo de supervisão para sistemas domóticos · v resumo a domótica veio trazer variados...

Documents