paddy firmware

Paddy -Firmware

Dies ist die Firmware -Komponente für Paddy, den Power Administration Dämon.

Es verwendet Arduino C ++ und richtet sich an einer Zustandsmaschine. Es wird direkt auf einem unterstützten Chip blitzt. Der für dieses Projekt verwendete Arduino -Typ ist ein IoT -Nano 33.

Die Aufgabe dieses Codes besteht darin, über Wi-Fi oder die Paddy-App über Bluetooth Low Energy mit dem Paddy MQTT-Broker für die Einrichtung und Fehlerbehandlung mitzuarbeiten. Der Code sollte auch die Hardware steuern, die ausgeführt wird:

1. Ein/Aus -Umschaltung des Lastgeräts
2. Leistungsmessung für das Lastgerät mit periodischer Statistik.

Zustandsmaschinendiagramm

Überblick

Der Code dieser Staatsmaschine ist mit Singleton -Komponenten organisiert, die einmal in der Firmware instanziiert und während des gesamten Lebenszyklus des Programms wiederverwendet werden. Diese Module sind wie folgt:

• BLE: Griff direkte Kommunikation zwischen dem Daemon und dem zentralen Gerät.
• Steuerung: Schalten Sie das Lastgerät je nach dem zu diesem Zeitpunkt empfangenen Befehl ein oder aus.
• MQTT: Übernimmt die gesamte Kommunikation mit dem Broker und Delegierte arbeiten an andere Komponenten oder Zustände zum Abrufen von Nachrichten.
• Leistung: Steuerelemente und kalibriert den Strommessstromtransformator. Macht regelmäßige Lesungen.
• Speicherung: emuliert einen EEPROM -Chip aufgrund des gewählten Arduino IoT Nano 33, der kein tatsächliches EEPROM hat. Speichert die notwendigen Anmeldeinformationen.
• Wi-Fi: Griff Wi-Fi-Verbindungen und Signalstärkemessung.

Da jeder Staat eine vordefinierte Pflicht hat, ist es leicht zu verstehen, was jedes Stück des Flusses tut:

• Boot -Status: Dies ist der Anfangszustand, in den der Mikrocontroller eingeht, sobald er aufstieg. Hier werden Hardwareprüfungen durchgeführt, insbesondere das Wi-Fi-Modul und das Bluetooth Low Energy-Modul. Wenn diese Überprüfungen erfolgreich sind und der Daemon die oben genannten Komponenten initialisieren kann, bewegt er sich in den Init -Zustand. Andernfalls wird auf kaputt gezogen, dort anhalten und eine LED blinkt, die einen Hardwarefehler für den Benutzer angibt.
• Init -Zustand: Der Init -Zustand ist der erste Zwischenstaat, in den der Daemon eintritt. Sein Zweck ist es, das Gerät für die richtige Funktion vorzubereiten, indem er zunächst das Leistungsmessmodul durch Radfahren ein paar Mal kalibriert, wodurch die Gerätewerte an den Linienstrom gewöhnt werden. Anschließend wird verifiziert, ob der Daemon alle in seinem emulierten EEPROM gespeicherten Anmeldeinformationen enthält oder nicht. Der Daemon bewegt sich mit diesen Anmeldeinformationen in den Verbindungsstatus, wenn ersterer wahr ist, andernfalls wird die Setup -Phase eingegeben.
• Setup -Status: Mit seinem Blockierungsverhalten wird dieser Zustand erst fortschreitet, wenn die Benutzeraktion durchgeführt wird. Da der Daemon hier keine Anmeldeinformationen enthält, hat es keine Ahnung, wie man eine Verbindung zum Wi-Fi oder Broker herstellt. Dies bedeutet, dass der Daemon in diesem Stadium Wi-Fi für Datenübertragungen nicht verwenden kann und einen direkten Ansatz benötigt. Ble ist perfekt für dieses Szenario, da das Schreiben und Lesen von Eigenschaften aus der Paddy -App leicht erreichbar ist. Daher werden die BLE -Funktionen des Geräts verwendet, um diese Eigenschaften auszugeben:

