ZHA Light Transition Issue

[Daniel-dev22]

The problem

After upgrading from 2022.6.7 to 2022.7.2 my lights are not functioning the same way.

Previously turning on any of my 50+ ecosmart bulbs a mix of br30s and a19s to 4500k 100% the lights turned on instantly with no noticeable delay from service call to lights on. The only noticeable delay from service call to lights on was anything less than 4500k such as 2500k at 50%.

I use all zha groups by the way.

Now it's hit or miss where light groups may turn on both with a service call for 4500k 100% or 2500k 50% brightness and they may get stuck at 1%. Which is apart of the recent transition update as it's noticeable.

I first noticed the noticeable transition delay to 4500k 100% which as noted earlier never happened, I actually saw 1% then a second or 2 later 100%. I thought my repeat 2 times on all light service calls was the culprit and when I removed it I noticed from the lights I noticed. Then I realized it wasn't that because they were now getting stuck at 1% and the 1 or 2 second delay was the repeat 2 times saving the day essentially from having lights at 1% when they should be at 50% or 100%.

I will attach videos/photos perfectly demonstrating the issue. It doesn't happen all the time, sometimes the same light group that was stuck on 1% 10 minutes ago will turn on correctly without the assistance of repeat.

In this video this was a single service call to turn the zha light group on to 4500k 100%. That noticeable dim up then full brightness never occurred. At least it went to full brightness as I think the expected behavior is to do this on different light settings than previous settings such as different temperatures. Except this was the same setting. It appears as if after an hour let's say of being off it struggles to turn on. See the next video for why.

https://user-images.githubusercontent.com/47092714/178126694-aeee2792-d920-43eb-aa77-07d5cf7d6ea0.mp4

In this video you can see it turn off from the first video. And when a service call was sent to turn back on to the same setting as the first video it was instant. Great, except if after awhile of it being off the first video is what happens.

https://user-images.githubusercontent.com/47092714/178126759-6ec9781a-3fda-4eeb-98fa-10f9de0b1aa5.mp4

Now here's an example of going from 4500k 100% previous state before being turned off to 2500k 50%. This as noted earlier would take a little bit longer on all light groups no matter the size. This is 7 bulbs but this is also occuring for both 4500k 100% and 2500k 50% on 2 light bulb groups.

It got stuck at 1% I had to send the service call again for it to go to 50%.

https://user-images.githubusercontent.com/47092714/178126798-7374ecff-20d8-41e9-b862-7f30ccc322fd.mp4

All of these videos were taken within 2 minutes of each other.

What version of Home Assistant Core has the issue?

2022.7.2

What was the last working version of Home Assistant Core?

2022.6.7

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ZHA

Link to integration documentation on our website

No response

Diagnostics information

config_entry-zha-279bc4cb5d0dc5e33b87e5a44fbe6ad2.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[dmulcahey]

Can you attach the HA log from this? If debug isn’t set for all libs, please set debug on and reproduce and attach the logs

[Daniel-dev22]

Can you attach the HA log from this? If debug isn’t set for all libs, please set debug on and reproduce and attach the logs

At 08:23 I started reproducing the issue with the kitchen light group.

I wanted to show how turning it off from 4500k 100% and back on within a short period to 4500k 100% results in a very noticeable transition that as noted earlier never occurred previously. Sometimes it will turn back on immediately with no noticeable transition to 4500k 100% but not always.

https://user-images.githubusercontent.com/47092714/178145571-c7658d3a-5961-4ae7-a925-b7036d311b84.mp4

Here to demonstrate a true state change I turned them off at 4500k 100% and did a service call to turn them on to 2500k 50%. As you can see there was a very noticeable transition delay to turn on.

https://user-images.githubusercontent.com/47092714/178145733-1ce2a63d-db47-4660-b22a-82b844158071.mp4

At this point the lights were previously 2500k 50% from the previous video and should have transitioned to 4500k 100% as that was the service call, instead they were stuck at 1% 2500k

