sistema para automaÇÃo e controle residencial...

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO

SISTEMA PARA AUTOMAÇÃO E CONTROLE

RESIDENCIAL VIA TWITTER

EDUARDO FELIPPI GADOTTI

BLUMENAU 2010

2010/2-10




Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação— Bacharelado.

Prof. Miguel Alexandre Wisintainer, Mestre – Orientador

BLUMENAU 2010

2010/2-10



Por


Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Miguel Alexandre Wisintainer, Mestre – Orientador, FURB

______________________________________________________ Membro: Prof. Antonio Carlos Tavares, Mestre – FURB

______________________________________________________ Membro: Prof. Paulo Fernando da Silva, Mestre – FURB

Blumenau, 09 de dezembro de 2010.

Dedico este trabalho a ao meu orientador, família e namorada, que me apoiaram, incentivaram e ajudaram na realização deste.

AGRADECIMENTOS

Ao meu orientador Miguel Alexandre Wisintainer, por ter acreditado na idéia deste o

início, pelo auxílio, incentivo, atenção e amizade.

Aos meus pais, Auro Gadotti e Norma Gadotti, que sempre estiveram presente,

fornecendo apoio e incentivo, não somente no desenvolvimento deste trabalho, mas em todo o

decorrer da faculdade.

À minha namorada, Taruana Gomes, que ajudou com conselhos, incentivo, apoio em

momentos difíceis e vibrou junto nos momentos de conquista.

Aos meus amigos, que me ouviram atentamente e incentivaram desde o início.

Se a liberdade significa alguma coisa, será, sobretudo, o direito de dizer às outras pessoas o que elas não querem ouvir.

George Orwell

RESUMO

A automação residencial é o futuro para as casas inteligentes, portanto este trabalho demonstra uma solução para automatizar um ambiente, ligando ou desligando dispositivos eletrônicos, sem a necessidade da utilização de um computador pessoal. O mesmo tem como objetivo usar o meio de comunicação, o Twitter, que é uma rede social em rápida ascendência no mundo globalizado e que pode ser acessada através de qualquer dispositivo com acesso à internet ou até mesmo através de mensagem de celular. Para o sistema embarcado foi utilizado o hardware FEZ. O resultado obtido através desta automação é o controle de ligar e desligar dispositivos tais como lâmpadas, televisores, eletrodomésticos, computadores, entre outros eletrônicos à distância.

Palavras-chave: Domótica. Twitter. Microcontrolador. Automação.

ABSTRACT

Housing automation is the future for smart houses, so this study points out a solution to automate an environment by switching on or switching off electronic devices, without the need of a personal computer. This study aims at using the mean of communication Twitter, a social net which is spreading fast around the world and can be accessed through any device connected to the internet or even through a mobile phone message. For the embedded system was used the FEZ hardware. The result achieved through this automation is the control of switching on and switching off devices such as lights, televisions, domestic appliances, computers among other electronics at distance.

Key Words: Domotica, Twitter, Microcontroller, Automation

LISTA DE ILUSTRAÇÕES

Figura 1 – Cenário de envio de comando à residência. ......................................................... 14

Figura 2 - Diagrama do módulo Administrador. ................................................................... 23

Figura 3 – Diagrama do módulo do usuário. ......................................................................... 24

Figura 4 – Diagrama de classes. ........................................................................................... 25

Figura 5 – Diagrama de sequência. ....................................................................................... 27

Figura 6 – Métodos WebService. .......................................................................................... 28

Figura 7 – Tela inicial do sistema “TwitterGeradorToken”. .................................................. 30

Figura 8 – Preenchimento das credenciais para o sistema “TwitterGeradorToken”. .............. 30

Figura 9 – Obtendo Token´s para o sistema “TwitterGeradorToken”. ................................... 31

Figura 10 – Arquivo “Parametros.xml”. ............................................................................... 32

Figura 11 – Arquivo “Usuarios.xml”. ................................................................................... 32

Figura 12 – Arquivo “Equipamentos.xml” ........................................................................... 33

Figura 13 – Arquivo “Comandos.xml”. ................................................................................ 35

Figura 14 – Site oficial do Twitter. ....................................................................................... 37

Figura 15 – Aplicação TweetDeck para PC. ......................................................................... 38

Figura 16 – Aplicação TweetCaster para Android. ............................................................... 39

Figura 17 – Enviando mensagem via SMS. .......................................................................... 39

Figura 18 – Placa inferior FEZ Domino. .............................................................................. 40

Figura 19 – Placa superior Ethernet Shield. .......................................................................... 41

Figura 20 – Placa controladora CLPIC-628. ......................................................................... 44

Figura 21 – Diagrama de relação saídas digitais e relés. ....................................................... 44

Figura 22 – Estado do dispositivo, lâmpada desligada. ......................................................... 45

Figura 23 – Estado do dispositivo, lâmpada ligada. .............................................................. 45

Quadro 1 - Requisitos funcionais ......................................................................................... 21

Quadro 2 - Requisitos não funcionais ................................................................................... 22

Quadro 3 - Regras de negócios ............................................................................................. 22

Quadro 4 – Código fonte de acesso ao WebService .............................................................. 28

Quadro 5 - Código de associação de comando com dispositivos. .......................................... 34

Quadro 6 - Código de envio de sinais às saídas digitais. ....................................................... 34

Quadro 7 - Código fonte da interpretação e execução de comandos. ..................................... 36

Quadro 8 - Código fonte da das leituras de mensagens via socket. ........................................ 43

Quadro 9 – Descrição do caso de uso Edita Comandos. ........................................................ 51

Quadro 10 – Descrição do caso de uso Edita Restrições. ...................................................... 51

Quadro 11 – Descrição do caso de uso Edita Usuários. ........................................................ 52

Quadro 12 – Descrição do caso de uso Edita Senha .............................................................. 52

Quadro 13 – Descrição do caso de uso Edita Intervalo de Leitura de Mensagens .................. 53

Quadro 14 – Descrição do caso de uso Edita Cadeia de Comandos ...................................... 53

Quadro 15 – Descrição do caso de uso Envia Comando pelo Twitter ................................... 54

Quadro 16 – Descrição do caso de uso Obtem Mensagem de Retorno .................................. 54

Quadro 17 – Descrição do caso de uso Envia Cadeia de Comandos pelo Twitter .................. 54

Quadro 18 – Descrição do caso de uso Edita Equipamentos. ................................................ 55

LISTA DE SIGLAS

API – Application Programming Interface

FEZ – Freakin´ easy

HTTP - Hypertext Transfer Protocol

TCP - Transmission Control Protocol

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................. 13

1.1 OBJETIVOS DO TRABALHO .................................................................................... 14

1.2 ESTRUTURA DO TRABALHO .................................................................................. 15

2 FUNDAMENTAÇÃO TEÓRICA ................................................................................ 16

2.1 AUTOMAÇÃO RESIDENCIAL .................................................................................. 16

2.2 O TWITTER ................................................................................................................. 16

2.3 FRAMEWORK .NET ................................................................................................... 17

2.4 FEZ (GHI) .................................................................................................................... 18

2.5 CRIPTOGRAFIA HMAC-SHA1 .................................................................................. 19

2.6 TRABALHOS CORRELATOS .................................................................................... 19

3 DESENVOLVIMENTO ................................................................................................ 20

3.1 LEVANTAMENTO DAS INFORMAÇÕES ................................................................ 20

3.2 REQUISITOS DO SISTEMA ....................................................................................... 20

3.3 ESPECIFICAÇÃO ........................................................................................................ 22

3.3.1 Diagramas de caso de uso ........................................................................................... 23

3.3.2 Diagramas de classe .................................................................................................... 24

3.4 IMPLEMENTAÇÃO .................................................................................................... 26

3.4.1 Técnicas e ferramentas utilizadas ................................................................................ 26

3.4.1.1 Webservice gerenciador de mensagens ...................................................................... 27

3.4.1.2 Modo de autenticação “oAuth” ................................................................................. 29

3.4.1.3 Como gerar Token e TokenSecret ............................................................................. 29

3.4.2 Operacionalidade da implementação ........................................................................... 31

3.4.2.1 Editar parâmetros ..................................................................................................... 31

3.4.2.2 Editar usuários .......................................................................................................... 32

3.4.2.3 Editar equipamentos ................................................................................................. 33

3.4.2.4 Editar comandos ....................................................................................................... 35

3.4.2.5 Enviando uma mensagem ......................................................................................... 36

3.4.2.5.1 Utilizando a página oficial ................................................................................... 37

3.4.2.5.2 Utilizando cliente TweetDeck em um PC ............................................................. 37

3.4.2.5.3 Utilizando cliente TweetCaster em um smartphone Android ................................ 38

3.4.2.5.4 Utilizando um celular comum para envio de SMS ................................................ 39

3.4.2.6 Placa FEZ ................................................................................................................. 40

3.4.2.7 Placa CLPIC-628 ...................................................................................................... 43

3.4.2.8 Mudança de estados de um dispositivo elétrico ......................................................... 45

3.5 RESULTADOS E DISCUSSÃO ................................................................................... 46

4 CONCLUSÕES ............................................................................................................. 47

4.1 EXTENSÕES ............................................................................................................... 48

REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................. 49

APÊNDICE A – Detalhamento dos casos de uso .............................................................. 51

13

1 INTRODUÇÃO

A automação residencial é também conhecida como “Casa inteligente”, isto significa

controlar uma residência remotamente, como por exemplo, ligar ou desligar luzes,

dispositivos eletrônicos tais como ferro elétrico, televisão, panela elétrica, aparelho de som ou

até mesmo um condicionador de ar.

As soluções em automação residencial tornaram-se realidade e tem sido cada vez mais

procuradas para serem utilizadas não só em residências, mas também em escritórios e

ambientes corporativos. Trata-se de um sonho antigo e ambicioso, transformar um imóvel em

um grande robô controlado por um controle remoto à distância.

Infelizmente, este tipo de automação implica em uma série de regras e normas que

muitas vezes torna a solução inviável de ser instalada. Além disso, os altos custos envolvidos

e suas dificuldades de configuração e manuseio também são um fator agravante. Através do

desenvolvimento da solução proposta para automação através do Twitter, é possível quebrar

uma série de obstáculos apresentados pelos sistemas que utilizam um meio de comunicação

proprietária.

O Twitter é um serviço web onde é possível escrever mensagens públicas ou privadas

de até 140 caracteres. É possível realizar a leitura destas mensagens através de programas que

tenham acesso a internet, e então interpretar comandos pré-definidos pelo próprio usuário.

O objetivo de automatizar–se a residência é fazer com que ela seja controlada à

distancia, pela internet e de forma confiável. Este sistema de automação possibilita que este

controle seja feito através de qualquer dispositivo que tenha conexões com internet ou até

mesmo celulares que permitam o envio de SMS1, independente do tipo de equipamento ou

sistema operacional.

Na Figura 1 é demonstrado um cenário ao realizar um comando à residência

1 SMS. Short Message Service (Serviço de mensagem curta).

14

sd Visao Geral

Usuário

Residência

Placa FEZ

Env ia comando

WebServ ice

Twitter

Figura 1 – Cenário de envio de comando à residência.

11..11 OOBBJJEETTIIVVOOSS DDOO TTRRAABBAALLHHOO

O objetivo deste trabalho é apresentar uma solução para automação residencial

utilizando como forma de comunicação o Twitter, dispensando a contratação de um serviço

de protocolo de internet (IP2) fixo para a residência e um computador.

Os objetivos específicos do trabalho são:

a) controlar automação residencial através do Twitter;

b) utilizar um hardware chamado FEZ3 a fim de dispensar a utilização de um

computador;

c) desenvolver uma solução utilizando sensores e atuadores;

d) utilizar um WebService para comunicação e autenticação com o Twitter.

2 IP. Internet Protocol (Protocolo de internet). 3 FEZ. Freakin´ easy (hardware responsável pela lógica e processamento do sistema).

15

11..22 EESSTTRRUUTTUURRAA DDOO TTRRAABBAALLHHOO

Este trabalho está disposto em quatro capítulos. No primeiro capítulo apresenta-se a

introdução, os objetivos e a estrutura do trabalho.

No segundo capítulo tem-se a fundamentação teórica, destacando-se os conceitos sobre

a automação residencial, Twitter, Framework .Net, hardware FEZ e trabalhos correlatos.

No terceiro capítulo é apresentado o desenvolvimento do sistema, incluindo detalhes

sobre a especificação, implementação realizada e operacionalidade do mesmo.

No quarto capítulo apresenta-se a conclusão e sugestões para trabalhos futuros.

16

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo aborda um breve referencial teórico que norteará o desenvolvimento do

presente estudo, enfocando os aspectos sobre automação residencial, o Twitter, o Framework

.NET, o hardware FEZ, além dos trabalhos correlatos.

22..11 AAUUTTOOMMAAÇÇÃÃOO RREESSIIDDEENNCCIIAALL

Wortmeyer, Freitas e Líum (2005) e Automatic House (2010), afirmam que a

automação residencial é algo recente e está em franco crescimento nos últimos anos. Esse

processo começou como automação industrial, depois comercial e agora residencial.

Seu crescimento deve-se ao avanço das tecnologias, custos reduzidos dos componentes

e também pelo aumento da violência nas cidades, proporcionando assim maior segurança às

casas através do maior controle, monitoramento e a possibilidade de simular que há pessoas

na residência.

Através da automação residencial é possível ligar ou desligar luzes, geladeira,

microondas, televisão, computador, condicionador de ar, portão eletrônico, ferro elétrico,

panela elétrica, entre outros dispositivos eletrônicos.

Além da segurança, outros objetivos ao automatizar a residência são de proporcionar

conforto, praticidade, produtividade, economia, eficiência e valorização do imóvel. O

conceito de imóvel “inteligente” ou automação residencial também é definido muitas vezes

pelo termo “Domótica”.

22..22 OO TTWWIITTTTEERR

Plácido et al. (2009), definem o Twitter como uma rede social para troca de mensagens

instantâneas caracterizada como “micro blog”. Surgiu em 2006 e seu grande sucesso deve-se

a grande disponibilidade de mídia móvel (celular). As mensagens podem ser enviadas através

de SMS e as mesmas não podem ultrapassar 140 caracteres, que é aproximadamente o

17

tamanho de um SMS. Além de trocar mensagens pessoais, o Twitter pode ser usado com o

objetivo de divulgação de notícias, links, promoções, emprego, além do uso corporativo.

Ao escolher “seguir” uma pessoa, você passará a acompanhar as coisas que ela publicar ao passo que ela será notificada por email que você a está acompanhando e decidirá se quer seguir você também. Diferente, portanto, de sites como Orkut e Facebook, em que os usuários só têm uma lista de contatos, no Twitter você terá duas: uma com a relação das pessoas que te seguem (seguidores / followers) e outras com aqueles que você segue (following / seguidos). (SPYER, et all, 2009, p. 14).

O Twitter é uma ferramenta em crescimento e expansão, sendo o mais novo meio de

mídia móvel do mercado e também o mais popular. Seu grande sucesso deve-se à expansão

dos sistemas móveis, smartphones e a sua possibilidade de adaptação a estas novas

tecnologias.

Recentemente, foi alterado o modo de autenticação dos usuários a fim de que a

aplicação se torne mais segura e confiável, até mesmo superior à troca de mensagens por

correio eletrônico. Sendo assim, não é permitido armazenar a senha do usuário para ser usado

pelas aplicações clientes, é permitido somente armazenar uma chave criptografada que é

gerada a partir da autenticação do usuário e identificador da aplicação que a utilizará. Esta

chave é única para cada usuário e leva em consideração a chave da aplicação que também é

única e privada.

22..33 FFRRAAMMEEWWOORRKK ..NNEETT

De acordo com Microsoft (2010 b), o framework .NET trata-se de um componente

desenvolvido pela Microsoft que tem como objetivo fornecer um ambiente de programação

orientada a objetos que possa ser executado remotamente, minimizar conflitos de implantação

e versionamento, melhorar a experiência do desenvolvedor e integração com outros códigos.

O framework .NET pode ser hospedado por componentes não gerenciados que

carreguem o Common language Runtime4, criando-se assim um ambiente de software que

pode ser explorado.

O framework também disponibiliza uma biblioteca de classes orientada a objetos de

tipo reutilizáveis, reduzindo assim, o tempo associado à programação e aumentando a

4 Common language Runtime. Fundação do Framework. Gerência memória, comunicação remota e segurança.

18

facilidade de utilização. Além disso, possibilita a integração de classes de terceiro

desenvolvidos no mesmo framework.

Existe uma versão deste framework utilizado em sistemas embarcados, chamada Micro

Framework, cujas funções são mais limitadas. Esta plataforma de desenvolvimento é

adequada a hardware com capacidade reduzida, e é inclusive utilizada por sistemas de

robótica que optam pelo framework .Net.

22..44 FFEEZZ ((GGHHII))

De acordo com Tinyclr (2010), FEZ é uma placa específica baseadas em chipset

USBizi, que de acordo com GHI ELETRONICS (2010), suporta programas escritos sob a

plataforma Micro Framework .NET. É um hardware de baixo custo direcionado a iniciantes,

porém nada impede de ser utilizada de forma profissional. Ideal para sistemas embarcados,

suas placas são de proporções bastante reduzidas e possibilitam a ligação com diversos

componentes desenvolvidos pela própria empresa.

A placa FEZ é desenvolvida pela empresa Tinyclr e utiliza o chip da GHI Eletronics,

ambas as empresas situadas nos Estudos Unidos. Portanto, as atualizações e pacotes de

desenvolvimentos ficam a cargo da GHI Eletronics.

O hardware é composto por quatorze saídas digitais, seis saídas analógicas,

alimentação 5V e 3.3V, entrada MicroSD, USB Host, USB Client, USBizi Chip, alimentação

externa 6 a 12V e botões de reset e loader. Possui 521KB de memória flash e 98KB de

memória RAM, porém as aplicações dispõem apenas 100KB flash e 50KB RAM para uso.

A placa FEZ por ser integrada a outras placas ou componentes desenvolvidos pela

própria empresa, ou até mesmo por terceiros caso compatível. Estas placas são encaixadas na

parte superior, através dos pinos das saídas digitais e analógicas, sem a necessidade da

soldagem de componentes.

19

22..55 CCRRIIPPTTOOGGRRAAFFIIAA HHMMAACC--SSHHAA11

Esta criptografia é utilizada para realizar a geração dos Token´s do usuário, sendo uma

combinação do nome do usuário, senha, hora atual, entre outras variáveis. Pode ser

criptografadas chaves de qualquer tamanho, porém o resultado sempre será um hash de 160

bits.

HMACSHA1 é um tipo de algoritmo de hash com chave que é construído a partir da função hash SHA1 e usado como um HMAC, ou com base de autenticação de mensagem código hash. O processo HMAC mistura uma chave secreta com os dados da mensagem, hashes o resultado com a função hash, mistura que o valor de hash com a chave secreta de novo, então aplica a função hash uma segunda vez. O hash de saída é de 160 bits de comprimento. (MICROSOFT, 2010).

Qualquer alteração de dados ou o valor de hash irá resultar em uma incompatibilidade,

pois é necessário o conhecimento da chave secreta para alterar a mensagem e reproduzir o

valor de hash correto. Portanto, quando os valores de hash originais e computados

coincidirem, a mensagem é autenticada.

22..66 TTRRAABBAALLHHOOSS CCOORRRREELLAATTOOSS

Reiter Jr. (2006), desenvolveu uma aplicação no ambiente de desenvolvimento Delphi

para controlar dispositivos eletrônicos (estado liga/desliga). Este estudo tem como objetivo

realizar comunicação utilizando uma controladora com a porta Serial através do Windows ou

Linux. Não é necessária a utilização de um PC para seu funcionamento, porém esta

controladora não possui acesso a informações externas, como por exemplo, Internet.

Censi (2001) desenvolveu uma aplicação de automação residencial utilizando o correio

eletrônico como forma de monitoramento de comandos. O objetivo é realizar a leitura da

caixa de correio eletrônico de um determinado endereço procurando reconhecer comandos

previamente definidos para executar alguma ação.

Independente da utilização de um PC para funcionamento, esta aplicação foi

desenvolvida sob o hardware “Rabbit 2000 TCP/IP”, que de acordo com Rabbit (2010),

suporta a linguagem de programação “C” ou Assembly.

20

3 DESENVOLVIMENTO

Neste capítulo estão descritas as particularidades técnicas do sistema tais como a sua

descrição e a apresentação de seus requisitos funcionais e não funcionais, regras de negócio e

os principais diagramas de caso de uso e a sua descrição, de atividades, de classes, de

relacionamento e principais softwares utilizados.

33..11 LLEEVVAANNTTAAMMEENNTTOO DDAASS IINNFFOORRMMAAÇÇÕÕEESS

Ao automatizar-se uma residência é necessária a configuração do sistema como, por

exemplo, a decisão de quais equipamentos serão controlados, quais as restrições de acesso,

quais são os usuários que utilizarão e demais detalhes técnicos.

33..22 RREEQQUUIISSIITTOOSS DDOO SSIISSTTEEMMAA

O Quadro 1 apresenta os requisitos funcionais previstos para o sistema e sua

rastreabilidade, ou seja, vinculação com os casos de uso associados.

Requisitos Funcionais Caso de Uso

RF01. O sistema deverá permitir ao Administrador inserir, editar e excluir

comandos através da edição de arquivo XML.

UC01.01

RF02. O sistema deverá permitir ao Administrador relacionar comandos à

ações de automação através da edição de arquivo XML.

UC01.01

RF03. O sistema deverá permitir ao Administrador restringir os comandos à

Usuários do Twitter através da edição de arquivo XML.

UC01.04

RF04. O sistema deverá permitir ao Administrador configurar o tempo de

intervalo entre cada leitura de novas mensagens através da edição de

arquivo XML.

UC01.03

RF05. O sistema deverá permitir ao Administrador editar a senha do usuário UC01.02

21

"monitor" do Twitter através da edição de arquivo XML.

RF06. O sistema deverá permitir ao Administrador configurar os comandos

que receberá retorno de execução através da edição de arquivo XML.

UC01.01


uma cadeia de comandos. Execução de vários comandos a partir de um só

através da edição de arquivo XML.

UC01.05

RF08. O sistema deverá realizar a leitura de mensagens do Twitter para

identificar comandos a executar

UC02.01

RF09. O sistema deverá permitir ao Administrador inserir, editar, e excluir

usuários através da edição de arquivo XML.

UC01.06

RF10. O sistema deverá enviar mensagem através do Twitter de retorno

quando for necessário.

UC02.02

RF11. O sistema deverá permitir ao Usuário o envio de comandos em

cadeia.

UC02.03


equipamentos através da edição de arquivo XML.

UC01.07

Quadro 1 - Requisitos funcionais

O Quadro 2 lista os requisitos não funcionais previstos para o sistema.

Requisitos Não Funcionais

RNF01. O sistema deverá ter acesso à Internet.

RNF02. O sistema deverá ser desenvolvido sob a plataforma Micro Framework .Net v4.0

RNF03. O sistema deverá fazer a leitura das mensagens do Twitter através de um WebService.

RNF04. O sistema deverá utilizar a API do Twitter para realizar requisições e envio de

mensagens.

RNF05. O sistema deverá gravar um arquivo log do tipo ".txt" a cada execução de um

comando ou havendo erros.

RNF06. O sistema deverá gravar as configurações de comandos e parametros em arquivos do

tipo ".xml"

RNF07. O sistema deverá ser executado em um hardware da empresa GHIEletronics

denominado FEZ Domino.

RNF08. O sistema deverá realizar a comunicação externa através de protocolos TCP/IP

(Ethernet)

22

RNF09. O sistema deverá gravar em um arquivo do tipo ".txt" o identificador da ultima

mensagem lida.

Quadro 2 - Requisitos não funcionais

O Quadro 3 lista as regras de negócio previstas para o sistema.

Regras de Negócio

RN01. O sistema não deverá permitir mais de 150 requisições de leitura ou envio por hora.

RN02. O sistema não deverá permitir a execução de comandos que estejam restritos e que o

usuário não tenha permissão.

RN03. O sistema não deverá permitir a execução de comandos inativos.

RN04. O sistema não deverá enviar mensagens de retorno que ultrapassem 140 caracteres.

RN05. O sistema deverá interpretar comandos somente do tipo de mensagem configurada

pelo usuário.

RN06. O sistema deverá possibilitar a leitura de comandos a partir de mensagens diretas