• Seriell (schreibgeschützt): Ein Merkmal, das die serielle Anzahl des Geräts abgibt.
• SSID (Schreibeinform): Der Service-Set-Kennung für das Wi-Fi-Netzwerk.
• Passwort (nur Schreiben): Das Passwort des Wi-Fi-Zugriffspunkts.
• Enterprise Benutzername (nur Schreiben): Wenn das Wi-Fi Enterprise-Authentifizierungstechniken wie EAP oder PEAP erfordert, den Benutzernamen für den Benutzer.
• Enterprise-Passwort (nur Schreibschreiber): Wenn das Wi-Fi Enterprise-Authentifizierungstechniken wie EAP oder PEAP erfordert, das Passwort für den Benutzer.
• JWT (Schreibschreiber): Das vom Dämon verwendete JSON-Web-Token, das sich mit dem Broker verbindet.
• Zurücksetzen (nur Schreiben): Wenn dieses Merkmal geschrieben wird, setzt der Daemon seine Anmeldeinformationen zurück.

Um fortzufahren, müssen die Merkmale von JWT und Anmeldeinformationen vom mobilen Gerät des Benutzers über die Paddy -App geschrieben werden. Es muss beachtet werden, dass die Firmware diese Phase zum Einfachheit halber als abgeschlossenes Schreiben in die SSID -Eigenschaften erkennt. Als solche können Schreibvorgänge in jeder Reihenfolge auftreten, mit Ausnahme des SSID, der so geschrieben werden muss, dass vorhersehbares Verhalten erreicht wird. Um zwischen den Autorisierungsmodi zu erkennen, ergeben unterschiedliche Kombinationen von schriftlichen Merkmalen drei Konfigurationen, wenn es um die Wi-Fi-Autorisierung geht: unsicher (nur SSID), sicher (SSID + Passwort) und Enterprise (SSID + Enterprise Benutzername + Enterprise-Passwort).

• Verbindungsstatus: Dieser Zustand ist relativ einfach, da er nur läuft, während der Daemon mit dem Backend -Broker eine Verbindung herstellt. Bei Verbindungserfolg übergibt es den Staat dem Online -Einsatz und zum Backoff -Backoff bei Misserfolg.
• Online -Status: Der „funktionierende“ Zustand des Daemons ist ein voll funktionsfähiges Pad. Hier kann es mit dem Broker interagieren, indem MQTT -Nachrichten empfangen und sie gesendet werden. Der Daemon hat ein paar Aufgaben, während es in diesem Zustand ist:

• Hören Sie sich MQTT -Nachrichten an, nämlich auf die Themen ein, aus, ausgeschaltet, zurücksetzen und drehen. Wenn eine dieser Nachrichten empfangen wird, führt sie die richtige Aktion aus.
• Senden Sie Keep-Alive Ping-Nachrichten an den Broker. Diese Botschaften dienen rein statistische Zwecke und sind nicht erforderlich, um die Verbindung tatsächlich am Leben zu erhalten. Sie werden nur verwendet, um den Status des Daemons von der App zu verfolgen. Bei der Nutzlast dieser Nachrichten wird die Wi-Fi-Signalstärke weitergeleitet.
• Leiten Sie regelmäßig Stromverbrauchsdaten an den Broker weiter.
• Überprüfen Sie, ob das Gerät weiterhin mit dem Broker verbunden ist. Wenn das Gerät nicht mehr angeschlossen ist, gehen Sie zu Backoff.

• Backoff -Status: Während dieser Zustand als Polsterung vor den Verbindungen des Daemons dient, ist er auch ein Fenster, mit dem der Benutzer den Daemon durch eine direkte Verbindung zurücksetzen kann. In Fällen, in denen der Daemon von einem Ort mit einer anderen Wi-Fi-Verbindung bewegt wird, hat er beispielsweise bereits Anmeldeinformationen, aber sie sind falsch. Wenn der Daemon den Backoff-Status erreicht, wird ein 60-Sekunden-Fenster geöffnet, in dem der Benutzer ihn direkt durch BLE zurücksetzen kann. Wenn der 60-Sekunden-Zähler jedoch ausgeht, wird der Daemon erneut eine Verbindung zum Server herstellen, indem sie zum Verbindungsstatus wechselt.

Schaltbild