• Nenhum resultado encontrado

PROTÓTIPO DE UM DISPOSITIVO GERENCIADOR DE EQUIPAMENTOS VIA ETHERNET PARA ECONOMIA DE ENERGIA

N/A
N/A
Protected

Academic year: 2021

Share "PROTÓTIPO DE UM DISPOSITIVO GERENCIADOR DE EQUIPAMENTOS VIA ETHERNET PARA ECONOMIA DE ENERGIA"

Copied!
63
0
0

Texto

(1)

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO

PROTÓTIPO DE UM DISPOSITIVO GERENCIADOR DE

EQUIPAMENTOS VIA ETHERNET PARA ECONOMIA DE

ENERGIA

MARLON ERICH RUTTMANN

BLUMENAU 2018

(2)

MARLON ERICH RUTTMANN

PROTÓTIPO DE UM DISPOSITIVO GERENCIADOR DE

EQUIPAMENTOS VIA ETHERNET PARA ECONOMIA DE

ENERGIA

Trabalho de Conclusão de Curso apresentado ao curso de graduação em Ciência da Computação do Centro de Ciências Exatas e Naturais da Universidade Regional de Blumenau como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação.

Prof. Miguel Alexandre Wisintainer, Mestre - Orientador

BLUMENAU 2018

(3)

PROTÓTIPO DE UM DISPOSITIVO GERENCIADOR DE

EQUIPAMENTOS VIA ETHERNET PARA ECONOMIA DE

ENERGIA

Por

MARLON ERICH RUTTMANN

Trabalho de Conclusão de Curso 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. Francisco Adell Péricas, Mestre – FURB

______________________________________________________

Membro: Prof. Gabriele Jennrich Bambineti, Especialista – FURB

(4)

AGRADECIMENTOS

Ao meu orientador Miguel Alexandre Wisintainer pelos conselhos e pelo apoio dado no decorrer deste trabalho.

À minha família por todo o apoio e incentivo dado para que eu chegasse até aqui. À minha namorada Luana Tiara Hoffmann pelo grande incentivo e paciência no decorrer deste trabalho.

Por fim, dedico a todos os colegas de aula e de trabalho que de alguma forma contribuíram com o desenvolvimento deste trabalho.

(5)

RESUMO

Este trabalho apresenta o desenvolvimento de um protótipo que tem como objetivo reduzir custos evitando o desperdício de energia e o gasto com vigias na FURB, monitorando as salas de aula e desligando os equipamentos eletrônicos, como aparelhos de ar-condicionado e projetores das salas vazias. Para tanto, foi desenvolvido um dispositivo para ser instalado nas salas de aula com a capacidade de desligar equipamentos através de comandos IR. Ele foi construído utilizando componentes como sensor de movimentos, receptor e emissores de IR, um Arduino Mega, um Ethernet Shield W5100 e LDRs. O dispositivo é capaz de conectar-se a um servidor de monitoramento pela Internet, detectar movimentos na sala, aprender e emitir comandos IR e detectar o status de equipamentos eletrônicos. Caso o dispositivo detectar que uma sala está vazia, ele solicita os comandos ao servidor de monitoramento e desliga os equipamentos. Foi também desenvolvida uma interface web onde é possível acessar todas as informações do sistema de monitoramento, monitorar os dispositivos conectados e alterar seus atributos. Para o desenvolvimento do servidor e da interface web foram utilizadas as linguagens JavaScript, HTML e CSS. Por fim, o protótipo funcionou de acordo com os objetivos definidos sendo possível monitorar as salas e desligar seus equipamentos através de comandos IR.

Palavras-chave: Economia de energia. Internet das coisas. Automação. Websocket. Monitoramento remoto. Arduino.

(6)

ABSTRACT

This work presents the development of a prototype that aims to reduce costs by avoiding wasted energy and spending on watchmen at FURB, monitoring classrooms and turning off electronic equipment such as air conditioners and projectors on empty rooms. For this, a device was developed to be installed in classrooms with the ability to turn off equipment through IR commands. It was built using components such as motion sensor, receiver and IR emitters, Arduino Mega, Ethernet Shield W5100 and LDRs. The device can connect to a monitoring server over the Internet, to detect movements in the room, learn and issue IR commands and detect the status of electronic equipment. If the device detects that a room is empty, it requests the commands to the monitoring server and turns off the equipment. It has also been developed a web interface where it is possible to access all the information of the monitoring system, monitor the connected devices and change its attributes. For the development of the server and the web interface were used the languages JavaScript, HTML and CSS. Finally, the prototype worked according to defined objectives and could monitor the rooms and turn off their equipment through IR commands.

Key-words: Energy saving. Internet of things. Automation. Websocket. Remote monitoring. Arduino.

(7)

LISTA DE FIGURAS

Figura 1 – Placas Arduino ... 15

Figura 2 - Shield Ethernet W5100 ... 16

Figura 3 - Espectro da radiação visível ... 17

Figura 4 - LED IR e receptor IR ... 17

Figura 5 - Emissão e recepção de sinais IR ... 18

Figura 6 - Sensor PIR com a lente removida ... 19

Figura 7 - Funcionamento de um sensor PIR ... 19

Figura 8 - Comunicação half-duplex e full-duplex ... 20

Figura 9 - Circuito de acionamento de lâmpadas ... 22

Figura 10 - Telas da aplicação de controle ... 23

Figura 11 - Planta e protótipo elaborado ... 24

Figura 12 - Interface gráfica do aplicativo de controle ... 25

Figura 13 - Estrutura de comunicação ... 26

Figura 14 – Diagrama de arquitetura do protótipo ... 28

Figura 15 – Diagrama de atividades ... 30

Figura 16 – Diagrama de casos de uso ... 31

Figura 17 – Esquema eletrônico do Dispositivo IR ... 32

Figura 18 – Dispositivo IR montado ... 33

Figura 19 – LDR conectado ao cabo CCI-50 ... 35

Figura 20 – LDR instalado em um ar-condicionado ... 36

Figura 21 – LDR instalado em um projetor ... 37

Figura 22 – Tela de Informações ... 48

Figura 23 – Tela de Dispositivos ... 48

Figura 24 – Painel de edição atributos do Dispositivo IR ... 49

Figura 25 – Tela de Comandos ... 50

(8)

LISTA DE QUADROS

Quadro 1 – Loop principal... 38

Quadro 2 – Método monitoraSalaCheia ... 39

Quadro 3 – Método monitoraSalaVazia ... 39

Quadro 4 – Método arEstaLigado ... 40

Quadro 5 – Método projetorEstaLigado ... 40

Quadro 6 – Método geraJSONsinais ... 41

Quadro 7 – Função que identifica os dispositivos ... 42

Quadro 8 – Função de recepção de comandos ... 43

Quadro 9 – Função que armazena os segmentos de comandos ... 43

Quadro 10 – Autorização e busca dos comandos no banco de dados ... 44

Quadro 11 – Envio dos segmentos de comando ... 44

Quadro 12 – Função que atualiza o status dos Dispositivos IR ... 45

Quadro 13 – Função que busca os comandos no banco de dados ... 45

Quadro 14 – Função de atualização e envio de comandos ... 45

Quadro 15 – Funções que enviam informações à interface de monitoramento... 46

Quadro 16 – Comparativo entre os trabalhos correlatos e o proposto... 53

Quadro 17 – Detalhes do UC01 – Cadastrar comandos IR no Dispositivo IR ... 60

Quadro 18 – Detalhes do UC02 – Ingressar Dispositivo IR no Sistema Gerenciador ... 60

Quadro 19 – Detalhes do UC03 – Monitorar Dispositivos IR ... 60

Quadro 20 – Detalhes do UC04 – Parametrizar comandos no Sistema Gerenciador... 61

Quadro 21 – Detalhes do UC05 – Atribuir comandos a Dispositivos IR no Sistema Gerenciador... 61

(9)

LISTA DE ABREVIATURAS E SIGLAS

API – Application Programming Interface HTTP – Hypertext Transfer Protocol

IDE – Integrated Development Environment IP – Internet Protocol

IR – Infra Red

IoT – Internet of Things

JSON – JavaScript Object Notation LED – Light-emitting Diode LDR – Light Dependent Resistor PIR – Passive Infra Red

TCP – Transmission Control Protocol UML – Unified Modeling Language

(10)

SUMÁRIO

1 INTRODUÇÃO ... 11

1.1 OBJETIVOS ... 11

1.2 ESTRUTURA... 12

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

2.1 ECONOMIA DE ENERGIA ELÉTRICA E DOMÓTICA ... 13

2.2 INTERNET DAS COISAS (IOT) ... 13

2.3 ARDUINO ... 14

