Ein einzelner ESP32 ist einfach. Eine Flotte nicht.

Das ist die Lektion, die wir beim Aufbau von NestGrow gelernt haben — einem edge-verteilten IoT-Bewässerungssteuerungssystem, das in Gewächshausumgebungen mit Dutzenden von ESP32-Knoten pro Installation eingesetzt wird. In dem Moment, in dem man über eine Handvoll Geräte hinaus skaliert, hört das Engineering-Problem auf, Hardware zu sein, und wird zu Flottenverhalten unter Ausfallbedingungen.

Dieser Artikel dokumentiert die Architektur, die Ausfallmodi, auf die wir gestoßen sind, und die Designprinzipien, die ein System wirklich produktionsreif machen — nicht nur “funktioniert auf meinem Tisch”.

Das eigentliche Problem: Flotten, nicht Geräte

Sobald man über wenige Knoten hinaus skaliert, entstehen drei Probleme, die Einzelgeräte-Denken nicht lösen kann:

• Nachrichtenzuverlässigkeit bei instabilen Netzwerken — MQTT-Nachrichten gehen verloren, werden dupliziert oder verzögert
• Firmware-Konsistenz über heterogene Knoten hinweg — Versionsabweichungen sind still und gefährlich
• Partielle Ausfallzustände — ein Gerät, das weder vollständig online noch vollständig offline ist, ist der schwierigste Fall

Der entscheidende konzeptuelle Wechsel ist dieser:

IoT dreht sich nicht um Geräte. Es dreht sich um verteilten Zustand unter Unsicherheit.

Referenzarchitektur

Eine produktionsreife ESP32-Flotte besteht aus vier Schichten, die zusammenarbeiten.

Schicht 1 — Edge-Knoten (ESP32)

Jeder Knoten ist verantwortlich für Sensorerfassung, lokale Aktorik, MQTT-Kommunikation und OTA-Update-Empfang. Die kritische Einschränkung: Jeder Knoten muss autonom weiter funktionieren, auch wenn das Netzwerk nicht verfügbar ist. Das Backend ist eine Policy-Engine, kein Echtzeit-Controller.

In NestGrow verwendeter Hardware-Stack: ESP32 WROOM-32D, HW-316 4-Kanal-Relais (invertierte Logik: LOW=EIN), HW-390 kapazitive Feuchtigkeitssensoren nur auf ADC1 (GPIO 32–35, 36 VP).

Schicht 2 — Messaging (MQTT-Broker)

Eclipse Mosquitto 2 verwaltet die Pub/Sub-Kommunikation. Ein kritisches Prinzip muss von Anfang an verinnerlicht werden:

MQTT ist eine Transportschicht, kein System of Record.

Zustand darf niemals aus MQTT rekonstruiert werden. Der Broker ist von Natur aus vergänglich.

Schicht 3 — Orchestrierungs-Backend (FastAPI)

Das Backend verwaltet Flottenstatusverfolg­ung, OTA-Koordination, regelbasierte Policy-Auswertung und Gesundheitsüberwachung. Es rekonstruiert den autoritativen Zustand aus dem Event-Stream — es vertraut dem vom Gerät gemeldeten Zustand nicht direkt.

Schicht 4 — Persistenz (MariaDB)

Alle Telemetrie-Events, Bewässerungsaufzeichnungen und Gerätemetadaten werden in MariaDB gespeichert. Die Datenbank ist die einzige Quelle der Wahrheit. Das Backend baut beim Start seine Sicht auf die Flotte daraus auf.

OTA-Update-Strategie

OTA ist der Bereich, in dem die meisten IoT-Systeme in der Produktion versagen. Die Grundregel:

OTA muss Fehler als Standardzustand annehmen, nicht als Ausnahme.

Ein sicherer OTA-Ablauf für ESP32:

1. Firmware auf die sekundäre Partition herunterladen (nicht die aktive)
2. SHA-256-Prüfsumme vor jedem Partitionswechsel verifizieren
3. Boot-Partition atomar wechseln
4. Firmware-Version nach erfolgreichem Neustart an das Backend melden

Wenn während Schritt 1 oder 2 der Strom ausfällt, bootet das Gerät von der unveränderten primären Partition. Fällt er während Schritt 3 aus, erkennt der ESP32-Bootloader den unvollständigen Wechsel und führt ein Rollback durch. Kein manueller Eingriff erforderlich.

Ausfallmodi in realen Deployments

Netzwerkverlust während des Statusupdates

MQTT-Trennung während der Telemetrie-Übertragung verursacht Nachrichtenverlust. Gegenmaßnahme: idempotentes Nachrichtendesign (jede Nachricht trägt einen Zeitstempel, doppelte Verarbeitung ist sicher) und lokaler FIFO-Puffer auf dem ESP32 zur Synchronisierung bei Wiederverbindung.

ADC2-Inkompatibilität mit WiFi

