Faculdade de Engenharia da Universidade do Porto

Sistema modular de comunicação e controlo de dispositivos sensores/atuadores: Um ensaio na

NextToYou - Network Solutions, Lda.

Luis Alberto Cerqueira Sousa

VERSÃO PROVISÓRIA

Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Major Automação

Orientador: Prof. Dr. José Ruela

Co-orientador: Engº Rui Moreira

© Luis Alberto Cerqueira Sousa, 26 de Junho 2012

ii

iii

Resumo

O presente documento descreve o trabalho efetuado no âmbito da dissertação de mestrado,

os objetivos do projeto, as opções tomadas, os passos seguidos e as conclusões e ambições futuras

do projeto.

Esta dissertação tinha como objetivo desenvolver um sistema de gestão para uma aplicação

de domótica a integrar num sistema existente desenvolvido pela empresa onde esta dissertação se

desenrolou. O sistema de gestão de domótica a desenvolver teria ser implementado numa Intranet,

ou seja, o sistema deveria operar numa rede domótica KNX já implementada. A rede de domótica

KNX implementada possui um Router, uma fonte de alimentação e um módulo de quatro saídas. O

Router garante a fiabilidade da comunicação entre um sistema externo e a rede KNX, a fonte de

alimentação alimenta toda a rede, o módulo de quatros saídas permite o controlo das saídas

independentemente das cargas elétricas (lâmpada, motor, led, etc.) colocadas para controlo, e

possui quatro sensores que permitem verificar o estado (on/off) das saídas desse módulo.

O sistema de gestão de domótica é constituído por um computador com o sistema operativo

Windows, um módulo de software que foi desenvolvido na dissertação e o programa Calimero. Com

a perspetiva a futuros desenvolvimentos como a ligação remota ao sistema de domótica, o software

devia ser desenvolvido numa linguagem compatível com o Worl Wide Web. As linguagens escolhidas

para esse efeito foram HTML e CSS para a parte visual, Javascript para criar mais interação entre o

sistema e o utilizador e por fim PHP responsável pelo controlo de todo o sistema de gestão de

domótica. O sistema de gestão de domótica controla o programa Calimero, segundo as decisões de

controlo do utilizador e de forma a que rede KNX já existente responda essas decisões.

O software a desenvolvido teve como base uma arquitetura Model View Controller, ou seja,

uma arquitetura de software modular. Esta arquitetura foi adotada para que o sistema possa

facilmente ser adaptado às opções que uma rede KNX oferece, em número, variedade e

funcionalidades dos dispositivos. Esta arquitetura permite também alterar o modelo de negócio, a

apresentação e o controlo do software sem que se tenha de alterar todo o sistema ou alguma das

partes que não seja necessária.

Tudo o que foi desenvolvido na dissertação teve por base o protocolo de domótica KNX.

iv

v

Abstract

This document consists in a master thesis describing the goals, decisions, implementation and

conclusions and future work in order to describe work done along the project.

This dissertation has the goal of developing a demotic management system, integrating the

application in a system built by the enterprise that hosted this project.

The demotic management system had to be implemented on an intranet, in other words, the

system had to operate in an already implemented KNX demotic network. The implemented network

has a Router, a power source and a four port module. The Router guarantee communication

reliability between an external system and the KNX network, the power supply feeds all the

network and the four ports module enables the control of all ports regardless of the electrical

charges ( lamp, motor, led, etc…) used to control and has four sensors that checks the state (

on/off) of each module output.

The demotic system consists of a computer with Windows operating system, a software module

developed in the dissertation and the Calimero application. The system had to be built on a

language compatible with the Worl Wide Web, covering the need of developing a software capable

of establishing a remote connection to the demotic system. Chosen languages were HTML and CSS

for the graphic interface[parte visual], JavaScript with the goal of stimulating interaction

between user and the system and finally PHP responsible of controlling all the demotic

management system. The demotic management system controls the Calimero application,

respecting the user decisions and letting the existing KNX network respond to that decisionsThe

software was developed using a Model View Controller architecture, in other words, a modular

software architecture. This architecture was adopted with the idea of easily integrate system with

the options that KNX network offers in quantity, variety, and device features. Finally this

architecture enables to edit one of the business, presentation or control models separately

avoiding unnecessary work.

All dissertation work was developed under the KNX demotic protocol.

vi

vii

viii

Agradecimentos

Quero expressar o meu sincero agradecimento ao meu orientador, Prof. José Ruela, pelo seu

interesse e acompanhamento, mesmo fora de horas, no desenvolvimento e escrita desta

dissertação.

Quero agradecer ao Luciano Alves pelas inúmeras sugestões e acompanhamento no

desenvolvimento da aplicação e pela revisão e sugestões dadas relativas ao artigo escrito em Inglês.

Quero também agradecer à minha mãe pela educação por tudo aquilo que faz de mim a pessoa

que sou hoje.

Quero ainda deixar um agradecimento à empresa NexttoYou pela compreensão e pelo tempo

disponibilizado para a realização do projeto e desta dissertação.

Agradeço a todos que me apoiaram incondicionalmente neste meu percurso académico.

A todos o meu muito obrigado.

ix

x

Índice

Resumo ............................................................................................ iii

Abstract ............................................................................................. v

Agradecimentos ................................................................................. viii

Índice ............................................................................................... x

Lista de figuras ................................................................................... xii

Abreviaturas e Símbolos ....................................................................... xvi

Capítulo 1 .......................................................................................... 1

Introdução..................................................................................................... 1 1.1 - Problema ............................................................................................ 1 1.2 - Motivação ............................................................................................ 2 1.3 - Estrutura da dissertação .......................................................................... 3 O relatório divide-se em 9 capítulos: .................................................................. 3

Capítulo 2 .......................................................................................... 4 2.1 História .............................................................................................. 4 2.2 Objetivos da Domótica ............................................................................ 4 2.3 Áreas de controlo ................................................................................... 5

2.4 Protocolos de comunicação ......................................................................... 6 2.4.1 X-10 ............................................................................................. 6

Capítulo 3 .......................................................................................... 9

Sistemas KNX ................................................................................................. 9 3.1 História .............................................................................................. 9 Principais características e vantagens .............................................................. 10 Desvantagens ............................................................................................ 11 3.2 Arquitectura e Elementos KNX ................................................................. 11 Modos de configuração ................................................................................. 11 Tipos de implementação .............................................................................. 13 Dispositivos .............................................................................................. 13 Acopladores .............................................................................................. 14 BCU (Bus Coupling Units) .............................................................................. 15 PEI (Physical External Interface) ..................................................................... 16 3.3 Rede KNX e Endereçamento .................................................................... 17 Topologia da Rede KNX ................................................................................ 17 Telegrama KNX .......................................................................................... 20

xi

3.4 Gateway IP / Bus KNX ............................................................................ 25 Troca de Dados e Interfuncionamento .............................................................. 26 3.5 Instalação de Redes KNX ....................................................................... 31 Quadro elétrico ......................................................................................... 31 Tipo de cabo ............................................................................................. 33

Capítulo 4 ......................................................................................... 35

Sistema de gestão de domótica ........................................................................... 35 3.1 Sistema de gestão de domótica ................................................................ 35 4.1 Model ............................................................................................... 37 4.2 View ................................................................................................. 37 4.4 BASE DE DADOS ................................................................................... 38

Capítulo 5 ......................................................................................... 42

Tecnologias adoptadas ..................................................................................... 43 5.3 CSS 44 5.4 Javascript .......................................................................................... 45 5.5 PHP .................................................................................................. 48 5.6 Calimero ............................................................................................ 49 5.7 Wampserver ....................................................................................... 49

Capítulo 6 ......................................................................................... 51

Interface gráfica .......................................................... Erro! Marcador não definido. 6.2 Processamento do controlo ..................................................................... 52

Capítulo 7 ......................................................................................... 54

Teste e avaliação do sistema .............................................................................. 54 7.1 Cenários de teste ................................................................................. 54 7.2 Base dados ......................................................................................... 54 7.3 Configuração da rede IP e configuração KNX ................................................ 62 7.6 Base de dados ..................................................................................... 68

Referências ....................................................................................... 74

xii

Lista de figuras

Figura 1: Exemplo de sistema de implementação do KNX. ............................................... 9

Figura 2: Exemplo de uma Rede KNX. ....................................................................... 10

Figura 3: Modos de configuração do KNX. ................................................................... 13

Figura 4: Estrutura de um dispositivo KNX. ................................................................. 14

Figura 5: Arquitetura de um BCU. ............................................................................ 15

Figura 6: Arquitectura de um TRC.. .......................................................................... 16

Figura 7: Diagrama de pinos do PEI. .......................................................................... 16

Figura 8: Tipos de redes KNX. ................................................................................. 18

Figura 9: Topologia genérica de um sistema KNX. ......................................................... 19

Figura 10: Endereços individuais do protocolo KNX. ...................................................... 20

Figura 11: Endereços de grupo no protocolo KNX. ........................................................ 20

Figura 12: Características de um telegrama KNX. ......................................................... 21

Figura 13: Características do campo de controlo de um telegrama KNX.. ............................ 22

Figura 14: Endereço individual. ............................................................................... 22

Figura 15: Endereços de grupo de dois e três níveis. ..................................................... 23

Figura 16: Características do campo de controlo de um telegrama KNX. ............................. 23

Figura 17: Campo contador. ................................................................................... 23

Figura 18: Campo de dados. ................................................................................... 24

Figura 19: Campo de verificação cruzada. .................................................................. 24

Figura 20: Estrutura de uma mensagem de confirmação. ................................................ 24

Figura 21: Montagens com routers IP/KNX. ................................................................. 26

Figura 22: Exemplo de comunicação entre um interruptor e uma lâmpada. ......................... 27

xiii

Figura 23: Pirâmide de inter-funcionamento. .............................................................. 28

Figura 24: Funções EIB. ......................................................................................... 29

Figura 25: Função EIB2 (dimming). ........................................................................... 29

Figura 26: Função EIB2 (Priority). ............................................................................ 30

Figura 27: Diferentes tipos de calha e cobertura para calha DIN. ...................................... 31

Figura 28: Montagem Rail-mounted. ......................................................................... 32

Figura 29: Dispositivos do tipo montagem embebida. .................................................... 32

Figura 30: Dispositivo do tipo montagem de superfície .................................................. 32

Figura 31: Dispositivo do tipo montagem Device mounted. .............................................. 33

Figura 32: Isolamento de cabos para KNX. .................................................................. 33

Figura 33: Características de um cabo param KNX. ....................................................... 34

Figura 34: Arquitetura global do sistema. ................................................................... 35

Figura 35: Arquitetura de Software do sistema a desenvolvida. ........................................ 36

Figura 36: Esquema da base de dados elaborada para armazenar a informação da rede KNX. ... 40

Figura 37: Modelo final da base de dados. .................................................................... 42

Figura 38: Página de login sem a influência da CSS. ......................................................... 44

Figura 39: Página de login já com a influência da CSS. ...................................................... 45

Figura 40: Organograma das classes de objetos existentes em Javascript................................ 46

Figura 41: Caixa de dialogo alert() do objeto Window. ..................................................... 46

Figura 42: Página antes de clicar no botão Ler e ativar o script. .......................................... 47

Figura 43: Página depois de clicar no botão Ler e ativar o script. ......................................... 47

Figura 44: HTML sem a influência das folhas de estilo e o Javascript. .................................... 51

Figura 45: HTML já com a influência das folhas de estilo mas sem o Javascript. ....................... 52

Figura 46: HTML já com a influência das folhas de estilo e o Javascript. ................................ 52

Figura 47: Pesquisa na base de dados na tabela habitações. ............................................ 55

Figura 48: Pesquisa à base de dados por habitações. ..................................................... 56

Figura 49: Pesquisa de utilizadores efetuada na base de dados. ....................................... 56

Figura 50: Pesquisa de utilizadores do sistema efetuada à base de dados. ........................... 57

Figura 51: Pesquisa de Datapoints efetuada na base de dados. ......................................... 57

Figura 52: Pesquisa de Datapoints efetuada à base de dados pelo sistema. .......................... 58

xiv

Figura 53: Pesquisa por dispositivos na base de dados. .................................................. 58

Figura 54: Pesquisa efetuada a base de dados pelo sistema à procura de todos os dispositivos. ................................................................................................. 59

Figura 55: Pesquisa efetuada a base de dados à procura de todos os endereços de grupo. ....... 59

Figura 56: Pesquisa efetuada a base de dados pelo sistema à procura de todos os endereços de grupo. .................................................................................................... 60

Figura 57: Pesquisa na base de dados por dispositivoaddressgroup. ................................... 61

Figura 58: Pesquisa por dispositivoaddressgroup na base de dados efetuada pelo sistema. ...... 61

Figura 59: Configuração do IP alternativo do computador para funcionar com o Calimero. ...... 62

Figura 60: Página de login. ..................................................................................... 63

Figura 61: Página de acesso interdito. ....................................................................... 64

Figura 62: Página de controlo para utilizadores do tipo util2. .......................................... 64

Figura 63: Página de controlo para utilizadores do tipo util1. .......................................... 65

Figura 64: Página de controlo para utilizadores do tipo admin. ........................................ 65

Figura 65: Página de acesso a base de dados para utilizadores do tipo admin. ...................... 66

Figura 66: Página de edição do utilizador do tipo admin, Luisa. ....................................... 66

Figura 67: Página de controlo para utilizadores do tipo técnico e escolha da habitação a controlar. ................................................................................................... 67

Figura 68: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação1. ................................................................................................. 67

Figura 69: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação2. ................................................................................................. 68

Figura 70: Página da base de dados para editar, adicionar, pesquisar e eliminar habitação. ..... 69

Figura 71: Página da base de dados para editar, adicionar, pesquisar e eliminar utilizadores ... 69

Figura 72: Página da base de dados para editar, adicionar, pesquisar e eliminar dispositivos. .. 70

Figura 73: Página da base de dados para editar, adicionar, pesquisar e eliminar Datapoints. ... 70

Figura 74: Página da base de dados para editar, adicionar, pesquisar e eliminar endereços de grupo. .................................................................................................... 71

Figura 75: Página da base de dados para editar, adicionar, pesquisar e eliminar relações entre um dispositivo e um endereço de grupo (dispositivoaddressgroup). ..................... 71

xv

xvi

Abreviaturas e Símbolos

Lista de abreviaturas (ordenadas por ordem alfabética)

AA - Acoplador de área

AC - Area Coupler

ACK - Acknowledgement (data networks)

AL - Acoplador de linha

AM – application module

A-Mode - Automatic mode

ANACOM - Autoridade Nacional de Comunicações

AP- application program

BAU- Bus Access Unit

BCU - Bus Coupling Unit

BIM- Bus Interface Modules

BUSY- Linha de bus ocupada

CEBus - Consumer Electronics Bus

CENELEC EN - European Committee for Electrotechnical Standardization

CEN EN - European Committee for Standardization

CSMA/CA - Carrier Sense Multiple Access with Collision Avoidance

DIN - Deutsches Institut für Normung

EEPROM - Electrically Erasable Programmable Read Only Memory

EHS - European Home Systems Protocol

EIA - Electronic Industries Association

EIB - European Installation Bus

EIBA - European Installation Bus Association

EIB/KNX - European Installation Bus/konnex

EIS - EIB Interworking Standard

EIS - EIB Interworking Standard

E-Mode - easy mode

xvii

EN - European standards

ETS - Engineering Tool Software

HTTP - Hypertext Transfer Protocol

IP - Internet Protocol

IR - infra-red

ISO - International Organization for Standardization

ITED - Infra-estruturas de Telecomunicações em Edifícios

KNX- konnex

LC – Line Coupler

LAN – Local Area Network

MVC - Model-view-controller

Mysql - Structured Query Language

NACK - negative acknowledgement

PEI - Physical External Interface

PLC- Power Line Carrier

RAM – Random access memory

RF - Radio frequency

ROM – read only memory

RP - Repetidor de Linha

SCADA - supervisory control and data acquisition

SELV - Safety Extra Low Voltage

S-Mode - system mode

TRC- Transceive

X-10 - protocolo de comunicação para domótica (USA)

Capítulo 1

Introdução

1.1 - Problema

O problema proposto pela empresa NextToYou sedeada no INESC Porto será o tema para a

dissertação a desenvolver no 2º semestre de 2011/2012. O projeto proposto para desenvolver

durante a dissertação foi a criação de um sistema de gestão de domótica do tipo modular que

permite o controlo remoto de dispositivos sensores (estado electroválvulas, intrusão, etc.) e

atuadores (ligar, desligar, ativar alarmes, gerar avisos SMS/Email, etc.). O Software desenvolvido

teve como base uma arquitetura de Software modular do tipo Model-view-controller (MVC). Esta

arquitetura de Software visa separar a lógica de negócio da lógica de apresentação, permitindo

assim o desenvolvimento, teste e manutenção isolado de ambos.

O modelo (model) será uma base de dados em Mysql ou Postgres usada para fazer o registo no

domínio dos dados do sistema, que permitirá armazenar, modificar e extrair informação de um

banco de dados mediante as necessidades do sistema. Esta será uma representação detalhada da

informação que a aplicação gera e necessita para o funcionamento de todo o sistema.

A visão (view) tem como objectivo a representação do sistema de uma forma gráfica ao

utilizador, apresentando os dados de saída do sistema assim como os dados a fornecer ao sistema

pelo utilizador. Isso permite a interação entre este e o sistema, oferecendo para um mesmo modelo

diferentes visões mediante as funcionalidades e decisões tomadas pelo utilizador. Inicialmente será

uma página Web e, mais tarde, pretende-se a publicação da mesma como a possibilidade de acesso

ao sistema, através de internet e/ou PDA.

O controlador (controller) é um sistema baseado no protocolo HTTP que fará a gestão da base

de dados. Tais dados irão permitir atuar as saídas e atualizar a visão gráfica apresentada ao

utilizador. O controlador recebe-os e inicia a resposta ao utilizador, invocando as funções do

sistema de domótica adequadas à ordem efetuada e apresentando a visão baseada nas entradas

inseridas. Este também é responsável pela validação e filtragem da entrada de dados.

2 Introdução

2

O sistema de domótica desenvolvido foi baseado no protocolo aberto KNX. Isso deveu-se à

análise dos prós e contras efetuados pela empresa: visto ser o que oferece mais e melhores

vantagens para a empresa, para o produto e para o cliente (mercado).

1.2 - Motivação

A automação de edifícios sempre foi vista como um artigo de luxo capaz de assegurar um maior

conforto, autonomia aos utilizadores e segurança a um edifício. Com o crescente sedentarismo das

pessoas, por motivos profissionais e devido às vantagens oferecidas pela domótica, cada vez mais é

vista aos olhos dos consumidores como algo cada vez mais fundamentável. Hoje em dia, e cada vez

mais, existem equipamentos e dispositivos nas nossas casas que melhoram a nossa qualidade de

vida. Os eletrodomésticos inteligentes e os sistemas de controlo de iluminação são bons exemplos

de equipamentos que aumentam o conforto. Contudo, necessitam da interação humana para

poderem funcionar de acordo com as suas pretensões, tendo de ser atuado de forma independente

para satisfazer as preferências de cada utilizador. Os sistemas ao atuar só sob as ordens dos

utilizadores não permite atingir uma boa solução global em termos de eficiência energética, pois o

utilizador não consegue estar constantemente a controlar os diferentes dispositivos. Com a

necessidade de relacionar fatores como as condições ambientais, o consumo energético, a

segurança e o conforto, os sistemas de domótica vêm de encontro às necessidades dos utilizadores.

A grande motivação desta dissertação está na satisfação das necessidades de mercado, no

apelo comercial e futurista da domótica e visando uma versão comercial mais avançada do produto

já existente. Este trabalho vem dar continuidade a um projeto já existente: um sistema de

domótica. O âmbito da dissertação é a criação de um Software de gestão de domótica com

linguagem Web. Este futuramente poderá permitir a gestão do sistema por acesso remoto através

da Internet.

A NextToYou já possuía uma rede KNX construída é configurada, mas pretendia alargar a

capacidade do controlo domótico incluindo mais dispositivos e criando um sistema de gestão para

a rede existente. Para isso será desenvolvido um Software com base na linguagem Web para

gestão do condomínio com o intuito de futuramente conseguir controlar uma rede KNX com o

maior número de funcionalidades possíveis. O Software desenvolvido teve por base uma

arquitetura modular MVC com a finalidade de ser mais fácil de evoluir e modificar o sistema todo.

Com estes atributos, a empresa pretende criar um sistema capaz de rivalizar e superiorizar-se aos

existentes no mercado, de modo a conseguir tornar-se, quem sabe, líder de mercado. Para atingir

esta meta, será necessário o desenvolvimento de um sistema que apresente uma qualidade igual

ou superior aos sistemas já existentes mas a um preço inferior. A empresa não pretende

desenvolver os seus próprios dispositivos (hardware), mas sim utilizar dispositivos fornecidos por

revendedores que possam comunicar com o sistema a desenvolver. É necessário que seja um

sistema de arquitectura modular e passível de suportar a sua integração numa plataforma de

serviços existente, tendo como fim um sistema robusto e seguro, estando protegido de possíveis

ataques que possam prejudicar o bom funcionamento.

Erro! A origem da referência não foi encontrada. 3

1.3 - Estrutura da dissertação

O relatório divide-se em 9 capítulos:

Capitulo 1: é apresentado o resumo, índice a lista das figuras e a lista de abreviaturas;

Introdução: é explicado o âmbito do projeto, a motivação para a elaboração do projeto, os

objetivos da dissertação e a estrutura do relatório;

Estado da arte da Domótica: é apresentado um estudo aprofundado da domótica e dos seus

protocolos até aos nossos dias, com em especial atenção para o protoclo X-10 e o protocolo

da dissertação o KNX.

Sistemas KNX: é contada a história da criação do protocolo KNX e a sua evolução (Evolução

histórica), explicada e exemplificados alguns tipos de arquiteturas KNX e explicada a

constituição dos dispositivos utilizados num sistema KNX (Arquitetura e Elementos KNX). É

explicado como se elabora uma rede KNX e como os dispositivos interagem e comunicam

entre si (Rede KNX e Endereçamento). São também explicados os princípios e requisitos de

uma instalação de domótica com o protocolo KNX (Instalações KNX);

Sistema de gestão de domótica:

É apresentada a arquitetura de Software (MVC) que foi utilizada para desenvolver o

sistema;

É apresentado e explicado o modelo de base de dados criado e implementado;

E apresentada a Interface gráfica que será apresentada ao utilizador ao utilizar o sistema

desenvolvido;

É feita uma apresentação de Calimero e explicado o processamento do controlo efetuado

através do Calimero.

Teste e avaliação do sistema- são apresentados os testes às principais funcionalidades do

sistema de gestão desenvolvido e é feita uma avaliação do mesmo. Os testes efetuados

pretenderam a avaliação funcional e qualitativa do sistema de gestão de domótica;

Conclusões: é feita uma análise dos objetivos propostos para esta dissertação e

apresentadas as conclusões;

Desenvolvimentos futuros: são apresentados e explicadas as espectativas do sistema de

gestão domótica desenvolvido;

Bibliografia: são enumeradas as fontes de conhecimento nas quais foram baseadas o

relatório.

Capítulo 2

2. Estado da Arte em Domótica

2.1 História

Domótica é a integração de tecnologias e serviços, que permite a gestão de todos os recursos

de edifícios (habitações, escritórios, hospitais entre outros) de uma forma autónoma. A palavra

Domótica (domotique) surgiu na França, por volta dos anos 80, no século XX, durante a construção

dos primeiros edifícios, e da necessidade de controlar e interligar as funções de climatização,

segurança e iluminação. A palavra Domótica é a junção de domus do Latim (lar ou casa) com a

palavra telemática (telecomunicações + informática). Numa perspetiva mais abrangente, domótica

é a utilização de um conjunto de tecnologias e sistemas (eletricidade, eletróncia e tecnologias da

informação), que deverão funcionar de uma forma integrada, permitindo o controlo e uma gestão

automática dos diferentes recursos de um edifício, local ou de forma remota (Internet) oferecendo

uma vasta gama de aplicações. Outro sinónimo para domótica é casa inteligente (smart house),

porém nesta dissertação será utilizado o termo domótica.

2.2 Objetivos da Domótica

A domótica tem como grande objetivo oferecer a automatização de uma vasta gama de

aplicações nas áreas da segurança, conforto, comunicações e gestão de energia rentabilizando o

sistema, simplificando a vida diária das pessoas, satisfazendo as suas necessidades. A domótica

pode substituir o ser humano em diversas atividades rotineiras de forma a propiciar uma otimização

nas condições de vida numa casa. O próprio sistema zela pela satisfação dos clientes, sem que seja

necessária a contínua intervenção do mesmo. A vantagem de um sistema de domótica perante

sistemas de alarme ou outros automatismos é o facto de ele próprio se ir otimizando com base nas

informações recolhidas pelos diversos dispositivos que estão ligados ao sistema. Os sistemas de

domótica deverão ter capacidade de inteligência distribuída e de interação com os diversos

subsistemas de um edifício ou de uma habitação (Ar Condicionado, Luzes, Segurança,

eletrodomésticos, aparelhos de multimédia, etc.) mas de uma forma integrada, numa única central

que gere todos os espaços autónomos e todos os sistemas. Ou seja o sistema deve possuir pequenos

módulos que possam tomar decisões simples e um módulo principal que faça a gestão desses

módulos de uma forma centralizada, pois é esse módulo que possui a informação de todo o sistema.

A automatização de edifícios envolve questões técnicas e funcionais. Sob um ponto de vista

Erro! A origem da referência não foi encontrada. 5

funcional devem-se analisar questões como "que funções realizar" (comandos, medidas a obter,

parâmetros a regular, etc.), "quando realizá-las" (em tempo) e "como se realizam" fisicamente. Sob

o ponto de vista técnico, devesse planear questões como a modularização do sistema, periféricos e

a compatibilidade com elementos de outros fabricantes. O grau de controlo domótico alcançado

pode ser variável, sendo uma função do custo, desejo pessoal dos clientes, estrutura do edifício e

tecnologia usada.

2.3 Áreas de controlo

A Domótica pode ser divida em quatro grandes áreas, a saber: a gestão de energia, a segurança, o

conforto e as comunicações. De seguida serão enumerados os benefícios, as funções e as ações

tomadas pela domótica, nas áreas em que foram divididas:

Gestão de energia: Otimizar a relação conforto / consumo energético;

Ajuste automático de temperatura;

Gestão da iluminação;

Permitir um uso mais racional da água;

Controlo de electro domésticos: ligar/desligar electro domésticos como máquinas de lavar,

secar roupa e sistemas de aquecimento, quando as tarifas de energia elétricas são mais

baixas;

Facilitar o uso de energias renováveis:

Aquecimento de água;

Produção de energia elétrica;

Redução de desperdícios energéticos:

Iluminação: desliga automaticamente as luzes quando não houver pessoas em

determinado ambiente;

Reaproveitamento de águas pouco sujas para utilização sanitária;

Controlo de temperatura: poder controlar aquecedores e ar condicionado de forma

a minimizar o consumo de energia.

Segurança: Vigilância e deteção de intrusão;

Simulação de presença: ligar música e luzes;

Deteção de situações de emergência;

Monitorização de pessoas e bens (sistemas de videovigilância ou circuito fechado de

televisão);

Gerar alarmes técnicos em situações de emergência ou anómalas:

Inundação;

Fuga de gás e água;

Falta de energia;

Fogo e fumo: deteção rápida;

Forno, luzes, esquentador ou fogão está ou estão ligados;

Portas ou janelas abertas;

Alarme médico: monitorização e diagnóstico remoto de sinais vitais;

Enviar a informação dos alarmes técnicos para telefone, telemóvel, PDA, e-mail, sistema

SCADA e página Web;

6 Introdução

6

Corte automático da água e gás em caso de ocorrência de fuga;

Acionar automaticamente os serviços de segurança:

Alerta a moradores (SMS, e-mail, chamada telefónica);

Fazer chamada para bombeiros e/ou polícia.

Conforto: Permitir uma melhor qualidade de vida e maior autonomia;

Facilitar tarefas, automatizar procedimentos (Acionamento automático de tarefas de rotina

como ligar o aquecimento);

Controlar, monitorizar e administrar a casa à distância;

Auxiliar de memória (controlar a toma de medicamentos, etc.);

Apoio a pessoas idosas, doentes ou com deficiências (permitir maior autonomia e

telemedicina);

Entretenimento (Vídeo, áudio e multimédia);

Adequar a iluminação e climatização para as diferentes pessoas;

Ligar luz (por presença, som, hora ou luz ambiente);

Abrir/ fechar persianas (controlo automático por presença de luz ambiente, chuvas e pelo

despertador);

Abertura de portões ou portas por reconhecimento de pessoas ou outros (matrículas, etc.);

Sistema de rega automática;

Comunicações: Proporcionar uma comunicação eficiente com o mundo externo;

Interligar a rede interna de uma casa (domótica, intranet) com a rede externa (por Internet);

Capacidade de controlar algum dispositivo remotamente;

Teletrabalho e Teleformação;

Divulgação das redes domésticas (Home Networks);

Acesso à Internet em banda larga;

Expansão das tecnologias Wireless (IEEE 802.11x, Bluetooth, ZigBee, ...);

Maior largura de banda (rede IP global integrando dados, voz e imagem);

Centralização: ligar/desligar o sistema com um único botão remotamente.

2.4 Protocolos de comunicação

Existe uma grande variedade de protocolos de comunicação para sistemas de domótica.

Todavia, serão enumerados os mais conhecidos com uma breve descrição. Posteriormente, será

feita uma descrição mais exaustiva do protocolo escolhido.

2.4.1 X-10

O X-10 é o protocolo mais antigo usado nas aplicações de domótica. Foi desenvolvido entre

1976 e 1978 com o objetivo de transmitir dados por linhas de baixa tensão (110V nos EUA e 230V na

Europa) a uma velocidade muito baixa (60 bps no EUA e 50 bps na Europa) e com custos muito

baixos. Ao usar as linhas elétricas da habitação, não é necessário instalar nova cablagem para ligar

Erro! A origem da referência não foi encontrada. 7

os dispositivos. O protocolo X-10 é proprietário mas a sua patente já expirou pelo que, atualmente,

qualquer fabricante pode produzir dispositivos X-10 e oferecê-los ao mercado. Graças ao seu

amadurecimento (mais de 30 anos no mercado) e à tecnologia implementada, os produtos X-10 tem

um preço muito competitivo e são líderes no mercado residencial Norte-Americano, podendo as

instalações ser realizadas por eletricistas sem conhecimentos de automação ou informática ou até

pelos próprios utilizadores. O preço e a facilidade de instalação são de facto os principais pontos

fortes desta tecnologia.

Existem três tipos de dispositivos X-10: os que só podem transmitir ordens, conhecidos por

controladores, os que só podem receber ordens conhecido por recetores, e os dispositivos que

podem receber e enviar ordens, que são na prática recetores com capacidade de responder e

confirmar a realização correta de uma ordem (feedback). Os controladores enviam sinais de

comando para os recetores que, por sua vez, fazem atuar o dispositivo elétrico que lhe está ligado.

Os recetores são adaptadores que se instalam entre o dispositivo elétrico que se pretende controlar

e a fonte de corrente elétrica que o alimenta. Os recetores vêm dotados de dois pequenos

comutadores giratórios, um com 16 letras (código da casa) e o outro com 16 números (código do

dispositivo), que permitem identificar um dos 256 endereços possíveis. Numa mesma instalação

pode haver vários recetores configurados com o mesmo endereço, todos realizam a função pré-

designada, desde que um controlador envie um telegrama com o seu endereço de destino. A

pequena gama de endereços existentes nesta tecnologia torna-a inadequada para grandes edifícios,

dado que só permite a existência de 256 dispositivos recetores independentes. Esta é uma

importante limitação relativamente às outras tecnologias existentes. Qualquer ação num sistema X-

10 implica o envio de duas mensagens: mensagem de seleção do dispositivo e mensagem com a

ordem a executar. De forma a minimizar possíveis falhas de comunicação, as mensagens são

enviadas em duplicado. Este protocolo de comunicação torna o envio de comandos para os

dispositivos um processo demasiado moroso, sendo este outro ponto fraco desta tecnologia. Por

outro lado, dado que este protocolo não inclui qualquer controlo sobre a correta receção de

mensagens por parte dos dispositivos recetores, esta tecnologia apresenta um baixo nível de

fiabilidade. Concluindo, a tecnologia X10 é uma tecnologia com bastante sucesso dado o seu baixo

custo e facilidade de instalação. No entanto apresenta bastantes limitações, comparando

nomeadamente com o EIB/KNX. O X-10 é apenas dirigido para pequenos ambientes residenciais

dada a sua incapacidade para suportar muitos dispositivos, e a pouca fiabilidade, robustez e rapidez

do seu protocolo de comunicação.

2.4.2 KNX

KNX - o protocolo KNX foi publicado pela recente Associação KNX em 2002 - é um protocolo de

domótica aberto. Foi desenvolvido por 110 empresas líderes de mercado e assenta num standard

mundial para o controlo de habitações e de edifícios ISO/IEC 14543-3. Aprovado como Norma

Europeia CENELEC EN 50090 e CEN EN 13321-1. Presentemente, existem centenas de fabricantes a

produzir equipamento certificado pela associação Konnex, disponibilizando aos clientes e

instaladores. Com mais variedade e opções para o desenvolvimento de soluções modernas e

competitivas, este protocolo permite ao utilizador o controlo local e remoto das aplicações

existentes na sua instalação. O protocolo KNX é a única norma global para domótica com uma

ferramenta de programação (ETS Engineering Tool Software) e conceção única e independente do

fabricante tem um conjunto vasto de meios de ligação suportados (par entrançado, linha de

potência, RF e IP /Ethernet) e inúmeros modos de configuração suportados.

EIB (European Installation Bus) - Protocolo concebido pela EIBA - European Instalation Bus

Association inicialmente pensado como sistema de gestão de instalações elétricas de edifícios.

8 Introdução

8

LonTalk - Tecnologia LonWorks desenvolvida na Echelon Corporation nos EUA em 1993 como

uma tecnologia de automação distribuída. A maior parte dos sistemas até então desenvolvidos eram

de controlo centralizado. A Echelon desafia essa premissa lançando um conceito inovador que em

1999 é definido como norma (Protocolo LonTalk).

CEBus (Consumer Electronics Bus) - Surgiu em 1984 como standard promovido pela EIA

(Electronic Industries Association).

Batibus – é um protocolo “open-source” dispõe de um sistema de controlo de colisões, baseado

numa hierarquia de prioridades. Nos dispositivos Batibus é possível seleccionar o seu endereço na

rede, à semelhança do Protocolo X-10. Todos os dispositivos escutam todas as mensagens, mas

apenas os invocados as executam.

EHS - o protocolo foi criado em 1992 por uma comissão de grandes empresas europeias de

produção eletrodomésticos. Esta comissão criou este protocolo como um protocolo aberto e com

uma vasta gama de aplicações, permitindo que equipamentos de diferentes fabricantes

comuniquem entre si de forma a que possam partilhar recursos. Hoje em dia já existem produtos

em Hardware e Software standard. As maiores empresas europeias de produção eletrodoméstica já

incluem o protocolo EHS nos seus produtos.

Erro! A origem da referência não foi encontrada. 9

Capítulo 3

Sistemas KNX

3.1 História

O protocolo KNX nasceu do desenvolvimento e da vontade de tornar standard as especificações

de comunicação do antigo protocolo EIB (European Instalation Bus), já anteriormente referido. Este

protocolo resultou da mistura de mais de 15 anos de experiência dos antecessores deste protocolo

( EIB, EHS e BATIBUS) e da união de empresas ligadas ao fabrico de materiais elétricos e eletrónicos

e de eletrodomésticos. KNX é um protocolo que permite ser utilizado em qualquer tipo de sistema:

desde a pequena habitação a grandes condomínios. Este protocolo devido ao seu grande

desenvolvimento permite a monitorização e controlo de sistemas de videovigilância, consumos de

energia, sistemas de iluminação, ar condicionado, contagem, controlo de áudio/vídeo,

aquecimento, ventilação e regularização automática de persianas. Todas estas funções podem ser

controladas, vigiadas e sinalizadas através dum sistema único sem necessidade de centrais de

controlo extra. Todos os componentes do sistema são ligados à rede KNX e as ligações podem ser

feitas por cabo entrançado, infravermelhos, radiofrequência, rede elétrica ou IP/Ethernet. É

através destas ligações que os dispositivos da rede trocam ou fornecem informações. Os dispositivos

ligados através de meios físicos como o par entrançado entre outros, retiram a energia para

funcionar através do barramento e os dispositivos sem ligação física têm fontes de alimentação

adicionais. As figuras seguintes mostram simples sistemas de aplicação do protocolo KNX e a rede

KNX.

Figura 1: Exemplo de sistema de implementação do KNX.

10 Introdução

10

Figura 2: Exemplo de uma Rede KNX.

Uma das grandes vantagens do KNX é possibilitar a construção de um sistema modular, em

qualquer altura do desenvolvimento do sistema ou até depois de implementado haverá a

possibilidade de acrescentar mais dispositivos e funções ao sistema, pois é reconfigurável. Esta

vantagem advém de ser um sistema descentralizado e em que os dispositivos comunicam entre si,

uma vez que podem ser recetores e emissores sem necessidade de hierarquia e/ou supervisão da

rede. Têm apenas de comunicar entre si através de telegramas segundo o formato definido pelo

protocolo. Este tipo de sistema é normalmente controlado por um computador comum, passando

assim a ter uma arquitetura centralizada e podendo ser controlado por outro qualquer sistema com

acesso à Internet. O intuito do desenvolvimento deste protocolo foi aumentar a flexibilidade e as

capacidades dos sistemas com um custo reduzido. Pode-se dizer portanto que os objetivos foram

quase cumpridos. No que toca aos custos e à flexibilidade, não se pode dizer que são dos sistemas

mais baratos e nem dos mais flexíveis. Contudo continua a ter a vantagem de ser um protocolo

aberto, bastante implementado, uma vasta gama de produtos e reconfigurável.

Principais características e vantagens

O protocolo KNX garante que os produtos das mais variadas marcas, quando construídos

segundo as definições do protocolo KNX, conseguem comunicar entre si se estiverem ligados na

mesma rede. Esta característica permite uma enorme flexibilidade para modificação e expansão de

um sistema já existente. A associação KNX exige dos seus representantes e fabricantes um nível

bastante exigente nos desenvolvimentos dos produtos KNX, pois todos os produtos desenvolvidos

pelos membros KNX vão representar a marca KNX. Os produtos KNX têm de cumprir a norma ISO

9001. Os membros da KNX fabricam produtos para todo o tipo de aplicações para o controlo de

edifícios, desde o controlo de iluminação até aos sistemas mais complexos de gestão inteligente de

energia. O protocolo KNX foi desenvolvido para integrar todos os tipos de edifícios: do edifício

antigo ao edifício totalmente construído de raiz sem quaisquer dificuldades de implementação.

Permite também a instalação em edifícios de um piso a edifícios de vários pisos, como hotéis,

shoppings e arranha-céus. Este tipo de implementações é possível devido à grande variedade de

meios físicos de comunicação como par entrançado, a rede elétrica (powerline), infravermelhos,

rádio frequências e IP/Ethernet. Todas estas formas de comunicar permitem ao sistema a facilidade

de se efetuar mudanças, atualizações e expansões sem que se tenha a necessidade de desenhar

novamente o sistema, reconstruir a instalação ou mudanças mais profundas que não as pretendidas.

A associação KNX tem um Software desenvolvido pelos seus membros o ETS (Engineering Tool

Software), que permite a configuração de todos os dispositivos certificados pela KNX

Erro! A origem da referência não foi encontrada. 11

independentemente da sua marca ou fabricante. Este Software possibilita a integração de vários

tipos de produtos numa instalação e possibilita a atualização da base de dados dos diferentes

produtos, descarregando os dados do fabricante do produto com a total garantia de compatibilidade

com o ETS, caso fabricado por um membro KNX. No KNX existem três tipos de configuração: o S-

Mode, o A-Mode e o E-Mode. O A-Mode é o mais simples neste modo de configuração, pois o sistema

configura-se automaticamente. Embora pareça uma vantagem para o sistema, este fica limitado às

configurações automáticas. O E-Mode é efetuado por um controlador de um dispositivo ligado ao

barramento de dados. E o S-Mode é o método de configuração mais poderoso. É realizado através

de um computador com o Software ETS instalado, ligado ao barramento através de um dispositivo

de interface. O modo S destina-se a projetistas e instaladores com certificação KNX e a instalações

de grandes dimensões. As vantagens desta norma face a outras são ter nascido de três normas já

existentes e com bastante experiência no mercado e se basear nas qualidades e vantagens de cada

norma.

Desvantagens

A norma KNX não apresenta grandes desvantagens e podem-se destacar como pontos menos

favoráveis desta tecnologia o preço, uma vez que em relação a outras tecnologias não é muito

convidativo, a instalação e a configuração é mais complexa e o elevado preço do software ETS. As

desvantagens não são muitas mas os preços dos dispositivos e das instalações pesam bastante na

decisão do cliente.

3.2 Arquitectura e Elementos KNX

Modos de configuração

Cada habitação, edifício, condomínio e um outro qualquer sistema KNX tem necessidades e

funcionalidades diferentes. Os sistemas EIB/KNX possuem vários modos de configuração para

satisfazer as diferentes necessidades de configuração dos diferentes dispositivos e utilizadores. Os

diferentes modos de configuração permitem que os fabricantes tenham mais liberdade para inovar e

ao mesmo tempo garantem a inter-funcionalidade entre os diferentes dispositivos. As várias

configurações possíveis de serem executadas poderão e/ou deveram ser alteradas conforme as

necessidades do utilizador, com o auxilio de Software nomeadamente o ETS da KNX. Existem já no

mercado outros Software de configuração de sistemas KNX de outras marcas. A título de exemplo, o

Tebis da Hager. Estas ferramentas acedem às características e configurações possíveis de cada

dispositivo e configuram-no conforme a sua utilidade e funcionalidades pretendidas, garantindo a

inter-funcionalidade no sistema. Os modos de configuração são 3:

O S-mode (System mode);

O A-mode (Automatic mode);

O E-mode (Easy mode) que se divide em duas sub-configuraçoes:

O Controller Mode;

O Push-Button Mode.

De seguida serão explicados de forma sucinta os diferentes modos de configuração dos

dispositivos KNX.

S-mode (System mode), esta forma de configuração do sistema é a mais utilizada e a mais

versátil. Esta está vocacionada para a instalação feita por profissionais, pois necessita da utilização

de Software especializado concebido para esse efeito, como o é caso (ETS). Este modo segue a

mesma filosofia que no EIB e permite que os dispositivos da nova instalação possam ser configurados

12 Introdução

12

conforme a vontade dos clientes e segundo as funcionalidades do dispositivo. Esta configuração terá

de ser efetuada por um computador ligado à rede KNX, tipicamente com o ETS. Para uma

configuração mais completa e abrangente, o ETS usa a informação detalhada de cada dispositivo.

Caso não disponha dessa informação, o configurador poderá importá-la do fabricante. Este Software

permite também atribuir o endereço individual ou de grupo de cada dispositivo (Binding); permite a

parametrização individual de cada dispositivo, de acordo com o datasheet do fabricante

(Parameterisation) e importar e carregar programas dos fabricantes para configurar as mais

diversas funcionalidades de cada dispositivo. Estas configurações são efectuadas através do BCU,

pois é este que faz o controlo de ligação com o módulo de aplicação do dispositivo, cabendo ao

configurador a responsabilidade e decidir a configuração.

E-mode (Easy mode) nesta configuração, os dispositivos como já vêm da fábrica programados

para realizar uma determinada função, não necessitam de um computador com o ETS para a

configuração da rede. Contudo oferece funções mais limitadas. Alguns detalhes podem e devem ser

configurados pelo instalador de acordo com a instalação pretendida. Essas alterações poderão ser

efetuadas através do uso de um controlador ou através de micro interruptores. Neste modo, as

propriedades dos dispositivos ligados na rede podem ser lidas através do barramento, sem haver a

necessidade da base de dados do fabricante com as propriedades do produto. Este modo de

configuração está dividido em outros dois modos, o easy controller mode e o easy push-button

mode.

Easy Controller Mode: neste modo, uma instalação precisa de definir um dispositivo como

controlador, que suportará o processo de configuração. Esta configuração suporta um número de

dispositivos limitado em cada segmento. Um controlador pode suportar uma ou mais configurações.

Contudo está limitado, pois não possui os detalhes das bases de dados dos fabricantes como no ETS,

visto não possuir memória para os guardar. Após a configuração, o controlador deverá continuar

ligado à rede salvo algumas exceções. O controlador pode ser dinamicamente configurado, pode

criar grupos de objetos para determinadas funções, definir endereços físicos e de grupo e

parâmetros de funcionamento. Ao controlador cabe ler as diferentes funcionalidades de cada

dispositivo e mediante as instruções do instalador configurar os diferentes endereços individuais de

cada dispositivo, as ligações a definir entre os mesmos e parâmetros de funcionamento.

Easy Push-button Mode: ao contrário do modo controller não é necessário o uso de

controlador, embora não permita um elevado número de dispositivos num segmento de rede. Cada

dispositivo pertencente à rede deverá possuir a possibilidade de autoconfigurar a sua aplicação,

definir o seu endereço físico e de grupo e definir os parâmetros necessários ao seu funcionamento.

A troca de parâmetros com outros dispositivos também é possível, no entanto a configuração é

essencialmente local. Aquando da configuração, o instalador designa sucessivamente os

dispositivos, cujas funções vão ser interligadas de acordo com as especificações de cada fabricante.

A troca de dados de configuração entre os dispositivos, tipicamente sensores e atuadores, ocorrem

através de um serviço da camada de aplicação. Aos dispositivos emissores, cabem apenas definir o

seu endereço de grupo único e informar depois os dispositivos a controlar o seu endereço.

A-mode (Automatic mode): este modo de configuração é o mais simples, pois é automático.

Contudo é também o mais limitado. Este modo pode ser configurado por um utilizador sem

conhecimentos sobre EIB/KNX e segue uma metodologia Plug&Play, pois os dispositivos possuem a

capacidade de localizar outros dispositivos, definir interoperações e adquirir os seus próprios

endereços físicos. Neste modo de configuração, os dispositivos são direcionados geralmente para

uma única aplicação que contém o seu próprio controlador de aplicação, sendo este também o

configurador Master para a aplicação. A este cabe a configuração dos endereços de grupo. Este

modo será especialmente indicado para ser usado em eletrodomésticos e equipamentos de

entretenimento (consolas, boxes, áudio e vídeo, etc.). A facilidade deste modo reside no facto de

Erro! A origem da referência não foi encontrada. 13

que nem o instalador nem o utilizador final têm de configurar qualquer dispositivo introduzido. A

figura 2 mostra-nos os três modos de configuração fundamentais do KNX.

Figura 3: Modos de configuração do KNX.

Tipos de implementação

Os sistemas de domótica têm dois tipos de implementação fundamentais: o Power Line Carrier

e Barramento/cablagem dedicada. A implementação Power Line Carrier (PLC) é a solução de mais

baixo custo, pois faz uso da rede elétrica do edifício para a transmissão de dados entre os

dispositivos que compõem o sistema. A implementação barramento/cablagem dedicada é uma

solução mais dispendiosa, devido à necessidade de instalação de cablagem extra durante a

construção. Atualmente, devido à regulação do sector das telecomunicações, a ANACOM define que

a instalação de infraestruturas de telecomunicações em edifícios, incluindo a respetiva ligação às

redes públicas (ITED) como obrigatória. Assim sendo, e como essa cablagem inclui cabos para o uso

de sistemas de domótica, este tipo de implementação fica um pouco mais acessível. Além da

comunicação por cabo a comunicação entre dispositivos do sistema, pode ainda ser feita por Rádio

Frequências, Infravermelhos, Bluetooth, Zigbee e fibra ótica.

Dispositivos

Os dispositivos KNX têm uma arquitetura que se divide em três grandes tipos: os componentes

básicos, os componentes de sistema e os orientados para aplicações. Os componentes básicos são

componentes que não entrevem no funcionamento do sistema e não têm parte ativa no sistema.

Exemplos de componentes básicos são: fontes de alimentação, filtros de sinal, etc. Os componentes

de sistema permitem a criação de uma rede são eles acopladores de BUS (BCU – Bus Coupling Unit),

Acopladores de Linha (LC – Line Coupler), Acopladores de Fase, repetidores, etc. Os componentes

orientados para as aplicações são componentes que entrevem diretamente no funcionamento do

sistema, são eles sensores, atuadores, Recetores de IR, painéis de comando essencialmente

atuadores, sensores e controladores. Estes dispositivos são ligados à rede através de um Acoplador

de Bus ou de uma interface similar. Os dispositivos são constituídos por:

Uma unidade de acoplamento ao barramento (BCU);

Um módulo de aplicação (AM);

14 Introdução

14

Um programa de aplicação (AP).

A unidade de acoplamento e o módulo de aplicação podem ser vendidos em conjunto

integrados num só ou ser vendidos em separado. Quando vendidos em separado devem ser

interligados por uma interface física externa (PEI - Physical External Interface). Existem no

mercado interfaces físicas externas de 10 e de 12 pinos, estas interfaces são utilizadas para troca

de mensagens entre os dispositivos e como fonte de alimentação para o módulo de aplicação. A

figura 4 descreve a constituição de um dispositivo:

Figura 4: Estrutura de um dispositivo KNX.

Acopladores

Os acopladores são componentes de sistemas KNX que têm como objetivo ligar diferentes

áreas, linhas e funcionar como repetidores. Os acopladores de bus podem funcionar como

dispositivos independentes ou estarem integrados em outros dispositivos orientados à aplicação

quando funcionam como independentes, os módulos de aplicação usam-nos para se ligarem a rede.

O módulo e o acoplador devem ser do mesmo fabricante para tornar mais fiável o seu

funcionamento. È nos interruptores tácteis onde normalmente se encontra separado o BCU do

módulo da aplicação (AM), o BCU é normalmente embutido nas paredes. Há também dispositivos

orientados à aplicação que tem acopladores. Quando o BCU faz parte do dispositivo, vem

normalmente integrado no dispositivo através de módulo de Interface como Barramento (BIM - Bus

Interface Module) ou através de um Chip set do próprio fabricante, substituindo PEI. Os tipos

acopladores são:

O Acoplador de Área (AA) que é um dispositivo que interliga a linha de área à Linha

Principal;

O Acoplador de Linha (AL) que é um dispositivo que interliga a linha principal a uma linha

secundária;

O Repetidor de Linha (RP) é um dispositivo que permite expandir um segmento de linha

possibilitando inserir mais 64 dispositivos ou poder expandir o cabo de transmissão de dados em

mais 1.000 m.

Erro! A origem da referência não foi encontrada. 15

Quando um acoplador de área ou de linha é utilizado, estamos a construir uma tabela de

filtragem, pois os telegramas só são encaminhados pelo acoplador para os dispositivos, se estiverem

registados na tabela de filtragem. O repetidor tem como função a repetição de um sinal nas redes

par entrançado regenerando os sinais elétricos, permitindo aumentar o comprimento das linhas e

unir segmentos de redes extensas quando necessário. A título de exemplo em grandes edifícios.

BCU (Bus Coupling Units)

Os BCU são disponibilizados para dois tipos de meios são eles o par entrançado (Twisted Pair) e

Linha de Potência (Power Line), ainda não existem para rádio frequências. Só existem soluções RF

integradas, ou seja, cada dispositivo tem a sua própria inteligência devido ao BCU, daí o KNX ser um

sistema descentralizado não necessitando de uma unidade central de processamento. As funções

centrais como a supervisão podem contudo ser implementadas, através de painéis tácteis ou

Software de Supervisão instalados em PC, através de página Web e aplicações Android. Os

dispositivos KNX podem ser divididos em três classes: sensores, atuadores e controladores. Os

sensores são dispositivos que fazem medições, leituras e enviam os dados para o BCU. O BCU

verifica o estado do módulo de aplicação, procurando constantemente no PEI variações de sinal, se

for detetada alguma alteração envia um telegrama para o barramento KNX. O telegrama é a

codificação da informação a ser transmitida, segundo o protocolo KNX. Os atuadores são dispositivos

que recebem telegramas e agem segundo o que lhes foi ordenado. Ao receber o telegrama o BCU

descodifica e envia essa informação ao módulo de aplicação (AM) que agirá mediante a informação

descodificada. Os controladores são dispositivos que ditam o funcionamento dos sensores e

atuadores. Estes recebem as suas funções quando o programa de aplicação adequado for carregado

para o BCU através do ETS. O BCU é constituído por duas partes: um controlador (BCC) e um

transceiver (TRC) adequado ao meio de transmissão que é possível visionar na figura 5.

Figura 5: Arquitetura de um BCU.

O módulo controlador (BCC) possui um microprocessador que faz a comunicação entre a

interface externa (PEI) e um sistema operativo que pode executar um programa de controlo do

dispositivo para a gestão do mesmo. Os diferentes tipos de memória internos do microprocessador

guardam os dados do Software do sistema na memória ROM, valores temporários do sistema e da

aplicação na RAM e o programa de aplicação e endereços na memória flash e ou EEPROM. O BCC

organiza e controla o acesso ao barramento, faz a gestão, codificação e descodificação dos

telegramas, a deteção de problemas na transmissão de dados, o controlo de repetição de

transmissões, fornece sinais de controlo e controla as funções das aplicações. O módulo transceiver

(TRC) tem a função de separar os dados, da alimentação, monitorização da temperatura, regular a

tensão a 5V e 24V, proteção contra polaridade invertida, proteger os dados se tensão baixar dos

18V, desligar o micro se a tensão for inferior a 4,5V.

16 Introdução

16

Figura 6: Arquitectura de um TRC..

PEI (Physical External Interface)

O PEI tem como objetivo a comunicação entre o meio físico BCU e a camada de aplicação e possui

especificações elétricas/mecânicas e de Software que permitem efetuar o acesso ao bus de dados.

O acesso ao meio e transmissão de dados pode ser feito por transmissão série ou paralelo, o

conector de ligação (elétrica/mecânica) deste ao BCU possui duas versões: de 10 pinos e de 12

pinos. Através de uma interface paralela PEI I/O, os valores de input e output podem ser acedidos

pela aplicação interna do BAU (Bus Access Unit). Por seu lado, na comunicação série PEI entre o

BAU e a aplicação, o módulo aplicação é o responsável pela leitura e escrita dos valores de entrada

e saida. Exemplos de comunicação deste tipo: a comunicação de um PC (com software ETS) no

processo de configuração de um dispositivo ou da rede através da rede e um dispositivo que tenha

dados que possam ser lidos e escritos por um outro dispositivo. O diagrama de pinos do PEI (figura

7) permite verificar o que até então foi explicado e perceber o que são os diferentes termos.

Figura 7: Diagrama de pinos do PEI.

Erro! A origem da referência não foi encontrada. 17

As diferentes ligações foram criadas devido à possibilidade de variação das resistências entre

os pinos 5 (Vcc) e 6 (type), com isso possibilitando a criação de 21 tipos, os quais são agrupados em

quatro grandes grupos:

Utilizações especiais;

Reservados para futuras extensões;

Comunicações em Paralelo;

Comunicações em Série.

As configurações do tipo utilizações especiais são:

PEI tipo 0 – é conseguida sem resistência entre os pinos 5 e 6, esta foi concebida para se

utilizar em aplicações onde não existe nenhum adaptador;

PEI tipo 1 – este tipo de configuração é utilizado quando não existe qualquer tipo definido

ou enquanto o tipo de PEI atribuído ainda não foi inicializado;

PEI tipo 20 – este tipo de PEI è destinado ao fabricante para fazer o download de

configurações para a unidade que contém o interface físico (BCU, BIM- Bus Interface Modules,…).

Os PEI reservados para futuras extensões são os tipos guardados para futuras necessidades ou

desenvolvimentos do protocolo KNX, são eles: 3, 5, 7, 9, 11, 13, 15, 18.

Os PEI para comunicações em Paralelo são: 2, 4, 6, 8, 17 e 19.

Os PEI para comunicações em Série são: 10, 12, 14 e 16 cada um suporta diferentes versões do

protocolo de comunicação (síncrona e a assíncrona). A comunicação assíncrona é garantida pelo

tipo 10 e 16. A comunicação síncrona é garantida pelo tipo 12 e 14. O tipo 12 implementa

comunicação síncrona com interface de mensagens, como foi dito anteriormente o tipo 14 suporta

também comunicação síncrona mas este com interface de blocos. O PEI tipo 10 implementa

comunicação assíncrona assim como o PEI do tipo 16. Contudo, este possui o seu protocolo para

interagir com o módulo de aplicação e o BCU. Nos sistemas EIB/KNX não têm de existir por

definição um PEI (Physical External Interface), garantindo assim outras formas e possibilidades de

comunicação entre o módulo de aplicação e o BCU, como por exemplo na utilização de memória

RAM partilhada ou qualquer outro protocolo que não tenha por base a interface PEI. E como já

referido existem dispositivos que têm o BCU e o módulo de aplicação em um dispositivo.

3.3 Rede KNX e Endereçamento

