[mqtt.homassistant] changing color temperature switches on light

[georg138]

Expected Behavior

I have a hue white ambiance bulb connected via zigbee2mqtt. When the bulb is switched off and I change the color temperature, I expect that the bulb stays switched off.

Current Behavior

When changing the color temperature, the bulb is switched on.
The following message is published to mqtt zigbee2mqtt/Osram Lampe 1/set:

{
  "state": "ON",
  "color_temp": 221
}

Possible Solution

Do not set the state at all in handleColorTempCommand

openhab-addons/bundles/org.openhab.binding.mqtt.homeassistant/src/main/java/org/openhab/binding/mqtt/homeassistant/internal/component/JSONSchemaLight.java

Line 224 in 09cf1b1

json.state = "ON";

If

{
  "color_temp": 221
}

was sent to mqtt, the color temperature is set but the bulb stays off.

I did not actually try the modified code; before setting up a dev environment, I wanted to make sure that the current behaviour is actually not intended and that there are no side effects I did not think of.

Steps to Reproduce (for Bugs)

1. Connect bulb with color temperature via zigbee2mqtt
2. Switch on
3. Switch off
4. Change color temperature

Context

Previously, the bulb was connected via deconz. Here, the bulb stays switched off when changing the color temperature. According to #9700 (comment) this should be the expected behaviour.

Your Environment

• openhab 4.3 in an LXC container on proxmox
• zigbee2mqtt 2.0.0
• hue white ambiance https://www.zigbee2mqtt.io/devices/929001953301.html#philips-929001953301 FW 1.122.2

[lsiepel]

fyi @ccutrer

[ccutrer]

There are a few things here. The short answer is that it's working as expected.

But first, while your linked comments indicate a preference for changing color temperature to not turn on a bulb, it's not a strict guideline for openHAB bindings. The documentation mentions color temperature, but not if it's expected that send a command to a color temperature channel should turn on the bulb, or leave the on state alone.

Second, specific to the Home Assistant binding, we're somewhat limited in that we have to live within the confines of how Home Assistant works, especially since 99% of Home Assistant MQTT compatible devices are only tested with Home Assistant, not openHAB. And Home Assistant itself does not support sending color_temp without also sending "ON". See the source. As such, it would be a toss up on how any particular device would respond to any given message. And in general in this binding, I try to follow Home Assistant's semantics as much as it makes sense within openHAB.

Which brings us to our final point... Zigbee2MQTT, at least with the Hue bulb you mention, does not support setting color temp while the bulb is off. Try it yourself directly with MQTT - send the following commands to your bulb with something like MQTT Explorer:

• {"state:"ON", "color_temp": 500} (turns it on, set to warmest color temp)
• {"state":"OFF"}
• {"color_temp":153} (attempt to set it to coolest color temp, while the bulb is off)
• {"state":"ON"} (turn it back on)

The bulb will come back on at the warmest color temp. You can also attempt these steps in Zigbee2MQTT's own UI, with the same results.

Which is a sad state of affairs. I'd love to change the color temp of my Hue bulbs while they're off as much as you (my wife gets really ornery when she notices them turn on in the morning and immediately transition from warm white that they were the prior night to cool white for daytime, and it seems like they pass through a pinkish hue). I know that Hue bulbs are capable of doing this when using the Hue openHAB binding and a native Hue bridge, but zigbee2mqtt doesn't expose this functionality. It's been discussed in the past, but I guess enabling it for Hue bulbs broke some other brands? I hope to try to send some lower level zigbee commands to get it to work, but haven't had time to do so. And even if it is, it would be out of scope for this binding.

[georg138]

Thanks for this detailed explanation. I already tried the examples you proposed and can confirm what you described. In my opinion this is still better than switching the light on. Previously, I was using deconz. I was setting the color temperature of all lights periodically (I guess for the same reason as you do - to adjust it to the current daylight temperature).
With deconz, no light was switched on when setting the color temperature. When switching on a light it used the previous temperature. After a short delay it was the set to the correct value by the rule.

I somehow assumed that basically moving the same 'thing' to a different binding would not change the behaviour but I can see that both implementations are compliant.

I guess I have to accept that the behaviour is different now and will rewrite my rule to update only the color temperature of already switched on lights. As this was one of the first things I automated with openhab it's probably a good idea anyway to get rid of this fragile piece of code.

[ccutrer]

Yup, that's exactly what I have to do. My rule (in Ruby):

def cct_range(item)
  item.range || ((2000 | "K")..(6500 | "K"))
end

changed Circadian_ColorTemp do |event|
  next unless event.state?

  gCircadian.members.each do |cct_item|
    switch_item = cct_item.equipment.points(Semantics::Switch).first
    next unless switch_item.on?

    target = event.state.clamp(cct_range(cct_item)) | "mired"
    current = cct_item.state&.|("mired")
    cct_item.command!(target) if !current || (target.to_f - current.to_f).abs > 2
  end
end

I have a single item Circadian_ColorTemp that I periodically calculate a new value for in another rule, and then this rule fires to cascade it down to all lights that I want to follow-the-sun (the CCT item is a member of gCircadian). Then I find the associated switch/dimmer/color item using the semantic model, and do nothing if it's not on. If I had things that could set the color temp without turning it on, I'd probably just add some metadata to tell me if I should check for the light being on or not. Then I truncate my global CCT value to what this particular bulb is capable of, and only actually change things if it's more than 2 mireds difference. It should also work regardless of if the item stores its state in Kelvin or mireds.

Anyhow, I'll close this issue now.