Uma proposta de Detecção de Incêndio para IoT utilizando a plataforma Arduino

Prévia do material em texto

Uma proposta de Detecção de Incêndio para IoT utilizando a 
plataforma Arduino 
Issacar dos Santos Beche 
Graduando de Ciência da Computação – Universidade Regional Integrada do Alto 
Uruguai e das Missões – Campus Santiago (URI – Santiago) 
Caixa Postal 97700-000 – Santiago – RS – Brasil 
issacarbeche@gmail.com 
Abstract. The fire detection systems are vital in homes and businesses as they 
aim at minimizing risks. This project aims to implement a fire detection 
system, making use of the Arduino prototyping platform and the concepts of 
the internet of things. Nowadays the products present in the market have a 
high value and with limited functionalities. This work makes use of Arduino to 
create a system with lower energy consumption, with a lower manufacturing 
cost than existing ones and integration with cloud servers using the 
Thingspeak platform. 
Resumo. Os sistemas de detecção de incêndio são vitais em residências e 
empresas, pois visam a minimização de riscos. Este projeto tem como objetivo 
implementar um sistema de detecção de incêndios, fazendo uso da plataforma 
de prototipagem do Arduino e dos conceitos de internet das coisas. 
Atualmente os produtos presentes no mercado possuem um valor elevado e 
com funcionalidades limitadas. Este trabalho faz uso do Arduino para criar 
um sistema com menor consumo energético, com um custo de fabricação 
inferior aos existentes e integração com servidores em nuvem utilizando a 
plataforma Thingspeak. 
1. Introdução 
Atualmente a demanda por produtos os quais venham a contribuir para a segurança e 
bem-estar tanto residencial quanto predial vem aumentando (Arion, 2019). Em conjunto 
com as novas inovações, destacam-se a criação de sistemas de detecção de incêndio, 
com o propósito de alertar possíveis focos de chamas, através de sensores e mecanismos 
de alerta tanto visual quanto sonoro. Segundo Sena (2005) a automação residencial não 
é apenas tecnologia por si só, ela está diretamente relacionada à qualidade de vida dos 
usuários, procurando atender aspectos tecnológicos que proporcionem um maior bem-
estar, economia e segurança. 
De acordo com a interseção de dados do Sistema Único de Saúde (SUS), e do 
levantamento realizado pela Geneva Association (2015), organização suíça que analisa 
estatísticas internacionais relacionadas a gerenciamentos de riscos, o Brasil está em 
terceiro lugar no ranking mundial de mortes por incêndio, catalogando uma média de 
mil mortes anuais. Conforme a Secretaria Nacional de Segurança Pública (Senasp), no 
ano de 2015 o país teve uma média de 267 mil incêndios (incluindo ocorrências 
florestais e residenciais). 
Contudo Imteaj (2017) destaca que em países subdesenvolvidos e também 
emergentes assim como o Brasil a aquisição destes produtos torna-se difícil, devido à 
 
custos elevados, falta de incentivos e leis governamentais, características duvidosas, 
inoportunas, e algumas tecnologias ultrapassadas, consequentemente levando a 
população a não aderir a um sistema de monitoramento residencial. 
Existem propostas no atual estado da arte que buscam diferentes soluções para 
as problemáticas mencionadas anteriormente, nelas, se destacam os trabalhos dos 
pesquisadores Muheden e Abaya. [Muheden 2016] apresenta uma proposta de 
monitoramento residencial utilizando o Arduino e os sensores de umidade, gás, fogo e 
Wi-Fi, o funcionamento se dá através do envio dos dados coletados em tempo real para 
um aplicativo instalado em um dispositivo móvel. Por outro lado, [Abaya 2016] 
desenvolveu um projeto em que é feito o envio de uma mensagem via SMS (Short 
Message Service) quando é detectada a presença de fumaça, para isso fez uso de um 
módulo GSM (Global System for Mobile) em uma central a qual quando acionada emite 
um alerta visual. 
O presente trabalho tem como escopo a resolução dos problemas encontrados 
nas tecnologias de detecção de incêndio, trazendo como enfoque um dispositivo com 
menor custo de aquisição e com um consumo energético inferior aos já existentes. 
Também explorando o conceito de IoT (Internet of Things) e tecnologias que não foram 
abordadas pelos trabalhos dos pesquisadores Muheden e Abaya, tais como capacidade 
de armazenamento de dados coletados em nuvem e avisos visuais de falhas encontradas 
nos periféricos do dispositivo. 
Para a realização do escopo pretendido no presente trabalho partiu-se de uma 
metodologia de levantamento bibliográfico de artigos científicos e trabalhos 
acadêmicos. No desenvolvimento do projeto foi utilizado o Arduino Uno R3, 
juntamente com o sensor de temperatura LM35, módulo Wi-Fi ESP8266, detector de 
gás/fumaça (MQ2) e Led RGB, fazendo uso da IDE (Integrated Development 
Environment) open-source fornecida pelo Arduino. Baseando-se na utilização de 
sensores de detecção de gás / fumaça e de temperatura, realizando a comunicação 
através do sensor Wi-Fi, subsequentemente acessando a rede de internet e 
encaminhando as alterações ocorridas nos sensores para armazenamento de dados em 
nuvem. 
Através da comparação das especificações técnicas, foi indicando o gasto 
energético nos sistemas de incêndios existentes no mercado com o desenvolvido, foi 
comprovado o seu custo inferior para mantenabilidade. Os registros de todas as 
informações sobre anomalias ocorridas na residência e no próprio hardware, assim 
como temperaturas ficarão salvas na plataforma em nuvem Thingspeak para futuro 
consumo de dados. 
Como contribuição o sistema de detecção de incêndios irá proporcionar um 
menor consumo energético, assim como a possibilidade de registrar todas as 
informações sobre temperatura, anomalias ocorridas na residência e também no próprio 
hardware, sendo que as mesmas ficarão salvas na plataforma em nuvem Thingspeak 
para futuro consumo de dados. 
 
Este artigo é dividido em seções, a seção 2 é descrito os conceitos fundamentais 
do Arduino, caracterizado pelos ambientes de desenvolvimento, dispositivos e 
componentes existentes. Na seção 3 é detalhado a arquitetura e os protocolos de 
 
referência da internet das coisas (internet of things), assim como as tecnologias de 
comunicação e os paradigmas para objetos inteligentes. Já na seção 4 é abordada os 
trabalhos relacionados. Após, na seção 5 encontra-se a proposta do artigo em conjunto 
com as especificações do protótipo e o uso da plataforma em nuvem ThingSpeak, 
também consta os resultados obtidos e trabalhos futuros. Por fim, a seção 6 constitui-se 
das considerações finais. 
2. Arduino 
De acordo com OSIER (2010) o Arduino é uma plataforma de prototipagem que foi 
desenvolvida tendo em mente a simplicidade para o usuário final. Possui um modelo de 
programação de fácil aprendizado e seu design é totalmente aberto. Além de possuir um 
vasto acervo de documentação, placas complementares (Shields), produtos derivativos e 
o suporte de uma grande comunidade de desenvolvedores. 
 Segundo McRoberts (2015) o Arduino pode ser utilizado para desenvolver 
objetos interativos independentes ou pode ser conectado a um computador, a uma rede, 
ou até mesmo à Internet para recuperar e enviar dados do Arduino e atuar sobre eles. 
Em termos práticos, um Arduino é um pequeno microcontrolador, capaz de ser 
programado para processamento de dados de entrada e saída. Ele também é denominado 
de plataforma de computação física ou embarcada, o qual interagir com o ambiente por 
meio de hardware e/ou software. Sua plataforma é formada por dois componentes 
principais: software e hardware. O software é uma IDE executada em um computador, 
local onde é realizado a programação, conhecida como sketch, na qual se realiza o 
upload para o firmware do Arduino, através da comunicação serial. O sketch realizado 
pelo projetista/programador dirá à placa o que deve ser executado durante o seu 
funcionamento. Já o hardware é composto por uma placa de prototipagem e seus 
periféricos afins, na qual são executadosos projetos. 
 A seguir na seção 2.1 e 2.2 será descrito seus conceitos fundamentais de 
funcionamento em níveis de software e hardware, respectivamente, logo em seguida na 
seção 2.3 trata-se de seus componentes complementares, por fim na seção 2.4 constitui-
se de uma conclusão parcial. 
2.1 Software 
Seu ambiente de programação é de fácil usabilidade para iniciantes, assim como flexível 
para usuários avançados. O software nativo é denominado Arduino IDE, o qual 
apresenta um alto grau de abstração, permitindo ao usuário manipular o hardware sem 
se deter ao conhecimento da utilização do microcontrolador e de seus registradores 
internos de trabalho. Sua IDE é munida de bibliotecas, estas responsáveis por fornecer 
funcionalidades especificas a determinadas módulos, simplificando o desenvolvimento 
de uma aplicação. 
 Devido ao seu código-fonte aberto e extensível, possibilitou a criação de plug-
ins para programação em outras ferramentas, tais como Codeblocks, Eclipse, Netbeans, 
Proteus (entre outros), assim como proporcionou a criação de uma nova ferramenta 
volta para uma área especifica, por exemplo o Ardublock (programação gráfica para 
Arduino). 
 O Arduino IDE é multiplataforma, baseado em linguagens de programação C e 
C++, pode ser obtido de forma gratuita no site da empresa, ou adquirido através dos 
 
repositórios dos sistemas Linux. Sua interface é simples e intuitiva, conforme mostra 
figura 1, a mesma, já contém bibliotecas e exemplos pré-programados. 
 
