Implementação do PCOM WiFi Bluetooth ESP32 para Arduino

Primeira parte:  apresentação.

olá a todos.

 

        Esta é a publicação que se originou de um tópico iniciado pela Marcela de Souza para uma implementação ESP32 na Plataforma Arduino, descrita neste link:   "Esp32 Wiffi e Bluetooth Classic"

 

        Marcela já havia aberto um outro tópico sobre a questão, mas não obteve sucesso naquele momento. Então teve insistência e abriu outro tópico (o do link anterior), me solicitando ajuda sobre a questão.

        O que Marcela desejava era apenas um Sistema que funcionasse preferencialmente no WiFi, mas que também fosse capaz de funcionar no Bluetooth caso em algum momento o WiFi não estivesse disponível. Por exemplo: parece que a Marcela implementou no Hardware do ESP32 alguma alimentação a Bateria, de forma que mesmo sem energia da rede elétrica convencional, o ESP32 continuava alimentado, e poderia se comunicar via Bluetooth, o que permitiria todos os controles estarem disponíveis no Smartphone, já que o WiFi dependeria do Roteador e este seria um problema a mais se tivesse que alimentar com alguma Bateria ou Nobreak.

        Então analisei a questão, olhando tópicos especializados no  mundo todo (inclusive publicados por quem escreve a plataforma do ESP32 na Espressif), e vi que haviam de fato problemas de convivência entre WiFi e Bluetooth. Estes problemas estavam enraizados no fato de que o WiFi e Bluetooth compartilham o mesmo Hardware Wireless, e embora fosse possível uma convivência entre eles (pois usam canais wireless distintos), esta “disputa” no Hardware do ESP32 inicialmente levou o pessoal da Espressif a separar completamente as coisas (talvez imaginando que as pessoas não iriam usar WiFi e Bluetooth "simultaneamente"). Essa separação se deu a nível da BIOS do ESP32, ou seja:  estava separado na raiz do Sistema. Qualquer alteração, implicaria em alterar a alma da coisa toda. Mas aparentemente, a Espressif o fez, embora existam algumas poucas restrições de uso. No entanto, isso ainda não chegou à implementação do ESP32 para a Plataforma Arduino.

        Apesar disso, ainda assim seria possível obter-se o comportamento que a Marcela desejava: ter um Sistema que permitisse tanto o controle via WiFi como via Bluetooth, e que isso se desse de forma automática, conforme qual deles estivesse disponível. Se a Rede WiFi estivesse disponível, o Sistema usaria o WiFi. E se não estivesse, e se algum Smartphone, Tablet, ou mesmo um computador com Bluetooth, iniciasse uma conexão, então todo o controle poderia ser feito via Bluetooth. E ao se desconectar do Bluetooth e o WiFi estiver novamente ao alcance, então automaticamente o Sistema usaria o WiFi. Tudo de forma automática sem nenhuma necessidade de intervenção externa nem no código do Arduino.

        Então aqui está sendo publicada esta implementação, a qual foi chamada de "PCOM WiFi-Bluetooth" (a sigla "PCOM" é uma alusão a “Port de Comunicação”). O código implementado é totalmente aberto, sem restrições.

 

        Marcela já tinha implementado por sua conta, um APP executando no Android, que era exatamente como ela precisava. Mas para que tudo fosse mais genérico e pudesse ser utilizado por todos, o PCOM WiFi-Bluetooth (ou simplesmente PCOM WF-BT) pode ser usado através de um APP dedicado como o da Marcela, ou então através de um APP de Terminal Serial Bluetooth.

        No link no início desta publicação, pode-se encontrar outras informações a respeito das conjecturas da implementação. Por exemplo o fato de que usar Máquinas de Estados para simplificar a implementação e torná-la robusta, era o caminho a seguir. Também sobre a necessidade de se reescrever a Biblioteca original SPP Bluetooth do ESP32 para o Arduino, pois na minha análise inicial, descobri o quanto "travada" e problemática era aquela biblioteca (inclusive com erros graves na metodologia de implementação, o que tornava impossível se fazer o que a Marcela desejava).

  

        Ao longo desta publicação, serão apresentados de forma gradativa, exemplos para demonstrar o uso dos recursos disponíveis no PCOM WF-BT. No Bluetooth por exemplo, para segurança há um Processo de Autenticação do Cliente, e uma Lista de Clientes Autenticados é mantida no Sistema, o que abre diversas possibilidades. No WiFi, pode-se ter exemplos de como usar um Mecanismo existente no PCOM para gerenciar facilmente diversas Páginas HTML (aninhadas ou não), dando uma sofisticação adicional para o Sistema (utilizando quaisquer protocolos sobre o TCP/IP, sejam padrões ou dedicados). E também exemplos sobre a forma mais adequada de se controlar o que se quiser (sejam dispositivos de Entrada ou de Saída, Digitais ou Analógicos, ou então apenas Gerenciamento de Dados). Assim estes exemplos poderão servir de base para explorar o Sistema PCOM WF-BT conforme cada um desejar.

        Ainda sobre os exemplos, a ideia é apresentar os mesmos com complexidade crescente, pois acredito que isto é a forma mais acessível a todos, permitindo trilhar um caminho ascendente no uso dos recursos apresentados.

        E claro, que as pessoas também fiquem à vontade para explorar a coisa toda, e da forma como acharem mais adequada a cada um.

 

 

        No tópico que originou a questão, apresentei a metodologia para a solução da implementação, a qual consistia em usar Máquinas de Estados para controlar o Sistema, e também redesenhar a Biblioteca SPP Bluetooth do ESP32. E isto foi seguido. Porém imediatamente depois, surgiu a necessidade de um Processo de Autenticação Bluetooth (pois a Espressif não implementou uma requisição de senha para o pareamento Bluetooth), para se ter algum controle de acesso ao Sistema, aumentando a segurança do mesmo. Esta questão da Autenticação Bluetooth, implicou em se fazer alguns ajustes nas Máquinas de Estados, porque a implementação manteve separados o Controle da Conexão e o Gerenciamento da Autenticação Bluetooth, pois para que a Autenticação fosse possível, a Conexão Bluetooth deveria estar ativa com um Cliente conectado.

        Então os Diagramas de Estados das Máquinas implementadas, não é exatamente igual ao publicado inicialmente. E para o Processo de Autenticação Bluetooth, mais duas Máquinas foram implementadas, o que totalizou em 5 Máquinas de Estados no Sistema.

 

        Na figura a seguir é mostrado como estas Máquinas se inter-relacionam, e onde os Processos do Usuário se encaixam no Sistema:

(clique na figura para "zoom")

 

        Observar que podem existir num mesmo Sistema, diversos Processos do Usuário. Cada um desses Processos, pode estar ocupado com o controle de algum elemento no Sistema, e estes Processos podem inclusive ser totalmente independentes uns do outros.

 

        A figura a seguir mostra alguns detalhes da estrutura de um Processo do Usuário:

 (clique na figura para "zoom")

        Assim, um Processo do Usuário, seria algo próximo a um “sketch” do Arduino (ESP32) que faz alguma coisa específica. E se for considerado um “sketch” mais complexo que faz diversas coisas, então um Processo do Usuário pode ser um trecho de código desse “sketch”, onde neste trecho de código também é feito algo específico. Por exemplo, um “sketch” simples que lê um Sensor de Temperatura, e informa a um “Cliente” conectado via PCOM, o valor da Temperatura a intervalos regulares. Como exemplo de um “sketch” um pouco mais complexo, pode ser um Sistema que controla o aquecimento de um forno, monitora a temperatura desse forno, e ainda controla motores: neste caso, o Cliente pode determinar a temperatura desejada do forno, assim como obter a qualquer instante o valor real da temperatura, e também determinar parâmetros de controle dos motores (qual motor, qual a velocidade, etc). Neste último exemplo, do “sketch” mais complexo, cada uma das ações descritas, é um Processo do Usuário.

 

        Como foi dito, os Processos podem ser independentes, ou então interligados de alguma forma. O importante é identificar os Processos, e implementar cada um deles seguindo uma “receita” ou “Modelo de Programação” para que cada Processo se comunique com o Cliente conectado (via WiFi ou Bluetooth), e através de comandos enviados pelo Cliente (ou pelo próprio Processo), controle adequadamente os elementos do Sistema que fazem parte daquele Processo. Isto é preciso ser descrito assim, porque um erro muito comum quando as pessoas “leigas” escrevem seus códigos para o Arduino, é misturar tudo como se fosse uma salada de frutas, onde mal se consegue distinguir um Processo individual sendo executado, e esta é a receita perfeita para tudo sair errado (o que acontece muito, e se não acontece é por uma certa “sorte” em se conseguir um código que mesmo “bagunçado” tem um resultado parecido com o desejado – mas normalmente frágil e muitas vezes instável).

 

        Nas próximas cinco figuras, são mostrados os Diagramas de Estados das Máquinas de Estados implementadas, junto a algumas descrições simples. Embora o funcionamento dessas Máquinas possa dar a impressão de serem implementações complexas, na realidade são simples. Ocorre que a falta de conhecimento dos princípios de funcionamento de uma Máquina de Estados, leva a se ter a impressão da complexidade.

        Além disso, é importante notar que os diversos elementos nos Diagramas de Estados (círculos, setas de cores diferentes, e descrições simples), indicam justamente que é implementado sempre o mesmo tipo de comportamento, fazendo que toda a técnica de implementação e o próprio funcionamento de uma Máquina de Estados, seja algo sistemático. Ou seja, conhecendo-se as técnicas básicas de como se implementa uma Máquina de Estados, pode-se abstrair e expandir tudo isso, levando a implementações bastante sofisticadas, com a vantagem da extrema confiabilidade (inexistência de bugs) e ainda mantendo a simplicidade.

        As cinco Máquinas aqui implementadas, tem sim algum nível de sofisticação e até complexidade, mas nada que seja de difícil de entendimento.

 (clique na figura para "zoom")