Topologia da Rede KNX

O KNX é definido como uma rede totalmente distribuída, pois não necessita de um controlador

central na instalação visto todos os dispositivos possuírem o seu próprio microprocessador e a

implementação do protocolo de comunicação KNX de acesso ao meio. Quando ligados a um

barramento de comunicação de dados funcionam como recetores e emissores, dispensando assim

um controlador central. Como já referido anteriormente, o KNX suporta diferentes meios físicos de

comunicação: o par entrançado, a rede elétrica (powerline), os infravermelhos e rádio frequências.

O KNX não possui uma topologia física definida para sua implementação. Num sistema KNX pode

existir uma mistura das topologias físicas ou só uma das topologias. As topologias físicas base: em

estrela, em anel, linear e em árvore. Existe ainda a possibilidade de as combinar numa topologia

mista. Estas topologias são constituídas por vários dispositivos e secções definidas pelos diferentes

cabos individuais que podem ser tão longos quanto o permitido pelos requisitos elétricos.

18 Introdução

18

A figura 8 é uma representação das diferentes topologias físicas base, muitas mais podem ser

conseguidas através destas topologias físicas base.

Figura 8: Tipos de redes KNX.

Em cada segmento (ramo) o KNX define um máximo de 64 dispositivos, dois quaisquer

segmentos podem ser ligados por um repetidor ficando com a designação de linhas. Uma linha pode

conter um máximo de quatro segmentos interligados por repetidores, ficando assim com uma

capacidade de até 255 dispositivos. À linha de bus principal é permitido conectar um maximo 15

linhas secundárias utilizando os acopladores de linha. O uso de mais que um segmento só será

aceitável para o aumento de capacidade de instalação do sistema. Quando o edifício a instalar está

separado por pisos e ou dá mais jeito dividir em subsistemas o sistema será dividido por áreas. Uma

área pode possuir até um máximo de 15 linhas e um sistema poderá ter até 15 áreas o que dá um

máximo de 225 linhas por sistema. As diferentes áreas têm de ser ligadas à linha principal através

de um acoplador de área (AA). Cada linha deve ter a sua própria fonte de alimentação, possuir até

6 controladores de linha (i.e. acopladores de linha, acopladores de área e repetidores) em cada

caminho de transmissão. Os repetidores de linhas não podem ser utilizados em linhas de área e

linhas principais. É possível utilizar dispositivos nas linhas de área e principal. Contudo, o número

de dispositivos que podemos utilizar decresce com os acopladores de área usados. Se não se

recorrer a repetidores podemos conseguir a instalação de até 15.153 dispositivos, se forem

utilizados repetidores podemos atingir os 61 233 dispositivos. A figura 9 mostra uma topologia

possível de um sistema KNX e a representação de alguns termos mencionados anteriormente:

Erro! A origem da referência não foi encontrada. 19

Figura 9: Topologia genérica de um sistema KNX.

Endereçamento

Endereçamento Individual

O endereço individual define o endereço de comunicação para um dispositivo e como o próprio

nome indica é único. Todos os dispositivos num sistema KNX possuem um endereço individual, pois é

para este que lhe vão ser enviadas mensagens. Este funciona para o dispositivo como a impressão

digital para um ser humano. Os endereços são baseados na área e linha onde se inserem e no seu

endereço do dispositivo nessa mesma linha. Um endereço individual definido por:

Área:

Numa área o endereço irá de 1 a 15;

O endereço 0 é reservado para o dispositivo na linha de área;

Linha:

Numa linha o endereço irá de 1 a 15 numa determinada área;

O endereço 0 é reservado para os dispositivos na linha principal;

Dispositivo:

Numa linha o dispositivo poderá ter um endereço de 1 a 255;

O endereço 0 é reservado para o acoplador de linha.

Os dispositivos quando saem de fábrica vêm com o endereço 15.15.255. Este endereço terá de

ser modificado pelo ETS ou será modificado quando programado automaticamente no A-Mode. A

figura 10 ilustra a organização dos endereços individuais.

20 Introdução

20

Figura 10: Endereços individuais do protocolo KNX.

Endereçamento de Grupo

O endereçamento de grupo é feito para um determinado conjunto de dispositivos (grupo). Cada

endereço pode ser atribuído a qualquer dispositivo numa qualquer linha. Ao atribuir um endereço

de grupo a vários dispositivos, eles podem ser endereçados ao mesmo tempo através de um único

telegrama. Um dispositivo de grupo atuador pode responder a vários endereços de grupo. Já um

sensor só envia a um endereço de grupo. A figura 11 ilustra uma atribuição de endereços de grupo e

como é constituído:

Figura 11: Endereços de grupo no protocolo KNX.

Telegrama KNX

O telegrama KNX é uma mensagem que pode ser enviada entre dispositivos na rede KNX. Nesta

rede, as mensagens enviadas terão de possuir as características definidas pelo protocolo. Antes de

enviar uma mensagem, o dispositivo emissor deve escutar a rede verificando se está desocupada. Se

estiver desocupada, poderá enviar a mensagem; se estiver ocupada, espera e vai escutando a rede

até ficar desocupada. Quando desocupada, espera que o tempo t1 (t1 =50bits) seja ultrapassado. De

seguida envia o telegrama. O telegrama possui um campo que define a prioridade. Se ao enviar um

telegrama, um dispositivo de maior prioridade transmitir um outro, o de menor deixará de

Erro! A origem da referência não foi encontrada. 21

transmitir. A deteção é feita porque o dispositivo enquanto transmite continua a ouvir a rede para

conseguir detetar colisões com outras transmissões. Quando o dispositivo de mais alta prioridade

parar de transmitir o dispositivo de menor prioridade volta a transmitir o telegrama. Este método

de funcionamento é definido no protocolo CSMA/CA (Carrier Sense Multiple Access with Collision

Avoidance). Após o envio da mensagem, o dispositivo espera um tempo t2 (t2=13bits) para receber

a confirmação de que a mensagem foi recebida com sucesso, senão repete-a um determinado

número de vezes. O telegrama de grupo é enviado ao mesmo tempo para todos os dispositivos a que

se destinam. Os telegramas são enviados de forma assíncrona. Contudo são enviados bits de início

antes do primeiro carácter e no fim um bit de finalização do telegrama para sincronizar os

participantes. Cada carácter enviado é um byte (bits) de informação. O telegrama é enviado a uma

taxa de transmissão de 9600 bits/s, demorando aproximadamente 104μs por bit. O período entre

um carácter e outro é de 13 bits, ou seja, 1,35ms. Cada telegrama pode possuir entre 8 e 23

caracteres de tamanho. O conhecimento da receção de um telegrama é efetuado por apenas um

carácter de reconhecimento. Com todos estes requisitos, um telegrama ocupa a linha por um tempo

de 20 a 40 ms. Os telegramas mais comuns ocupam o bus aproximadamente 20 ms. A figura 13

demonstra visualmente o que foi até então explicado:

Figura 12: Características de um telegrama KNX.

Um telegrama é informação específica de uma rede e para essa rede e fornece os dados e

ordens para o bom funcionamento da mesma. Um telegrama possui um campo que define a

prioridade de uma mensagem que é o campo do controlo; possui o endereço de origem e destino;

um campo contador e de comprimento; um campo de dados e um campo de verificação. O campo

de controlo é um campo de oito bits que define a prioridade dos telegramas entre os vários

dispositivos. Permite a escolha da repetição de um telegrama se não for confirmado pelo dispositivo

que o recebe. Os oito bits começam com D7 e acaba em D0 como podemos verificar pela figura 14:

22 Introdução

22

Figura 13: Características do campo de controlo de um telegrama KNX..

Os bits que sofrem alteração e que podem alterar o funcionamento do sistema são os bits D3 e

D2 e D5. Podemos verificar na figura 14 que para os diferentes tipos de funcionamento existem

diferentes tipos de prioridade. Quando os bits D3D2 estão 0 prioridade é máxima e mínima quando

estão a 1 (prioridade de serviço baixa). A prioridade da transmissão é apenas levada em conta

existirem 2 ou mais dispositivos a transmitirem em simultâneo. Quando o telegrama é enviado e o

emissor não recebe a confirmação, o bit D5 será alterado para 0 e o telegrama será novamente

enviado, garantindo assim que caso o destinatário tenha executado o comando não o volte a

executar. Saberá que é uma repetição de um comando, porque o bit D5 estará a zero. Neste caso é

assegurado que o participante que já tenha executado o respetivo comando não o repita

novamente. Os restantes bits podem ser alterados pelo Software ETS, segundo as necessidades do

utilizador e do sistema.

O campo dos endereços incluiu o endereço de origem e o de destino; o de origem possui 16

bits, o de destino tem mais um bit para definir o tipo de endereçamento. O endereço de origem

pertence ao dispositivo que envia o comando, isto para que o dispositivo de destino saiba quem lhe

envia o comando. O endereço de destino garante que o comando é recebido pelo(s) dispositivo(s) a

que é destinado. Este é normalmente um endereço de grupo, com um número elevado de

participantes que podem ser endereçados simultaneamente. O endereço pode também ser

individual, este é normalmente utilizado no modo de inicialização do sistema, programação e

diagnóstico.

A informação do endereço de destino é transmitida com 17 bits para que o recetor, consiga

partir do bit D7 saber de que tipo de endereço de destino (grupo, individual). Como poderemos

verificar na figura 15. As imagens ilustram os bits que constituem os diferentes endereços e os tipos

de endereçamento.

Figura 14: Endereço individual.

Os quatro bits mais à esquerda definem a área. Os quatro bits seguintes definem uma linha e os

últimos 8bits à direita definem o dispositivo do qual o comando é enviado.

Erro! A origem da referência não foi encontrada. 23

Figura 15: Endereços de grupo de dois e três níveis.

Figura 16: Características do campo de controlo de um telegrama KNX.

Na figura 16 podemos ver que os 4 bits de A3 a A0 definem a área de destino, os 4 bits

seguintes de L3 a L0 a linha, os oito bits de P7 a P0 o endereço do dispositivo de destino e o último

bit o tipo de endereço. No endereçamento de grupo os quatro bits de P3 a P0 indicam o endereço

do grupo principal, os três bits de I2 a I0 o endereço do grupo intermédio, os 8 bits seguintes o

subgrupo e o bit mais a direita a 1 para indicar que é um endereço de grupo de três níveis.

O campo contador e comprimento contêm um campo inicializado com o valor 6, que é o

número de vezes que pode passar por um Router. A cada passagem por um acoplador de linha é

decrementado e retransmite, enquanto o valor for positivo. As tabelas de filtragem são também

tidas sempre em linha de conta. Este campo cede um bit ao endereço de destino; o bit D7 mais a

esquerda que define o tipo de endereço (individual ou de grupo). Os 3 bits seguintes de R2 a R0

representam o contador e os 4 bits mais a direita de L3 a L0 definem o comprimento do campo dos

dados. A figura 17 confirma e representa o que foi dito sobre o campo contador.

Figura 17: Campo contador.

O campo dos dados é constituído normalmente por 2 bytes (16 bits), este na generalidade

apenas utiliza um bit para activação (1) ou desactivação (0) de dispositivos. A informação no campo

dos dados pode ter um comprimento de 1 bit até 13 Bytes (Byte 2 a 15), esta depende do tipo de EIS

(EIB Interworking Standard).

24 Introdução

24

Quando é feito um pedido para "ler" é solicitado ao dispositivo que recebe o telegrama um

aviso do seu estado que pode ser uma confirmação curta ou longa.

Figura 18: Campo de dados.

A ordem (as funções a executar) é definida pelos 4 bits BBBB acima representados: a escrita

(0010), a leitura (0000), a confirmação curta (0001) e a confirmação longa (0001). Os restantes

bytes são parâmetros que podem ser a confirmação, dados ou não serão utilizados dependendo do

tipo de dados a enviar.

O campo de verificação permite verificar se o telegrama chega ao seu destino corretamente. A

verificação do carácter faz a soma dos bits de dados (D7 a D0) e de Pz. Essa soma tem de dar 0,

caso contrário a mensagem está corrompida (confirmação por paridade par). A Verificação de

Telegrama analisa a posição dos bits de todos os caracteres por prioridade, isto é, o bit de

verificação S7 recebe o valor “0” ou “1” para fazer a soma de todos os bits de dados D7 mais os bits

de verificação S7 iguais a 1. A combinação da verificação dos caracteres e do telegrama é chamada

Verificação Cruzada. A figura 19 representa o que foi explicado.

Figura 19: Campo de verificação cruzada.

Quando um receptor recebe um telegrama e foi efectuada a correcta recepção do mesmo,

deve enviar um aviso como confirmação correspondente uma mensagem de reconhecimento. Se o

dispositivo de origem receber um reconhecimento NAK (recepção incorrecta), o dispositivo de

origem envia um novo telegrama que poderá ser repetido até três vezes. Caso receba um

reconhecimento BUSY (linha de bus ocupada), o emissor aguarda um intervalo antes de repetir o

telegrama. Se o emissor não receber a mensagem de reconhecimento, irá terminar a transmissão.

No caso de a mensagem estar correcta o receptor envia um reconhecimento ACK. A figura 20 mostra

a estrutura da mensagem de reconhecimento.

Figura 20: Estrutura de uma mensagem de confirmação.

Erro! A origem da referência não foi encontrada. 25

Esta é a constituição de um telegrama utilizado para comunicar e gerir um sistema de

domótica através do protocolo KNX.

3.4 Gateway IP / Bus KNX

As Gateways têm como função a interligação de um sistema de domótica a outros sistemas e

meios em qualquer nível. Com o crescer do número de edifícios, com aplicações de domótica e a

evolução das tecnologias de comunicação, começa a fazer cada vez mais sentido a utilização deste

tipo de solução, devido às dimensões dos projetos e as tecnologias e funções a implementar no

sistema. Um dos principais motivos para a interligação de sistemas através de Gateways é o

crescente aumento de dispositivos e o volume de telegramas que implica a interação entre os

mesmos. O congestionamento da rede pode acontecer devido ao sistema possuir dispositivos que

enviem constantemente o seu estado ou informações. Numa topologia par entrançado poderá

sobrecarregar facilmente a linha, devido à sua baixa velocidade de transmissão: aproximadamente

9.6 kbit/s. Esta situação poderá ser ultrapassada usando uma rede IP, utilizando acopladores IP nas

linhas principais e de área. A rede Ethernet é pelo menos 1000 vezes mais rápida que a de par

entrançado. As Gateways podem funcionar como acopladores IP/KNX e também para configuração

ou programação remotamente através da rede IP. A interligação em paralelo de várias linhas não

serão mais problema com as Gateways. Esta comunicação tem o nome Tunnelling consiste em criar

um túnel IP, entre um cliente KNXnet/IP e um servidor KNXnet/IP por onde são trocadas tramas

KNX. Em linhas individuais KNX, a comunicação terá de ser assegurada por uma Gateway Router

IP/KNX. A este tipo de comunicação dá-se o nome de Routing esta é utilizado para efetuar o

encaminhamento de tramas pela rede KNX. O princípio de funcionamento de um Router IP/KNX é

muito parecido com o das linhas principais de par entrançado: se precisar de enviar um telegrama

entre linhas, fá-lo através de um endereçamento Multicast sobre a rede Ethernet. Os Router IP/KNX

endereçados com este tipo de endereçamento são capazes de receber e avaliar o telegrama. O

Router ao filtrar os telegramas faz o seu roteamento, ou seja, faz o mesmo que o acoplador de

linha faz quando usa as tabelas de filtragem, resultando assim no encaminhamento ou bloqueio dos

telegramas. Assim como acoplador de linha de par entrançado, o Router pode ser utilizado como

acoplador de linha e de área. Topologias físicas possíveis com Routers IP/KNX:

Caso 1, a linha de área passa a ser uma rede LAN;

Caso 2, todas as linhas principais e também a linha de área são substituídas por uma rede

Ethernet;

Caso 3, é uma mistura do caso 1 e 2. A linha de área em par entrançado, um Router IP/KNX

no topo e por cada linha um Routers IP/KNX em vez de acopladores de linha.

A alta taxa transmissão de bits da rede Ethernet facilita muito o tráfego de telegramas e

minimiza as suas perdas. Contudo, deverá ser feita uma gestão de tráfego, evitar o envio de

telegramas a alta frequência e o envio simultâneo das várias linhas para uma única linha. As

imagens na figura 21 representam alguns dos diferentes tipos de montagem utilizando Routers

IP/KNX:

26 Introdução

26

Figura 21: Montagens com routers IP/KNX.

Troca de Dados e Interfuncionamento

A troca de dados entre os vários dispositivos e o interfuncionamento permite-lhes que

comuniquem entre si, executem comandos e partilhem informação necessária ao funcionamento do

sistema. A título de exemplo, a comunicação entre um sensor (comando de um ar condicionado) e

um atuador (um ar condicionado), é constituída por uma sequência de operações que poderemos

ver na ilustração da figura 22. O exemplo é de um interruptor e uma lâmpada que em tudo se

assemelha ao exemplo dado anteriormente:

Erro! A origem da referência não foi encontrada. 27

Figura 22: Exemplo de comunicação entre um interruptor e uma lâmpada.

Os dispositivos físicos da figura 22 representados possuem um endereço único, a comunicação é

feita por endereçamento individual quando só uma lâmpada ou por endereçamento de grupo

quando se trata de várias. Através do protocolo KNX, um dispositivo poderá comunicar com vários

outros dispositivos que pertençam a um grupo através de um endereçamento de grupo e de um

simples comando. Não existe a necessidade de se enviar um comando para cada dispositivo. A

transmissão de informação baseia-se na troca de dados codificados, que apenas podem fazer o

endereçamento da mensagem para um único grupo por mensagem ou para um único dispositivo. Já

o recetor poderá subscrever vários endereços de grupo, que permitirá que seja controlado por

vários emissores. Uma mensagem enviada para um determinado grupo será recebida e interpretada

pelos vários recetores que o constituem e que subscrevem esse endereço de grupo. O

interfuncionamento está dividido em vários patamares de uma pirâmide que determina os vários

graus de interfuncionamento. Um comando é inicialmente um telegrama a transmitir e depois acaba

como ações executadas por um ou vários atuadores. Este processo é muito semelhante à troca de

correio, representado na figura 22, em que os objetos representam a caixa de correio e a Acão a

tomar a mensagem que está escrita na carta. A figura 23 ilustra e define os vários tipos de

interfuncionamentos e suas funcionalidades:

28 Introdução

28

Figura 23: Pirâmide de inter-funcionamento.

O patamar inicial (Formato Comum) é a base do inter-funcionamento. Garante a troca de

informação com o mesmo tipo de codificação em todas de mensagens trocadas entre os dispositivos.

O segundo patamar (mesma interpretação) garante que os dispositivos receptores iram interpretar a

mensagem da mesma forma e segundo a interpretação desejada e efectuada pelo emissor usando

uma semântica comum. O terceiro patamar (funções comuns) garante que os vários constituintes

partilhem as mesmas funções, garantindo assim que para um mesmo objectivo os diferentes

dispositivos irão utilizar as mesmas funções e regras para chegar às acções desejadas. O patamar de

topo (mesmas funcionalidades) é alcançado a partir da junção dos vários patamares da pirâmide de

inter-funcionamento, reunindo as funções comuns, garantindo a mesma interpretação e num

formato comum a todos os dispositivos. A título de exemplo, se um interruptor pretender desligar

uma lâmpada terá de enviar uma mensagem à lâmpada para a desligar. Esta terá de perceber o que

o interruptor escreveu e conhecer a função desligar. O topo da pirâmide garante que para um

qualquer dispositivo, a função desligar será interpretada da mesma forma. Para garantir o inter-

funcionamento entre os vários dispositivos foram definidas normas, o EIS (EIB Interworking

Standards), através das quais devem ser criadas e programadas as aplicações. Os diferentes tipos de

dispositivos e as diferentes marcas devem garantir entre si a comunicação e interpretação da

mesma forma e as mesmas funções. Com esse intuito, foram criados vários tipos de funções tipo

que estão definidos na norma EIS e se pode ver na figura 24. Estas funções standard são chamadas

EIB functions:

Erro! A origem da referência não foi encontrada. 29

Figura 24: Funções EIB.

O nome das EIB-functions está relacionado com a primeira aplicação para que foram

concebidas. Contudo podem ser usadas noutras aplicações. A título de exemplo, a função Dimming

foi inicialmente concebida para variar a intensidade da iluminação e é também hoje utilizada para

a regulação de aquecimento, assim como em vários outros tipos de utilização. Estas funções base

podem constituir outras funções ligeiramente diferentes ou completamente diferentes, permitindo

assim através destas conceber as mais variadas funções de um sistema de domótica. Serão

apresentadas e explicadas as diferentes funções disponibilizadas pelas normas EIS:

A função EIB EIS 1 (“Switching”) é usada para a comutação de cargas ligadas a um atuador

que permitirá: operações on/off, operações lógicas ativo/desativo, sinalização verdadeiro/falso,

alarme, etc. servindo na sua essência para ativar ou descativar um dispositivo;

A função EIB EIS 2 (“dimming”) consiste na união de três outras funções: a de control

(dimming relativo), a de value (demming absoluto) e a de position (comutação on/off e estado). A

função position permite ligar/desligar o dispositivo. A função control é usada para aumentar ou

diminuir o valor a atuar, permitindo também a comutação on/off do atuador. Por fim, a função

value permite a atribuição de um valor através de um byte igual à função EIS 6. A figura 25

exemplifica de forma clara e concisa o funcionamento da função dimming.

Figura 25: Função EIB2 (dimming).

30 Introdução

30

A função EIB EIS 3 (“Time”) fornece as horas em tempo real a qualquer dispositivo que

forneça e necessite deste tipo de informação, a informação será enviada no formato

horas/minutos/segundos;

A função EIB EIS 4 (“Date”) fornece a data a qualquer dispositivo que forneça e necessite

deste tipo de informação, a informação será enviada no formato dia/mês/ano;

A função EIB EIS 5 (“Value”) é usada para transmitir dados que representam valores físicos

numa variável de 2bytes. O valor é obtido através da formula [ (-1)S * (0.01M) *2E ] onde “S” é o

sinal, “E” é o expoente na base dois com 4 bits e “M” representa a mantissa em complemento para

dois de 11bits, o valor (value) poderá variar de -671.088.64 a +670 760.96;

A função EIB EIS 6 (“Scaling”) serve para enviar valores relativos de oito bits, normalmente

utilizado para valores percentuais.

A função EIB EIS 7 (“Control Drive”) é constituída por duas outras sub-funções: elas as

funções move e step. A função move serve para pôr por exemplo um motor de um estore a

funcionar ou mudar de sentido de rotação. A função step serve para fazer movimentos graduais ou

ordenar a paragem de um dispositivo.

As funções EIB EIS 8 (“Priority”) são constituídas por duas sub-funções: a função

EIS_priority_position e a função EIS_priority_control. A sub-função EIS_priority_position permite a

comutação para o estado on/off supervisionada pela função EIS_priority_control. Se a entrada

control estiver activa a função EIS_priority_control controla a saída, caso contrário a saída é

controlada pela função EIS_priority_position. Como podemos verificar na figura 26.

Figura 26: Função EIB2 (Priority).

A função EIB EIS 9 (“Float value”) é utilizada para enviar valores físicos no formato de

vírgula flutuante IEEE, usando 4 bytes.

A função EIB EIS 10 (“16-bit Counter Value”) é usada para representar um contador de 16

bits.

A função EIB EIS 11 (“32-bit Counter Value”) é usada para representar um contador de 32

bits.

A função EIB EIS 12 (“Acess”) faz o controlo de permissões de acesso às várias aplicações

através de uma variável de 4 bytes.

Erro! A origem da referência não foi encontrada. 31

A função EIB EIS 13 (“EIB-ASCII-Char”) permite o envio de um único caracter.

A função EIB EIS 14 (“8-bit Counter Value”) é usada para representar um contador de 8 bits.

A função EIB EIS 15 (“Character String”) permite o envio de mensagens textuais com

tamanho máximo de 14 bytes.

As funções EIB são a as mesmas que as do protocolo KNX, pois este nasceu com base no

protocolo EIB e das mudanças e melhorias necessárias.

3.5 Instalação de Redes KNX

Quadro elétrico

O quadro elétrico permite alojar os dispositivos elétricos e eletrónicos que não precisam e ou

não devem estar acessíveis ao utilizador. O quadro elétrico poderá ser um qualquer normalizado

pela norma EN50022 35×7,5mm DIN. No quadro a parte de energia deve ser separada da instalação

KNX. Preferindo-se não separar, deverão ser utilizados cabos com a bainha até aos terminais e

garantir que os cabos de energia não contactem com o bus. Os quadros têm de possuir calha DIN

para colocação dos dispositivos. Quando existem dispositivos KNX e elétricos na mesma calha, terá

de se garantir que não existe uma descarga de energia para a calha e esta não pode ser ligada ao

potencial da terra. A régua de dados liga os participantes como fontes de alimentação filtros entre

outros ao bus. A régua autocolante deve ser colocada de acordo com a norma numa calha DIN de 35

mm. O tamanho destas réguas depende dos tamanhos normalizados para cada quadro elétrico e não

devem ser alteradas. Para evitar contactos indesejados, a parte das calhas que não são utilizadas,

deverão ser tapadas com uma cobertura como podemos ver na figura 27, onde podemos ver também

os vários tipos de calha DIN.

Figura 27: Diferentes tipos de calha e cobertura para calha DIN.

Este tipo de montagem tem o nome de Rail-mounted. Esta permite arrumar e organizar os

dispositivos na calha DIN de uma forma muito simples. A figura 28 ilustra um exemplo para melhor

compreensão:

32 Introdução

32

Figura 28: Montagem Rail-mounted.

Na montagem embebida (Flush mounted), a instalação de dispositivos é feita dentro das

paredes, sempre que possível é preferível este tipo de montagem. Este tipo de montagem é feita

em caixas embebidas nas paredes, os dispositivos são fixados a estas através de parafusos. As caixas

devem ter 50 mm de profundidade para se poder trabalhar com os cabos e o dispositivo caber.

Neste tipo de montagem é possível combinar dispositivos de energia e dispositivos do tipo embebido

KNX, como podemos ver na figura 29.

Figura 29: Dispositivos do tipo montagem embebida.

Na montagem de superfície (Surface mounted,) os dispositivos são colocados à superfície,

ficando totalmente visíveis para o utilizador como mostra a figura 30.

Figura 30: Dispositivo do tipo montagem de superfície

Na montagem Device mounted os dispositivos são incorporados em outros equipamentos como

aquecedores, ar condicionado, lâmpadas e em alguns eletrodomésticos. Aos olhos do utilizador não

Erro! A origem da referência não foi encontrada. 33

é visível sua presença. Como poderemos confirmar na figura 31, não é visível que a banheira tem

qualquer tipo de controlo contudo existe: possui electro-válvulas e vários sensores que não são

visíveis, mas que podem ser controlados em benefício do utilizador.

Figura 31: Dispositivo do tipo montagem Device mounted.

Tipo de cabo

Antes de especificar o tipo de cabos a utilizar nas instalações, convém dar uma breve

explicação sobre as tensões admissíveis nos cabos de bus KNX. A tensão SELV (Safety Extra Low

Voltage) é uma das mais importantes a ter em conta. Esta tensão é gerada por um transformador de

segurança. O seu valor normal de funcionamento é de 29 VDC e não pode ser ligada ao potencial da

terra. Os limites máximos de tensão para corrente contínua e alternada são nomeadamente:

120VDC e 50VAC. Os cabos utilizados nos sistemas KNX devem possuir isolamento de segurança das

outras redes, isolamento à terra e sem isolamento para o utilizador. A figura 32 representa os

termos e ideias referenciados:

Figura 32: Isolamento de cabos para KNX.

No capítulo 9 do Handbook KNX estão todos os tipos de cabos que podem ser utilizados numa

instalação. A título de exemplo, os cabos com o logótipo KNX e os outros que cumprem as

características e que lá estão definidos, como exemplo: o YCYM 2x2x0.8 e o JY(St)Y 2x2x0.8. Só os

cabos verdes KNX garantem: o máximo comprimento da linha, o máximo espaço entre dispositivos e

o máximo de dispositivos. Este cabo tem como características 72Ω e uma capacidade de 0.12μF por

cada 1000m. A figura 33 especifica as características necessárias de um cabo KNX.

34 Introdução

34

Figura 33: Características de um cabo param KNX.

Os requisitos de uma instalação KNX são normalmente os mesmos que param uma instalação

de 230/400V. Quando possível deve-se garantir uma distância mínima de 4mm entre os condutores

do bus KNX e os de energia.

Erro! A origem da referência não foi encontrada. 35

Capítulo 4

Sistema de gestão de domótica

3.1 Sistema de gestão de domótica

No âmbito da dissertação foi proposto o desenvolvimento de um sistema de gestão de domótica

que deveria interagir com uma rede KNX já implementada. O novo sistema acrescenta

funcionalidades ao sistema já existente, devendo ser baseado numa arquitetura de software

modular. O sistema desenvolvido é constituído por um computador e um quadro que representa a

rede KNX, sendo ligados entre si por um cabo Ethernet. Para melhor compreender o sistema a figura

34 representa de forma simplificada e concisa a constituição do sistema.

Figura 34: Arquitetura global do sistema.

Toda esta arquitetura de hardware já se encontrava elaborada, faltando apenas o software

para controlar e gerir todo este sistema. Com este projeto a empresa pretendia dar os primeiros

passos na área da domótica; após este desenvolvimento pretende-se que o sistema evolua e que

inclua novas funcionalidades. A arquitetura de hardware é constituída por uma Gate Box que

permite a ligação do sistema à Internet e futuramente o acesso remoto e um Switch que permite a

ligação do sistema desenvolvido até então à Gate Box. O switch identifica cada porta (sistema de

gestão de domótica) e envia os dados somente para a porta destino, evitando assim que outros

36 Introdução

36

sistemas de gestão de domótica recebam dados que não lhe são destinados. A caixa verde

representa um sistema idêntico ao desenvolvido e a possibilidade de ligar vários sistemas idênticos

ao switch. O sistema desenvolvido nesta dissertação é constituído por um computador que possuí o

software que controla a rede KNX. O computador é ligado ao quadro ou rede KNX por um cabo

Ethernet como já foi referido e está representado na figura 34. O quadro ou rede KNX é constituído

por um Router (ABB KNX IP router IPR/S 2.1), uma fonte de alimentação representada na figura por

VCC e um módulo de controlo de quatro saídas (TXA 204A). O router tem a função de fazer a

interface entre o computador e o resto da rede KNX e o encaminhamento dos telegramas KNX

recebidos para os dispositivos a que se destinam através do bus de dados representado pelos fios

preto e vermelho e legenda “KNX”. O bus de dados serve para transmitir os telegramas e alimentar

os módulos da rede KNX. O módulo de controlo de quatro saídas independentes é constituído por

quatro relés que permitem fazer a interface do bus KNX com cargas elétricas comandadas por

comandos ligar/desligar. Permitem comandar a iluminação, o aquecimento ou qualquer outra carga

pelo apertar de um botão (contacto livre de potencial). Este módulo possui quatro botões de

pressão com um indicador de estado (led verde se ligado) para comandar as saídas independentes. A

fonte de alimentação é alimentada a 230 V alternados, produz uma tensão de 29 V contínuos

(definido pelo protocolo), uma corrente máxima de 350 mA e pode alimentar até um máximo de 16

dispositivos KNX. As habitações 1 e 2 representam habitações que poderiam ser adicionadas à rede

KNX. Devido às limitações apresentadas pela rede relativamente ao número de saídas que se podem

controlar e à necessidade de definir vários perfis de utilização, definiu-se que as mesmas saídas

iriam ser comuns às duas habitações. Isto para que fosse possível mediante cada perfil de utilizador

e sua habitação, o utilizador só pudesse controlar determinadas saídas ou conjunto, mediante as

permissões que tivesse. Contudo isto será mais percetível aquando da apresentação de resultados

nos testes e avaliação do sistema.

Voltando ao objetivo fundamental desta dissertação salienta-se a especificação e

desenvolvimento de uma arquitetura modular que permitisse futuras alterações e desenvolvimentos

do sistema global. Após a análise das várias arquiteturas de software foi escolhida a arquitetura

Model-View-Controller (MVC) representada pela figura 35.

Figura 35: Arquitetura de Software do sistema a desenvolvida.

A arquitetura MVC é uma arquitetura de Software que se divide em três camadas: Model

(modelo), View (visão) e Control (controlo). Esta foi escolhida por ser uma arquitetura modular que

permitiria aumentar o número de aplicações e o número de dispositivos a controlar. A arquitetura

MVC por ser modular permitia a separar a lógica de negócio da lógica do controlador, desta forma

facilitando a organização e separação dos diferentes módulos. A separação dos dados a apresentar

ao utilizador dos dados da aplicação permitia uma melhor organização da informação.as vantagens

que levaram à escolha desta arquitetura são as seguintes:

Separação das diferentes camadas de desenvolvimento dotando o sistema da capacidade de

se tornar modular;

Separação da lógica de apresentação do negócio da lógica de aplicação;

Erro! A origem da referência não foi encontrada. 37

Facilidade e possibilidade de reaproveitamento do código em desenvolvimentos futuros ou

possíveis alterações;

Reutilização do código do desenvolvido para as diferentes partes a desenvolver;

Facilidade de manutenção do sistema;

Facilita a criação de documentação e manutenção de cada parte constituinte arquitetura;

Desenvolvimento de múltiplas aplicações e integração de equipas multidisciplinares no

desenvolvimento da arquitetura;

Separação do design da visão, da programação do controlo;

Teste e manutenção isolada das diferentes camadas de desenvolvimento;

Facilidade da implementação de segurança no sistema;

Facilidade da organização do sistema a desenvolver pois possibilita a programação por

diferentes especialistas em cada área e a interação entre os mesmos devido à sua modularidade.

Antes de chegar ao sistema de gestão de domótica a implementar foi necessário uma análise

dos requisitos do sistema, definir objetivos de usabilidade, realizar estudos de campo, analisar a

concorrência, definir perfis de utilizador para os diferentes utilizadores do sistema, realizar análise

de tarefas, definir cenários de utilização, definir o que é responsabilidade do sistema e o que é

responsabilidade do utilizador e por a fim definição e combinação das diferentes tecnologias para

as diferentes camadas de forma a serem compatíveis e de terem bom desempenho.

4.1 Model

A camada model (modelo) representa as informações do sistema de gestão de domótica,

fornece funções para operar os dados, isto é, representa as funcionalidades da aplicação. A camada

model é responsável por notificar a interface (View) quando os dados são alterados se assim for

definido no modelo de negócio. A forma como os dados são armazenados, manipulados e como é

feito o seu acesso não depende da arquitetura mas sim do modelo de negócio. A camada Model teve

como finalidade as características atrás mencionadas, definir e gerir o domínio da informação e

notificar os utilizadores sobre mudanças nos dados, manipular e representar a informação detalhada

fornecida pelo utilizador à aplicação. Devido à necessidade de armazenar a informação foi

necessário criar uma base de dados para guardar a informação do sistema. No model foram criadas

as regras do negócio representadas sob a forma de tabelas, campos, estruturas, relações entre

tabelas etc. A base de dados criada para a camada model será explicada de forma mais

aprofundada após a explicação da arquitetura de software.

4.2 View

A camada View (visão) ou interface teve como objetivo apresentar o modelo de negócio ao

utilizador com a apresentação dos dados. Diferentes visões podem ser apresentadas para um mesmo

modelo de negócio se existirem diferentes propósitos como a limitação por tipo de utilizador. A

camada View teve a finalidade de definir de que forma a informação é apresentada ao utilizador. A

camada View teve ainda como função base a apresentação das perguntas e respostas ao utilizador

mediante os dados pretendidos pelo controlador e pelo utilizador. Assim sendo esta camada foi

fundamentalmente utilizada para entrada e saída de dados e dar um aspeto gráfico mais agradável

à apresentação dos dados. Antes de ser definida à camada View do sistema foi necessário:

Definir objetivos de usabilidade do sistema;

Analisar a concorrência (outros sistemas de gestão de domótica) para retirar o melhor que

cada sistema de gestão de domótica possui e implementar um se possível ainda melhor;

Analisar e definir as diferentes visões para cada perfil de utilizador;

Definir os diferentes cenários de utilização;

38 Introdução

38

Definir a informação a apresentar e como deveria ser apresentada ao utilizador;

Definir a tecnologia e linguagem gráfica a usar.

Depois das necessidades acima mencionadas existiram duas perguntas que impuseram:

A quem se destina esta camada?

Foi fundamental saber quem era o público-alvo, o número de utilizadores, as tecnologias já

existentes e o que os utilizadores esperavam e achavam necessário ser apresentado. Foi definido o

design com base nestes aspetos e com a preocupação de criar uma navegabilidade e uma estrutura

da camada View que promovesse a usabilidade do sistema.

O que apresentar na elaboração da camada View?

Saber o conteúdo a apresentar foi dos tópicos mais importantes e uma das razões da camada

View; daí adveio também a preocupação da forma como apresentar a informação visto esta

influenciar a funcionalidade da camada.

Após uma análise dos prós e contras das várias tecnologias e não esquecendo a necessidade de

compatibilidade dentro de todo o sistema foi escolhida a apresentação gráfica do explorador de

Internet com base na linguagem HTML e no tratamento gráfico pela linguagem de estilo CSS.

Estas tecnologias e linguagens foram escolhidas por serem de acesso livre e gratuito, existir

imensa documentação, variados exemplos onde se basear para a elaboração da apresentação

gráfica e por fim porque o produto final conseguido com estas escolhas ser de elevada qualidade

gráfica e de fácil obtenção.

4.3 Controller

A camada Controller (controlador) tem como função fazer toda a gestão da arquitetura de

software, receber e tratar as interações com a visão, apresentar e implementar o modelo de

negócio sempre que solicitado e dar as respostas ao modelo através da visão. As funções base da

camada Controller e necessidades do sistema são:

Controlar as regras do negócio;

Processar e responder a eventos;

Poder invocar alterações no Modelo.

Ao Controller cabe a responsabilidade de toda a gestão e controlo do que ocorre no sistema e a

decisão de tudo o que é apresentado ao utilizador. Ao Controller é exigido que ao receber a

entrada de dados, inicie a resposta ao utilizador invocando objetos do modelo e por fim apesente

uma visão baseada na entrada. Ele também terá a responsabilidade da validação e filtragem da

entrada de dados. Como neste caso prático é usado uma aplicação web em HTML como na camada

View, o controlador teria de receber a entrada dos dados pelo método GET ou POST. Após um

estímulo do utilizador a camada Controller tinha de decidir como processar os dados, invocando

objetos do sistema para tratar a lógica de negócio, e por fim invocar uma visão para apresentar a

saída. Depois da análise efetuada às necessidades do sistema, da camada Controller e à

necessidade de compatibilidade com as tecnologias até então escolhidas e a vasta abrangência de

funções o PHP foi a linguagem escolhida. O porquê desta escolha será detalhado mais a frente.

4.4 BASE DE DADOS

A criação de uma base de dados surgiu da necessidade de suportar o modelo de negócio

permitindo armazenar e gerir a informação de toda a rede KNX. Posteriormente ocorreu a

necessidade de criar um modelo de base de dados que servisse de suporte para toda a informação

de qualquer rede KNX. É na base de dados que são guardadas todas as informações uteis ao

funcionamento do sistema e onde são registadas todas as informações úteis da rede (habitações,

Erro! A origem da referência não foi encontrada. 39

utilizadores, dispositivos, Datapoints, endereços de grupo, a relação entre cada uma das entidades

e todas as atividades da rede KNX). Tudo isto será explicado mais à frente neste capítulo.

A base de dados construída é uma base de dados relacional que foi criada devido à necessidade

de ter conjuntos de relações (tabelas) que guardassem as informações e as separassem segundo as

necessidades da rede KNX e segundo restrições de integridade. A cada relação (tabela) criada

segundo as necessidades da rede KNX foi necessário atribuir um nome, definir os diferentes

atributos (tuplos) e um conjunto de restrições internas para o seu preenchimento. A necessidade de

organização da informação levou à criação de atributos nessas tabelas criadas que só admitem

valores elementares e nunca conjunto de valores. Para uma melhor identificação, todas as tabelas

construídas possuem uma chave de relação que identifica os seus tuplos de uma forma única

possuem; ainda um conjunto mínimo de atributos para que sejam distintas, uma chave primária e

em alguns casos chaves alternativas. As chaves alternativas são chaves estrangeiras que permitem a

utilização de um atributo ou um conjunto de atributos que referenciam um atributo ou um conjunto

de atributos de outra tabela permitindo relacionar as diferentes tabelas entre si. Estas chaves

estrangeiras permitiram o cruzamento dos dados, a relação das diferentes tabelas como um só

sistema de informação e tornaram mais simples de obtenção da informação desejada.

As restrições do modelo relacional criado para suportar a informação da rede KNX são comuns

às mais variadas bases de dados e foram criadas em resposta às seguintes necessidades:

Integridade das entidades:

Os valores da uma chave primária não podem ser nulos;

Os valores dos atributos devem ser todos do mesmo tipo;

Unicidade das chaves;

Não podem existir 2 tuplos diferentes com valores iguais na chave;

Integridade referencial:

Um tuplo de uma relação que se refira a uma outra relação tem de se referir a um tuplo

existente nessa relação referenciada;

Alguns atributos não podem possuir valores nulos mesmo não sendo chaves candidatas

colocando na criação do atributo Not Null, isto porque são atributos fundamentais à identificação e

ao funcionamento da rede KNX;

Chaves candidatas são atributos que têm de ser únicos (UK- Unique Key) estes definem o

objeto exemplo: contribuinte de um utilizador.

A necessidade de identificar de forma única as diferentes tabelas criadas levou à criação de

chaves de identidade, isto porque era necessário como já referido criar relações entre as diferentes

tabelas. As relações tipo que surgiram foram de um campo para muitos campos (cardinalidade 1:N)

e de muitos para muitos (cardinalidade N:M). A título de exemplo estas relações tipo surgiram da

necessidade de relacionar uma habitação com N dispositivos e da necessidade de relacionar N

dispositivos com M endereços de grupo e vice-versa.

A criação de relações foi fundamental para um bom funcionamento e organização da base de

dados uma vez que permitiu o cruzamento de informação. Estas aceleraram e facilitaram a

realização de pesquisas e consultas que incluíam mais de uma tabela. Para criar uma relação como

já referido foi preciso associar o campo chave primária duma tabela com os seus correspondentes

numa outra tabela. A figura 36 retrata o modelo da base de dados concebido para o sistema

desenvolvido na dissertação.

40 Introdução

40

Figura 36: Esquema da base de dados elaborada para armazenar a informação da rede KNX.

A figura 36 serve para suportar o que será explicado de forma a se perceber como e o porquê

de cada tabela.

O que representa cada tabela:

Habitação é a representação da casa como um todo, caso seja uma só moradia, ou uma

fração, caso existam várias moradias.

Utilizador é a representação das diferentes pessoas que irão utilizar o sistema com as

diferentes permissões.

Dispositivo é a representação dos diferentes elementos que constituem a rede.

Datapoint é a representação de cada funcionalidade possível de se implementar nos

diferentes dipositivos.

Addressgroup é a representação de um endereço de grupo de um ou vários dispositivos

numa rede KNX.

Dispositivoaddressgroup representa a relação de N:M entre o dispositivo e o addressgroup,

isto para se saber quantos dispositivos possui um Addressgroup e a quantos Addressgroup pertence

um dispositivo.

Será agora explicado porquê da rede ter sido dividida desta forma.Como a rede KNX que existia

já possuía determinadas características e tinha como perspetivas futuras acrescentar mais

funcionalidades por conseguinte mais dispositivos. Com base em todas essas necessidades foi criada

uma base de dados que possibilitasse a gestão de N habitações, com M dispositivos e com X

utilizadores. A necessidade de guardar a informação da rede e a necessidade de organizar essa

informação, levou à criação de uma tabela para dividir a rede nas N habitações possíveis. Como

para cada habitação havia muita e variada informação, foi necessário repartir a informação por

mais duas outras tabelas, utilizador e dispositivo (aparelho KNX). Daí surgiu a necessidade de criar

relações entre estas e a tabela habitação, as relações criadas foram uma habitação para M

dispositivos e uma habitação para X utilizadores daí as relações terem a cardinalidade 1:N. Depois

desta divisão verificou-se que ainda não era o suficiente visto que a informação necessária ao

funcionamento e gestão de um dispositivo era imensa. Foi efetuada uma análise e verificado que o

dispositivo comum segundo o protocolo KNX precisava de um a N Datapoints (define uma

funcionalidade) para funcionar e devia pertencer a pelo menos um endereço de grupo (o seu para

ser identificado no comando a executar) ou poderia pertencer a N endereços (definindo um

cenário). Com base na possibilidade e necessidade de criar cenários foi criada uma relação de M

Erro! A origem da referência não foi encontrada. 41

dispositivos para Y grupos e vice-versa, daí adveio a necessidade de criar a tabela de relação

dispositivoaddressgroup para que fosse possível este tipo de relação e assim a tecnologia obrigava.

Após uma profunda análise e estudo do protocolo KNX descobriu-se que a cada addressGroup só

poderia estar associado um Datapoint e a cada Datapoint uma só funcionalidade daí a necessidade

anteriormente definida de existir uma relação de M dispositivos para Y grupos e vice-versa. Devido

à existência de duas habitações e a possibilidade de existirem N habitações surgiu a necessidade de

identificar no endereço de grupo (addressGroup) a habitação que pertence.

Agora será demonstrado como a informação foi organizada e distribuída assim como a

informação necessária à correta gestão da rede KNX:

Habitação:

Id (identificação da habitação);

O IP da Gateway da rede (ipGatewayKNX- ip do Router IPR/S 2.1) para comunicação com a

mesma;

O IP do computador (ipGateway) para comunicação com a rede;

Porto do computador para comunicação com a rede;

Utilizador:

Identificação enquanto utilizador;

Identificação pessoal do utilizador;

Username e password para autenticação;

Dispositivos:

Identificação do dispositivo;

Habitação pertencente;

Endereço individual (área, linha, nº do dispositivo) único na rede;

Estado atual do dispositivo e valor atual para saber do seu funcionamento;

Datapoint:

Identificação do Datapoint;

Prioridade face a outras funções;

Codificação ou seja uma string que identifica o comando na rede KNX;

Valor máximo e mínimo para saber a gama de valores que o dispositivo poderá receber num

comando;

Unidades quando aplicavél;

AddressGroup:

Identificação do endereço de grupo;

Identificação da habitação a que pertence;

Endereço físico atribuído pelo programa de gestão da rede KNX (ETS);

Identificação do Datapoint a que está associado;

O número de dispositivos que constituem o grupo;

Dispositivo_AddressGroup:

Identificação da relação entre o dispositivo e o endereço a que pode pertencer;

Identificação do dispositivo;

Identificação do endereço de grupo;

42 Introdução

42

Após vários testes de funcionalidade e sucessivas alterações o modelo de base de dados final é

o abaixo demonstrado pela figura 37:

O tipo de dados de cada tuplo corresponde à informação que este terá de armazenar não

podendo guardar de qualquer outro tipo. Este modelo pode ser aplicado a qualquer rede KNX com o

mais variado número de dispositivos e utilizadores e habitações.

Figura 37: Modelo final da base de dados.

Erro! A origem da referência não foi encontrada. 43

Tecnologias adoptadas

4.5.1 MySQL

O MySQL é um sistema de gestão de base de dados (SGBD), que utiliza a linguagem SQL

(Structured Query Language - Linguagem de Consulta Estruturada) como interface. O SGBD é

responsável pela gestão da base de dados; o principal objetivo é gerir o acesso, a manipulação e a

organização dos dados. A inclusão de um SGBD no sistema surgiu devido à necessidade de

armazenar, agilizar e garantir a continuidade e segurança dos dados necessários e adquiridos. Após

uma análise aprofundada foi escolhido um SGBD em MySQL; no início a escolha recaiu em 2

linguagens o PostgreSQL e o MySQL pois as linguagens ofereciam:

Manipulação, definição, controlo, transação e consulta de dados;

Elevada Portabilidade (suportadas por praticamente qualquer plataforma atual);

Elevada compatibilidade (módulos de interface para diversas linguagens de programação,

como Delphi, Java, C/C++, Python, Perl, PHP e Ruby e drivers ODBC, JDBC e .NET);

Excelente desempenho e estabilidade;

Pouco exigente quanto a recursos de hardware necessários do sistema na sua manipulação;

Facilidade de uso e elevado número de documentação livre;

Serem de utilização livre.

A escolha foi o MySQL pois havia mais documentação onde apoiar o seu estudo e

desenvolvimento, preenchia todos os requisitos e necessidades inerentes ao sistema, era uma

linguagem nova para mim e por fim era uma linguagem de uso livre, que também era um dos

requisitos. Era necessário que fosse compatível com o Windows, pois era o sistema operativo do

computador; verificou-se ser possível e que ainda podia operar com outros sistemas operativos (

Linux, Mac OS X, etc.). Devido à possibilidade de o sistema operar com um elevado número de

habitações, utilizadores e dispositivos, revelou-se a necessidade de um SGBD de elevado

desempenho, robustez, multitarefa e multiutilizador. Prova da resposta a estas necessidades era a

própria Wikipedia utilizar MySQL na gestão da sua base de dados, demostrando assim que é possível

utilizá-la em sistemas de produção de alta exigência e em aplicações sofisticadas com múltiplos

utilizadores a aceder e modificar os dados ao mesmo tempo. Depois de todas estas vantagens,

funcionalidades e prova das suas capacidades não restou dúvidas na escolha do MySQL para o

sistema SGBD.

4.5.2 HTML

O HTML é uma linguagem de marcação de hipertexto (Hyper Text Markup Language), ou seja,

uma linguagem usada para criar páginas Web. Esta linguagem foi desenvolvida para transmitir a

informação que é colocada nos documentos partilhados na web pelo protocolo http (Hyper Text

Transfer Protocol). A escolha do HTML deveu-se à necessidade de apresentar dados ao utilizador

através de camada View, formatar texto e imagens, atribuição de cores, definir padrões, fundos,

definir papel de parede, tabelas, links e frames. O facto de ser uma linguagem de fácil

compreensão mesmo para quem nunca teve contato com qualquer outro tipo de linguagem de

programação, adicionado às necessidades atrás mencionadas e às funcionalidades e vantagens

ajudou na escolha do HTML. O HTML possui ainda a vantagem de poder ser criado e editado por um

simples editor de texto, como por exemplo o Notepad. Caso seja desejado um melhor será

aconselhado o Notepad++ que também é de uso livre e é mais vocacionado para este estilo de

programação em questão. O HTML no sistema elaborado sofreu grande influência das folhas de

44 Introdução

44

estilo (CSSs) na sua apresentação, essa influência será de seguida justificada e apresentadas as

vantagens dessa influência.

4.5.3 CSS

Cascading Style Sheets (folha de estilo) é uma linguagem de estilo utilizada para definir a

apresentação de documentos escritos numa linguagem de marcação, como HTML ou XML. A

principal vantagem na sua utilização é permitir separar a formatação do conteúdo a apresentar na

camada View. Em vez de colocar a formatação do documento HTML dentro deste, o programador

apenas precisa criar um link (ligação) em cada página criada para a folha de estilos. A necessidade

de criar muitas páginas e a possibilidade de usar a mesma CSS economizando código nas páginas

HTML e por conseguinte redução do tamanho dos ficheiros. A facilidade de quando se quiser alterar

a aparência das diferentes páginas dependentes da CSS. A necessidade de acompanhar as

tendências do mercado e por conseguinte a necessidade de alterar o conteúdo a apresentar. Os 16

milhões de cores para utilizar nos textos e fundos e imagens. A possibilidade de definir vários

padrões para utilizar sempre que necessário formatar:

Fontes tipo para formatação de texto;

Formatação das margens;

Formatação de tabelas;

Fundos;

Bordas;

Distância entre objetos;

Definir posição de objetos.

Depois de demonstradas as vantagens e verificadas as necessidades do sistema ficou clara a

necessidade e as vantagens da utilização de CSS na elaboração da camada View. Assim sendo a

imagem seguinte demonstra de uma forma visual o que até agora foi enumerado como vantagens.

Serão mostradas duas imagens com a mesma página web, uma sem a influência das formatações da

CSS e depois da influência da CSS para demonstrar e exemplificar o que foi dito e o impacto no

produto final.

Figura 38: Página de login sem a influência da CSS.

Como podemos verificar a página está sem vida, não capta a atenção do utilizador, não motiva

a sua utilização e não permite identificar o objetivo de cada elemento. A imagem seguinte já é uma

Erro! A origem da referência não foi encontrada. 45

imagem com a influência da CSS; tem muito mais vida, está mais organizada, consegue-se perceber

o que é cada elemento, é mais atrativa a sua utilização e mais funcional.

Figura 39: Página de login já com a influência da CSS.

Em jeito de conclusão além de tornar a página bem mais agradável, funcional, atrativa etc. a

CSS permitiu uma redução muito grande do código em cada página e facilitou o tratamento dos

erros e as alterações feitas ao longo do desenvolvimento.

4.5.4 Javascript

O Javascript é uma linguagem de programação web normalmente utilizada para auxiliar o

desenvolvimento de páginas web. Esta linguagem foi desenvolvida pela NETSCAPE, para tornar as

aplicações nas páginas HTML mais interativas. Após a sua criação recebeu uma importante

colaboração da Sun Microsystems, empresa que já se havia dedicado ao desenvolvimento de

aplicações para a Internet, com uma das linguagens mais poderosas, o Java contudo diferente do

Javascript. Após esta colaboração, podemos dizer que o Javascript é uma linguagem compatível

com a linguagem Java, daí a semelhança do nome “Javascript”. As características e vantagens que

levaram à utilização da linguagem Javascript foram:

Ser uma extensão da linguagem HTML;

Ser uma linguagem de programação orientada a objetos;

Variedade de objetos que já existem criados;

Possibilidade de poder mudar as propriedades mesmo depois do objeto ser carregado

aquando a página;

Possibilidade de criação de scripts tanto do lado cliente como do lado servidor;

Fazer o tratamento de:

Eventos (clicar em objeto, selecionar algum objeto, pressionar tecla);

Formulários (preenchimento e analise dos dados inseridos);

Maior interação com o utilizador do que HTML;

Facilidade de edição num editor ASCII como por exemplo, o Bloco de Notas do Windows.

Possibilidade de reutilizar o código se desenvolvido num ficheiro à parte.

46 Introdução

46

As imagens seguintes demonstram um organograma de parte dos objetos que a linguagem

possui e um exemplo de um objeto muito utilizado nas páginas web.

Figura 40: Organograma das classes de objetos existentes em Javascript.

Conforme apresentado neste organograma, pode-se verificar que existem vários objetos e

alguns são melhorias dos seus antecessores. A figura apresenta uma função comum no

desenvolvimento web que permite alertar o utilizador para um qualquer erro.

Figura 41: Caixa de dialogo alert() do objeto Window.

Erro! A origem da referência não foi encontrada. 47

As duas figuras seguintes apresentam uma das funcionalidades criadas na página de controlo, a

primeira figura antes de clicar sobre objeto submit (Ler) e segunda depois de clicar.

Figura 42: Página antes de clicar no botão Ler e ativar o script.

Figura 43: Página depois de clicar no botão Ler e ativar o script.

48 Introdução

48

Como se pode constatar mesmo depois da página carregada o script alterou a página e pediu a

informação à base de dados sobre o dispositivo em questão, sem a necessidade de carregar uma

nova página. Para concluir é de referir que o Javascript facilitou o desenvolvimento do projeto e o

tratamento de dados; contudo, devido à falta de tempo não foi muito utilizado. O Javascript

revelou-se uma ferramenta poderosa, fácil de implementar e muito útil.

5.5.5 PHP

O PHP ( Hypertext Preprocessor originalmente Personal Home Page) é uma linguagem de

programação web livre utilizada para gerar conteúdo dinâmico. O PHP foi escolhido porque

acrescentava valor às páginas web e devido à capacidade de dotar o sistema de funcionalidades

avançadas. Uma das vantagens de usar PHP é que é simples para um iniciante, contudo oferece

muitos recursos ao programador profissional. Era necessária uma linguagem que permitisse a gestão

e a execução de comandos que executassem programas externos; de todas as linguagens analisadas

e livres a que melhor se enquadrava era o PHP. Pode-se dizer que a única limitação para o uso do

PHP é a imaginação. O PHP é uma linguagem muito rica; contudo pode ser editada num qualquer

editor de texto, embora seja aconselhado o Notepad++ ou o Netbeans que é ainda melhor, e

correspondem à exigência de serem software livre. Uma desvantagem que no fundo não se tornou

uma desvantagem devido ao sistema a desenvolver foi que o PHP apenas executava no Netbeans ou

num servidor; contudo, tal não se tornou uma desvantagem visto o sistema necessitar dum servidor

para publicar as páginas web do sistema. Ao contrário do que ocorre com o HTML e as CSS, no

PHP não faz diferença o navegador que é usado, mas sim o servidor onde a página é hospedada. Isto

porque PHP é uma tecnologia processada do lado do servidor, o que se torna uma segurança para o

mesmo, pois o cliente apenas vê o código como HTML e não tem como saber que é PHP. O PHP

