• Nenhum resultado encontrado

Comparativo dos resultados com os trabalhos correlatos

3.4 ANÁLISE DOS RESULTADOS

3.4.3 Comparativo dos resultados com os trabalhos correlatos

O Quadro 16 apresenta um comparativo entre as funcionalidades presentes nos trabalhos correlatos, o protótipo estendido e o protótipo desenvolvido.

Quadro 16 – Comparativo entre os trabalhos correlatos e o proposto

Características Trabalhos Beghini (2013) Araújo et al. (2012) Lisboa e Cruz (2014) Sabel (2016) Este trabalho

Plataforma Arduino Arduino

Arduino / Raspberry

PI

Arduino Arduino Permite monitoramento via

Internet Sim Não Sim Não Sim

Possui servidor de gerenciamento Não Não Sim Não Sim

Armazena histórico Não Não Não Não Não

Suporta vários tipos de

sensores/atuadores Sim Sim Sim Não Não

Suporte a câmeras Sim Não Não Não Não

Controla equipamentos via

comandos IR Não Não Não Sim Sim

Reporta falhas no controle dos

equipamentos Não Não Não Não Sim

Consulta o status do

ambiente/equipamento eletrônico Não Sim Sim Sim Sim

Utiliza conexões Websocket Não Não Não Sim Sim

Fonte: elaborado pelo autor.

Todos os trabalhos fazem uso do Arduino como dispositivo de monitoramento e controle de atuadores, com exceção do trabalho de Lisboa e Cruz (2014), que utiliza um

54

Raspberry PI como intermediário entre o servidor e o Arduino. Nenhum dos trabalhos armazena histórico de dados de sensores ou de ações realizadas e apenas o protótipo proposto reporta falhas no controle dos equipamentos.

Ao comparar o trabalho de Beghini (2013), percebe-se que apesar do mesmo contar com monitoramento via Internet, não existe um servidor dedicado a reunir as informações vindas dos sensores e atuadores. O trabalho de Beghini (2013) não controla equipamentos via comandos IR, não utiliza conexões Websocket para tráfego de dados e não consulta o status dos sensores e atuadores, ficando esta responsabilidade a cargo do usuário do aplicativo. Entretanto, é o único trabalho com suporte a câmeras.

O trabalho de Araújo et al. (2012) suporta vários tipos de sensores e atuadores, como LDRs e coolers de ventilação. Por contar com sensores, o trabalho permite o monitoramento do status do ambiente ou dos equipamentos que monitora. Conta apenas com monitoramento e gerenciamento via Bluetooth e, portanto, não usa conexões Websocket. Por se tratar do desenvolvimento de uma maquete, não conta com servidor dedicado ao gerenciamento e não é possível efetuar monitoramento via Internet.

Comparando o trabalho de Lisboa e Cruz (2014), verifica-se que o mesmo permite monitoramento via Internet e possui um servidor dedicado ao gerenciamento. Apesar de conectar-se à Internet, não faz uso de conexões Websocket para a troca de informações. Não controla equipamentos através de comando IR, apenas através de relês que utiliza para controle de iluminação e persianas. Por controlar persianas e luminosidade, precisa monitorar o status dos equipamentos de modo a emitir o comando correto.

O protótipo de Sabel (2016) tem funcionalidade muito semelhantes ao protótipo proposto. Não conta com servidor dedicado ao monitoramento, realizando o monitoramento através de conexões Websocket diretamente a um navegador web. Sabel (2016) fez uso de um sensor de corrente não-invasivo para detectar se o equipamento estava ligado ou não, porém esta solução não é aplicável aos casos de equipamentos que ao serem desligados pelo controle entram em modo stand-by. Neste caso ainda há leitura e corrente, e o protótipo erra a detecção de status. O trabalho de Sabel (2016) também não permite monitoramento pela Internet, apenas pela rede interna. Isso implica na criação de uma sub-rede exclusiva para a conexão dos dispositivos e do servidor, o que não acontece no caso do protótipo proposto, pois o servidor de gerenciamento roda na nuvem e qualquer dispositivo com conexão à Internet pode se conectar diretamente a ele. O protótipo de Sabel (2016) desliga equipamentos através de comandos IR, porém usa apenas um LED emissor de IR. No trabalho proposto foram

55

adotados três LEDs emissores de IR para cada equipamento a ser desligado, tornando a emissão de comandos mais confiável e menos suscetível a falhas e interferências.

Por fim, o trabalho proposto se mostra relevante por utilizar componentes de baixo custo e de fácil acesso para desempenhar suas funções. O uso de conexões Websocket entre o Dispositivo IR e o Sistema Gerenciador é um recurso confiável e proporciona rapidez na troca de dados entre as partes. Por contar com um modo stand-by, o Dispositivo IR pode atuar de forma autônoma após ser instalado na sala, sendo necessário a intervenção humana apenas em caso de falhas reportadas.

56

4 CONCLUSÕES

O objetivo de desenvolver um protótipo para controlar equipamentos através de comandos IR com monitoramento remoto via Internet foi atendido adequadamente. O protótipo cumpre com todos os objetivos específicos definidos e aplica melhorias nas funcionalidades do protótipo estendido.

O uso da engine Node.JS no servidor supriu todas as necessidades de conectividade com o Arduino e agilizou o desenvolvimento da interface web, pois o uso da linguagem Javascript no servidor e na interface facilitou a transferência de dados entre ambas. A biblioteca Socket.io-v1.x-Library, apesar das limitações, também foi um grande facilitador para as conexões Websocket entre o Arduino e o servidor.

As ferramentas utilizadas para o desenvolvimento e para a especificação atenderam bem as necessidades do projeto. Porém a execução de testes com o Arduino durante o desenvolvimento do Dispositivo IR demandou maior tempo e atenção, pois a cada alteração da codificação foi necessário compilar e enviar o código ao Arduino, o que se mostrou um processo lento. Os testes do Sistema Gerenciador e da interface web decorreram de forma satisfatória, devido a abundância de recursos existentes para depuração e testes de execução em sistemas web.

O Arduino Mega demonstrou ser uma plataforma de prototipação muito poderosa e versátil. A grande quantidade de portas digitais e analógicas torna possível o uso de diversos sensores e atuadores simultaneamente e a API da plataforma conta com funções que agilizam o desenvolvimento do hardware. A grande quantidade de bibliotecas e documentação na Internet também é outro positivo, que auxilia muito no desenvolvimento.

O desenvolvimento do protótipo proposto se justifica pela economia de energia e comodidade proporcionadas com o tempo. Os custos com vigias e o tempo gasto pelos mesmos para verificar os equipamentos de cada sala também podem ser reduzidos. O potencial de redução de custos com energia elétrica e pessoal é alto, principalmente se aplicado a edificações com grande quantidade de salas e equipamentos de alto consumo energético.

A partir dos resultados pode-se concluir que embora diversas dificuldades tenham ocorrido no decorrer do desenvolvimento, os objetivos foram alcançados e o protótipo proposto se mostra adequado às necessidades para as quais foi desenvolvido.

57

Documentos relacionados