paddy firmware

Firmware Paddy

Este é o componente de firmware para Paddy, o daemon da Administração de Power.

Ele usa o Arduino C ++ e foi projetado em torno de uma máquina de estado. É exibido diretamente em um chip suportado. O tipo Arduino usado para este projeto é um Nano 33 da IoT.

O trabalho deste código é interagir com o corretor Paddy MQTT através do Wi-Fi, ou o aplicativo Paddy através da Bluetooth Low Energy, para configuração e manuseio de erros. O código também deve controlar o hardware que executa:

1. Ligando/desligando o dispositivo de carga
2. Medição de energia para o dispositivo de carga, com o envio estatístico periódico.

Diagrama de máquinas de estado

Visão geral

O código dessa máquina de estado é organizado com componentes singleton que são instanciados uma vez no firmware e reutilizados durante todo o ciclo de vida do programa. Esses módulos são os seguintes:

• BLE: lida com a comunicação direta entre o daemon e o dispositivo central.
• Controle: Ligue ou desative o dispositivo de carga, dependendo do comando recebido no momento.
• MQTT: lida com toda a comunicação com o corretor e os delegados trabalham com outros componentes ou estados na recuperação de mensagens.
• Poder: controla e calibra o transformador de corrente de medição de energia. Faz leituras periódicas.
• Armazenamento: Emula um chip EEPROM devido ao Nano 33 escolhido em IoT 33 não possui uma EEPROM real. Armazena as credenciais necessárias nele.
• Wi-Fi: lida com conexões Wi-Fi e medição de força de sinal.

Com cada estado tendo um dever predefinido, é fácil entender o que cada parte do fluxo faz:

• Estado de inicialização: este é o estado inicial em que o microcontrolador entra assim que ele inicializar. As verificações de hardware são realizadas aqui, especificamente o módulo Wi-Fi e o módulo de baixa energia Bluetooth. Se essas verificações forem bem -sucedidas e o daemon poderá inicializar os componentes acima mencionados, ele se move para o estado init. Caso contrário, ele passa para quebrado, parando por lá e exibindo um LED indicando um erro de hardware para o usuário.
• Estado init: O estado init é o primeiro estado intermediário que o daemon entra. Seu objetivo é preparar o dispositivo para a função adequada, calibrando primeiro o módulo de medição de energia, pedalando -o algumas vezes, acostumando as leituras do dispositivo na corrente da linha. Posteriormente, é verificado se o daemon contém alguma credenciais armazenados em sua EEPROM emulada ou não. O daemon passa para o estado de conexão com as referidas credenciais se o primeiro for verdadeiro, caso contrário, a fase de configuração será inserida.
• Estado de configuração: com seu comportamento de bloqueio, esse estado não progredirá até que a ação do usuário seja realizada. Como o daemon não contém credenciais aqui, não tem idéia de como se conectar ao Wi-Fi ou corretor. Isso significa que, nesta fase, o daemon não pode usar o Wi-Fi para transferências de dados e precisa de uma abordagem direta. O BLE é perfeito para esse cenário, pois escrever e ler as características são facilmente alcançáveis no aplicativo Paddy. Portanto, as capacidades BLE do dispositivo são usadas para emitir essas características:

• Serial (somente leitura): uma característica que emite o número de série do dispositivo.
• SSID (somente de gravação): o identificador do conjunto de serviços para a rede Wi-Fi.
• Senha (somente de gravação): a senha do ponto de acesso Wi-Fi.
• Nome de usuário Enterprise (somente gravação): Se o Wi-Fi exigir técnicas de autenticação corporativa como EAP ou PEAP, o nome de usuário para o usuário.
• Senha corporativa (somente gravação): se o Wi-Fi exigir técnicas de autenticação corporativa, como EAP ou PEAP, a senha do usuário.
• JWT (somente de gravação): O Token da Web JSON usado pelo Daemon para se conectar ao corretor.
• Reset (somente gravação): Quando essa característica é gravada, o daemon redefine suas credenciais.

Para prosseguir, o JWT e as características de credenciais devem ser gravadas pelo dispositivo móvel do usuário através do aplicativo Paddy. Deve -se notar que, por simplicidade, o firmware detecta esse estágio como concluído apenas escrevendo para as características do SSID. Como tal, as gravações podem ocorrer em qualquer ordem, exceto para a SSID, que deve ser escrita para durar o comportamento previsível a ser alcançado. Para discernir entre os modos de autorização, diferentes combinações de características escritas produzem três configurações quando se trata de autorização Wi-Fi: insegura (somente SSID), Secure (SSID + Senha) e Enterprise (SSID + Enterprise UserName + Segunda Senha).

• Estado de conexão: esse estado é relativamente simples, pois só funciona enquanto o daemon está se conectando ao corretor de back -end. No sucesso da conexão, ele entrega o estado ao on -line e, para fazer o fracasso.
• Estado on -line: o estado "funcionando" do daemon, isso representa um bloco totalmente funcional. Aqui ele pode interagir com o corretor recebendo mensagens MQTT e enviando -as. O daemon tem alguns deveres enquanto está neste estado:

• Ouça as mensagens MQTT, a saber, on, off, redefinir e girar tópicos. Quando uma dessas mensagens é recebida, ele executa adequadamente a ação certa.
• Envie mensagens de ping de keep-alive para o corretor. Essas mensagens são puramente para fins estatísticos e são desnecessários para realmente manter a conexão viva; Eles são apenas usados para acompanhar o status do Daemon no aplicativo. Na carga útil dessas mensagens, a força do sinal Wi-Fi é transmitida.
• Retransmitir os dados de uso de energia periodicamente para o corretor.
• Verifique se o dispositivo ainda está conectado ao corretor. Se o dispositivo não estiver mais conectado, vá para o retirada.

• Estado de retirada: Embora esse estado sirva como um preenchimento antes do Daemon Executive Connections, também é uma janela para o usuário redefinir o daemon através de uma conexão direta BLE. Por exemplo, nos casos em que o daemon é movido de um local com outra conexão Wi-Fi, ele já possui credenciais, mas está incorreto. Como tal, quando o daemon chega ao estado de retirada, ele abre uma janela de 60 segundos na qual o usuário pode redefini-lo diretamente BLE. No entanto, se o contador de 60 segundos acabar, o daemon voltará a se conectar ao servidor, movendo-se para o estado de conexão.

Diagrama de circuito