When looking at the piles of cheap RGB, Bluetooth-controlled LED strips you can find for sale just about anywhere these days, integrating them into a home-automation setup is very tempting. Normally these strips are controlled via a special smartphone app, that speaks whatever dodgy protocol was thrown together for the LED strip controller in question. Reverse-engineering this Bluetooth protocol is fairly easy these days, as [Will Cooke] describes in a recent tutorial, although for him there was a bit of a tragic ending with one particular RGB set.
With previous experiences reverse-engineering the Bluetooth protocol with Wireshark under his belt and having published the BJ_LED repository for LED strips that use the MohuanLED app, reverse-engineering this new LED strip with the associated “iDeal LED” app seemed fairly routine. Initially it was indeed routine, with just a curveball in the form of some encryption that the Jadx decompiler used on the app couldn’t help with. Fortunately the key ended up floating around on the internet, and the protocol was wide open. That’s when disaster struck.
While trying to throw payloads at the LED controller to find hidden modes and settings, [Will] found that he could indeed increase the brightness beyond what the app supported, but poking at lighting modes beyond the 10 presets gave a nasty shock. Modes 1 through 10 worked fine, 11 also did something new, but when the controller was asked to switch to mode 12, it shut off. Permanently. Whether this corrupted the firmware or caused some other issue is unknown, but it’s a clear warning that reverse-engineering comes with potentially fried hardware.
We hope that [Will] can get an autopsy performed on this controller to see the cause of this seemingly permanent failure that persisted across hard resets and disconnecting from power overnight. The protocol for this controller has been published on GitHub for those who’d like to take their chances.
LED lights: LadyAda, CC BY-SA 4.0.
Everyone knows you should only turn it up to 11.
why don’t you make 10 a little bit louder?
Because those who desire 10 would be annoyed at the gap between 9 and the now louder 10.
I liked analog dials; people underestimate how many digital levels they really need to span any given range especially if it’s for volume. So many times I want somewhere between 0 and 1…
Even Spinal Tap knew that!
Replace the controller with an ESP8266 or ESP32 running WLED.
Or Pico W
WLED unfortunaltelly doesn’t run on Pico W.
Call me Dr Doofenshmirtz the way I put self-destruct buttons in my firmwares
Perhaps it’s not some sort of nefarious self-destructing firmware trick but something more ordinary, like an over current condition frying something in the USB adapter. In keeping with the cheap junk vibe of those “USB powered fairy lights” the USB adapter is likely to be complete garbage, too. Hope you didn’t fry a USB port on your computer!
Pretty good guess, reading through his probing he found that the app would not even send a full brightness code of FF to the string. Possibly a cheap way to limit current?
For almost any of these strips, step 1:
Cut the controller off and throw it away. Or at a minimum, check its output voltage (12v vs 5v) and scope the data pin to determine which protocol it is using.
Step 2: Drive the strip with FadeCandy, WLED, etc.
That’s exactly what I did with a strand from noname Chinese vendor Aoycocr – the controller was useless, now I’m feeding it with an ESP32 running WLED and it’s working great. (Why not buy something from one of the more reputable WS281x vendors? They were the only individually controllable C9 strands I could find that would arrive in time for the holidays from Amazon.). Now instead of the rather useless modes accesible from a proprietary Bluetooth protocol, I’ve got sound reactive C9 lights driven by WLED + LEDfx
Exactly. You can literally get an Arduino (or a cheap Elegoo clone), install FastLED libraries and cut and paste code off GitHub if you don’t feel like learning it.
Or easier yet, just download a precompiled WLED build and flash it.
There are problems with serial RGB LED’s emitting a ton of EMI and trashing the ISM band, especially easy when your house has the LED strips all over the outside, like an antenna. I think it’s the PWM or LED driver internal clock- not the serial data daisy-chain. I did see a newer APA102 or WS28xx with softened edges, slower slew rates.
That’s unusual as WS2812 for example runs at 800khz. It is a square wave signal but only to the first led. The next led gets a repeated signal that’s delayed so it’s not phase aligned at all and when the LEDs are close together there’s not really much of an antenna.
seems more like you have no clue how any of this works…
sounds more like a bad power supply making a lot of RF noise.