esp_alox/readme.md

# UART Protokoll

## Struktur einer Nachricht

    0xAA = Startbyte  
    checksum = XOR über alle Bytes (ohne Startbyte und Checksum-Byte)

## Nachrichtenaufbau (Message Frame)

[ Startbyte ] [ Length ] [ CommandPage ] [ Payload (variabel) ] [ Checksum ]

### Felder im Detail:

- **Length** (`uint8_t`):  
  Gibt die Gesamtlänge der Nachricht **ab `CommandPage` bis einschließlich `Payload`** an.  

- **CommandPage** (`uint8_t`):  
  Gibt an, welcher Nachrichtentyp oder Befehl gesendet wird.

- **Payload** (`variabel`):  
  Datenfeld mit variabler Länge, abhängig vom `CommandPage`.

- **Checksum** (`uint8_t`):  
  XOR über alle Bytes ab `Length` bis einschließlich `Payload`.  

---

# Roadmap 
- [ ] SEND STATUS OF DEVICE OVER UART
- [ ] CONFIGURE PEERS OVER MASTER
- [ ] SAVE PIN CONFIG ON PEERS

# Machbarkeits-Studie

## 1.0 Hardware-Features

### 1.1 Hardware-Aufbau
Anforderung
Es soll eine Hardware von 20 Modulen bereitgestellt werden, welche als Basis der
grundlegenden Software-Features dient. Dabei liegt der Fokus auf der Verarbeitung von
Wifi-Nachrichten und weniger auf deren Hardware-technischen Umsetzung.
Lösungsansatz
Die Hardware besteht aus 20 ESP32-Modulen (1x Koordinator und 19 Peers) und der
entsprechenden Energieversorgung: 20x Stecker-Netzteil + USB-Leitungen
Abnahme-Kriterium
Alle Peers sind so mit Energie zu versorgen, dass sie sich in einem Radius von ca. 15m um
den versorgten Koordinator befinden.
Dokumentation
Es wird per Liste festgehalten, welches ESP32-Board benutzt wird und ob Modifikationen
bei der Spannungsversorgung (bspw. Elko an 3.3V) vorgenommen wurden.

## 2.0 Software-Features

### 2.1 Netzwerk-Aufbau
Anforderung
Das Netzwerk soll sich nach einem Power-On selbständig aufbauen und eine Teilnehmer-
Liste nach abgeschlossener Initialisierung bereitstellen.
Lösungsansatz
Der Koordinator erstellt ein MAC-Netzwerk und fügt die Peers in das Netzwerk hinzu.
Zusätzlich erstellt der Koordinator eine Liste von MAC-Adressen der Peers.
Abnahme-Kriterium
Dieses Feature wird per Systemtest verifiziert. Der Test startet den Netzwerk-Aufbau auf
dem Koordinator per Terminal-Kommando und gibt nach 5 Minuten die MAC-Adressen-
Liste zurück.
Dokumentation
Der Netzwerk-Aufbau wird per Ablauf-Diagramm dokumentiert.

### 2.2 PingPong-Feature
Anforderung
Nach dem Netzwerk-Aufbau soll jeder Peer durch den Koordinator ein Ping erhalten,
welchen dieser umgehend mit einem Pong (bzw. mit seiner Firmware-Version)
beantwortet. Sollte ein Teilnehmer auf die Anfrage nicht reagieren, soll die Anfrage sofort
wiederholt werden. Die benötigte Zeit und die Anzahl der Wiederholungen soll erfasst
werden.
ALOX Labs UG Lastenheft Pflichtenheft PowerPods 4
Lösungsansatz
Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl und
erwartet die Pong-Antwort (Firmware-Version) des jeweiligen Peers. Sollte ein Teilnehmer
nicht antworten wird die Nachricht nach 10ms wiederholt – maximale Wiederholung: 5x.
Die Zeit (Start: vor der Sendung – Stopp: nach dem Empfang) wird im Koordinator erfasst.
Abnahme-Kriterium
Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature mit
einer erwarteten Firmware-Version und bekommt als Resultat eine Liste mit dem Status
der Firmware, der Dauer und den benötigten Versuchen pro Peer zurück.
Dokumentation
Das PingPong-Feature wird per Ablauf-Diagramm dokumentiert.