https://user-images.githubusercontent.com/47092714/178145652-ec20ccb9-9538-46ba-91ca-89a874134063.mp4

The lightgroup in the videoes nwk's:

0x655f
0x3e30
0x40bb
0x2551
0xc1ec
0x75d0
0x0a56

In this picture the lights should have turned on to 4500k 100%. Instead they were stuck at 1% 4500k. Previous state was 4500k 100%.

The lightgroup in the picture:

0x4a6f
0xae3f

ZHA Transition Issue Logs.txt

[TheJulianJES]

It might have nothing to do with the issue, but can you restart Home Assistant while debug logging is enabled and search for "Z-Stack" in the logs? You should see the build number which is something like 20220101. Please let me know what version you're running.

[Daniel-dev22]

I'm running the latest stable version.

Connected via Texas Instruments CC1352/CC2652, Z-Stack 3.30+ (build 20220219)

[TheJulianJES]

Can you test if there's any difference with lights not reaching the final target state (from an off state) when you force that service call to use 0 as a transition?

Also, is the behavior different if you have two service calls immediately after one another where the first call sets only brightness (with a transition if wanted) and the second one then does the color change (with a transition if wanted) (could also add brightness change here again).

[Daniel-dev22]

Didn't help.

Just tried it with a set of 4 lights. I did both 2500k previous state off to on 2500k and 4500k. I also had 3 of 4 transition. 1 didn't. Right now they are at 1% with a previous state of 2500k and the service call below.

service: light.turn_on
data:
  transition: 0
  kelvin: 2500
  brightness_pct: 50
target:
  entity_id: light.living_room_lights_main

If I do a repeat of 2 on the same service call it will correct the issue of getting stuck at 1%. If I don't they will stay at 1% for 90% of the time.

In the areas I purposely removed the repeat from for testing this it usually gets stuck transitioning between color temperatures or even the same temperature as if it forgot. The rest of the house I left repeat count 2 on because as you could imagine the lights turning on to 1% is not ideal.

[TheJulianJES]

I'll definitely have a proper look at this later. It seems like (ZHA group) messages are getting dropped somewhere (and are not tried to be sent again or does the order mix up?) (Might produce different behavior depending on the coordinator)

[Daniel-dev22]

I'll definitely have a proper look at this later. It seems like (ZHA group) messages are getting dropped somewhere (and are not tried to be sent again or does the order mix up?) (Might produce different behavior depending on the coordinator)

I think you're on to something about the zha groups because I just created an ha Group for group of 4 I was just testing the transition with and they didn't get stuck. Still noticeable transition even from going from the same previous state let's say 4500k 100% to 4500k 100%

I do have to specify transition of 0 though. To have a faster transition even from off 4500k 100% to on 4500k 100%, as noted before this used to be very fast.

Just now doing another test using transition 0. I did previous 2500k 50% to on 4500k 100% and 3 of 4 successfully transitioned. 1 is stuck at 1%. So something is definitely happening and not just zha groups potentially. But I'm not the expert in this the way you and David are.

[TheJulianJES]

I think the issue might be that broadcast messages are sent somewhat optimistically. So the multiple turn on calls may not be executed at all or in a wrong order. For single lights, zigpy_znp/bellows is always waiting until the light has received the request. This isn't done for groups because the waiting is sometimes massively delayed, so a simple group light change operation which causes at least two Zigbee calls can take multiple seconds before it finishes (https://github.com/home-assistant/core/issues/42249 was fixed by having bellows sent group messages optimistically. zigpy_znp already did this before but it was still further changed IIRC).

Recently, https://github.com/home-assistant/core/pull/74024 was merged into HA 2022.7.0. This PR makes one change: If a light is request to turn on with a color/temperature call from being off, it will (with a 0 second transition) turn on the light to 1% brightness, then (with another 0s transition) immediately change the color/temperature to the target and then dim-up the light to the target brightness with the transition specified in the service call. (This needs to be done because Zigbee lights cannot accept a color change if it's off, so it needs to be turned on first. But then the color also transitions from the old color which isn't wanted -> see the PR for more details and a small video clip)

Note: Those changes do not do anything when (1) there's no color color/temperature in the service call OR (2) the light is already on

(The implementation in that PR is very similar to the one done by Philips Hue when using it with HA and I don't think similar issues have been reported for that.)

The issue that you have with ZHA groups isn't really caused by that change but, at least for you, got much worse if the messages aren't received (or even sent) in the correct order. I didn't have any issues whatsoever in my testing with single lights and also tried ZHA groups just fine. (Still using them just fine on my main network.) My main ZHA groups (of ~10 lights) are near the coordinator though (and I'm also on a pretty empty Zigbee channel). I'll later create some ZHA groups with lights further away and see if I can reproduce the issue. I'll also have a look how zigpy_znp handles group requests (for example, if there's a delay to confirm the message is sent or if they're just scheduled to be sent without waiting at all. If so, perhaps a small 0.1 second delay could be added after each group call if multiple calls need to be made for one turn_on service call.)

[TheJulianJES]

Just now doing another test using transition 0. I did previous 2500k 50% to on 4500k 100% and 3 of 4 successfully transitioned. 1 is stuck at 1%. So something is definitely happening and not just zha groups potentially.

I have some large HA scenes that turn on 11 lights from an off state and change their color + brightness and although it takes a few seconds for all lights to react, they do eventually change completely. (Zigbee scenes would be nice for this) If you already (sometimes) have issues with 4 bulbs, your network might have some interference (or other issues). I guess that could also issues with ZHA groups (of messages being dropped/received in the wrong order). (Again, I'll have a more in-depth look at this later)

[Daniel-dev22]

Just now doing another test using transition 0. I did previous 2500k 50% to on 4500k 100% and 3 of 4 successfully transitioned. 1 is stuck at 1%. So something is definitely happening and not just zha groups potentially.

I have some large HA scenes that turn on 11 lights from an off state and change their color + brightness and although it takes a few seconds for all lights to react, they do eventually change completely. (Zigbee scenes would be nice for this) If you already (sometimes) have issues with 4 bulbs, your network might have some interference (or other issues). I guess that could also issues with ZHA groups (of messages being dropped/received in the wrong order). (Again, I'll have a more in-depth look at this later)

Previous to this update there were 0 issues. The network is extremely responsive, I don't think there's any inteference issues. I have 126 devices the majority of which are 50+ ecosmart bulbs which act as repeaters and the rest are end devices such as shades, buttons and other things. The biggest light group I have is 7 bulbs which I showed in the video. Otherwise the majority are 4 and a lot of 2 bulbs. Distance from the coordinator is not an issue as there's 2 light groups directly next to trh coordinator with this issue if I turn repeat off. I don't like the idea of waiting a few seconds for lights to reach which is why I stopped using ha scenes and ha groups. When I switched to zha groups I was amazed at how fast all light groups turned on vs previous behavior with ha groups. All turn on at the same time and transition at the same time (previous to this update that is).

[TheJulianJES]

Another thing I just thought of: the second "move to level" call will only do something if the light is already on (which it clearly should be at that point), as the first "move to level with on off" call turned it on to 1%. Maybe the second call can be replaced with another "move to level with on off" call.

(It wouldn't solve the underlying issue though. Just wondering what difference it would make.)

[Daniel-dev22]

Can this be tested with custom deps deployment? Any changes you would like for me to test as long as I can roll back with a simple remove command, I will test it if it helps solve the issue.

[TheJulianJES]

I don't like the idea of waiting a few seconds for lights to reach which is why I stopped using ha scenes and ha groups. When I switched to zha groups I was amazed at how fast all light groups turned on vs previous behavior with ha groups. All turn on at the same time and transition at the same time (previous to this update that is).

I can see that. The underlying issue for the change in 2022.7.0 is that there’s no waiting going on at all probably (for ZHA groups). So it might just be "luck" if all messages are received/sent in the correct order. (Again, I wasn’t able to reproduce the issue just yet with my main ZHA groups.)

If the underlying issue (of group messages being lost or mixed up) can’t be solved easily, a config option for #74024 could be added (maybe to disable it at all or just for ZHA groups) (since it doesn’t cause any issues for me, even though I’m also on a TI coordinator and have large ZHA groups).

(I also wonder if Ecosmart bulbs are doing something funky again. I tested the change on different generation of Hues, IKEA bulbs, Sunricher, GLEDOPTO Pro and some others without issues.)

[TheJulianJES]

Can this be tested with custom deps deployment? Any changes you would like for me to test as long as I can roll back with a simple remove command.

In my experience that addon is somewhat broken. First, I'll try to reproduce your issue later today and see if any "easy" changes help solve the issue.

[Daniel-dev22]

If the new behavior is a transition no matter what even if it's the same previous state then as long as a transition of 0 will make it faster that's fine. I am hopeful this feature will speed up transitions from different previous states. Or transitions from off to 2500k because no matter what the previous state was meaning if previous was 2500k 50% and turn on is 2500k 50% it always took noticeably longer before 2022.7. I assume this is something to do with the warmer temperature.

[Daniel-dev22]

I also agree, if it's not an easy fix to at least have a configuration option to disable it all together. Although, not just for zha groups as the issue occurs with ha groups as well.

[deam0n]

I have the exact same issue.

It's not related to groups.

I have:

(scene that puts 100% brightness and 197 temperature in a light group)

  - service: scene.turn_on
    data: {}
    target:
      entity_id: scene.bathroom_day_scene

When calling the scene from an automation - the scene will not fully activate, leaving 1 of the bulbs (not always the same.. random) not at 100% brightness. It's a hit or miss.

If I press the "play" icon on the scene menu, it does not miss.

In order to troubleshoot the scenes and groups, I've changed my automation to:

- service: light.turn_on
    data:
      color_temp: 197
      brightness_pct: 100
    target:
      entity_id:
        - light.bath_1
        - light.bath_2
        - light.bath_3

And the issue remains (not all bulbs turn on at 100% brightness.)

This has been working correctly for at least 1year, it just stopped working from the update.

EDIT: reverting back to 2022.6.7 fixed the issue.

Lights: Lidl GU10 (zhaquirks.lidl.cct.CCTLight) Coordinator: Conbee2 Platform: ZHA

[bwrex]

Same problem here :/ also with lights without a zha group.

[Daniel-dev22]

What lights are you guys using? Ecosmart, Ikea, Philips, etc. Post your debug logs just as I did. It will help them find the issue faster. Including your diagnostic information from the "download diagnostics". The firmware of your coordinator as well. Videos as well if possible. Match them with the logs. Include the nwk addresses of the lights in the videos and time stamps of when you took the video to match up with the logs. That will help them sort through the logs. Post the steps you took to reproduce/different methods of testing. Essentially what I did above ^. Again this will help them establish a pattern potentially and find the root cause much faster if this is occuring with more types of lights and different circumstances (non zha groups, non ha groups, with scenes not just service calls, different coordinators, etc.).

[Daniel-dev22]

Lights: Lidl GU10 (zhaquirks.lidl.cct.CCTLight) Coordinator: Conbee2 Platform: ZHA

@TheJulianJES It appears it's just not ecosmart acting weird or the coordinator. I'm on sonoff zigbee 3.0 coordinator running the latest stable firmware, the same issue is appearing on a conbee2.

Can you attach all the logs as well @deam0n?

[bwrex]

Hi I have a Conbee 2 coordinator with HUE lights. I have already updated the firmware to the latest firmware 0x26780700 due to the problem. But the problem still exists.

But my main problem is that the light is turned on but always only to 1%. With renewed movement, the brightness is then set to the correct setting of the automation.

Here is the diagnostic data from the coordinator.

{ "home_assistant": { "installation_type": "Home Assistant OS", "version": "2022.7.3", "dev": false, "hassio": true, "virtualenv": false, "python_version": "3.10.5", "docker": true, "arch": "x86_64", "timezone": "Europe/Berlin", "os_name": "Linux", "os_version": "5.15.45", "supervisor": "2022.07.0", "host_os": "Home Assistant OS 8.2", "docker_version": "20.10.14", "chassis": "vm", "run_as_root": true }, "custom_components": { "powercalc": { "version": "v0.22.1", "requirements": [ "numpy>=1.21.1" ] }, "ontario_energy_board": { "version": "0.3.1", "requirements": [ "beautifulsoup4==4.10.0", "holidays==0.12" ] }, "bosch_shc": { "version": "0.4.28", "requirements": [ "boschshcpy==0.2.31" ] }, "dwd_weather": { "version": "1.2.22", "requirements": [ "simple_dwd_weatherforecast==1.1.5", "markdownify==0.6.5" ] }, "xiaomi_cloud_map_extractor": { "version": "v2.2.0", "requirements": [ "pillow", "pybase64", "python-miio", "requests", "pycryptodome" ] }, "average": { "version": "2.2.3", "requirements": [] }, "ui_lovelace_minimalist": { "version": "v1.0.2", "requirements": [] }, "alexa_media": { "version": "4.0.3", "requirements": [ "alexapy==1.26.1", "packaging>=20.3", "wrapt>=1.12.1" ] }, "spotcast": { "version": "v3.6.29", "requirements": [ "spotify_token==1.0.0" ] }, "fasthue": { "version": "1.2.1", "requirements": [] }, "abfallplus": { "version": "0.2.1", "requirements": [ "recurring-ical-events>=1.0.1b0", "icalendar>=4.0.4" ] }, "zha_toolkit": { "version": "v0.8.11", "requirements": [] }, "mass": { "version": "2022.7.0b1", "requirements": [ "music-assistant==1.6.0" ] }, "cryptostate": { "version": "2.0.0", "requirements": [] }, "holidays": { "version": "1.8.0", "requirements": [ "python-dateutil>=2.8.2", "holidays>=0.14.2" ] }, "hacs": { "version": "1.26.0", "requirements": [ "aiogithubapi>=22.2.4" ] }, "shelly": { "version": "1.0.0", "requirements": [ "pyShelly==1.0.2", "paho-mqtt==1.6.1", "websocket-client" ] }, "esxi_stats": { "version": "0.6.4", "requirements": [ "pyvmomi==7.0.3" ] }, "var": { "version": "0.14.2", "requirements": [] }, "ble_monitor": { "version": "8.9.8", "requirements": [ "pycryptodomex>=3.14.1", "janus>=1.0.0", "aioblescan>=0.2.13", "btsocket>=0.2.0", "pyric>=0.1.6.3" ] } }, "integration_manifest": { "domain": "zha", "name": "Zigbee Home Automation", "config_flow": true, "documentation": "https://www.home-assistant.io/integrations/zha", "requirements": [ "bellows==0.31.0", "pyserial==3.5", "pyserial-asyncio==0.6", "zha-quirks==0.0.77", "zigpy-deconz==0.18.0", "zigpy==0.47.2", "zigpy-xbee==0.15.0", "zigpy-zigate==0.9.0", "zigpy-znp==0.8.0" ], "usb": [ { "vid": "10C4", "pid": "EA60", "description": "2652", "known_devices": [ "slae.sh cc2652rb stick" ] }, { "vid": "10C4", "pid": "EA60", "description": "sonoffplus", "known_devices": [ "sonoff zigbee dongle plus" ] }, { "vid": "10C4", "pid": "EA60", "description": "tubeszb", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "tubeszb", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "zigstar", "known_devices": [ "ZigStar Coordinators" ] }, { "vid": "1CF1", "pid": "0030", "description": "conbee", "known_devices": [ "Conbee II" ] }, { "vid": "10C4", "pid": "8A2A", "description": "zigbee", "known_devices": [ "Nortek HUSBZB-1" ] }, { "vid": "0403", "pid": "6015", "description": "zigate", "known_devices": [ "ZiGate+" ] }, { "vid": "10C4", "pid": "EA60", "description": "zigate", "known_devices": [ "ZiGate" ] }, { "vid": "10C4", "pid": "8B34", "description": "bv 2010/10", "known_devices": [ "Bitron Video AV2010/10" ] } ], "codeowners": [ "@dmulcahey", "@adminiuga" ], "zeroconf": [ { "type": "_esphomelib._tcp.local.", "name": "tube" }, { "type": "_zigate-zigbee-gateway._tcp.local.", "name": "zigate" } ], "after_dependencies": [ "onboarding", "usb", "zeroconf" ], "iot_class": "local_polling", "loggers": [ "aiosqlite", "bellows", "crccheck", "pure_pcapy3", "zhaquirks", "zigpy", "zigpy_deconz", "zigpy_xbee", "zigpy_zigate", "zigpy_znp" ], "is_built_in": true }, "data": { "ieee": "REDACTED", "nwk": 0, "manufacturer": "dresden elektronik", "model": "ConBee II", "name": "dresden elektronik ConBee II", "quirk_applied": false, "quirk_class": "zigpy_deconz.zigbee.application.DeconzDevice", "manufacturer_code": 4405, "power_source": "Mains", "lqi": null, "rssi": null, "last_seen": "2022-07-12T18:25:38", "available": true, "device_type": "Coordinator", "signature": { "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Coordinator: 0>, complex_descriptor_available=0, user_descriptor_available=1, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.RxOnWhenIdle|MainsPowered|FullFunctionDevice|AlternatePanCoordinator: 15>, manufacturer_code=4405, maximum_buffer_size=71, maximum_incoming_transfer_size=43, server_mask=64, maximum_outgoing_transfer_size=43, descriptor_capability_field=<DescriptorCapability.NONE: 0>, allocate_address=False, is_alternate_pan_coordinator=True, is_coordinator=True, is_end_device=False, is_full_function_device=True, is_mains_powered=True, is_receiver_on_when_idle=True, is_router=False, *is_security_capable=False)", "endpoints": { "1": { "profile_id": 260, "device_type": "0x0005", "in_clusters": [ "0x0000", "0x000a", "0x0019", "0x0501" ], "out_clusters": [ "0x0001", "0x0020", "0x0500", "0x0502" ] }, "242": { "profile_id": 41440, "device_type": "0x0064", "in_clusters": [], "out_clusters": [ "0x0021" ] } } }, "entities": [], "neighbors": [ { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0xE497", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0xE4B1", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0x06D7", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0xE02F", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0x62A7", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0x7AAB", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0x5C23", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0x7E6A", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0x7696", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0x9F8A", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0xA0AF", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "Router", "rx_on_when_idle": "On", "relationship": "Sibling", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0xCA4F", "permit_joining": "Accepting", "depth": "1", "lqi": "252" }, { "device_type": "EndDevice", "rx_on_when_idle": "Off", "relationship": "Child", "extended_pan_id": "REDACTED", "ieee": "REDACTED", "nwk": "0xB0D3", "permit_joining": "NotAccepting", "depth": "1", "lqi": "252" } ], "endpoint_names": [ { "name": "CONFIGURATION_TOOL" }, { "name": "unknown 100 device_type of 0xa1e0 profile id" } ], "user_given_name": null, "device_reg_id": "f7f0fee9c6b580351cb5ef1dddb4b602", "area_id": null, "cluster_details": { "1": { "device_type": { "name": "CONFIGURATION_TOOL", "id": 5 }, "profile_id": 260, "in_clusters": { "0x0000": { "endpoint_attribute": "basic", "attributes": {}, "unsupported_attributes": {} }, "0x000a": { "endpoint_attribute": "time", "attributes": {}, "unsupported_attributes": {} }, "0x0019": { "endpoint_attribute": "ota", "attributes": {}, "unsupported_attributes": {} }, "0x0501": { "endpoint_attribute": "ias_ace", "attributes": {}, "unsupported_attributes": {} } }, "out_clusters": { "0x0001": { "endpoint_attribute": "power", "attributes": {}, "unsupported_attributes": {} }, "0x0020": { "endpoint_attribute": "poll_control", "attributes": {}, "unsupported_attributes": {} }, "0x0500": { "endpoint_attribute": "ias_zone", "attributes": {}, "unsupported_attributes": {} }, "0x0502": { "endpoint_attribute": "ias_wd", "attributes": {}, "unsupported_attributes": {} } } }, "242": { "device_type": { "name": "unknown", "id": 100 }, "profile_id": 41440, "in_clusters": {}, "out_clusters": { "0x0021": { "endpoint_attribute": "green_power", "attributes": {}, "unsupported_attributes": {} } } } } } }

[Daniel-dev22]

@TheJulianJES any idea what the issue is yet?

[Daniel-dev22]

Now I'm noticing some lights occasionally turn on at the correct 100% brightness only to become 1% a second later and get stuck at 1%. This is also with repeat of 2 times. This was previously what I thought was a workaround but not a guarantee anymore. Additionally again no issues with the network or interference in fact the most recent group I noticed this with is directly in front of the coordinator.

[Daniel-dev22]

Fixed in #75220

[bwrex]

hmm i still have the problem - even after the update.:/ how can I make the option available in the ZHA configuration? sorry ;)

[dmulcahey]

hmm i still have the problem - even after the update.:/ how can I make the option available in the ZHA configuration? sorry ;)

We can’t add a configuration in a .release. We will add something in the next HA release to disable this functionality completely.

[deam0n]

After update the issue did not go away in my case. Reverting again to 2022.6

[dmulcahey]

hmm i still have the problem - even after the update.:/ how can I make the option available in the ZHA configuration? sorry ;)

