It can be difficult to resist the impulse buy. You see something interesting, the price is right, and even though you know you should do your research first, you end up putting it in your cart anyway. That’s how [Tobias Girstmair] ended up being the not-so proud owner of a LEDBERG RGB LED strip from IKEA, and what eventually pushed him to replace wimpy original controller with an ESP8266.
So what was the problem with the original controller? If you can believe it, it was incapable of producing white light. When IKEA says an LED is multi-color, they apparently mean it’s only multi-color. A quick check of the reviews online seem to indicate that the white version is sold as a different SKU that apparently looks the same externally and has confused more than a few purchasers.
Rather than having to pick one or the other, [Tobias] decided he would replace the original controller with an ESP-03, hoping that would give him granular enough control over the LEDs to coax a suitably white light out of them. He didn’t want to completely start from scratch, so one of the first decisions he made was to reuse the existing PCB and MOSFETs. Some handy test points on the PCB allowed him to hook the digital pins of the ESP right to the red, blue, and green LED channels.
Then it was just a matter of coming up with the software. To keep things simple, [Tobias] decided to create a “dumb” controller that simply sets the LED color and intensity according to commands it receives over a simplified UDP protocol. Anything beyond that, such as randomized colors or special effects, is done with scripts that run on his computer and fire off the appropriate UDP commands. This also means he can manually control his newly upgraded LEDBERG strips from basically anything that can generate UDP packets, such as an application on his Android phone.
It might not be the most robust implementation we’ve ever seen, but all things considered, it looks as though this modification could be a pretty good way to get some cheap network controlled RGB lighting in your life.
just “udp”? Why not a framework?
You could use druffle, which needs huffle, to interface with draggle, running on the booble service, which runs on the frabble architecture, on the duble servers, communicating with a nuffle client, linked to a puffle account, which uses druffle to fluffle the socksifier.
Seriously, nice solution to use plain old udp. Latency measured in uSec, and not seconds, or hours of debugging crap overblown frameworks, running one someone else’s servers.
Mostly agree, assuming you care about things like timing and latency. :)
I might consider implementing this though as your UDP protocol: https://www.qlcplus.org/docs/html_en_EN/e131plugin.html
Very little extra work, and then sequencers could control it..
you almost had me at the first sentance..
And you’re right, not enough bloatware in this project! Why write a few lines of code that might run 1000 times faster when you can use someones library that has been built using another, which was built…
Y’all are right, this is rad. Using plain, unauthenticated UDP means that I can turn this dude’s lights on and off, which is awesome and good. Using an authenticated framework? Pfffft dum
If you have UDP bots on your internal home network or the ports wide open to the intranet, you got 99 real problems, and the status of your ikea lights isn’t one of them.
My point is that, though UDP may be appropriate here, designing for the average case requires more consideration. You can’t make assumptions that people are smart with their network. So while appreciating the value of quick and functional, it’s worth understanding that nothing is all of simple, correct, and universally applicable.
@Sarah: “You can’t make assumptions that people are smart with their network.”
Well, judging by the amount of frameworks going around, the amount of work necessary to get them to run, and the extremely limited added usefulness once you do get it to run, not to speak of just as much lack of security as your average front door, actually makes ME think:
“You can’t make assumptions that framework developers are smart with your network.”
So if you’re not smart with your network, and they are not either, then who is?
Well, at least I can assume that most people who read this, are. :)
I would venture a guess that if you’re hacking like this, chances are you are a little more than comfortable with your LAN config.
you can’t without breaching my wifi first, which i consider to be the authentication layer for this. and once you’ve done that, i’ve got far worse problems than some dinky led lights.
this isn’t some mass produced iot-device–its a one-off project.
I’ve done loads of similar things with some RFID fun stuff, and it’s perfectly valid. Rolling your eyes at people that understand that any DIY system is likely to miss edge cases that standards-compliant protocols cover, though, is a level of elitism that borders on hubris. To genuinely believe that reimplementing some ersatz auth is sufficient for all cases is ludicrous. Security, if you’re invested in doing it “right” (or at least with rigor), is a difficult thing. Which is why it’s rational to use the collected work of innumerable experts who have been studying the art of making data transmission secure and reliable since before the triode was a glimmer in Eccles’ eye. At least, for many cases.
Prove it.
This ‘joke’ is getting a bit tedious now. Can you come up with something more original, please?
I’ts not a joke. These days “hello world” “compiles” to about 30Mb, due to crap frameworks.
Everything needs ADs, telemetry, data collection and exfiltration, and of course, has one or more pieces that runs on someone else’s servers.
Forgive me, this is the third or fourth time you’ve made the druffle/huffle comment – it has all the appearances of a troll. And the buzzword bingo above only confirms it.
but it’s true. people who use these “frameworks” are the “I can programming!” types. Not really understanding what they are using or putting together.
not everyone understands udp, which is fine, there are plenty of “I can programming!” tutorials I can find on other sites, where I have to pollute my machine with a few GB of crap to get “hello world” to compile and run, in just minutes on a i7 with 32gb of ram.
some of us come from “real” programming backgrounds, ie: understanding assembly, cycle counts, and dealing with limited storage space.
I don’t need a few GB of crap to get “hello world” working.
But hey, good work on that java “hello world” program that only needs 500Mb of crap.
if you think it is a troll then follow internet rule #1 and dont feed the trolls. If he keeps making the exact same comment and gets replies to it then contextually it makes sense even if you find it repetitive.
Thats another thing, who are you to police what someone else says just because you find it repetitive? you could have easily just scrolled past and let it be, or maybe chosen to come up with some unique and substantive post of your own.
Best comment ever.
Randomize it by sending it the UDP feed from a game of the old Macintosh classic game BOLO?
With this mod, the original Ikea product just got a lot more interesting. Would like to see somebody come up with a 3D printed enclosure for the new electronics rather than a piece of cardboard though. Also seems like the DC regulator he used is uncessarily beefy, unless I’m missing something?
author here. yes, extremely oversized. but it was the cheapest and simplest option i could get on short notice
Greetings Tobias. Use what you can get easily or already have. I totally get it.
You could make this universally useful and controllable from sequencers with just a little modification to how you are handling your existing UDP packets. Take a look at https://wiki.openlighting.org/index.php/E1.31
Probably can skip the client side stuff then too.
I tried to do this with the cheap RGB 10W LED area lights you can find with just IR remotes, but alas they were all epoxy potted and not worth the work.
Cheers.
I wonder if IKEA (or more likely the company they purchased it from) made a decision that having “white” and “multi-color” capability was too much for the power supply, so they made it either/or.
Just a guess, nothing more…
I have an actual commercial product that does something very very similar to this, but instead controls vast square meters of LED strips for advertising purposes. It uses UDP as well, the control packet consists of a simple UDP datagram of 255, 0, R, G, B, Checksum. The reciever is an arduino leonardo with a W5100 ethernet shield, and 3 mosfets with some resistors and status LEDs on the enclosure. It’s ethernet, as we needed 100 percent reliability in signal transfer.
No massive frameworks or cloud services or mqtt or fancy stuff.
The program that sends the UDP data over the network to the arduino+W5100 unit is a grand total of 400 lines of code and compiles to an EXE of 150kb. Sadly i had to use the SDL framework to send UDP data, but other then that, “KISS” keep it simple stupid.
UDP over Ethernet is not 100% reliable…
Oh noes! it’s only 99% reliable. I really need 100% availability of my lighting controller, or I might have to send the packet TWICE!
Quick, I’ll use the booble framework, on the dribble servers, running the frooble patches, using the dooble archiecture, running the frabble server, using my nuffle account to communicate with the puffle server, using a linked druffle account.
there is no way that could fail, since third party servers have 100% reliability.
I just need to have a small quad core computer, running 24×7 to run all these frameworks, with a few GB of ram, and a few hundred GB of disk space.
A single computer will never cut it, what you need is a cluster.
Multiple computers, and multiple servers, in multiple data centers, on redundant connections, with backup power.
I *NEED* to be able to control my lights with 99.999% reliability.
I would have just bought another magichome controller to drive the LEDs. Absurd of ikea to not do white out of the box, also guess it meant you could only get the circus colours at full saturation from the strip too.
Remember, people here don’t design for the “average” user.
The average user would be fine with a server running on draggle, using the fraggle architecture, running on the dooble servers, using the frooble patches, on the doodle framework, requring a nuffle account, linked to the puffle service, which enables druffle to fluffle the socksifier and change the colors. Latency would be about 1-2 minutes, at most!
the phone application would need access to:
-contacts
-make and receive calls
-manage phone calls
-send receive data
-camera and microphone access
-read and send email
-read and send SMS
-read/write files
the phone app would weigh in at only 300Mb, and of course, lets not forget all the useful ad frameworks!
If you have open udp to/from your router, you have other problems. I don’t see the need to burn a few hundred watts of someone else’s computing power to turn on/off things.
dynamic dns, and routers have solved this many many years ago.
but hey, feel free to give away data.
It was funny the first time you posted that, but you didn’t need to repeat the joke so many times.
I wish it was a joke. It seems that “programmers” are stuck in this mode.
And you seem to be stuck in the “telling the same frooble/doodle/nuffle joke” mode, that’s what I’m saying ;-P There are certainly outliers, don’t get me wrong, and I don’t appreciate when I need to work with a service that is super slow (which doesn’t happen very often). I also appreciate being able to get free SSL out of HTTPS, free graphs/storage out of something like Thingspeak, and all the cool stuff that MQTT provides. When I need speed or un-bloatedness, I drop some things, when I need more features or more abstraction, I add some things to the stack. I also use assembly when needed.
There are valid reasons to dump on folks using assembly where it’s not suitable, as much as there are valid reasons to dump on folks using a stack of services where it’s not suitable. There is hardly a reason to repeat the same joke 4 times in a row, we get it, you are very passionate about the topic, but it’s hardly even relevant to the article once you spread it out over such a wide area.
Give it about 5 years or so and when large parts of the internet and IoT devices start failing because the 1435th cloud based framework to be invented to do the same thing as all the others is turned off, suddenly all sorts of things stop working.
We already see i happening in isolated cases but even with the large enterprise orgs.
He may be repeating himself, but he’s just ahead of the curve.
5 years? How about 5 months?
everytime a cloud provider is announced, 5 different ones close up shop.
Greenwave “smart bulbs” gone in less than 2 years
Remember Logitech “smart” remotes? Remember the certificate that wasn’t renewed?
Amazon dash – dead
Just contributing more electronic junk.
The Next Hackaday Prize:
I’d like to propose for the next Hackaday Prize:
The most trivial project, that requires the most frameworks, and over powered solution.
ie: Using 3 different services, running on a i7, to turn on a single LED from anywhere on the interwebz.
Points awarded for:
-Most third party services
-Most data exfiltrated
-Most creative use of advertising
-Most waste of disk space, 1 point per 100Mb
-Highest latency, 1 point per second
-Most points of failure, 1 point per failure point
Disallowed:
-No 555’s
-No arduinos or raspberry pi’s
-Nothing under an i7
I appreciate that you made a post without the huffle/druffle kerfuffle.
(really!)
Ladies and Gentlemen, I now present the name of the proposed Hackaday Prize framework : Kerfuffle!
Seriously, that makes a great name for an IoT framework!
Kerfuffle will be so great, almost everyone will hear of it before it breaks under its own weight.
I can’t wait to use Kerfuffle
Now all I need is a computer with a water cooled overclocked i9, and 1 TB of RAM and I can finally hope to install it! An additional 1TB to actually run it though.