Universidade Tecnológica Federal do Paraná – UTFPR

Departamento Acadêmico de Eletrônica – DAELN

Departamento Acadêmico de Informática – DAINF

Engenharia de ComputaçãoOficina de Integração 3 (IF66J) – S71 – 2015/1

Relatório TécnicoPantheon: automação residencial utilizando

rede Wi-Fi

Bruno Campera – brunocmpr@gmail.com

Lucas T. Godoi – ltg_fdh@hotmail.com

Renan T. Nakashima – renan.taizo@gmail.com

Rui P. Leite – ruipimentelleite@gmail.com

Julho de 2015

Resumo

Recentemente, sistemas de automação de residências vêm sendo empre-gados para a melhoria ou customização de soluções nestes ambientes.Apesar disso, produtos desta natureza permanecem longe da maior partedas residências. Este trabalho apresenta um sistema de automação resi-dencial de custo relativamente baixo, customizável e de fácil instalaçãoe operação. A solução proposta inclui as placas controladoras popula-res Arduino e Raspberry Pi 2, o módulo transceptor serial–Wi-Fi Espres-sif ESP8266 ESP01, a plataforma de software NodeJS e um protocolo deaplicação proprietário, implementado pela equipe sobre a pilha TCP/IP.Além da especificação e do desenvolvimento do sistema, três aplicaçõesdemonstrativas de conceito foram construídas.

1 Introdução

Recentemente, as tecnologias de comunicação vêm ficando cada vez mais aces-síveis e populares. Dispositivos Wi-Fi, por exemplo, hoje são bastante difundi-dos e apresentam diversos formatos e funcionalidades. De computadores portá-teis a aparelhos domésticos antes desconectados — como televisores e geladei-ras, por exemplo —, consolida-se atualmente uma forte tendência ao compar-tilhamento de informações e à automatização de tarefas através de máquinasinteligentes.

Além de mercados muito lucrativos e em franca expansão, as sub-áreas daautomação residencial e da IOT — sigla em inglês para Internet of Things (Inter-net das Coisas) — proporcionam ainda novos produtos que chegam para suprirnecessidades cuja solução, há alguns anos, era por vezes muito custosa ou de-masiado complexa do ponto de vista técnico; a gama de dispositivos de comuni-cação digital hoje disponível, em especial os da categoria wireless (sem fio), em

1

Relatório Técnico: Pantheon 2

conjunto com plataformas de prototipagem eletrônica de hardware e software— e.g. Arduino e Raspberry Pi (RPi) —, vem permitindo até aos usuários semformação em eletrônica ensaiar sistemas simples com um custo acessível. Por-tadores de necessidades especiais de deslocamento, para citar apenas um exem-plo, podem hoje — a partir de suas experiências e dificuldades particulares —inspirar, sugerir e até mesmo projetar [Hac] pequenos sistemas de automaçãode tarefas totalmente customizados, aumentando consideravelmente sua qua-lidade de vida.

Com tudo isso em vista, a equipe deste projeto propõe, nas seções a seguir,uma tecnologia de automação residencial baseada em:

• Equipamento de rede wireless padrão;• Placas microcontroladoras populares (a saber: Raspberry Pi 2 e Arduino

Mega);• Módulos transceptores serial–Wi-Fi de baixo custo (ESP8266);• Protocolo para propagação de valores de parâmetros, desenvolvido pela

equipe.

Como requisitos de projeto, foram identificados:• O sistema deverá possuir um painel de controle acessível através de dis-

positivos móveis;• O sistema deverá permitir a inserção e remoção de contas de usuário do

painel de controle;• O sistema deverá suportar a instalação de novos pacotes de dispositivos

ou remover pacotes antigos;• O sistema deverá possuir opções de configuração de pacotes de instalação

dos dispositivos;• O sistema deverá exibir ao usuário, através do painel de controle, dados

entregues por aparelhos instalados e sincronizados na rede de automaçãoresidencial;

• O sistema deverá sincronizar dados dos dispositivos com o painel de con-trole;

• O sistema deverá permitir ao usuário enviar instruções (comandos), atra-vés do painel de controle, aos dispositivos que estejam instalados e sin-cronizados na rede de automação residencial;

• O sistema deverá permitir a programação de eventos para efetuar o co-mando programado no dispositivo desejado.

Como características-chave do projeto, destacam-se:• Interface gráfica com o usuário unificada, de fácil assimilação e acessível

através de qualquer dispositivo Wi-Fi com navegador de Internet;

Relatório Técnico: Pantheon 3

• Enfoque na utilização por usuários com reduzido conhecimento técnico;• Redução considerável do esforço necessário para desenvolvimento futuro

de novos produtos inteligentes baseados neste projeto.

