April 8, 2022 15:21
Leadup
Everything started as I bought the “LED Panel, Colour Temperature Fully Adjustable […]” by “B.K.Licht” off Amazon. It worked great with the also shipped remote control and it was only a little bit inconvenient to never have the remote when needed. It is a 15W
LED panel with RGB/WW/CW
and therefore 5 channels. I chose it because the pictures in the reviews indicated a modular power supply and also showed some minor information about the wattage and ratings. Furthermore, the manufacturer (or at least distributor) was also located in Germany, so I hoped for easier communication.
But with time I realized that I only used a very small set of the lamps features. This is primarily caused by the clunky remote not providing granular control over the lamps functions. Additionally, the “sleep mode” (so the lamp times out after a fixed amount of time), only provided at least a runtime of one hour, which was too long for my taste. Finally, being unable to quickly load scenes including this ceiling light from my Home Assistant was also annoying.
Hack it!
So, I came to the conclusion that the built-in functions needed to be extended and, therefore I started to investigate how to achieve this…
MiLight Derivative?
My first thought was, that this light could be a derivative of the popular product line of MiLight, as their remotes looked very similar. Sadly, I was unable to communicate with the built-in controller of the power supply using a nRF24L01+
- despite many attempts and different reverse-engineered protocol-versions by the community. I even wrote some code to scan the frequency-bands while I was handling the remote - again, without any success as the remote was also sending on the crowded 2.4GHz
band…
Furthermore, a message to the manufacturer resulted in a non-cooperative response 😒, so I was forced to try another approach…
Reverse Engineer the Protocol?
My next idea was to reverse-engineer the protocol, spoken between the remote and the controller. Sadly, I quickly realized that I had no idea how RF works nor that I had any equipment to even capture the transmitted signals. There are some interesting communities around RF and their tools out there (like this one), but they all came with a steep price. Overall, I didn’t feel like investing ~290,-€
, just to be able to talk with the controller and then to use his (very) limited set of features.
Own Power Supply?
Due to my inability to communicate and also my missing motivation to deal with that retarded controller, I started to investigate the possibility to just replace the whole power supply and to implement my own logic. I quickly realized, that this would be quite a challenge, as the power supply just provides 60-70V
at 220mA
to all of its 5 channels and I just did not find any suitable replacement on AliExpress to begin with.
The built-in power supply with integrated controller.
Open built-in power supply, bottom right is the controller on an additionaly PCB.
As often with these kind of projects, I asked the professionals at the forum “ledHILFE”, who already helped me out on other projects. After taking a measure of the load of the power supply under different conditions…
Color | Voltage | Power | = Wattage |
---|---|---|---|
R | 42.5V | 26mA | 11.05W |
G | 63.0V | 28.9mA | 18.28W * |
B | 62.9V | 31.6mA | 19.88W * |
CW | 61.7V | 188mA | 11.6W |
WW | 61.7V | 194.9mA | 12.03W |
* Interestingly, the power supply is only rated for 15.4W
…
…we realized that it would be easier to just hack the existing power supply with an own controller. This was then affirmed, when I discovered that the existing power supply / controller was using a SMD called V1SK
, which is just a popular casing for the ME6209A33M3G
, which is just a 3.3V
low-power MOSFET - perfectly suited to be controlled by a chip from the ExpressIf family.
ESP32 with Home Assistant!
As explained before, the new plan was now to just replace the current controller of the power supply. I’ve chosen the ESP32 instead of the ESP8266 as I intended to also experiment with its Buetooth capabilities down the road. Additionally, I feared running out of free GPIO pins on the ESP8266, as I also intended to add a BME280. Here is an image of the original power supply:
Once again I hit a roadblock as I discovered that the linear regulator of the soldered controller is only capable of delivering up to 200mA
, which is by far not enough to power an ESP32. I was recommended to use an HLK-PM03, which is a 220V
to 3.3V
(~ 3W
) power supply module instead… Here is a picture of the assembled ESP32 with the attached BME280 and prepared lines for the channel controls. I also strongly recommend you to program the ESP32 now, before you have any chance to forget and then regret it 😛.
ESP32 with all connections prepared, also with attached BME280.
😊 Isn’t the board just cute?
Now, let’s proceed to the last part of connecting the new controller to the power supply. As shown in the next picture, you have to desolder the existing controller and then connect your replacement to the correct pins. In case you are not entirely sure which pins are used for what, I recommend you to take a look at the YAML below.
Relevant pins on the power supply. The left pin is just the underpowered 3.3V
line.
The final assembly of the power supply with the ESP32, BME280 and needed power supply module.
As previously mentioned, I planned to use this light with my Home Assistant instance, which lead me to choose the ESPHome firmware for the ESP32. To clarify the specific pinouts and how I configured the light, here is the relevant part of the YAML-configuration. Keep in mind not to overdrive the built-in power supply, as it otherwise may overheat or catch fire…
i2c:
sda: GPIO15
scl: GPIO2
scan: true
sensor:
- platform: bme280
temperature:
name: "Temperature"
id: bme280_temperature
pressure:
name: "Pressure"
id: bme280_pressure
humidity:
name: "Humidity (relative)"
id: bme280_humidity
address: 0x76 # Somehow this sensor is not the typical 0x77
output:
- platform: ledc
pin: GPIO27
id: gpio_27
- platform: ledc
pin: GPIO33
id: gpio_33
- platform: ledc
pin: GPIO26
id: gpio_26
- platform: ledc
pin: GPIO14
id: gpio_14
- platform: ledc
pin: GPIO13
id: gpio_13
light:
- platform: status_led
name: "Status LED"
internal: true
restore_mode: ALWAYS_OFF
pin:
number: GPIO32
- platform: rgbww
id: ceiling_light
name: "LEDs"
red: gpio_14
green: gpio_26
blue: gpio_33
cold_white: gpio_27
warm_white: gpio_13
cold_white_color_temperature: 6536 K
warm_white_color_temperature: 2000 K
restore_mode: RESTORE_AND_ON
# Following are required to protect the power supply
color_interlock: true
constant_brightness: true
After modding the power supply case, gluing all the parts into place and connecting the ESP32 to my Home Assistant instance, the result looked like this (the BME280 is located right beside the wall of the aluminium case):
Modified power supply case with all parts in place.
I then enabled the lamp for the first tests and everything went perfectly fine - except only then did I realize, that I had no idea if Home Assistant is properly connected, as the ESP32 does not have a built-in LED (in contrast to the ESP8266)…
Same as before, but connected and enabled for testing.
So, let’s add a status LED now (already part of YAML from above)! I found some old LEDs from some dismantled PC cases lying around and discovered that they also work on a 3.3V
logic level. They therefore do not require any resistor or further components to just work with the new controller. After some hot glue and a burned finger, the final result looked like this:
Final result, with the added status LED.
Closing words
I hope you had fun reading this journal of my adventure, hacking a proprietary light to work with Home Assistant. Maybe you even learned something what (not) to do - anyways, have a great day! 👋