2.3.1 ETHERNET SHIELD W5100 ... 15

2.4 COMUNICAÇÃO E DETECÇÃO DE MOVIMENTOS VIA IR... 16

2.5 WEBSOCKET ... 20

2.6 PROTÓTIPO ATUAL... 21

2.7 TRABALHOS CORRELATOS ... 21

2.7.1 Automação residencial de baixo custo por meio de dispositivos móveis com sistema operacional Android ... 22

2.7.2 Desenvolvimento de um protótipo de automação predial/residencial utilizando a plataforma de prototipagem eletrônica Arduino ... 24

2.7.3 Webhome – Automação residencial utilizando Raspberry PI... 25

3 DESENVOLVIMENTO DO PROTÓTIPO ... 27

3.1 REQUISITOS ... 27

3.2 ESPECIFICAÇÃO ... 28

3.2.1 Arquitetura do protótipo ... 28

3.2.2 Diagrama de atividades ... 29

3.2.3 Diagrama de casos de uso ... 31

3.3 IMPLEMENTAÇÃO ... 31

3.3.1 Construção do Dispositivo IR ... 31

3.3.2 Técnicas e ferramentas utilizadas... 37

3.3.3 Códigos-fonte do protótipo ... 38

3.3.3.1Dispositivo IR ... 38

3.3.3.2Servidor ... 41

3.3.3.3Cliente ... 45

(11)

3.4 ANÁLISE DOS RESULTADOS ... 50

3.4.1 Testes de campo ... 51

3.4.2 Testes da interface de monitoramento... 52

3.4.3 Comparativo dos resultados com os trabalhos correlatos ... 53

4 CONCLUSÕES ... 56

(12)

11

1 INTRODUÇÃO

O desperdício de energia elétrica no Brasil gera muitos custos que podem ser evitados. Segundo a Secretaria de Energia e Mineração do Estado de São Paulo (2016), o desperdício de energia elétrica foi de cerca de 60 mil GWh (Gigawatts/hora) no ano de 2015, equivalente a 13% do consumo nacional. O órgão público também aponta que o mercado de eficiência energética tem dificuldades em mensurar seu potencial e que no momento só é possível mensurar o custo que determinado tipo de consumidor pode evitar adotando medidas para melhorar seu perfil de consumo de energia elétrica. De acordo com Marcel Haratz, diretor da Comerc Esco (empresa privada especializada em consultoria para gestão de energia), os dois principais focos de ganho em eficiência energética estão em climatização e iluminação, com variações de 10% a 50% e 30% a 60%, respectivamente (SECRETARIA DE ENERGIA E MINERAÇÃO DO ESTADO DE SÃO PAULO, 2016).

Cálculos da Associação Brasileira das Empresas de Serviços de Conservação de Energia (ABESCO) apontam que os prejuízos causados pelo desperdício de energia elétrica no Brasil chegam a R$12,6 bilhões por ano. Ainda sugerem que o consumidor residencial tem o maior potencial de economia energética, pois com a adoção de medidas simples como desligar as luzes, reduzir o uso do chuveiro elétrico e do ar-condicionado é possível reduzir até 15% do consumo de energia elétrica. Nos setores comercial e industrial, o potencial de redução do consumo fica em torno de 10% e 6,2%, respectivamente (GUADAGNIN, 2016).

A automação residencial e predial está cada vez mais presente na vida das pessoas, proporcionando conforto, comodidade e economia de energia. Segundo Bolzani (2004), a comodidade e a economia proporcionadas ao longo do tempo pela automação, compensam o investimento inicial.

Diante do exposto, este trabalho propõe uma extensão do protótipo desenvolvido por Sabel (2016), que tinha por objetivo desenvolver um dispositivo para desligar equipamentos eletrônicos via Wi-Fi. As principais alterações são a mudança da comunicação para Ethernet, proporcionando maior confiabilidade na comunicação com o servidor e a mudança na maneira como o protótipo detecta se os equipamentos estão ligados, trocando o sensor de corrente não-invasivo por LDRs.

1.1 OBJETIVOS

O objetivo geral deste trabalho é estender as funcionalidades do protótipo desenvolvido por Sabel (2016), alterando a comunicação de Wi-Fi para Ethernet e incluindo recursos para monitoramento remoto via Internet.

(13)

12

Os objetivos específicos são:

a) substituir o módulo ESP8266-EVB pelo Ethernet Shield W5100, implementando a comunicação via Ethernet, de modo a facilitar a conexão do protótipo com a rede da Universidade Regional de Blumenau (FURB);

b) implementar monitoramento por um servidor remoto, através de conexões WebSocket diretamente com o servidor, usando a plataforma Node.JS e bibliotecas compatíveis;

c) utilizar 3 emissores de infravermelho por equipamento a ser desligado ao invés de apenas 1, de modo a aumentar a intensidade do sinal enviado e evitar a interferência de sinais externos;

d) alterar a maneira como o dispositivo detecta se os equipamentos estão ligados, substituindo o sensor de corrente não-invasivo por um LDR.

1.2 ESTRUTURA

O presente trabalho está organizado em quatro capítulos, sendo o primeiro esta introdução, bem como a apresentação de seus objetivos e estrutura. No segundo capítulo há a fundamentação teórica do trabalho que aborda assuntos como economia de energia e sua correlação com a domótica, IoT, Arduino e o Ethernet Shield W5100, comunicação e detecção de movimentos via IR e protocolo Websocket. Ao final são descritos o protótipo atual e os trabalhos correlatos.

O terceiro capítulo se refere ao desenvolvimento do protótipo, através do levantamento de requisitos, especificação, hardware e técnicas utilizadas, códigos implementados e operacionalidade. São apresentados também os resultados e discussões sobre os problemas e soluções encontrados no decorrer do desenvolvimento. Por último, o quarto capítulo traz conclusões a respeito do trabalho e sugestões de extensões observadas ao longo do desenvolvimento do mesmo.

(14)

13

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem o objetivo de explorar os principais assuntos abordados neste trabalho. Os assuntos foram divididos em seis seções. A seção 2.1 traz alguns dados sobre economia de energia elétrica, domótica e a correlação entre estes conceitos. A seção 2.2 apresenta os principais conceitos sobre Internet das Coisas (IoT). A seção 2.3 introduz os principais conceitos e especificações sobre Arduino e o Ethernet Shield W5100. A seção 2.4 apresenta conceitos sobre comunicação e detecção de movimentos via IR. A seção 2.5 apresenta definições sobre Websockets. A seção 2.6 apresenta a descrição do protótipo atual e, por fim, na seção 2.7 são apresentados os trabalhos correlatos.

2.1 ECONOMIA DE ENERGIA ELÉTRICA E DOMÓTICA

Recentes pesquisas concluem que, no período de 2008 a 2016, o Brasil desperdiçou 143647 Gigawatts/hora (GWh) de energia elétrica, o que compreende um volume cerca de 1,4 vezes maior que a geração total de energia de Itaipu em 2016. O potencial de economia neste caso é de cerca de R$61,71 bilhões (ABESCO, 2017). A legislação brasileira ainda é muito deficiente quanto a exigências mínimas e padronização das instalações elétricas residenciais. O uso de sistemas gerenciadores de consumo de energia aliados a sensores e atuadores otimiza o uso dos equipamentos elétricos, principalmente os de alta potência, e o controle na ativação de equipamentos de climatização em períodos pré-determinados é de grande impacto no gerenciamento do consumo energético (BOLZANI, 2004).

Segundo Bolzani (2004, p. 51), “a palavra domótica originou-se do latim domus que significa casa. É a ciência moderna de engenharia das instalações em sistemas prediais”e que através da automação surge a possibilidade de controlar remotamente a residência, o que proporciona conforto, segurança e economia. Ainda de acordo com o autor, o principal determinante no desenvolvimento de sistemas de automação e gerenciamento de sistemas prediais foi a crescente preocupação com a diminuição do desperdício de energia elétrica. Durante as últimas décadas, os custos com energia vêm crescendo mais do que os com pessoal, fazendo com que aspectos de economia e utilização racional da energia elétrica sejam levados em conta por construtores, usuários e técnicos ao manterem e planejarem instalações prediais e residenciais (BOLZANI, 2004).

2.2 INTERNET DAS COISAS (IOT)

Segundo Xia et al. (2012, tradução nossa, p.1), “a Internet das Coisas se refere à interconexão em rede de objetos cotidianos, que muitas vezes são equipados com inteligência

(15)

14

ubíqua”. Entretanto não há uma definição comum sobre IoT e não há um consenso sobre o que a IoT atualmente engloba. De acordo com Wortmann e Flüchter (2015), o termo tem sua origem há 17 anos atrás, sendo atribuído às pesquisas sobre identificação por tags RFID do laboratório Auto-ID Labs no Instituto de Tecnologia de Massachusetts (MIT).

