The Compact Disc is 40 years old, and for those of us who remember its introduction it still has that sparkle of a high-tech item even as it slides into oblivion at the hands of streaming music services.
If we could define a moment at which consumers moved from analogue technologies to digital ones, the announcement of the CD would be a good place to start. The public’s coolest tech to own in the 1970s was probably an analogue VCR or a CB radio, yet almost overnight they switched at the start of the ’80s to a CD player and a home computer. The CD player was the first place most consumers encountered a laser of their own, which gave it an impossibly futuristic slant, and the rainbow effect of the pits on a CD became a motif that wove its way into the design language of the era. Very few new technologies since have generated this level of excitement at their mere sight, instead today’s consumers accept new developments as merely incremental to the tech they already own while simultaneously not expecting them to have longevity. Continue reading “The CD Is 40, The CD Is Dead”→
The Internet of Things is eating the world alive, and we can’t buy incandescent light bulbs anymore. This means the Internet is now in light bulbs, and with that comes some special powers. You can turn lights on and off from a botnet. You can change the colors. This is the idea for the Philips Hue system, which is well respected among people who like putting their lights on the Internet. There are other brands — and you can make your own — but the Hue system does work pretty well.
This is what led [Marius] to create software to interface various electronics with the Hue system. It’s a project called diyHue, and already there’s a vibrant community of devs creating their own smart lights and connecting them to the Internet.
The software for this project is built in Python, and is designed to run on certain single board computers. This allows the SBC to connect to the Hue bridge so Hue bulbs can be controlled, a MiLight hub so MiLight bulbs can be controlled, or, with the addition of a ZigBee radio, all those ZigBee devices can be controlled. Right now the only thing that doesn’t work is Google Home because it requires a remote API, the Home & Away feature from the Hue app (again, remote API), and the Eneco Toon.
There really are a fantastic number of devices this software works with, and if you’re building out your Internet-connected home lighting solution, this is one piece of software you need to check out. Thanks to [cheesemarathon] for bringing our attention to this. He also liked it so much he’s now contributing to the GitHub. Very cool.
The Philips Hue range is a great way to add wirelessly controllable lighting to your home, but the protocol is proprietary which makes it difficult to add our own custom hardware. [Peter] found a way to create his own Hue compatible devices based on cheap JN5168 modules that are able to connect to the Hue bridge. This means you can roll out your own lamps using cheap RGB or White LEDs, a power supply and the JN5168 Zigbee Light Link module.
He started off by trying to clone a Zigbee Light Link device to a MeshBee — Seeed studio’s open source Zigbee Pro module based on the NXP JN5168. Even though the MeshBee used the same device as a Hue lamp, it would not connect to the Hue bridge. But another clone lamp called Innr that he purchased from the local hardware store did connect quite easily. Using NXP’s open source tools, he was able to download the flash and EEPROM contents from the Innr and copy them to the MeshBee which did the trick.
After the EEPROM transfer trick, he figured out how to modify the two keys used for the ZigBee protocol — one for Home Automation and the other for the Light Link. With this final discovery he is able to take the ZigBee Light Link demo project, edit it using Beyond Studio, and then load the binaries on the MeshBee device so it can connect to the Hue bridge.
All of this work culminates in two custom firmware binaries; one for white dimmable lights and another for RGB dimmable ones. It even runs on these cheap JN5168 breakout kits he found for a few bucks. With all of the software taken care of, and having cheap ZigBee Light Link compatible modules on hand, building low cost Hue compatible lights becomes pretty straight forward.
Building on the work of others (as is always the case!) [pepe2k] managed to get root access on the Philips Hue Bridge v2 IoT light controller. There’s nothing unusual here, really. Connect to the device over serial, interrupt the boot process, boot up open firmware, dump the existing firmware, and work the hacker magic from there.
Of course, the details are the real story. Philips had set U-Boot to boot the firmware from flash in zero seconds, not allowing [pepe2k] much time to interrupt it. So he desoldered the flash, giving him all the time in the world, and allowing him to change the boot delay. Resoldering the flash and loading up his own system let him dump the firmware.
The “hacker magic” glossed over in the intro consisted of poking around until he found a script that was called on every boot. This is how [pepe2k] gets around not knowing the root password. The script compares the hash of the typed password with an environment variable, set with the hash of the correct password. Changing that environment variable to the hash of his favorite password (“root”) made him master of the box.
And just in case you’re one of the few Hackaday readers who doesn’t understand why we do these things, besides the fact that it’s just fun, consider Philips’ (eventually retracted) clampdown on the interoperability of this very device, or Google’s red bricks. The fatal flaw of IoT devices is that they place you at the whims of companies who may decide that they’re not making enough money any more, and shut them down. Keep your hacking skills sharp.
The 900-pound gorilla in the corner of the Internet of Things (IoT) hype that everyone is trying to ignore is interoperability. In the Internet of Internets (IoI) everything works on a few standards that are widely accepted: IP and HTML. The discrepancies are in the details and the standards wars are in the past. Websites are largely interoperable. Not so in the wild-west ethos of the IoT.
Philips makes a line of ZigBee-enabled RGB lightbulbs that took the enthusiast community by storm. And initially, Philips was very friendly to other devices — it makes a ZigBee-to-WiFi bridge that would let you control all of your ZigBee-based lights, regardless of their manufacturer, from your phone. Until now.
Philips has just rolled out a “Friends of Hue” certification process, and has since pushed out a firmware update where their Hue bridges stop interoperating with non-certified devices. You can read Philips’ version of the story here.
Philips Locks Out 3rd Party ZigBee Hardware
The short version is that, ZigBee standards be damned, your future non-Philips lights won’t be allowed to associate with the Philips bridge. Your GE and Osram bulbs aren’t Friends of Hue. DIY RGB strips in your lighting mix? Not Friends of Hue. In fact, you won’t be surprised to know who the “Friends of Hue” are: other Philips products, and Apple. That’s it. If you were used to running a mixed lighting system, those days are over. If you’re not on the friends list, you are an Enemy of Hue.
Their claim is that third party products may display buggy behavior on a Philips network, and that this loads up their customer-response hotlines and makes people think that Philips is responsible. Of course, they could simply tell people to disable the “other” devices and see how it works, putting the blame where it belongs. Or they could open up a “developer mode” that made it clear that the user was doing something “innovative”. But neither of these strategies prevent consumers from buying other firms’ bulbs, which cost only 30-50% of Philips’ Hue line.
While Philips is very careful to not couch it as such, the Friends of Hue program really looks like an attempt to shut out their competitors; Philips got an early lead in the RGB LED game and has a large share of the market. As they say themselves in their own press release “Today these 3rd party bulbs represent a minimal fraction of the total product connected to our bridges so the percentage of our users affected is minimal.” And they’d like to keep it that way, even though the people they’re hurting are probably their most vocal and dedicated customers.
And while we, with our manual light switches, laugh comfortably at the first-world problems of Hue consumers, we have to ask ourselves whether we’re next. Today they come for our RGB lightbulbs, but tomorrow it might be our networked toasters. A chilling thought!
Snark aside, the IoT brings two of the saddest realities of the software world into your home appliances: Where there’s code, there’s vulnerabilities, and when you can’t control the code yourself you aren’t really in control. You may own the lightbulb, but you’re merely licensing the firmware that runs it. The manufacturer can change the rules of the game, or go out of the product line entirely, and you’re high and dry. What can you do? Pull out your JTAG debugger.
Of course it’s insane to suggest that everyone needs to become an embedded-device firmware hacker just to keep their fridge running. As we’ve written before, we need to come up with some solution that puts a little more control in the hands of the ostensible owners of the devices, while at the same time keeping the baddies out. We suggest a press-to-revert-firmware button, for instance. When Philips pushes a non-consumer-friendly upgrade, you could vote with your fingertips — but then you’d miss out on bug fixes as well. Maybe it’s better to just give in an learn to love Windows 10.
There are no easy solutions and no perfect software. The industry is still young and we’ll see a lot of companies staking out their turf as with any new technology. It seems to us that IoT devices leave consumers with even less choice and control than in the past, because they are driven by firmware that’s supposed to be invisible. It’s just a lightbulb, right?
What do you think? Any ideas about how to put the power back in the hands of the “owner” of the device without everyone’s refrigerators becoming botnet zombies? Let us know in the comments.
“We underestimated the impact this would have upon the small number of our customers who currently use uncertified lights from other brands in the Philips Hue system. We have decided to continue to enable our customers who wish to integrate these uncertified products within their Philips Hue system.”
Old Mini and Mainframe computers often had huge banks of diagnostic lights to indicate the status of address, data and control buses or other functions. When the lights blinked, the computer was busy at work. When they stopped in a particular pattern, engineers could try and figure out what went wrong by decoding the status of the lights.
[Folkert van Heusden] has an old MSX-based Philips VG-8020 computer and decided to add his own set of BlinkenLights to his system. The VG-8020 was a first generation MSX released in 1983 and featured a Zilog Z80A microprocessor clocked at 3.56 MHz, 64KB of RAM, 16KB of VRAM, and two cartridge slots.
The cartridge slots of the MSX are connected to the address and data buses in addition to many of the control signals, so it seemed logical to tap in to those signals. Not wanting to play around with a whole bunch of transistors, he opted to use an Arduino Nano to connect to his computer and drive the LEDs. In hindsight, this seemed like a wise decision as it allowed him to do some processing on the incoming data before driving the LEDs.
Instead of creating a new PCB, he cut open one of his beloved game cartridges. A switch was added to the slot select control pin (SLTSL) and eight wires soldered directly to the data bus. These were hooked up as inputs to the Arduino. A bank of eight LEDs with limiting resistors were connected to outputs on the Arduino. A quick test confirmed it all worked, including the switch to enable / disable the cartridge. He had to experiment with the code a bit as the LEDs were initially blinking too fast.
A couple of months later, he upgraded his BlinkenLight display to include the 16 bit address, 8 bit data and 8 lines for control signals. To do this, he used two MCP23017 – I2C 16 input/output port expander chips. For the LEDs, he installed a bank of four NeoPixel LED bars. A Pro-Mini takes care of the processing, and a custom PCB in the cartridge format houses all of it neatly. Check out the two videos below showing the BlinkenLights in action.
[Martin] recently purchased a Philips LivingColors lamp. It’s a commercial product that basically acts as mood lighting with the ability to change to many different colors. [Martin] was disappointed with the brightness of his off-the-shelf lamp. Rather than spend a few hundred dollars to purchase more lamps, he decided to modify the one he already had.
[Martin] started by removing the front cover of his lamp. He found that there were four bright LEDs inside. Two red, one green, and one blue. [Martin] soldered one wire to the driver of each LED. These wires then connected to four different N-channel MOSFET transistors on a piece of protoboard.
After hooking up his RIGOL oscilloscope, [Martin] was able to see that each LED was driven with a pulse width modulated signal. All he had to do was connect a simple non-addressable RGB LED strip and a power source to his new driver board. Now the lamp can control the LED strip along with the internal LEDs. This greatly extends the brightness of the lamp with minimal modifications to the commercial product. Be sure to check out the video below for a complete walk through. Continue reading “Increasing The Brightness Of A Philips LivingColors Lamp”→