A tecnologia de automação residencial proposta, batizada pela equipe de"Pantheon", estende as funcionalidades de uma rede wireless simples e organiza-se conceitualmente a partir de componentes de três classes principais: i) Umaestação base chamada de "Estação Zeus"(detalhada na seção 2), única em cadarede doméstica de automação, e responsável pela descoberta de dispositivos epela persistência de dados; ii) Um ou mais aparelhos residenciais (eletrodomés-ticos, por exemplo) equipados com um módulo especial chamado de "MóduloHermes"(abordado em maior profundidade na subseção 3.2), que viabiliza a in-tegração do aparelho à rede; iii) Um ou mais usuários, que interagem com aEstação Zeus e com os Módulos Hermes através do navegador de Internet dosdispositivos Wi-Fi tradicionais, em uma interface gráfica dinâmica ("InterfaceOráculo") servida ao usuário pela Estação Zeus.

Apesar do conceito voltar-se para a comunicação entre as três classes prin-cipais, a tecnologia não dispensa o uso do roteador sem-fio comum — ou SOHO(sigla para Small Office Home Office), como vêm sendo chamados os dispositi-vos voltados para o uso em escala reduzida. Além disso, para os aparelhos re-sidenciais desprovidos de uma interface que possibilite a configuração de pa-râmetros da conexão à rede (tradicionalmente, SSID e chave), faz-se necessáriotambém um dispositivo facilitador de configuração (detalhado na seção 2, e ba-tizado pela equipe de "Adaptador Hermes–USB").

A Figura 1 apresenta um diagrama da visão geral do sistema, com os compo-nentes anteriormente mencionados. O roteador sem-fio, apesar de não exibido,providencia a comunicação entre os dispositivos móveis, a estação base e osaparelhos residenciais e, portanto, assume importante papel no sistema.

Quanto ao escopo da Tecnologia Pantheon, a comunicação entre o usuárioe o aparelho doméstico visa a consulta e a alteração de parâmetros, processosestes possíveis graças à participação da estação base. O usuário pode visualizaro estado de seus aparelhos domésticos através da Interface Oráculo, bem comosolicitar alterações em determinados parâmetros. Um protocolo binário (HP3),também proposto pela equipe e abordado na seção 4, possui a finalidade detransmitir as requisições de consulta (GET) ou alteração (SET) de valor por partedo usuário, bem como de devolver a resposta (RESPONSE) ou falha (ERROR)emitida pelo aparelho doméstico.

2 Estação base

A estação base do projeto é constituída de um RPi 2 (Modelo B) [Rasa], com asseguintes características principais: processador ARM Cortex-A7 (quad core de

Relatório Técnico: Pantheon 4

Figura 1: Representação conceitual da rede de automação residencial Pantheon.

900MHz), memória RAM de 1GB, alimentação via entrada µUSB, porta Ether-net comum e 4 portas USB — das quais uma foi utilizada para interface comum adaptador Wi-Fi–USB. Em relação à alimentação, apesar de existirem outrasopções, a equipe decidiu pela aquisição de uma fonte de 3A com saída µUSBpois, além de possuir custo razoável, oferece maior estabilidade à corrente con-sumida pelo dispositivo.

Através de um cabo Ethernet comum, o usuário pode acessar uma página es-pecial (desenvolvida pela equipe), armazenada no Raspberry, capaz de exibir asredes wireless disponíveis, bem como a rede atual (se houver). De maneira grá-fica e descomplicada, pode-se então alterar a rede sem fio à qual a Estação Zeusse manterá conectada, bastando para tal preencher o campo de senha quandosolicitado.

De maneira complementar, o módulo Adaptador Hermes–USB também foidesenvolvido pela equipe para permitir que o usuário final configure com maiorfacilidade seus aparelhos domésticos para ingresso à rede residencial WLAN.A função do adaptador é (conforme exibido na Figura 2) realizar o interface-amento entre a porta USB da estação base (com o auxílio de um cabo Mini-USB–USB) e os pinos do módulo ESP8266. Basta que o Módulo Hermes sejainserido nos pinos de entrada do Adaptador, na posição indicada na Figura 3, eque o cabo auxiliar seja conectado, então, a uma das portas do Raspberry Pi 2.Na mesma interface gráfica de configuração de wireless, descrita anteriormentenesta seção, uma nova opção convidará o utilizador a requisitar o ingresso doMódulo Hermes à mesma rede Wi-Fi em que a Estação Zeus se encontra.

Quanto ao software, o Raspberry Pi 2 é capaz de executar boa parte dos sis-temas operacionais comuns existentes; a equipe, no entanto, preferiu instalar

Relatório Técnico: Pantheon 5

Figura 2: Diagrama ilustrativo do papel do Adaptador Hermes–USB.

neste dispositivo uma distribuição derivada do Debian e especialmente custo-mizada para o gadget: o Raspbian [Rasb]. Com ferramentas úteis (como o des-compactador de unidade de disco, capaz de liberar o espaço da memória flashde instalação para uso comum) e mais otimizado, este SO conta ainda com boadocumentação, comunidade de desenvolvedores bastante ativa e as ferramen-tas mais utilizadas do Debian, a exemplo do package manager padrão.

Sobre este ambiente, foram instalados, então, a plataforma NodeJS [Nod](que permite a criação de programas interpretados em linguagem JavaScript),o banco de dados não-relacional MongoDB [Mon] (que facilita consultas e re-gistros na Notação de Objetos do JS, ou JSON, como é mais conhecida), a fer-ramenta NMAP [NMA] (capaz de executar descobertas de dispositivos na redelocal) e outros softwares facilitadores de camada entre os já citados. Dentre osprogramas desenvolvidos sobre o NodeJS, encontram-se a Interface Oráculo, oalgoritmo de descoberta (vide subseção 3.2 e de registro em tabela dos clientesHP3 ativos, e os scripts necessários à operação do adaptador USB–Hermes.

3 Clientes do serviço

Os clientes do Servidor Zeus consomem basicamente dois tipos de dados: pá-ginas web, no caso do usuário final, e mensagens HP3, no caso dos aparelhosdomésticos equipados com Módulo Hermes. O primeiro tipo corresponde, naFigura 1, aos dispositivos móveis equipados com browser; na mesma figura, es-tão ilustrados também os Módulos Hermes e seus respectivos aparelhos domés-ticos, que correspondem aos clientes HP3. Ambos os tipos de clientes são des-critos a seguir.

Relatório Técnico: Pantheon 6

Figura 3: Foto do Adaptador Hermes–USB já com o Módulo Hermes e o cabo Mini-USB–USB.

3.1 Clientes HTTP

No protocolo HTTP, o browser do dispositivo do usuário atua como requisitante(cliente), enquanto um servidor HTTP (no caso específico do Projeto Pantheon,implementado dentro do NodeJS) fica responsável pelo atendimento das solici-tações, servindo páginas estáticas e dinâmicas conforme requisitado.

As interfaces gráficas fornecidas pelas páginas permitem aos clientes HTTP:• Definir a rede wireless para a Estação Zeus;• Integrar Módulos Hermes à rede sem fio onde a estação base reside;• Realizar login no painel de controle (Interface Oráculo);• Visualizar e atuar sobre o status dos aparelhos domésticos ativos e conhe-

cidos;• Realizar upload de DAs para aparelhos domésticos ativos desconhecidos.

Relatório Técnico: Pantheon 7

3.2 Clientes HP3

Os clientes de protocolo HP3 (discutido na seção 4) são os aparelhos domésticosque possuem um Módulo Hermes integrado. Estes módulos, em si, são consti-tuídos de módulos Espressif ESP8266 ESP01 (2ª geração) [Esp], que possuemuma interface Wi-Fi 802.11b/g/n e outra UART, permitindo ao seu dispositivohost configurar o módulo e receber/enviar mensagens TCP. No caso específicodo Arduino, por exigir 5V de nível lógico alto — o que viola os 3,3V propostospela interface de pinos do módulo ESP8266 —, foram necessários, ainda, cir-cuitos conversores de tensão, denominados buffers (um para o sentido Zeus–Hermes, outro para o sentido Hermes–Zeus, conforme Figura 4). Ainda no que-sito de hardware, o módulo chega a consumir 300mA (segundo testes de outrosusuários), o que exige especial atenção de potenciais fabricantes de produtossegundo a tecnologia proposta pela equipe. Para as aplicações demonstrativasde conceito (detalhadas na seção 5), uma alimentação exclusiva (com reguladorde tensão LM1117, conforme Figura 5) foi empregada em cada Módulo Hermes.Salvas as observações acima, o microcontrolador da preferência de cada fabri-cante pode ser utilizado no aparelho doméstico, ou seja, não é obrigatório queo Arduino seja o controlador da aplicação cliente HP3.

Figura 4: Diagrama da PCB dos circuitos integrados de buffer, utilizados para conver-são de lógica 3,3V para 5V e vice-versa.

No que tange ao software, o módulo ESP8266 é vendido com um firmwarepadrão, o qual foi mantido pela equipe (apesar da possibilidade de substitui-ção por outros firmwares e/ou customização do programa). O firmware padrão,então, permite interação com a interface serial através de comandos AT [Nur],os quais podem ser utilizados para configurar o módulo e para enviar e recebermensagens TCP e UDP. Para tal, é pré-requisito que o módulo seja ingressado narede wireless doméstica, mediante envio de SSID e chave através dos já citados

Relatório Técnico: Pantheon 8

comandos AT (via serial) por parte do Adaptador Hermes–USB. Uma vez devi-damente ingressado à rede, o dispositivo disponibiliza duas opções para trocade mensagens TCP: a conexão em papel de cliente a um socket TCP já estabele-cido na rede (em papel servidor, e mediante prévio conhecimento do endereçoIP deste host), ou a abertura de um novo socket TCP (em papel servidor) nopróprio módulo.

Figura 5: Diagrama esquemático do circuito regulador de tensão 3,3V para alimentaçãodos módulos ESP8266. Adaptado de [STM].

Uma vez que a descoberta de rede é mais facilmente implementada em ladoservidor HP3 (Estação Zeus), devido à maior capacidade de hardware e ao usoda ferramenta NMAP, bem estabelecida em ambiente Linux (do qual o Raspbianna estação base é um exemplo), escolheu-se, portanto, padronizar os Módu-los Hermes como servidores de socket TCP pois, após a descoberta de rede (viaescaneamento NMAP periódico, a cada minuto, aproximadamente), seus ende-reços de IP tornam-se conhecidos à estação base, habilitando assim esta últimaa se comportar como cliente do socket TCP. Apesar deste fato, a equipe continuaa adotar a nomenclatura servidor HP3 para a Estação Zeus e cliente HP3 paraos aparelhos domésticos dotados de Módulos Hermes. É necessário ressaltar,também, que o socket TCP do Módulo Hermes deve ser aberto na porta 4444,

Relatório Técnico: Pantheon 9

escolhida pela equipe como a porta padrão do Protocolo HP3 (detalhado na se-ção a seguir).

4 Protocolo de propagação de parâmetro (HP3)

O protocolo HP3, proposto pela equipe, faz uso da pilha TCP/IP já implemen-tada no nó participante — a saber, são participantes da comunicação: i) O adap-tador wireless comum do Raspberry Pi 2; e ii) Cada Módulo Hermes de um apa-relho doméstico na rede. As duas categorias de mensagem (requisição e retorno)são compostas por poucos bytes, tendo como foco apenas a propagação de va-lores de parâmetros — daí o nome escolhido, "Hermes Parameter PropagationProtocol".

Exemplos de parâmetros de equipamentos domésticos incluem o setpointde temperatura (escolhido pelo usuário) para um aparelho de ar-condicionado,e também o status (ligado/desligado) de um alarme. Outros exemplos, maisdetalhados, podem ser encontrados na seção 5.

O protocolo HP3 foi desenvolvido de maneira a manter a brevidade dos da-dos transmitidos, de forma a causar o menor impacto possível em eletrodomés-ticos cujo desempenho pudesse ser prejudicado com o impacto de mensagensmais longas. Por exemplo: um dimmer, dispositivo responsável pelo controlede potência fornecida a uma carga, como uma lâmpada, deve realizar funçõesperiódicas, da ordem de precisão de milissegundos, para ativação de compo-nentes. Caso este período não seja respeitado (devido a leituras de mensagensdo servidor excessivamente grandes, por exemplo), isto poderia afetar a quan-tidade de potência fornecida, e causando efeitos muitas vezes notáveis, como opiscar da lâmpada.

Para que o protocolo possa operar com sucesso, um ambiente propício deveser implementado tanto no lado servidor (Estação Zeus) quanto no lado Hermesda rede (aparelhos domésticos). Os componentes deste ambiente são descritosnas subseções 4.1 a 4.4. Já as subseções 4.5 a 4.8 detalham as mensagens TCPpermitidas pelo HP3, e resumidas na Figura 6.

4.1 Descritor de Aplicação

O Descritor de Aplicação (DA) é um arquivo de marcação em formato JSON,contido no arquivo ZIP que deve ser fornecido por um fabricante como requi-sito para que seu produto (desenvolvido nos moldes da Tecnologia Pantheon)possa ter seu estado exibido na interface gráfica. O arquivo ZIP mencionadodeve ser enviado pelo usuário para a Estação Zeus (via Interface Oráculo). Umavez recebido pela estação base, suas informações são persistidas em banco dedados no lado servidor.

O DA fornece à Estação Zeus, entre outras informações, a lista de parâmetros(cujos estados devem ser registrados) do aparelho, bem como suas respectivas

Relatório Técnico: Pantheon 10

Figura 6: Diagrama de comparação entre os 5 possíveis formatos válidos de mensagensno protocolo HP3 proposto.

condições quanto à visualização e manipulação pelo usuário na interface grá-fica. As declarações efetuadas pelo fabricante neste arquivo são divididas emdois grupos distintos: os atributos de topo (que se aplicam ao aparelho comoum todo) e os atributos específicos de parâmetro (os quais formam um con-junto que deve ser explicitado para cada parâmetro do aparelho), ambos lista-dos e brevemente explicados nas Tabelas 1 e 2.

Tabela 1: Descritor de Aplicação — Atributos de Topo.

Nome Descriçãoapplication_description Descrição legível do produto.

application_manufacturer Descrição do fabricante do produto.application_model Descrição do modelo do produto.

application_version Versão do produto.application_mmv Identificador de MMV 1 de 4 bytes.application_year Ano-modelo do produto.

application_parameters Lista de parâmetros do aparelho.

Dentre os atributos de topo, destaca-se o appl i cati on_mmv , que indicaà Estação Zeus o fabricante, o modelo e a versão do produto. O mesmo iden-tificador deve ser introduzido, ainda, na Tabela de Parâmetros (detalhada nasubseção 4.3).

1Manufacturer/Model/Version.2Valores especiais são aqueles para os quais a interface gráfica exibe um valor distinto do real.

Relatório Técnico: Pantheon 11

Tabela 2: Descritor de Aplicação — Atributos de Parâmetros.

Nome Descriçãoparam_id Byte (de 0x10 a 0xF F ) identificador do parâmetro.

type Tipo de dados para interpretação dos bytes.request_component (opcional) Componente gráfico para manipulação do valor.

notification_component (opcional) Componente gráfico para visualização do valor.description Descrição legível do componente gráfico.

