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

Segunda parte:  primeiro exemplo simples de uso do PCOM WiFi-Bluetooth.

        Neste exemplo, a ideia é usar o PCOM WiFi-Bluetooth na implementação de um Sistema bem simples: controlar o liga/desliga de um LED, seja via WiFi, seja via Bluetooth (pois o PCOM se conectará ao que estiver disponível). A partir deste exemplo simples, inúmeros outros mais sofisticados poderão ser implementados.

 

        O Hardware de teste, pode ser algo como o mostrado na figura a seguir:

(clique na figura para "zoom")

        No código, pode-se especificar facilmente qual o pino da placa ESP32 será usado. Notar também que o “Katodo” do LED está ligado diretamente a um pino de I/O do ESP32, enquanto o “Anodo” está ligado à alimentação de 3.3V através de um Resistor de 330 Ω (o Resistor foi dimensionado considerando-se os 3.3V e uma luminosidade “média” para o LED, sem exageros do tipo “super nova ofuscante”). Assim o pino de I/O é configurado no código como “saída digital”, e para que o LED ligue é preciso ter-se no respectivo pino, o valor “LOW” (ou seja, nível digital0”). O nível que liga o LED também pode ser facilmente configurado no código.

 

        O LED poderá ser ligado ou desligado através de Interfaces entre um Cliente conectado através do WiFi ou Bluetooth.

 

        O mesmo código pode ser utilizado para controlar uma Lâmpada acionada através de um Relé. Por este motivo, no código deste exemplo sempre é usada a palavra Lâmpada ao invés de LED. Para aqueles que têm mais experiência em montagem de circuitos, e se sentem seguros em fazer montagens que se conectam à rede elétrica AC (127 ou 220 Volts), é mostrado na figura a seguir um exemplo de montagem com Lâmpada/Relé:

 (clique na figura para "zoom")

        Para o caso da Lâmpada/Relé, procure seguir rigorosamente o circuito mostrado, pois alguns pontos que podem parecer “bobos”, foram pensados para se ter maior nível de segurança (exemplo: o fato do fio marrom de “Fase” da rede elétrica estar conectado ao “CM” dos contatos do Relé).

        Observar também a forma como são interligados os diversos “GNDs” (do ESP32, da plaquinha do Relé, e da fonte que alimenta esta plaquinha), onde há um “ponto” de conjunção mais próximo da plaquinha do Relé do que da placa do ESP32. Essa topologia de ligação, é para minimizar as interferências e efeitos de “loops de terra” (que normalmente são nocivos ao funcionamento adequado dos circuitos).

 

        A plaquinha do Relé mostrada, é acionada por um Transistor BC548, justamente para permitir uma perfeita interface entre os níveis de tensão da Bobina do Relé (normalmente entre 5V e 12V), e a saída digital do ESP32 (D27 na figura). Vou elucidar um pouco, o porquê de se usar o Transistor como elemento intermediário para o acionamento do Relé.

        Esta plaquinha, aciona o Relé quando o nível digital de controle aplicado à mesma (no pino “IN” no conector de controle da plaquinha), é o nível “LOW” (ou “0”, exatamente como no caso do LED). Este acionamento é feito através de um Foto-Acoplador (aquele de 4 pinos na placa) cujo LED interno recebe alimentação de uma fonte ligada entre os pinos “VCC” e “GND” do conector de controle da plaquinha (via resistor existente na placa). E essa alimentação é a mesma usada para a Bobina do Relé, que é normalmente entre 5V e 12V (é especificado no datasheet do Relé). Devido a isso, há uma incompatibilidade entre o nível lógico “HIGH” do ESP32 (que é entre 2.5V e 3.3V), e o “HIGH” da plaquinha do Relé. Vou esclarecer. Se o sinal de saída do pino de I/O do ESP32 fosse aplicado diretamente para o controle da plaquinha do Relé, quando o pino do ESP32 estivesse em “LOW”, algo entre 0V e 0.3V, então seguramente o Relé seria acionado, pois esta faixa de tensão “LOW” iria ligar confiavelmente o LED do Foto-Acoplador. Porém para desligar o Relé, o nível lógico da saída do ESP32 tem que ser “HIGH”,  algo entre  2.5V  e  3.3V  Ocorre que esta faixa “HIGH” do ESP32 pode também acionar o Relé, já que o LED do Foto-Acoplador está sendo alimentado entre 5V e 12V (como já dito, a mesma tensão da Bobina do Relé), o que não deveria ocorrer. E para que não ocorra esse acionamento, é utilizado um Transistor BC548 como “Interface” entre os níveis lógicos do ESP32 e os níveis de tensão da Plaquinha do Relé. Neste caso, se a saída do ESP32 está em “LOW”, este nível lógico “desliga” o BC548 e o Foto-Acoplador não é acionado, desligando o Relé. E se a saída do ESP32 estiver em “HIGH”, a faixa deste nível será suficiente para “ligar” o Transistor e consequentemente o Foto-Acoplador e Relé. Observe no entanto, que agora a lógica inverteu, pois agora é o “HIGH” que aciona o Relé. Como pode-se escolher no código qual nível lógico irá acionar o Relé (“LOW” ou “HIGH”), então é melhor usar o BC548 como “Interface” entre os níveis digitais do ESP32 e os níveis para ligar/desligar o Relé da plaquinha, pois esta topologia garante um liga/desliga sempre confiável.

 

        No circuito com o BC548, o Resistor R1 é o de polarização da Base do Transistor, e é necessário para garantir os níveis adequados das correntes de liga/desliga no LED do Foto-Acoplador.

        Ao se fazer as ligações para o circuito Relé/Lâmpada, atenção à identificação dos pinos do Transistor BC548, mostrado na figura a seguir:

(clique na figura para "zoom")

 

        Mas existem plaquinhas de Relés cujo acionamento via sinal de controle no conector da respectiva plaquinha (o equivalente ao sinal “IN” na plaquinha mostrada), é através do “HIGH” (essas plaquinhas são menos comuns no mercado), então o sinal do pino do ESP32 pode ser ligado diretamente ao pino de controle da plaquinha, pois neste caso não costuma haver incompatibilidade de níveis lógicos.

        Seja acionando um LED, seja acionando uma Lâmpada via Relé, no código basta especificar o nível lógico (“LOW” ou “HIGH”) que liga o elemento (LED ou Relé da Lâmpada).  E claro, procure seguir as orientações e dicas sobre a montagem dos circuitos.

 

        Observar também que em algumas plaquinhas, como a mostrada aqui, na verdade não existe o efeito de isolação que poderia ser proporcionado pelo Opto-Acoplador. Então é preciso ficar atento aos modelos comercializados, caso a isolação seja realmente necessária.

 

        Como dito anteriormente, a Lâmpada (ou o LED), poderá ser ligado ou desligado através de Interfaces entre um Cliente conectado através do WiFi ou Bluetooth.

        Para a Interface via WiFi, foi utilizada uma Página HTML simples, que sempre mostra o estado da Lâmpada, e tem um Botão para mudar este estado. Ou seja, o ESP32 se conecta à Rede WiFi especificada no código do Arduino, e a partir do Endereço IP que foi designado ao mesmo pela Rede, se acessa a Página HTML da Interface de Controle da Lâmpada, via navegador em um Computador, Smartphone, ou Tablet.

 

        O Endereço IP, é mostrado no Terminal Serial do Arduino, sempre que o PCOM WiFi se conecta à rede WiFi. Uma vez conectado, esse endereço não é exibido novamente. Mas se em algum momento a rede cair e depois ficar novamente disponível, o PCOM WiFi irá se conectar automaticamente à rede, e novamente irá exibir o Endereço IP da Interface. Isto é feito assim, porque o IP poderá mudar, uma vez que é designado pela Rede.

        Se um Roteador estiver sendo utilizado, pode-se também fixar o Endereço IP neste Roteador. Para isto, normalmente basta se entrar na página do Roteador, seção DHCP ou Clientes DHCP, pois ali vai estar sendo mostrado também o Endereço MAC do ESP32, e então ali mesmo se reserva o IP desejado para a Interface de Controle da Lâmpada, atrelando este IP ao MAC do ESP32.

 

        Na figura a seguir pode-se ver no Terminal do Arduino, o Endereço IP “192.168.0.21” da Página de Interface com o ESP32, exibido logo que o PCOM WiFi consegue se conectar à rede de nome “RJJ” que está especificada no código:

(clique na figura para "zoom")

 

        No código do Arduino, pode-se especificar o nome da Rede WiFi, a senha para conexão à esta Rede, bem como o “Port” do Servidor TCP/IP a ser usado pelo PCOM WiFi, exatamente como se faz nos programas convencionais de exemplos de WiFi Server para o ESP32.

 

        Na figura seguinte, o IP “192.168.0.21” mostrado na figura anterior, é digitado em um navegador de Internet, sendo então acessada a Página HTML da Interface de Controle da Lâmpada do exemplo em questão:

(clique na figura para "zoom")

 

        Como se vê, é uma Interface simples, que funciona no modotoggle”, ou seja, cada vez que clica no Botão de controle, o estado da Lâmpada é “invertido” (se estava desligada então liga, e se estava ligada então desliga, caracterizando o “toggle”).

        Observar que na Página é mostrado o estado atual da Lâmpada, e quando se clica no Botão, esta informação é atualizada na Página de Controle. É interessante criar um atalho para a Página de Controle, pois se por qualquer motivo a Rede WiFi caia ou se desconecte o ESP32, basta clicar no atalho para se ver o estado atualizado em que se encontra a Lâmpada, e neste caso o atalho é o próprio Endereço IP sendo usado pelo PCOM WiFi, conforme mostrado na figura a seguir:

 (clique na figura para "zoom")

        No exemplo de controle da Lâmpada via PCOM WiFi, foi utilizada apenas uma Página HTML simples, conforme mostrado. Porém o PCOM WiFi permite facilmente se controlar diversas Páginas, o que abre uma gama de possibilidades para a Interface com o Cliente WiFi. Escolhendo-se de forma adequada o “Modelo de Memória” para o ESP32, certamente será possível manter no espaço da Memória de Programa, estas diversas Páginas HTML (ou mesmo através de um SD Card conectado ao Sistema). Em exemplos ainda a serem publicados, será mostrado como implementar este Gerenciamento de Páginas através do PCOM WiFi.

 

 

        Para o controle via Bluetooth, como já foi dito no início, pode-se utilizar um APP de Terminal Serial Bluetooth (que tenha o perfil SPP no Bluetooth Classic), ou um APP desenvolvido especificamente para a aplicação de controle.

        Lembrando que independente do APP utilizado, um Cliente Bluetooth deverá passar pelo Processo de Autenticação, para então ter acesso ao Sistema. Observar que no WiFi, o Cliente já terá ingressado na Rede WiFi local, a qual normalmente já requer uma senha de conexão, mas se necessário é também fácil implementar um controle de acesso através de Páginas HTML, o que será demonstrado em breve também.

 

        Para o acesso e controle via APP de Terminal, foi utilizado o APPSerial Bluetooth Terminal”, que reúne todos os requerimentos para o controle via Interface SPP. Este APP é de autoria de Kai Morich, e está disponível gratuitamente no Google Play, conforme pode ser visto na figura a seguir:

 (clique na figura para "zoom")

No momento que este texto é escrito, o link da página do APP é este:   "Serial Bluetooth Terminal"

 

        Um documento foi preparado para descrever a configuração deste APP “Serial Bluetooth Terminal” para uso adequado com o PCOM Bluetooth, e que também mostra o Processo de Autenticação de um Cliente Bluetooth e o respectivo Controle da Lâmpada (também no modo “toggle” para simplicidade, da mesma forma que na Página HTML acessada via PCOM WiFi).

        Assim, para não se gastar mais linhas aqui neste texto, as quais já estão incluídas no documento mencionado, para entender como o APP é configurado e utilizado, veja o respectivo documento que está em um link no final deste artigo.  XYZ

 

 

        O controle do Sistema depois que um Cliente Bluetooth está Autenticado, é totalmente livre, e o Processo do Usuário sendo executado na Placa ESP32/Arduino tem a liberdade de utilizar qualquer mecanismo de controle que achar conveniente. Este mecanismo ainda estará dentro da Interface SPP Bluetooth, mas isto será totalmente transparente ao Processo do Usuário. Isto será mostrado mais à frente, e posteriormente será demonstrado através de um APP dedicado.

 

        O Processo de Autenticação Bluetooth tem suas regras, que apesar de muito simples, devem ser seguidas para que um Cliente possa se Autenticar e assim ter acesso ao controle do Sistema.

 

        O PCOM Bluetooth disponibiliza dois “Modos de Comando” para o Processo de Autenticação: o “Modo de Comando Simples” e o “Modo de Comando Texto”. Este dois modos estão descritos no documento que trata do uso do APP de Terminal Serial, então os detalhes relacionados a estes modos não serão aqui mostrados.

 

        Mas é importante dizer que o “Modo de Comando Texto” é o mais adequado quando se utiliza um APP de Terminal Serial, onde uma pessoa (o Cliente Bluetooth) irá fazer a Autenticação e o Controle do Sistema.

 

        Já o “Modo de Comando Simples” é o mais adequando quando se utiliza um APP dedicado, onde certamente quem fará a Autenticação e o controle efetivo, é uma “Máquina” ou Programa (no caso o próprio APP). Assim, o Cliente não tem que se preocupar com a Autenticação nem precisa conhecer os comandos necessários para o controle do Sistema. A coisa funciona assim: quando a conexão Bluetooth é estabelecida e o Dispositivo implementado (no exemplo, o “BlueLAMP”) está pareado (no ESP32 isto não requer senha), o PCOM Bluetooth enviará um comando simples ao APP requisitando a senha de Autenticação. Então o APP responde enviando a senha, e se estiver correta, o Cliente será incluído na Lista de Clientes Autenticados e poderá acessar e controlar o Sistema. Mas se o Cliente não Autenticar, será enviado uma mensagem (que é considerada um Comando Simples também), avisando ao Cliente do ocorrido. Tudo que ocorre no “Modo de Comando Texto”, ocorre no “Modo Simples”, a única diferença é que os comandos no “Modo Simples” são sequências simples de caracteres ASCII (dificilmente passando de 4 caracteres), o que simplifica o processo de interpretação dos comandos e mensagens por parte do APP dedicado sendo utilizado (enquanto no “Modo Texto” os comandos e mensagens são sequências mais compridas de caracteres ASCII formando frases que são facilmente entendíveis por pessoas).

 

        Normalmente o Modo de Comando a ser utilizado para a Autenticação, é selecionado no início do código sendo executado no ESP32, e permanece o mesmo durante o tempo todo.

        Mas é possível mudar o Modo de Comando para Autenticação, a qualquer momento (ou seja, “on the fly”), caso isto seja desejável, através de uma função da Interface do PCOM que permite especificar qual o Modo de Comando será usado para Autenticação.

 

 

        Além do Comando de Requisição da Senha de Autenticação, o APP tem que interpretar também as mensagens que o PCOM envia indicando as várias ocorrências do Processo de Autenticação, a fim de que o APP possa tomar a decisão do que fazer em cada situação (como por exemplo saber que está autenticado e que pode iniciar o acesso e o Controle do Sistema, ou se não autenticou e terá que tentar novamente depois de aguardar um período de tempo chamado “Intervalo de Autenticação”).

 

        Os comandos/mensagens no Modo de Comando Simples para o Processo de Autenticação Bluetooth, são apenas 5 e estão listadas na tabela mostrada na figura a seguir:

 (clique na figura para "zoom")

        Após estar Autenticado no Sistema, o APP poderá utilizar qualquer método de controle que desejar, pois o PCOM Bluetooth não interfere mais no Processo do Usuário. Isto porque qualquer coisa enviada pelo Cliente Bluetooth será repassada integralmente ao código que está executando o Processo do Usuário, e da mesma forma qualquer coisa que o Processo do Usuário repassar ao PCOM será enviado diretamente para o Cliente Bluetooth sem interferência. Claro, isso tudo enquanto a conexão estiver estabelecida.

        Então após a Autenticação, o Cliente Bluetooth e o Processo do Usuário executando na Placa ESP32, estarão totalmente livres para se entenderem conforme desejarem.

        Lembrando que o PCOM Bluetooth não irá solicitar a senha de Autenticação para um Cliente que já tenha autenticado no Sistema, e portanto a conexão entre este Cliente e o Processo do Usuário executando na Placa ESP32, será imediata assim que o Cliente se conectar.

 

 

        E desde que um Processo qualquer do Usuário deseje, ele pode utilizar apenas o PCOM WiFi ou apenas o PCOM Bluetooth, ou então ambos, e conforme o Gerenciamento do PCOM conecte automaticamente o Sistema via WiFi ou via Bluetooth (qual estiver disponível em um determinado momento).

        E lembrando também que é possível “desativar” e “reativar” qualquer dos PCOMs (inclusive ambos) a qualquer instante que se desejar (“on the fly”).

 

Links para downloads de alguns documentos/arquivos individuais:

 

        Todos os arquivos individuais nos links a seguir, já se encontram no arquivo "Zip" da Bliblioteca PCOM WiFi-Bluetooth,  no link no final da primeira parte do tópico.

        Link para o Documento que mostra como configurar/usar o APPSerial Bluetooth Terminal” :          "config_APP_PCOM_BT_00.pdf"

 

        Link para o Documento que mostra como configurar uma Placa ESP32 para compilar código que usa o PCOM WiFi-Bluetooth:    "config_ESP32_PCOM_WF_BT_00.pdf"

 

        Para aqueles que querem analisar como é o funcionamento interno do PCOM WiFi-Bluetooth, aconselho configurar de forma mais adequada a IDE do Arduino.

        Este documento mostra a configuração da IDE:    "config_IDE_Arduino_00.pdf"

 

        Os Diagramas de Estados do PCOM WiFi-Bluetooth, estão inclusos junto à Biblioteca, mas o mesmo documento está neste link:    "PCOM_WiFi_Bluetooth_01 - Diagramas.pdf"

 

        O código de exemplo de controle da Lâmpada, via PCOM WiFi-Bluetooth está também incluso na Biblioteca, e também neste link:    "ESP32_WiFi_Bluetooth_Lampada_01.zip"

 

        E finalmente, a própria Biblioteca do PCOM WiFi-Bluetooth, está disponível neste link, que já foi publicado na primeira parte do tópico:    "PCOM WiFi-Bluetooth ESP32/Arduino"

 

        Em breve novos exemplos usando o PCOM WiFi-Bluetooth serão aqui publicados.

Abrçs,

Elcids

Boa noite Elcids , Agradeço muito pelo esforço em nos ajudar e resolver nossas duvida aqui no LBG, ficou muito 10 esses projetos das duas interface wifi e bluetooth rodando juntos, só vc mesmo com suas ideias e sabedoria para nos ajudar valeu mesmo muito obrigada, estou fazendo um apk para android para rodar junto com o código, já posto ele aqui  

olá Marcela.

      Ficou legal a implementação do seu APP. Vi que vc usou a base de código do APP que vc já tinha desenvolvido anteriormente, o que é uma ótima notícia.

      Espero que tenha ficado satisfeita com a Autenticação Bluetooth que implementei no Sistema. Lembre-se que vc pode distribuir seu APP e a respectiva senha de Autenticação para as pessoas de sua confiança, pois o PCOM Bluetooth mantém uma Lista de Clientes Autenticados, a qual é não-volátil (ela pode ser apagada, e em breve mostrarei como fazer isso).

      Apenas tive como curiosidade em saber qual método de Comando de Autenticação vc usou para o Bluetooth. Foi o Método de "Comando Simples" (que seria o mais adequado para o seu caso, já que vc desenvolve seus próprios APPs), ou foi o Método de "Comando Texto" (que é o indicado para APPs de Terminais ou semelhantes, mas que pode ser usado também em APPs dedicados) ?

      Abrçs,

      Elcids

Bom dia Elcids, a respeito da Autenticação Bluetooth ,instalei o APP “Serial Bluetooth Terminal para Autenticar o Bluetooth e depois desinstalei o App Serial Bluetooth Terminal e comecei a usar o meu App ESP32_BT_WIFI_Marcela.apk

Marcela,

      Sua solução foi realmente genial.  Em nenhum momento pensei nesta possibilidade de Autenticar com o APP de Terminal, e depois usar o APP dedicado.

      Mas claro,  pretendo mostrar como se faz a Autenticação no modo de "Comando Simples", o que permite mais liberdade a quem desenvolver seus APPs  interfaceando com o PCOM Bluetooth.

      Abrçs,

      Elcids

Boa noite Elcids, como seria para adicionar mais pinos gpio?

sim Marcela.

      O  PCOM WiFi / Bluetooth  não depende dos pinos de I/O do ESP32.

      Isto significa que vc pode usar quaisquer pinos do ESP32 que desejar (desde que estejam disponíveis para uso na sua placa ESP32).  Também pode-se usar quaisquer canais Analógicos do ESP32 que estejam disponíveis na sua placa.

      Vc pode também facilmente usar os I/O daquelas plaquinhas de Interface I2C,  o que torna bastante versátil e simples acrescentar uma grande quantidade de I/Os.   E pode-se também usar qualquer tipo de Expansor de I/O, sejam Digitais ou Analógicos (em breve também publicarei um tópico relacionado a isso, e a forma adequada de fazer os acessos).

      Mas eu acredito que sua dúvida está em como fazer isso.

      A princípio eu diria a vc para seguir exatamente o mesmo modelo  que está no exemplo inicial que publiquei, apenas estendendo aquele modelo para tratar mais I/Os.  Mas caso vc tenha dificuldades em fazer isso,  peço que aguarde um pouco, que irei publicar mais exemplos, e darei prioridade para atender sua necessidade.

      Abrçs,

      Elcids