Figura 1. Ambiente de Desenvolvimento do Arduino. 
Fonte: Do Autor. 
 Para iniciar a utilização da IDE, não é necessário ter a placa física conectada ao 
USB do computador, basta apenas executar o programa. Entretanto para realizações de 
testes e implementações visuais, se torna necessário a configuração do dispositivo USB 
no software, através da inserção do modelo de Arduino e logo em sequência predefinir o 
dispositivo serial (Figura 2). 
 
Figura 2. Sistema para Reconhecimento da Placa. 
Fonte: Do Autor. 
 
 Seu ciclo de programação pode ser divido da seguinte maneira: 
1. Conexão da placa a uma porta USB do computador; 
2. Desenvolvimento de um sketch com comandos para a placa; 
3. Verificação de Erros na programação (realizado por sua IDE); 
 
4. Upload do sketch para a placa, utilizando a comunicação USB. 
5. Aguardar a reinicialização do Arduino, para posterior execução 
do sketch criado. 
2.2 Hardware 
Em seu hardware de fonte livre, há uma enorme gama de dispositivos (Figura 3), cada 
um com suas especificações para determinadas utilizações. Sua alimentação pode-se dar 
através da entrada USB, ou por fonte de alimentação externa, de acordo com o manual 
de cada placa. Há modelos pequenos, conhecidos como pro mini suas dimensões e suas 
utilizações estão voltadas para projetos compactos exigindo um maior cuidado em seu 
manuseio. Por outro lado, na família Arduino o maior modelo é denominado de mega, o 
qual é voltado para projetos que exijam interfaces com diversos sensores e conexões. 
Entre os modelos citados encontra-se outros modelos voltados para áreas especificas, 
tais como robótica, conexões Wi-Fi (NodeMCU) e dedicado a ligação de celulares 
Android (Mega ADK), ambos com processadores e barramentos adaptados para cada 
função. 
 
Figura 3. Modelos de Arduino. 
Fonte: www.filipeflop.com 
 Em especial no Arduino Uno R3 (Figura 4), sua placa além da Porta Usb e 
entrada de alimentação, também é disponibilizado entradas e/ou saídas digitais e 
analógicas, proporcionado, em níveis de energização de 0 ou 5 volts. No contexto 
digital promove uma corrente elétrica desligada (0v) ou ligada (5v). Já em seu âmbito 
analógico, sua corrente varia entre 0v até 5v, para estes fins a placa fornece 
alimentações de 3,3 volts, 5 volts e 0 volts (Terra). Para um bom custo/benefício a placa 
é dotada de um microcontrolador (pequeno computador, responsável por armazenar e 
executar o sketch em baixo nível) e de um chip ATmega de 8bits, assim como demais 
estruturas adjacentes para seu bom funcionamento. As entradas e saídas 
digitais/analógicas, são utilizadas para comunicações com outros hardwares estendidos 
para a sua placa, como veremos na sessão 2.3. 
 
 
Figura 4. Arduino Uno R3 principais componentes. 
Fonte: Do Autor. 
2.3 Componentes Complementares 
Os hardwares responsáveis por aumentar a funcionalidade do Arduino são denominados 
Shields, os quais são placas de circuito impresso com conectores que se encaixam 
facilmente nos circuitos da protoboard ou utilizam jumpers para realizar sua 
conexão/comunicação. Para a realização de experimentos e expansões no Arduino, se 
faz uso de placa de ensaio, conhecida como protoboard. Ela apresenta orifícios e 
conexões condutoras para montagem de circuitos elétricos experimentais, conforme a 
figura 5 letra A. Em seus orifícios, são conectados alguns modelos de placas impressas 
e/ou se faz o uso de um jumper (Figura 5 letra B), responsável por realizar a condução 
elétrica entre os circuitos, conforme a necessidade do projeto. 
 
Figura 5. Letra A - Protoboard 400 Pontos | Letra B - Jumper M x M. 
Fonte: Do Autor. 
 Também para a utilização de determinados circuitos se faz necessário o uso de 
resistores, os quais compõem os circuitos elétricos diversos. Os resistores possibilitam 
alterar a diferença de correntes elétricas em uma determinada parte de um circuito, 
através da conversão de energia elétrica em energia térmica. Cada resistor tem potências 
diferentes delimitados por suas cores (Figura 6 letra A), seguindo os princípios da Lei 
de Ohm e tabela pré-definidas. 
 
 
Figura 6. Letra A - Resistor | Letra B – Potenciômetro 3 Pinos. 
Fonte: http://twixar.me/9fTn | Do Autor 
 Para estipulados intuitos, se faz o uso de potenciômetros (Figura 6 letra B). São 
similares aos resistores, pois também são responsáveis por cria uma limitação para o 
fluxo de corrente elétrica que passa por ele. Sua diferença perante os resistores está na 
capacidade de ajustar de forma manualmente o fluxo de corrente elétrica, o tornando 
uma resistência elétrica ajustável através de seu eixo giratório. Os potenciômetros, são 
utilizados na comunicação elétrica de botões de rádio, sonorizações, controle de 
luminosidades, velocidades de transições, assim como também auxiliam no controle de 
displays LCD (alguns modelos de Shields). 
 Em algumas propostas são empregados o uso de Led RGB, o qual é um 
dispositivo capaz de emitir luz de forma econômica e eficiente, seu formato RGB (Red, 
Green e Blue), consiste em três leds encapsulados, das cores vermelha, verde e azul, em 
um único dispositivo. São capazes de gerar inúmeras cores distintas combinados 
diferentes níveis de cada cor primária (Figura 7). 
 
Figura 7. Led RGB. 
Fonte: http://twixar.me/vKTn 
Para uma comunicação visual são utilizados os displays LCDs, os quais podem 
ser conectados em uma placa de ensaio e ligados ao Arduino através dos jumpers. Seus 
mecanismos de LEDs gera uma interface de comunicação, onde sua finalidade é 
possibilitar uma interação visual entre homem e máquina, barata e simples de usar. Em 
particular, para os microcontroladores do Arduino, os displays LCD mais comuns são o 
16×2 (16 caracteres x 2 linhas) ou 20×4 (20 caracteres x 4 linhas), conforme figura 8. 
 
Figura 8. Display LCD 16X2 e 20x4. 
Fonte: Do Autor. 
Já para a interação do hardware visualmente, quanto necessário, usa-se módulos 
de câmeras (Figura 9 letra A), aplicados maioritariamente em projetos de robóticas 
(robôs), que através da codificação do projetista/programador auxilia nas tomadas de 
decisões do Arduino para os mais variados fins. Na forma de comunicação auditiva, em 
projetos que necessitam de avisos sonoros, utiliza-se o uso de buzzers (Figura 9 letra B), 
 
o qual é um pequeno alto-falante capaz de emitir sons em diversas frequências, através 
da utilização de um sinal elétrico. 
 
Figura 9.Letra A - Módulo câmera VGA OV7670 | Letra B - Buzzer. 
Fonte: http://twixar.me/vKTn | Do Autor. 
 Nos sensores existentes à um grande destaque nos modelos relacionados a 
verificação de temperatura em diversos ambiente, como podemos destacar o modelo 
LM-35 (Figura 10 Letra A). Seu funcionamento se dá através de um circuito integrado, 
preciso e barato, retornando a temperatura atual no formato de graus Celsius, operando 
entre temperaturas de -50ºC e 150ºC. 
 
Figura 10. Letra A - Módulo LM 35 | Letra B - Módulo MQ2. 
Fonte: Do Autor. 
Para projetos envolventes com gazes diversos e fumaças, há o uso de módulos 
específicos, tais como os sensores MQ-2 (gás inflamável e fumaça), MQ-3 (álcool e 
etanol), MQ-4 (gás metano) entre outros. No modelo MQ2 (Figura 10 Letra B), seu 
funcionamento se dá através de um nível máximo de concentração de gases/fumaça 
permitido, sendo este ajustado por um pequeno trimpot (potenciômetro miniaturizado) 
no módulo, quando algum gás ultrapassa esse nível, a saída digital do sensor é acionada 
em nível alto, caso contrário a mesma permanece em nível baixo. 
Para realizar a conexão dos dispositivos Arduino com a rede de internet, há a 
possibilidade de utilizar tanto a conexão por métodos de ethernet (Cabo), como também 
por meio de metodologias sem fio (Wi-Fi), conforme a figura 11. Ambos são munidos 
de protocolos padrões de interconexão de dispositivos, assim como mecanismos para 
conexão com o Arduino e suas bibliotecas. 
 
Figura 11. Módulo Ethernet ENC28J60 | Módulo Wi-Fi ESP8266. 
Fonte: Do Autor. 
 
2.4 Conclusão Parcial 
Com a criação do Arduino foi possível disponibilizar ao mercado algo inovador e de 
baixo custo, também foi observado a facilidade de sua implementação, tanto física 
(hardware), quando lógica (software). Além disso essa renovação do estado da arte 
possibilita a criação de inúmeros protótipos deforma a ser utilizado em diversos meios, 
oportunizando uma vasta expansão de dispositivos interconectados a uma rede de 
comunicação (internet das coisas - IoT). 
3. Internet das Coisas - internet of things (loT) 
Com a finalidade de facilitar compartilhamentos de recursos, tais como impressoras e 
troca de informações entre computadores, surgiu em meados de 1969 um projeto de 
comunicação de dados (ABBATE, 2000, p. 46) denominado ARPANET. Com o 
decorrer dos anos, já em meados da década de 70 e 80, seu projeto se expandiu de forma 
internacional e ficou conhecida como Internet, surgindo os primeiros domínios e 
alcançando a popularidade nos anos 90, com o surgimento de modelos de 
endereçamento World Wide Web (WWW). 
Para fins de realizar a trocas de dados e resolver a heterogeneidade, ao decorrer 
dos anos foi criado um modelo de comunicação denominado modelo TCP/IP. Este 
modelo trouxe quatro camadas distintas, em conjunto com elas foi criado novos 
protocolos tais como HTTP (Hypertext Transfer Protocol), TCP (Transmission Control 
Protocol), IP (Internet Protocol), MAC (Media Access Control), entre outros. 
 Com o crescimento da internet, em meados de 1999, surgiu o termo Internet of 
Things. Segundo Kevin (2009) o termo Internet das Coisas foi proposto como título de 
uma apresentação realizada na Procter & Gamble para descrever um sistema em que a 
internet estaria conectada ao mundo físico através de sensores onipresentes. 
A Internet das Coisas, através dos protocolos padrões de forma circunscrita, 
pode ser considera uma extensão da internet atual, pois através dela, é proporcionado 
aos objetos do cotidiano (sensores, geladeiras, carros, celulares) uma capacidade 
computacional viabilizada através da comunicação com a rede mundial de 
computadores. Sua metodologia oferta aplicações interativas ao meio, como informação 
em tempo real referentes aos objetos do mundo físico. 
Para Bartleson (2014) a Internet das Coisas promete ser uma das maiores 
revoluções tecnológicas que a humanidade já viu. Este fenômeno está em constante 
evolução e vem invadindo pouco a pouco a vida de todos. Também para Evans, D. 
(2011) a IoT pode ser considerada a próxima evolução da internet, evoluindo a coleta, 
análise e distribuição de dados, estes que podem se transformar em conhecimento e 
sabedoria. 
 A seguir na seção 3.1 será descrita sua arquitetura de referência, logo após na 
seção 3.2 seus protocolos referentes a arquitetura de aplicação, em seguida na seção 3.3 
serão abordados suas tecnologias de comunicação e seus paradigmas para objetos 
inteligentes (seção 3.4), por fim na seção 3.5 constitui-se de uma conclusão parcial. 
 
3.1 Arquitetura de Referência 
A fim de padronizar este novo conceito fez-se necessário uma normatização dada por 
uma arquitetura referencial, visando o futuro da real interoperabilidade dos dispositivos 
denominados IoT, tendo em vista o real crescimento deste segmento. 
Khan (2012) comenta que, as soluções que nasceram através do segmento de IoT 
apresentam uma falta de padronização o qual eleva a utopia do conceito criado tornando 
frequente a falta de heterogeneidade dos dispositivos, permitindo assim uma 
comunicação somente de uma mesma marca ou de um mesmo fabricante, o tornando 
detentor da sua tecnologia. Afins de resolver esta indisponibilidade ou ao menos 
melhorá-la, sugeriu-se diversos modelos de arquiteturas de referência, tornando a tarefa 
de padronização complexa. 
Segundo Al-Fuqaha (2015) há algumas camadas que formam um modelo básico 
desta arquitetura, conforme demostra a figura 12. De acordo com o autor, a primeira 
camada de percepção é a de objetos físicos, os quais utilizam sensores para coletar e 
processar informações. Já na segunda camada de rede é composta por abstrações das 
tecnologias de comunicação, serviços de gerenciamento, roteamento e de identificação. 
Por fim encontra-se a camada de aplicação, está incumbida de tornar os recursos 
disponíveis para serem usados. 
 
Figura 12. Arquitetura de Referência Básica de acordo Al-Fuqaha (2015). 
Fonte: Adaptação do autor Al-Fuqaha (2015). 
No entanto estas camadas são genéricas, não abrangendo toda a complexidade 
presente no cenário de loT e assim tornando a necessidade de criar arquiteturas mais 
específicas (Al-Fuqaha, 2015). Com esse cunho, há diversas organizações que 
trabalham no desenvolvimento e no processo de padronização tais como a ITU 
(International Telecommunication Union) e a ETSI (European Telecommunications 
Standards Institute). 
3.2 Protocolos de Aplicação 
Os protocolos são conjuntos de informações, normas, decisões e regras responsáveis por 
regular uma determinada ação, também é definido como “as regras que regem” a 
sintaxe, semântica e sincronização da comunicação. Os protocolos podem ser operados 
pelo hardware, software ou por uma combinação de ambos, de acordo com as camadas 
de implementações. 
Para Santos (2016) os protocolos padrões criados para a comunicação entre 
maquinas, se tornou pesado devido ao grande número de informações de suma 
necessidade utilizadas por tais. Levando em consideração a capacidade de 
processamento e memória dos dispositivos/sensores, fez-se uma nova adaptação de tais 
medidas de comunicações. 
 
 Os protocolos de aplicação são responsáveis por comunicar mensagem de uma 
aplicação específica. Devido a capacidade de processamento reduzida dos pequenos 
dispositivos, tornou-se praticamente impossível a utilização de protocolos já existentes, 
fazendo-se necessário uma implementação mais compacta afim de melhor 
aproveitamento dos dispositivos. Com esse viés a regulamentação é caracterizada em 
três categorias de protocolos relacionados a atividades de controle: 
• D2D (Device Data Device) é utilizado para interconectar dispositivos 
diretamente entre si. 
• D2S (Device Data Server) são destinados a coletar os dados e enviar a 
sistemas externos (servidores). 
• S2S (Server Data Server) é empregado para gerenciamento e integração das 
informações entre servidoresde aplicação. 
Em conjunto com as categorizações citados acima e em prol da melhor 
usabilidade dos dispositivos, pode-se destacar a criação de dois protocolos padrões de 
atuadores da camada de aplicação chamados de MQTT e CoAP. 
O protocolo MQTT (Messaging Queue Telemetry Transport) é um padrão de 
mensagens do tipo D2S encapsulado pelo protocolo TCP e projetado para dispositivos 
limitados. Sua estratégia de funcionamento (Figura 13) se dá inicialmente através de 
dispositivos que se registram (subscribe) a um broker (servidor) para obter informações 
sobre dados específicos. O broker é incumbido de avisar sempre que publicadores 
(publishers) publicarem os dados de interesse. Os dispositivos inteligentes (publishers) 
transmitem informações para os subscriber através do broker. As mensagens devem ser 
publicadas para um endereço, chamado de topic. Os clientes podem se inscrever em 
mais de um tópico, recebendo todas as mensagens enviadas para tais tópicos. O broker é 
responsável por gerir as publicações, sendo uma espécie de mediador entre os 
dispositivos, permitindo desacoplamento entre as partes. 
 
Figura 13. Esquematização protocolo MQTT. 
Fonte: forum.movimentomaker.pt 
De acordo com a figura 13 é possível verificar uma troca de dados entre dispositivos 
usando o protocolo MQTT. O sensor de temperatura publica (publish) a temperatura 
 
atual com o tópico (topic) de nome “temp” em um servidor (nroker), o qual, por sua 
vez, quando outras maquinas solicitam essa informação (subscriber) sobre o tópico 
“temp” envia as informações (publish) armazenadas da temperatura. 
 Já o protocolo CoAP (Constrained Application Protocol) utiliza padrões 
seguindo o protocolo D2D e encapsulado no protocolo UDP. Sua sistemática de 
funcionamento se dá através da troca de mensagens entre o cliente e o servidor, o qual é 
feito na base do pedido/resposta (request/response). Cada mensagem contém um 
identificador (token) usado para detectar duplicatas. Com relação a qualidade do serviço 
uma mensagem pode ser confirmável (COM) ou não (NON). Quando confirmável a 
mensagem deve ser respondida pelo remetente com um pacote ACK, enquanto que a 
mensagem não confirmável segue o estilo fire and forget (disparar e esquecer). A 
comunicação realizada se faz através de métodos semelhante ao usados no HTTP tais 
como GET (solicitar um recurso do destino), PUT (o recurso especificado é modificado 
com a informação enviada, se não existir é criado), POST (normalmente, resulta em um 
recurso sendo criado ou atualizado) e DELETE (apaga recurso selecionado). 
Seguindo a sistemática do protocolo CoAP, na figura 14, apresenta o esboço de 
seu funcionamento. O temperature sensor (sensor de temperatura) encaminha uma 
mensagem não confirmável (NON) com a identificação (token) “0x21” ao servidor, 
solicitando que grave (PUT) a temperatura obtida naquele momento. Já o computer 
(computador) e o mobile devide (dispositivo móvel) solicitam (GET) a informação da 
temperatura salva no servidor pelas identificações (token) “0x15” e “0x95” respectivos, 
com a diferença do computer, o qual solicita uma confirmação de recebimento da 
mensagem (CON), e o servidor, posteriormente, retorna com a mensagem de 
confirmação (ACK) em conjunto com a informação solicitada (Content). O dispositivo 
moisture sensor (sensor de umidade) solicita (GET) através de uma mensagem não 
confirmável (NON), uma verificação de movimento ao sensor motion sensor (sensor de 
movimento), o qual retorna com uma mensagem não confirmável (NON), com a 
informação de no moviment (sem movimento), após o retorno o sensor de umidade 
encaminha duas mensagens ao servidor, ambas solicitando que grave informações 
(PUT), a primeira solicitação é uma mensagem a qual não necessita confirmação 
(NON),já a segunda se faz necessário que o servidor confirme o recebimento (CON), 
após receber a segunda mensagem, o servidor retornar a mesma com um ACK, 
confirmando a mensagem recebida juntamente com a informação enviada. 
 
 
Figura 14. Esquematização protocolo CoAp. 
Fonte: Do Autor. 
Segundo Thangavel (2014) ambos os protocolos são amplamente utilizados, 
contudo há diferenças fundamentais entre eles. O protocolo MQTT as mensagens são 
distribuídas entre vários clientes cabendo ao servidor rotear as mensagens para os 
clientes certos, sua sistemática não possibilita o suporte a metadados. Por outro lado, o 
protocolo CoAP realiza a transferência entre cliente e servidor diretamente 
possibilitando suporte para identificação do conteúdo, além da possibilidade da 
comunicam direta entre os próprios dispositivos. 
3.2 Tecnologias de Comunicação 
Há fins de realizar a comunicação física entre dispositivos e/ou servidores, nesta seção 
será abordado as principais tecnologias com suas características mais fundamentais para 
IoT. 
O padrão Ethernet (IEEE 802.3) foi oficializado em 1983 pelo IEEE, sua 
sistemática de funcionamento é baseada no envio de pacotes de dados através de sinais 
elétricos, popularmente conhecido e amplamente utilizado em redes de área local (LAN 
- Local Area Network). O uso do padrão Ethernet é sugerido para dispositivos fixos, 
sem mobilidade, o que pode ser inadequado para a aplicabilidade em dispositivos do 
âmbito de IoT. 
 A tecnologia Wi-Fi (IEEE 802.11) surgiu em meados de 1997, sua comunicação 
se dá através de redes sem fio, a qual emitem ondas eletromagnéticas em frequências 
específicas, encontrando-se presente nos mais variados ambientes através de redes 
locais sem fio (WLAN- Wireless Local Area Network). Desde o seu lançamento já 
foram propostas novas versões do padrão IEEE 802.11 e, atualmente, a versão IEEE 
802.11ac prevê taxas de comunicação de 600 Mbps ou 1300 Mbps. A utilização deste 
padrão para pequenos dispositivos é pouco utilizada no âmbito da internet das coisas, 
devido ao consumo de energia/processamento elevado. 
 O paradigma do ZigBee foi baseado no IEEE 802.15.4 para a camada de enlace 
através de rádio frequência e a capacidades de dispositivos entrarem em modo sleep 
 
(repouso). Com esse intuito, foi possível disponibilizar uma rede com baixa potência de 
operação, ocasionando um baixo consumo de energia, assim como uma maior 
durabilidade. O ZigBee opera na frequência 2.4 GHz (faixa ISM), mas é capaz de 
operar em outras duas frequências, 868 MHz e 915 MHz. Este padrão já é adotado em 
aplicações residenciais e comerciais, sua utilização em IoT depende apenas de um 
gateway (dispositivo de rede equipado para comunicação com outra rede que usa 
protocolos diferentes). 
O Bluetooth Low Energy (BLE) é um protocolo padrão de comunicação 
primariamente projetado para baixo consumo de energia com baixo alcance, de 1 metro 
até 100 metros (dependendo da potência), sua comunicação se dá por intermédio do 
sistema via rádio. Sua taxa de transmissão varia de 1Mbit/s até 50Mbit/s (dependendo 
da versão utilizada). Para fins de utilização em pequenos dispositivos, foi proposta uma 
camada de adaptação para o BLE, similar ao padrão 6LoWPAN, chamada de 
6LoBTLE. 
Os parâmetros de telefonia celular 3G/4G também podem ser aplicados à IoT, 
projetos que necessitam transcorrer grandes distancias podem aproveitar as redes 
telefônicas, embora ocorra um alto consumo de energia, quando comparado a 
tecnologias adjacentes. Em locais sem disponibilidade de outras métricas de rede, pode-
se fazer interessante a utilização deste meio. A taxa de comunicação alcançado no 
padrão 3G é de até 2 Megabit/s e no padrão 4G entre 100 Megabit/s em movimento e 
1 Gigabit/s em repouso. 
O mecanismo Sigfox foi projetada em 2009, considerada uma operadora de rede 
global afins de trabalhar com pequenas taxas de transferência de dados e com a 
finalidade de conectar objetos de baixa energia, denominado LPWAN (Low-Power 
Wide-Area Network). Seu funcionamento se dá com o auxílio de uma banda de rádio 
ISM com um raiode cobertura oficialmente relatada entre 3 km e 10 km em zonas 
urbanas e em zonas rurais entre 30 km a 50 km. Sua cobertura atual é de 5 milhões de 
quilômetros quadrados e em 60 países, além disso a taxa de dados é de até 100 byte/s. 
A especificação LoRaWan (Long Range Wide Area Network) foi desenvolvido 
para criar redes de longa distância LPWAN (Low-Power Wide-Area Network) com 
intermédio do sistema radio ISM de comunicação. Sua distinção está no tratamento de 
requisitos presentes na IoT como comunicação segura e bidirecional, mobilidade e 
tratamento de serviços de localização, além disso seu padrão oferta suporte ao protocolo 
IPV6 através de uma adaptação da regulamentação do 6LoWPAN. A distância 
suportada varia de 2 quilômetros a 45 quilômetros, já sua taxa de transferência varia de 
300 byte/s a 50 Kbyte/s. 
Com a finalidade de prover serviços a mais variada gama de dispositivos e 
territórios, cada padrão demostrado acima possibilita uma melhor adequação de um 
projeto/sistema, cabendo ao seu desenvolver optar pelo mecanismo que melhor supra as 
necessidades de seu equipamento. 
 
3.3 Paradigmas de comunicação para objetos inteligentes 
No que regue os paradigmas de comunicação há uma interseção entre rede de sensores 
sem fio (RSSF) e a Internet das Coisas. O arquétipo gerado para objetos inteligentes 
 
pode ser dividido de acordo com a comunicação a qual sofrerá impacto diretamente em 
recursos de hardware, energia e na viabilização de aplicações sobre a rede. De acordo 
com Santos (2016), os paradigmas podem ser representados por quatro categorias, 
conforme demostra a figura 16. 
 
Figura 16. Paradigmas de Iot. 
Fonte: Livro Internet das Coisa da Teoria à Prática. 
O modelo Muitos-para-Um (Many-to-One), também conhecido como coleta de 
dados, é um dos modelos mais comumente utilizados em que vários 
sensores/dispositivos se conectam a muitos outros tipos de produtos e geralmente a 
fontes externas de dados. É conhecido pelo fato de ser direcionado a coleta de 
informações através de uma árvore de roteamento onde encontra-se uma raiz nas 
estações base. Sua caracterização se dá pelo fato de não possibilitar confirmação de 
entrega de dados, assim como é responsável por não gerar grandes consumo de memória 
e energia. Um dos protocolos que utiliza destas métricas é o Collection Tree Protocol 
(CTP), o qual faz parte do sistema aberto TinyOS. 
Já o modelo Um-para-Muitos (One-to-Many) é distinguido pela possibilidade de 
disseminação de dados, nesta métrica as raízes das estações base enviam comandos para 
um ou diversos objetos da estação. Comumente utilizado para reconfigurar/modificar 
parâmetros dos dispositivos na rede, porém igualitário ao modelo citado anteriormente, 
pois não tem capacidade de confirmar de mensagens, contudo se difere em caso de uma 
grande demanda de mensagens (inundações de rede), a qual poderá acarretar em um 
maior custo de processamento e energização do mecanismo. O protocolo Deluge é um 
exemplo da utilização desta idealização. 
Há uma mescla de ambos procedimentos citados acima chamado de Um-para-
Muitos e Vice-Versa (One-to-Many and Many-to-One). Nesta abordagem os objetos 
inteligentes podem se comunicar com as raízes das estações e vice-versa, o qual 
possibilita a utilização de métricas confiáveis entre a troca de mensagens, entretanto se 
faz necessário uma memória e processamento adicional. Um exemplo desta categoria é 
o Extend Collection Tree Protocol (XCTP). 
Por fim o paradigma Um-para-Um (Any-to-Any), o qual possibilita que dois 
dispositivos se comuniquem de forma direta exigindo maiores recursos de 
armazenamento de rotas, o tornando não aconselhável para dispositivos bastantes 
limitados. Em contrapartida não apresentam restrições significativas para as aplicações. 
3.4 Conclusão Parcial 
De acordo com a empresa CISCO e Intel, a Internet das Coisas é um mercado promissor 
em pleno crescimento. A empresa McKinsey & Company estima um aumento do 
 
impacto econômico global de US$ 3,9 trilhões de dólares ao ano para US$ 11,1 trilhões 
de dólares ao ano até 2025. De acordo com a consultoria Business Insider Intelligence o 
número de dispositivos conectados à internet irá saltar de cerca de 10 bilhões em 2015 
para 34 bilhões até 2020, quando a população no planeta será de 7,6 bilhões, o que 
demostra um futuro promissor da tecnologia direcionada a interconexão de todos e 
quaisquer dispositivos aos meios da internet, afins de prover trocas de informações, 
tendo por finalidade facilitar e demostrar maior comodidade e segurança em todos os 
meios. Com uma grande demanda no mercado e um aumento na utilização de 
dispositivos interligados a rede de internet, foi criado diversos modelos de sistemas 
residências e prediais visando não somente uma comodidade, mas também uma melhor 
aplicabilidade de sua métricas em prol de uma adequada segurança em seus mais 
variados aspectos. 
4. Trabalhos Relacionados 
Esta seção será abordada os trabalhos relacionados, os quais tratam da 
automação/monitoramento residencial, logo em seguida na subseção encontra-se uma 
conclusão parcial. De acordo com Terra (2017), sistemas de automação e 
monitoramento residencial têm sido pesquisados e desenvolvidos em diversas partes do 
mundo. As pesquisas têm se concentrado no aperfeiçoamento de soluções para 
comunicação entre sensores, centrais, servidores e dispositivos móveis, como em [Lian 
2011], por exemplo, onde é apresentado um sistema de monitoramento com circuito 
impresso composto por multi-sensor. O qual consiste na utilização de um sensor de 
fumaça e outro de temperatura. Sua arquitetura faz uso de um limite preestabelecido de 
fumaça e temperatura baseado em um algoritmo de compensação, a notificação ao 
usuário é realizada via SMS. É uma solução interessante, porém não é considerado o 
uso do Arduino e da internet para propagar as informações, também não é emitido 
alertar visuais no dispositivo. 
 Em Al-Ameen 2013 os autores desenvolveram um sistema de divulgação rápida 
de emergência de incêndio via envio de mensagens de celular (SMS) para um 
determinado grupo de destinatários, sua arquitetura necessita de um computador para 
rodar o programa que gerencia a comunicação entre o microcontrolador e o celular 
responsável por enviar as mensagens de texto (SMS). A proposta não aborda o uso da 
internet para propagar as informações, também necessita de um computador para fazer o 
gerenciamento da comunicação, o que acaba consumindo uma maior energização 
elétrica e dificultando suas instalações em larga escala. Por outro lado Carvalho (2015) 
propôs um sistema de monitoramento implementado por Raspberry, utilizando a rede 
móvel GSM em conjunto com um sistema via rádio de comunicação. O mecanismo de 
detecção foi dividido em sistemas sensorial e central. No sistema sensorial foi munido 
de múltiplos sensores tais como sensor de temperatura, sensor de fumaça e sensor de 
gás e módulo RF. Na central foi utilizado um módulo GSM e algoritmos de 
compensação. Sua arquitetura de funcionamento foi realizada através do envio dos 
dados coletados pelo sistema sensorial para a central, a qual emite notificações ao 
usuário via SMS. Novamente, no entanto, não é considerado o uso da internet para 
propagar as informações e do uso do Arduino para a elaboração do hardware, além da 
proposta não trazer alertas visuais de funcionamento do dispositivo, também o sistema é 
subdividido entre uma central e nós sensoriais, o que torna o sistema vulnerável em caso 
de falhas na central. 
 
 Já Abaya (2016) propôs um sistema de monitoramento residencial construído em 
Arduino, com o uso dos módulos GSM, sensor de chamas e Led RGB. O 
funcionamento é baseado em duas centrais, estas localizadas uma na 
residência/edificação e outra em uma estação contra incêndio. Na detecção da chama 
ocorre o envio do alerta via SMS para o módulo GSM localizado na estação.Quando 
recebido o alerta, emite um sinal visual na localidade da planta baixa da residência 
instalado na estação. Este trabalho torna-se interessante, entretanto em locais como 
edificações, a criação de uma planta baixa especificada de cada cômodo torna-se 
inviável, além da vulnerabilidade ocasionada pela existência de possíveis falhas na 
central, também não é cogitado a possibilidade da utilização da internet para envio e 
recebimento dos alertas. 
 Muheden (2016) apresentou um trabalho de um sistema implementado com 
Arduino para monitorar remotamente em conjunto com os sensores de temperatura, 
umidade, gás e fogo. A sistemática deu-se por um único sistema controlador, o qual é 
responsável por coletar os dados e realizar comunica via rede sem fio (Wireless) com 
um aplicativo (App) de celular/tablet. As notificações ao usuário são realizadas através 
da busca do aplicativo do dispositivo móvel, ao sistema controlador. A solução, no 
entanto, não armazena as informações coletadas, assim como não há alertas visuais de 
funcionamento do dispositivo. 
 Adicionalmente, cabe ressaltar que os trabalhos mencionados não apresentam 
armazenamento de dados coletados, tampouco o armazenamento em nuvem. Assim 
como há trabalhos que fazem o uso de sistemáticas de central e escravo (slive), os quais 
são passiveis de vulnerabilidades e acometidos em um consumo elétrico mais elevados e 
encarecimento de sua elaboração. Também os trabalhos de [Lian 2011], [Al-Ameen 
2013], [Carvalho 2015] e [Muheden 2016] demostram uma menor acessibilidade devido 
à falta de alertas visuais de funcionamentos de seus dispositivos. 
4.1 Conclusão Parcial 
Há um grande aumento nas iniciativas para melhorar os dispositivos que venham a 
facilitar a aplicabilidade e usabilidade das tecnologias atuais em prol da detecção de 
incêndios. Cabe ressaltar a sua importância no acompanhamento do estado da arte, 
assim como sua implementação através do desenvolvimento de novos circuitos. 
Também se deve ao respaldo do avanço dos objetos inteligentes conectados pela rede 
mundial de computadores através de serviços oferecidos por servidores, aparatos 
móveis e iniciativas de interconexão de dispositivos. 
5. Proposta de detecção de incêndio para IoT utilizando a plataforma 
Arduino 
De acordo com Glitho (2016) uma proposta é uma definição estratégica de 
desenvolvimento de algo de competência nova ou melhorada, objetivando uma real 
validação no âmbito pretendido, com o viés de alcançar determinadas métricas nos 
meios de aplicabilidades invólucros dos métodos e técnicas executadas. 
 Segundo o DATASUS (Departamento de Informática do Sistema Único de 
Saúde) no ano de 2017 ocorreu em torno de mil mortes registrada por incêndios no 
Brasil. Seu prejuízo estimado tanto monetário quanto físico chega a ultrapassar dez 
bilhões de reais anuais, gastos estes, tanto pessoais quanto governamentais. De acordo 
 
com a lei número 13.425 de março de 2017, a utilização de mecanismos de prevenção a 
incêndio residências e prediais é determinado pelos municípios, os quais tornam 
facultativo a utilização de sistemas de incêndio em residência e prédios, exceto em 
casos de locais de grande concentração e circulação de pessoas (edificações 
empresariais). 
 Conforme Mueller (2013), uma das formas mais eficientes de proteção contra 
incêndios é a sua rápida detecção assim como a localização do(as) principal(ais) foco(s) 
do incêndio, possibilitando que seja combatido de forma eficiente e com agilidade. 
 As limitações de muitos sensores residenciais/prediais atuais se caracterizam 
pela utilização unicamente de metodologias de atuadores sonoros unicamente no 
ambiente em que se encontram com pouquíssimas ou nenhuma forma de interação com 
as pessoas. O atual estágio de desenvolvimento tecnológico e a sua respectiva 
popularização de comunicação com telefonias móveis e a própria rede de Internet, 
tornou possível a utilização desses novos recursos nos projetos atuais. 
 Com o viés de acompanhar o estado da arte e auxiliar na localização de focos de 
incêndio residências/prediais, foi criada a proposta de um novo dispositivo baseado na 
plataforma Arduino em conjunto com suas shields, conectados na rede de internet 
através de práticas de interconexão de dispositivos com o uso da ferramenta de 
comunicação em nuvem chamada ThingSpeak. 
 A seguir na seção 5.1 será demostra o uso da plataforma em nuvem ThingSpeak, 
logo em seguida na seção 5.2 é especificado o funcionamento do protótipo criado, 
dividido entre a modelagem do hardware (seção 5.2.1) e a construção do código fonte 
(5.2.2), após na seção 5.3 encontra-se a montagem final do protótipo. Na seção 5.4 foi 
demostrado o envio e o formato da disponibilidade dos dados para diversas aplicações, 
já na seção 5.5 é realizado um comparativo de valores e custo de energização entre o 
protótipo e um modelo encontrado no mercado. A seção 5.6 é composta por trabalhos 
futuros a serem desenvolvidos, por fim na seção 5.7 constitui-se de uma conclusão 
parcial. 
5.1 IoT com o uso da plataforma em nuvem ThingSpeak 
Segundo Sabanci (2018), o ThingSpeak é uma plataforma/ferramenta em nuvem de 
código open-source com aplicações voltada para a internet das coisas (IoT), a qual 
disponibiliza APIs que permite coletar, armazenar, analisar, visualizar e atuar em dados 
de sensores ou atuadores conectados à internet em tempo real. De acordo com Mhatre 
(2017) a plataforma funciona como um concentrador de dados e serviços. Segundo o 
esboço na figura 17, as informações de todos os dispositivos são armazenadas e 
organizadas em nuvem na plataforma ThingSpeak, o qual possibilita análise com 
ferramentas tais como a MATLAB, também a criação de aplicações de diversos fins 
com a conexão ao API suportado. 
 
 
Figura 17. Esboço de funcionamento Thingspeak. 
Fonte: www.embarcados.com.br 
 Os dados digitais dos sensores podem ser enviados para o Thingspeak através de 
um microcontrolador ou qualquer outro hardware que possua uma interface de 
comunicação que suporte os protocolos TCP/IP, HTTP ou MQTT. O envio dos dados 
ocorre através da comunicação com as APIs REST ou MQTT. 
• Uso da API REST no Thingspeak é realizado através de chamada de GET, 
POST, PUT e DELETE para criar e excluir canais, ler e gravar dados de canais e 
limpar os dados em um canal. 
• A utilização do protocolo MQTT no Thingspeak é mais restrito permitindo que 
clientes atualizem e recebam atualizações dos feeds de canais por meio do 
broker disponibilizado pela ferramenta. 
 Sua comunicação é feita através de textos simples, JSON ou XML, já as 
informações são armazenadas nos denominados canais, os quais fornecem aos usuários 
diversos recursos. De acordo com a figura 18, o canal disponibiliza na versão gratuita 
armazena até 8 (oito) campos de dados além dos campos para nome do canal, descrição, 
metadados (informações do canal) incluindo dados JSON, XML ou CSV, tags para 
identificação do canal, links para sites externo, localização do canal (latitude, longitude) 
e elevação do canal entre outros dados. 
https://www.embarcados.com.br/wp-content/uploads/2015/02/ThingSpeak-1.jpg
 
 
Figura 18. Dados disponíveis por canal gratuito da plataforma thingspeak. 
Fonte: thingspeak.com 
No momento em que os dados de cada canal são recebidos pela ferramenta, as 
informações são vinculadas a um número único de identificação em conjunto com as 
respectiva data e hora atual do recebimento dos dados. A publicação das informações na 
plataforma ocorre através da utilização de uma Write Key (chave de gravação) a qual é 
disponibilizada de forma análoga após a criação do canal. Já para a leitura dos dados 
gravados é necessário a utilização do ID do canal gerado em conjunto com uma chave 
de leitura (Read Key). 
 O ThingSpeak oferece uma série de aplicações para serem usadas com os dados 
obtidos além de possibilitar através da API o resgate dosdados para utilização em 
qualquer sistema. A plataforma tem recursos que permitem processar os dados e exibir 
na forma de lista, indicadores visuais (Figura 19 letra A) ou gráficos (Figura 19 letra B), 
os quais podem ser personalizados usando modelos pré-definidos ou também a 
interação com o software MATLAB (programa para análise de dados, desenvolvimento 
de algoritmos e criação de modelos matemáticos). A figura 19 letra A mostra um 
indicador gráfico Gauge (calibre), que exibe em tempo real o último parâmetro de 
temperatura. Já na figura 19 letra B exibe um gráfico pré-definido de todos os dados 
coletados em conjunto com os dados coletados em tempo real no formato de 
temperatura em função do tempo de medição. 
 
Figura 19. Letra A - Gauge | Letra B - Gráfico Temperatura X Tempo. 
Fonte: ThingSpeak. 
 
 De acordo com Maureira (2016) devido a API ser de código fonte aberto torna 
possível a sua integração com qualquer dispositivo de hardware tais como Arduino, 
ESP8266, Raspberry Pi, entre outros microcontroladores. Outro aspecto importante é 
sua interface acessível, a qual facilita o uso para usuários inexperientes, através de sua 
organização em forma de canal tornando a API mais intuitiva, também possibilita tornar 
canais privados em canais públicos (pode ser publicado em sites, fóruns, blogs, 
comunidades), de modo a servir como fonte de inspiração entre diferentes 
desenvolvedores de projetos IoT, possibilitando o compartilhamento de projetos e 
experiências na utilização da plataforma. 
 Entretanto Maureira (2016) também afirma que há alguns modelos pré-definidos 
para a visualização de dados através do ThingSpeak, mas caso necessite obter 
gráficos/indicadores visuais mais complexos ou de formas diferentes a plataforma não 
disponibiliza, necessitando programar no espaço oferecido pela plataforma, o qual se 
faz necessário um conhecimento de programação avançada. Também Sabanci (2018) 
destaca os limites de trafego de dados impostas para cada tipo de usuário, podendo ser 
usuários comerciais, acadêmicos ou gratuito. Para os usuários gratuitos o upload (envio 
de informações) dos dados está limitado a cada 15 segundos com o tempo de 
processamento das informações de 20 segundos, há também a limitação diária de envios 
em 8.200 vezes, limitações estas implicadas na versão disponibilizada de forma gratuita. 
 Para o projeto proposto, essas limitações não são necessariamente um problema, 
tendo em vista que as características do projeto não necessitam de um grande volume de 
informações a curtos intervalos de envio. 
5.2 Especificação de Funcionamento 
A funcionalidade do protótipo consiste em aferir os dados dos sensores de temperatura e 
gás fumaça, encaminha-los para um servidor em nuvem, também alertar os usuários de 
forma visual em casos de defeitos no sensor e em caso de detecção de fumaça e gás no 
ambiente. A elaboração da sistemática de funcionamento foi realizada em duas etapas, 
inicialmente realizou-se um levantamento dos periféricos que melhor atendam aos 
requisitos básicos do projeto, também ocorreu a organização e união dos hardwares 
selecionados. Na segunda etapa, foi realizada a sistemática de funcionamento por meio 
da programação de um código fonte, seguindo os princípios da modelagem criada e 
visando uma melhor harmonia dos periféricos de forma a respeitar o paradigma da 
internet das coisas e possibilitar o envio dos dados coletados a plataforma ThingSpeak. 
5.2.1 Modelagem do Hardware 
Para tais funcionalidades descrita acima, foi utilizada o hardware da plataforma 
Arduino em conjunto com os sensores/componentes, conforme a tabela 1. 
 
 
 
 
 
Quantidade Nome do Dispositivo 
 
1 Resistor 100K 
3 Resistor 330R 
1 Jumper Macho-Macho 
1 Detector de Gás / Fumaça MQ-2 
1 Sensor de Temperatura LM35 
1 Led RGB 
1 Arduino Uno R3 
1 Módulo Wi-Fi ESP8266 ESP-01 
1 Adaptador para Módulo WiFi ESP8266 
ESP-01 
1 Fonte de Alimentação para Arduino 
Tabela 1 Periféricos Utilizados. 
Fonte: Do autor. 
 Para o projeto com o Arduino Uno R3 foi concluído que os componentes 
descritos na tabela 1 são mais apropriados, pois além de fornecer um melhor 
custo/benefício suas substituições são mais acessíveis. 
 Com a finalidade da interligação de maneira adequada dos sensores, 
primeiramente foi realizado uma esquematização de ligação com o auxílio do software 
fritzing. O fritzing é uma ferramenta de código fonte aberto e gratuita, a qual possibilita 
a automação de design eletrônico, além de fornecer simulações com montagem de 
circuitos elétricos e suporta a programação dos periféricos. Para o projeto a ligação 
entre os componentes segue a união lógica dos circuitos de entrada/saída, respeitando as 
esquematizações de cada Datasheet (folhas de especificação). 
 Conforme a figura 20 e figura 21, respectivamente, é possível verificar a 
esquematização da união de todos os circuitos usados e o esboço do projeto. Na 
confecção da esquematização e do esboço foi utilizado fios de diferentes padrões de 
cores. Os fios pretos represam polo negativo, já os vermelhos são os polos positivos 
(Exceto para o Led RGB), os fios amarelos representam a ligação dos periféricos a 
placa Arduino através do canal digital, já na esquematização, os fios de cor verdes 
realizam a ligação dos canais analógicos (no esboço e projeto final os fios brancos). 
Para a ligação ao Led RGB foi utilizado os fios de acordo com o padrão de cores RGB 
(Red, Green e Blue) com o formato das cores vermelho, verde e azul. Devido a diferente 
voltagem de funcionamento do led RGB foi utilizado três resistores de 330R, também 
para o módulo LM35 empregou-se um resistor de 100K com o viés de diminuir a 
porcentagem de erros das leituras. As figuras 20 e 21 são caracterizadas pelo uso de 
módulos e sensores enumerados conforme os itens a seguir: 
 
 
(1) - Arduino Uno R3. 
(2) - Módulo ESP8266. 
 
(3) - Módulo MQ2. 
(4) - Sensor LM35. 
(5) - Led RGB. 
(6) – Protoboard (presente apenas na figura 21). 
 
Figura 20. Esquemática de ligação com o uso da ferramenta fritzing. 
Fonte: Do Autor. 
 
Figura 21. Esboço do projeto com o uso da ferramenta fritzing. 
Fonte: Do Autor. 
 Após a confecção e a verificação da sistematização de funcionamento foi 
confeccionado a montagem do projeto. Para apoio da montagem foi utilizado uma placa 
 
protoboard em conjunto com uma base em acrílico, visando facilitar o manuseio do 
experimento. 
 Durante a montagem verificou-se que o módulo Wi-Fi ESP8266 precisa de uma 
energização de 3.3 volts, a qual deve ser uma corrente continua, sem variações, 
limitadas a uma sobre tensão com consequências de queima do módulo ou mau 
funcionamento. Com a necessidade de evitar a queima do módulo como também 
proporcionar uma manutenção mais descomplicada e uma melhor conexão a 
protoboard, foi realizado a construção do projeto com um adaptador para o módulo, o 
qual é energizado por uma corrente de 5 volts e com regulador de tensão de 3.3 volts. 
Conforme figura 22 é possível visualizar o adaptador, que fornece oito entradas (RX, 
TX, GPIO0, GPIO2, VCC, GND, RST, CH_PD) para o módulo ESP8266 e quatro 
entradas para utilização do adaptador (VCC, TX, RX, GND). 
 
Figura 22. Adaptador para Módulo Wi-Fi ESP8266. 
Fonte: Do Autor. 
5.2.2 Construção do Código Fonte 
De acordo com Mhatre (2017) o código fonte é um conjunto de palavras ou símbolos 
escritos de forma ordenada, contendo instruções em uma linguagem de 
programação existentes, visando uma funcionalidade, seja ela para software como para 
hardware ou ambos. 
 Para a construção do código fonte se torna necessário inicialmente compreender 
a sistemática de funcionamento do projeto proposto. A organização foi dividida e 
baseada no dispositivo Arduino e no módulo ESP8266, ambos exercem uma 
comunicação serial de forma a manter sincronizados os dados em nuvem, como também 
realizam troca de informações defuncionamentos incorretos ou incoerentes. 
 O Arduino tem por finalidade coletar os dados dos sensores, enviar alertas 
