Posts mit dem Label Hardware werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Hardware werden angezeigt. Alle Posts anzeigen

Freitag, 31. Juli 2026

Lumini P30 Control: China-Lampe mit diyHue steuerbar machen

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:

Erster Lumini-P30-Controller-Prototyp mit NodeMCU, vier MOSFET-Boards und Verkabelung

Lumini P30 am Nano-Meerwasseraquarium im Betrieb

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
  1. Die erzeugten Dateien in den data-Ordner legen.
  2. Den SPIFFS-Inhalt mit dem ESP8266 Sketch Data Upload Plugin der alten Arduino IDE hochladen.
  3. 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.

Freitag, 24. Juli 2026

USB2SerialMux - Weniger Kabelsalat beim Debuggen von Embedded-Systemen

USB2SerialMux - Weniger Kabelsalat beim Debuggen von Embedded-Systemen

USB2SerialMux ist ein kleines Hardware-/Firmware-Projekt, um mehrere USART-faehige Geraete ueber einen einzigen USB-Anschluss erreichbar zu machen.

USB2SerialMux PCB Top-Seite

Der konkrete Anlass war ein alter Embedded-Cluster. Darin liefen mehrere Orange Pis, und beim Booten wollte ich nicht nur einen einzelnen Knoten sehen, sondern zwischen den seriellen Konsolen der Boards umschalten koennen. Vorher bedeutete das: ein USB-Hub, mehrere USB-zu-Serial-Adapter, viele Kabel und am Ende trotzdem die Frage, welcher Adapter gerade zu welchem Board gehoert. Danach hing ein USB-Pigtail an meiner Platine und die Zielgeraete wurden per Multiplexer ausgewaehlt.

Das Projekt ist kein grosses Framework und auch kein universeller Console-Server. Es ist eine pragmatische Loesung gegen serielles Kabelchaos.

Was das Problem war

Bei Embedded-Boards ist die serielle Konsole oft der ehrlichste Debug-Ausgang. Gerade beim Booten sieht man dort Dinge, die spaeter ueber SSH oder Netzwerk nicht mehr sichtbar sind:

  • Bootloader-Ausgaben
  • Kernel-Start
  • fruehe Fehler vor dem Netzwerkstart
  • Login-Konsole
  • sporadische Ausgaben im Betrieb

Mit einem einzelnen Board ist das einfach: USB-Serial-Adapter anschliessen, screen, minicom oder picocom starten und mitlesen. Bei sieben oder acht Boards wird daraus aber schnell ein unuebersichtlicher Aufbau. Jeder Adapter erzeugt ein eigenes Device, die Reihenfolge kann sich aendern, der USB-Hub liegt irgendwo zwischen den Boards, und beim Mitschneiden muss man immer wissen, welcher Port gerade welches Geraet ist.

USB2SerialMux loest nicht alle Probleme gleichzeitig. Es reduziert das Setup bewusst auf eine klare 1-zu-1-Verbindung: ein USB-Anschluss am Rechner, ein gerade ausgewaehlter USART-Kanal auf der Zielseite.

Wie die Loesung aufgebaut ist

Die Platine basiert auf einem ATmega32U4 mit LUFA-Firmware. Am Rechner meldet sich das Geraet als USB-CDC-Device mit zwei virtuellen seriellen Interfaces:

  • ein Control-Interface fuer Kommandos wie Kanalwahl, Baudrate abfragen oder Baudrate setzen
  • ein Daten-Interface fuer den eigentlichen USART-Datenstrom

Auf der Hardwareseite schalten zwei 74HCT4051-Multiplexer die USART-Leitungen auf einen von acht Kanaelen. Die Firmware steuert die drei MUX-Select-Leitungen und leitet die Daten zwischen USB-CDC und UART weiter.

Das ist der wichtige Punkt: Es ist kein USB-Hub mit mehreren USB-Serial-Adaptern. Es ist auch kein paralleler Mehrkanal-Logger. Der Host sieht ein USB-Geraet, und die Platine verbindet dieses logisch mit genau einem ausgewaehlten USART-Ziel.

Bedienung

Nach dem Einstecken wird das Board als serielles USB-Geraet erkannt. Die Steuerung passiert ueber das Python-Tool im Projekt:

python tools/muxctrl.py -d /dev/ttyACM0 -l 3 -m

Damit wird zum Beispiel MUX-Kanal 3 ausgewaehlt und der aktuelle Kanal wieder abgefragt. Die Firmware unterstuetzt Kanaele von 0 bis 7.

Die Baudrate kann ebenfalls ueber das Tool gesetzt werden:

python tools/muxctrl.py -d /dev/ttyACM0 -s 115200 -b

Im Projekt liegt ausserdem ein kleines Shell-Skript, das den urspruenglichen Cluster-Anwendungsfall zeigt: tools/logClusterBootup.sh setzt Default-Werte, startet ein Logging-Skript und schaltet dann nacheinander durch die Kanaele 0 bis 7.

Warum das fuer den Cluster praktisch war

Vorher sah das Setup ungefaehr so aus:

  • mehrere Orange Pis
  • je Board ein USB-Serial-Adapter
  • ein USB-Hub
  • viele kurze Adapter- und Dupont-Kabel
  • manuelle Zuordnung von /dev/ttyUSB* oder /dev/ttyACM*

Nachher war der Aufbau deutlich ruhiger:

  • ein USB-Kabel zum Rechner
  • eine kleine Platine am Cluster
  • bis zu acht USART-Anschluesse auf der Zielseite
  • Umschalten per Kommandozeile

Fuer meinen Zweck war das genau die richtige Vereinfachung. Beim Booten konnte ich Kanal fuer Kanal mitloggen oder gezielt auf den gerade interessanten Knoten schalten. Im laufenden Betrieb war die serielle Konsole weiterhin erreichbar, ohne jedes Mal Kabel oder Adapter umzustecken.

Warum ueberhaupt eine eigene Platine?

Damals haette ich das Problem natuerlich auch mit mehreren USB-zu-Serial-Adaptern loesen koennen. Technisch waere das vollkommen ausreichend gewesen.

Mich reizte jedoch die Idee, dafuer eine eigene Hardware zu entwickeln. Zum einen entstand dadurch ein wesentlich aufgeraeumterer Aufbau. Zum anderen bot das Projekt die Moeglichkeit, Mikrocontroller-Firmware, USB-Kommunikation, Leiterplattenentwicklung und Embedded-Hardware in einem kleinen, ueberschaubaren Projekt miteinander zu verbinden.

Rueckblickend war genau das vermutlich der eigentliche Grund, warum dieses Projekt entstanden ist.

Hardware

Aus den Projektdateien ist dieser Aufbau ableitbar:

  • Mikrocontroller: ATmega32U4-A
  • USB-Anschluss: USB Mini-B
  • Multiplexer: 2 x 74HCT4051
  • Firmware-Basis: LUFA CDC
  • Takt: 16 MHz laut Firmware-Makefile
  • Ziel: acht umschaltbare USART-Kanaele

Die Platine ist als Shared Project bei OSH Park verfuegbar: USB2SerialMux bei OSH Park.

Das groesste praktische Problem war nicht die Firmware, sondern die Platine: moeglichst klein bleiben und trotzdem so viele USART-Anschluesse wie moeglich sauber herausfuehren. Genau an der Stelle wird so ein Projekt mechanisch und layoutseitig interessant. Die reine Idee ist simpel, aber auf engem Raum mit USB, Mikrocontroller, Multiplexern und Anschluessen wird es schnell ein echtes PCB-Projekt.

Firmware

Die Firmware ist ein angepasstes LUFA-CDC-Beispiel. Im Quellcode ist der Stand mit 08/2016 und Version v0.1 kommentiert; auf der Platine steht USB2SerialMux v0.2.

Sie stellt auf der USB-Seite zwei CDC-Interfaces bereit: eines fuer die Steuerung und eines fuer den eigentlichen seriellen Datenstrom. Die Firmware nimmt die Kommandos des Python-Tools entgegen, schaltet darueber den aktiven MUX-Kanal und reicht die UART-Daten zwischen Host und ausgewaehltem Zielgeraet weiter. Die Baudrate wird dabei im EEPROM gespeichert, und fuer Firmware-Updates kann das Board per Kommando in den Bootloader springen.

Das Makefile ist fuer atmega32u4 ausgelegt und nutzt dfu-programmer zum Flashen. Vor dem Programmieren kann das Board ueber muxctrl.py in den Bootloader geschickt werden.

Was es nicht kann

USB2SerialMux ist bewusst kein Mehrkanal-Logger. Es kann nicht zwei oder mehr USART-Geraete gleichzeitig mitschneiden. Es gibt immer genau eine aktive Verbindung zwischen USB-Seite und einem Zielkanal.

Das ist keine versteckte Einschraenkung, sondern die eigentliche Designentscheidung. Fuer paralleles Logging aller Boards waere ein anderes Design noetig: mehrere UARTs, groesserer Controller, anderes Buffering, anderes Host-Protokoll. Fuer meinen Anwendungsfall war das nicht der Punkt. Ich wollte das serielle Chaos am Cluster reduzieren und bei Bedarf sauber umschalten koennen.

Repository

USB2SerialMux auf Okoyono-Gitea

Fazit

USB2SerialMux ist ein typisches Werkstattprojekt: ein konkretes Problem, eine kleine Platine, etwas Firmware und am Ende weniger Kabelsalat. Es ersetzt keinen Console-Server und keinen Log-Aggregator, aber es macht einen bestimmten Embedded-Alltag deutlich angenehmer: viele USART-Geraete, ein USB-Anschluss, Umschalten per Kommandozeile.

Fuer mich war das der Punkt, an dem aus sieben oder acht USB-Serial-Adaptern an einem Hub eine kleine eigene Platine wurde.

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

PowerMgr in der Praxis: PV, Batterie, Kühlung und Hauszustand steuern PowerMgr geht über eine Sammlung von Gerätetreibern hinaus. Der inte...