Koenkk / zigbee2mqtt

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

Light mqtt discovery with different available color mode than later sent via state topic #12663

Closed Bascht74 closed 2 years ago

Bascht74 commented 2 years ago

What happened?

There is the following problem in zigbee2mqtt (see: https://github.com/home-assistant/core/issues/72727) HA receives this state update where color mode is set to xy:

zigbee2mqtt/Lampe_OG_Schlafzimmer_Schreibtisch: 
{"brightness":254,"color_mode":"xy","linkquality":69,"state":"OFF","update":{"state":"idle"},"update_available":null}'

But when the light was discovered, only support for color temp was indicated:

              "supported_color_modes": [
                "color_temp"
              ],

What did you expect to happen?

The available color modes have to be the same possible entries for mqtt discovery as well as later the state topics sent by z2m

How to reproduce it (minimal and precise)

see infos here: https://github.com/home-assistant/core/issues/72727

Zigbee2MQTT version

1.25.1

Adapter firmware version

20220219

Adapter

zStack3x0 Sonnoff

Debug log

example light: zigbee2mqtt/Lampe_OG_Schlafzimmer_Schreibtisch

log.zip

frenck commented 2 years ago

I glanced at the discovery code of z2m, and imho the issue is that color modes are somewhat filtered towards HA in the discovery message (eg, preferring HS over XY at times).

This same filtering logic is not applied when publishing the states of a light, so things might end up out of sync.

IMHO, the color modes filtering in the discovery message should be removed and all possible color modes should be exposed to HA.

HA can handle/can switch between appropriate modes when needed.

hhromic commented 2 years ago

I've been observing the same warnings on my HA setup with z2m and IKEA bulbs under a Deconz RaspBee coordinator. So you are not alone with this issue. Thanks for reporting 👍

Koenkk commented 2 years ago

@Bascht74 the Philips 9290022944 definition only mentions color temp support, no x/y color support. Do I understand correctly that this bulb does support x/y color?

Bascht74 commented 2 years ago

Hi @Koenkk I don't think so. But sometimes z2m seems to report the light with an x/y color mode to home assistant:

2022-05-30 23:45:32 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on zigbee2mqtt/Lampe_OG_Schlafzimmer_Schreibtisch: b'{"brightness":254,"color_mode":"xy","linkquality":69,"state":"OFF","update":{"state":"idle"},"update_available":null}'
2022-05-30 23:45:32 WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode received

The discovery messages has only color_temp:

              ],
              "supported_color_modes": [
                "color_temp"
              ],
              "friendly_name": "Lampe_OG_Schlafzimmer_Schreibtisch",

The documentation here: https://www.zigbee2mqtt.io/devices/9290022944.html#philips-9290022944 has a documentation of a hue_power_on_color :

Power-on behavior This device allows you to set the power-on behavior. Note that this requires at least November/December '18 firmware update of the device. Send a MQTT command to zigbee2mqtt/FRIENDLY_NAME/set with the following payload.

