Lights brightness level and colors

[tammeryousef1006]

Problem

the domain lights has multiple kind of lights but they all shown like switches

Why are you creating this issue?

Expected behavior

should provide brightness level and color to supported lights

[t0bst4r]

Can you provide some details about your lights? Please open the developer tools in home assistant and go to the states tab. Search for your light entity and share the attribute column shown there.

[tammeryousef1006]

effect_list: blink, breathe, okay, channel_change, finish_effect, stop_effect
supported_color_modes: brightness
effect: null
color_mode: null
brightness: null
last_seen: 1718964307250
level_config: 
on_level: previous

linkquality: 43
update: 
installed_version: 16909584
latest_version: 16909584
state: idle

update_available: false
friendly_name: Osram Light
supported_features: 44

brightness: 3
color: 
h: 240
hue: 240
s: 100
saturation: 100
x: 0.136
'y': 0.04

color_mode: xy
color_options: 
execute_if_off: false

color_temp: 575
color_temp_startup: 65535
last_seen: 1718964000423
linkquality: 109
power_on_behavior: previous
update: 
installed_version: 587806257
latest_version: 587806257
state: idle

update_available: false
device_class: update
friendly_name: Ikea Z Bedroom Corridor

min_color_temp_kelvin: 2202
max_color_temp_kelvin: 4000
min_mireds: 250
max_mireds: 454
effect_list: blink, breathe, okay, channel_change, finish_effect, stop_effect
supported_color_modes: color_temp
effect: null
color_mode: null
brightness: null
color_temp_kelvin: null
color_temp: null
hs_color: null
rgb_color: null
xy_color: null
color_options: 
execute_if_off: false

color_temp_startup: 65535
last_seen: 1718964587613
linkquality: 47
power_on_behavior: previous
update: 
installed_version: 587814449
latest_version: 587814449
state: idle

update_available: false
friendly_name: Berandah_2
supported_features: 44

[tammeryousef1006]

these lights via zigbee2mqtt not philips hue

[t0bst4r]

What matter controller do you use, that shows them as switches only? Alexa? Google Home?

The attributes are a bit hard to read, because you copied all into one message without splitting them by light 😁 But as far as I understand:

1. the Osram light supports brightness. This should work with this addon. If not, it’s definitely a bug.
2. the IKEA light does not have supported_color_modes which is required for my current implementation. It only has supported_features which is the old/unsupported way. I could add support for supported_features but that’s more an enhancement than a bug. I’ll need to prioritize it against other bugs.
3. The Berandah light does not support color, but color temp. The current implementation only supports color temperature with colored lights. I was not thinking of color temperature without other colors. That’s my bad, but I assume it’s more a feature request than a bug.

[tammeryousef1006]

i did put some spaces between the 3 lights , sorry if it appears connected together , and regarding the controller I'm using other home assistant setup , because its the most showing details , I got smartthings alexa google home & ewelink , so I test with home assistant based on my experience .

[genehand]

Hey I'm seeing something similar for Hue bulbs connected through Zigbee2mqtt, brightness is working but not the color settings. Ah in my case it's because these are ColorMode.xy lights

OnOff: true Level: 204%

min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6535
min_mireds: 153
max_mireds: 500
effect_list: blink, breathe, okay, channel_change, candle, fireplace, colorloop, finish_effect, stop_effect, stop_hue_effect
supported_color_modes: color_temp, xy
effect: null
color_mode: color_temp
brightness: 204
color_temp_kelvin: 3636
color_temp: 275
hs_color: 27.048, 41.896
rgb_color: 255, 196, 148
xy_color: 0.444, 0.371
friendly_name: Nightstand
supported_features: 44

---

Here's an RGB one from a esphome controlled lightstrip:

OnOff: true Hue: 19 Saturation: 122% Level: 224%

min_color_temp_kelvin: 2700
max_color_temp_kelvin: 6000
min_mireds: 166
max_mireds: 370
effect_list: None, Pulse, Strobe, Random, Breathe, Color Breathe, Colorloop, Fiesta
supported_color_modes: color_temp, rgb
effect: None
color_mode: color_temp
brightness: 224
color_temp_kelvin: 3375
color_temp: 296
hs_color: 27.306, 47.56
rgb_color: 255, 188, 133
xy_color: 0.465, 0.376
icon: phu:light-strip
friendly_name: Office closet 
supported_features: 44

[t0bst4r]

Yes, it’s caused by xy color mode in your case. I didn’t know how to convert between HA xy values and matter xy values. Maybe I’ll do that in the next days.

[t0bst4r]

I just found this in the docs of HA, saying that hs_color will be converted to rgb or xy whenever it is used with a light, which does not support hs. This would make things a lot easier, since i wouldn't need to convert to xy when controlling devices. I'd only need to convert to hs when the state update comes from HA.