A implementação de dispositivos IoT requer a combinação de múltiplos componentes de software e hardware, formando uma arquitetura de tecnologia multicamadas. Usualmente são definidas três camadas: a camada de dispositivo, a camada de conectividade e a camada da nuvem. Na camada de dispositivo encontram-se geralmente os dispositivos de hardware, bem como sensores, atuadores e softwares embarcados. A camada de conectividade compreende os protocolos e os meios de comunicação entre o dispositivo e a nuvem. Na camada da nuvem encontram-se os softwares de gerenciamento e armazenamento de dados. Além disso, também é comum encontrar nesta camada softwares de análise de dados e de segurança (WORTMANN; FLÜCHTER, 2015).

2.3 ARDUINO

Criado em 2005 por um grupo de 5 pesquisadores: Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino e David Mellis, o Arduino é um dispositivo eletrônico que atende principalmente às necessidades de prototipagem e aprendizagem de programação e eletrônica (THOMSEN, 2014). É uma placa muito similar à de um computador de pequeno porte composta por um microcontrolador, memória RAM, armazenamento secundário (memória flash), circuito de clock, circuitos de entrada/saída e que pode ser conectado a computadores através de conexão USB e programado via IDE (Integrated Development Environment) com uma linguagem de programação baseada em C/C++ (OLIVEIRA; ZANETTI, 2015). A Figura 1 mostra alguns modelos de placas Arduino.

(16)

15

Figura 1 – Placas Arduino

Fonte: Thomsen (2014).

Ela pode ser aplicada para projetos de dispositivos independentes como também ser conectada a um computador, a uma rede ou à Internet para enviar, receber e processar dados. A possibilidade de extensão de suas funcionalidades é ampla através do uso dos Shields, que são placas de circuito contendo outros dispositivos (por exemplo, displays de LCD, receptores de GPS, etc.) e módulos de sensores (MCROBERTS, 2015).

2.3.1 ETHERNET SHIELD W5100

O Shield Ethernet W5100 permite que o Arduino se conecte à Internet via Ethernet. Ele é baseado no chip Ethernet Wiznet W5100, que provém acesso à rede através do protocolo IP, também capaz de operar nos protocolos TCP (Transmission Control Protocol e UDP (User Datagram Protocol) (MOUSER ELECTRONICS, 2010). Conta com um buffer interno de 16 KB (kilobytes), opera com tensão 5 volts, suporta velocidades de comunicação de 10 ou 100 Mbps (megabits por segundo) e comunica-se com o Arduino através da porta serial SPI (Serial Peripheral Interface Bus) (STEVAN JUNIOR; SILVA, 2015). Possui alguns LEDs de informação de seu funcionamento. Sendo eles (STEVAN JUNIOR; SILVA, 2015):

a) PWR: indica que a placa está sendo alimentada;

b) LINK: indica que há conexão de rede, piscando quando há transmissão ou recepção de dados;

c) FULLD: indica que a conexão de rede é full-duplex;

d) 100M: indica que a velocidade de conexão de rede é de 100 Mbps quando aceso e de 10 Mbps quando apagado;

(17)

16

f) TX: indica a transmissão de dados; g) COLL: indica que houve colisão na rede.

A Figura 2 mostra o Shield Ethernet W5100 com alguns LEDs acesos. Figura 2 - Shield Ethernet W5100

Fonte: elaborado pelo autor.

2.4 COMUNICAÇÃO E DETECÇÃO DE MOVIMENTOS VIA IR

IR é um tipo de luz similar à luz visível. As diferenças entre a luz IR e a visível são a frequência e, portanto, o comprimento de onda (PATTABIRAMAN, 2017). A luz IR tem um comprimento de onda maior que o da luz visível e menor que o das micro-ondas. Seu comprimento de onda varia entre 700 nanômetros e 1mm micrômetro, tornando-o um segmento muito maior do espectro do que a luz ultravioleta ou visível. Cerca de 55% da luz que atinge a superfície da Terra a partir do Sol é IR (SPARKFUN, 2016b). A Figura 3 demonstra todo o espectro de radiação existente, destacando o segmento da luz IR.

(18)

17

Figura 3 - Espectro da radiação visível

Fonte: Sparkfun (2016b).

Um típico sistema de comunicação via IR necessita de um emissor e um receptor IR. O emissor é como um LED comum, exceto pelo fato deste emitir luz IR, invisível ao olho humano. O receptor IR é composto de um fotodiodo e um pré-amplificador que converte a luz IR em um sinal elétrico (PATTABIRAMAN, 2017). A Figura 4 mostra um LED IR e um receptor IR.

Figura 4 - LED IR e receptor IR

Fonte: Sparkfun (2016a).

Pelo fato da luz IR ser emitida pelo sol, por lâmpadas e por qualquer artefato que produza calor, interferências indesejadas no funcionamento de dispositivos de comunicação via IR podem ocorrer. Para evitar estas interferências, se utiliza uma técnica de modulação de sinal. Nesta técnica, um codificador no emissor de IR converte um sinal binário em um sinal elétrico modulado que por sua vez é enviado ao LED IR. Este LED converte o sinal elétrico modulado em um sinal de IR modulado. O receptor IR então demodula este sinal, converte-o para um sinal binário e o envia para o microcontrolador responsável por interpretá-lo (PATTABIRAMAN, 2017). A Figura 5 ilustra o processo de emissão e recepção de sinais IR.

(19)

18

Figura 5 - Emissão e recepção de sinais IR

Fonte: Pattabiraman (2017).

O sinal IR modulado é uma série de pulsos de luz IR que ligam e desligam em uma frequência chamada de frequência da portadora. A frequência da portadora comumente utilizada em eletrodomésticos e eletroeletrônicos é de 38 kHz (quilohertz) por ser rara na natureza e, portanto, mais fácil de ser distinguida das interferências. Deste modo o receptor IR capta apenas sinais emitidos pelo emissor esperado, mitigando possíveis detecções indesejadas de sinais provenientes do ambiente (PATTABIRAMAN, 2017).

De acordo com Adafruit (2014), um dos sensores mais utilizados para detecção de movimentos é o sensor PIR (também conhecido como “sensor infravermelho passivo”, “sensor piroelétrico” e “sensor de movimentos por IR”). Este tipo de sensor é pequeno, de baixo custo, baixo consumo energético e de fácil aplicação.

Um sensor PIR detecta movimentos através de um sensor piroelétrico, que por sua vez detecta níveis de radiação IR. Todos os elementos presentes em um ambiente emitem algum nível de radiação IR e quanto mais quente, maior a quantidade de radiação emitida. O sensor piroelétrico é dividido em duas partes compostas de um material especial sensível à radiação IR. Quando o sensor está ocioso, ambas as partes detectam uma quantidade constante de IR naturalmente emitida pelo ambiente que o sensor monitora. Quando um corpo quente como um humano ou um animal passa pela área de detecção do sensor, ele intercepta inicialmente apenas uma das partes do sensor, causando uma mudança diferencial positiva entre as partes. Quando o corpo aquecido sai da área de detecção, ocorre o inverso, com o sensor gerando uma mudança diferencial negativa. Estas variações de sinal entre as partes do sensor caracterizam uma detecção (ADAFRUIT, 2014). A Figura 6 mostra um sensor PIR com sua lente removida para exibir o sensor piroelétrico e a Figura 7 ilustra o funcionamento do sensor PIR.

(20)

19

Figura 6 - Sensor PIR com a lente removida

Fonte: Adafruit (2014).

Figura 7 - Funcionamento de um sensor PIR

(21)

20

2.5 WEBSOCKET

O protocolo WebSocket permite a comunicação bidirecional entre um cliente que executa código não confiável em um ambiente controlado e um host remoto que tenha optado por se comunicar com este código. O modelo de segurança usado para isso é o baseado em origem, comumente usado por navegadores da web. O protocolo consiste em um handshake de abertura seguido por um enquadramento de mensagem básico sobre a camada TCP. O objetivo dessa tecnologia é fornecer um mecanismo para aplicativos baseados em navegador que precisam de comunicação bidirecional com servidores que não dependem da abertura de várias conexões HTTP (INTERNET ENGINEERING TASK FORCE, 2011, tradução nossa).

Segundo Silva (2011), as conexões Websocket são full-duplex, permitindo comunicação simultânea nas duas direções: cliente servidor ou servidor cliente. Em conexões convencionais, conhecidas como half-duplex, cada solicitação do cliente ao servidor e sua respectiva resposta são independentes, implicando no envio e tráfego de cabeçalhos HTTP. Para aplicações que necessitem consultar o servidor repetidamente, o tráfego envolvido pode requerer um alto consumo de banda com provável aumento na taxa de transferência. Como casos de exemplo, pode-se citar: transmissão de eventos ao vivo, salas de bate-papo e jogos online multijogador. A Figura 8 ilustra o funcionamento da comunicação convencional (half-duplex) e da comunicação com Websockets (full-(half-duplex).

Figura 8 - Comunicação half-duplex e full-duplex

Fonte: Silva (2011).

Estudos e testes conduzidos pela Corporação Kaazing concluem que a adoção de Websockets proporciona uma redução do tráfego de cabeçalhos HTTP em 500:1. Dependendo do tamanho dos cabeçalhos HTTP, esta redução pode chegar a 1000:1. A latência também é reduzida, chegando a 3:1 (SILVA, 2011).

(22)

21

2.6 PROTÓTIPO ATUAL

Sabel (2016) teve por objetivo o desenvolvimento de um protótipo que monitorasse as salas da FURB e desligasse os equipamentos eletrônicos, como projetores e aparelhos de ar-condicionado, ao detectar que a sala estivesse vazia. As partes do protótipo são:

a) sensor de movimento: responsável por captar a presença e movimentação de pessoas nas salas. Assim que uma conexão com o servidor de monitoramento é estabelecida, o estado do sensor de movimento passa a ser consultado regularmente para determinar se a sala está vazia ou não;

b) emissor de infravermelho (IR): responsável por emitir o sinal de IR para os equipamentos eletrônicos a serem desligados;

c) receptor de IR: utilizado para que o dispositivo receba o sinal emitido pelo controle remoto do equipamento eletrônico que se deseja controlar. Ao receber o sinal, ele é armazenado na memória interna da placa Arduino;

d) placa Arduino: responsável por “aprender” e armazenar os sinais dos controles remotos dos equipamentos que se deseja controlar;

e) módulo baseado no chip ESP8266EX: responsável pela conexão do dispositivo com a rede da FURB e pela conexão com a aplicação web gerenciadora do dispositivo. Com a conexão estabelecida, é papel deste componente retornar à aplicação web gerenciadora o estado corrente do sensor de movimento;

f) aplicação web: responsável por requisitar periodicamente ao dispositivo o estado corrente do sensor de movimento. Ao detectar ausência de movimentação na sala por um longo período, a aplicação web envia uma requisição ao módulo ESP8266EX para que desligue o(s) equipamento(s).

2.7 TRABALHOS CORRELATOS

São apresentados três trabalhos correlatos, com características semelhantes aos principais objetivos deste trabalho. O primeiro descreve o trabalho de conclusão de curso de Beghini (2013), que trata do desenvolvimento de um sistema de automação residencial de baixo custo, fazendo uso do Arduino Uno como central de automação com acesso via Internet e de um aplicativo para celulares Android para o controle remoto dos dispositivos de automação. O segundo trata de um artigo que apresenta a ideia de um protótipo educacional baseado em Arduino desenvolvido por Araujo et al. (2012), que aborda os conceitos de automação residencial e predial para o controle de variáveis como temperatura, luminosidade e segurança, fazendo uso de diversos sensores e atuadores disponíveis no mercado. Por fim, o

(23)

22

terceiro é um artigo que descreve o desenvolvimento de um sistema para controle automatizado de residências baseado na placa Raspberry PI e na placa Arduino desenvolvido por Cruz e Lisboa (2014), com acesso à Internet para gerenciamento remoto, capaz de controlar diferentes tipos de dispositivos, como luzes, persianas, temperatura de ambientes e monitoramento do estado de portas e janelas.

2.7.1 Automação residencial de baixo custo por meio de dispositivos móveis com sistema operacional Android

Beghini (2013) desenvolveu um projeto de automação residencial fazendo uso de uma placa Arduino Uno para cada dispositivo de automação. Nela foram conectados um sensor IR para detecção de movimento aplicado no desenvolvimento do controle de lâmpadas e em um sistema de alarme, e um motor de passo aplicado no desenvolvimento de um alimentador de animais de estimação.

O autor seguiu cinco passos principais no desenvolvimento do projeto. O primeiro passo foi a configuração para acessar o Arduino via Internet, onde o autor fez uso de uma solução de DNS (Domain Name Server) dinâmico, o no-ip, de modo a possibilitar acesso externo ao Arduino através de um endereço fixo na Internet, para resolver o problema dos endereços IP (Internet Protocol) gerados dinamicamente a cada vez que o roteador da residência se conecta à Internet.

O segundo passo consistiu no desenvolvimento de um circuito para controle de lâmpadas, onde uma saída digital do Arduino é conectada ao pino base de um transistor que chaveia um circuito externo responsável por acender e apagar uma lâmpada. A Figura 9 apresenta o esquema do circuito utilizado.

Figura 9 - Circuito de acionamento de lâmpadas

(24)

23

No terceiro passo foi desenvolvido um sistema simples de alarme. Foi utilizado um sensor de IR para detectar movimento no ambiente monitorado e um disco piezoelétrico para simular uma sirene. Ambos os componentes são conectados a saídas digitais do Arduino. Também foi desenvolvido um sistema de notificações via Twitter, onde toda vez que o alarme for acionado, uma mensagem citando uma conta pré-determinada do Twitter é disparada, avisando sobre o disparo do alarme.

O quarto passo foi o desenvolvimento de um alimentador para animais de estimação. Uma câmera é configurada semelhantemente ao primeiro passo, de modo a permitir o acesso remoto para o usuário monitorar a quantidade de comida no pote. Em seguida, o autor simulou o acionamento de um motor de passo remotamente, através do aplicativo Android.

O quinto e último passo consistiu na criação do aplicativo gerenciador. O autor utilizou a ferramenta App Inventor para desenvolver as três telas de interação com o usuário. A primeira tela é a inicial, onde usuário se autentica através de senha. A segunda tela é de configuração, onde o usuário deve inserir o endereço de IP obtido através do no-ip, anteriormente citado. A terceira tela é a principal, com botões para comandar todas as 3 aplicações desenvolvidas e verificar o status das aplicações através de cores nos botões. A Figura 10 apresenta as três telas desenvolvidas.

Figura 10 - Telas da aplicação de controle

Fonte: Beghini (2013).

Beghini (2013) indica que os resultados obtidos foram satisfatórios. Ele ressalta que o principal problema apresentado foi o acesso externo ao Arduino, onde alguns problemas de DNS impossibilitaram o funcionamento pleno do projeto. Porém foi possível encontrar outra solução, que ao custo de aumentar o tempo de resposta do Arduino aos comandos enviados, solucionou a questão da conectividade.

(25)

24

2.7.2 Desenvolvimento de um protótipo de automação predial/residencial utilizando a plataforma de prototipagem eletrônica Arduino

Araujo et al. (2012) desenvolveu um protótipo que representa uma edificação, podendo ser interpretada como um conjunto de escritórios ou ambientes de uma residência, com o intuito de auxiliar o ensino nos cursos de Engenharia. Através do uso de diversos tipos de sensores acoplados ao Arduino foi possível simular o monitoramento de diversas variáveis envolvidas na automação residencial, como temperatura, luminosidade e estado (aberto ou fechado) de janelas e portas.

O autor elaborou uma maquete, possuindo cinco salas com portas e janelas. Foram instalados sensores tais como o LM35 (sensor de temperatura) e o LDR (sensor de luminosidade), bem como atuadores como coolers e LEDs de alta luminosidade. A Figura 11 mostra a planta desenhada e o protótipo pronto.

Figura 11 - Planta e protótipo elaborado

Fonte: Araujo et al. (2012).

Os sensores foram conectados às portas analógicas do Arduino, pois enviam um sinal de diferentes intensidades, como níveis de temperatura e intensidade da luminosidade. O atuador, neste caso um motor, foi conectado a uma porta digital configurada como saída do Arduino. Para a comunicação, foi utilizado um módulo Bluetooth, responsável pela comunicação dos dispositivos envolvidos e o usuário.

A comunicação entre os dispositivos se deu através de comunicação serial, sendo possível a comunicação via cabo ou Bluetooth. A Figura 12 ilustra a interface gráfica, desenvolvida através do AppInventor, solução que facilita a criação de aplicativos para dispositivos Android.

(26)

25

Figura 12 - Interface gráfica do aplicativo de controle

Fonte: Araujo et al. (2012).

Araujo et al. (2012) conclui que o protótipo desenvolvido atende aos objetivos definidos. Os autores ressaltam o baixo custo para o desenvolvimento do protótipo com o Arduino e comentam que existem outras plataformas similares mais baratas para projetos mais simples. Também concluem que apesar de o projeto contemplar apenas um sensor de cada tipo, nada impede que um número maior de sensores, inclusive de outros tipos, seja adicionado.

2.7.3 Webhome – Automação residencial utilizando Raspberry PI

Cruz e Lisboa (2014) desenvolveram um sistema de controle automatizado para residências baseado na placa Raspberry PI e na placa Arduino, englobando o acionamento de luzes e persianas, o monitoramento do estado de portas e janeles e o controle e monitoramento da temperatura de ambientes. Todos os dispositivos podem ser controlados através de algum dispositivo conectado à Internet. A solução de controle e monitoramento desenvolvida é um sistema web, sendo que os autores tiveram o cuidado de desenvolvê-lo de modo que fosse compatível com a maioria dos navegadores atuais.

O desenvolvimento resultou em um projeto com base eletrônica e códigos computacionais. A estrutura de comunicação, partindo do sinal emitido pelos sensores, segue para uma placa de I/O (entradas e saídas) que encaminha os sinais para o Arduino, que é responsável por receber estes sinais e enviá-los a um servidor web que roda sobre a Raspberry PI. Quando o usuário se conecta ao sistema gerenciador web, faz uma requisição via Internet para o servidor web. A Figura 13 ilustra esta estrutura.

(27)

26

Figura 13 - Estrutura de comunicação

Fonte: Cruz e Lisboa (2014).

Os autores concluíram que o projeto atendeu aos objetivos definidos. Ressaltam também a economia de energia alcançada ao usar o Raspberry PI como servidor web, tornando a aplicação relevante e economicamente viável. Também salientam que a demanda crescente por dispositivos móveis é um ponto que fornece grande impulso ao desenvolvimento e adoção de tecnologia de automação residencial, aumentando muito o impacto da automatização residencial no cotidiano dos usuários.

(28)

27

3 DESENVOLVIMENTO DO PROTÓTIPO

Neste capítulo estão descritas as especificações técnicas do protótipo proposto, o levantamento de requisitos, a especificação utilizando diagramas UML, o hardware necessário para o desenvolvimento, as técnicas, as ferramentas utilizadas e os detalhes dos códigos-fonte, bem como seu funcionamento após a conclusão do desenvolvimento.

3.1 REQUISITOS

O protótipo é um sistema de monitoramento desenvolvido para ser aplicado na FURB com o objetivo de desligar os equipamentos das salas quando as mesmas estiverem desocupadas. Para isso foi desenvolvido um dispositivo para ser instalado em salas com pontos de acesso à rede cabeada, para que atue sobre os equipamentos desligando-os através da emissão de comandos IR, com funcionalidade similar à de um controle remoto de televisão ou ar-condicionado. Também foi necessário desenvolver uma aplicação para gerenciar estes dispositivos a partir de um servidor remoto. A fim de facilitar o entendimento do trabalho, o dispositivo que ficará nas salas será chamado de Dispositivo IR, por ter como principal funcionalidade a emissão de comandos IR e a aplicação de gerenciamento será chamada de Sistema Gerenciador.

A seguir estão listados os requisitos funcionais (RF) e não funcionais (RNF) definidos para o protótipo:

a) aprender comandos IR (RF);

b) armazenar comandos IR aprendidos em um servidor remoto (RF); c) desligar equipamentos através de comandos IR (RF);

d) identificar salas vazias (RF);

e) conectar os dispositivos de controle de equipamentos diretamente ao Sistema Gerenciador (RF);

f) disponibilizar uma interface web para monitorar e gerenciar os dispositivos (RF); g) utilizar Ethernet como meio de conexão do Dispositivo IR à rede (RNF);

h) utilizar uma solução na nuvem para hospedar o Sistema Gerenciador (RNF); i) utilizar Node.JS para desenvolver o back-end do Sistema Gerenciador (RNF); j) utilizar o protocolo Websocket para conexão e troca de mensagens entre o

(29)

28

3.2 ESPECIFICAÇÃO

A especificação foi desenvolvida de acordo com a metodologia UML para a elaboração do diagrama de arquitetura, diagrama de atividades e diagrama de casos de uso. Para a elaboração dos diagramas de arquitetura e casos de uso foi utilizada a ferramenta web Cacoo e para a elaboração do diagrama de atividades foi utilizada a ferramenta web Draw.io. 3.2.1 Arquitetura do protótipo

Na Figura 14 encontra-se o diagrama de arquitetura do protótipo. Figura 14 – Diagrama de arquitetura do protótipo

Fonte: elaborado pelo autor.

O Sistema Gerenciador é composto por três partes: Servidor, Banco de dados e Cliente. O Servidor é responsável por receber a conexão Websocket do Dispositivo IR, através da qual todos os dados entre o Servidor e o Dispositivo IR serão trafegados. Outra

(30)

29

responsabilidade do Servidor é manipular o banco de dados, salvando dados enviados pelo Dispositivo IR e buscando dados posteriormente salvos. A camada Cliente diz respeito à interface com o usuário através de uma aplicação web, onde é possível monitorar Dispositivos IR conectados e editar dados de Dispositivos IR conhecidos (que já se conectaram ao Sistema Gerenciador no passado).

O Dispositivo IR é composto pelo Arduino e pelo Ethernet Shield. O Ethernet Shield é responsável por prover a capacidade de comunicação via Ethernet ao Dispositivo IR sendo completamente controlado pelo Arduino.

O Arduino é responsável por aprender os comandos IR dos controles remotos dos equipamentos que se deseja desligar, monitorar a presença de pessoas na sala através do Sensor PIR e verificar se os equipamentos da sala estão ligados ou desligados através de LDRs acoplados a uma fonte de luz do equipamento. O processo de captura de comandos deve ser feito pelo usuário diretamente no Dispositivo IR. Cada comando aprendido é posteriormente enviado ao Sistema de Gerenciamento, de modo a armazenar os comandos aprendidos em um local centralizado, eliminando a necessidade de cadastrar comandos já aprendidos por outros dispositivos. Assim que o Arduino detecta que a sala está vazia, solicita ao Sistema Gerenciador o envio dos comandos posteriormente aprendidos ou atribuídos a ele (através da interface web o usuário pode alterar os comandos atribuídos ao Dispositivo IR). Antes de emitir os comandos recebidos, o Arduino verifica se os equipamentos da sala estão ligados. Esta verificação é necessária pois alguns equipamentos têm um comando único para ligar e desligar, portanto o comando só pode ser enviado se o aparelho estiver ligado.

3.2.2 Diagrama de atividades

(31)

30

Figura 15 – Diagrama de atividades

Fonte: elaborado pelo autor.

Como pode-se observar, o fluxo de atividades do protótipo é divido em três componentes, sendo que o primeiro faz parte do Dispositivo IR e os dois restantes fazem parte do Sistema Gerenciador. A seguir são enumeradas as três partes:

a) a primeira parte corresponde às funções desempenhadas pelo Dispositivo IR, que é responsável pelas atividades de monitoramento de movimentos na sala, desligamento dos dispositivos, aprendizado e envio de comandos ao Sistema Gerenciador;

b) a segunda parte corresponde às funções desempenhadas pelo Sistema Gerenciador, no que diz respeito ao armazenamento e gerenciamento das informações enviadas pelo Dispositivo IR e pelo Cliente Web;

c) a terceira parte é o Cliente Web e corresponde à parcela do Sistema Gerenciador que trata de exibir informações sobre os Dispositivos IR conectados e suas informações. A partir do Cliente Web é possível monitorar o status e gerenciar os Dispositivos IR.

(32)

31

3.2.3 Diagrama de casos de uso

A Figura 16 mostra o diagrama de casos de uso do Sistema Gerenciador e do Dispositivo IR. Os casos de uso do diagrama estão detalhados no Apêndice A.

Figura 16 – Diagrama de casos de uso

Fonte: elaborado pelo autor. 3.3 IMPLEMENTAÇÃO

Nesta seção é detalhada a construção do Dispositivo IR, são apresentadas as técnicas e ferramentas utilizadas e a operacionalidade da implementação.

3.3.1 Construção do Dispositivo IR

Para a construção do protótipo do Dispositivo IR que ficará na sala, foi utilizado um Arduino MEGA com um Ethernet Shield W5100 acoplado. Também foram necessários LEDs emissores de IR, um receptor de IR, resistores, fios conectores, botões, transistores, um sensor PIR, um LED vermelho e LDRs. Detalhes dos componentes de hardware utilizados podem ser conferidos no Apêndice B. Na Figura 17 pode-se visualizar o esquema eletrônico completo do Dispositivo IR, o qual foi desenvolvido com a ferramenta Fritzing.

(33)

32

Figura 17 – Esquema eletrônico do Dispositivo IR