### 2.3 PingPong-Feature im definierten Raster
Anforderung
Es soll sichergestellt werden, dass die Dauer der Peer-Abfrage immer im gleichen zeitlichen
Raster stattfindet. Dies soll unabhängig von den Teilnehmern des Netzwerks sein und sich
an der Maximalen Anzahl der Teilnehmer richten. Dadurch soll sichergestellt werden, dass
die Performance bei 5 Teilnehmern sich genauso verhält wie bei 19 Teilnehmern.
Lösungsansatz
Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl in
einem vor-definierten zeitlichen Raster. Das Raster richtet sich an die in Pos. 2.2
gemachten Ergebnisse, wo die maximale Dauer einen PingPongs bestimmt wird.
Die menschl. Reaktionszeit beträgt ca. 250ms. Die maximale Abfrage-Zeit sollte unterhalb
von 200ms (bestenfalls bei 125ms) liegen um ein flüssigen Spielablauf zu gewährleisten.
- 19 Teilnehmer mit 125ms: 5ms Raster + 3 Wiederholungen (5ms + 5ms)
- 19 Teilnehmer mit 200ms: 8ms Raster + 3 Wiederholungen (8ms + 8ms)
Abnahme-Kriterium
Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature im
vor-definierten Raster und bekommt als Resultat eine Liste mit der jeweiligen Dauer, den
benötigten Versuchen und einer Rückmeldung, ob das Raster eingehalten wurde zurück.
Dokumentation
Das PingPong-Feature im definierten Raster wird per Ablauf-Diagramm dokumentiert

### 2.4 Broadcast-Message
Anforderung
Der Koordinator soll nicht nur die Peers einzeln per MAC-Adresse, sondern auch per
globaler Nachricht direkt an alle Peers eine Nachricht versenden können.
Lösungsansatz
Durch eine spezielle Nachricht, die an alle Peers gerichtet ist, können Nachrichten per
Broadcast vom Koordinator an alle Peers versendet werden. Eine Rückmeldung der Peers
wird nicht erwartet.
ALOX Labs UG Lastenheft Pflichtenheft PowerPods 5
Hinweis
Der erfolgreiche Abschluss der Machbarkeitsstudie soll mit den aufgeführten Punkten erreicht werden.
Nach dem Abschluss soll der Status soweit sein, um mit der Produkt-Entwicklung starten zu können.
Im Rahmen der Entwicklung wird (wenn nicht anders im Unterpunkt beschrieben) immer davon
ausgegangen, dass Funktionen und Übertragungen korrekt funktionieren – sprich, es wird der Gut-Fall
abgedeckt. Sollten trotz dieser Erwartung Fehler während oder nach der Inbetriebnahme stattfinden,
werden diese nachträglich behoben.
Abnahme-Kriterium
Die Broadcast-Message wird über einen Systemtest verifiziert. Dabei wird der Test per
Terminal-Kommando gestartet und an alle Peers eine globale Nachricht mit einem Wert
gesendet. Diesen Wert fragt der Koordinator per modifiziertem PingPong (Wert statt
Firmware-Version) im zweiten Schritt ab.
Dokumentation
Der Systemtest zur Broadcast-Nachricht wird per Ablauf-Diagramm dokumentiert.

### 2.5 OTA-Update
Anforderung
Die Peers sollen vom Koordinator eine neue Firmware per Funk übertragen bekommen, so
dass eine händische Programmierung der Module nicht notwendig ist.
Lösungsansatz
Der Koordinator prüft nach jedem Neustart des Netzwerks, ob die Teilnehmer die korrekte
Firmware besitzen. Wenn dies nicht der Fall ist, wird die aktuelle Firmware übertragen.
Abnahme-Kriterium
Das OTA-Update wird über einen Systemtest verifiziert. Dabei wird der Test per Terminal-
Kommando gestartet und an alle Peers die neue Firmware übertragen. Mit einem
nachträglichen PingPong wird im zweiten Schritt die neue Version der Peers abgefragt.
Dokumentation
Der Integrationstest zum OTA-Update wird per Ablauf-Diagramm dokumentiert.

## 3.0 Abschlussbericht

### 3.1 Nach erfolgreicher Implementierung der beschriebenen Features soll ein
aussagekräftiger Abschlussbericht erstellt werden. Darin sollen die gemachten Ergebnisse
und Erkenntnisse kurz dargestellt werden. Dieser Bericht dient dann als Grundlage für
das Lasten- und Pflichtenheft der Produktentwicklung und gibt einen Ausblick, ob sich die
techn. Anforderungen hinreichend gut umsetzen lassen.

### 3.2 Eine tabellarische Auflistung, welche der aufgeführten Features wie umgesetzt wurden
und ob diese den ursprünglichen Anforderungen entsprechen.