@genehand could you test what happens when you do the following service call on a light which only supports xy?

service: light.turn_on
target:
  entity_id: light.my_light
data:
  xy_color: [0.291, 0.535]

[github-actions[bot]]

:tada: This issue has been resolved in version 1.5.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[t0bst4r]

Just released xy support (without testing, just hoping, since i dont have such lights). Please test it, and provide some feedback if it works.

[genehand]

Hmm, won't start up 😢

Jun 30 11:14:49 chip matterbridge[7690]: file:///usr/lib/node_modules/matterbridge/node_modules/@project-chip/matter.js/dist/esm/device/Device.js:164
Jun 30 11:14:49 chip matterbridge[7690]:     throw new ImplementationError("createOptionalClusterServer needs to be implemented by derived classes");
Jun 30 11:14:49 chip matterbridge[7690]:           ^
Jun 30 11:14:49 chip matterbridge[7690]: ImplementationError: createOptionalClusterServer needs to be implemented by derived classes
Jun 30 11:14:49 chip matterbridge[7690]:     at MatterbridgeDevice.createOptionalClusterServer (file:///usr/lib/node_modules/matterbridge/node_modules/@project-chip/matter.js/dist/esm/device/Device.js:164:11)
Jun 30 11:14:49 chip matterbridge[7690]:     at MatterbridgeDevice.getClusterServer (file:///usr/lib/node_modules/matterbridge/node_modules/@project-chip/matter.js/dist/esm/device/Device.js:176:37)
Jun 30 11:14:49 chip matterbridge[7690]:     at get levelControlCluster [as levelControlCluster] (file:///usr/lib/node_modules/matterbridge-home-assistant/lib/devices/aspects/level-control-aspect.js:8:28)
Jun 30 11:14:49 chip matterbridge[7690]:     at LevelControlAspect.update (file:///usr/lib/node_modules/matterbridge-home-assistant/lib/devices/aspects/level-control-aspect.js:32:48)
Jun 30 11:14:49 chip matterbridge[7690]:     at LightDevice.updateState (file:///usr/lib/node_modules/matterbridge-home-assistant/lib/devices/home-assistant-device.js:21:26)
Jun 30 11:14:49 chip matterbridge[7690]:     at async HomeAssistantMatterAdapter.create (file:///usr/lib/node_modules/matterbridge-home-assistant/lib/home-assistant/home-assistant-matter-adapter.js:91:9)
Jun 30 11:14:49 chip matterbridge[7690]:     at async HomeAssistantMatterAdapter.expensiveUpdate (file:///usr/lib/node_modules/matterbridge-home-assistant/lib/home-assistant/home-assistant-matter-adapter.js:45:13)
Jun 30 11:14:49 chip matterbridge[7690]:     at async HomeAssistantClient.expensiveUpdate (file:///usr/lib/node_modules/matterbridge-home-assistant/lib/home-assistant/home-assistant-client.js:50:13)

[t0bst4r]

Bug fix is on its way 🙈 Just fixed it on my mobile, so hoping it actually works. 😂

[genehand]

Bug fix is on its way 🙈 Just fixed it on my mobile, so hoping it actually works. 😂

Haha cool I can test again.

could you test what happens when you do the following service call on a light which only supports xy?

The service call with xy_color is all good, as is hs_color so yeah I think it handles all the conversions.

[t0bst4r]

Release 1.5.1 is available. Could you try again?

[genehand]

Looks good in matterbridge now but Alexa is showing Color Capabilities: None

OnOff: true Hue: 19 Saturation: 92% Level: 255%

I'd only need to convert to hs when the state update comes from HA.

Also don't know if this is universal but the 3 xy lights I have (2 hue, 1 sengled) have attributes for each type:

hs_color: 26.827, 35.453
rgb_color: 255, 205, 164
xy_color: 0.422, 0.366

[genehand]

Update: deleted the device in alexa to reset it. Excluded in mb, restarted, then re-included and restarted again. Came back with the same endpoint id but now it has Color Capabilities: Color, Color Temperature 🎉

I could've reset commissioning but didn't want to redo some routines again 😄

[t0bst4r]

Also don't know if this is universal but the 3 xy lights I have (2 hue, 1 sengled) have attributes for each type

Yes I have seen the same behaviors for virtual lights, but wouldn’t rely on that. Maybe in that case we could prefer hs but still fall back to the others.

ok, good to know that it works. Does also the color conversion match (roughly)? (The color Selected in Alexa vs the one assigned in HA)

[t0bst4r]

Another user has verified that hs_color is available for xy-lights. I changed it in #143 to always prefer hs, then rgb, then xy (from highest confidence & compatiblity to lowest 😁 )

[genehand]

Sorry missed this the other day, matches up great here with 1.5.2 🙌