min (opcional) Valor mínimo para os bytes do valor.max (opcional) Valor máximo para os bytes do valor.

value_list (opcional) Lista de valores especiais do parâmetro 2.

De maneira semelhante, cada par am_i d escolhido, além de único dentrodo DA, deve ser igualmente identificado na Tabela de Parâmetros do lado cli-ente.

4.2 Descritor de Estado

O Descritor de Estado (DE) da aplicação é um objeto instanciado na EstaçãoZeus uma vez para cada aparelho doméstico encontrado na rede local. O pro-cesso de descoberta desses dispositivos, em si, acontece através do escanea-mento citado na subseção 3.2, via ferramenta NMAP no Raspbian. A estruturado DE deriva das declarações contidas no DA correspondente, refletindo o es-tado atual do aparelho doméstico e de todos os seus parâmetros declarados.Para determinar qual DA conterá a descrição adequada de um dado aparelhodoméstico, a Estação Zeus interroga cada dispositivo encontrado, a fim de obterseu identificador de MMV. Com o MMV determinado, uma consulta ao bancode dados não-relacional retorna o DA do aparelho, que pode, então, ser utili-zado para derivar em memória um novo DE com sua estrutura (Figura 7).

Figura 7: Diagrama ilustrativo do relacionamento entre DAs e DEs, em que um mesmoDA pode ditar a estrutura de dados em um ou mais DEs simultaneamente.

Relatório Técnico: Pantheon 12

O DE, portanto, é uma área de memória da estação base utilizada para re-gistrar as informações de estado dos parâmetros (e.g. seus valores, que não sãoregistrados no DA), o objeto de referência ao socket de comunicação com o Mó-dulo Hermes relacionado, entre outras informações relevantes ao processo deenvio, recebimento e manipulação de valores de parâmetros. Enquanto cadaDE referencia uma instância de aparelho doméstico, um DA descreve a estru-tura de toda uma classe de aparelhos que compartilhem o mesmo identificadorde MMV.

4.3 Tabela de Parâmetros

Com função similar ao do DE da aplicação, porém no lado cliente do serviço, aTabela de Parâmetros constitui um índice de valores de parâmetros. Tal índicepode ser implementado na plataforma (microcontrolador/linguagem) de pre-ferência do fabricante, desde que a mesma seja acompanhado de uma imple-mentação das rotinas do protocolo HP3. Por ser apenas um índice, na realidadea Tabela de Parâmetros não armazena, propriamente, os valores dos parâmetrosapontados, ficando a cargo da aplicação (aparelho doméstico da Rede Hermes)alocar e gerenciar o espaço de memória ocupado pelos bytes de valor. Uma vezalocado o espaço para os valores de parâmetros, as mensagens HP3 recebidasda estação base permitem a manipulação e a consulta destes bytes.

Para que a Estação Zeus consiga instanciar um DE compatível com a Tabelade Parâmetros da aplicação, é crucial que os 4 bytes identificadores de MMV se-jam inicializados na mesma, conforme declarados no DA, sob o parâmetro deíndice 0x00 (par am_i d). Aplicações cujo MMV não seja encontrado em ne-nhum dos DAs existentes no banco de dados do servidor são consideradas des-conhecidas, mesmo que operacionalmente ativas, até que um DA correspon-dente seja adequadamente instalado na estação base.

4.4 Objetivo específico do protocolo proposto

Estabelecidos os componentes que compõem o ambiente de uma Rede Hermes,torna-se possível, então, estabelecer o objetivo específico do protocolo HP3 pro-posto: a transferência de valores de parâmetros entre cada DE (localizado emmemória na Estação Zeus) e a Tabela de Parâmetros da aplicação respectiva.

Através do escaneamento sistemático da rede doméstica pela estação base(conforme subseção 3.2), aparelhos recém-conectados são testados quanto àsua responsividade a requisições HP3 na porta padrão (4444); os nós clientesque estiverem ativos, que informarem corretamente seu MMV (em resposta auma requisição GET, conforme descrita na subseção 4.5) e que aceitarem o IDgerado pela Estação Zeus (e entregue à aplicação via SET, conforme subseção4.6) são, então, tabelados no servidor como clientes HP3 ativos. É neste mo-mento, também, que os aparelhos tabelados que possuem DA persistido (iden-tificado pelo MMV recém-obtido) têm seu DE instanciado. Em qualquer caso,

Relatório Técnico: Pantheon 13

uma vez tabelado, cada aparelho doméstico se torna apto para exibição na in-terface gráfica de usuário. Ainda nesta etapa, os DEs instanciados com sucessonecessitam sincronizar seus valores de parâmetros com a tabela de lado apli-cação; esta tarefa é realizada através de um loop de requisições GET para cadaDE.

4.5 Requisição GET

Uma requisição do tipo GET é uma mensagem que objetiva a informação, porparte do Módulo Hermes, do valor do parâmetro especificado na tabela de ladocliente.

Seu formato é constituído de um caractere ASCII para a letra "G", seguido de1 byte de identificador de parâmetro, e um caractere ASCII para quebra de linha(0x0A). É importante notar que o identificador de parâmetro deve ser conhe-cido, ou seja, constar no DA e na Tabela de Parâmetros.

