Philips Says: No Internet Of Things For You!

December 15, 2015 by Elliot Williams 159 Comments

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 hub shown on the right is what's being locked down. — The hub shown on the right is what’s being locked down.

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.

Who owns the IoT?

This Techdirt response to the situation is positively apoplectic, and there’s been the predictable flood of tirades in the comments on Slashdot. [Joel Ward], who in January was celebrating the ability to afford enough colored lights to appease his son is not so happy anymore.

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.

Thanks [djxfade] for the tip!

Edit: Shortly after we ran this piece, Philips backed down:

“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.”

3D-Printing The Most Ornate Room

December 12, 2015 by Elliot Williams 21 Comments

It’s no secret that we like 3D printing, but Artist and architect [Michael Hansmeyer] really likes 3D printing. So much so that he’s based his entire career around exploring the artistic possibilities of what he calls “computational architecture”.

We first fell in love with [Michael]’s work “Columns” because it was both daring and relatively low-budget at the same time. He made a series of architectural-sized columns out of cross-sections of laser-cut cardboard. Why cardboard? Because his goal was to make the columns as complex as possible and the current range of 3D printers couldn’t give him the resolution he wanted.

Fast-forward to “Digital Grotesque”. Now [Michael] has access to a large-scale sand printer, and the license to go entirely nuts. He makes a space reminiscent of a Rococo grotto, but full of so much detail that you can’t really take it all in: it’s nearly fractal. Some stats: 11 tons of printed sandstone, 260 million surfaces, 30 billion voxels. We’re stoked that we don’t have to dust it!

His latest piece, “Arabesque Wall” is partly organic and elegant, and part Aliens. If we can play art critic, we think it’s beautiful. Go click through the portfolio. (And although they never got printed, we really like some of the “Voxels” series of cellular-automata pieces.)

From new paint materials opening up new color possibilities to new instruments enabling entirely different types of music, art, and technology mutually inform each other much more than we often appreciate. In ten years time, we’ll be looking back on this work and saying “this piece looks good” and “that piece looks bad” instead of “wow, amazing tech!”. But for now, we’re also content to wallow in the “wow”.

Squash Your ESP-8266 Bugs With ESP-gdbstub

December 12, 2015 by Elliot Williams 14 Comments

We hope we’re not insulting you by suggesting this, but it’s possible that even the best among us may be faced with bugs in our embedded code from time to time. And while we’re great fans of printf debugging over the serial port, and its high-speed equivalent — flipping a GPIO pin — there’s a time when your bug is so deep that having a real debugger is the best way to dig it out.

[slaff] has been doing some great work documenting C/C++ programming on the ESP-8266, mostly using Eclipse and some of the Arduino libraries. In the fourth part of his series of posts, he walks through using a couple debugger options for the ESP. What makes this all work is the ESP-gdbstub code from Espressif themselves. gdbstub looks great — it works both with the standard SDK as well as with FreeRTOS, so you can debug your ESP-8266 code whether it’s in an OS or on the bare metal. And all this just using the standard serial connection that’s used for programming.

Now, this still may not help with timing-related bugs. ESP-gdbstub uses the serial port, after all. But having the ability to set breakpoints and interactively inspect what’s going on in the chip’s memory is priceless, and doing so with no extra hardware connections is brilliant.

Continue reading “Squash Your ESP-8266 Bugs With ESP-gdbstub” →

Encryption For Arduino With Spritz

December 12, 2015 by Elliot Williams 4 Comments

Hackaday.io user [Abderraouf] has written an implementation of the new(ish) Spritz cipher and hash for Arduino. While we’re not big enough crypto-nerds to assess the security of the code, it looks like it’s going to be pretty handy.

Spritz itself is a neat cipher. Instead of taking in fixed blocks of data and operating on them, it allows you to process it in (almost) whatever chunks it comes in naturally, and then extract out the encrypted results piecewise. It works both as a two-way cipher and as a one-way hash function. It looks like Spritz is a one-stop-shop for all of your encryption needs, and now you can run it on your Arduino.

