Logbuch#homeos#energie#smart-home#architektur#simulation
Energie-Management: die Software ist fertig, bevor das Haus steht
Von Niclas Hennrich · veröffentlicht · geschehen am
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.