{ "hue_power_on_behavior": "on", // default, on, off, recover "hue_power_on_brightness": 125, // same values as brightness "hue_power_on_color_temperature": 280, // same values as color_temp "hue_power_on_color": "#0000FF" // color in hex notation, e.g. #0000FF = blue }

Furthermore the light has the following option, that is enabled in my case (as default): image

Maybe the color sync option is causing z2m reporting the lamp with x/y color mode? As you can see there is no value in the topic, only brightness...

I think, if a lamp only support color_temp the option for color xync shouldn't be available...

As @frenck suggested, an additional good idea could be to remove the color modes filtering in the discovery message so that all possible color modes should be exposed to HA. That way HA would take what it gets...

Seb

Koenkk commented 2 years ago

But sometimes z2m seems to report the light with an x/y color mode to home assistant:

Can you provide the debug log when z2m does this?

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging.

sjorge commented 2 years ago

I think, if a lamp only support color_temp the option for color xync shouldn't be available...

AFAIK it shouldn't unless there is alread xy attribtes in the device state... but some ct only bulbs do return xy when changed via a scene. (Which is kind of annoying, looking at you ikea)

hhromic commented 2 years ago

I think, if a lamp only support color_temp the option for color xync shouldn't be available...

AFAIK it shouldn't unless there is alread xy attribtes in the device state... but some ct only bulbs do return xy when changed via a scene. (Which is kind of annoying, looking at you ikea)

I can confirm that was the case on my side. I went to check which devices were sending color_mode: xy and I recalled that indeed in the past I tried to create a zigbee scene with exactly those devices misreporting the color mode. I removed them from the state.json file and zigbee2mqtt never again tried to send color_mode: xy for them and HA is now happy.

Before removing them manually from state.json, I tried to reconfigure the devices (using the yellow button in the UI) but that didn't help. I wonder if there is a nicer way to restart the state of a device in zigbee2mqtt that does not involve re-pairing? Manually editing state.json looks a bit extreme to me :)

Anyway thanks for the hint, @sjorge !

sjorge commented 2 years ago

You should be able to do something like this:

mosquitto_pub -t zigbee2mqtt/<dev>/set/color_temp -m 250
mosquitto_pub -t zigbee2mqtt/<dev>/get/color_mode -m ''

lightingColorCtrl.colorMode isn't reported by default but you can read it just fine.

If you do scene_add and scene_recall it will be incorrect again of course, well not incorrect as the bulb will return xy when read too. It's just that ZCL dropped the ball on that on ZCL < 7 that did not have colorTemperature in scenes, I've not seen a ZCL >= 7 bulb though.

That being said, manually setting via color_temp and then reading color_mode should have it report 2 AKA color_temp for the color_mode attribute. (Yes, I spend days on this getting frustrated)

hhromic commented 2 years ago

Thanks for the further tips, @sjorge. Sending messages to the topics seem much cleaner than what I did indeed. I forgot to mention before that the affected bulbs in my case are not even white-spectrum ones, they are just simple dimmable GU10 with fixed warm white color. I have had IKEA bulbs for a long time and I have gone from the IKEA gateway to Deconz addon to HA's ZHA and now I am going with zigbee2mqtt. So yes I also know very well the struggle and frustration of IKEA hardware :(

Bascht74 commented 2 years ago

after I chanced to color sync mode to off it did not happen again.

@Koenkk Could you disable that feature for that device, because it doesn't support that color mode? https://www.zigbee2mqtt.io/devices/9290022944.html#philips-9290022944

sjorge commented 2 years ago

after I chanced to color sync mode to off it did not happen again.

@Koenkk Could you disable that feature for that device, because it doesn't support that color mode? https://www.zigbee2mqtt.io/devices/9290022944.html#philips-9290022944

It's a side effect of how scenes work, so it should be disabled for all colorTemperature when scenes are used. I don't think there is an easy way to fix it as the bulb actually has a colorMode of xy when a scene is recalled, at least on my Hue/Innr/Tint test bulbs I had in the past.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

oyvindwe commented 1 year ago

I found this issue as I also got these annoying warnings in HA log:

WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode 'xy' received for entity light.tradfri_bulb_1
WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode 'xy' received for entity light.tradfri_bulb_2
WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode 'xy' received for entity light.tradfri_bulb_3
WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode 'xy' received for entity light.tradfri_remote

The bulbs are IKEA LED1537R6 and the remote is IKEA E1524.

I only get this warnings for these devices, and it started after I created scenes to mimic the default left/right button behaviour on the remote that changes colour temperature, so it's obviously caused by scenes somehow.

Any state update (on, off, brightness, color temp) for these devices contains "color_mode": "xy" in the message, e.g.:

{
    "brightness": 44,
    "color_mode": "xy",
    "color_temp": 454,
    "color_temp_startup": 454,
    "linkquality": 255,
    "power_on_behavior": "on",
    "state": "ON",
    "update": {
        "installed_version": 587757105,
        "latest_version": 587757105,
        "state": "idle"
    },
    "update_available": false
}

I have worked around the issue by editing state.json, replacing "color_mode": "xy" with "color_mode": "color_temp" for these devices. I also noticed the affected devices only had color_temp values, while some other devices also had values for x and y.

Is it possible to fix this in zigbee2mqtt?

HA-Master-User commented 1 month ago

Hi @Koenkk , what do you need from us to tackle it ? I would like to get this lut of the logs.

Thanks