The upgrade that did not need a new light
This project began with two ordinary 12 V bi-color LED key lights. They worked well, but every adjustment meant reaching for the physical buttons. Smart replacements with remote control cost about $60 each, and replacing functional hardware only for convenience did not feel like the right answer.
Instead, I asked a more interesting question: could I keep the LEDs and power electronics that already worked, then replace only the control layer? That question grew into AMS KeyLight, an ESP32-based lighting platform with Wi-Fi, a browser interface, a network API, automatic discovery, multi-light control, and a native Elgato Stream Deck plugin.
Reverse engineering the original light
Opening the controller revealed separate warm and cool LED channels sharing the same 12 V supply. The original board already contained two MOSFETs that switched those channels, so rebuilding the entire power stage would have added complexity without improving the light.
I traced the connections and measured the gate and drain behavior at different brightness levels. A multimeter initially showed values that looked unusual because it was averaging a rapidly switching signal. Once that was understood, the design became clear: the factory controller used PWM, and an ESP32 could take over those control signals while leaving the proven MOSFET stage in place.
Recreating brightness and color temperature with PWM
The first prototype connected two ESP32 GPIO outputs to the warm and cool control channels. From there, the microcontroller could generate PWM for each side of the panel and reproduce both original controls entirely in software.
The user does not need to manage two channels. The firmware accepts one master brightness value and one color-temperature value, then calculates the correct mix. Moving warmer increases the warm channel while reducing the cool channel. Moving cooler does the opposite. The center position blends both channels into a neutral light.
This simple control model became the foundation of the project. Every interface can request a brightness and temperature, while the firmware translates those requests into the electrical behavior the panel needs.
Finding a stable operating limit
Getting visible light was only the first test. At high PWM output, the panel could run briefly and then shut down and restart several minutes later. Short tests looked successful, but longer runs exposed voltage sag and a practical limit in the original 12 V hardware.
I progressively reduced the maximum PWM value while watching the supply and repeating longer tests. The current firmware uses a conservative ceiling of 90 out of 255. The perceived brightness loss is small, while the electrical load is reduced substantially. Higher values caused much more supply sag without producing anything close to a proportional visual improvement.
The exact limitation still deserves deeper characterization, but the process reinforced an important lesson: a prototype that survives thirty seconds is not necessarily stable. Thermal behavior, power delivery, and protection only become visible when the system is allowed to run.
Turning the prototype into a network device
The LEDs responding to an ESP32 proved the concept, but AMS KeyLight needed to behave like a finished network device. The firmware evolved into version 1.4 with automatic Wi-Fi reconnection, an HTTP server, live state reporting, and API commands for power, brightness, and color temperature.
The ESP32 also hosts its own branded control page. Power, brightness, temperature, device information, and current output values are available from any browser without installing software. The artwork and favicon are stored in flash, so the interface is completely self-contained and does not depend on an outside server.
That separation matters. A browser, Stream Deck, or future integration only asks for a result. The firmware remains responsible for PWM mixing and the physical hardware underneath.
Automatic discovery across a segmented network
Hardcoding one IP address would work for one light until DHCP changed it. Every AMS KeyLight instead creates a unique identity from its ESP32 and advertises an mDNS service with its friendly name, device ID, firmware version, and connection details.
That design created a real networking challenge in my segmented home lab. Normal HTTP traffic routed correctly between VLANs, but mDNS advertisements stayed inside their local broadcast domain. Avahi on pfSense now reflects mDNS only between the appropriate networks, allowing the plugin to discover KeyLights across the VLAN boundary while normal firewall policy remains in control.
The software remembers the permanent device ID, not a temporary address. Additional lights can advertise themselves independently, change addresses, and still appear as the same physical devices to every controller.
Building a native Stream Deck experience
Remote control was the original motivation, so the web interface was not the finish line. I built a native Elgato Stream Deck plugin that discovers AMS KeyLights and provides dedicated actions for power, brightness, temperature, presets, and dial control.
Each action includes an automatically populated device selector and an All Lights option. Selections are saved by unique device ID, which means the plugin continues to control the correct light even when its network address changes. Presets can also be placed inside Stream Deck Multi Actions for larger streaming or recording scenes.
On Stream Deck+, one dial adjusts brightness and toggles power when pressed. Another moves between warm and cool light and returns to neutral when pressed. The touchscreen displays the current settings, which makes the system feel native instead of like a collection of generic web requests.
Even the Power key required careful state handling. Stream Deck's automatic state switching initially disagreed with the real light. The ESP32 is now the source of truth, so the plugin reads the actual device state and updates the key artwork only after it knows what the hardware is doing.
What comes next
The core architecture now works from the LED channels to the network and Stream Deck. The next hardware revision will replace the large development board with a much smaller ESP32-C3 design and make the modification cleaner and easier to install.
The roadmap also includes friendlier Wi-Fi provisioning, persistent settings, OTA firmware updates, stronger security, additional calibration, integration with the original physical buttons, and more refinement of the plugin package and artwork.
What began as a way to avoid walking over to a cheap light became a complete hardware and software platform. Was all of this necessary just to change brightness from a chair? Absolutely not. That is also exactly why projects like this are fun.