(privadas).

RN07. O sistema não deverá permitir ler mensagens já lidas anteriormente.

RN08. O sistema deverá verificar mensagens para comandos somente do usuário configurado

no sistema.

RN09. Os log do sistema não poderão ultrapassar 1 (um) megabyte.

Quadro 3 - Regras de negócios

33..33 EESSPPEECCIIFFIICCAAÇÇÃÃOO

Esta seção apresenta os diagramas que serão necessários para o entendimento do

sistema de automação e comunicação com o Twitter. Para a especificação do sistema utilizou-

se a notação UML5, sendo os diagramas gerados através da ferramenta Enterprise Architect.

5 UML. Unified Modeling Language (Linguagem de modelagem unificada).

23

3.3.1 Diagramas de caso de uso

Esta sub-seção apresenta na Figura 2 e na Figura 3 os diagramas de casos de uso da

solução desenvolvida. Para melhor entendimento do sistema, os detalhamentos dos casos de

uso encontram-se no Apêndice A.

uc PCT01 - Módulo Administrador

Administrador

UC01.01 - Edita comandos

UC01.02 - Edita Senha

UC01.03 - Edita interv alo

de leitura de mensagens

UC01.04 - Edita restrições

UC01.05 - Edita cadeia

de comandos

UC01.06 - Edita

usuários

UC01.07 - Edita

Equipamentos

«extend»

Figura 2 - Diagrama do módulo Administrador.

24

Na Figura 3 são ilustradas as funcionalidades que o usuário comum utiliza para

automatizar a residência.

uc PCT02 - Usuário

Usuário

UC02.01 - Env ia

comando pelo Twitter

UC02.02 - Obtem

mensagem de retorno

UC02.03 - Env ia cadeia

de comando pelo Twitter

Figura 3 – Diagrama do módulo do usuário.

3.3.2 Diagramas de classe

Na Figura 4 apresenta-se o diagrama de classes. A solução desenvolvida não utiliza um

Sistema de Gerenciador de Banco de Dados (SGBD), portanto estas classes não representam

entidades no banco de dados, mas sim, estruturas de arquivos XML6 as quais são utilizadas

para manter as informações necessárias ao sistema.

Os nomes e atributos foram nomeados visando facilitar a leitura e o entendimento do

desenvolvedor.

6 XML. Extensible Markup Language.

25

class Diagrama de Classes

Comandos

- Id: int

- Descricao: char

- Comando: char

- EquipamentosId: int

- TipoComando: TipoComando

- EnviaRetorno: boolean

- RestricaoUsuarios: char

- DataCadastro: char

- Ativo: boolean

- ListaComandos: char

- EstadoEquipamento: boolean

Parametros

- Usuario: char {readOnly}

- Token: char

- TokenSecret: char

- Intervalo: int

- DataUltimaMensagemLida: char

- EnderecoIp: char

- MascaraIp: char

- GatewayIp: char

- EnderecoMacGateway: char

Mensagem

- Texto: char

- Data: char

- EnviadorPor: char

- EnviadorPorId: int

- Seguindo: boolean

«enumeration»

TipoComando

Simples

Encadeado

Usuarios

- Id: int

- Nome: char

- Email: char

- UsuarioTwitter: char

Equipamentos

- Id: int

- Descricao: char

«enumeration»

EstadoEquipamento

Liga

Desliga

1

0..*

1

0..*

0..* 0..*

Figura 4 – Diagrama de classes.

A função de cada classe de entidade está descrita a seguir:

a) classe Parametros - classe que possui os atributos referentes aos parâmetros

utilizados por todo o sistema;

b) classe Mensagem - classe que possui os atributos referentes às mensagens lidas do

Twitter;

c) classe Usuários - classe que possui os atributos referentes aos dados dos usuários

cadastrados no sistema de automação;

d) classe Comandos - classe que possui os atributos referentes aos comandos

cadastrados no sistema de automação;

e) classe Equipamentos - classe que possui os atributos referentes aos equipamentos

da residência;

f) classe TipoComando - tipo definido (enumeração, constantes do tipo int

nomeadas), com valores pré-estabelecidos para o reconhecer o tipo de comando a

ser executado;

26

g) classe EstadoEquipamentos - tipo definido (enumeração, constantes do tipo int

nomeadas), com valores pré-estabelecidos para o reconhecer o estado do

equipamento.

33..44 IIMMPPLLEEMMEENNTTAAÇÇÃÃOO

A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da

implementação.

3.4.1 Técnicas e ferramentas utilizadas

Para a implementação do sistema foi utilizado a ferramenta Microsoft Visual Studio

2008 que permite trabalhar com diversas linguagens da plataforma .Net, entre elas o C# que é

a linguagem na qual o sistema foi desenvolvimento. Sendo um sistema embarcado é

necessária a compilação do sistema em um framework mais compacto, chamado Micro

Framework, neste caso utilizado a versão 4.0.

O sistema realiza a comunicação externa através da Ethernet com protocolos TCP/IP,

sendo assim, é possível comunicar-se com um WebService para gerenciar as mensagens

recebidas e enviadas.

A Figura 5 ilustra como é realizada a comunicação entre o sistema embarcado e o

Twitter ao obter uma leitura de mensagem para então executar o comando de automação e

realizar o retorno ao usuário.

27

sd Business Process Model

Usuário

Sistema

embarcado (FEZ)

Webservice

gerenciador

Api Twitter Placa

controladora

(CLPIC)

Envia Mensagem()

Busca mensagens não l idas()

Busca mensgens não l idas()

Retona mensagens()

Retorna mensagens()

Executa comando()

Envia mensagem de retorno()

Envia mensagem()

Recebe mensagem()

Figura 5 – Diagrama de sequência.

3.4.1.1 Webservice gerenciador de mensagens

Foi necessário o desenvolvimento específico de um WebService, denominado

“TwitterGerenciador”, para auxiliar na comunicação entre o sistema embarcado e a API do

Twitter. O WebService tem como objetivo realizar a autenticação do usuário e retornar as

mensagens obtidas de modo otimizados, ou seja, filtra somente informações necessárias para

o sistema embarcado. Como resultado, a comunicação fica íntegra, segura, ágil e de fácil

manutenção.

Um Web Service é uma classe escrita em uma linguagem suportada pela plataforma .NET que pode ser acessada via protocolo http. Isso significa dizer que você pode acessar qualquer Web Service disponível na Web e utilizar todas as funcionalidades do mesmo. O acesso sempre será via http, mas internamente existe uma string XML que está empacotada em um protocolo SOAP (Simple Object Access Protocol). O SOAP é um padrão aberto criado pela Microsoft, Ariba e IBM para padronizar a transferência de dados em diversas aplicações, por isso, se dá em XML. (MICROSOFT, 2010 a).

28

Este WebService foi desenvolvido exclusivamente para realizar a comunicação entre o

sistema embarcado e o Twitter. Faz-se necessário a utilização deste intermediário devido a

uma alteração no modo de autenticação (oAuth) do usuário, utilizando criptografias (HMAC-

SHA1) com chaves públicas e privadas (Token e TokenSecret), criptografia a qual não é

suportada pelo hardware FEZ.

Esta aplicação é a responsável pela comunicação direta com o Twitter, enviando e

recebendo as mensagens do sistema embarcado, servindo assim como um intermediador. A

requisição a este sistema através do hardware FEZ é demonstrada no trecho de código fonte a

seguir no Quadro 4.

var url = "http://gadottisolucoes.com/

twittergerenciador/Gerenciador.asmx/BuscaMensagensDiretas?pSinceId=" +

pUltimaMsgId + "&pCount=1&pToken=" + pToken + "&pTokenSecret=" +

pTokenScret;

…

var serverIp = new byte[] { 174, 123, 78, 178 }; //servidor onde está o WS

…

//Realiza conexão com o socket

serverSocket.Connect(serverIp, 80);

System.Threading.Thread.Sleep(5000); //5 segundos

//Constroi o Header da mensagem

var request = BuscaHeader(url, referer, extraHeaders, requestMethod,

postContentType, postBody);

Quadro 4 – Código fonte de acesso ao WebService

Na Figura 6 encontram-se as funções publicadas neste WebService.

Figura 6 – Métodos WebService.

29

3.4.1.2 Modo de autenticação “oAuth”

De acordo com o Twitter (2010 b), oAuth é um protocolo de autenticação que permite

usuários aprovar uma aplicação cliente para interagir com seu usuário, obtendo e enviando

mensagens sem compartilhar a senha e assim proporcionando mais segurança a cada troca de

mensagem. Este processo é transparente ao usuário da aplicação, sendo responsabilidade da

mesma realizar este tipo de tratamento.

Este protocolo foi escolhido pela corporação do Twitter como oficial para todas as

aplicações que realizam a comunicação com sua API. No dia 16 de agosto de 2010 foram

desativadas as autenticações básicas, impedindo que a senha do usuário trafegue pela rede.

Também existe a opção de autenticação xAuth, que realiza a comunicação passando

diretamente a senha do usuário, porém o uso deste protocolo é mais restrito, e para ser usado

deve ser feita uma solicitação para a equipe da empresa, na qual explica-se as razões da

utilização deste protocolo e aguarda-se uma aprovação exclusiva à aplicação desejada.

3.4.1.3 Como gerar Token e TokenSecret

Para gerar as informações de Token e TokenSecret foi necessário o desenvolvimento de

outro programa denominado “TwitterGeradorToken”, sendo necessário executar o programa

em um computador com acesso à Internet. Este programa irá direcionar o usuário a uma

página do Twitter que informará qual o nome da aplicação a fim de liberar o acesso. Após

liberado, o programa irá gerar os Token baseados nos Token privados da aplicação, os quais

somente poderão ser usados com a aplicação liberada.

A geração destes Token é feita apenas uma única vez, desde que o usuário não mude

seu identificador ou senha. Não há data para expiração destas informações.

Na Figura 7 é ilustrada a tela inicial deste sistema.

30

Figura 7 – Tela inicial do sistema “TwitterGeradorToken”.

Na Figura 8, o usuário é direcionado diretamente à pagina do Twitter com o

identificador do sistema a ser liberado e com os campos para preenchimento das credenciais

do usuário.

Figura 8 – Preenchimento das credenciais para o sistema “TwitterGeradorToken”.

31

Após preenchimento das credenciais corretas do usuário e clicado no botão “Allow”,

ou seja, permitir acesso, então é mostrado um código chamado PIN. Este código deve ser

informado no campo livre abaixo e clicando no botão “Update” para gerar as informações de

Token´s que devem ser informadas no arquivo de parâmetros do sistema de automação.

Na Figura 9, é demonstrado o envio do código PIN e o recebimento das informações

de Token´s.

Figura 9 – Obtendo Token´s para o sistema “TwitterGeradorToken”.

3.4.2 Operacionalidade da implementação

Nesta sub-seção é apresentada a sequência de telas e operações para cada tipo de

usuário para conseguir utilizar corretamente o sistema de automação. Todos os arquivos de

configuração seguem o padrão XML e são armazenados no cartão de memória MicroSD na

placa FEZ, sendo possível alterações de seus registros sem a necessidade da compilação do

código fonte do sistema.

3.4.2.1 Editar parâmetros

No arquivo de parâmetros do sistema, o administrador deve definir variáveis

necessárias para que o sistema funcione corretamente. Na Figura 10, é ilustrado o formato do

arquivo de parâmentros.

32

Figura 10 – Arquivo “Parametros.xml”.

Este arquivo é a principal base de configuração do sistema, pois compõe as

informações do usuário monitor, senha (que é formado pelos campos “Token” e

“TokenSecret”, ambos criptografados para maior segurança), intervalo de leitura de

mensagem (que não deve ser inferior a 30 segundos) e os respectivos IP´s da rede em que o

sistema está atuando.

3.4.2.2 Editar usuários

Na Figura 11, é demonstrado o arquivo de usuário, onde o administrador pode manter

os usuários que utilizam o sistema de automação. Este arquivo tem como objetivo manter os

usuários documentados para posterior rastreamento caso seja necessário.

Figura 11 – Arquivo “Usuarios.xml”.

33

3.4.2.3 Editar equipamentos

No arquivo de equipamentos, o administrador deverá manter os equipamentos que

estão sendo automatizados na residência. Cada um deve possuir um código de identificação

única para ser relacionado junto ao comando e uma descrição para ser usada nas mensagens

de retorno e log´s para fácil entendimento do usuário.

O campo de identificador do comando é responsável pela associação com os

dispositivos eletrônicos, sendo sua numeração a correspondente com a sequência na placa

CLPIC.

Na Figura 12, é exemplificado um cadastro de equipamentos.

Figura 12 – Arquivo “Equipamentos.xml”

No quadro 5, encontra-se o código fonte que realiza esta associação e em seguida

como é realizado o envio do comando para a placa CLPIC.

Public bool Executa(Comando pComando, Saidas pSaidas)

{

try

{

switch (pComando.EquipamentosId)

{

case 1:

{

pSaidas.Tomada1.Write(pComando.EstadoEquipamento);

break;

34

}

case 2:

{


break;

}

case 3:

{


break;

}

case 4:

{


break;

}

case 5:

{


break;

}

}

return true;

}

catch (Exception ex)

{

//Grava log

Funcoes.EscreverLog(PathSd, “Erro de exceção ocorrido ao

executar comando ‘” + pComando.Nome + “’: “ + ex, 1, false);

return false;

}

}

Quadro 5 – Código de associação de comando com dispositivos.

No Quadro 6, é apresentado a classe de controle de saídas.

public class Saidas

{

public OutputPort Tomada1 { get; set; }





public Saidas()

{

//Inicia as saídas e indica o estado inicial

Tomada1 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di3, false);





}

}

Quadro 6 - Código de envio de sinais às saídas digitais.

35

3.4.2.4 Editar comandos

No arquivo de comandos, o administrador deve manter os comandos aceitos pela

automação. Cada um deve ter um identificador único para fácil identificação e controle pelo

sistema.

São configuráveis neste arquivo variáveis como descrição, nome (comando que será

identificado na mensagem recebida pelo Twitter), identificador do equipamento, tipo do

comando (simples ou encadeado), envio de mensagem de retorno após a execução, restrição a

usuários, lista de comandos (no caso de um comando encadeado) e estado do equipamento

(liga ou desliga).

Na Figura 13, é exemplificado um cadastro de comandos.

Figura 13 – Arquivo “Comandos.xml”.

36

No quadro 7, é demonstrado o código fonte responsável pela interpretação e execução

destes comandos.

//Verifica se encontra o nome do comando detro da mensagem

if (itemMensagem.Texto.IndexOf(itemcomando.Nome) >= 0)

{

//Verifica se há restrição para usuários

if (itemcomando.RestricaoUsuarios != string.Empty &&

!(itemcomando.RestricaoUsuarios.IndexOf(itemMensagem.EnviadoPor)

>= 0))

continue;

//Executa o comando

var retorno = itemcomando.TipoComando == TipoComandoEnum.Simples ?

Executa(itemcomando, pSaidas) :

ExecutaEncadeado(itemcomando, pSaidas);

//Verifica retorno da execução

if (retorno)

{

//Salva id da mensagem executada

Parametros.GravaUltimaMsgId(PathSd, itemMensagem.Id);

//Verifica necessidade de envio de retorno

if (itemcomando.EnviaRetorno)

Mensagem.EnviaMensagem(pToken, pTokenSecret,

itemMensagem.EnviadoPor, "Comando_" + itemcomando.Descricao +

"_executado_com_sucesso");

}

else

{

//Verifica necessidade de envio de retorno

if (itemcomando.EnviaRetorno)

Mensagem.EnviaMensagem(pToken, pTokenSecret,

itemMensagem.EnviadoPor, "Comando_" + itemcomando.Descricao +

"_nao_executado_Erro_de_execucao");

}

//Proxima mensagem

break;

}

Quadro 7 - Código fonte da interpretação e execução de comandos.

3.4.2.5 Enviando uma mensagem

A seguir alguns exemplos de possibilidades de enviar uma mensagem ao Twitter

independente do sistema operacional ou plataforma utilizada, podendo até mesmo utilizar

SMS dispensando assim a conexão com a internet e enviando a mensagem através de um

simples celular.

37

3.4.2.5.1 Utilizando a página oficial

Na Figura 14, utiliza-se a página oficial do Twitter (www.twitter.com) e seleciona-se a

opção “Message”, usada para o envio de mensagens privadas.

Figura 14 – Site oficial do Twitter.

Este site é compatível com os sistemas operacionais Windows, Mac OS e Linux e

suportado pelos principais navegadores como Internet Explorer, FireFox, Chrome e Opera.

3.4.2.5.2 Utilizando cliente TweetDeck em um PC

Na Figura 15, utiliza-se uma aplicação cliente que realiza a comunicação com o

Twitter. Existem versões para esta aplicação para os sistemas Mac, PC, Linux, iPhone, iPod

Touch, iPad e Android.

38

Figura 15 – Aplicação TweetDeck para PC.

3.4.2.5.3 Utilizando cliente TweetCaster em um smartphone Android

Na Figura 16, utiliza-se o cliente chamado TweetCaster para celulares com sistema

operacional Android. Não há custos para adquirir ou utilizar este aplicativo.

39

Figura 16 – Aplicação TweetCaster para Android.

3.4.2.5.4 Utilizando um celular comum para envio de SMS

Na Figura 17, utiliza-se um celular sem acesso à internet, enviando mensagem através

de SMS.

Figura 17 – Enviando mensagem via SMS.

40

3.4.2.6 Placa FEZ

Este hardware é responsável pela comunicação com o WebService, que por sua vez se

comunica com o Twitter. Também, ele interpreta os comandos e envia os sinais necessários

para a placa controladora CLPIC através de saídas digitais lógicas. Além da comunicação,

contém um cartão MicroSD que armazena todos os parâmetros necessários para o sistema.

Na figura 17 e 18 demonstra-se o hardware que é composto por 2 placas, a inferior

chamada de “FEZ Domino” contém o chip da GHI Eletronics, com suporte ao framework .Net

e na parte superior a placa chamada de “Ethernet Shield” responsável pela comunicação via

Ethernet.

Figura 18 – Placa inferior FEZ Domino.

Mini USB

USB Host

Alimentação externa 6 a 12V

MicroSD

Entradas e saídas digitais

Entradas e saídas analógicas

41

Na Figura 19, é demonstrado o hardware Ehternet Shield.

Figura 19 – Placa superior Ethernet Shield.

No quadro 8, é demonstrado no trecho de código fonte, como é realizada a conexão via

socket utilizando as placas FEZ e Ethernet Shield obtendo assim as mensagens do WebService

gerenciador.

public static byte[] WebRequest(string url, string referer,

string extraHeaders, string requestMethod,

string postContentType, string postBody)

{

byte[] mensagemRetorno = null;

//Trata Url

url = url.Substring(7);


var serverSocket = new

FEZ_Shields.Ethernet.uSocket(FEZ_Shields.Ethernet.uSocket.Protocol.TCP,

80);

var serverIp = new byte[] { 174, 123, 78, 178 }; //servidor onde está

o WebService

try

{

//Realiza conexão com o socket

serverSocket.Connect(serverIp, 80);

Saída Ethernet

Ligação “Terra” com a CLPIC

Saídas digitais ligadas à CLPIC

42


//Constroi o Header da mensagem

var request = BuscaHeader(url, referer, extraHeaders,

requestMethod, postContentType, postBody);

//Converte o Header para Array de Bytes

var bytesToSend = System.Text.Encoding.UTF8.GetBytes(request);

//Realiza o envio da requisição e verifica se está Ok.

if (serverSocket.Send(bytesToSend, bytesToSend.Length) > 0)

{


//Aguarda os dados

var timeoutInicial = DateTime.Now.AddSeconds(30);

while (serverSocket.AvilableBytes <= 0 && DateTime.Now <

timeoutInicial)

{

System.Threading.Thread.Sleep(500); //0,5 segundo

}

//Declara Buffer que será usado para as receber as partes da

mensgem

var buffer = new Byte[serverSocket.AvilableBytes];

//Realiza leitura do socket até encontrar o final da mensagem

// ou até o timeout limite de 60 segundos

var timeoutPrincipal = DateTime.Now.AddSeconds(60);

var finalMensagem = false;

//Realiza Loop até ler a mensagem completa

do

{

//Verifica se foi alterado seu tamanho

if (buffer.Length != serverSocket.AvilableBytes)

buffer = new Byte[serverSocket.AvilableBytes];

//Limpa Buffer antigo

Array.Clear(buffer, 0, buffer.Length);

//Recebe nova parte da mensagem

var bytesRead = serverSocket.Receive(buffer,

serverSocket.AvilableBytes);

//Verifica se foi lido algum byte

if (bytesRead > 0)

{

//Verifica se é a primeira leitura

if (mensagemRetorno == null)

{

//Retira o header da mensagem

buffer = RetiraHeader(buffer);

bytesRead = buffer.Length;

mensagemRetorno = new byte[buffer.Length];

}

else

{

//Aumenta o tamanho do array da mensagem

var temp = new byte[mensagemRetorno.Length];

Array.Copy(mensagemRetorno, temp,

43

mensagemRetorno.Length);

mensagemRetorno = new byte[temp.Length +

bytesRead];

Array.Copy(temp, mensagemRetorno, temp.Length);

//Limpa array não mais utilizado

Array.Clear(temp, 0, temp.Length);

}

//Copia a parte da mensagem lida para o Array

totalizador

Array.Copy(buffer, 0, mensagemRetorno,

mensagemRetorno.Length - bytesRead, bytesRead);

//Verifica se obteve final da mensagem ou se é método

de envio

if (Funcoes.BytesToString(buffer).IndexOf("</string>")

> 0)

finalMensagem = true;

}

//} while (bytesRead > 0 || serverSocket.AvilableBytes != 0);

} while (DateTime.Now < timeoutPrincipal && finalMensagem ==

false);

}

}

finally

{

try

{

//Desconecta o socket

serverSocket.Disconnect();

} catch (Exception){}

try

{

//Fecha a conexão independete de qualquer evento da rotina.

serverSocket.Close();

} catch (Exception){}

}

return mensagemRetorno;

}

Quadro 8 - Código fonte da das leituras de mensagens via socket.

3.4.2.7 Placa CLPIC-628

Esta placa é montada de acordo com a necessidade da residência, como neste trabalho

foi optado automatizar cinco dispositivos, então optou-se por uma placa que continha cinco

Relés. Esta placa recebe os comandos diretamente da placa FEZ que os executam.

Na Figura 20, é demonstrado a placa CLPIC-628.

44

Figura 20 – Placa controladora CLPIC-628.

Na figura 21, é ilustrada a relação entre as saídas digitais da placa FEZ com os relés da

placa CLPIC.

composite structure Driagrama de Blocos

Placa FEZ

Placa Ethernet

Shield Saída Digital 3

Saída Digital 7

Saída Digital 5

Saída Digital 8

Saída Digital 9

Placa CLPICRelé 1

Relé 2

Relé 3

Relé 4

Relé 5

Figura 21 – Diagrama de relação saídas digitais e relés.

Relés que controlam cada tomada

Entradas digitais vindas diretamente da placa FEZ

Alimentação externa 12V

45

3.4.2.8 Mudança de estados de um dispositivo elétrico

Demonstra-se aqui o resultado do envio de um comando para ligar e desligar uma

lâmpada. Na figura 22 é ilustrada uma lâmpada apagada.

Figura 22 – Estado do dispositivo, lâmpada desligada.

Após enviado um comando para o sistema de automação para que fosse ligada esta

mesma lâmpada, observa-se o resultado na Figura 23.

Figura 23 – Estado do dispositivo, lâmpada ligada.

46

33..55 RREESSUULLTTAADDOOSS EE DDIISSCCUUSSSSÃÃOO

O desenvolvimento deste sistema permitiu a automatização de dispositivos elétricos

utilizando uma ferramenta de rede social moderna e com segurança. Este sistema dispensa a

necessidade da contratação de serviços de IP fixa para a residência automatizada, visto que as

mensagens serão sempre enviadas ao Twitter e não especificamente à residência.

Não foi necessário o desenvolvimento de programas “clientes”, ou seja, programas

desenvolvidos especificamente para realizar a comunicação com o sistema embarcado. É

possível utilizar qualquer programa cliente que se comunique com o Twitter ou ainda através

de SMS. Sendo assim foi possível, por exemplo, ligar ou desligar uma lâmpada através de

