PowerMgr in der Praxis: PV, Batterie, Kühlung und Hauszustand steuern

PowerMgr geht über eine Sammlung von Gerätetreibern hinaus. Der interessante Teil liegt in der Regelung: Aus Messwerten, Zuständen und Konfiguration entsteht im laufenden Betrieb eine Entscheidung, ob geladen, entladen, gekühlt, gelüftet oder eine Fahrzeugladung freigegeben wird.

Der erste PowerMgr-Artikel beschreibt, warum das System entstanden ist und welche Geräte es verbindet. Dieser zweite Teil schaut auf die praktische Steuerlogik.

Datenfluss

PowerMgr arbeitet mit mehreren Datenquellen, die unterschiedliche Bedeutung haben.

Der Stromfluss im Haus kommt aus Leistungsmessung, PV-Wechselrichter und Batterie-Inverter. Die Batteriedaten kommen vom Victron MultiPlus II und den Pylontech-Batterien. Wetterdaten kommen aus lokaler Wetterstation, Oko-Wetterstation-Sensoren und OpenWeather. Hauszustände wie Tür-/Fensterstatus oder manuelle Freigaben kommen über Homebridge und weitere Sensoren dazu.

Diese Werte landen nicht bloß in einer Oberfläche. Sie werden in den dynamischen Regeln verwendet. Im Repository ist diese Trennung gut sichtbar:

• dynamic/020-load-device-data.py lädt Gerätedaten.
• dynamic/025-health.py behandelt Health- und Fehlerzustände.
• dynamic/030-weather.py verarbeitet Wetterdaten.
• dynamic/040-homebridge-states.py liest Homebridge-Zustände.
• dynamic/050-door-window-sensor-handling.py bewertet Tür- und Fensterzustände.
• dynamic/070-proxon-timed.py trifft zeitabhängige Proxon-Entscheidungen.
• dynamic/080-proxon.py enthält zusätzliche Proxon-Gates.
• dynamic/110-evcc.py steuert EVCC.io-Modi.
• dynamic_threads/rules/010-energy-storage.py berechnet die ESS-Zielleistung.

Die Regeldateien sind dadurch klein genug, um einzelne Entscheidungen nachvollziehen zu können, ohne das ganze System in einer einzigen Datei zu verstecken.

Batterie und MultiPlus II

Die ESS-Regelung läuft im dynamischen Thread 010-energy-storage.py. Dort wird aus Netzleistung, Inverterleistung und geglätteten Werten ein Zielwert für den Batteriespeicher berechnet.

Ein wichtiger Punkt ist die Bedeutung der Vorzeichen. PowerMgr muss unterscheiden, ob das Haus gerade Leistung aus dem Netz bezieht, Leistung einspeist, die Batterie lädt oder die Batterie entlädt. Zusätzlich beeinflusst der Batterie-Inverter selbst die gemessene Leistung. Deshalb berechnet die Regel eine korrigierte reale Leistung:

p_real = power_phases_connected - p_inv

Danach wird dieser Wert geglättet und als p_real_lp verwendet. Aus diesem geglätteten Wert entstehen zwei Richtungen:

• corrected_charge_power: verfügbare Leistung zum Laden
• corrected_discharge_power: Bedarf, der durch Entladen gedeckt werden kann

Erst danach greifen Hysterese, Schrittbegrenzung, Mindestleistungen, SoC-Grenzen, Temperaturprüfung und Fallback-Regeln. Am Ende wird entweder Ladeleistung gesetzt, Entladeleistung gesetzt oder die Leistung auf null gestellt.

Diese Reihenfolge ist wichtig. Ohne Glättung und Begrenzung würde die Batterie auf jede kleine Schwankung reagieren. Ohne korrigierte Leistung würde der Regler teilweise auf Werte reagieren, die bereits durch den eigenen Inverter verfälscht sind.

Kühlung über die Proxon FTW-2

Die Proxon-Steuerung ist einer der sichtbarsten Teile von PowerMgr, weil sie Komfort und Energie direkt verbindet.

