These days, home appliances are equally as likely to have soft buttons and rotary encoders as they are to have a simple old clunk/clunk power switch and an analog knob for controls. This is all well and good if the device aligns with your personal philosophy about how such controls should work; otherwise, it’s absolutely maddening. [j-zero] ran into this problem with their ORSALA lamp from IKEA, and set about rectifying the problem with some custom firmware.
The ORSALA lamp uses a rotary encoder for setting both brightness and color temperature, with a button to toggle modes. A long press is required to switch the lamp off. The custom firmware modifies this behaviour, such that the lamp can be switched on and off with a simple button press. Turning the encoder modifies brightness, and turning it to minimum switches the lamp off too. Meanwhile, the less commonly used color temperature setting can be modified by using the button while adjusting the encoder.
The hack was executed by reprogramming the ORSALA’s onboard microcontroller, the STM8S003F3P6, via its SWIM interface. The pads for the interface are easily located on the board, making the hack easy. Other than the inputs, the lamp packs separate TTP932 LED drivers for the warm white and cool white LEDs, making it easy to code a custom firmware to handle all the necessary functions.
It’s a great example of a hacker taking control of their own device and remaking it to suit their needs. Of course, if you want to go for another hacker trope, just stuff a Raspberry Pi in there instead!
Very nicely done – and extra cool that you just reprogrammed the existing mc rather than stuffing a dev board in there.
Mmh, the FW might be nice but:
* There is no license. This mean we can just look at code. Not copy, compile or run it, if you follow the rules. I see someone already noticed it.
* There is a copy of what appears to be original FW. I’m not sure this is legal, without IKEA’s permission.
* The choice of needing to press to button while turning is really awkward for me. A long press to switch mode is what I prefer in these cases – but de gustibus… and it’s of course easy to change!
This is very common for an articles on Hackaday. Even when articles authors write “open source”, it can be just 100% copyrighted code without any permission.
I’ve already created >70 tickets for code authors, with request to use any popular opensource license. Most of them are closed with a positive decision. 16 tickets still open.
Great! I noticed that, and I just made a PR with MIT license.
As the underlying library is LGPL2.1, and source and methods for relinking are trivially provided, I think it’s the best option.
And yes, that’s also a pet peeve of mine, when I notice it I always raise an issue or make a PR.
Looks like this is already fixed: now it’s “beer ware” license – one I’ve seen, but not sure it actually meets the osi definition or the dfsg. Strangely, though, the “unlicense” does actually get the nod, so maybe if anyone reading wants a “do anything” license, that’s worth a look for next time. (I don’t remember if the WTFPL is as widely accepted). Oh, license proliferation….
Yes, it is strange choice, but anyway it is much better than no licence.
IANAL: To my understanding “open source” alone doesn’t imply anything else than that the source code is shown. (Not to mention that all code is 100% copyrighted, but the license is the only thing allowing any use, derivative works, or giving the rights away.) It is easy to attach the “free to use” type interpretations to the term, as they often go hand-in-hand. And for many private uses, people don’t care about license as long as the job gets done. My impression is that this is slowly changing towards more awareness on the necessity of licenses.
I have to agree with newbrain on the “hold to change color temp” feature. I’m currently trying to find a equivalent but with only one touch interface. So far I have on/off on single tap, change brightness on hold. But I’m not sure what would be best for color temp changing : holding longer, double tap, something else…
I thought that too until I tested it. It’s sound arkward, but doesn’t feel arkward.
As, said, very personal taste!
And kudos for fast acting on the license and original FW issues!
You could do what I think is an under-used interaction: tap then tap and hold. (Down, up, down…) Distinguishes it from just regular hold, but providers the same variable-duration input.
Also, long press, have the lamp sort of pulse in ack, and you dial (without pressing) the knob to adjust the colour. and either long press when done, or after a few seconds of no adjustments, the lamp drops out of adjustment mode.
I think a very interesting detail that was not mentioned in the article is that hacker, j-zero, used the Arduino software framework to do this, unless I’m missing something here. His main source code is in orsala_hack.ino. This has very interesting implications to hacking other devices. If they have a Arduino-compatible micro (or a close-enough compatible one), shooting new code into it becomes a lot simpler. Great job!
Oh, I have a few ideas on how to improve this even more, and putting them into Arduino code should not be too much of an issue, it’s all very straightforward in there. There are really nice LED desk lights out there, but they are universally horrible when it comes to user interface and functions. Easy hackability turns this one into a prime target.
For even more hackability there are a heck (no pun included) of unused pins. For example UART is not used at all. But they are not as accessible as the SWIM interface.
Also the power supply is 19.2 volts an can possibly replaced with a USB-C power delivery chip.
Long-pressing is the worst cancer of UI design. Nice to see people fighting it
Especially when you use a long press to turn off a lamp!
Thank you.
I don’t have a problem with long press, except when it’s used for the more frequently used interface – on/off should (IMO) be a quick tap, and a long press is some other action (if implemented). I have a floor lamp that is much the same here – long press to turn it off, but short to cycle through colour. Er, which do you think I’m going to do more often? Also, the lamp I mention doesn’t save colour and intensity to flash, so if it’s plugged into a switchable outlet, when you switch it back on, it’s back to a factory default, which is nearly as lame as the poor long/short assignment.
It takes for-bloody-ever to turn off a Playstation 4.
A lamp with firmware? Hmm, what’s going to be next regarding objects in which you don’t expect firmware?
Almost every modern electronic item has firmware in it somewhere. There’s no reason not to when the alternative to a 3 cent microcontroller is a dollar’s worth of discrete circuitry.
Not everything electric is electronic (yet).
what’s the current draw when you turn it off?? That’s the normal reason I hate these things..
Good point. I’ll measure this today. I’m already aware of that and trying to implement the halt/deep sleep mode on the STM8 µC. I don’t think the original firmware implemented that.
The lamp draws ~30mA when turned of and my current firmware and ~35mA with the original IKEA firmware. I will try to reduce that in later releases.
30 mA where? At the power plug, at 230V? According to the datasheet the STM8S is supposed to draw a maximum of 4mA (typically ~1.8mA), and that’s at 3.3V. I don’t believe any amount of code optimization will make a significant difference there. Someone CMIIW please.
Yes, at the powerplug on 230V.
And you are right. I tried to put the µC to HALT-Mode. There is no real change. So will not implement that feature.
Unsurprising about the MCU and its part in power consumption. That’s still a bit shocking, though. 30-35mA at 230V equals roughly 7-8W. What’s going on there, is the PSU so horribly inefficient?
That’s outrageous, and much, much worse in climates that need airconditioning. Thank you for checking, I know to avoid this lamp now.