Osram colors broken again due to preferred xy mode in homeassistant.js #6402
Comments
|
I guess a way to indicate which bulbs should use hs over xy would be a good start. osram and hue definitely look way better with hs (with the gamma correct applied), innr looks slightly different between hs and xy, both look objectively the same, as they don’t do enhancedHue they look the most consistent with XY between normal and scenes (they need enhancedHue for using hs in scenes) ikea only supports XY tint again does not do enhancedHue but does look a bit better with hs, but when using scenes with fallback to xy and looks about the same as hs outside of scenes... xy outside of scenes looks really bad. Which makes me wonder if it internally applies some sort of correct to the xy values when using scenes. These are by far the worst. Hue and Osram being the better looking ones if using hs. |
|
Should be fixed now. Can you check if it is OK now? The colors of the bulbs are indeed very off, these are in fact the only two devices which were forced to hs instead of xy ( zigbee2mqtt/lib/extension/homeassistant.js Line 1395 in 1bccc5d Changes will be available in the latest dev branch in a few hours (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html) |
|
It works better than ever before with the color being set correctly and everything being reported back in home assistant. Thanks! Edit: It seems that when changing color temperature XY is being reported back to home assistant. Changing the hsv color in home assistant doesn't change the color on the color wheel after that, as it seems home assistant prioritizes XY coloring. Maybe in zigbee-herdsman-converters something that works like the current miredsToXY conversion for color temperature? |
|
@jasperro this can be solved after home-assistant/architecture#519 . For now stop z2m, edit |
|
Hello, there has been something new in the frontend since the update, but it has no function. -Gardenpole Mini RGBW OSRAM Debug Received Zigbee message from 'BWM Terrasse', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":24672}' from endpoint 2 with groupID 0 |
|
@Koenkk, maybe like with level_options and power_on_behavior we should not expose this? (As originally propose) Support seems to vary between different models/brands.
~ sjorge
… On 27 Feb 2021, at 09:13, salopette ***@***.***> wrote:
Hello, there has been something new in the frontend since the update, but it has no function.
It is there for three different types of lamps.
-Gardenpole Mini RGBW OSRAM
-PAR16 RGBW Z3
-Outdoor Lantern W RGBW OSRAM
Debug Received Zigbee message from 'BWM Terrasse', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":24672}' from endpoint 2 with groupID 0
Debug Received MQTT message on 'zigbee2mqtt/Terrassen Licht/get' with data '{"color_options":""}'
Debug Received MQTT message on 'zigbee2mqtt/Terrassen Licht/get' with data '{"color_options":{"execute_if_off":""}}'
Debug Received MQTT message on 'zigbee2mqtt/Terrassen Licht/set' with data '{"color_options":{"execute_if_off":true}}'
Debug Received Zigbee message from 'Terrassen Licht', type 'readResponse', cluster 'lightingColorCtrl', data '{}' from endpoint 3 with groupID 0
Error Publish 'get' 'color_options' to 'Terrassen Licht' failed: 'Error: Read 0x7cb03eaa00b13545/3 lightingColorCtrl(["options"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'
Info MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'get' 'color_options' to 'Terrassen Licht' failed: 'Error: Read 0x7cb03eaa00b13545/3 lightingColorCtrl(["options"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'","meta":{"friendly_name":"Terrassen Licht"},"type":"zigbee_publish_error"}'
Info MQTT publish: topic 'zigbee2mqtt/Terrassen Licht', payload '{"brightness":254,"color_options":{"execute_if_off":false},"last_seen":"2021-02-27T08:12:33.963Z","linkquality":105,"state":"OFF","update":{"state":"idle"},"update_available":false}'
Info MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'get' 'color_options' to 'Terrassen Licht' failed: 'Error: Read 0x7cb03eaa00b13545/3 lightingColorCtrl(["options"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'","meta":{"friendly_name":"Terrassen Licht"},"type":"zigbee_publish_error"}'
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@sjorge agree, could you make a PR? |
I'll make one tonight, also good to know as I was just about to buy a Osram Flex strip because my E27 Osram bulb supported this. Might need to rethink that now :( |
Suppor varies between bulbs, my E27 seems to suport it, my tradfri panels also. Tradfi GU10 accepts it but ignores the bit, As per Koenkk/zigbee2mqtt#6402 Osram seems to barf at it for there GU10 and non bulb shaped lamps.
Suppor varies between bulbs, my E27 seems to suport it, my tradfri panels also. Tradfi GU10 accepts it but ignores the bit, As per Koenkk/zigbee2mqtt#6402 Osram seems to barf at it for there GU10 and non bulb shaped lamps.
Suppor varies between bulbs, my E27 seems to suport it, my tradfri panels also. Tradfi GU10 accepts it but ignores the bit, As per Koenkk/zigbee2mqtt#6402 Osram seems to barf at it for there GU10 and non bulb shaped lamps.
Suppor varies between bulbs, my E27 seems to suport it, my tradfri panels also. Tradfi GU10 accepts it but ignores the bit, As per Koenkk/zigbee2mqtt#6402 Osram seems to barf at it for there GU10 and non bulb shaped lamps.
What happened
Commit acfd938 made it so that xy color is always preferred in home assistant. This unfortunately breaks previous fixes for color rendering that forced on hsv mode. On AC03647 and AC03645 colors are again incorrectly set, because xy color on the device is broken on a firmware level. It seems that Koenkk/zigbee-herdsman-converters#2129 has something to do with this issue too, is that the reason for the change?
What did you expect to happen
HSV color advertised to home assistant as the primary way to set colors on devices AC03647, AC03645 and other devices with broken XY support.
How to reproduce it (minimal and precise)
Change colors in home assistant of a affected device, see only the xy values change, and wrong color bulb.
Possible fix
Add a extra flag in the code to check for preferred mode.
Instead of
something like
?
In the meantime, I reverted back to version 1.17.0, and my colors are working perfectly again.
Debug info
Zigbee2MQTT version: 1.17.1-dev
Adapter hardware: CC2531
Adapter firmware version: not relevant
The text was updated successfully, but these errors were encountered: