Eine Batterie-Analytics-Plattform für 100k+ IoT-Geräte

Als alleiniger Entwickler habe ich eine Batterie-Analytics-Plattform für 100.000+ IoT-Thermostate gebaut: eine getestete Bibliothek zur Kapazitäts- und Laufzeitschätzung im internen PyPI, Dagster-Ingestion, FastAPI-Services, Dashboards und Monitoring.

Die Plattform schätzt die verbleibende Batteriekapazität und Laufzeit von mehr als 100.000 IoT-Thermostaten. Ich bin ihr alleiniger Entwickler und arbeite an allen Teilen, vom Schätzalgorithmus bis zur Integration in das Vue-Dashboard der Firma.

Die ursprüngliche Aufgabe war die Schätzung selbst: wann die Batterie eines bestimmten Thermostats leer sein wird. Um diese Schätzung produktiv zu betreiben, waren weitere Komponenten nötig. Die Schätzung braucht Felddaten, und die Felddaten brauchen eine zeitgesteuerte Pipeline. Andere Systeme lesen die Schätzung über einen Service, Menschen prüfen sie in Dashboards, und Monitoring meldet Ausfälle. Jede Komponente muss deploybar und rückrollbar sein.

Komponenten

Felddaten   -> Ingestion (Dagster -> Parquet/MinIO)
            -> Schätzbibliothek (Kapazität + Laufzeit, typisiert, getestet, internes PyPI)
            -> Services (FastAPI: Schätzungen pro Gerät, Fleet-Abfragen)
            -> Dashboards (Streamlit für Analysten, firmeneigenes Vue-Dashboard für das Produkt)
            -> Monitoring (Health-Checks, Alerting)

Die Schätzlogik ist als eigene Bibliothek verpackt, von der die anderen Komponenten abhängen.

Schätzbibliothek

Die Kapazitäts- und Laufzeitschätzung ist in einer typisierten Python-Bibliothek auf Basis von Polars implementiert und in einem internen PyPI veröffentlicht. Sie ist getestet und streng typgeprüft.

Vier Komponenten nutzen die Bibliothek: die Ingestion-Pipeline, das Diagnose-Tool pro Gerät, das Fleet-Reporting und die Evaluierungspipeline. Eine unbemerkte Änderung im Schätzverhalten würde alle vier gleichzeitig betreffen. Weil die Bibliothek ein versioniertes Paket ist, pinnt jeder Consumer eine bekannte Version, und eine Algorithmusänderung erreicht einen Consumer nur über ein neues Release und ein ausdrückliches Versions-Update.

Ingestion

Dagster-Jobs ziehen Gerätetelemetrie, bauen Laufzeit- und Kapazitätsdatensätze und speichern sie in MinIO als nach Zeit partitioniertes Parquet.

Die Flotte produziert kontinuierlich Telemetrie. Mit Zeitpartitionen betrifft die Neuverarbeitung eines Monats nur die Daten dieses Monats, und der Re-Run einer Partition ist günstig und idempotent.

Services und Dashboards

Die Schätzungen sind an drei Stellen verfügbar. FastAPI-Services liefern anderen Systemen Schätzungen für ein Gerät, eine Flotte oder einen Kunden. Eine Diagnoseansicht pro Gerät zeigt, warum das System für ein Thermostat eine bestimmte Schätzung berechnet hat. Die Schätzungen auf Flottenebene sind in das bestehende Vue-Dashboard der Firma integriert, das Produktteam und Kunden bereits nutzen.

Das Vue-Dashboard wird von anderen Entwicklern betreut. Ich habe die dort angezeigten Batterie-Analytics gebaut und in dieses Frontend integriert.

Monitoring

Health-Checks und Alerting erkennen Ingestion-Ausfälle, veraltete Datensätze und Datenqualitätsprobleme, bevor die Zahlen bei den Menschen ankommen, die sie nutzen.

Arbeit als alleiniger Entwickler

Eine Person baut und betreibt alle Komponenten, also muss jede Komponente so einfach sein, dass diese Person sie verstehen und betreiben kann. Daraus ergeben sich die getestete Kern-Bibliothek, die wiederholbare Ingestion, die dünnen Services und ein Monitoring, das bei einem fehlgeschlagenen Schritt alarmiert.