possui a particularidade de poder conjugar HTML e código de controlo PHP e ainda exige menos

comandos que o HTML. O PHP para ser diferenciado do HTML apenas precisa ser delimitado pelas

tags “<?php” no início e no fim terminar com “?>”.

O que distingue essencialmente o PHP do Javascript é que o PHP é executado do lado do

servidor, gerando código HTML que é então enviado ao cliente. O cliente recebe apenas os

resultados da execução do script, mas não sabe como é o código fonte o que oferece segurança ao

sistema desenvolvido nesta linguagem.

O PHP é uma linguagem muito rica. Com ela pode-se fazer tudo o que se precisar como por

exemplo interagir com outros programas de outras linguagens como era necessário ao sistema de

gestão de domótica desenvolvido. O PHP é uma linguagem de script, com ele pode fazer tudo o que

faria com outro programa CGI (Common Gateway Interface) como:

Receber e tratar dados de formulários;

Gerar páginas com conteúdo dinâmico;

Enviar e receber Cookies;

Correr outros programas;

Trabalhar com base de dados;

Escrever aplicações de desktop, se bem que não é a sua melhor funcionalidade.

O PHP tem a sua maior utilização na construção de scripts:

Do lado do servidor (server-side) e este é o principal campo de atuação do PHP;

Execução de comandos na linha de comandos, que é um script que funciona sem um

servidor web ou browser; apenas necessita de um interpretador. Este tipo de uso é ideal para

agendar tarefas, rotinas de processamento de texto.

Erro! A origem da referência não foi encontrada. 49

Com a necessidade de criar conexões, manipular dados, pesquisar e eliminar dados na base de

dados o PHP foi um ótimo aliado devido às suas funcionalidades e à facilidade de as utilizar. Com o

desenrolar de sistema desenvolvido foi necessário limitar as funcionalidades até então

desenvolvidas por tipo de utilizador e mais uma vez e devido às variáveis de sessão e

funcionalidades do PHP foi simples de resolver.

Com muito por dizer em termos de funcionalidades e vantagens, pode se mesmo dizer que o

PHP poderia ser quase a única linguagem para o desenvolvimento da dissertação e não só da parte

de controlo pois revelou se uma ferramenta poderosa.

4.5.6 Calimero

O Calimero é um pacote de software livre constituído por um conjunto de APIs JAVA,

desenvolvidas por estudantes da Vienna University of Technology e da University Of Applied

Sciences in Deggendorf, que foi apresentado na conferência científica de KNX. Com as bibliotecas

criadas por este grupo de estudantes podem-se construir aplicações KNX, que permitem a

comunicação, controlo, acesso local e remoto de redes KNX. O acesso efetuado pelo Calimero ou

qualquer outra aplicação desenvolvida com base nestas bibliotecas permite o estabelecimento de

um túnel de comunicação sobre uma rede IP com um Gateway KNX, processo denominado

KNXnet/IP Tunnelling. A versão mais atual do software suporta ainda o modo KNXnet/IP Routing, a

gestão da rede de dispositivos, registo de erros e mensagens de Debug, possui um buffer para as

mensagens de rede KNX e uma função que permite registo de todos os eventos ocorridos no

Barramento KNX numa base de dados. As APIs do Calimero permitem a criação de aplicações KNX

sem conhecer a fundo o protocolo de comunicação do KNX. O Calimero permite a ligação a uma

rede KNX permitindo passar comandos de escrita e de leitura sobre os dispositivos KNX, podendo

atuar como um gestor de eventos na rede KNX. A função do Calimero no sistema desenvolvido é

apenas fazer a interface entre o sistema e a rede KNX. Ao Calimero cabe apenas executar os

comandos de escrita e leitura enviados pelo sistema para a rede KNX e transformar os dados

recebidos pelo sistema em telegramas KNX percetíveis à rede KNX. Após receber o telegrama, a

rede KNX, mais propriamente a Gateway KNX, fará a interface entre a rede IP e a sub-rede KNX/EIB

- TP1. Após o telegrama chegar à rede KNX, será encaminhado para o dispositivo certo e convertido

num comando. Estas são as funções base do Calimero no sistema desenvolvido na dissertação.

4.5.7 Wampserver

O Wampserver ou WAMP5 é um pacote de software livre que foi desenvolvido pela PHP Team.

WAMP5 significa Windows, Apache, MySQL, PHP5. Este pacote é constituído por um conjunto de

programas que instala automaticamente o Apache, o PHP, o MySQL, o PHPmyadmin e

SQLitemanager. A escolha deste programa deveu-se essencialmente ao facto de ser executável em

Windows, possuir o servidor Apache que foi um dos maiores servidores web em 2010 com mais de 66

milhões dos sites mais, possuir uma base de dados MySQL, disponibilizar as ferramentas necessárias

para o uso de scripts PHP e interpretar CSS, HTML e Javascript. Com auxílio deste programa pode-se

criar um sistema de gestão de domótica, sem ter que publicar na Internet qualquer página,

permitindo ainda navegar entre páginas como se se estivesse na Internet como era pretendido. O

Wampserver permitiu o acesso às páginas web escritas em PHP, HTML e Javascript e tornou o

sistema mais dinâmico e rápido. Permitiu ainda alojar o sistema e através deste o acesso à base de

dados MySQL. O Wampserver como já referido anteriormente interpreta a tecnologia livre PHP5

permitindo o uso dos seus objetos e scripts. Como já antes foram abordadas e referidas as suas

funcionalidades tem se a acrescentar que o Wampserver possui uma interface para o utilizador

adicionar, editar, pesquisar e eliminar utilizadores, base de dados, tabelas e tudo o que uma base

de dados necessite.

50 Introdução

50

Erro! A origem da referência não foi encontrada. 51

4.6.1 Interface gráfica

A interface gráfica como já referido na arquitetura MVC é a parte visual apresentada ao

utilizador. A interface desenvolvida baseou-se fundamentalmente em três linguagens: HTML, CSS e

Javascript.

O HTML é a principal linguagem e a mais utilizada na parte visual de todo o projeto; a ela

coube a apresentação dos conteúdos comuns como imagens, textos, tabelas, hiperligações e

estrutura das várias páginas.

As CSSs e a sua programação foram a tecnologia secundária desta interface, permitindo a

definição de uma estrutura, uma formatação do texto e uma apresentação comum às várias

páginas, tornando o sistema modular e de fácil alteração quer na estrutura ou na parte gráfica.

O Javascript foi a tecnologia menos utilizada por falta de tempo para aprofundar o projeto. O

tratamento de formulários, criação de animações e a promoção de uma maior interatividade entre

o controlo e o utilizador podiam ser promovidos por esta tecnologia visto serem funções muito

comuns nesta linguagem. A sua utilização limitou-se ao tratamento de formulários e algumas

animações. As figuras seguintes irão demonstrar a dependência das três linguagens para o projeto

desenvolvido e o acrescento de qualidade a cada linguagem adicionada.

Figura 44: HTML sem a influência das folhas de estilo e o Javascript.

52 Introdução

52

Figura 45: HTML já com a influência das folhas de estilo mas sem o Javascript.

Figura 46: HTML já com a influência das folhas de estilo e o Javascript.

Como se pode observar ao passar o rato pelo menu a imagem troca de posição com as letras e ao

retirar volta a trocar, isto graças ao Javascript pois na imagem acima o rato está lá e nada

aconteceu pois o Javascript estava desativado.

4.6.2 Processamento do controlo

O processamento do controlo do sistema desenvolvido dividiu-se em duas partes o controlo com

o PHP e o controlo com Calimero. O PHP tem o seu controlo dividido em duas grandes partes: o

controlo da base de dados e o controlo e gestão da parte da domótica. A gestão da base de dados

envolve todo o processamento, tratamento, edição, pesquisa e eliminação de dados. Para a gestão

de um sistema de domótica é necessária a informação fundamental ao funcionamento de toda a

rede.

Erro! A origem da referência não foi encontrada. 53

A base de dados como já referido tem de ter a informação necessária ao funcionamento da

rede KNX e a possibilidade de relacionar as diferentes componentes da mesma. Em cada rede KNX

pode existir uma ou mais habitações, pois pode ser uma rede de uma habitação pessoal ou a rede

de um condomínio com muitas habitações. Dentro de cada habitação podem existir imensos

dispositivos (sensores, atuadores e aplicações), cada um terá de ser identificado e possuir a

informação necessária ao seu funcionamento na base de dados da rede. Todos os dispositivos

possuem um endereço individual e único na rede, contudo devem pertencer a um grupo ou a vários

grupos dentro dessa rede. Isto é útil para definir cenários e ou facilitar o funcionamento da rede

evitando enviar comandos individuais, enviando para vários de uma só vez. Os dispositivos podem

ainda possuir vários Datapoints consoante as suas funções e necessidades da rede.

Os Datapoints são aplicações para os mais diferentes tipos de dispositivos, o tipo de um

Datapoint define o tipo de aplicação para o qual foi definido. Os Datapoints são normalizados para

garantir a compatibilidade de dispositivos similares de diferentes fabricantes. Esta normalização

inclui exigências relativas ao formato dos dados e da estrutura dos Objetos de Grupo, bem como das

funções dos sensores e dos atuadores estas normas são definidas pela Organização KNX. À

combinação de vários tipos de Datapoints normalizados é dominado por bloco funcional de um

dispositivo ou grupo de dispositivos. Os Datapoints podem ser atribuídos a um só dispositivo ou a

vários dispositivos, contudo é de ressalvar que um endereço de grupo não pode possuir mais que um

Datapoint.

Os AddressGroup ou endereços de grupo são utilizados para definir um endereço de um

dispositivo ou comum a vários dispositivos da rede e possibilitar o comando de vários dispositivos ao

mesmo tempo e com isso por vezes e se for de interesse definir cenários de funcionamento. Devido

a necessidade de relacionar os diferentes endereços de grupo com os diferentes dispositivos foi

criada uma tabela com o nome de dispositivoaddressgroup, esta necessidade surge por pelo facto de

um grupo possuir muitos dispositivos e ainda porque um dispositivo poder pertencer a vários grupo.

A parte de controlo da rede KNX é efetuada pelas funções de escrita e leitura criadas no

âmbito deste projeto. Para isto ser possível foi necessário combinar as funções criadas com dois

ficheiros Batch (comandos )e o programa Calimero anteriormente explicado. Aos ficheiros PHP cabe

a tomada de decisões mediante as ações do utilizador, depois das decisões tomadas o programa PHP

executa o comando de escrita ou de leitura. No comando de escrita e de leitura o programa em PHP

aatravés das suas funções (exec, escapeshellarg, etc.) executa o ficheiro Batch e passa-lhe como

argumentos os dados necessários para a execução dos comandos. Após a execução do ficheiro

Batch, ele irá passar como argumentos os argumentos anteriormente transmitidos a este. Os

argumentos serão passados ao Calimero e é feito o pedido que este execute o comando pretendido.

O controlo por parte do Calimero é especificamente a execução da função ProcComm que ao

receber os argumentos executa os comandos recebidos para os dispositivos definidos nos

argumentos passados pelo ficheiro Batch. O que esta função faz basicamente é converter os

dados passados como argumento em dados interpretados pela rede KNX ou seja telegramas KNX

interpretados pela rede e por um ou vários dispositivos a que se dirige o comando. Os argumentos

passados são:

Endereço IP do computador;

Endereço IP da gateway da rede KNX;

Comando a executar (write ou read);

Porto de comunicação;

Codificação do Datapoint;

Estado futuro;

Endereço de grupo.

É assim que é feito e executado o controlo do sistema desenvolvido nesta dissertação,

concebido com a interação entre o PHP, os Batch files e o Calimero.

54 Introdução

54

Capítulo 5

Teste e avaliação do sistema

5.1 Cenários de teste

O cenário de teste teve o intuito de testar e verificar a compatibilidade entre o sistema e o

protocolo KNX e o seu desempenho. Os cenários de testes criados foram divididos em dois grandes

grupos:

1. Base de dados:

Teste de habitação;

Teste de utilizadores;

Teste de endereço de grupos;

Teste de dispositivos;

Teste de Datapoint;

Teste de relação entre endereços de grupo e Datapoints;

2. Controlo:

Teste de 2 habitações numa mesma rede;

Teste para utilizadores com diferentes perfis;

Como só havia um quadro (rede KNX) foram mapeadas duas habitações no mesmo quadro.

Devido ao limitado número de saídas e à necessidade de definir diferentes tipos de perfis de

utilizador foi necessário utilizar as mesmas saídas físicas para as duas habitações pois o módulo

possuía apenas quatro saídas. Mesmo mapeando os mesmos endereços físicos, os dispositivos

dispõem de endereços virtuais e na base de dados independentes. Caso fosse acrescentado mais um

módulo apenas seria necessário mudar os endereços físicos na base de dados e o sistema continuaria

a funcionar mas já com saídas diferentes e independentes. Como o intuito era testar o software e a

base de dados não fazia diferença mapear endereços físicos iguais pois o que poderia acontecer era

mandar ligar ou desligar duas vezes o mesmo dispositivo isto sem qualquer consequência física

(curto-circuito) e nem na base de dados. Todos os testes efetuados tiveram em linha de conta o

facto de os dispositivos além de serem os mesmos fisicamente, mapeavam endereços diferentes na

base de dados. Todas as atividades e testes foram registados na base dados como seria expectável

numa habitação em uso. Serão apresentados os dados referentes às duas habitações criadas e o

cruzamento dos dados para provar a viabilidade do sistema.

5.2 Base dados

Para efetuar os testes da base dados teriam de se criar cenários que representassem situações

gerais e que provassem que o sistema de gestão de base de dados funcionaria mesmo em casos

extremos. Não foi necessário um teste tão exaustivo; contudo, foi criado um cenário de teste que

garantisse que a base dados era compatível com qualquer rede. O cenário foi criar na base de

dados:

Duas habitações para garantir que o sistema tanto podia possuir uma como N habitações;

Cinco utilizadores para que fosse garantido que se pudesse no limite ter N utilizadores e

para garantir os 5 perfis diferentes com as cinco permissões diferentes;

Erro! A origem da referência não foi encontrada. 55

Dois Datapoints para garantir que o sistema podia possuir no limite N Datapoints.

Oito dispositivos, quatro da primeira habitação e quatro da segunda habitação, isto para

garantir que o sistema funcionaria no limite com N dispositivos, salvaguardava a utilização das

quatro saídas e as diferentes permissões dos diferentes utilizadores;

Doze endereços de grupo, oito dos quais endereços dos oito dispositivos, dois endereços de

grupo de dois grupos de dois dispositivos nas diferentes habitações e por fim dois grupos de todos os

dispositivos de cada habitação;

Vinte relações entre dispositivos e endereços de grupo (dispositivoaddressgroup):

Oito devido aos endereços de grupo individuais;

Quatro dos dois endereços de grupo de dois dispositivos;

Oito dos dois endereços de grupo de quatro dispositivos;

Os testes efetuados serão demonstrados por imagens que são print screens da base dados e das

diferentes visões criadas pela camada View do projeto desenvolvido.

Habitação:

Figura 47: Pesquisa na base de dados na tabela habitações.

Como se pode verificar na figura da base de dados, esta possui a mesma informação que é

recebida pelo sistema quando é feita uma pesquisa pelas habitações existentes, o que demonstra a

coerência dos sistemas e com os dados anteriormente mencionados.

56 Introdução

56

Figura 48: Pesquisa à base de dados por habitações.

Utilizadores:

Os utilizadores são as pessoas que irão usar o sistema; a cada tipo de utilizador está associado

um tipo de perfil, uma identificação pessoal e da base de dados como poderemos verificar nas

imagens seguintes.

Figura 49: Pesquisa de utilizadores efetuada na base de dados.

Como podemos verificar existem diferentes tipos de utilizadores, todos os endereços de e-

mail, username, telemóvel, idUtilizador e contribuinte são únicos pois é exigido pelo sistema e pela

base de dados.

Erro! A origem da referência não foi encontrada. 57

Figura 50: Pesquisa de utilizadores do sistema efetuada à base de dados.

Como se pode verificar os dados nas duas tabelas da base de dados e sistema são os mesmos,

confirmando-se assim a coerência no sistema.

Datapoints:

Os Datapoints são importantes ao sistema pois são eles que possuem a informação necessária

para implementar as funções que os mesmos representam. Como se pode verificar pela figura 51 só

existem dois Datapoints (funções), embora para o sistema a implementar e devido às suas

limitações só é necessário o primeiro Datapoint.

Figura 51: Pesquisa de Datapoints efetuada na base de dados.

A figura 52 representa uma pesquisa na base de dados por Datapoints e confirma a coerência

entre o sistema e a base de dados.

58 Introdução

58

Figura 52: Pesquisa de Datapoints efetuada à base de dados pelo sistema.

Dispositivos:

Os dispositivos representados na figura 53 pertencem à mesma rede KNX mas a habitações

diferentes. Como podemos verificar pelo idhabitacao os primeiros 4 dispositivos pertencem à

primeira habitação e os últimos quatro à segunda habitação.

Figura 53: Pesquisa por dispositivos na base de dados.

Como se pode verificar todos os dispositivos possuem um endereço individual único constituído

pelas componentes área, linha e número do dispositivo como exigido pelo protocolo KNX. A

componente estadoActual representa o estado atual do dispositivo na base de dados; contudo, tal

não implica que fisicamente o dispositivo esteja no mesmo estado. A cada escrita ou leitura

efetuada pelo sistema o estado será atualizado pelo mesmo e será garantido que o seu estado é

aquele que foi executado pelo sistema. A figura 54 confirma a coerência dos dados e da pesquisa

obtida nos dois sistemas.

Erro! A origem da referência não foi encontrada. 59

Figura 54: Pesquisa efetuada a base de dados pelo sistema à procura de todos os dispositivos.

Pode se constatar-se que os dados são coerentes, assim garantido-se o compromisso de

coerência dos dois sistemas.

Addressgroup:

O addressgroup como já referido anteriormente é um endereço de grupo que pode estar

associado a varios dispositivos de uma rede KNX. O sistema implementado possui para cada

habitação quatro grupos de um elemento, um de dois elementos e por fim um com todos os

elementos. Como podemos verificar na figura 55 existem 6 grupos para cada habitação, num total

de doze habitações.

Figura 55: Pesquisa efetuada a base de dados à procura de todos os endereços de grupo.

60 Introdução

60

O campo idHabitacao identifica a que habitação pertence cada endereço de grupo, o código o

endereço físico na rede KNX e como podemos constatar são seis e representam os mesmos

endereços físicos para as duas habitações como já foi referido. Como o único módulo que a rede

KNX possuía era um módulo para controlo de quatros dipositivos a única função possível era on/off,

daí o Datapoint ser sempre o mesmo em todos os dispositivos. Por fim, como se pode verificar, a

coluna nDispositivos apresenta os grupos anteriormente referidos, que totalizam 12 endereços de

grupo.

Figura 56: Pesquisa efetuada a base de dados pelo sistema à procura de todos os endereços de grupo.

Dispositivoaddressgroup:

A dispositivoaddressgroup é o nome dado à relação entre um endereço de grupo e um

dispositivo. Esta tabela foi criada devido à necessidade de representação das relações entre os

diferentes dispositivos e os endereços de grupo e também devido à sua cardinalidade N:M. Ou seja,