Die Datei COOLER_CONTROL.md dokumentiert die wichtigsten Kühlungs-Flags. Sie sind als Erlaubnis-Gates zu verstehen. Ein gesetztes Flag bedeutet nicht automatisch, dass die Kühlung gestartet werden muss. Es bedeutet nur, dass die Kühlung in diesem Zustand laufen darf, wenn alle anderen Bedingungen ebenfalls passen.

Für einen automatischen Start prüft dynamic/070-proxon-timed.py unter anderem:

• verfügbare Leistung oder Batterieunterstützung
• aktueller Kühlungszustand
• Intensivlüftung
• Außentemperatur
• erwartete Tagesmaximaltemperatur
• Proxon-Betriebsart
• Tür-/Fensterzustände
• Anwesenheit, falls konfiguriert
• Mindestabstand zwischen mechanischen Schaltvorgängen

Der mechanische Schaltabstand ist bewusst defensiv. Auch wenn die Konfiguration einen niedrigeren Wert erlauben würde, erzwingt der Code für den Proxon-Kühler mindestens 7200 Sekunden. Dadurch wird verhindert, dass die Anlage durch kurzfristige Leistungsschwankungen ständig ein- und ausgeschaltet wird.

Wenn die Batterie gerade lädt und cooler_run_while_battery_charge erlaubt ist, kann die Ladeleistung zur verfügbaren Kühlleistung addiert werden. Wenn die Batterie entlädt, startet die Kühlung nicht einfach deshalb. Ein Start über Batterie-Fallback ist nur möglich, wenn zusätzliche Bedingungen passen: SoC, verfügbare Entladeleistung, Außentemperatur, Raumtemperatur und die konfigurierten Leistungsgrenzen.

Das Ergebnis ist keine einfache Regel wie „bei Sonne kühlen“. PowerMgr versucht, Kühlung dann zu nutzen, wenn das Haus davon profitiert und die Energie dafür sinnvoll verfügbar ist.

Lüftung, Luftqualität und Hauszustand

Neben der Kühlung ist auch die Lüftung Teil des Systems. Der praktische Hintergrund ist Komfort und Luftqualität im Haus. Wenn die Luft abends schlecht ist, kann automatische Lüftung wichtiger sein als eine rein energetisch optimale Entscheidung.

PowerMgr verarbeitet dafür Hauszustände und Sensorinformationen gemeinsam mit den Energieflüssen. Tür- und Fenstersensoren sind dabei keine Dekoration. Eine offene Tür oder ein offenes Fenster kann beeinflussen, ob Kühlung oder Proxon-Zustände geschaltet werden sollen. Homebridge liefert außerdem Steuerflags, mit denen bestimmte Automatiken erlaubt, gesperrt oder manuell übersteuert werden können.

Damit bleibt das System lokal bedienbar. Automatik und manuelle Eingriffe schließen sich nicht aus; sie müssen aber im selben Regelpfad sichtbar sein, damit PowerMgr nicht gegen den tatsächlichen Zustand des Hauses arbeitet.

EVCC.io und Fahrzeugladung

Die Datei dynamic/110-evcc.py zeigt, wie PowerMgr die Fahrzeugladung in die restliche Energielogik einbindet.

EVCC.io bleibt dabei das System für die Ladesteuerung. PowerMgr entscheidet aber, wann ein Modus freigegeben oder deaktiviert wird. Dafür werden verfügbare Leistung, Homebridge-Freigaben, Batterie-Ladezustand, Proxon-Kühlung und Wallbox-Zustand berücksichtigt.

Wenn genug überschüssige Leistung vorhanden ist, kann PowerMgr den konfigurierten EVCC-Standardmodus setzen. Wenn Homebridge die Ladung sperrt oder die verfügbare Leistung zu gering wird, kann PowerMgr EVCC.io wieder auf off setzen. Zusätzlich gibt es Overwrite-Pfade, über die eine manuelle Ladefreigabe Vorrang bekommen kann.

Die Fahrzeugladung wird dadurch nicht isoliert betrachtet. Sie konkurriert mit Batterie, Kühlung und Hausverbrauch um dieselbe Energie.

Fehlerzustände und Decision-Logs

Ein System, das reale Geräte steuert, braucht nachvollziehbare Fehler- und Diagnosepfade.

PowerMgr trennt das Laden von Gerätedaten und die Bewertung der Health-Zustände. Ein Proxon-Lesefehler, ein Batterieproblem oder ein fehlender Wetterstationswert soll nicht still verschwinden. Gleichzeitig darf eine kurzzeitige Störung nicht automatisch wie ein bestätigter Gerätefehler behandelt werden, ohne dass später nachvollziehbar bleibt, was passiert ist.

Dafür gibt es zwei Ebenen:

• normale technische Logs über print_log(...)
• strukturierte Decision-Logs für Steuerentscheidungen

Die Decision-Logs enthalten Komponente, Ereignis, Ergebnis, Grund, Eingangsgrößen und Grenzwerte. Bei ESS-Entscheidungen stehen dort zum Beispiel Zielwert, letzter Wert, p_real_lp, unused_pv_lp, power_lp und SoC. Bei Proxon-Entscheidungen werden verfügbare Leistung, Batterieunterstützung, Temperaturwerte und Gründe wie pv_surplus oder battery_support sichtbar.

Das ist im Betrieb entscheidend. Wenn die Kühlung nicht startet, reicht ein „aus“ im Status nicht. Interessant ist, ob Leistung fehlte, die Betriebsart nicht passte, ein Fenster offen war, der Schaltabstand noch lief oder die Batteriegrenze erreicht wurde.

Warum die Regelung lokal bleibt

PowerMgr läuft lokal auf Embedded Linux und wird als Docker-Container betrieben. Das reduziert Abhängigkeiten von Cloud-Diensten und hält die Steuerung nah an den Geräten. Externe Dienste wie OpenWeather oder EVCC.io können eingebunden werden, aber die Grundlogik bleibt im eigenen System.

Für ein Energiemanagement im Haus ist das ein wichtiger Unterschied. Wenn PV, Batterie, Wärmepumpe, Lüftung und Fahrzeugladung zusammenhängen, reicht eine Sammlung loser App-Automatiken nicht aus. Die zentrale Regelung muss Zustände zusammenführen, Konflikte auflösen und begründen können, warum sie gerade nichts tut.

PowerMgr ist genau aus diesem Bedarf gewachsen: messen, bewerten, entscheiden, begrenzen und später erklären können, warum diese Entscheidung getroffen wurde.

PowerMgr: Mein selbst gebautes Energie- und Smart-Home-System

PowerMgr ist mein eigenes Home-Energy-Management-System. Es verbindet Photovoltaik, Batteriespeicher, Wechselrichter, Wärmepumpe, Wetterdaten, Sensoren und Smart-Home-Schnittstellen zu einem lokalen System, das Messwerte sammelt und daraus Steuerentscheidungen ableitet.

Der Kern läuft auf einem kleinen Embedded-Linux-System mit Armbian und Docker. Das ist bewusst unspektakulär: kein proprietärer Smart-Home-Computer, keine komplette Neuverkabelung des Hauses, sondern ein dauerhaft laufender Linux-Rechner, der vorhandene Geräte einbindet und die relevanten Daten an einer Stelle zusammenführt.

Ausgangslage

Beim Hausbau war Smart Home zwar grundsätzlich ein Thema, praktisch fehlten aber viele der Dinge, die später wirklich wichtig wurden. Ein zusätzlicher Smart-Home-Computer hätte mehrere tausend Euro gekostet. Damit wären aber noch keine elektrischen Rollos, Tür- und Fenstersensoren, Heizungs- oder Kühlungssteuerungen und keine sinnvolle Einbindung der Energieanlage vorhanden gewesen.

Später kamen Angebote von Ingenieurbüros dazu, die das Haus für den Betrieb mit Batteriespeicher und Energiemanagement deutlich umfassender umgebaut hätten. Die Größenordnung lag im fünfstelligen Bereich bis etwa 25.000 EUR. Der technische und finanzielle Nutzen passte für mich nicht zusammen: Das Haus hätte teuer umgebaut werden müssen, obwohl viele Geräte bereits vorhanden waren und nur miteinander sprechen mussten.

PowerMgr entstand deshalb aus einem sehr konkreten Ziel: Vorhandene Hardware weiterverwenden, offene oder zumindest lokal kontrollierbare Schnittstellen nutzen und daraus ein System bauen, das zum realen Haus passt.

Warum Eigenbau?

Das Problem war nicht, dass es keine Smart-Home-Produkte gab. Das Problem war, dass die verfügbaren Lösungen die eigentlichen Energiefragen nicht gut genug beantworteten.

Für mich ging es nicht darum, eine Lampe per App einzuschalten. Das System sollte verstehen, wann Energie erzeugt, gespeichert, verbraucht oder ins Netz eingespeist wird. Daraus sollten Entscheidungen entstehen:

• Soll die Batterie geladen oder entladen werden?
• Ist genug PV-Leistung übrig, um die Kühlung zu starten?
• Muss die Lüftung laufen, weil die Luft im Haus schlecht ist?
• Soll eine Fahrzeugladung freigegeben, gedrosselt oder gestoppt werden?
• Sind Türen oder Fenster offen, obwohl die Kühlung aktiv werden soll?
• Welche Daten müssen in HomeKit, Grafana oder einer mobilen App sichtbar sein?

Dafür war ein klassisches Smart-Home-System zu oberflächlich. Ein reines Energiemonitoring hätte dagegen nur angezeigt, was passiert, aber nicht aktiv gesteuert. PowerMgr sitzt genau dazwischen: Es ist kein universelles Smart-Home-Framework, sondern eine lokale Steuerung für das eigene Haus und die eigene Energieanlage.

Systemüberblick

PowerMgr ist ein Python-Projekt mit Docker-Betrieb. Im Repository liegen unter anderem ein Dockerfile, eine docker-compose.yml, Konfigurationsdateien, ein Webinterface, dynamische Regeldateien und Module für die angebundenen Geräte.

Die wichtigste Struktur ist nicht eine einzelne große Steuerdatei, sondern die Trennung nach Aufgaben:

• powermgr.py startet den Hauptprozess.
• lib/ enthält Geräteanbindungen und gemeinsame Infrastruktur.
• dynamic/ enthält Regeldateien, die im Betrieb ausgewertet werden.
• dynamic_threads/ enthält länger laufende Regelpfade, zum Beispiel für die ESS-Leistungssteuerung.
• html/ stellt Webinterface und Statusseiten bereit.
• conf/ enthält Beispielkonfiguration und Betriebsparameter.

Die dynamischen Regeldateien werden nach ihrem dreistelligen Präfix sortiert ausgeführt. Dadurch ist der Ablauf im Betrieb nachvollziehbar: erst Grunddaten laden, dann Gesundheitszustände bewerten, Wetter und Homebridge-Status einlesen, anschließend Proxon, Shelly, EVCC und andere Steuerpfade behandeln.

Eingebundene Geräte und Datenquellen

PowerMgr bindet mehrere sehr unterschiedliche Systeme zusammen.

Die Photovoltaikseite wird unter anderem über einen StecaGrid-Wechselrichter ausgelesen. Das Modul lib/stecagrid.py liest die aktuelle AC-Leistung und schreibt die Daten für die spätere Auswertung nach InfluxDB.

Der Batteriespeicher wird über einen Victron MultiPlus II und Pylontech-Batterien eingebunden. Das Modul lib/energy_storage.py liest Inverter- und Batteriedaten, überwacht Zustände und stellt Funktionen bereit, um Lade- und Entladeleistungen zu setzen.

Die Zimmermann Proxon FTW-2 wird angezeigt und gesteuert. PowerMgr kann Betriebsart, Kühlung, Lüftung, Heizelemente und weitere Zustände berücksichtigen. Die Regeln dafür liegen unter anderem in dynamic/070-proxon-timed.py, dynamic/080-proxon.py und dynamic/090-proxon-t300.py.

Wetterdaten kommen aus einer eigenen Wetterstation, optionalen Oko-Wetterstation-Sensoren und OpenWeather. Das ist wichtig, weil Energieentscheidungen im Haus nicht nur vom aktuellen Stromwert abhängen. Für Kühlung und Lüftung spielen Außentemperatur, Tagesmaximaltemperatur, Raumtemperaturen und verfügbare PV-Leistung zusammen.

Zusätzlich sind Homebridge, Shelly-Geräte, Tür-/Fenstersensoren und EVCC.io angebunden. Dadurch werden Hauszustände, manuelle Freigaben und Fahrzeugladung Teil derselben Entscheidungslogik.

Vom Messen zum Steuern

PowerMgr sammelt nicht nur Daten. Das System entscheidet im Betrieb, ob eine Aktion sinnvoll ist.

Ein einfaches Beispiel ist die Kühlung. Wenn genug PV-Leistung verfügbar ist, die Außentemperatur hoch genug ist, die Tagesprognose passt, Türen und Fenster geschlossen sind und die Proxon in der passenden Betriebsart läuft, kann PowerMgr die Kühlung einschalten. Wenn die Batterie gerade lädt, kann diese Ladeleistung je nach Konfiguration als verfügbare Leistung mitgezählt werden. Wenn die Batterie entlädt, kann die Kühlung unter bestimmten Komfort- und SoC-Grenzen weiterlaufen oder durch Batterie-Fallback unterstützt werden.

Das ist der entscheidende Unterschied zu einer starren Zeitsteuerung. Die Anlage reagiert auf Hauszustand, Energiefluss und Komfortbedingungen.

Betrieb und Beobachtbarkeit

Der Betrieb ist lokal und nachvollziehbar aufgebaut. Das Webinterface zeigt Statusdaten, Konfiguration und Diagnoseinformationen. Zusätzlich schreibt PowerMgr Messwerte nach InfluxDB, sodass sie in Grafana ausgewertet werden können.

Für Steuerentscheidungen gibt es ein eigenes Decision-Logging. Neben dem normalen Textlog hält PowerMgr strukturierte Ereignisse im Speicher und stellt sie über diese Endpunkte bereit:

/decision_log
/decision_log.json

Damit lässt sich später sehen, was passiert ist und warum es passiert ist. Bei der Kühlung kann zum Beispiel sichtbar werden, ob PV-Überschuss, Batterieunterstützung, geöffnete Fenster, Wallbox-Ladung oder Temperaturgrenzen die Entscheidung beeinflusst haben. Bei der Batterie wird sichtbar, welcher Zielwert berechnet wurde und welche Eingangsgrößen beteiligt waren.

Ergebnis

Der praktische Nutzen liegt in der Eigenverwendung des erzeugten Stroms. Zu Beginn lag die eigene Nutzung der PV-Erzeugung nur grob bei 10 bis 15 Prozent. Im aktuellen Ausbau liegt sie nach eigener Messung bei etwas über 70 Prozent.

Das ist kein abstrakter Optimierungswert. Es bedeutet, dass mehr selbst erzeugter Strom im Haus bleibt: für Grundlast, Batterie, Kühlung, Lüftung, Heizelemente oder Fahrzeugladung. Gerade bei niedriger Einspeisevergütung ist das wichtiger als eine möglichst schöne Smart-Home-Oberfläche.

PowerMgr ist deshalb für mich weniger ein Smart-Home-Projekt im klassischen Sinn. Es ist ein lokales Energie- und Betriebsleitsystem für ein konkretes Haus.

Lumini P30 Control: China-Lampe mit diyHue steuerbar machen

Lumini P30 Control ist ein Umbau einer kleinen Aquarium-LED-Lampe, die unter Bezeichnungen wie Lumini, Lominie, Pixie 30 und P30 verkauft wurde. Die Lampe selbst passte gut zu einem kleinen Meerwasserbecken. Das optionale Steuermodul des Herstellers war dagegen teuer und für diesen Zweck kaum brauchbar: kein WLAN, keine gezielten eigenen Einstellungen und nur vorgefertigte Programme, die nicht zum Becken passten.

Der konkrete Einsatz war ein 50-Liter-Nano-Meerwasseraquarium mit Makroalgen, Riffkeramik, Einsiedlern und Schnecken. Die Beleuchtung war dafür grundsätzlich geeignet. Statt die Lampe zu ersetzen, wurde die vorhandene Elektronik so erweitert, dass die vier LED-Kanäle per ESP8266, PWM und eigenem Webinterface steuerbar wurden. Zusätzlich blieb die Anbindung an diyHue erhalten, damit die Lampe aus Sicht von Hue, HomeKit oder Siri wie ein Hue-kompatibles Gerät verwendet werden konnte.

Das Projekt war abgeschlossen und lief etwa sechs Monate im realen Aquarium-Betrieb. Abgebaut wurde später das Aquarium, nicht wegen der Lampe, sondern weil das kleine Meerwasserbecken insgesamt nicht stabil genug lief.

Ausgangslage

Die Lampe war eine typische günstige Aquariumleuchte aus dem Amazon-Umfeld. Technisch war sie interessant, weil intern getrennte LED-Kanäle vorhanden waren. Praktisch fehlte aber eine brauchbare Steuerung für einen eigenen Tagesverlauf. Für ein kleines Meerwasserbecken ist gerade die Lichtsteuerung wichtig, weil ein abruptes Ein- und Ausschalten oder unpassende Spektren schnell sichtbar werden.

Das Hersteller-Steuermodul löste dieses Problem nicht gut genug. Es bot keine WLAN-Integration und keine freie Konfiguration der einzelnen Kanäle. Deshalb entstand ein eigener Controller, der die Lampe elektrisch direkt ansteuert und die Bedienung ins Heimnetz verlagert.

Warum Eigenbau?

Elektrisch war der Umbau überschaubar: Die LED-Kanäle der Lampe lassen sich über PWM steuern, indem die Steuerleitungen über MOSFET-Module nach GND gezogen werden. Die eigentliche Arbeit lag deshalb weniger in komplizierter Leistungselektronik, sondern in der Firmware: mehrere Kanäle, ein konfigurierbarer Tagesplan, lokale Bedienung im Webinterface und die Kompatibilität zur vorhandenen diyHue-Welt mussten zusammenpassen.

Als Basis diente der diyHue-Sketch ESP8266/Generic_Dimmable_Light. Dieser brachte die Hue-kompatible Erkennung und die /state-Schnittstelle bereits mit. Lumini P30 Control behielt diese Schnittstellen bei, baute den Sketch aber zu einer auf die Lampe zugeschnittenen Firmware um.

Das war auch eines der ersten Projekte, bei denen massiv ChatGPT im Stand von 2023 eingesetzt wurde. In der Projekt-README steht entsprechend, dass ein großer Teil des Codes mit ChatGPT erzeugt und anschließend selbst angepasst wurde.

Hardware

Der Controller ist ein alter NodeMCU v1.0 auf ESP8266-Basis. Die vier Lampenkanäle werden über vier D4184-MOS-Breakoutboards geschaltet. Die Versorgung des NodeMCU erfolgt über einen 7805-Regler: dessen Eingang hängt an den 24 V des Lampen-Netzteils, der Ausgang am Vin-Pin des NodeMCU.

Die Verbindung zur Lampe wurde über ein passendes Anschlusskabel hergestellt, das halbiert und auf die MOSFET-Boards geführt wurde. Die Pinbelegung ist im Projekt dokumentiert:

Kanal	LED-Farbe	Kabelfarbe	MOS-Board	NodeMCU-Pin	GPIO
ch1	blau	blau	1	D1	GPIO5
ch2	warmweiß	schwarz	2	D2	GPIO4
ch3	violett	rot	3	D7	GPIO13
ch4	weiß, rot und grün	weiß	4	D5	GPIO14
Versorgung	+24 V	grün	-	-	-

Die Pinbelegung war am Anfang einer der unsicheren Punkte. Der Projektkontext verweist deshalb auf einen Reef2Reef-Thread zur Lumini/Lominie Pixie 30/P30, in dem der Umbau und die Leitungen ebenfalls behandelt werden:

https://www.reef2reef.com/threads/for-lumini-lominie-pixie-30-p30-hers-how-to-add-ramp-up-down-and-timer-with-memory-quite-cheaply.935409/

Der erste Prototyp ist im Reef2Reef-Thread mit zwei Bildern dokumentiert. Zu sehen sind der NodeMCU-Aufbau mit den MOSFET-Boards und die laufende Lampe am Nano-Becken:

Im Projekt liegen außerdem ein Schaltbild des Controllers und Fotos eines späteren 3D-gedruckten Gehäuses.

Software

Die Firmware ist ein Arduino-/ESP8266-Projekt. Im Vergleich zum ursprünglichen diyHue-Beispiel wurde der Code auf mehrere Dateien aufgeteilt:

• firmware.ino: Setup, WLAN, EEPROM, SPIFFS, HTTP-Update und Hauptloop
• light_engine.ino: PWM-Berechnung, Szenen und Helligkeitsübergänge
• timing_control.ino: NTP-Zeit, Tagesplan und EEPROM-Daten für zehn Zeitpunkte
• webserver.ino: lokale HTTP-Endpunkte und Weboberfläche
• test_pwm.ino: Testlauf durch die vier PWM-Kanäle
• firmware/html/ und firmware/data/: HTML-, CSS- und JavaScript-Dateien für das Webinterface

Die diyHue-Kompatibilität blieb dabei erhalten. Die Firmware antwortet weiterhin auf /detect mit einem native_multi-Gerät und auf /state mit den Helligkeits- und Ein/Aus-Zuständen der einzelnen Kanäle. Dadurch kann sie von diyHue und darüber indirekt auch von Hue-Apps oder HomeKit-Integrationen genutzt werden.

Funktionsweise

Nach dem Start verbindet sich der NodeMCU per WLAN. Die IP-Adresse kann dynamisch per DHCP vergeben oder im Webinterface statisch konfiguriert werden. Die Weboberfläche wird aus SPIFFS-Dateien geladen; die HTML-Dateien werden vor dem Upload aus Templates erzeugt.

Für die Lichtsteuerung gibt es zwei Ebenen. Die Hue-kompatible Ebene setzt pro Kanal Ein/Aus und Helligkeit über JSON an /state. Die lokale Ebene bietet ein Webinterface mit separaten Reglern für die vier Kanäle, Statusanzeige der tatsächlichen PWM-Werte, Szenen, Startverhalten, Netzwerkdaten und einem Editor für den Tagesverlauf.

Der Tagesverlauf besteht aus zehn Zeitpunkten. Jeder Datenpunkt enthält Stunde, Minute und die Helligkeitswerte für ch1 bis ch4. Die Firmware liest die Zeit über NTP, speichert die Timing-Daten im EEPROM und berechnet zwischen zwei Datenpunkten Übergänge. Dadurch kann die Lampe morgens hoch- und abends wieder herunterdimmen, ohne dass dauerhaft ein externer Server die Werte schicken muss.

Die PWM-Frequenz ist im Projekt auf 500 Hz gesetzt. Anfangs gab es Flackern durch unpassende PWM-Einstellungen; dieser Punkt wurde im Projektverlauf behoben. Die Firmware begrenzt die PWM-Werte auf den Bereich 0 bis 255 und rechnet die Helligkeitswerte über eine eigene calcPWM()-Funktion auf die Ausgabe um.

Bedienung

Im normalen Betrieb wurde die Lampe per WLAN ins Heimnetz eingebunden und über das Webinterface konfiguriert. Dort konnten die Kanäle einzeln geschaltet und gedimmt, der Tagesplan bearbeitet, Timing-Control aktiviert oder deaktiviert und ein PWM-Test gestartet werden.

Zusätzlich blieb die Bedienung über die Hue-Welt möglich. Mit diyHue konnte die Lampe wie ein Hue-kompatibles Gerät erscheinen. Wenn diese Hue-Integration über ein Homebridge-Plugin nach HomeKit weitergereicht wurde, ließ sich die Lampe auch per Siri steuern.

Für Tests gibt es außerdem das Skript lp3ctrl.sh. Es fragt die vier Kanalzustände über /state?light=... ab und kann per HTTP-PUT einen Kanalzustand mit Helligkeit setzen. Das Skript ist eher ein Diagnosewerkzeug als die eigentliche Bedienoberfläche.

Build und Installation

Die README dokumentiert keinen vollständigen modernen Build-Prozess, aber den historischen Upload-Weg:

1. Firmware mit der Arduino-ESP8266-Umgebung auf den NodeMCU schreiben.
2. HTML-Dateien für SPIFFS erzeugen:

bash ../../tools/html_gen_files.sh

3. Die erzeugten Dateien in den data-Ordner legen.
4. Den SPIFFS-Inhalt mit dem ESP8266 Sketch Data Upload Plugin der alten Arduino IDE hochladen.
5. Nach dem ersten Start im Webinterface reset timing control data ausführen.

Die README weist ausdrücklich darauf hin, beim Flashen den EEPROM zu löschen. Die Firmware setzt Standardwerte für die Konfiguration, behandelt den Timing-Datenblock aber gesondert.

Stolpersteine

Die Pinbelegung war zunächst nicht offensichtlich. Ohne die dokumentierte Zuordnung der Kabelfarben und GPIOs lässt sich der Umbau leicht falsch verdrahten.

Die PWM-Einstellungen waren ein praktischer Testpunkt. Eine ungeeignete Frequenz führte anfangs zu sichtbarem Flackern; in der dokumentierten Firmware ist PWM_FREQ auf 500 Hz gesetzt.

Der Build-Prozess hängt an der damaligen Arduino-ESP8266-Werkzeugkette und am alten ESP8266 Sketch Data Upload Plugin. Der Artikel ist deshalb keine aktuelle Schritt-für-Schritt-Anleitung für heutige Arduino-IDE-Versionen.

Die Weboberfläche nutzt JavaScript-Bibliotheken von öffentlichen CDNs. Für den Betrieb im Heimnetz war das ausreichend, macht die Oberfläche aber nicht vollständig unabhängig vom Internet, solange diese Dateien nicht lokal eingebunden werden.

Projektstand

Lumini P30 Control liegt im lokalen Archiv unter oko_git_backup/lumini_p30_control. Das Projekt enthält eine Okoyono-Gitea-Remote-URL, die beim Prüfen für diesen Artikel aber nicht öffentlich erreichbar war. Deshalb wird hier kein direkter Repository-Link veröffentlicht.

Der Stand ist abgeschlossen und historisch. Die Lampe hat im realen Nano-Meerwasseraquarium etwa sechs Monate funktioniert. Der Umbau zeigt damit vor allem, dass die P30-Hardware mit einem ESP8266, vier MOSFET-Kanälen und angepasster diyHue-Firmware gut steuerbar war. Weitergeführt wurde das Projekt nach dem Abbau des Aquariums nicht.

Die ältere DIYHue Lights-Dokumentation gehört fachlich zu diesem Artikel: Sie beschreibt den Upstream-Fundus, aus dem die verwendete Basis stammt. Als eigener Blogpost wäre sie neben Lumini P30 Control eher eine Doppelung.