In case you are afraid of new implementations of new ciphers (and you should be), Spritz’s pedigree should help to put you at ease: it was developed by [Ron Rivest] to be a successor to his RC4 algorithm, and it incorporates a lot of the lessons learned about that algorithm over the past. This doesn’t exclude subtle flaws in the implementation of the library (no offence, [Abderraouf]!) or your work downstream, but at least the underlying algorithm seems to be the real deal.

[Abderraouf] links it in his writeup, but just for completeness, here’s the Spritz paper (PDF). What crypto libraries do you currently use for Arduino or microcontroller projects? We’ve been fans of XXTEA for ages, but more because it’s simple and small than because it’s secure. Spritz may be simple enough to implement easily, and still more secure. Sweet.

Beautiful Sidewalk Graffiti Machine

December 11, 2015 by Elliot Williams 22 Comments

Our hero [Alex] just built a sidewalk graffiti machine, and it’s a beauty to behold, so make sure you check out the video below the break. But don’t neglect [Alex]’s blog, and the build videos throughout. (Nice t-shirt in the wheel-making video, BTW.)

The machine itself is basically a two-meter wide printer where the roller is replaced with drive wheels. The frame, made of plywood, looks great and helps keep the machine light weight. Everything is done with DC motors and timing belts, which means motor encoders and closed-loop control in the firmware. It connects via a WiFi serial bridge, made with an ESP8266, to [Alex]’s cell phone.

Everything, from plans to software, is available on [Alex]’s GitHub for the project.

Continue reading “Beautiful Sidewalk Graffiti Machine” →

Embed With Elliot: Debounce Your Noisy Buttons, Part II

December 10, 2015 by Elliot Williams 112 Comments

If you’ve ever turned a rotary encoder or pushed a cursor button and had it skip a step or two, you’ve suffered directly from button bounce. My old car stereo and my current in-car GPS navigator both have this problem, and it drives me nuts. One button press should be one button press. How hard is that to get right?

In the last session of Embed with Elliot, we looked into exactly how hard it is to get right and concluded that it wasn’t actually all that bad, as long as you’re willing to throw some circuitry at the problem, or accept some sluggishness in software. But engineers cut corners on hardware designs, and parts age and get dirty. Making something as “simple” as a button work with ultra-fast microcontrollers ends up being non-trivial.

And unsurprisingly, for a problem this ubiquitous, there are a myriad of solutions. Some are good, some are bad, and others just have trade-offs. In this installment, we’re going to look at something special: a debouncer that uses minimal resources and is reasonably straightforward in its operation, yet which can debounce along with the best of ’em.

In short, I’ll introduce you to what I think is The Ultimate Debouncer(tm)! And if you don’t agree by the end of this article, I’ll give you your money back.

Continue reading “Embed With Elliot: Debounce Your Noisy Buttons, Part II” →

Texel: Art Tracks You, Tracks Time

December 9, 2015 by Elliot Williams 6 Comments

French robot-artist [Lyes Hammadouche] tipped us off to one of his latest works: a collaboration with [Ianis Lallemand] called Texel. A “texel” is apparently a time-pixel, and the piece consists of eight servo-controlled hourglasses that can tip themselves over in response to viewers walking in front of them. Besides making graceful wavelike patterns when people walk by, they also roughly record the amount of time that people have spent looking at the piece — the hourglasses sit straight up when nobody’s around, resulting in a discrete spatial representation of people’s attentions to the piece: texels.

We get jealous when we see artists playing around with toys like these. Texel uses LIDAR scanners, Kalman-filtered naturally, to track the viewers. openFrameworks, OpenCV, and ROS. In short, everything you’d need to build a complex, human-interactive piece like this using completely open-source tools from beginning to end. Respect!

Continue reading “Texel: Art Tracks You, Tracks Time” →