olá Marcela.

       A algum tempo atrás vc me questionou sobre a utilização do PCOM WiFi-Bluetooth, para acionamentos de diversos I/Os. Naquele momento respondi que sim, que era possível, e que bastava seguir a mesma receita que foi usada no exemplo que publiquei.

      Assim, volto aqui para verificar se vc conseguiu implementar da forma que vc precisava.

      Mas minha volta ao tópico é também para dar continuidade ao "Projeto", divulgando e expandindo seus recursos, e também iniciar a publicação de mais exemplos para demonstrar as possibilidades do uso do PCOM WiFi-Bluetooth.

      Minha intenção é tentar publicar um exemplo a cada semana, inclusive demonstrando a utilização do PCOM WiFi-Bluetooth  com uma enormidade de I/Os diferentes (entenda-se "periféricos", como sensores, motores, displays, etc), e entre os primeiros exemplos estará a situação que vc me perguntou sobre diversos I/Os simultaneamente. Também estarei aberto para sugestões de exemplos (ou mesmo Projetos completos) de quem estiver acompanhando o tópico aqui no LDG.

      Para a interface com o usuário, irei também utilizar o App-Inventor (que vc também utilizou na sua implementação),  por ser popular em termos de programação.  Para isso irei desenvolver no App-Inventor, uma estrutura básica ou "core" para suporte a diversos Projetos usando o PCOM WiFi-Bluetooth.  Este "core" no App-Inventor, permitirá uma robustez em termos de confiabilidade, e também diminuirá em muito o tempo de desenvolvimento dos APPs já que todos usarão o mesmo "core".

      Este "core"  já fará também a Autenticação automática quando se utiliza o Bluetooth,  o que simplificará em muito o trabalho de quem for desenvolver seu APP personalizado. Sei que esta questão da Autenticação, apesar de muito importante (por motivos de segurança), era também uma dificuldade até aqui, pois o pessoal não está acostumado a implementar a lógica necessária para este processo (além de tomar tempo de desenvolvimento e testes). Além disso, uma Autenticação efetiva, exige uma comunicação Máquina/Máquina, o que foi previsto no PCOM WiFi-Bluetooth desde o início através do "Modo de Comando Simples" (ao invés do "Modo de Comando Texto", quando se usa uma comunicação Homem/Máquina, a qual foi usada no primeiro exemplo publicado através de um APP de Terminal Serial Bluetooth).

      E para o WiFi pode-se usar um componente WebViewer do App-Inventor ou simplesmente um componente "Web". Então irei mostrar o uso do PCOM WiFi-Bluetooth com ambos os componentes do App-Inventor.

      Claro, quando falamos do App-Inventor, pode-se estender tudo para o "Kodular" que também é amplamente utilizado mundo afora. E isto vale também para diversos similares que "encapsulam" o App-Inventor.

      Assim, fique de olho aqui, pois o segundo exemplo estarei publicando na próxima semana, já com o desenvolvimento de um APP para a Interface de Controle  usando o App-Inventor.

      Abrçs,

      Elcids

bom dia Elcids , nao consegui aumentar, mais pinos para acionar estou usando so um mesmo para para acionar meu portao via wifi ou bluetooth, se vc da um exemplo como aumentar pinos nesse codigo eu agradeço, arrespeito do app que vc esta emprementando vai fica muito show com autenticaçao, fico no aguardo esperando para mim testar, valeu por nos ajudar 

Ok então Marcela.

      No segundo exemplo, irei apresentar o "core" para se usar o PCOM WiFi-Bluetooth através do App-Inventor, e já no terceiro exemplo irei mostrar como aumentar "indefinidamente" para quaisquer quantidades de I/Os que se deseje (de 1 a uma centena ou mais).

      Abrçs,

      Elcids

olá Marcela.

      Planejei  vários exemplos,  tentando cobrir  uma gama de controles que  sejam de referência para  os mais diversos dispositivos possíveis (Digitais e Analógicos, inclusive combinados).

      Mas se vc puder informar quais são os dispositivos que vc  precisa controlar ou monitorar,  posso fazer também um exemplo adicional,  mais dedicado e próximo ao que vc precisa.  Neste caso, não esqueça de informar como vc usa cada dispositivo no seu Sistema.

      Abrçs,

      Elcids

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço