O código fonte gravado no ESP 32 foi desenvolvido no mesmo ambiente de desenvolvimento do Arduino. Com algumas instalações de bibliotecas e algumas configurações, a IDE do Arduino, ilustrada na Figura 25, pode ser utilizada para a programação e gravação do
_____________________________________________________________________________________ módulo ESP 32. Isto é possível devido ao fato da linguagem de programação utilizada em ambos ser a mesma, a linguagem C. Além disso, também é possível utilizar o mesmo monitor serial do Arduino para interagir via comunicação serial com o ESP 32.
Figura 25 – IDE Arduino
Fonte: Autoria própria (2020).
O código fonte completo e totalmente comentado do sistema de monitoramento e controle de processos produtivos pode ser consultado ao final deste relatório, no Apêndice A. Nas próximas páginas serão expostos alguns trechos deste código fonte, acompanhados de uma breve explicação das partes mais importantes e relevantes para o sucesso dessa implementação.
A Figura 26 ilustra o trecho do código onde é realizada a inclusão de todas as bibliotecas necessárias para o correto funcionamento do sistema. Também são inseridos o usuário e a senha para conexão do ESP 32 com a rede Wi-Fi desejada.
Figura 26 – Código fonte – Parte 1
Fonte: Autoria própria (2020).
A Figura 27 ilustra o trecho do código onde são definidas as strings com os dados obtidos durante o cadastro do dispositivo na Plataforma IBM Watson IoT. São elas: ORG, TIPO_DISP, ID_DISP e TOKEN_DISP.
Através da união desses dados também são formadas as strings ID_CLIENTE e SERVIDOR_MQTT, ambas utilizadas na conexão do dispositivo com o servidor MQTT.
Também estão sendo definidas as variáveis “Temperatura” e “Entrada” que serão utilizadas mais adiante.
Figura 27 – Código fonte – Parte 2
_____________________________________________________________________________________ A tela ilustrada na Figura 28 serve para exemplificar o local de obtenção dos dados utilizados anteriormente no código fonte. Imagem obtida durante a realização do cadastro na Plataforma IBM Watson IoT.
Figura 28 – Tela com dados da Plataforma IBM Watson IoT
Fonte: Autoria própria (2020).
O trecho de código da Figura 29 é importante e deve-se ter cuidado na definição dos tópicos, pois alguns padrões de composição estão definidos de acordo com o servidor MQTT escolhido. Neste caso, para o servidor IBM Watson, o padrão para formação dos tópicos de publicação deve seguir essa sequência:
“ iot-2/evt/event_id/fmt/format_string ”, onde “event_id” e “format_string” podem ser alterados conforme a necessidade do projeto.
Os tópicos para inscrição foram cadastrados no aplicativo do dashboard e neste ponto somente foram registrados replicando as informações daquele local. Porém, também devem seguir uma sequência pré-definida, sendo:
“ iot-2/cmd/command_id/fmt/format_string ”, onde “command_id” e “format_string” podem ser alterados conforme a necessidade do projeto.
Além da definição dos tópicos para inscrição e publicação de informações, neste trecho deve ser realizada a definição dos pinos que serão utilizados no ESP 32 e ainda deve-se definir o cliente PubSubClient, através da informação do SERVIDOR_MQTT, da porta padrão 1883 e das informações Wi-Fi da conexão.
Figura 29 – Código fonte – Parte 3
Fonte: Autoria própria (2020).
A Figura 30 ilustra o trecho do código onde é realizado o setup do ESP 32. Nesse ponto, a serial é inicializada com velocidade de 115200 bits por segundo (bps), os pinos utilizados são configurados como entrada ou saída, e ainda, os pinos de saída são definidos inicialmente com nível lógico baixo.
Figura 30 – Código fonte – Parte 4
_____________________________________________________________________________________ A Figura 31 ilustra o trecho do código onde é realizada a conexão com a rede Wi-Fi, através da função WifiManager, uma função padrão existente para esses fins. Na última linha do trecho também é realizada a chamada da função para conexão com o servidor MQTT.
Figura 31 – Código fonte – Parte 5
Fonte: Autoria própria (2020).
A Figura 32 ilustra a parte inicial da função loop principal do ESP 32. Inicialmente ocorre a verificação se o dispositivo permanece conectado ao servidor MQTT, e caso não esteja, ocorre a chamada da função para que essa conexão se estabeleça. Após reestabelecida a conexão com o servidor, passaremos para o próximo trecho.
Figura 32 – Código fonte – Parte 6
Fonte: Autoria própria (2020).
No trecho ilustrado na Figura 33, ocorre a chamada das funções de leitura de temperatura e de leitura da entrada digital, os valores de retorno dessas funções são salvos nas variáveis correspondentes e são mostrados no monitor serial. Além disso, é realizada a alteração do estado
do pino de saída do LED amarelo de acordo com o estado dessa entrada digital. Também é realizada a chamada da função “client.loop()”, que tem a função de averiguar se houve alguma publicação em algum tópico de interesse do dispositivo, baseado na inscrição realizada nos tópicos.
No fim deste trecho é chamada a função de publicação de eventos, e para esta função são enviados os valores das variáveis “Temperatura” e “Entrada”. Então ocorre um delay de 1000 ms, para que a publicação destes dados ocorra a cada 1 segundo.
Dessa forma, encerra-se o loop principal e recomeça, novamente verificando se a conexão do dispositivo com o servidor MQTT ainda está ativa.
Figura 33 – Código fonte – Parte 7
Fonte: Autoria própria (2020).
A função mostrada na Figura 34 é responsável por realizar efetivamente a conexão do dispositivo com o servidor MQTT. É para esse trecho do código que o programa segue cada vez que se faz necessária a conexão ou a reconexão com este servidor. Nesta função é utilizado o
_____________________________________________________________________________________ comando “client.connect”, que envia os dados como ID_CLIENTE e o TOKEN_DISP para o servidor validar a conexão.
Outro comando MQTT utilizado aqui é o “clientsetCallback”, que habilita o retorno de informação cada vez que algo for alterado em algum tópico que o dispositivo está inscrito.
Após a confirmação de conexão com o servidor, o LED verde de conexão é ligado e o comando “client.subscribe” tem a função de inscrever o dispositivo nos tópicos de interesse, neste caso, dois tópicos, um para receber os comandos da saída 1 e o outro para a saída 2.
Em caso de falha na conexão, uma mensagem de erro é enviada ao monitor serial e é realizada uma nova tentativa de conexão.
Figura 34 – Código fonte – Parte 8
Fonte: Autoria própria (2020).
A função de publicação mostrada na Figura 35 é responsável por todos os dados que saem do dispositivo em direção à nuvem. Nesta função é composta uma string de nome “payload” com as descrições e os valores recebidos das variáveis “Temperatura” e “Entrada”. Após formada a
“TOPIC_PUB”, o qual contém o endereço do tópico designado como tópico de publicação. Em outras palavras, esse comando envia os dados para a nuvem.
Após a publicação, uma mensagem de OK ou de falha é enviada ao monitor serial, conforme retorno obtido do servidor MQTT.
Figura 35 – Código fonte – Parte 9
Fonte: Autoria própria (2020).
A função “retorno_topico” ilustrada na Figura 36, desempenha a função de receber o retorno das mensagens dos tópicos onde o dispositivo está inscrito. Sempre que algum tópico for modificado, essas mensagens são enviadas para esta função e recebem o devido tratamento para identificação de, por exemplo, a qual tópico elas pertencem. Neste caso pode ser o tópico da saída 1 ou o tópico da saída 2.
Uma vez definido o tópico, é possível saber em qual saída deverá ser tomada a ação, basta saber ainda que ação tomar. Ligar ou desligar a saída?
Neste momento a função Json Parse entra em ação. Esta função tem a finalidade de analisar a variável recebida, “carga”, e separá-la em partes, a fim de descobrir o valor contido na
_____________________________________________________________________________________ carga útil desta variável e armazenar este valor na variável “comando”, que recebe então 0 ou 1. Este valor então é aplicado à saída correspondente ao comando.
Figura 36 – Código fonte – Parte 10
Fonte: Autoria própria (2020).
A leitura de temperatura do circuito integrado LM35 ocorre nessa função mostrada na Figura 37. A obtenção do valor de temperatura ocorre através da leitura da entrada analógica denominada “ANALOG_ENT”. Como a tensão de trabalho do ESP 32 é de 3,3 V e a resolução do conversor AD é de 12 bits, na equação é necessário dividir os 3,3 por 4096 (combinações binárias possíveis), obtendo-se assim o valor correspondente de cada bit. Então basta multiplicar este resultado pelo valor binário lido na entrada analógica, e ainda multiplicar por 100. Essa multiplicação por 100 é necessária devido ao fato do LM35 apresentar sinal de saída de 10 mV/°C. São realizadas 5 amostras que são acumuladas na variável “temp” e ao final da quinta amostragem a variável “temp” é dividida por 5, aumentando a precisão das leituras. Por fim, o valor resultante de temperatura é enviado de volta para a variável que realizou o chamado desta função.
Figura 37 – Código fonte – Parte 11
Fonte: Autoria própria (2020).
E por fim, a leitura da entrada digital é realizada nesta função ilustrada na Figura 38, que simplesmente realiza a leitura da entrada digital e armazena o valor, 0 ou 1, na variável “digital”.
Essa variável “digital” é multiplicada por 100 e armazenada na variável “digi100”, somente para melhorar a forma de indicar este valor no dashboard. Assim, tem-se 0 é igual a 0% e 1 é igual a 100% e pode-se utilizar um mostrador do tipo ponteiro no aplicativo.
E finalmente, o valor resultante da entrada é enviado de volta para a variável que realizou o chamado desta função.
Figura 38 – Código fonte – Parte 12
Fonte: Autoria própria (2020).
Após a conclusão do desenvolvimento do código fonte, o mesmo foi compilado, e não tendo apresentado nenhum erro, foi gravado no módulo ESP 32 através da IDE do Arduino, com conexão via porta mini USB.
_____________________________________________________________________________________
5 RESULTADOS
Finalizado o projeto e a elaboração do código fonte, o NodeMCU ESP 32 e os demais componentes eletrônicos do sistema de monitoramento foram montados em uma protoboard, conforme a Figura 39, para o início dos testes e verificação dos resultados.
Figura 39 – Circuito montado na protoboard
Após várias correções necessárias sobre a primeira versão do código fonte, o sistema apresentou-se funcional, mas com algumas instabilidades na conexão.
Nesse sentido, mais ajustes e melhorias no código fonte, e a estabilidade foi alcançada. Entre as qualidades do sistema pode-se destacar a velocidade de resposta do sistema a cada alteração de uma entrada do dispositivo local, ou a cada acionamento de uma saída do mesmo. Em condições normais de funcionamento da internet, o tempo de resposta é menor que 1 segundo.
O aplicativo desenvolvido no ambiente do Node-RED, está hospedado na nuvem, dentro da Plataforma IBM Watson IoT, no ambiente “mybluemix”, e resultou na aparência ilustrada na Figura 40. Este aplicativo pode ser acessado por qualquer smartphone, Tablet ou computador a partir do endereço https://famu-esp32.mybluemix.net/.
Figura 40 – Aparência do aplicativo elaborado
Fonte: Autoria própria (2020).
Os eventos ocorridos no ESP 32 também podem ser visualizados a partir do monitor serial da IDE do Arduino, conforme ilustrado na Figura 41, onde estão destacados alguns pontos importantes, que serão melhor detalhados logo na sequência.
_____________________________________________________________________________________ Figura 41 – Monitor serial IDE Arduino
Fonte: Autoria própria (2020).
Pode-se observar na parte inicial do arquivo, apontada pela seta vermelha, o momento onde ocorre a conexão com a rede Wi-Fi e a obtenção do endereço de IP 192.168.1.106. Logo abaixo, na linha destacada em azul, ocorre a confirmação de conexão com o servidor MQTT. A
partir desse momento passam a ocorrer as publicações das informações e o recebimento dos comandos a cada 1 segundo. Na parte apontada pela seta verde, ocorre a publicação da temperatura 25,4°C e da entrada digital em 0%. Pouco mais abaixo, na parte apontada pela seta azul, ocorre a entrada de um comando indicado pelo tópico da saída 1 e também são publicados os valores de temperatura 25,0°C e da entrada digital em 100%. E por fim, na parte apontada pela seta laranja, ocorre a entrada de mais um comando indicado pelo tópico, dessa vez para a saída 2, e também são publicados os valores de temperatura 25,2°C e da entrada digital em 100%.
Todas as informações publicadas pelo dispositivo local também podem ser visualizadas diretamente no ambiente da Plataforma IBM Watson IoT, conforme a Figura 42.
Figura 42 – Publicações na Plataforma IBM Watson IoT
Fonte: Autoria própria (2020).
Nesta mesma plataforma também pode ser verificado o status da conexão de todos os dispositivos cadastrados, por usuário, conforme a Figura 43.
_____________________________________________________________________________________ Figura 43 – Status de conexão dos dispositivos cadastrados no IBM
Fonte: Autoria própria (2020).
O status acima indica que o dispositivo denominado ESP 32, com ID 001, está ativo, conectado ao servidor MQTT, desde o dia 19 de junho de 2020, às 08:12, sendo essa uma informação daquele instante.