O formato da requisição GET é exibido na Figura 6 a).

4.6 Requisição SET

Uma requisição do tipo SET é uma mensagem que objetiva a manipulação, porparte da Estação Zeus, do valor do parâmetro especificado na tabela de ladocliente. Cabe ressaltar que, em boa parte dos casos, a estação base inicia estetipo de requisição HP3 devido a uma solicitação do usuário via interface gráfica.

O formato deste tipo de requisição é um caractere ASCII para a letra "S", se-guido de 1 byte de identificador de parâmetro, um número de bytes ditado pelotipo de dados declarado para o parâmetro no DA, e um caractere ASCII para que-bra de linha. Novamente, o parâmetro deve ser conhecido, porém, além disso,ele deve ser diferente de 0x00, que é reservado ao MMV na Tabela de Parâmetrosde lado cliente.

O formato da requisição SET é exibido na Figura 6 b).

4.7 Retorno RESPONSE

Um retorno do tipo RESPONSE é uma mensagem que é enviada apenas comoresposta de sucesso a uma requisição (GET ou SET). Quando sucede um GET,indica (além do ASCII para "R") o identificador do parâmetro requisitado e seurespectivo valor. Quando sucede um SET, indica (além do "R") apenas o identi-ficador, como confirmação de execução da atualização solicitada. Em ambos oscasos, a mensagem deve terminar com o caractere ASCII para quebra de linha.

Os dois formatos do retorno RESPONSE são exibidos nas Figuras 6 c) e d).

4.8 Retorno ERROR

Um retorno do tipo ERROR é uma mensagem que é enviada apenas como res-posta de falha a uma requisição (GET ou SET), sempre indicando (além do AS-

Relatório Técnico: Pantheon 14

CII para "E") o identificador do parâmetro requisitado e a identificação do erroocorrido (e mais o ASCII para quebra de linha).

O formato do retorno ERROR é exibido na Figura 6 e).

5 Resultados

Conforme já esclarecido neste trabalho, cada aparelho doméstico que aspireintegrar-se à Rede Hermes deve embarcar, em si, um Módulo Hermes descritona seção 3.2. Vale ressaltar, no entanto, que o fabricante não precisa necessa-riamente projetar mecanismos para o ingresso do módulo à rede Wi-Fi, comoexplicado na seção 2.

Para fins de demonstração do conceito proposto, a equipe desenvolveu 3aplicações simples que tiram proveito de todas as estruturas descritas até então.É importante notar que, conforme mostrado nas subseções 5.1 a 5.3 seguintes,as preocupações principais do fabricante — além do hardware próprio — du-rante o projeto de um aparelho compatível com a Rede Hermes resumem-se àalimentação do Módulo Hermes, à implementação da Tabela de Parâmetrosem software e à declaração dos parâmetros em um DA.

Após o encerramento das aquisições de materiais de desenvolvimento, aequipe pôde preparar uma relação de custos (listados na Tabela 3).

5.1 Cafeteira

Como primeira aplicação demonstrativa, a equipe escolheu uma cafeteira acio-nada pelo usuário, de maneira remota, através da Interface Oráculo. Além disso,deseja-se medir e exibir a temperatura do café na referida interface gráfica. Parao acionamento da cafeteira foi utilizado um relé Songle [Son], disponível em umshield genérico [Fil]. A temperatura foi adquirida através de um sensor MCP9808[MCP].

A Tabela 4 traz um resumo das declarações de parâmetros feitas no DA. Estesmesmos parâmetros foram tabelados na lógica do programa do Arduino (con-trolador escolhido).

Utilizando a biblioteca ESP8266, o software de lado Arduino é capaz de pro-cessar as mensagens GET e SET iniciadas pela Estação Zeus e, em resposta aelas, enviar a temperatura da chapa da cafeteira e ligar/desligar o aparelho. Valeressaltar que as mensagens GET (para obtenção da temperatura) são periodi-camente enviadas pela estação base, e as mensagens SET são provocadas pelousuário, através de um componente "switch"na Interface Oráculo.

5.2 Dimmer

A segunda aplicação demonstrativa proposta é uma lâmpada com potência con-sumida regulável. A equipe disponibilizou, na interface gráfica, um compo-nente "slider"para seleção do brilho desejado, por parte do usuário. A Figura 8

Relatório Técnico: Pantheon 15

apresenta o diagrama esquemático do dimmer implementado, posteriormentemontado em uma placa padrão.

Figura 8: Diagrama esquemático do circuito de controle de potência do dimmer.Adaptado de [Liv] e [Loy].

A Tabela 5 resume as declarações de parâmetros do DA do dimmer. Nova-mente, estes mesmos parâmetros foram tabelados no programa do Arduino.

O software de Arduino fez uso do recurso "timer"para ativação periódica doTRIAC, e da biblioteca ESP8266 para recebimento das mensagens HP3. Comoresultado final, obteve-se um controle do tipo slider na interface gráfica, quepode ser utilizado para enviar requisições SET ao Módulo Hermes do dimmer, eassim causar variações na luminosidade deste equipamento.