After update the issue did not go away in my case. Reverting again to 2022.6

Can you both open your own issues detailing what you are seeing. Please include the coordinator in use, the manufacturer and models of the bulbs (diagnostic files too please) and a description of what is happening (short videos would be helpful too)? This will help to get your issues resolved.

[bwrex]

Hi, in my case i use a conbee 2 coordinator. my problem is that individual lights turn on automations with only one percent brightness. The color is correct but the brightness is only 1%. This happens on average about every 5th time. In the meantime I have adjusted the automations so that the light is switched on and this action is carried out again after 2 seconds. So at least after 2 seconds I have light :D

[Daniel-dev22]

Hi, in my case i use a conbee 2 coordinator. my problem is that individual lights turn on automations with only one percent brightness. The color is correct but the brightness is only 1%. This happens on average about every 5th time. In the meantime I have adjusted the automations so that the light is switched on and this action is carried out again after 2 seconds. So at least after 2 seconds I have light :D

That was the same issue I had and documented in the videos above and logs. Repeat only worked 50% of the time for me. However, for this to ever be fixed for you, you will need to post logs. Simply saying what the problem is, isn't enough information. Especially after an update where the same issue you're describing was actually fixed for me and the pr that started this was tested on hue lights as well. Therefore the only way to have a chance of resolving this, is your logs as they will show exactly what happened. Otherwise it's impossible for the devs to know what's going wrong. Creating a separate issue is advisable because there may be something else wrong and what was wrong for this issue has been solved.

[bwrex]

config_entry-zha-11c966c75ff45a19df02b4e3884a22a0.json.txt Do you need this one?