Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.25k stars 1.6k forks source link

[Feature request]: Set light color before turning ON #22653

Open Hattan-BA opened 2 weeks ago

Hattan-BA commented 2 weeks ago

Is your feature request related to a problem? Please describe

I’m using some IKEA RGB light bulbs, when turning the bulb on with a certain color, it turns on with the previous color for a second, then changes to the desired color. For example, if it was set to White then I turned it off, then I called the service to turn it on as Red, it turns On as White then changes to Red.

Describe the solution you'd like

There is a setting in Z2M in the exposes of the device that says “Execute if off: Controls whether the color and color temperature can be set while light is off” [See screenshot bellow]

It works, but only when controlling the color from the Z2M dashboard. Meaning, that if I go to the bulb page in the Z2M dashboard, set it to white then turn it Off, I can choose the color Red (while it's Off), and when I turn it On, it turns On as Red directly.

So the problem isn't hardware related with the bulb or Z2M communicating with the bulb, The problem is with the HA "light.turn_on" service giving the call to Z2M via MQTT in one payload template , i.e. "turn on" & "set color". When it should be two separate payloads, "set color" then "turn on".

Separating the mqtt into two separate payloads, first that sets the color, the second to turn it on: payload: "{\"color\":{\"r\":255,\"g\":0,\"b\":0}}" then payload: "{\"state\": \"ON\"}"

and not a payload template that contains both: {"state": "ON", "color":{"r":255,"g":0,"b":0}}

Describe alternatives you've considered

An easier fix could be to just import the color bar in Z2M bulb exposes as a list into HA [See screenshot bellow]. Since it works if manually controlled from Z2M dashboard.

Additional context

ZHA has an option called "Enable enhanced light color/temperature transition from an off-state", which fixes this issue if enabled.

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/light.py#L236-L246

Screenshot_1

chris-1243 commented 1 week ago

In your home assistant automation, you may try to send two commands like this (do NOT run them in parallel):

- service: mqtt.publish
  data:
    qos: '0'
    retain: false
    topic: 'TOPIC/FRIENDLY_NAME/set'
    payload: '{"color_temp": VALUE}'
- service: mqtt.publish
  data:
    qos: '0'
    retain: false
    topic: 'TOPIC/FRIENDLY_NAME/set'
    payload: '{"state": "ON"}'
or
- service: mqtt.publish
  data:
    qos: '0'
    retain: false
    topic: 'TOPIC/FRIENDLY_NAME/set'
    payload: '{"color_xy": {"x": X_VALUE, "y": Y_VALUE}}'
- service: mqtt.publish
  data:
    qos: '0'
    retain: false
    topic: 'TOPIC/FRIENDLY_NAME/set'
    payload: '{"state": "ON"}'

It is working perfectly and when the light is turned on, the color is set as you wish.

As you tried already, sending two commands work perfectly...

For me, it is more a firmware problem from IKEA. If you send multiple commands in one payload:

    payload: '{"state": "ON", "brightness": 254, "color_temp": 370, "transition": 1}'

the transition will not work...

Hattan-BA commented 1 week ago

Hey, thanks for the response, I have already made a script to solve this issue in the meantime. But it's definitely not an IKEA bulb firmware issue, since this issue was fixed in ZHA a few days ago. I'm not talking about their "Enable enhanced light color/temperature transition from an off-state" workaround where they turn the bulb on at 0 brightness and set the color then turn it on to the desired brightness, this option is a workaround for all bulbs, but bulbs that have the "ExecuteIfOff" functionality like the IKEA bulb, doesn't need this workaround since they can be sent the command to set the color while they're off, then turn them on as normal. ZHA didn't check if the bulb has the "ExecuteIfOff" feature and assumed all bulbs didn't have it and used their workaround, now they edited the code to check if the bulb can be controlled while off and then control it accordingly.

That's what I'm hoping Z2M does, to check if the bulb has the "ExecuteIfOff" feature, and if it does have it, then just split the MQTT payload, and make everyone's life a little easier.