A really interesting thing happens if you have a reasonably long standing, stable, and documented API in the wild for a while. Other people start building their own implementations to serve different needs. My current favorite example of this is the emulated_hue code in Home Assistant.
Philips Hue has been one of the most consumer ux friendly IoT platforms out there. They have an extremely robust and documented API. And they provide cloud level access to some of the larger vendors, which has made integrations with other platforms pretty extensive. It was one of the first IoT platforms that voice assistants like Amazon’s Alexa could talk to and control.
Which makes it an ideal platform to build your own copy of. Because, if Alexa can talk to it on the local network, you can tell Alexa that anything is a lightbulb, and get basic on / off / dimming controls of that. Which is exactly what was done in Home Assistant. Switches, lights, and even media players are exported as fake lightbulbs with names that voice assistants can address. And now, they can control parts of your house they weren’t originally designed to support.
This was originally written by my friend Bruce, this is now part of the Home Assistant base, and being extended to Google Home as we speak. It goes to show was stability and documentation do for making an API become embedded way more places than you imagined.
One thought on “Repurposing APIs”
Over at Vivaldi they’ve apparently made their browser control your Philips Hue stuff based on the colors on the website you’ve currently got on your screen. https://vivaldi.net/teamblog/193-why-the-vivaldi-browser-is-venturing-into-the-internet-of-things
I’d be curious to see what it’s like, although it’s neither a reason to buy Hue lights nor a reason to use Vivaldi. 😛