para um dispositivo pode pertencer a N grupos e um endereço de grupo possuir M dispositivos; daí a

necessidade da criação desta tabela. Como cada habitação possui quatro grupos individuais, um de

dois e um de quatro, isto totaliza dez relações por habitação e vinte no total como se pode verificar

na figura 57.

Erro! A origem da referência não foi encontrada. 61

Figura 57: Pesquisa na base de dados por dispositivoaddressgroup.

Figura 58: Pesquisa por dispositivoaddressgroup na base de dados efetuada pelo sistema.

Como se pode verificar mais uma vez os dados são coincidentes e representam as

funcionalidades e necessidades do sistema implementado. Toda a base de dados é coerente com o

sistema desenvolvido e com as necessidades de configuração e das suas atividades e assim sendo

62 Introdução

62

pode se concluir-se que o sistema está bem implementado a nível de base de dados. Pode-se ainda

concluir que a base de dados poderia suportar um sistema bem maior e muito mais abrangente,

correspondendo às espectativas.

5.3 Configuração da rede IP e configuração KNX

Para o sistema desenvolvido funcionar em conjunto com o Calimero e por conseguinte comunicar com a

rede KNX foi necessário realizar algumas configurações. As configurações devem ser efetuadas em:

Propriedades de Ligação de Área Local no campo Protocolo de IP versão IPV4, isto no computador que

comunica com a rede e no programa Calimero. O computador que comunicar com o sistema tem de possuir

um IP alternativo para conseguir executar a aplicação Calimero. As configurações são:

IP address: 192.168.0.20;

Netmask: 255.255.255.0;

A figura 59 demonstra as configurações efetuadas e onde as fazer.

Figura 59: Configuração do IP alternativo do computador para funcionar com o Calimero.

Ordem dos passos a seguir:

1. Propriedades de ligação de Área Local;

2. Selecionar o Protocolo IP versão 4;

3. Clicar em propriedades;

4. Clicar na aba configuração alternativa;

5. Inserir o endereço IP: 192.168.0.20;

6. Inserir a Netmask: 255.255.255.0;

7. Por fim confirmar os dados e sair.

Assim fica configurado o computador onde o sistema for instalado.

Para comunicar com a rede KNX o Calimero ou as suas funções devem ser executadas com o

endereço IP 192.168.0.222 e com o porto 3671 para que o módulo da rede KNX (Módulo ABB IPRS/S

2.1) consiga receber as tramas KNX e enviá-las para o dispositivo a que se destinam.

Erro! A origem da referência não foi encontrada. 63

5.4 Avaliação funcional

Serão demonstradas e avaliadas as funcionalidades do sistema, tais como a gestão de

utilizadores, demonstrações de controlo individual e de grupo dos dispositivos. Como anteriormente

referido existem diferentes tipos de utilizadores, pelo que serão apresentadas de forma gradual as

funcionalidades que cada grupo de utilizadores usufrui, para que seja mais fácil a sua apresentação

e compreensão. Os perfis existentes dividem-se em cinco tipos são eles o técnico, o administrador,

o utilizador de nível um, o utilizador de nível dois e o utilizador de nível três. A cada perfil estão

associadas diferentes tipos de permissões como:

Técnico este perfil tem todo o tipo de permissões possíveis no sistema.

Administrador este perfil tem todo o tipo de permissões de controlo na sua habitação

contudo não é permitida a execução de todos os comandos na base de dados.

Utilizador 1 – este perfil apenas pode comandar as lâmpadas individualmente e a edição dos

seus dados enquanto utilizador.

Utilizador 2 – este perfil apenas pode comandar as lâmpada 1 e 2 individualmente e a

edição dos seus dados enquanto utilizador.

Utilizador 3 – este perfil apenas pode comandar o sistema físico, não tem acesso a qualquer

função do sistema desenvolvido.

De seguida serão demonstradas as funcionalidades do sistema de gestão de domótica para os

diferentes perfis de utilizador.

A figura 60 é a página que aparece caso o utilizador tente aceder a uma página que implique

que se tenha efetuado o login.

Figura 60: Página de login.

Utilizadores do tipo util3:

Este tipo de utilizador não tem acesso a nenhuma página criada. Este perfil foi criado para

teste e para definição de vários tipos de perfis para as mais variadas funções possíveis do sistema,

podendo vir a ganhar permissões em desenvolvimentos futuros. Como este perfil não possui

qualquer tipo de permissão mesmo após ter feito login, quando tentar aceder a qualquer

funcionalidade do sistema a página que aprece é a da figura 61.

64 Introdução

64

Figura 61: Página de acesso interdito.

Utilizadores do tipo util2:

Utilizador do tipo 2 (util2) é um perfil de utilizador que já possui permissão para o controlo das lâmpadas

1 e 2 de forma individual, pertencentes à sua habitação. A figura 62 demonstra a página de acesso.

Figura 62: Página de controlo para utilizadores do tipo util2.

Utilizadores do tipo util1:

Utilizador do tipo 1 (util1) é um perfil de utilizador que já possui permissão para o controlo de

todas as lâmpadas de forma individual, pertencentes à sua habitação. A figura 63 demonstra a sua

página de acesso.

Erro! A origem da referência não foi encontrada. 65

Figura 63: Página de controlo para utilizadores do tipo util1.

Utilizadores do tipo admin:

Utilizador do tipo administrador (admin) é um perfil de utilizador que já possui permissão para

o controlo de todas as lâmpadas de forma individual ou o grupo 1_2 ou grupo 1_2_3_4 que

pertencentes à habitação onde foi inserido o seu perfil. A figura 64 demonstra a sua página de

acesso.

Figura 64: Página de controlo para utilizadores do tipo admin.

O utilizador pode ainda aceder à base de dados e editar o seu perfil de utilizador e dos

utilizadores da sua rede como podemos verificar nas imagens 64:

66 Introdução

66

Figura 65: Página de acesso a base de dados para utilizadores do tipo admin.

Após aceder à página basta clicar no ícone de editar e será reencaminhado para a página de

edição do seu perfil para editar os seus dados com podemos ver na figura 66.

Figura 66: Página de edição do utilizador do tipo admin, Luisa.

Utilizadores do tipo técnico:

O utilizador do tipo técnico tem permissão para controlar todos os dispositivos de todas as

casas pertencentes à rede KNX, assim como a possibilidade de gerir toda a base de dados (editar,

pesquisar, eliminar e adicionar) da mesma rede. A apresentação deste perfil limita se à

apresentação básica das páginas principais, inicialmente a parte de controlo e por fim a base de

dados. A figura 67 é a imagem de controlo apresentada ao utilizador do tipo técnico, que lhe

permite escolher a casa a controlar, como se pode ver.

5.5 Controlo

Erro! A origem da referência não foi encontrada. 67

Figura 67: Página de controlo para utilizadores do tipo técnico e escolha da habitação a controlar.

Como se pode verificar na imagem da planta da habitação acima, a habitação ainda não está

identificada e é dada a possibilidade do utilizador escolher a habitação a controlar. A figura 68

representa a escolha da habitação 1.

Figura 68: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação1.

Como se pode verificar na planta da casa já aparece a identificação neste caso habitação 1: agora

será apresentada a imagem quando a escolha é a habitação 2.

68 Introdução

68

Figura 69: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação2.

Os comandos que serão de seguida apresentados representam os comandos enviados pelo

controlador para o Calimero comunicar com a rede KNX e executar os pedidos do utilizador:

Lâmpada 1 – on ( 192.168.0.20 3671 1.001 0.0.1 on 192.168.0.222), off ( 192.168.0.20 3671

1.001 0.0.1 off 192.168.0.222);

Lâmpada 2 - on ( 192.168.0.20 3671 1.001 0.0.2 on 192.168.0.222), off ( 192.168.0.20 3671

1.001 0.0.2 off 192.168.0.222);

Lâmpada 3 - on ( 192.168.0.20 3671 1.001 0.0.3 on 192.168.0.222), off ( 192.168.0.20 3671

1.001 0.0.3 off 192.168.0.222);

Lâmpada 4 - on ( 192.168.0.20 3671 1.001 0.0.4 on 192.168.0.222), off ( 192.168.0.20 3671

1.001 0.0.4 off 192.168.0.222);

Lâmpada 1_2 - on ( 192.168.0.20 3671 1.001 0.0.5 on 192.168.0.222), off ( 192.168.0.20

3671 1.001 0.0.5 off 192.168.0.222);

Lâmpada 1_2_3_4 - on ( 192.168.0.20 3671 1.001 0.0.6 on 192.168.0.222), off (

192.168.0.20 3671 1.001 0.0.6 off 192.168.0.222);

Os comandos representados acima são os mesmos para a habitação 1 e 2 pois como já referido

os dispositivos possuem os mesmos endereços físicos. Em cada lâmpada são apresentados os dois

comandos possíveis (on e off).

5.6 Base de dados

As figuras seguintes apresentam as diferentes possibilidades que o utilizador do tipo técnico poderá

usufruir para configurar a base de dados: contudo, apenas serão apresentadas as principais páginas

de cada opção.

Erro! A origem da referência não foi encontrada. 69

Habitação:

Figura 70: Página da base de dados para editar, adicionar, pesquisar e eliminar habitação.

Utilizador:

Figura 71: Página da base de dados para editar, adicionar, pesquisar e eliminar utilizadores

Dispositivo:

70 Introdução

70

Figura 72: Página da base de dados para editar, adicionar, pesquisar e eliminar dispositivos.

Datapoint:

Figura 73: Página da base de dados para editar, adicionar, pesquisar e eliminar Datapoints.

AddressGroup:

Erro! A origem da referência não foi encontrada. 71

Figura 74: Página da base de dados para editar, adicionar, pesquisar e eliminar endereços de grupo.

DispositivoAddressGroup:

Figura 75: Página da base de dados para editar, adicionar, pesquisar e eliminar relações entre um

dispositivo e um endereço de grupo (dispositivoaddressgroup).

72 Introdução

72

Capítulo 6

Conclusões

6.1 Conclusões

O objetivo desta dissertação era desenvolver um sistema a integrar na linha de produtos da

empresa NextToYou e, deste ponto de vista, constituiria uma evolução desses produtos (melhoria do

ponto de vista de funcionalidades oferecidas). A evolução que foi proposta foi a criação de um

sistema de gestão de domótica para a rede KNX já existente.

Os objetivos que foram propostos para esta dissertação foram completamente cumpridos com

sucesso e ainda garantindo a fiabilidade do sistema de gestão de domótica.

Foi criado um modelo de base dados que ao longo do processo de criação foi sofrendo várias

alterações, mediante os testes efetuados, conforme se iam descobrindo as falhas de conceção do

modelo relativamente ao protocolo KNX e às exigências da rede a implementar. Pode se dizer que o

processo exigiu um estudo aprofundado das exigências e necessidades do protocolo KNX, os tipos de

endereçamento e como o fazer, como atribuir funcionalidades aos dispositivos e de que forma se

tinham de processar. O modelo implementado teria de garantir que poderia ser implementado

numa qualquer rede KNX independentemente do seu tamanho e complexidade. Concluído este

processo e efetuados os testes necessários pode-se concluir que o modelo criado pode suportar uma

qualquer rede que siga o protocolo KNX.

A escolha da base de dados MySQL correspondeu às necessidades porque permitia a utilização

do modelo relacional concebido para o modelo de base de dados e demonstrou elevada

consistência, elevado desempenho, confiabilidade, para além de muito simples de utilizar.

A arquitetura Model-View-Controller revelou-se uma ótima escolha pois o trabalho foi

desenvolvido de forma modular. Isto permitiu que nunca tivesse de se parar o desenvolvimento do

sistema por qualquer problema, isto porque se ocorresse um qualquer problema nos diferentes

módulos podia sempre desenvolver um dos outros módulos sem o problema de compatibilidades e

ou erros pois os módulos eram independentes. Isto permitiu ganhar tempo e desenvolver uma

solução que pudesse ser alterada e evoluir em qualquer altura devido à sua modularidade. Esta

característica também ajudou na fase em que foi necessário detetar e corrigir erros pois como eram

módulos independentes era mais fácil de chegar ao erro e o poder corrigir. Esta modularidade

permitiu que facilmente se pudessem fazer alterações na camada View, para que esta se fosse

adequando e ficando com melhor apresentação e promovesse a usabilidade e captasse o interesse

do cliente. Esta arquitetura também permitiu que o projeto ficasse em aberto para qualquer

evolução em qualquer camada que o constitui, o que faz desta arquitetura de software uma boa

base para um projeto de software igual ou idêntico.

O sistema de gestão da base de dados foi plenamente conseguido ele permitia que o utilizador

sem formação alguma em base de dados conseguisse preencher a informação que o sistema de

gestão precisasse e ainda editar, pesquisar e eliminar qualquer dado da base dados sempre que não

violasse as restrições (do tipo de atributos, chaves estrangeiras, campos not nul, etc.) impostas

aquando da criação da base de dados. Basicamente pode-se se fazer quase tudo o que se faz na

base de dados do projeto só que de uma forma mais simples e intuitiva, o utilizador apenas está

limitado pelo facto de não poder mudar o modelo da base de dados e seus atributos.

A navegabilidade do sistema construído é simples e muito intuitiva tanto na gestão da base de

dados como na parte de controlo. Foi conseguido o objetivo de construir um sistema que

Erro! A origem da referência não foi encontrada. 73

promovesse a usabilidade, que fosse simples de utilizar, fosse útil e por fim eficaz ou seja com

poucos cliques executar uma determinada funcionalidade.

A criação do sistema de gestão da rede KNX foi conseguido na sua plenitude visto que no final

da dissertação, o sistema conseguia atuar sobre os quatro atuadores que a rede possuía e ler dos

quatro sensores que existiam na rede. Como foi desenvolvido segundo a arquitetura de software

modular e visto que as funcionalidades de escrever nos atuadores e ler dos sensores estão

implementadas e que a comunicação com a rede KNX se resume às funcionalidades de escrita e

leitura. Visto isto pode-se concluir que seria simples adicionar mais e diferentes módulos e

conseguir o completo controlo desse sistema pois teria pouco de novo a acrescentar visto já se

conseguir ler e escrever nos dispositivos existentes.

Porque o sistema possui funcionalidades que em caso de uso indevido poderia comprometer o

normal funcionamento do sistema foram criadas restrições de uso a certas funcionalidades a alguns

utilizadores. Para que a segurança do sistema e dos seus dados (dados da rede KNX e dos

utilizadores) não fosse comprometida, foram criados vários perfis de utilizador para diferentes tipos

de utilização e criadas restrições de acesso a determinadas funções e páginas segundo esses

diferentes tipos de perfis.

6.2 Desenvolvimentos futuros

O sistema de gestão de domótica desenvolvido foi um pequeno passo contudo importante para

o que se pode fazer no campo da gestão de domótica. Tendo como ponto de partida o que foi até

então feito e estudado poder-se-á chegar a um sistema mais complexo e bem mais completo. Os

próximos passos seriam adicionar mais dispositivos ao sistema mas com diferentes funcionalidades

para tornar o sistema mais abrangente e dotando-o da capacidade de ter um exemplo de software

para cada tipo de módulo existente na domótica KNX. Seria também de apostar na criação de mais

funcionalidades em Javascript para tratamento de formulários e promover a interatividade entre o

sistema e utilizador.

Com o âmbito de comercializar o produto seria necessário implementar mais segurança no

sistema (defesa contra intrusão e controlo indevido) e posteriormente criar um sistema para o

utilizador poder fazer o acesso remoto do sistema através da Internet.

O programa ETS4 concebido pela KNX para configurar uma rede KNX após a configuração da

rede cria um documento XML. Seria interessante e muito útil criar um módulo software que

convertesse esse ficheiro em dados que seriam úteis ao sistema e se possível que apenas através

deste ficheiro fosse possível criar a base de dados fundamental à rede e com a informação

necessária ao funcionamento de todo o sistema de gestão de domótica KNX. Este passo seria um

parsing de XML para a linguagem MySQL . Depois de todas estas melhorias o produto já podia ser

comercializado pois já ofereceria as funcionalidades que os sistemas de gestão de domótica

oferecem atualmente.

Referências

[1] Ciberdúvidas da Língua Portuguesa. Disponível em http://www.ciberduvidas.com/

/glossario.php. Acesso em 20/Maio/2008.

[2] Luís Grave Rodrigues, “Regras de escrita e gramática”. Disponível em

http://rprecision.blogspot.com/2008/02/regras-de-escrita-e-de-gramtica.html. Acesso

em 20/Maio/2008.

[3] “Regras para a Apresentação de Dissertações de Cursos de Mestrado da FEUP”, Faculdade

de Engenharia da universidade do Porto, Junho de 1995. [4] The EIB Association: The EIBA Handbook Series – Release 3.0, Brussels, 1998

[5] X-10, “Wireless solutions for 230 volts countries”. Disponível em

http://www.x10europe.com. Acesso em Junho /2011.

[6] The Konnex Association: KNX, The World’s First Open Standard For Home and Building

[7] Control – System Architecture, Brussels, July 2004.

[8]

[9] Wolfgang Kastner and Bernd Thallner: “A GPL Linux Device Driver for the EIB”, Technische

Universität Wien Institut für Rechnergestützte Automation, Treitlstraße 1, A-1040 Wien

[10] S. Avelar, “Protocolo EIB KNX”, Instituto Superior de Engenharia do Porto, Dezembro,

2007

[11] IEEE STD 830-1998, IEEE Recommended Practice for Software Requirements Specifications.

[12] Pedro Miguel de Miranda Fernandes, “Aplicações Domóticas para Cidadãos com Paralisia

Cerebral”, Tecnologia Domótica, Universidade de Aveiro, 2001.

http://portal.ua.pt/thesaurus/default1.asp?OP2=0&Serie=0&Obra=28&H1=1&H2=0 Acesso em Junho

/2011 .

[13] João Pedro Santos Silva, “Aplicação de Interface Com Sistema Domótico EIB”, Instituto

Superior Técnico

[14] Diana Sobreiro da Costa Palma, “FEUP KNX, Domótica KNX/EIB de Baixo Custo”, Faculdade

de Engenharia da Universidade do Porto

[15] Institute of Automation, Automation Systems Group - Calimero - EIBnet/IP Tunnelling

[16] (and more) for Java; Acedido pela última vez em 2009-06-28;

[17] URL:https://www.auto.tuwien.ac.at/a-lab/calimero.html;

[18] Boris Malinowsky, Georg Neugschwandtner, Wolfgang Kastner, “Calimero: Next

[19] Generation”, Novembro 2008;

[20] www.knx.org/pt. Acesso em Junho /2012.

[21] www.enei.net/ Acesso em Junho /2012.

[22] http://www.maujor.com Acesso em Junho /2012.

[23] http://www.w3schools.com Acesso em Junho /2012.

[24] http://www.domus.areadeservico.com/ Acesso em Junho /2012.

[25] http://www.logichome.pt/ Acesso em Junho /2012.

[26] http://www.ihome.pt/ Acesso em Junho /2012.

[27] http://pt.wikipedia.org Acesso em Junho /2012.

[28] http://www stackoverflow.com Acesso em Junho /2012.

Erro! A origem da referência não foi encontrada. 75

[29] http://php.net/ Acesso em Junho /2012.