So i just had a user hit me up about trying to use setcolor in RM to adjust the color of a device for their kids. It resulted in some strange behavior. I just wanted to check if this is intended behavior.
First they were trying to set the color to what was indicated as WARM White in the RM UI but at a bulb value of 1. When the rule executed it appears that the device didn't turn on. When I tested this myself i got a similar result, but was able to confirm that the device did actually turn on, but the color was a near black color also. So when on there was really nothing to show on the light device because it was such a black color. I was able to confirm this by looking at the command that was submitted through the driver. To work with the Hubitat the integration driver does have to change from HSB % scale to RGB scale. It does appear RM is passing the bulb level as the B value in the HSB % Scale, but that doesn't really relate to bulb dim level, but color brightness and when converted is causing strange results. That Bulb level value really needs to submit Set level command after the color is requested to ensure the color is first achieved and then the level is set as expected.
I don't know if this is diffrent for bulbs that work on the HSB scale but this is certainly causing a issue when converting between HSB % scale and RGB. It is also shown well when you look at the color picker in the Hubitat ui.
Is this tied with yesterday's thread about Dimming RGB up on motion? My thinking cap did not produce any helpful guidance there, unfortunately. Curious indeed.
It very well could be. I do see references to the RGB Scale in the Live Logging. I can't tell for sure what the driver for that device is doing but at first glance I would say it is related.
@gopher.ny or @bcopeland
It would be interesting to hear your take on this since we have now seen it twice.
In the case of what @LibraSun was pointing to it was a Inovelli Bulb Multi-Color LZW42 bulb mentioned in the thread. Not sure what driver. In the experience I was engaged in it is with the custom "Govee Lights, Plugs, and Switch" driver i am maintaining.
I can tell you with certainty that the "Govee Lights, Plugs, and Switch" driver does a HSV to RGB conversion to send the commands to Govee.
I think a simple change to the Govee driver may kind of address this, I had it adjusting the level independently of setting the color. As the level is in a way part of the RGB array sent to Govee to set their device to it was redundant. It still makes it confusing though as you can set a brightness in RM for the color but then can still adjust the bulbs brighness for that device once the command is set. It also means that if a user has there device already set to a cretain level it won't change to that after the color command is implemented.
Almost makes me wonder if i should have the driver change the brightness value to 100% after being change to color mode or something. But that may have other implications.
Ok so i think my solution will be to set the bulb level to 100% when the set color command is initiated. This will give full brightness for the RGB map that is being processed. The idea being 100% of very little is still very little. So I have a plan to fix this for the Govee stuff.
@bcopeland for RM based on the verbiage when using Set Color, i would think sending a value of 100 for the Lightness value would be the way to go and then send a option to adjust the level to what is being specified on that page. Below is a screen shot of the stuff I am talking about. That value of 41 may work better if submitted as a setlevel command instead of as part of the HSL values on the set color command. Interestingly if you use the option to Pick a color the bulb level option goes away.
I'm the one who posted that thread but I can confirm that the bulb turns on at last set color and brightness then changes to new color and new brightness. I was going to also look at that after figuring out how to start at a low level and then increase to the desired level so it is a similar.