(clique na figura para "zoom")

(clique na figura para "zoom")

(clique na figura para "zoom")

(clique na figura para "zoom")

        O tópico está continuado imediatamente a seguir, apresentando o primeiro exemplo,  que mostra o controle via WiFi (Página HTML) e Bluetooth (um dispositivo que foi chamado de "BlueLAMP"). Este exemplo mostra o controle de uma Lâmpada (ou LED, para quem quiser apenas testar a funcionalidade), sendo o primeiro de uma série de exemplos.

        E finalizando esta primeira parte, segue o link para Download da Biblioteca do PCOM WiFi-Bluetooth (o link é do GitHub, pois o arquivo zipado tem mais de 8MBytes, impedindo de anexá-lo aqui no LDG).

        Para adicionar a biblioteca, basta seguir o método padrão de acrescentar bibliotecas na IDE do Arduino, através do Menu  "Sketch", opção "Incluir Biblioteca", opção "Adicionar biblioteca .ZIP" (fazendo isso a partir do arquivo "zip", nenhum ajuste no nome de arquivos será necessário para uma compilação sem erros relacionados a "arquivos não-encontrados"). No arquivo zipado, além da Biblioteca, já se encontra toda a documentação e o primeiro exemplo aqui publicado).

        Link para a Biblioteca:   "PCOM WiFi-Bluetooth ESP32/Arduino"

        Para fazer o download na página do link, basta clicar no Botão "Download" mostrado na figura a seguir:

(clique na figura para "zoom")

Abrçs,

Elcids

Exibições: 2385

Responder esta

Respostas a este tópico

Bom dia Elcids, eu gostaria de controlar pelo esp32 via wifi e bluetooth, 5 lampada, Liga e desliga e 2 portoes com pulso, total 7 reles

Ok Marcela.

      Nos exemplos que irei publicar, já existirão elementos de controle na quantidade e tipos conforme vc disse estar usando. Mas mesmo assim posso publicar também um exemplo exatamente conforme vc está descrevendo.

      Para o controle dos Portões,  acredito que vc esteja usando o mesmo esquema daquele post do "Blink" onde te ajudei com uma solução (deste link: "Portão-Blink" ).  Então irei usar o mesmo tipo de acionamento para os Portões. Mas fica a pergunta: eles deverão fechar automaticamente também após 25 segundos,  como naquele post?

      Claro, como os exemplos irão ser crescentes em termos de complexidade, este seu não estará entre os primeiros que publicarei aqui, devido à quantidade de elementos (como vc disse, são no total 7 elementos, além da questão do portão fechar automaticamente). Mas já deixei toda base pronta,  do APP no App Inventor,  ao código básico do ESP32 PCOM WiFi/Bluetooth para usar nos exemplos. Então não deve demorar muito.

      Abrçs,

      Elcids

Boa noite Elcids, sim com o fechamento automatico com 25 segundos

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço