Post on 18-Jan-2019
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
EDUARDO FELIPPI GADOTTI
SISTEMA PARA AUTOMAÇÃO E CONTROLE
RESIDENCIAL VIA TWITTER
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
SISTEMA PARA AUTOMAÇÃO E CONTROLE
RESIDENCIAL VIA TWITTER
Por
EDUARDO FELIPPI GADOTTI
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
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
RF07. O sistema deverá permitir ao Administrador inserir, editar e excluir
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
RF12. O sistema deverá permitir ao Administrador inserir, editar e excluir
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:
{
pSaidas.Tomada2.Write(pComando.EstadoEquipamento);
break;
}
case 3:
{
pSaidas.Tomada3.Write(pComando.EstadoEquipamento);
break;
}
case 4:
{
pSaidas.Tomada4.Write(pComando.EstadoEquipamento);
break;
}
case 5:
{
pSaidas.Tomada5.Write(pComando.EstadoEquipamento);
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 OutputPort Tomada2 { get; set; }
public OutputPort Tomada3 { get; set; }
public OutputPort Tomada4 { get; set; }
public OutputPort Tomada5 { get; set; }
public Saidas()
{
//Inicia as saídas e indica o estado inicial
Tomada1 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di3, false);
Tomada2 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di7, false);
Tomada3 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di5, false);
Tomada4 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di8, false);
Tomada5 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di9, 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);
System.Threading.Thread.Sleep(5000); //5 segundos
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
System.Threading.Thread.Sleep(5000); //5 segundos
//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)
{
System.Threading.Thread.Sleep(5000); //5 segundos
//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;
4. Arquivo atualiza lista de comandos cadastrados.
Cenário – Exclusão 1. Arquivo mostra registros cadastrados;
2. Administrador seleciona um registro para exclusão;
3. Administrador seleciona opção para salvar os dados;
4. Arquivo atualiza lista de comandos cadastrados.
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
Pré-condição Administrador deve ter acesso ao cartão Micro SD inserido no equipamento.
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;
2. Administrador seleciona um registro para edição;
3. Arquivo mostra o nome, e-mail e usuário do Twitter;
4. Administrador altera registro e seleciona opção para salvar os dados;
5. Arquivo atualiza lista de usuários 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;
4. Arquivo atualiza lista de usuários cadastrados.
Cenário – Exclusão 1. Arquivo mostra registros cadastrados;
2. Administrador seleciona um registro para exclusão;
3. Administrador seleciona opção para salvar os dados;
4. 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
Pré-condição Administrador deve ter acesso ao cartão Micro SD inserido no equipamento.
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
Pré-condição Administrador deve ter acesso ao cartão Micro SD inserido no equipamento.
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;
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;
4. Arquivo atualiza os registros cadastrados.
Cenário – Exclusão 1. Arquivo mostra registros cadastrados;
2. Administrador seleciona um registro para exclusão;
3. Administrador seleciona opção para salvar os dados;
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
Pré-condição Administrador deve ter acesso ao cartão Micro SD inserido no equipamento.
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;
4. Administrador seleciona um registro para edição;
5. Administrador altera registro e seleciona opção para salvar os dados;
6. Arquivo atualiza lista de equipamentos cadastrados.
Cenário – Inclusão 7. Arquivo mostra registros cadastrados;
8. Administrador inclui um novo registro;
9. Administrador seleciona opção para salvar os dados;
10. Arquivo atualiza lista de equipamentos cadastrados.
Cenário – Exclusão 11. Arquivo mostra registros cadastrados;
12. Administrador seleciona um registro para exclusão;
13. Administrador seleciona opção para salvar os dados;
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.