Fonte: elaborado pelo autor.

Conforme o esquema eletrônico, o pino OUT do receptor IR é conectado à porta digital 2 do Arduino e seus pinos VCC (5 volts) e GND (negativo) são respectivamente conectados às portas 5V e GND do Arduino. Este sensor é responsável por receber e enviar ao Arduino os sinais emitidos pelos controles remotos dos equipamentos.

Os botões para aprendizado do sinal 1, sinal 2 e para iniciar a operação do Dispositivo IR são respectivamente conectados às portas digitais 7, 6 e 5 do Arduino. Cada botão tem um resistor de pull-down de 1kΩ (1 kilo ohm) conectado à porta GND do Arduino. Os botões para aprendizado de sinais ativam uma rotina que recebe os sinais do controle remoto e os armazenam na memória interna do Arduino. O botão para iniciar a operação ativa a rotina que conecta o Arduino ao Servidor de Gerenciamento e inicia a operação.

O sensor PIR tem seu pino SIG conectado à porta digital 37 do Arduino e seus pinos VCC e GND são respectivamente conectados às portas 5V e GND do Arduino. Este sensor é responsável pelo monitoramento de movimentos nas salas, sendo que toda vez que um movimento é detectado, este pino vai a nível lógico alto por 5 segundos.

Um LED vermelho é conectado à portal digital 53 do Arduino, que é utilizado como LED de feedback do dispositivo, sendo ativado quando há detecção de movimento pelo sensor PIR e quando ocorre alguma falha na operação do Dispositivo IR.

(34)

33

O Arduino tem a porta digital 46 ligada à base de 6 transistores 2N2222. Todos os transistores têm seu coletor conectado ao pino 5V do Arduino. Cada transistor ao receber sinal em sua base, chaveia um LED de IR ligado ao seu pino emissor. Estes LEDs de IR são responsáveis por emitir os comandos aos equipamentos elétricos da sala. Para cada equipamento da sala são apontados 3 LEDs IR, de forma a melhorar a emissão dos sinais.

Nas portas analógicas 0 e 1 do Arduino estão conectados LDRs responsáveis por verificar se os equipamentos da sala estão ligados ou não. Cada LDR tem um resistor de pull-up de 10kΩ (10 kilo ohm) que serve para aumentar a diferença entre os valores lidos pelo Arduino quando o equipamento está ligado ou desligado. Por serem resistores que variam sua resistência conforme a incidência de luz, os LDRs são apontados para alguma fonte de luz do equipamento que esteja acesa quando o equipamento está ligado e apagada quando o equipamento estiver desligado. A Figura 18 mostra o dispositivo depois de montado.

Figura 18 – Dispositivo IR montado

(35)

34

Os detalhes do dispositivo são abordados a seguir:

a) os itens de 1 a 6 são os LEDs emissores de IR, os quais emitem os comandos para desligar os equipamentos nas salas;

b) o item 7 é o receptor de IR, o qual recebe os comandos dos controles remotos dos equipamentos, que são armazenados na memória interna do Arduino;

c) os itens 8 e 9 são os LDRs que são acoplados a uma fonte de luz de um equipamento. Estes mudam sua resistência conforme a incidência de luz, sendo usados para detectar se o equipamento está ligado ou desligado;

d) os itens 10, 11 e 12 são respectivamente os botões de iniciar operação, aprender sinal 1 e aprender sinal 2. Quando pressionados, emitem um sinal para o Arduino executar sua respectiva função;

e) o item 13 é o sensor PIR, responsável por monitorar movimentos na sala;

f) o item 14 é LED de feedback, que acende a cada vez que o sensor PIR detectar um movimento e pisca intermitentemente quando ocorre uma falha;

g) o item 15 é o Arduino com o Ethernet Shield W5100 acoplado. Este é responsável por emitir e aprender comandos IR, verificar se os equipamentos estão ligados e conectar-se ao Sistema de Gerenciamento para envio, armazenamento e recepção de comandos.

Na Figura 19 é mostrado um LDR conectado ao cabo que vai até o equipamento a ser monitorado. O LDR é apontado o mais próximo possível da fonte de luz que o equipamento emite quando está ligado.

(36)

35

Figura 19 – LDR conectado ao cabo CCI-50

Fonte: elaborado pelo autor.

A Figura 20 mostra um LDR instalado de modo a captar a luz emitida por um LED do ar-condicionado. Optou-se por utilizar fita isolante para cobrir o LDR, garantindo que somente a luz do LED do ar-condicionado seja captada.

(37)

36

Figura 20 – LDR instalado em um ar-condicionado

Fonte: elaborado pelo autor.

A Figura 21 mostra um LDR instalado em um projetor. A única maneira encontrada para verificar se o projetor está ligado ou não, foi apontando o LDR diretamente para a lente do projetor, pois nos projetores testados o LED indicador fica aceso na cor laranja quando o mesmo está desligado. Quando o projetor está ligado, o LED do projetor acende e apaga intermitentemente na cor verde.

(38)

37

Figura 21 – LDR instalado em um projetor

Fonte: elaborado pelo autor.

3.3.2 Técnicas e ferramentas utilizadas

O protótipo é dividido em 3 partes: Dispositivo IR, Servidor e Cliente. Para desenvolver o código-fonte que roda no Dispositivo IR, foi utilizada a linguagem C++, que é a linguagem de programação padrão para desenvolvimento no Arduino. A ferramenta de codificação foi a IDE Arduino. Para conectar-se à Internet foi utilizada a biblioteca Ethernet, que é parte integrante da API padrão do Arduino. Para implementar a comunicação Websocket com o Sistema de Gerenciamento, foi utilizada a biblioteca externa Socket.io-v1.x-Library. Para emitir e receber os comandos IR foi utilizada a biblioteca externa IRremote e para gerar os segmentos dos comandos que trafegam entre o Sistema de Gerenciamento e o Dispositivo IR, foi utilizada a biblioteca externa ArduinoJson.

Na parte do Servidor, foi utilizada a linguagem JavaScript sobre a engine Node.JS. Para a codificação foi utilizada a IDE Visual Studio Code. Para o servidor web foi utilizado o framework Express e para implementar as conexões Websocket com o Dispositivo IR e

(39)

38

com o Cliente foi utilizado o framework Socket.IO. Para o armazenamento de dados, foram escolhidos o banco de dados MongoDB e o Mongoose.JS como framework de persistência.

Para o desenvolvimento do Cliente foram utilizadas as linguagens HTML, CSS e JavaScript e as bibliotecas jQuery, Bootstrap e Socket.IO. Para a codificação também foi utilizada a IDE Visual Studio Code. O versionamento dos códigos-fonte das 3 partes do protótipo foi feito através da ferramenta Git, com os códigos hospedados no serviço GitHub. 3.3.3 Códigos-fonte do protótipo

Nesta seção são apresentados trechos de código para destacar aspectos importantes do protótipo, os quais estão divididos entre o Dispositivo IR, o Servidor e o Cliente.

3.3.3.1 Dispositivo IR

O Quadro 1 apresenta o principal método do Arduino, que permanece em execução contínua após a inicialização do Dispositivo IR. Quando há movimentos detectados na sala, o método monitoraSalaCheia é executado repetidas vezes. Quando não for detectado movimento na sala por mais de 60 segundos, o Dispositivo IR solicita sinais ao Sistema de Gerenciamento para desligar os equipamentos da sala. Assim que os equipamentos da sala são desligados, o Dispositivo IR entra em modo stand-by e passa a executar o método monitoraSalaVazia, que ao detectar algum movimento na sala, reconecta o Dispositivo IR ao Sistema de Gerenciamento e volta a executar o método monitoraSalaCheia. No Quadro 2 encontra-se o código do método monitoraSalaCheia. No Quadro 3 encontra-se o código do método monitoraSalaVazia.

Quadro 1 – Loop principal void loop() { if (salaVazia) { monitoraSalaVazia(); } else { enviarKeepAlive(); monitoraSalaCheia(); } }

(40)

39

