Zum Inhalt springen
labkompass

Logbuch#homeos#energie#smart-home#architektur#simulation

Energie-Management: die Software ist fertig, bevor das Haus steht

Von Niclas Hennrich · veröffentlicht · geschehen am


BuildIm Einsatz

Selbst gebaut und in Betrieb genommen. Gehört zum Vorhaben HomeOS — Control Center mit drei Säulen.

Hardware-Readiness
2von 10
Simulierte PV-Anlage
9.8kWp
Simulierter Speicher
12kWh

HomeOS ist mein selbst gebautes Control Center fürs Homelab, aus dem Infrastruktur-NOC gewachsen, mit drei Säulen: Infrastruktur, Haus (Smart Home) und Family (Haushalt). Am 31. August habe ich die Energie-Auswertung auf Kalendertage, Frische-Regel und Tarifhistorie gestellt. Die läuft an fünf echten Shellys. Alles andere — PV, Batterie, Wärmepumpe, Hauszähler — gibt es noch nicht, weil das Haus noch nicht steht.

Was ich wollte: Dass ich nach dem Einzug nur noch adoptiere: Gerät anschließen, Rolle und Raum zuweisen, und Messwerte, Statistiken und Bilanz funktionieren. Keine neue Architektur unter Umzugsstress.

Was fehlte: Die Auswertungskonstanten (Grundlast-Perzentil, Nachtfenster, Schwellen für Hinweise) lagen verstreut. Es gab keine kanonischen Rollen und Vorzeichen, kein Vokabular dafür, woher ein Wert stammt, kein Gebäudeprofil, keine Sicht auf „was ist bereit", keinen Simulator.

Was ich gebaut habe, in sechs Schritten: Eine Semantik-Datei, in der jede Konvention genau einmal steht — Netz positiv heißt Bezug, Batterie positiv heißt Laden, die Hauslast-Bilanz als reine Funktion. Dazu ein Herkunfts-Vokabular: MEASURED, DERIVED, ESTIMATED, SIMULATED, STALE, NOT_CONFIGURED. Fünfzehn neue Capabilities mit eigenen Metriknamen für Netz, PV, Batterie, Heizung, Klima und Wasser, damit die Summe über die bisherige Leistungsmetrik per Konstruktion die Summe der Verbraucher bleibt. Eine Energie-Rolle am Gerät. Eine Flow-Engine, bei der jeder Knoten Herkunft und Quellen trägt; ohne Hauszähler ist die Hauslast not_configured — nie 0. Ein Gebäudeprofil als Selbstauskunft statt erfundener Defaults, Retrofit-Maßnahmen mit „Erwartung ≠ Messung" als Modelleigenschaft, und eine Readiness-Seite, die live aus dem Bestand rechnet.

Und der Haus-Simulator: Netz, PV mit 9,8 kWp, Speicher mit 12 kWh, Wärmepumpe, fünf Räume, Fenster, Wasser. Die Profile sind deterministisch aus Uhrzeit und Jahreszeit, und der Trick ist: Das Netz wird nicht simuliert, sondern ist die Bilanz der anderen Profile. Damit ist jede Flussprobe automatisch eine Identitätsprüfung der Auswertung. Die Zähler sind Integrale seit einer festen Epoche — monoton über Neustarts und Tagesgrenzen. In Produktion ist der Simulator aus; wo er läuft, trägt jeder Wert SIMULATED bis hinauf zum Banner im UI.

Damit löst sich auch ein Spannungsfeld, das mich beschäftigt hat: „erst ein echtes Gerät, dann das Modell" gegen „Software vor Hardware". Der Simulator ist das erste Gerät jeder Klasse — echte Payloads durch die echte Kette, und das Herstellerwissen bleibt trotzdem im Adapter.

Der Befund nebenbei: Bei der Live-Validierung auf optimus fiel auf, dass der webOS-Poller seit Tagen jeden Zyklus mit OverflowError abbrach. Der Fernseher war seit Tagen aus, der Fehlerzähler fünfstellig — und 2 ** fehler sprengte den Float-Bereich, noch bevor das min auf die Backoff-Obergrenze greifen konnte. Die Integration hätte sich nie wieder erholt. Exponent gedeckelt, Regressionstest, nachdeployt. Gefunden nur, weil ich nach dem Deploy die Logs gelesen habe und nicht nur den Health-Check.

Stand nach dem Deploy: Die bestehende Energie-Antwort ist unverändert (213,4 W aus fünf echten Quellen), Flow und Readiness antworten ehrlich mit „nicht konfiguriert" und „wartet". Hardware-Readiness 2 von 10 — Messpunkte und Raumklima sind da, der Rest wartet auf das Haus. Software: bereit. Genau das Bild, das ich vor dem Einzug sehen wollte.

Im zweiten Lauf am selben Tag kamen Solar- und Batterie-Sicht dazu (leer, bis das erste Gerät adoptiert ist — dann füllen sie sich ohne Codeänderung), der echte Stromtarif per API aus meiner Finanzverwaltung statt per Handeingabe, und ein Preis-Provider für Börsenstrompreise. Der bleibt in Produktion standardmäßig aus: Ein neuer ausgehender Kontakt zu einem Drittanbieter ist eine Entscheidung, keine Nebenwirkung eines Deploys. Und Anzeige ist nicht Verrechnung — dynamische Tarife bleiben aus der Kostenrechnung draußen, bis es eine verrechenbare Preishistorie gibt.

Was ich mitnehme: not_configured als eigener Herkunftswert verhindert die 0-kW-Lüge strukturell; die UI muss nicht wissen, warum ein Wert fehlt — der Wert sagt es selbst. Ein Rollenwechsel ist ein Serienwechsel: Wer einen Zähler zum Netzzähler erklärt, beginnt neue Metriknamen, und die alte Serie endet ehrlich. Und exponentielles Backoff braucht einen Deckel, sonst ist der Fehlerzähler eines lange toten Geräts eine Zeitbombe.