visuais, como também encaminhar os dados ao módulo ESP8266, o qual por sua vez é 
encarregado de enviar os dados a plataforma em nuvem, através das métricas do 
protocolo MQTT. A leitura dos sensores ocorre através de ciclos limitados por tempos 
de leituras. O Arduino realiza a leitura a cada cinco segundos, já o envio para o módulo 
ESP8266 acontece a cada vinte segundos (ambos podem ser modificados 
posteriormente no código fonte), o qual por sua vez encaminha os dados a plataforma 
em nuvem ThingSpeak. 
 Em caso de mau funcionamento de um dos sensores é emitido um alerta visual 
pelo Led RGB como também o erro é reportado para a plataforma ThingSpeak, com 
exceção de funcionamento incorreto do módulo ESP8266, o qual apenas emite alerta 
visual, quando defeito na conexão da rede Wi-Fi. A tabela 2, especifica os alertas 
visuais emitidos, assim como o respectivo código de erro, quando detectados, em 
conjunto com o respectivo sensor. O código de erro é gravado no ThingSpeak, no 
campo do sensor/módulo a qual foi identificada no respectivo erro. 
 
Código Sensor/Módulo Significado Alerta Reporta 
Erro a 
Nuvem 
----- ----- Funcionamento correto do 
dispositivo 
Led RGB de cor 
verde liga por um 
segundo 
Não 
350 
LM35 
Erro polo negativo sem 
energização 
Led RGB de cor 
amarela pisca por 
duas vezes durante 
o ciclo 
 
Sim 
353 Erro temperatura inválida 
0 
 
 
MQ2 
 
Sem detecção de 
Gás/Fumaça 
----- 
 
 
 
 
Sim 
 
1 Detecção de Gás/Fumaça Led RGB de cor 
vermelha pisca de 
forma intermitente 
até o próximo ciclo 
200 Erro polo negativo sem 
energização 
 
 
Led RGB de cor 
amarela pisca por 
quatro vezes 
durante o ciclo 
201 Erro polo positivo sem 
energização 
202 Erro entrada digital 
desconectada 
203 Erro entrada analógica 
desconectada 
204 Erro de leitura do sensor 
analógicos e digital. 
801 
 
ESP8266 
Erro conexão Wi-Fi Led RGB de cor 
azul pisca duas 
vezes 
 
 
Não 
802 Erro do protocolo MQTT Led RGB de cor 
azul pisca quatro 
vezes 
Tabela 2 Especifico de alertas. 
Fonte: Do autor. 
 O código fonte foi desenvolvido com o auxílio do ambiente de desenvolvimento 
integrado do Arduino, denominado de Arduino IDE. A programação criada é baseada na 
linguagem de programação C e C++, o código fonte foi delimitado de acordo com os 
dados acima e seguindo o fluxograma do dispositivo Arduino e do módulo ESP8266, 
encontrados na figura 23 e figura 24 respectivamente. 
 
 
Figura 23. Fluxograma do Arduino. 
Fonte: Do Autor. 
 
Figura 24. Fluxograma do Módulo ESP8266. 
Fonte: Do Autor. 
 
 
 
 Para a programação dos sensores, atuadores, broker e plataforma na nuvem, na 
placa de desenvolvimento do Arduino e no módulo ESP8266 foram utilizadas as 
bibliotecas a seguir: 
• ArduinoUniqueID.h - Permite coletar o número de série único do dispositivo, 
que se encontra no chip de processamento; 
• SofwareSerial.h - Possibilita criar uma conexão de comunicação serial com uma 
porta não nativa do Arduino, em conjunto com dois pinos de entrada/saída 
(input/ output) denominados no projeto de R7 e T6 (rx e tx respectivamente); 
• WiFi.h - Disponibiliza uma forma mais simples de conectar o dispositivo a rede 
de internet, sendo necessário apenas o uso do SSID (nome da rede) e senha da 
rede. 
• PubSubClient.h – Utilizado para escrita e leitura de comandos do broker, através 
das métricas do protocolo MQTT. 
 O sensor de temperatura (LM35) e o led RGB não necessitam de bibliotecas, 
utilizam as programações comuns e disponíveis para a placa, onde foram programados 
com o direcionamento dos pinos, input no sensor de temperatura e output para o LED. 
5.3 Montagem Final 
De acordo com a figura 25, encontra-se a montagem do protótipo final, a qual foi 
utilizado uma base de acrílico para sustentação do Arduino Uno R3 em conjunto com a 
protoboard e os módulo/sensores utilizados. Também foi usado jumpers do tipo macho-
macho para realizar a conexão do Arduino na protoboard e nos sensores. O protótipo 
montado demostrou-se compacto e multifuncional, sua conexão Wi-Fi não altera as 
instalações do ambiente. Para ser colocado em funcionamento necessita apenas de uma 
tomada e fonte chaveada com saída (output) de 9 volts (DC) de 1 amper (1000mA). 
 
Figura 25. Montagem Final do Protótipo. 
Fonte: Do Autor. 
 
 
5.4 Envio e disponibilidade dos dados na plataforma ThingSpeak 
Para validação do projeto proposto, o protótipo foi submetido a testes de envio dos 
dados coletados para a plataforma ThingSpeak por meio da conexão do módulo Wi-Fi 
ESP8266 a rede de internet. A comprovação do reconhecimento e do encaminhamento 
de gás/fumaça pelo módulo MQ2 para a plataforma em nuvem, se deu pelos testes 
realizados com um isqueiro. Também com cunhos de comprovação do encaminhamento 
de erros oriundos de mau funcionamento do protótipo, foi induzido falha no polo 
negativo do módulo MQ2 e do sensor LM35 através da remoção dos jumpers da 
protobord onde encontram-se conectados. 
 Os dados dos sensores do projeto foram enviados pelo modulo ESP8266 a cada 
vinte segundos, durante uma hora de funcionamento. As informações foram convertidas 
em gráficos disponibilizados pela plataforma ThingSpeak, conforme as figuras 26, 27 e 
28, nas quais, cada uma apresentam-se três gráficos enumerados de acordo com a 
função estabelecida. O primeiro gráfico (1), encontra-se o código único do Arduino, já o 
segundo (2) representa a leitura das temperaturas e o terceiro (3) é informado se há 
fumaça ou gás no ambiente. A figura 26 exibe uma leitura do cotidiano, sem manifestar 
variações de temperatura ou fumaça/gás, por outro lado as figuras 27 e 28, apresentam 
testes provocados com o intuito da comprovação/validação do projeto. Na figura 27 em 
seu terceiro gráfico (3) é possível constatar em suas últimas leituras a detecção de 
fumaça/gás, por fim na figura 28 apresentam erros provados nos sensores de 
temperatura (gráfico 2) e no sensor de fumaça/gás (gráfico 3). 
 
Figura 26. Dados Enviados ao ThingSpeak. 
Fonte: Do Autor. 
 
 
Figura 27. Dados Enviados ao ThingSpeak, com detecção de fumaça/gás. 
Fonte: Do Autor. 
 
Figura 28. Dados Enviados ao ThingSpeak, com erros. 
Fonte: Do Autor. 
 O projeto em conjunto com a ferramenta ThingSpeak disponibiliza uma API que 
possibilita a outros aplicativos/sistemas usufruírem dos dados obtidos dos dispositivos, 
de forma a respeitar o paradigma da internet das coisas (IoT). A API utiliza comandos 
no formato HTTP do tipo GET para buscar dados, o qual retorna a busca nos formatos 
json, xml ou csv, de acordo com a figura 29 é possível verificar o formato e um modelo 
exemplo para buscar dados salvos na nuvem. 
 
Figura 29. Exemplo de Busca através da API. 
Fonte: Do Autor. 
 
5.5 Comparativos de custos de aquisição e energização do protótipo com modelo 
encontrado no mercado 
Com o viés de verificar a redução de custos de aquisição do projeto proposto em 
comparação com dispositivos similares existentes no mercado, a tabela 3 apresenta o 
valor gasto com cada sensor/módulo, como também o valor final do protótipo criado, 
totalizando R$ 176,63 reais. Enquanto que o aparelho da marca Unbrande de modelo 
S19360, conhecido como detector de incêndio Wi-Fi, encontra-se no mercado em um 
valor médio de R$327,00 com funcionalidades similares, diferenciado do modelo 
proposto, pelo fato de possuir um aplicativo criado que apenas exibe os dados coletados 
de forma momentânea, também o produto utiliza como fonte de energia uma bateria de 
lítio não recarregável. 
 
Quantidade Nome do Produto Valor 
1 Resistor 100K 1/4W R$ 0,21 
3 Resistor 330R 1/4W R$ 0,81 
1 Jumper para Protoboard Macho-Macho Kit 
c/ 20 peças 
R$ 9,98 
1 Detector de Gás / Fumaça MQ-2 R$ 14,82 
1 Sensor de TemperaturaLM35 R$ 11,97 
1 Led RGB R$ 2,76 
1 Arduino Uno R3 R$ 54,06 
1 Módulo Wi-Fi ESP8266 R$ 24,61 
1 Adaptador para Módulo WiFi ESP8266 R$ 10,50 
1 Fonte de Alimentação para Arduino R$ 16,91 
1 Prototipagem de Impressão 3d R$ 30,00 
Total: R$ 176,63 
Tabela 3. Orçamento de Desenvolvimento do Projeto. 
Fonte: Do autor. 
 Por fim foi realizado testes de energização, com o intuito de demostrar sua 
