paddy firmware

Firmware de arroz

Este es el componente de firmware para Paddy, el Daemon de administración de energía.

Utiliza Arduino C ++ y está diseñado alrededor de una máquina de estado. Se muestra directamente en un chip admitido. El tipo Arduino utilizado para este proyecto es un IoT Nano 33.

El trabajo de este código es interactuar con el corredor Paddy MQTT a través de Wi-Fi, o la aplicación Paddy a través de Bluetooth Low Energy, para el manejo de la configuración y los errores. El código también debe controlar el hardware que realiza:

1. Encendido/apagado del dispositivo de carga
2. Medición de potencia para el dispositivo de carga, con envío estadístico periódico.

Diagrama de máquinas de estado

Descripción general

El código de esta máquina de estado está organizado con componentes singleton que se instancian una vez en el firmware y se reutilizan durante todo el ciclo de vida del programa. Estos módulos son los siguientes:

• BLE: Maneja la comunicación directa entre el demonio y el dispositivo central.
• Control: enciende o apaga el dispositivo de carga dependiendo del comando recibido en el momento.
• MQTT: Maneja toda la comunicación con el corredor y los delegados trabajan a otros componentes o estados en la recuperación de mensajes.
• Potencia: controla y calibra el transformador de corriente de medición de potencia. Hace lecturas periódicas.
• Almacenamiento: emula un chip EEPROM debido al elegido Arduino IoT Nano 33 no tiene un EEPROM real. Almacena las credenciales necesarias en él.
• Wi-Fi: maneja las conexiones Wi-Fi y la medición de la resistencia a la señal.

Con cada estado que tiene un deber predefinido, es fácil entender lo que hace cada pieza del flujo:

• Estado de arranque: este es el estado inicial en el que entra el microcontrolador tan pronto como se arranca. Aquí se realizan verificaciones de hardware, específicamente el módulo Wi-Fi y el módulo de baja energía Bluetooth. Si estas verificaciones tienen éxito y el demonio puede inicializar los componentes mencionados anteriormente, entonces se mueve al estado init. De lo contrario, se mueve hacia roto, deteniendo y parpadeando un LED que indica un error de hardware para el usuario.
• Estado Init: El estado init es el primer estado intermedio en el que entra el demonio. Su propósito es preparar el dispositivo para una función adecuada, calibrando en primer lugar el módulo de medición de potencia al ciclarlo varias veces, acostumbrando a las lecturas del dispositivo a la corriente de línea. Posteriormente, se verifica si el demonio contiene alguna credencial almacenada en su EEPROM emulado o no. El demonio se mueve al estado de conexión con dichas credenciales si el primero es verdadero, de lo contrario se ingresa la fase de configuración.
• Estado de configuración: con su comportamiento de bloqueo, este estado no progresará hasta que se realice la acción del usuario. Dado que el demonio no contiene ninguna credencial aquí, no tiene idea de cómo conectarse al Wi-Fi o al corredor. Esto significa que en esta etapa, el demonio no puede usar Wi-Fi para transferencias de datos y necesita un enfoque directo. BLE es perfecto para este escenario, ya que escribir y leer las características se pueden lograr fácilmente de la aplicación Paddy. Por lo tanto, las capacidades BLE del dispositivo se utilizan para emitir estas características:

• Serial (de solo lectura): una característica que emite el número de serie del dispositivo.
• SSID (solo escritura): el identificador del conjunto de servicios para la red Wi-Fi.
• Contraseña (solo escritura): la contraseña del punto de acceso Wi-Fi.
• Nombre de usuario empresarial (solo escritura): si el Wi-Fi requiere técnicas de autenticación empresarial como EAP o PEAP, el nombre de usuario para el usuario.
• Contraseña empresarial (solo escritura): si el Wi-Fi requiere técnicas de autenticación empresarial como EAP o PEAP, la contraseña para el usuario.
• JWT (solo escritura): el token web JSON utilizado por el demonio para conectarse al corredor.
• Restablecer (solo escribir): cuando se escribe esta característica, el demonio restablece sus credenciales.

Para continuar, el dispositivo móvil del usuario debe escribir las características de JWT y credenciales a través de la aplicación Paddy. Cabe señalar que, por simplicidad, el firmware detecta esta etapa como una escritura solo completa para las características SSID. Como tal, las escrituras pueden ocurrir en cualquier orden, excepto el SSID, que debe escribirse para durar el comportamiento predecible que se logra. Para discernir entre los modos de autorización, diferentes combinaciones de características escritas producen tres configuraciones cuando se trata de autorización Wi-Fi: inseguro (solo SSID), seguro (SSID + contraseña) y Enterprise (SSID + Enterprise UserName + Enterprise Password).

• Estado de conexión: este estado es relativamente simple, ya que solo se ejecuta mientras el demonio se conecta al corredor de backend. Sobre el éxito de la conexión, entrega el estado al en línea y al retroceso al fracaso.
• Estado en línea: el estado de "trabajo" del demonio, esto representa una almohadilla totalmente funcional. Aquí puede interactuar con el corredor recibiendo mensajes MQTT y enviándolos. El demonio tiene algunas tareas mientras está en este estado:

• Escuche los mensajes MQTT, a saber, en los temas ON, OFF, RESET y Rotar. Cuando se recibe uno de estos mensajes, realiza adecuadamente la acción correcta.
• Enviar mensajes de ping de Keep-Alive al corredor. Estos mensajes son puramente para fines estadísticos y son innecesarios para mantener viva la conexión; Simplemente se usan para realizar un seguimiento del estado del demonio desde la aplicación. En la carga útil de estos mensajes, se transmite la intensidad de la señal Wi-Fi.
• Periódicamente de transmisión de datos de uso de energía al corredor.
• Compruebe si el dispositivo todavía está conectado al corredor. Si el dispositivo ya no está conectado, vaya a retroceso.

• Estado de retroceso: si bien este estado sirve como un acolchado antes de que el demonio reemplace las conexiones, también es una ventana para que el usuario restablezca el demonio a través de una conexión directa BLE. Por ejemplo, en los casos en que el demonio se mueve de un lugar con otra conexión Wi-Fi, ya tiene credenciales, pero son incorrectos. Como tal, cuando el demonio alcanza el estado de retroceso, abre una ventana de 60 segundos en la que el usuario puede restablecerlo a través de BLE directamente. Sin embargo, si el contador de 60 segundos se agota, el demonio volverá a intentar conectarse al servidor nuevamente moviéndose al estado de conexión.

Diagrama de circuito