Closed Bascht74 closed 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.
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 👍
@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?
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):
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
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.
I think, if a lamp only support
color_temp
the option forcolor 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 think, if a lamp only support
color_temp
the option forcolor 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 !
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)
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 :(
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
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.
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
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?
Hi @Koenkk , what do you need from us to tackle it ? I would like to get this lut of the logs.
Thanks
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:
But when the light was discovered, only support for color temp was indicated:
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