I know the RGB RGBW drivers provide H S and V values but they are updated separately and also the values get interleaved with responses from other bulbs. This makes it difficult to establish the new HSV value for a bulb from events without local state storage. Or I have to re-read all values independently from the bulb after any color change event . Is there an easy way around this ? Why no state for color ?
I need to publish a single consistent COLOR_MAP topic payload on MQTT and also the RGB value. Currently I re-assemble these from HSV event values but for split seconds these are incorrect as they update independently and also when groups are changed the interleaving means I have to do the re-reads.
Added:
TP-Link. Setting the hue and saturation separately is possible; however, it is also possible to set these in a single command on the TP-Link Bulb. If setColor is sent, a single command is sent with all three parameters above.
Thanks Dave. The transform between RGB and HSV you mean ? and the 0-100 or 0-360 H value. I have implemented that myself and it works.
It's just the aspect of not being able to get the complete current color back from any state of the bulb or in any one 'event' - I can only recover independent values, you can set HSV in one command but not read it.
Does that RGB attribute mean I can read the RGB value of a bulb ? I can't see that attribute in the color driver e.g. the latest RGBW virtual
I use the attribute color in my implementation to be the color map (in text format) for the setColor command. This provides an event in the system with both hue, saturation, and level.
RGB attribute is new. It is probably the actual RGB. Since the TP-Link bulbs report HSL, I use the color attribute only (I would have to do a transformation to create RGB. If my bulbs were RGB, I would use the attribute RGB.)
Hubitat is expanding the definition. Next may be the RGBW attribute. I do not expect them to change the setColor command (it would break the Input interface).
So you basically copy the setColor command value into the color attribute ? But what if the bulbs color is updated elsewhere with something that just alters one value of HSV (or HSL) does color update ?
Also I am trying to make something that works with existing official Hubitat drivers and they don't update that color attribute - so I'm stuck aren't I ?
Not really. In my drivers, I overkill. When a refresh is done, and there is a change, I report hue, saturation, level, and color. The sendEvent will only trigger "events" when a value has changed. An app using H, V, and L attributes will need to
remember the Hue, Saturation, and Level values.
when an event is triggered, update the values that have changed
you could also manually get the device's current value of H, S, L whenever an event is triggered
If the device and app use setColor and sets attribute color, then no memory is required. But, as you stated, not all devices report attribute color.
OK - That's pretty much what I'm doing now. I don't want to get into storing any device states within my MQTT app and so I rely on an event that provides me the 'complete' new state or I have to retrieve the other related states from the device, which is what I'm doing with HSL - it just seems inefficient as for the 3 HSL events I have to retrieve 6 other values.
I am publishing a calculated #RGB value on MQTT and also allowing a set using an #RGB value which I convert to HSL which works well aside from the rounding of two digit hex 00-FF 0-255 value being reduced to 0-100 and then multiplied back which creates rounding issues.
Thanks for your help here .. one last Q is your color attribute like this or using initials h s l .. and hue is 0-100 ? I may as well be able to support your reported attributes in the MQTT app.
Can you point me to your driver - is at aimed at TPLink devices or all RGB inc Philips Hue ?
