4 ms·
I think they're trying to say, "you can create an app that uses the hue api to control virtual lightbulbs, but you can't build software/devices that accept hue
by warfangle 11y ago
I think they're trying to say, "you can create an app that uses the hue api to control virtual lightbulbs, but you can't build software/devices that accept hue api messages that will also control your window blinds."
It makes sense: the hue api is for lightbulbs, not for window blinds or door locks. You're free to create a layer on top of it that accepts hue api messages for lightbulbs, and other messages for other things.
I think they don't want people to get your hypothetical hue-api enabled deadbolt and mistakenly unlock their deadbolt by turning using the hue app to turn their lights off.
On the other end of things, you could make an app that will unlock your doors and turn the lights on, as long as the message that unlocks the doors does not conform to the hue api.
- mjg59 11y agoIt's more that they're saying "You can't make a bridge that would allow a Hue app to control a non-Hue lighting system"
- warfangle 11y agoSuccinct, but I think it's more restrictive than what they're saying - more like, "You can't make a bridge/device that would allow a Hue app to control something that isn't a lightbulb."
- simoncion 11y agoThey say: "...it is a condition of access to our API documentation that you do not use it to develop or distribute any bridges or devices which interpret the hue API in order to control physical devices." A lightbulb is a physical device. It seems clear to me that they distribute this API and documentation with a license that ensures that you can only write software to work with their hardware.