Allow me to set individual light properties without full HSBK
dotMorten opened this issue · comments
It would be awesome if you could add messages that solely set either hue, brightness, kelvin or saturation. It would mean a more efficient way in a lot of scenarios to communicate with the bulb. Ie if you just want to dim the bulb, you need to first query it's current hue, saturation and temperature, just so you can set the brightness without changing the other values. It makes commands slower and more brittle, rather than just sending for instance a "SetBrightness" message.
The way you mentioned is the way our own applications currently also update the lights. They also try to track the state internally so that they can act faster and send only a single message.
The problem with setting each value individually is that there may be several devices controlling the bulb (including over the cloud). This could end up with the bulb being put in an inconsistent state. Forcing the color updates to be atomic solves this and prevents the bulb from ever displaying a color that was not requested.
Actually the scenario with multiple apps that you describe makes it all worse. One app can't set the color while another sets the brightness. If they are individual commands, things would be just fine and they wouldn't be fighting each other.
In addition you recommend a max of 20 msg/second. If I have to query the state, this effectively becomes 10/sec, meaning you can't do as smooth a transition either.
As you said yourself: your apps "tries" to track state. I personally like a little more certainty than 'tries'.
Add to that that the AllJoyn protocol allows setting properties individually - Creating an alljoyn bridge for your lightbulbs that aren't AllJoyn enabled means being forced to create this overhead.
On a side note, Philips Hue seems to handle this just fine, and can set 1, 2, 3 or all 4 parameters (or more) in one go. It would be nice to have something similar to this.
I don't really see the issue with multiple simultaneous request and being put in an inconsistent state. Last request to set the brightness wins. Last request to set the color wins. Last request that sets them all wins etc. There's never a case that you get a color that wasn't requested. It's just about what was requested last.
Lastly it's weird to me you need to set hue and saturation on your newer lightbulbs that doesn't even support hue and saturation?
I agree with @dotMorten. Let us worry about inconsistent state. The API shouldn't enforce it.
I'll refer this request to our firmware team as this will require updated firmware on the bulbs to add some new message types. For various reasons firmware features need to be carefully analysed and implemented so it could take some time.
I'd encourage anyone else who is interested to post their use case here to put more weight behind it and move it to the top of the firmware teams priority list.
...I'd rather the firmware team spend their time bringing AllJoyn too all your bulbs, since it already has this. 😉 if possible that is