Dies ist wenig dokumentiert und verursacht stille Ausfälle. Beim ESP32 ist ADC2 hardware-multiplext mit dem WiFi-Funkmodul. Wenn WiFi aktiv ist, liefern ADC2-Lesungen zufällige Werte. Alle analogen Sensoren müssen ADC1 verwenden (GPIO 32–35, GPIO 36 VP).

Invertierte Relaislogik

Das HW-316-Relaismodul verwendet invertierte Logik: LOW = Relais EIN, HIGH = Relais AUS. Firmware, die dies nicht berücksichtigt, aktiviert Pumpen beim Start oder zu falschen Zeiten. Jeder Relaisbefehl in der NestGrow-Firmware ist explizit invertiert.

Water Hammer (logisch)

Wenn Bewässerungsschwellenwerte zu aggressiv eingestellt sind, sendet das Backend zu häufig Befehle und belastet die Aktoren. Lösung: ein Cooldown-Fenster pro Zone (10 Minuten in NestGrow) auf Ebene der Rule-Engine erzwingen, unabhängig von den Sensormesswerten.

Sensordrift (kapazitiv)

Kapazitive Feuchtigkeitssensoren driften im Laufe von Wochen. Zonen, die bei der Installation genau messen, zeigen nach 3–4 Wochen einen Offset von +6–8%. Lösung: dynamische Baseline-Kalibrierung pro Zone mit wöchentlichen Rekalibrierungsroutinen.

Designregeln

Dies sind die architektonischen Invarianten einer stabilen IoT-Flotte. Verstößt man dagegen, werden früher oder später Produktionsvorfälle eintreten.

Regel	Begründung
Gerätezustand ist immer transient	Dem, was ein Gerät als Wahrheit meldet, niemals vertrauen
Backend-Zustand ist immer autoritativ	Aus dem Event-Stream rekonstruieren, nicht vom Gerät
MQTT ist Transport, nicht Wahrheit	Broker-Neustart darf niemals Systemzustand verlieren
Jede Nachricht muss idempotent sein	Doppelte Zustellung ist bei Skalierung garantiert
Fehler ist der normale Betriebsmodus	Für Fehler entwerfen, nicht für den Happy Path
OTA muss Stromausfall überleben	Dual-Partition + Prüfsumme ist nicht verhandelbar

Häufige Anti-Pattern

Das Gerät als Quelle der Wahrheit verwenden. Führt zu Zustandsdrift und Inkonsistenz bei Skalierung. Das Gerät weiß, was es gemessen hat — das Backend entscheidet, was das bedeutet.

Stabile Konnektivität voraussetzen. Funktioniert auf dem Tisch. Bricht sofort in realen Umgebungen mit WiFi-Interferenzen, Power-Cycling oder Firmware-Abstürzen zusammen.

Statuslose OTA-Logik. Jede OTA-Implementierung, die unterbrochene Downloads nicht als erstklassigen Fall behandelt, wird früher oder später ein Gerät in der Produktion zum Absturz bringen.

Kein Reconciliation-Layer. Ohne einen Backend-Prozess, der regelmäßig den erwarteten mit dem tatsächlichen Gerätezustand abgleicht, sammelt sich stille Desynchronisierung unsichtbar an.

Fazit

Eine ESP32-Flotte in der Produktion wird nicht durch Konnektivität definiert — sie wird definiert durch die Fähigkeit, partielle Ausfälle zu überleben, deterministischen Zustand wiederherzustellen, Firmware-Konsistenz aufrechtzuerhalten und unter instabilen Bedingungen zu betreiben.

Das richtige mentale Modell ist nicht “IoT-Geräte verbunden mit einem Backend”. Es ist:

Ein verteiltes System unzuverlässiger Knoten, verwaltet durch deterministische Zustandsrekonstruktion.

NestGrow basiert genau auf diesem Prinzip. Der vollständige Quellcode für die ESP32-Firmware ist als Open Source (MIT-Lizenz) verfügbar unter github.com/jaffa2970/nestgrow-esp32. Das Docker-Backend ist verfügbar unter lake8.dev/projects/nestgrow-docker.

Quellen

Espressif Systems — ESP32 Technical Reference Manual
https://www.espressif.com/en/support/documents/technical-documents
2023

OASIS Standard — MQTT Version 5.0
https://docs.oasis-open.org/mqtt/mqtt/v5.0/
2019

lake8.dev — NestGrow Projekt
https://lake8.dev/projects/nestgrow-docker/
2026

---

Rechte und Quellenangaben

Bilder, Logos und Fotos, die in diesem Artikel zitiert oder gezeigt werden, sind Eigentum ihrer jeweiligen Inhaber. Es wird keine Verletzung von Rechten beabsichtigt: Die Materialien werden in Bezug auf Drittquellen und zu Kommentarzwecken verwendet.

---

← Back to journal