5.3 Detector de intensidade sonora

A última aplicação demonstrativa proposta é um circuito detector de intensi-dade sonora, que envia suas medições para a Interface Oráculo de maneira sis-temática.

A Figura 9 apresenta o diagrama esquemático do detector de intensidadesonora. Para aquisição do sinal de áudio foi utilizado um microfone de eletreto.Além deste componente, o circuito emprega transistores com o objetivo de am-

Relatório Técnico: Pantheon 16

plificar, retificar e realizar buffering sobre o sinal do microfone.

Figura 9: Diagrama esquemático do circuito amplificador do detector de intensidadesonora proposto. Adaptado de [Edu].

A Tabela 6 exibe as declarações de parâmetros efetuadas no DA do detectorde intensidade sonora, cuja lógica de programa implementa também os mes-mos parâmetros declarados.

A tensão de saída do circuito da Figura 9 varia entre 0V e 4V, de acordo coma intensidade sonora de entrada no sistema. A leitura é feita pelo Arduino eentão remapeada para uma escala entre 0 e 100 (faixa de valores mais adequadapara exibição ao usuário na interface gráfica). Esses valores são periodicamenteconsultados pela estação base através de requisições GET, e então exibidos naInterface Oráculo para o usuário.

5.4 Operação do Pantheon

De maneira a operar uma Estação Zeus, o usuário final deve garantir que estedispositivo se encontre integrado à rede wireless da residência. A interface grá-fica "Zeus Wireless Wizard", desenvolvida pela equipe e mostrada na Figura 10,auxilia o usuário (mediante conexão cabeada) ao listar as redes Wi-Fi disponí-veis para a Estação Zeus. Vale ressaltar que, neste acesso, é necessário que ainterface Ethernet do computador do usuário seja configurada para o endereçoIP 10.10.10.11/16.

A tela do Zeus Wireless Wizard possui ainda outras duas funções: o autoin-gresso de Módulos Hermes à rede wireless (desde que os mesmos encontrem-seconectados via Adaptador Hermes–USB), e a exposição do endereço IP WLANda Estação Zeus. Tal endereço pode ser consultado de outras maneiras, mas suaexibição no Wireless Wizard torna-se conveniente como mais uma opção aosusuários menos experientes. O endereço IP da Estação Zeus é importante porfornecer acesso à Interface Oráculo, onde todas as funcionalidades da estação

Relatório Técnico: Pantheon 17

Figura 10: Captura de tela da interface de configuração wireless da Estação Zeus e dosMódulos Hermes.

base podem ser acessadas (inclusive um link para o próprio Zeus Wireless Wi-zard).

Com o Módulo Hermes devidamente ingressado à rede doméstica, um apa-relho doméstico torna-se apto para descoberta por parte da estação base. Umavez descoberto e operante dentro do protocolo HP3, tal aparelho é exibido nainterface gráfica com o usuário. Aplicações cujos DAs sejam desconhecidos sãolistadas com seu MMV, de maneira a guiar o usuário rumo à instalação do pa-cote descritor. Já as aplicações conhecidas (a exemplo da cafeteira da Figura 11)exibem seus componentes de visualização e manipulação de parâmetros.

Figura 11: Captura de tela da Interface Oráculo após a descoberta de uma cafeteira.

Relatório Técnico: Pantheon 18

6 Conclusão

Apesar de mirar um estreito espaço de aplicações (voltadas à sincronização devalores de parâmetros, apenas, como os três aparelhos desenvolvidos), o projetose mostrou promissor no sentido em que diminui o esforço do desenvolvedor,reduz os conhecimentos técnicos necessários do usuário e mantém a interfacegráfica unificada e funcional.

Durante o desenvolvimento, a equipe aprofundou seus conhecimentos emcircuitos analógicos e digitais, entrou em contato com o ambiente (hoje, extre-mamente popular) do NodeJS e dos bancos de dados não-relacionais, além deaprender tópicos avançados nos assuntos-alvo do projeto, a saber: IOT e módu-los wireless (em especial o ESP8266), Arduino, Raspberry Pi, redes de computa-dores cabeadas e sem fio, e, por fim, protocolo TCP.

As aplicações demonstrativas do conceito (cafeteira, dimmer e detector deintensidade sonora) demonstraram que os objetivos estabelecidos foram atingi-dos, resultando em um protótipo de sistema de automação residencial comple-tamente funcional. Como características principais do Pantheon, destacam-se:i) A interface gráfica com o usuário centralizada e de fácil operação — inclu-sive permitindo, com baixo esforço técnico, configurar o roteador SOHO paraacessá-la remotamente —, ii) O protocolo de troca de parâmetros simples e deoverhead reduzido e iii) As ferramentas auxiliadoras de configuração (WirelessWizard e Autoingresso de Módulos Hermes).

Para trabalhos futuros, sugere-se:• Pesquisa visando ganhos de estabilidade, confiabilidade, segurança e per-

formance no protocolo HP3 proposto e/ou no software do servidor;• Desenvolvimento de tipos mais avançados de mensagens HP3, com su-

