Java Runtime Environment: openjdk version “1.8.0_252”
openHAB version: 2.5.5 Release
Issue of the topic: I have my Sengled Color bulbs configured in OH2 through Zigbee2MQTT and inside OH2 I have them working just fine, but when I use them through Alexa as a smart device I have issues. Whenever I set ColorTemperature in Alexa, it sends the command to my OH2 instance and the lightbulb changes color just fine, but after a few seconds the Alexa app shows it reverting to the previous Color (differnent from Color Temperature) it was set to. I think the reason it’s reverting back is because it’s failing some sort of expected response, but I’m not sure… The main problem this causes is that routines that include changing color to color temperature now fail and thus never complete.
I’m hoping someone has run into something similar before and can help me out, but at the very least some help debugging this would be great. I have no been able to find a way to get debug logs from the Alexa side and I currently just don’t have any more ideas left on what to do to debug this.
Can you please provide the OH event logs related to the items, part of the group you listed, when you make the color temperature voice request, as well as the state of each of these items prior to that request being triggered?
Sorry for the late reply, my ISP decided that I didn’t need internet for a few days. :\
These are the logs generated right after send the voice command “Alexa, set the lights to Cool White” or if I pick “Cool White” as a Color Temperature option in the Alexa app.
2020-06-19 09:04:33.038 [nt.ItemStatePredictedEvent] - BedroomLightsColorTemp predicted to become 33.33333333333333
2020-06-19 09:04:33.062 [vent.ItemStateChangedEvent] - BedroomLightsColorTemp changed from 33.33333333333332909090909090909091 to 33.33333333333333
2020-06-19 09:04:33.288 [vent.ItemStateChangedEvent] - BedroomLightsColorTemp changed from 33.33333333333333 to 33.33333333333332909090909090909091
I thought it might be the fact that the number gets changed twice, but I changed it from a dimmer type to a number type to avoid this and still got the same results.
The value for BedroomLightsColorTemp or BedroomLightsColor is always the last ColorTemp or Color used, but Alexa won’t necessarily revert to the last color OH2 knows about, it’ll revert to the last color that the Alexa app knows about. I setup a sitemap to show you the item values, but the color value only gets set if it’s actually selected with the colorpicker, otherwise it just goes to this default location. This might be because I have color set to just a commandTopic and not a stateTopic. This is because my lights require some conversion on the color values and while I have it set for values going out (you can see the transformPatternOut), I haven’t done the reverse work.
I also recorded what it looks like from the Alexa app and uploaded to youtube, hopefully this will let me post the link: https://youtu.be/DoxbK7tqTyc
I tried running the bulb without Alexa knowking about the Color feature, with just knowing about brightness and ColorTemperature and it works just fine. I’m going to see if I can try to reverse my transform function so I can set color’s stateTopic and see if that solves any issues.
I hope this was all the information you requested. If I missed something I apologize in advance, but please let me know and I’ll fetch it ASAP. I’ve been trying to get this to work for weeks now with no progress, so I truly appreciate the help.
Thanks for all the details. So the skill has some logic in place in order to determine if a color light is either in color or white temperature mode based on how standard bindings (e.g. Hue or LIFX) have implemented the differences between the two modes.
My guess since you are using a custom MQTT implementation is the color item state isn’t getting updated when switching to white temperature mode and vice versa. Thus, the skill still considers the device being in color mode, when requesting for the latest status, even though it sent the proper command in the first place, and ends up using the state of the color item over the temperature one.
There are two ways that can be fixed depending on what type your temperature item is configured. For Dimmer, the saturation of the color item (second element of HSB value) should be set to 0. For Number item, as long as the temperature is different than 0, the skill will consider the device in temperature mode but to go back to color mode, the temperature state will either need to be undefined (UNDEF or NULL) or set to 0.
Below is the code that is handling this logic. The reason behind using the saturation for Dimmer is because bindings such as LIFX uses the color saturation to differentiate between the two modes while not changing the temperature item. While other bindings such as Hue, reset the temperature state when in color mode to make that distinction. I guess having the omitSaturationColorMode property available to user would have resolved your issue. This might be something that could be added in the future.
With that explanation I was able to write a rule and now it doesn’t revert back. All I need now is to get the routine working.
This is the rule I wrote:
rule "Working around Alexa Color Temp Issues"
when
Item OfficeLightsColorTemp received update or
Item BedroomLightsColorTemp received update
then
if(triggeringItem.state == NULL || triggeringItem.state == "") {
return;
}
switch (triggeringItem){
case OfficeLightsColorTemp: {
var HSBType color = OfficeLightsColor.state as HSBType
color.saturation = 0;
}
case BedroomLightsColorTemp: {
var HSBType color = BedroomLightsColor.state as HSBType
color.saturation = 0;
}
}
end
I can clean this code up a bit more by changing from a Map data structure rather an a switch, but I’m going to leave it like this for now because I’m pretty sure this will cause some unintenteded side effects I will need to fix.
Thanks again for your help jeshab!
EDIT: With this and a few more tweaks, finally got my routines that change color temp to work!