Quadro 2 – Método monitoraSalaCheia void monitoraSalaCheia() {

statusPIR = digitalRead(PIN_PIR);

if (!statusPIR) { //Não há movimentação digitalWrite(PIN_LED_FDB, LOW); if (!contadorIniciado) { contadorIniciado = true; tempoContador = millis(); } else { if ((millis() - tempoContador) >= 10000) { Serial.println(F("Requisitando

autorização para desligar dispositivos...")); notificaServidor(); contadorIniciado = false; tempoContador = 0; } } } else { //Há movimentação digitalWrite(PIN_LED_FDB, HIGH); contadorIniciado = false; tempoContador = 0; } }

Fonte: elaborado pelo autor.

Quadro 3 – Método monitoraSalaVazia void monitoraSalaVazia() { statusPIR = digitalRead(PIN_PIR); if (statusPIR) { //Há movimentação digitalWrite(PIN_LED_FDB, HIGH); Serial.println(F("Reconectando dispositivo ao servidor...")); setupComunicacao(); salaVazia = false; Serial.println(F("Retomando monitoramento...")); } }

Fonte: elaborado pelo autor.

Os Quadros 4 e 5 mostram, respectivamente, os métodos arEstaLigado e projetorEstaLigado. Estes métodos são executados antes de desligar um equipamento e seu valor de retorno condiciona a emissão dos comandos aos equipamentos, pois somente são emitidos comandos para equipamentos que estão ligados. Alguns equipamentos usam o mesmo comando para ligar e desligar, portanto, é necessário verificar se o equipamento está ligado.

(41)

40

Quadro 4 – Método arEstaLigado bool arEstaLigado() { ldrAr = analogRead(PIN_LDR_AR); if (ldrAr >= 600) { //Desligado Serial.println(F("Ar-condicionado desligado...")); Serial.print(F("Medição: ")); Serial.println(ldrAr); return false; } else { //Ligado Serial.println(F("Ar-condicionado ligado...")); Serial.print(F("Medição: ")); Serial.println(ldrAr); return true; } }

Fonte: elaborado pelo autor.

Quadro 5 – Método projetorEstaLigado bool projetorEstaLigado() { ldrPr = analogRead(PIN_LDR_PR); if (ldrPr >= 150) { //Desligado Serial.println(F("Projetor desligado...")); Serial.print(F("Medição: ")); Serial.println(ldrPr); return false; } else { //Ligado Serial.println(F("Projetor ligado...")); Serial.print(F("Medição: ")); Serial.println(ldrPr); return true; } }

Fonte: elaborado pelo autor.

Devido às limitações da biblioteca Socket.io-v1.x-Library, não é possível enviar mensagens via Websocket que sejam maiores do que 150 bytes, o que impossibilita enviar de uma só vez o comando aprendido. Para contornar este problema, foi desenvolvido o método geraJSONsinais, que segmenta o comando em partes de 15 pulsos ou menos e envia estas partes sequencialmente ao Sistema de Gerenciamento. Cada segmento de pulsos é convertido e enviado ao Sistema de Gerenciamento como um array JSON, facilitando a interpretação e armazenamento do segmento pelo Sistema de Gerenciamento. O Quadro 6 mostra o código do método geraJSONsinais.

(42)

41

Quadro 6 – Método geraJSONsinais

void geraJSONsinais(unsigned int tamanhoSinal, unsigned int* sinais) {

unsigned int quantDivisoes = 0; bool ehMultiplo15 = false; unsigned int contadorSinal = 0;

const char idMensagem[] = "arrayPart"; if (tamanhoSinal%15 == 0) { quantDivisoes = tamanhoSinal/15; ehMultiplo15 = true; } else { quantDivisoes = tamanhoSinal/15+1; ehMultiplo15 = false; } enviarMensagem("sigSend", "msg", "start"); for (int i=1; i<=quantDivisoes; i++) { StaticJsonBuffer<JSON_ARRAY_SIZE(15)> jb; JsonArray& arrayJSON = jb.createArray(); if (ehMultiplo15) {

for (int j=contadorSinal; j<contadorSinal+15; j++) { arrayJSON.add(sinais[j]); } contadorSinal += 15; enviarJSON(idMensagem, arrayJSON); } else { if (i < quantDivisoes) { for (int k=contadorSinal; k<contadorSinal+15; k++) { arrayJSON.add(sinais[k]); } contadorSinal += 15; enviarJSON(idMensagem, arrayJSON); } else {

for (int l=contadorSinal; l<tamanhoSinal; l++) { arrayJSON.add(sinais[l]); } enviarJSON(idMensagem, arrayJSON); } } } enviarMensagem("sigSend", "msg", "end"); }

Fonte: elaborado pelo autor. 3.3.3.2 Servidor

No Quadro 7 encontra-se a função que identifica os Dispositivos IR que se conectam ao Sistema de Gerenciamento. Caso o dispositivo nunca tenha se conectado, ele é reconhecido como sendo novo e inserido no banco de dados. Se o dispositivo já se conectou anteriormente ao Sistema Gerenciador, suas informações são buscadas no banco de dados.

(43)

42

Quadro 7 – Função que identifica os dispositivos socket.on('identify', data => {

socket.clientID = data.id

if (socket.clientID == 'web') { console.log("[WEB] Cliente web se conectou.")

adminsWeb.push(socket.id) } else {

let query = Arduino.where({ clientID: socket.clientID })

query.findOne( (err, record) => { if (err)

return console.error('[ERR] Erro na query de banco (identify).', err)

if (!record) {//Novo dispositivo se conectou

console.log(`[NEW] Cliente '${socket.clientID}' identificado.`)

isNewDevice = true

arduinoBanco = new Arduino arduinoBanco.clientID = socket.clientID

} else {//Dispositivo já conhecido se conectou console.log(`[OLD] Cliente '${socket.clientID}' identificado.`) arduinoBanco = record } }) } })

Fonte: elaborado pelo autor.

No Quadro 8 encontra-se a função responsável por preparar o Sistema Gerenciador para receber os comandos enviados pelo Dispositivo IR e no Quadro 9 encontra-se a função responsável por receber e armazenar cada segmento de comando. Através da mensagem start o Dispositivo IR avisa que deseja enviar segmentos de comandos. Neste momento, o Sistema Gerenciador cria um objeto de banco. Em seguida, cada segmento de sinal é recebido em uma mensagem arrayPart e é atribuído ao objeto de banco. Após o Dispositivo IR enviar o último segmento de comando, ele emite uma mensagem end, informando que todos os segmentos foram enviados. Neste momento o Sistema Gerenciador persiste em banco o objeto recém manipulado.

(44)

43

Quadro 8 – Função de recepção de comandos socket.on('sigSend', data => {

switch (data.msg) { case 'start':

console.log(`[SIG] Recebendo segmentos de sinal do cliente '${socket.clientID}'`)

signalBanco = new Signal

signalBanco.description = `Adicionado em: ${new Date().toLocaleString('pt-BR')}`

break case 'end':

console.log(`[SIG] Recepção de segmentos de sinal do cliente '${socket.clientID}'

terminou.`)

if (!isNewDevice && isFirstSignal) { arduinoBanco.set({ signalKeys: [] }) isFirstSignal = !isFirstSignal } arduinoBanco.signalKeys.push(signalBanco.id) signalBanco.save((err, signalBanco) => { if (!err) {

console.log(`[SIG] Comando para o cliente '${socket.clientID}' persistido.`)

} else return console.error(err) })

break }

})

Fonte: elaborado pelo autor.

Quadro 9 – Função que armazena os segmentos de comandos socket.on('arrayPart', data => {

signalBanco.signal.push(data) })

Fonte: elaborado pelo autor.

Nos Quadros 10 e 11 são exibidos os trechos de código responsáveis por buscar e enviar os comandos ao Dispositivo IR. No Quadro 10, o Dispositivo IR envia a mensagem emptyRoom, informando que a sala está vazia. Se a hora atual estiver dentro do período de desligamento autorizado (entre 22 horas e 7 horas da manhã na FURB), o Sistema Gerenciador envia a mensagem ok ao Dispositivo IR e busca seus comandos no banco de dados. Caso contrário, a mensagem nok é enviada ao Dispositivo IR. No Quadro 11, quando o Dispositivo IR é autorizado a desligar os equipamentos da sala, ele solicita os segmentos de comandos do ar-condicionado através da mensagem send1 e os segmentos de comandos do projetor através da mensagem send2. A cada mensagem send1 ou send2 recebida, o Sistema Gerenciador envia um segmento do comando ao Dispositivo IR. Após todos os segmentos serem enviados, é enviada a mensagem eS, sinalizando o fim do envio de segmentos.

(45)

44

Quadro 10 – Autorização e busca dos comandos no banco de dados case 'emptyRoom':

if (new Date().getHours() >= 22) {

socket.emit('monitoring', { msg: 'ok' }) let queryArduino = Arduino.where({ clientID: socket.clientID })

queryArduino.findOne(function(err, record) {

if (err) return console.error(err) arduinoBanco = record

})

let querySignal1 = Signal.where({ _id: arduinoBanco.signalKeys[0] })

querySignal1.findOne(function(err, record) {

if (err) return console.error(err) if (record) {

comando1 = record.signal }

})

let querySignal2 = Signal.where({ _id: arduinoBanco.signalKeys[1] })

querySignal2.findOne(function(err, record) {

if (err) return console.error(err) if (record) { comando2 = record.signal } }) } else { socket.emit('monitoring', { msg: 'nok' }) } break

Fonte: elaborado pelo autor.

Quadro 11 – Envio dos segmentos de comando case 'send1':

if (comando1 != null && comando1.length > 0) { socket.emit('sP', { s: `[${comando1[0]}]` }) comando1.splice(0,1) } else { socket.emit('sP', { s: 'eS'}) } break case 'send2':

if (comando2 != null && comando2.length > 0) { socket.emit('sP', { s: `[${comando2[0]}]` }) comando2.splice(0,1) } else { socket.emit('sP', { s: 'eS'}) } break

(46)

45

3.3.3.3 Cliente

No Quadro 12 é exibida a função updateDevicesStatus, que é responsável por preencher as listas de Dispositivos IR online e offline. Esta função busca no banco de dados por todos os dispositivos cadastrados no Sistema Gerenciador e os adiciona às listas devicesOnline ou devicesOffline, dependendo de seu status no momento.

Quadro 12 – Função que atualiza o status dos Dispositivos IR async function updateDevicesStatus() {

devicesOnline.splice(0,devicesOnline.length) devicesOffline.splice(0,devicesOffline.length) connectedClients = await

getAllConnectedClients()

devicesDB = await getAllDevices() devicesDB.forEach((currentDevice) => { if (connectedClients.indexOf(currentDevice.clientID) == -1) devicesOffline.push(currentDevice) else devicesOnline.push(currentDevice) })

console.log("[LOG] Lista de dispositivos online atualizada.")

await updateDevicesSignalsNames() sendClientDevices()

}

Fonte: elaborado pelo autor.

No Quadro 13 é exibida a função getAllSignals, que é responsável por buscar todos os comandos no banco de dados. No Quadro 14 é exibida a função updateSignalsList, que após buscar os comandos no banco de dados, atualiza a lista de comandos no Sistema Gerenciador.

Quadro 13 – Função que busca os comandos no banco de dados function getAllSignals() {

return new Promise((resolve,reject) => { let query = Signal.where({})

query.find( (err, results) => {

if (err) return console.error('[ERR] Erro buscando todos os sinais do banco para WEB.')

resolve(results) })

}) }

Fonte: elaborado pelo autor.

Quadro 14 – Função de atualização e envio de comandos async function updateSignalsList() {

signalsList = await getAllSignals() sendClientSignals()

}

(47)

46

O Quadro 15 exibe as funções sendClientDevices e sendClientSignals, que são responsáveis por enviar à interface de monitoramento as listas de Dispositivos IR online e offline e as listas de comandos cadastrados no banco de dados, respectivamente, através de mensagens Websocket.

Quadro 15 – Funções que enviam informações à interface de monitoramento function sendClientDevices() {

adminsWeb.forEach((currentClient) => { arduinoNM.connected[currentClient]

.emit('updateDevices', { online: devicesOnline, offline: devicesOffline }) }) } function sendClientSignals() { adminsWeb.forEach((currentClient) => { arduinoNM.connected[currentClient].emit('updateSignals', { signals: signalsList }) }) }

Fonte: elaborado pelo autor.

3.3.4 Operacionalidade da implementação

A primeira etapa envolve cadastrar no Dispositivo IR os comandos dos equipamentos que se deseja desligar. Esta etapa está descrita com detalhes no caso de uso UC01 no Apêndice A. Opcionalmente, o usuário pode iniciar a operação do dispositivo sem cadastrar comandos, bastando pressionar o botão de iniciar operação. O caso de uso UC02 no Apêndice A, contém os detalhes desta etapa. Se foram cadastrados sinais, o Dispositivo IR se conectará ao Sistema Gerenciador, os enviará e iniciará a operação. Caso contrário, o Dispositivo IR se conecta ao Sistema Gerenciador e inicia sua operação.

A segunda etapa envolve a operação do Dispositivo IR. Após se conectar ao Sistema Gerenciador e enviar os seus comandos aprendidos, inicia-se a tarefa de monitoramento. Nesta tarefa o dispositivo fica constantemente monitorando movimento na sala. Caso não sejam captados movimentos durante um tempo pré-determinado, o dispositivo emite uma mensagem ao Sistema Gerenciador, informando-o que a sala está vazia. Se a hora atual compreende o período de desligamento, o Sistema Gerenciador envia uma mensagem ao Dispositivo IR autorizando o desligamento dos equipamentos. Caso a hora atual esteja fora do período de desligamento, o Sistema Gerenciador envia uma mensagem e o Dispositivo IR volta à rotina de monitoramento da sala. Mesmo que movimentos não estejam sendo detectados na sala fora do período de desligamento, os equipamentos não são desligados, pois podem haver pessoas na sala que estejam fazendo poucos movimentos que

(48)

47

não são detectados pelo Dispositivo IR (caso estejam sentadas estudando ou trabalhando, por exemplo). No caso do Dispositivo IR ser autorizado a desligar os equipamentos, ele envia uma mensagem ao Sistema Gerenciador solicitando os comandos a ele atribuídos. Após o recebimento dos comandos, o Dispositivo IR verifica se os equipamentos para os quais os comandos serão emitidos estão ligados ou desligados e somente emite os comandos para equipamentos ligados. Esta verificação se faz necessária pois dispositivos como projetores e televisores recebem o mesmo comando para ligar e desligar. Após o Dispositivo IR emitir os comandos, ele verifica por três vezes se o equipamento desligou e reemite o comando caso o mesmo não tenha se desligado. Se o Dispositivo IR não conseguir desligar o equipamento nestas tentativas, ele emite ao Sistema Gerenciador uma mensagem informando qual dispositivo não pôde ser desligado. Em seguida, independente se o desligamento dos equipamentos foi feito com sucesso ou não, o Dispositivo IR se desconecta do Sistema Gerenciador e entra em modo stand-by. Neste modo, o monitoramento de movimentos na sala continua sendo feito. Caso um movimento seja detectado, o Dispositivo IR sai do modo stand-by, reconecta-se ao Sistema Gerenciador e reinicia sua operação. Há também um LED de feedback ao usuário, que pisca intermitentemente caso ocorra alguma falha que impeça o funcionamento do Dispositivo IR (indisponibilidade da rede Ethernet ou do Sistema Gerenciador). Quando ocorre uma falha, é necessário reiniciar o Dispositivo IR.

A terceira etapa envolve as tarefas de monitoramento e gerenciamento dos Dispositivos IR e dos comandos, através da interface web. Nesta interface existem 3 telas. Na tela de Informações são encontradas as instruções de uso. Na tela de Dispositivos é possível visualizar uma tabela contendo todos os dispositivos cadastrados no Sistema Gerenciador, bem como suas informações: ID da sala onde está instalado, descrição, comandos atribuídos, status (online/offline) e status de falha. Dispositivos IR com status online sinalizam que há movimentação na sala onde estão instalados. Dispositivos IR com status offline sinalizam que a sala está vazia, pois quando o Dispositivo IR detecta que não há movimentos na sala e desliga os dispositivos, ele se desconecta do Sistema Gerenciador. Na Figura 22 é exibida a tela de Informações e na Figura 23 é exibida a tela de Dispositivos.

Referências

Documentos relacionados

1- Indica com P, se a frase estiver na voz passiva e com A se estiver na ativa. Depois, passa-as para a outra forma. a) Vimos um cisne moribundo.. Assinala com um X o

1- Indica com P, se a frase estiver na voz passiva e com A se estiver na ativa. Depois, passa-as para a outra forma.. Assinala com um X o retângulo correspondente.. Derivada

- Analisando a movimentação da Ordem de Produção pelo CS0503, por exemplo, verifica-se um movimento ACA no período de JAN/2016 e não encontra nenhum movimento

Local de realização da avaliação: Centro de Aperfeiçoamento dos Profissionais da Educação - EAPE , endereço : SGAS 907 - Brasília/DF. Estamos à disposição

Note on the occurrence of the crebeater seal, Lobodon carcinophagus (Hombron &amp; Jacquinot, 1842) (Mammalia: Pinnipedia), in Rio de Janeiro State, Brazil.. On May 12, 2003,

Não houve diferenças estatísticas no tipo de bactéria isolada segundo os grupos definidos (Streptococcus sp, outros aeróbios e anaeróbios) com relação ao uso ou não

servidores, software, equipamento de rede, etc, clientes da IaaS essencialmente alugam estes recursos como um serviço terceirizado completo...

A) Valorizar a comunidade surda em virtude de ser universal, ampliando os artefatos culturais dos sujeitos surdos brasileiros. B) Constituir os valores, os costumes, a