porte a streaming, por exemplo — viabilizando, assim, componentes deinterface gráfica mais avançados;

• Busca de melhorias no processo de descoberta de rede.

Referências

[Edu] Revolution Education. http://www.picaxe.com/docs/picaxe_

sound.pdf.

[Esp] Espressif. http://espressif.com/en/products/esp8266/.

[Fil] FilipeFlop. http://www.filipeflop.com/pd-6b84a-modulo-rele-

5v-2-canais.html?ct&p=1&s=1.

[Hac] Hackaday. http://hackaday.com/tag/assistive-technology/.

Relatório Técnico: Pantheon 19

[Liv] Elétron Livre. http://blog.eletronlivre.com.br/2010/09/

dimmer-futuristico-automacao.html.

[Loy] Edu Loyola. https://efloyola.wordpress.com/2011/10/02/

controle-triac-com-arduino-dimmer/.

[MCP] Adafruit MCP9808. http://www.adafruit.com/datasheets/

MCP9808.pdf.

[Mon] MongoDB. https://www.mongodb.org/.

[NMA] NMAP. https://nmap.org/.

[Nod] NodeJS. https://nodejs.org/.

[Nur] Nurdspace. https://nurdspace.nl/ESP8266#AT_Commands.

[Rasa] Raspberry. https://www.raspberrypi.org/products/raspberry-

pi-2-model-b/.

[Rasb] Raspbian. https://www.raspbian.org/.

[Son] Songle. http://img.filipeflop.com/files/download/Datasheet_Rele_5V.pdf.

[STM] STMicroelectronics. http://www.st.com/web/en/resource/

technical/document/datasheet/CD00002116.pdf.

Relatório Técnico: Pantheon 20

Tabela 3: Relação de custos do projeto.

Discriminação $/un. Quant. ValorCafeteira R$ 59,90/pc. 1 R$ 59,90Fios de instalação elétrica R$ 30,00/pc. 1 R$ 30,00Placas perfuradas R$ 14,50/pc. 3 R$ 43,50Cases para hardware R$ 9,50/pc. 3 R$ 28,50Triac BTA12-600SW 12A / 600V R$ 2,90/pc. 3 R$ 8,70MOC3020M R$ 2,40/pc. 3 R$ 7,20LM35CZ R$ 5,40/pc. 1 R$ 5,404N25 R$ 1,70/pc. 3 R$ 5,10Arduino Mega R$ 79,90/pc. 3 R$ 239,70Raspberry Pi 2 R$ 140,48/pc. 1 R$ 140,48Case para Raspberry Pi 2 R$ 22,90/pc. 1 R$ 22,90Adaptador Wi-Fi USB 150Mbps RALINK RT5370 R$ 26,47/pc. 1 R$ 26,47Fonte 5V 3A para Raspberry Pi 2 R$ 29,99/pc. 1 R$ 29,99Módulo Wi-Fi UART ESP8266 ESP01 R$ 33,99/pc. 3 R$ 101,97Placa conversora UART USB FT232RL R$ 29,90/pc. 1 R$ 29,90Sensor de som KY-038 R$ 22,90/pc. 1 R$ 22,90Sensor de temperatura MCP9808 R$ 44,90/pc. 1 R$ 44,90Módulo relé 5V com 2 canais R$ 19,90/pc. 2 R$ 39,80LM1117 3.3V R$ 5,50/pc. 3 R$ 16,50LM1117 ADJ (Internet) R$ 8,40/pc. 3 R$ 25,20Microfone para PC R$ 10,00/pc. 1 R$ 10,00Bateria 9V genérica R$ 4,00/pc. 4 R$ 16,00Bateria 9V alcalina R$ 11,90/pc. 2 R$ 23,80Bateria 9V Duracell R$ 16,00/pc. 3 R$ 48,00CD 4050 R$ 2,00/pc. 4 R$ 8,00Suporte para bateria 9V R$ 2,00/pc. 2 R$ 4,002N2222 R$ 0,30/pc. 10 R$ 3,00BC 546 R$ 0,15/pc. 10 R$ 1,50

TOTAL: R$ 1043,31

Relatório Técnico: Pantheon 21

Tabela 4: Parâmetros da cafeteira.

Parâmetro Atributos de DA Valor

p_status

param_id 0x10type "boolean"

request_component "checkbox"description "Status da cafeteira"

value_list { "ligada": true, "desligada": false }

p_temperature

param_id 0x11type "float32"

notification_component "numeric"description "Temperatura do café"

value_list { "desconhecida": 0 }

Tabela 5: Parâmetros do dimmer.

Parâmetro Atributos de DA Valor

p_status

param_id 0x10type "int8"

request_component "slider"description "Brilho"

min 0x00max 0x64

value_list { "ligada": true, "desligada": false }

Tabela 6: Parâmetros do detector de intensidade sonora.

Parâmetro Atributos de DA Valor

p_temperature

param_id 0x10type "int8"

notification_component "numeric"description "Última medição notificada"

min 0x00max 0xC 8

value_list { "desconhecido": 0 }