_Negativo_pn.png)
Neste blog trazemos uma shield que suporta tanto o Esp32 com o Esp12, numa única placa, seguindo um conceito de dois em uma. Apenas mudando o lado dela. Com informações muito valiosas referente aos Esp's, por exemplo, como mudar o firmware sem usar cabo de comunicação; como funcionar em Acess Point e web server; aplicativo para mudar o SSID e senha do esp; entre outras coisas.
Vamos aplicar a shield com o Esp32 na CPB Infinity para mostrar mais sobre ela. Mas ela pode ser aplicada também em outros produtos da Crescer.
Como premissas para o firmware temos:
1) Mudar o firmware sem usar cabo de comunicação e, portanto, não precisar tirar da placa para carregar novo software;
2) Funcionar no ESP32 e 12 da mesma maneira;
3) Usar a IDE do Arduino;
4) Receber regras de envio de mensagem do uC da CPB, ou seja, se vai enviar os dados para o thingspeak e estiver instalado em uma CPBInfinity, receberá tudo do Atmega328 da Infinity e enviará;
5) Funcionar como Access Point e como Server;
6) Resetar caso ocorra alguma falha;
7) Ter aplicativo para configuração do SSID e senha;
8) Salvar os dados de conexão wifi em EEProm.
No github tem todos os arquivos que serão comentados aqui.
NA PRÁTICA
PREMISSA 1: “Mudar o Firmware sem usar cabo de comunicação e portanto, não precisar tirar da placa para carregar novo software”
Quando selecionamos as placas com o microcontrolador ESP8266 ou ESP32 na IDE do Arduino, a IDE configura uma série de exemplos de códigos que não tinham ao selecionar o Arduino Uno, por exemplo.
Um destes exemplos para ESPs é relacionado ao termo OTA (Over The Air) mencionado em nosso vídeo:
OTA Intranet
OTA Http
Nestes vídeos abordamos que, ao carregar códigos preparados para OTA, as próximas mudanças de firmware, poderão ser via o endereço IP dos ESPs na rede, pois como visto na figura abaixo, eles ficam disponíveis e se o próximo firmware carregado, tiver ainda o código de OTA, continuará tendo esta funcionalidade.
Um teste interessante para fazer é abrir duas instâncias da IDE do Arduino, em uma delas colocar o ESP32 (por exemplo, podendo ser o nodemcu também) e na outra instância o Arduino Uno para o hardware de exemplo abaixo:
E então na instância do ESP, encontrar o IP na IDE (isto funcionará somente após a configuração do SSID que mostraremos a seguir).
E na instância do Uno, colocar a porta com que mapeou após a conexão o cabo.
Fazendo o upload na IDE que está o 32, poderá ver o avanço da carga do código como na figura abaixo:
PREMISSA 2: “Funcionar no ESP32 e 12 da mesma maneira”
Esta premissa não foi possível atender por um detalhe, no ESP32 tem a Serial2 e no ESP12 precisamos usar o Software Serial para tal funcionalidade, esta segunda porta não é útil.
A demanda de ter uma segunda Uart, não é deste projeto, mas sim da CPB32, mas ainda sim optamos por subir os 2 firmwares ao github, mas a diferença é somente esta que não conseguimos contornar, as demais diferenças como muitas Libraries, estão contornadas conforme abaixo:
Esta sintaxe é muito boa, pois roda no momento da compilação e fora das funções, assim dependendo de qual microcontrolador é, são selecionadas as bibliotecas.
PREMISSA 3: “Usar a IDE do Arduino”
Tanto as placas com ESP8266 como as placas que utilizam o ESP32 são utilizáveis com a IDE do Arduino e para quem domina a lógica de programação do Arduino, facilita bastante o uso.
PREMISSA 4: “Receber regras de envio de mensagem do uC da CPB, ou seja, se vai enviar os dados para o thingspeak e estiver instalado em uma CPBInfinity, receberá tudo do Atmega328 da Infinity e enviará”
A comunicação serial dos ESPs adicionados na CPB está perfeitamente adequada para que os microcontroladores troquem informações.
Nos códigos de exemplo, tudo que os ESPs enviam pela serial, a CPB imprime no monitor serial.
E se digitarmos a letra “a” no monitor serial, a CPB (arduino) envia para o ESP:
Então o ESP recebe o byte 0x02 que avisa o início do comando, após ele receberá a palavra “teste”, com isto o ESP está programado para enviar um número para o nosso thingspeak. E a CPB envia o byte 0x06 para avisar o final do comando.
Se digitar a letra “b” no monitor serial, deverá enviar o host para o ESP como o exemplo abaixo:
E se digitar a letra “c”, deverá enviar a url do envio como o exemplo abaixo:
O ESP receberá o “b” e aguardará o “c” para daí enviar algo para um server.
PREMISSA 5: “Funcionar como Access Point e como Server”
O Firmware que disponibilizamos testará constantemente o SSID disponível e se o mesmo não conectar, ele se configurará automaticamente como um access point, aí poderemos nos conectar a ele como se fosse um roteador, ele aparecerá com o nome CPB_xxxx; sendo os 4 últimos dígitos, o final do Mac Adress; assim ficará muito difícil de ter ESPs com o mesmo nome no ambiente. A Senha do SSID é 12345678. Uma vez conectado, você poderá configura-lo conforme descrito a frente.
PREMISSA 6: “Resetar caso ocorra alguma falha”
As configurações de SSID podem ser resetadas se colocar o GND no pino 18 do ESP12 e no pino 25 do ESP32 durante 10 segundos:
PREMISSA 7; “Ter aplicativo para configuração do SSID e Senha”
O conceito da pAr (Plataforma Aberta para Automação Residencial) que a Crescer lançou em 13/03/2018 é a base do código e do aplicativo que estamos disponibilizando, o aplicativo foi desenvolvido no App Inventor e está no github também, o arquivo de instalação android e o arquivo para usar e alterar no App Inventor.
O APP tem 3 telas:
A tela de entrada, onde no botão da esquerda você entra no aplicativo e no botão direito sai.
A tela de operação, onde tem 2 botões para cada ESP, que inclusive enviarão comandos na serial e você poderá lê-los e usá-los na CPB.
Ao acessar o botão de configuração, você configurará o ESP com o SSID, Password e IP fixo ou não.
Nos primórdios dos nossos estudos, configurávamos a porta também, por entender que impactava em caso de acesso remoto, mas já sabemos que a porta pode ser sempre a 80 localmente, e nos roteadores, deverá configurar uma porta distinta de entrada, mas a porta da intranet, poderá ser a 80. Aproveito para citar como exemplo o meu roteador abaixo:
Nesta questão, toda vez que tiver um acesso externo ao meu roteador (podendo ser via um No-Ip meu) e este acesso vier pela porta 90, exemplo http://no-ip.ddns.net:90/xxxxxxxxxx
O Roteador enviará esta requisição para o IP local 192.168.100.249 na porta 502. Este foi um caso que implantei para o Modbus IP que normalmente usa a 502. Neste caso, usaremos sempre a 80.
Voltando para a tela 3 abaixo:
Os campos obrigatórios são:
Rede Wifi: coloque o SSID que deseja que o ESP se conecte ao ligar.
Senha: a senha do SSID
IP fixo deste ESP: se somente for publicar dados ou buscar em algum lugar, pode deixar o IP dinâmico, deixando este campo com o número 0, caso contrário defina um número de 2 a 255 que não coincida com nenhum IP existente, estudo como definir um range de IPs fixos ou Dinâmicos no seu roteador, caso precise de IPs fixos.
Salvar: Pressione o botão Salvar e para enviar as configurações ao ESP, provavelmente o ESP estará como Access point, já que não conseguiu conectar-se a uma rede wifi, assim você deve conectar o telefone diretamente ao ESP, procurando por uma rede chamada CPB_xxxx; uma vez conectado, você poderá enviar os parâmetros de configuração clicando no botão:
PREMISSA 8: “Salvar os dados de conexão wifi em EEProm”
Bom, este foi um desafio interessante, pois a maior parte dos códigos de exemplo tem o SSID e senhas no próprio código fonte, o que na prática não é muito aplicável.
Para piorar um pouco, os ESPs não tem memória EEprom, mas ao invés disto, utilizam uma parte da memória Flash como EEprom.
Fazendo com que os comandos sejam diferentes, mas estas diferenças foram resolvidas ainda na época da pAr e estão disponíveis no firmware disponível no github.
Abaixo temos um fluxo do funcionamento geral do firmware:
E aí, o que achou deste material? Deixe seus comentários e vamos avançando...