Connected IoT-Gerät: Firmware, Cloud-Pipeline, Fleet-Portal und OTA-Updates.
Ausgangslage
Ein OEM entwickelte ein vernetztes Industriegerät: sensorbasiert, mit Aktoren (Bewegung, Relais/Heizung) und klaren Sicherheitszuständen — aber ohne vorhandene Cloud-Plattform.
Ziel war ein durchgängiger Datenpfad: Gerät sendet Telemetrie, das Backend speichert historisiert, der Betreiber sieht Online-Status und Versionen im Portal, und Updates werden kontrolliert ausgerollt — ohne Service-Einsatz.
Solvetronix übernahm den kompletten Pfad: Firmware-Grundlagen (Netzwerk, Provisioning, Safety), MQTT-Telemetrie und Control-Kanäle, Cloud-Ingestion nach PostgreSQL, Ops-Portal sowie einen OTA-Artefakt-Server für Build und Dateisystem.
Vorgehen
Firmware-Fundament (Netzwerk, Safety, Telemetrie)
- Geräte-Identität (chipId), Boot-Logging, resilienter Netzwerk-Connect
- Safety-Interlocks: definierte Fehlerzustände schalten Aktoren ab
- JSON-Telemetrie: Zustände, Messwerte, Fehlercodes, Build/Environment
MQTT Datenmodell + bidirektionaler Control-Pfad
- Topic-Konventionen: Environment (dev/prod), chipId, dataType
- Telemetrie-Kanäle (z. B. devinfo, errors) plus Control-Topics (Update/Wi‑Fi)
- JSON-Format bewusst erweiterbar — Backend akzeptiert zusätzliche Felder
Cloud Ingestion → PostgreSQL
- MQTT Subscriber verarbeitet Topic → (chipId, dataType, env)
- UPSERT Device Registry via ON CONFLICT, keine Race-Conditions bei Parallelpaketen
- Historisierung in device_data: topic, JSON payload, received_at
Ops-Portal (Fleet View)
- Geräteliste: last_seen, firmware_build, env, OTA-Flag
- Detailansicht: Telemetrie-Historie und Statusdaten pro device_id
- Funktionen für Flottenbetrieb: Versionen prüfen, Update anstoßen
Staged OTA: Build + Dateisystem
- Artefakt-Server listet dev/prod Builds (Ordnerstruktur pro Build-Timestamp)
- HTTP Download: firmware.bin + filesystem image (z. B. LittleFS)
- Update-Trigger über MQTT Control-Topic; Gerät bestätigt mit neuem build im devinfo
End-to-End Abnahme
- Telemetrie → DB → Portal: identisches Gerät in UI sichtbar
- OTA-Ordner → Control-Command → Reboot → neue Build-Version im Portal
- Negativpfade: Cloud/Queue-Ausfall blockiert nicht lokale Safety
So funktioniert die Lösung
Der Kern dieser Fallstudie ist der komplette Datenpfad im Betrieb: Gerät sendet Telemetrie, Cloud speichert, Portal zeigt Fleet-Status — und OTA kann versionsbasiert ausgerollt werden (anonymisiert, ohne Produktnamen).
Datenpfad
Hauptpfad (Abnahme)
- 1 · Telemetrie
Gerät verbindet sich mit Wi‑Fi, publiziert devinfo (build/env) und Statusdaten auf MQTT Topics.
- 2 · Persistenz
Ingestion-Service legt das Gerät (chipId) an/aktualisiert es und speichert die JSON-Nachricht historisiert in PostgreSQL.
- 3 · Portal
Im Ops-Portal erscheint das Gerät als online (last_seen) und zeigt aktuelle Firmware-Version und Environment.
- 4 · OTA
Portal/Backend wählt einen Build-Ordner, sendet Update-Control via MQTT; Gerät lädt Firmware + Dateisystem, rebootet und bestätigt die neue Version.
Weitere getestete Pfade
Update-/Wi‑Fi-Commands werden als eigener dataType gespeichert (nicht in devinfo), um Auswertungen stabil zu halten.
JSON kann neue Felder enthalten; Ingestion speichert ohne Schema-Bruch. Parallelpakete erzeugen keine Duplikate durch UPSERT.
Sicherheitszustände (z. B. Interlock-Fehler) schalten Aktoren lokal ab — unabhängig davon, ob die Cloud erreichbar ist.
Abnahme-Checkliste (Staging)
- MQTT devinfo erscheint am Broker
- PostgreSQL: device + device_data für chipId
- Oversicht im Portal: last_seen + firmware_build
- OTA API: dev/prod Build-Ordner listen
- Update-Control → Reboot → neuer build im Portal
Ergebnisse
Technologien
IoT-Gerät geplant — aber kein Fleet-Betrieb?
In 30 Minuten klären wir, ob ein MQTT→PostgreSQL→Portal Pfad mit staged OTA für Ihre Geräteflotte realistisch ist — inklusive Safety- und Update-Strategie.
Kostenfreie Ersteinschätzung