I have had a look through the docs and see with the HTTP API you can change color, brightness, saturation or kelvin individually.
This does not seem to be the case with the LAN protocol.
I appreciate a work around is to get the values first then send them back, altering only the value you want to change, but this seems like twice the work for something that should be included already.
Am I missing something?
You’re not missing anything. The current API documentation for the LAN Protocol does not document any way in which to change color, brightness, saturation, or kelvin individually. It is my understanding that, over time, they will be improving the documentation.
In the mean time, your work around is exactly what I have been doing, even though it’s tedious and inefficient. Your other option is to follow an unofficial documentation by MagicMonkey found here. You, of course, do so at your own risk. A few of the commands have notes about potentially causing trouble with their devices.
Thanks for the link… reading about how you can damage bulbs I think I’ll stick with what we have ta and just tell users they need to set HSBK all at the same time. The way my app works it won’t be too bad anyways as it will be more about setting presets.
Add me too the list of users who would like the LAN protocol fleshed out to match the power of the HTTP API.
There are a few things that the LAN API will never be able to do, for example the cycle endpoint. These are done in the API using either a cached state of the bulb, or by asking the bulb for its state before performing the action. There is no reason it couldn’t be implemented the same way in your application.
That said we are looking to release more of the LAN protocol going forward. In particular the next thing I want to document is the SetWaveform message. There is also a method for changing a single attribute, and that’ll be next.
This is all achievable on the LAN protocol by caching (or querying) bulb state and submitting changes only for the desired property, using the cached values for the other props - and I presume this is exactly the way the HTTP API works. Since client libraries will tend to just implement the spec (at least initially), you can either implement your own wrapper functions to modify a single property, or try and get these functions added to the library for your language of choice.
I for one would be hesitant to take on the maintenance burden of these extra functions in a lib though, since they’re so easy to implement outside the core code, and adhering to a smaller surface area that more closely matches the API is much more maintainable for libraries in the long term.
Also, the official API docs are pretty decent these days, with the exception of a couple of commands.