qualquer tipo de celular, com ou sem comunicação com internet, e também utilizando

computadores com sistemas operacionais Windows, Linux ou Mac.

Foi possível também realizar uma automação mais segura em relação às automações

que utilizam e-mails, como a aplicação de Censi (2001), as quais são passíveis de falhas de

envio e recebimento, assim como problemas de spam. Enquanto e-mails são acessados de

forma direta através de qualquer aplicativo que tenha usuário e a senha do mesmo, nesta

automação a senha do usuário não é armazenada, logo a mesma não é trafegada pela rede,

aumentando assim a sua segurança. O Token utilizado para autenticação do usuário somente

será aceito se realizado através do sistema de automação que foi previamente cadastrado no

banco de dados da corporação do Twitter.

Portanto, alcançou-se o objetivo de desenvolver um sistema de automação utilizando a

rede social Twitter, garantindo a segurança, privacidade das mensagens e possibilitando o

envio de comandos através de multi-plataformas.

47

4 CONCLUSÕES

Neste trabalho provou-se que as redes sociais podem ser usadas de forma séria e

confiável, podendo ser utilizadas para realizar automações residenciais, dessa forma,

aproximando os usuários de sua realidade como navegadores da internet.

O sistema desenvolvido atendeu seus objetivos principais e específicos, realizando

assim uma automação que utiliza o Twitter como meio de comunicação e o hardware que

suporta a plataforma .Net orientada a objetos.

Este tipo de automação via Twitter mostrou-se também mais segura que uma

comunicação por e-mail, onde usuário e senha trafegam diretamente pela rede e não há

garantias de entrega da mensagem, ao contrário do Twitter.

Foi possível também reduzir os custos para o usuário final, caso o sistema venha a ser

comercializado, visto que não é necessário o desenvolvimento e a venda de um programa para

comunicação com o sistema de automação. Hoje, há programas clientes que realizam

comunicação com o Twitter sob diversas plataformas e sem custos. Também como o sistema

de automação busca as mensagens do servidor do Twitter não é necessário que a residência

possua um endereço de IP fixo.

Uma das grandes vantagens de se optar pelo Twitter é a comunicação com o sistema de

automação realizado através de multi-plataformas, não existindo limitação para sistema

operacional, seja para computadores ou celulares, ainda com a opção da comunicação via

SMS.

O desenvolvimento deste sistema permitiu a contribuição à comunidade destinada ao

hardware FEZ e a linguagem embarcada Micro Framework .Net, uma vez que não há nenhum

sistema similar. O sistema foi pioneiro neste tipo de comunicação gerando assim várias

dificuldades que foram necessárias ser transpostas, assim como, protocolos de comunicação

com a placa de conexão Ethernet e comunicação utilizando socket respeitando as limitações

de memória do hardware FEZ.

A automação baseada em mensagens recebidas pelo Twitter é o principal diferencial

do sistema, porem é também uma de suas limitações. O sistema é dependente deste serviço,

logo, caso o site não esteja online o sistema também não estará.

O protocolo de comunicação com a API do Twitter é passível de mudanças, que

acabou gerando atrasos e dificuldades durante o desenvolvimento do sistema. Para que fosse

possível transpor estas dificuldades com autenticações e criptografia dos dados foi necessário

48

o desenvolvimento de dois programas de apoio ao sistema de automação, um WebService para

realizar a comunicação com o Twitter e o hardware FEZ e outro sistema para gerar as chaves

de autenticação do usuário monitor (Token e TokenSecret).

Foi necessário o investimento de aproximadamente mil reais na construção do sistema,

entre importação do hardware FEZ e Ethernet Shield, componentes para a placa CLPIC e

componentes elétricos para montagem de tomadas que são utilizadas para exemplificação do

sistema.

O sistema foi um desafio desde sua implementação até a construção de seus

componentes físicos, um processo que demandou experiência e estudo na área de eletrônica.

Este estudo levou à aquisição de importantes conhecimentos em eletrônica e à ampliação dos

saberes em sistemas embarcados, especialmente no uso do Micro Framework .Net que está

em ascensão.

44..11 EEXXTTEENNSSÕÕEESS

Embora a implementação do sistema de automação ofereça a configuração externa dos

principais parâmetros, e não de forma fixa no programa, outras funcionalidades poderiam ser

desenvolvidas, entre elas:

a) desenvolvimento de um sistema gerenciador dos arquivos de configuração de

forma que a edição seja mais “amigável” ao administrador;

b) inclusão de um arquivo de configuração de cômodos do imóveis, de modo a criar

restrições aos usuários por estes cômodos;

c) inclusão de uma arquivo de configuração de agendamento de comandos, de modo a

possibilitar a execução programada ou recursiva sem a necessidade de estar

enviando um comando;

d) desenvolvimento da autenticação do usuário utilizando o método “xAuth”,

armazenando a senha direta do usuário;

e) desenvolvimento de um programa auxiliar mais intuitivo e específico para este

sistema, para que o administrador obtenha mais facilmente as informações de

Token e TokenSecret do usuário.

A criação destas funcionalidades implica em um sistema mais condizente com o

mercado e às necessidades dos usuários.

49

REFERÊNCIAS BIBLIOGRÁFICAS

AUTOMATIC HOUSE. O que é automação residencial. Sorocaba, 2010. Disponível em <http://www.automatichouse.com.br/AutomaticHouse/WebSite/Automacao/Residencial.aspx>. Acesso em: 23 set. 2010.

CENSI, Angela. Sistema para Automação e Controle Residencial via E-mail. 2001. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. Disponível em <http://campeche.inf.furb.br/tccs/2001-I/2001-1angelacensivf.pdf>. Acesso em: 2 out. 2010.

GHI ELETRONICS. USBizi100 Chipset. Clinton Twonship, 2010. Disponível em: < http://www.ghielectronics.com/product/117 >. Acesso em: 6 set 2010.

MICROSOFT. Classe HMACSHA1. [S.l.], 2010 a. Disponível em <http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.aspx>. Acesso em: 25 out. 2010.

MICROSOFT. Visão geral conceitual do .NET Framework. [S.l.], 2010 b. Disponível em <http://msdn.microsoft.com/pt-br/library/zw4w595w.aspx>. Acesso em: 2 set. 2010.

PLÁCIDO, André; ANSELMO, Camila; STANZANI, Caroline; BUARQUE, Danielle; SALOMÃO, Julian; LIMA, Luciana; YAMANE, Mônica; SANTOS, Pâmela; GALVANO, Thiago; LOPES, Vivianne. Conversao. [S.l.], 2009. Disponível em: <http://www.conversao.net/wp-content/uploads/2009/12/pasta_de_producao_conversao.pdf>. Acesso em: 2 abr. 2010.

RABBIT. Description. Davis, 2010. Disponível em <http://www.rabbit.com/products/rab2000/>. Acesso em: 7 maio 2010.

REITER JR, René Alfonso. Sistema de Automação Residencial com Central de Controle Micro Controladora e Independente de PC. 2006. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. Disponível em <http://campeche.inf.furb.br/tccs/2006-II/2006-2reneareiterjrvf.pdf>. Acesso em: 2 abr. 2010.

SPYER, Juliano; FERLA, Luiz Alberto; PAIVA, Moriael; AMORIM, Fabiola. Tudo o que você precisa saber sobre Twitter: você já aprendeu em uma mesa de bar. São Paulo: Talk Interactive, 2009.

TINYCLR. Your guide to embedded systems. [S.l.], 2010. Disponível em <http://www.tinyclr.com/>. Acesso em: 13 set. 2010.

50

TWITTER. Twitter REST API Method: oauth access_token for xAuth. [S.l.], 2010. Disponível em <http://apiwiki.twitter.com/w/page/23730780/Twitter-REST-API-Method:-oauth-access_token-for-xAuth>. Aceso em: 1 nov. 2010.

TWITTER. What is OAuth. [S.l.], 2010 b. Disponível em <http://dev.twitter.com/pages/oauth_faq>. Acesso em: 1 nov. 2010.

WORTMEYER, Charles; FREITAS, Fernando; LÍUM, Cardoso. Automação Residencial: Busca de Tecnologias visando o Conforto, a Economia, a Praticidade e a Segurança do Usuário. Resende, 2005. Disponível em <http://www.aedb.br/seget/artigos05/256_SEGET%20-%20Automacao%20Residencial.pdf>. Acesso em: 2 set. 2010.

51

APÊNDICE A – Detalhamento dos casos de uso

No Quadro 9 apresenta-se o caso de uso "Edita comandos".

Nome do Caso de Uso Edita Comandos

Descrição Administrador acessa o arquivo “Comandos.xml” para manter informações dos

comandos. São mantidos os dados: Identificador, Descrição, Nome, Identificador do

equipamento, Tipo de comando, Envio de retorno, Restrição de Usuários, Data de

Cadastro, Ativo, Lista de comandos e Estado do Equipamento.

Ator Administrador

Pré-condição Administrador deve ter acesso ao cartão Micro SD inserido no equipamento.

Fluxo principal 1. Arquivo informa comandos cadastrados;

2. Administrador opta por editar, apagar ou cadastrar um comando.

Cenário – Edição 1. Arquivo mostra comandos cadastrados;

2. Administrador seleciona um registro para edição;

3. Administrador altera registro e seleciona opção para salvar os dados;

4. Arquivo atualiza lista de comandos cadastrados.

Cenário – Inclusão 1. Arquivo mostra registros cadastrados;

2. Administrador inclui um novo registro;

3. Administrador seleciona opção para salvar os dados;


Cenário – Exclusão 1. Arquivo mostra registros cadastrados;

2. Administrador seleciona um registro para exclusão;



Pós-condição Administrador visualizou, editou, apagou ou cadastrou um comando.

Quadro 9 – Descrição do caso de uso Edita Comandos.

No Quadro 10 apresenta-se o caso de uso “Edita Restrições”.

Nome do Caso de Uso Edita Restrições

Descrição Administrador edita um Comando e seleciona a restrição de usuários. Usuários

informados nesta restrição é que somente terão permissão de executar o comando.

Ator Administrador

Pré-condição 1. Administrador deve editar um Comando;

2. Usuários devem estar previamente cadastrados.

Fluxo principal 1. Administrador seleciona os usuários que terão permissão;

2. Administrador salva alterações.

Pós-condição Administrador inseriu, editou ou removeu restrições de usuários.

Quadro 10 – Descrição do caso de uso Edita Restrições.

52

No Quadro 11 apresenta-se o caso de uso “Edita Usuários”.

Nome do Caso de Uso Edita Usuários

Descrição Administrador acessa o arquivo “Usuarios.xml” para manter dados dos usuários.

Serão mantidos os dados: Nome, E-mail e Usuário do Twitter.

Ator Administrador


Fluxo principal 1. Arquivo informa usuários cadastrados;

2. Administrador opta por editar, apagar ou cadastrar um usuário.

Cenário – Edição 1. Arquivo mostra registros cadastrados;


3. Arquivo mostra o nome, e-mail e usuário do Twitter;


5. Arquivo atualiza lista de usuários cadastrados.









Pós-condição Administrador visualizou, editou, apagou ou cadastrou um usuário.

Quadro 11 – Descrição do caso de uso Edita Usuários.

No Quadro 12 apresenta-se o caso de uso “Edita Senha”.

Nome do Caso de Uso Edita Senha

Descrição Administrador acessa o arquivo “Parametros.xml” e altera a senha do usuário

monitor.

Ator Administrador


Fluxo principal 1. Arquivo mostra parâmetros de Token e TokenSecret;

2. Administrador informa insere novo Token e TokenSecret;

3. Administrador seleciona opção para salvar os dados.

Pós-condição Administrador alterou a senha do usuário monitor.

Quadro 12 – Descrição do caso de uso Edita Senha

53

No Quadro 13 apresenta-se o caso de uso “Edita Intervalo de Leitura de Mensagens”.

Nome do Caso de Uso Edita Intervalo de Leitura de Mensagens

Descrição Administrador acessa o arquivo “Parametros.xml” e altera o intervalo de leitura de

mensagens.

Ator Administrador


Fluxo principal 1. Arquivo mostra parâmetro de intervalo de leitura de mensagens;

2. Administrador altera intervalo de leitura de mensagens;

3. Administrador seleciona opção para salvar os dados.

Pós-condição Administrador alterou o intervalo de leitura de mensagens.

Quadro 13 – Descrição do caso de uso Edita Intervalo de Leitura de Mensagens

No Quadro 14 apresenta-se o caso de uso "Edita Cadeia de Comandos".

Nome do Caso de Uso Edita Cadeia de Comandos

Descrição Administrador acessa o arquivo “Comandos.xml” para manter informações da

cadeia comandos.

Ator Administrador

Pré-condição 1. Administrador deve ter acesso ao cartão Micro SD inserido no equipamento;

2. Arquivo deve ter pelo menos dois comandos cadastrados.

Fluxo principal 1. Arquivo mostra comandos cadastrados;

2. Administrador opta por editar, apagar ou cadastrar uma cadeia comando.

Cenário – Edição 1. Arquivo mostra comandos cadastrados;







4. Arquivo atualiza os registros cadastrados.




4. Arquivo exclui o registro e atualiza os registros restantes.

Pós-condição Administrador visualizou, editou, apagou ou cadastrou uma cadeia comando.

Quadro 14 – Descrição do caso de uso Edita Cadeia de Comandos

54

No Quadro 15 apresenta-se o caso de uso "Envia Comando pelo Twitter".

Nome do Caso de Uso Envia Comando pelo Twitter

Descrição Usuário envia mensagem para usuário monitor do sistema através do Twitter para

executar um comando.

Ator Usuário

Pré-condição 1. Usuário deve ter acesso ao Twitter ou a um meio de transmissão de SMS;

2. Sistema deve ter pelo menos um comando cadastrado.

Fluxo principal 1. Usuário envia mensagem de texto com identificação do comando;

2. Sistema interpreta comando e executa ação pré-definida.

Pós-condição Usuário enviou um comando para ser executado.

Quadro 15 – Descrição do caso de uso Envia Comando pelo Twitter

No Quadro 16 apresenta-se o caso de uso "Obtem Mensagem de Retorno".

Nome do Caso de Uso Obtem mensagem de retorno.

Descrição Usuário recebe mensagem de retorno do comando enviado

Ator Usuário

Pré-condição 1. Usuário deve ter acesso ao Twitter;

2. Usuário deve ter enviado pelo menos um comando que envie retorno.

Fluxo principal Usuário verifica mensagens recebidas pelo usuário monitor do sistema.

Pós-condição Usuário recebeu uma mensagem de retorno.

Quadro 16 – Descrição do caso de uso Obtem Mensagem de Retorno

No Quadro 17 apresenta-se o caso de uso "Envia Cadeia de Comandos pelo Twitter".

Nome do Caso de Uso Envia cadeia de comandos pelo Twitter.

Descrição Usuário envia mensagem para usuário monitor do sistema através do Twitter para

executar uma cadeia de comandos.

Ator Usuário

Pré-condição 1. Usuário deve ter acesso ao Twitter ou a um meio de transmissão de SMS;

2. Usuário deve ter pelo menos uma cadeia de comandos cadastrada.

Fluxo principal 1. Usuário envia mensagem de texto com identificação da cadeia de comandos;

2. Sistema interpreta cadeia de comandos e executa ações pré-definidas.

Pós-condição Usuário enviou uma cadeia de comandos para ser executado.

Quadro 17 – Descrição do caso de uso Envia Cadeia de Comandos pelo Twitter

55

No Quadro 18 apresenta-se o caso de uso “Edita Equipamentos”.

Nome do Caso de Uso Edita Equipamentos

Descrição Administrador acessa o arquivo “Equipamentos.xml” para manter dados dos

equipamentos. Serão mantidos os dados: Identificador do equipamento e Descrição.

Ator Administrador


Fluxo principal 1. Arquivo mostra equipamentos cadastrados;

2. Administrador opta por editar, apagar ou cadastrar um equipamento.

Cenário – Edição 3. Arquivo mostra registros cadastrados;



6. Arquivo atualiza lista de equipamentos cadastrados.




10. Arquivo atualiza lista de equipamentos cadastrados.




14. Arquivo exclui o registro e atualiza os registros restantes.

Pós-condição Administrador visualizou, editou, apagou ou cadastrou um equipamento.

Quadro 18 – Descrição do caso de uso Edita Equipamentos.

sistema para automaÇÃo e controle residencial...

Documents