I’m using some Osram RGBW bulbs connected to my HE using the new Advanced driver. When I use Alexa to issue a color change command, the bulbs are always reverted to 100% brightness. I thought, but am not entirely certain, that the brightness stayed the same when using the generic driver. Is there any way to keep the nice features of the advanced driver, while leaving the brightness alone during voice-issued color changing commands? My searches found some threads that were sort of related to this, but didn’t speak to voice control App integrations.
Well, I just tried this out with a Sylvania rgbw bulb using the advanced Zigbee rgbw, generic Zigbee rgbw, and Sengled color plus drivers. Every time I ask Alexa to change a “color” it also sets the level to 100. Asking for a white (soft, warm, etc) doesn’t change the level with any of the drivers.
I next used Siri to try this experiment. Siri doesn’t change the level with any color change command or white color. I did notice that with the Advanced driver Siri is better at making the color request actually happen. For instance, using the Sengled driver caused requests for blue to be ignored by the driver or bulb (no change happened and none was reported on the device page).
My conclusion is that you should use Siri
Just kidding (not that much though). I think Alexa must be sending a level command with the color change.
If it is, I don’t think it’s intentional. If I pair the same bulb directly to Alexa (via the built-in Zigbee hub) the color will change without altering the level, and I distinctly remember it used to work that way with the Hubitat skill too.
It’s not a show-stopping disaster since most of my color changes are done with scenes where I can capture and set the desired level anyway, but it’s messing with my nightstand a bit — I have a series of Alexa routines I use at night while getting ready for bed that make it warmer (and eventually red) and dimmer, but the brightness popping back to maximum has an other-than-desirable effect on the intent.
I can’t try it today (I work nights and it’s bedtime), but have you tried it with a group device? If it works that way, you could just have a group of one bulb and share it to Alexa instead. I don’t know why it would work, but stranger things have happened. If not, perhaps @bravenel or @mike.maxwell can offer guidance.
I have this problem with the tp link driver (and didn't used to have the problem before I came to HE). In my circumstance, the driver owner said that Alexa is not sending the full HSL command that the driver expects so it basically turns the L from a missing value to 100.
We had discussed some workarounds but didn't go down the rabbit hole because most of my home is automated and the only time it becomes an issue is like when you say "Alexa, set x room/device to red" it will change everything to 100% in the process. Very annoying but what I got from Dave was it was something we'd need to fix in the driver.
Our symptoms are nearly identical and I think the problem at the heart of it is the same (just on a different driver).
Voice controlling the color temperature does not mess with the brightness. Only changing the RGB color does. I feel like this should be fixable in the Hubitat Alexa app, but I’m not sure really where to look.
That isn't too surprising: color is set with the setColor() command, while color temperature is set via setColorTemperature() -- different commands, different parameters. Conventionally, setColor() takes a single parameter that is a data structure (Map in Groovy) consisting of the hue, saturation, and brightness values (technically three values, but all part of the same parameter--I don't think behavior is well defined if one of the "keys" is missing from this structure), whereas setColorTemperature() has long accepted just one parameter, the color temperature. (Recently, you recently also became able to optionally specify a level and tranisition time.)
But the ultimate question is what Alexa and the Hubitat skill ultimately send to the device. In the case of color temperature, I observed the classic one-parameter setColorTemperature() command (though with quite odd values--and likely why I've never found this useful--like 2000 for "warm white" and 7000 for "cool white"). In the case of color, it appears to send the complete Map--not totally unexpected, though some drivers might be OK if something, like level, were missing:
I think the Skill is just playing it safe and providing a default brightness value. For most colors, this was 100%, though I tried purple a few times and it was reliably 94%. Current device level did not seem to play into this. Whether this is Alexa or the Hubitat Skill specifically, I don't know, but it's definitely not the driver (this is just a log of the exact command the driver was told to execute--I wrote a custom virtual driver to test this). In any case, I don't think there's anything we'd be able to do, short of writing our own Alexa Skill, that would affect this.
That is some excellent information, very much appreciated! I agree that the correction would likely need to take place in either the Alexa Hubitat skill (in Amazon) or the Hubitat Alexa app (on HE). I’d describe the current behavior as a bug—or at least an unexpected outcome—is there an appropriate venue to raise that to the attention of the developers?