economia em comparação com o aparelho mencionado acima (modelo S19360). O 
projeto proposto consome 9 Watts/hora, levando em consideração o funcionamento de 
24 horas por dia durante um ano (365 dias) o consumo final será de 78840 Watts ou 
78,840 kWh (quilowatt-hora), no Rio Grande do Sul o valor do quilowatt-hora com 
tarifa de bandeiras inclusa está na média de R$0,84 centavos, o valor gasto anualmente 
será algo em torno de R$66,23. Enquanto que o modelo S19360 faz uso de uma bateria 
de lítio de 3 volts, com a especificação CR123A 1400mAh (não recarregável) e o 
aparelho necessita de uma alimentação constante de 0,4mA. A pilha nas condições 
identificadas, demostram durar em média 130 dias, necessitando de 3 pilhas anuais, já o 
custo de cada pilha na internet está na média de R$ 40,00 reais, totalizando um custo 
anual de R$ 120,00 (desprezando o frete). Desta forma é possível afirmar que o custo 
 
anual de energização do protótipo é praticamente o dobro mais em conta comparado ao 
aparelho de modelo S19360 da fabricante Unbrande. 
5.6 Trabalhos Futuros 
 Pretende-se implementar aplicativos para Android e iOS baseado nos dados 
coletados, de forma a não somente exibir os resultados, mas sim usar os parâmetros 
aferidos pelos sensores para mapeamentos de temperaturas e fumaça e gás. Como 
também em ambientes com diversos dispositivos unificar as coletas e exibir métricas de 
balanceamento das temperaturas e em casos de identificações de incêndio/fumaça usar 
medidas para expressar o foco inicial do incêndio/fumaça com o viés de uma eficácia 
em seu combate. 
 Há também a possibilidade da criação de um servidor em nuvem destinado a 
coletas e mapeamento dos dispositivos de forma a criar uma unificação e concentração 
dos dados e conjuntamente disponibiliza-los através de uma API de forma a zelar pelas 
métricas da interconexão de dispositivos e abrir possibilidades de uniões com outros 
mecanismos e programas. 
 Viabilizar a utilização de outros sensores com características diferenciados 
visando prover uma maior interação entre o meio e o usuário de forma a promover uma 
gama de serviços que beneficiem a sociedade e o meio, zelando pelo bem-estar social 
com o viés educacional ao ambiente e a suas limitações. 
 Com cunhos futuros permitir a união do servidor a ser desenvolvido, juntamente 
aos mapas e radares de carros autômatos visando alertas de incêndios em ambientes, de 
forma a proteger seus usuários bem como os seus veículos. 
5.7 Conclusão Parcial 
Os testes realizados no protótipo, desenvolvido no projeto, demostraram que o sistema 
apresentou-se estável, tornando-o passível para ser implementado em um ambiente, 
também além de fornecer um consumo de energia mais ecológico, seus custos de 
aquisição e montagem mostraram-se mais acessíveis em comparação com produtos 
encontrados no mercado atualmente. 
6. Considerações finais 
O projeto proposto, sintetiza o início da interconexão dos dispositivos aos meios afins, 
respeitando os ideais do paradigma de internet das coisas (IoT) e métricas de 
informações em nuvem, com cunho inicial de promover maior segurança e comodidade 
ao ambiente físico, de forma a zelar pelo bem-estar social. Também buscou-se trazer 
uma nova atualização ao estado da arte e viabilizar a proposta, com o uso de 
ferramentas e análise de valores, por fim pretende-se realizar novos projetos baseando-
se nos trabalhos futuros, de forma a promover melhores interações e facilitar a sua 
usabilidade. 
7. Referências 
ABAYA, S et al. An Embedded System of Dedicated and Real-time Fire Detector 
and Locator Technology as an Interactive Response Mechanism in Fire 
Occurrences. Pune - India, IEEE ICAECCT, 2016. 
 
IMTEAJ, Ahmed, Tanveer Rahman, Muhammad Kamrul Hossain et al. An IoT based 
Fire Alarming and Authentication System for Workhouse using Raspberry Pi 3. 
Bazar - Bangladesh IEEE ECCE, 2017. 
MUHEDEN, K. et al. Design and Implementation of the Mobile Fire Alarm System 
Using Wireless Sensor Networks. Budapest - Hungria, IEEE CINTI, 2016. 
MCROBERTS, Michael. Beginning Arduino, Second Edition. Nova York - Estados 
Unidos, Apress Inc.,2015. 
ARION, Caio. Automação na Arquitetura, 2019. Disponível em: < 
http://wattconsultoria.com.br/automacao-na-arquitetura/> Acesso em 20/11/2019. 
SENA, Diane Cristina Souza. Automação Residencial. Vitória - Brasil, Projeto de 
Graduação. 119 f. Centro Tecnológico da Universidade Federal do Espírito Santo, 
2005. 
RODRIGUES, Bruno Gomes. Automação residencial: suas principais aplicações. 
Rio de Janeiro - Brasil, Instituto Federal de Educação, Ciência e Tecnologia 
Fluminense - Campos dos Goytacazes, 2010. 
OSIER, Jeffrey M. Hardware Aberto: Como e Quando Funciona. 2010. Disponível 
em: <http://www.ibm.com/developerworks/br/library/os-openhardware/> Acesso em 
10/05/2019. 
GENEVA ASSOCIATION. Fire and Climate Risk. 2015. Disponível em: 
<https://www.genevaassociation.org/> Acesso em 10/09/2019. 
BARTLESON, Karen. The Internet Of Things Is A Standards Thing, Electronic 
Design 2014. 
KEVIN, Ashton. That ‘Internet of things’ Thing. RFID Journal, 2009. 
ABBATE, Janet, Inventing the Internet. Massachusetts - Estados Unidos, MIT Press, 
2000. 
AL-FUQAHA, A., Guizani, M., Mohammadi, M., Aledhari, M., and Ayyash, M. 
Internet of things: A survey on enabling technologies, protocols, and 
applications. IEEE Communications Surveys & Tutorials (Volume: 17, Edição: 4) 
2015. 
SHELBY, Zach, Klaus Hartke and Carsten Bormann. The Constrained Application 
Protocol (CoAP). RFC 7252, Bremen - Alemanha, 2014. 
SANTOS, Bruno P., Lucas A. M. Silva, Clayson S. F. S. C, et al. Internet das Coisas: 
da Teoria à Prática. Livro de Minicursos SBRC 2016. 34 ed, Sociedade Brasileira 
de Computação (SBC), v. XXXIV, p. 1-50, Rio Grande do Sul – Brasil, 2016. 
KHAN, Rafiullah, Sarmad U. Khan, Rifaqat Zaheer, Shahid Khan. Future Internet: 
The Internet of Things Architecture, Possible Applications and Key Challenges. 
IEEE International Conference on Frontiers of Information Technology, Islamabad – 
Paquistão, 2012. 
THANGAVEL, D., Ma, X., Valera, A., Tan, H.-X., and Tan, C. K.-Y. (2014). 
Performance evaluation of MQTT and CoAP via a common middleware. 
ISSNIP, IEEE Ninth International, Singapura - Malásia, 2014. 
 
MCKINSEY & COMPANY, Internet das coisas já é realidade, porém falta 
regulamentá-la. São Paulo - Brasil, 14 de dezembro de 2016. Disponível em: < 
https://www.mckinsey.com/br/our-insights/blog-made-in-brazil/internet-das-coisas-
ja-e-realidade-porem-falta-regulamenta-la>. Acesso em: 19 de setembro de 2019. 
BUSINESS INSIDER INTELLIGENCE, Here's how the Internet of Things will 
explode by 2020. Nova York - Estados Unidos, 28 de abril de 2016. Disponível em: 
< https://www.businessinsider.com/iot-ecosystem-internet-of-things-forecasts-and-
business-opportunities-2016-4-28 >. Acesso em: 19 de setembro de 2019. 
GLITHO, Roch H. Powering Internet of Things with Cloud and NFV for Cost 
Efficient and Agile Applications and Services Provisioning. IEEE Conference on 
Network Softwarization, 2016. 
MUELLER, Martin, Peter Karasev, Ivan Kolesov, Allen Tannenbaum. Optical Flow 
Estimation for Flame Detection in Videos, IEEE Transactions on Image Processing 
(Volume: 22, Edição: 7), 2013. 
LIAN, Chun-Yuan. Design of intelligent fire alarm system based on gsm network. 
IEE International Conference on Electronics and Optoelectronics, Dalian - China, 
2011. 
CARVALHO, André A. D., Francisco O. C. S. Antunes. Sistema remoto de detecção e 
prevençãode incêndio multi-sensor em ambiente residencial. Universidade 
Tecnológica Federal Do Paraná Engenharia De Computação, Curitiba – Brasil, 2015. 
AL-AMEEN, Mahdi Nasrullah. An Intelligent Fire Alert System using Wireless 
Mobile Communication. The University of Texas at Arlington, Condado de 
Arlington - Texas, 2013. 
SABANCI, Kadir, Deniz Üstün, Enes Yigit, AbdurrahimToktaş. Thingspeak Based 
Monitoring IoT System for Counting People in A Library. IEE International 
Conference on Artificial Intelligence and Data Processing (IDAP), Malatya – 
Turquia, 2018. 
MAUREIRA, Marcello A. Gómez, Daan Oldenhof, Livia Teernstra. ThingSpeak - an 
API and Web Service for the Internet of Things. Media Technology - Institute of 
Advanced Computer Science (LIACS) Leiden – Holanda, 2016. 
MHATRE, Leena Neha Rai. Integration Between Wireless Sensor and Cloud. IEE 
International Conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud) 
(I-SMAC), Palladam - India, 2017.