Devices unavailable after Conbee to SkyConnect migration

prnzngr commented 1 year ago

The problem

I switched from Deconz/Conbee to ZHA/Skyconnect and since then the problems started. Everyday some random devices (Aqara sensors, Ikea Bulbs) getting unavailable. I have to pair them again and the next day some diffent device is unavailable. With Deconz/Conbee I never had this problems.

What version of Home Assistant Core has the issue?

core-2023.1.5

What was the last working version of Home Assistant Core?

core-2022.11

What type of installation are you running?

Home Assistant OS

Integration causing the issue

zha

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zha

Diagnostics information

zha-f63193a751e4f18abbdbeaba6257af97-LUMI lumi.sensor_magnet.aq2-38e364b71addd13e8f72c896cb83e544.json.txt zha-f63193a751e4f18abbdbeaba6257af97-Zigbee Coordinator-aabc7e236d33f421590e46eb61ea0400.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2023-01-19 12:35:59.016 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x99DE](lumi.sensor_magnet.aq2): last_seen is 141280.53930068016 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:03.510 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xAD16](lumi.sensor_wleak.aq1): last_seen is 1038776.234536171 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:04.011 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0CBA](SmokeSensor-EF-3.0): last_seen is 167550.2345740795 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:28.082 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x6378](lumi.sensor_wleak.aq1): last_seen is 144684.77171301842 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:30.030 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x3BBB](TRADFRI remote control): last_seen is 144489.35309433937 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:30.057 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xDB20](TRADFRI control outlet): last_seen is 614320.0762073994 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:32.193 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xAE69](lumi.sensor_magnet.aq2): last_seen is 169974.5131304264 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:47.953 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xC7D4](TRADFRI bulb E27 WS opal 1000lm): last_seen is 20564.596658945084 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:52.008 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x2A27](lumi.sensor_magnet.aq2): last_seen is 108069.15588212013 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:36:52.032 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x360D](lumi.sensor_magnet.aq2): last_seen is 170186.2264046669 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:37:04.510 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xAD16](lumi.sensor_wleak.aq1): last_seen is 1038837.235011816 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:37:12.012 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0CBA](SmokeSensor-EF-3.0): last_seen is 167618.23617124557 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:37:12.019 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x99DE](lumi.sensor_magnet.aq2): last_seen is 141353.54190301895 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:37:32.083 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x6378](lumi.sensor_wleak.aq1): last_seen is 144748.77293539047 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:37:36.059 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xDB20](TRADFRI control outlet): last_seen is 614386.0775065422 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:37:45.031 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x3BBB](TRADFRI remote control): last_seen is 144564.3546833992 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:37:51.194 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xAE69](lumi.sensor_magnet.aq2): last_seen is 170053.51456308365 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:38:05.511 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xAD16](lumi.sensor_wleak.aq1): last_seen is 1038898.2359614372 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:38:11.954 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xC7D4](TRADFRI bulb E27 WS opal 1000lm): last_seen is 20648.59741950035 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:38:20.009 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x2A27](lumi.sensor_magnet.aq2): last_seen is 108157.15664672852 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:38:20.013 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0CBA](SmokeSensor-EF-3.0): last_seen is 167686.2369081974 seconds ago and ping attempts have been exhausted, marking the device unavailable
2023-01-19 12:38:25.020 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x99DE](lumi.sensor_magnet.aq2): last_seen is 141426.5432062149 seconds ago and ping attempts have been exhausted, marking the device unavailable

Additional information

No response

rchiileea commented 1 year ago

For those saying it’s just sky connect stop as it will make the cause hard to track I switched for a whole new system and sky connect and started resetting devices and added them fresh then went away for work after doing a 14 of them, I got back to devices still fine as soon as I updated to 2023.2 (by the time I got back it was on 2023.2.4 so that was my update and things dropped off, so I looked at the old install with Conbee 2 it was fine updated that and next morning stuff had dropped of, so I started messing with then new build both with only zha and both sticks separately, I also tried with zigbee2mqtt and the same result, updating makes stuff start to drop off… so I restored back to 2023.1 and have not seen no issue crop up on either stick. This is not a sky connect issue, something else is going on to do with one of the 2023.2 updates

austwhite commented 1 year ago

@rchiileea It is not just SkyConnect, but please remember people here are logging this as a result of SkyConnnect in ZHA That is what the original poster found. I haven't had time to get logs as I am dealing with cancer and 7nable to experiment right now, but I found the SkyConnect was fine with OpenHab so the issue is something with SiLabs chipset and ZHA. Unfortunately I don't know when I will be able to play next due to my health issues and I needed to move the home system to be reliable while I am seeking medical treatments. I hope someone else can maybe test in OpenHab and get the logs so we can find 5he bugs 8n ZHA that cause the random disconnects for some users

lougreenwood commented 1 year ago

@austwhite So sorry to hear that you're dealing with cancer. Not to politicise it, but I think your situation underlines why an LTS release stream is needed. I hope you get better soon.

@puddly FWIW, It seems that my Hue motion SML003 sensors are solid on my network (Sonoff V2 Plus/E) - so for me, the only Zigbee devices which are unstable are Hue SML001 sensors (my Zigbee network only has Philips Hue devices on it).

Would some logs showing SML001 going unavailable and SML003 staying connected be useful?

rchiileea commented 1 year ago

@austwhite I wish you a speedy recovery, Yes I understand, on this was created by people reporting issues with sky connect, I thought its best that it was mentioned that due to fact i was moving machines as well as dongles at the time I had a chance to play around with all of it and did and discovered both conbee 2 and skyconnect are loosing devices (as I only retruned in time to try the 2023.2.4 update) since this update on both sticks and with both zha and zigbee2mqtt.. restoring to 2023.1 got rid of the issue, so there is something else going on rather than pointing straight at the stick or zha as the same issue happens on both sticks and both zha and zigbee2mqtt. There must have been something happen between 2023.1 and 2023.2 that is causing the issue. if I did not have to go away for work again I would do more testing, but I cant leave the wife and son with a non working smart home.

TheFelix93 commented 1 year ago

@puddly

Can you also enable ZHA debug logging on both 2023.1.7 and the latest release, to show a sensor disconnecting with the new release and not the old release?

I updated to 2023.2.5 and enabled debug logging in zha yesterday evening. Till now no disconnects happened. I am tracking humidity on my building site, currently the floor fill is drying, so the value is changing all the time, so I guess the sensor is not going into standby mode. Could be, that the problem only occurs when a sensor goes to standby and will not come back online.

I keep the logging enabled and wait until a disconnect/not available happens again.

timiman commented 1 year ago

I want to report that I've had zero disconnects by using 2023.3.0b5. Except two TRADFRI repeaters which change from unavailable/available all day long, but without hurting any End Devices of the network which are connected to coordinator via them. It might be the connected End Devices that are put themselves to "power saving sleep" due to inactivity and thus the TRADFRI repeater itself. In my case, I've change the position of one TRADFRI repeater a little bit further away from a wifi repeater, so it might have helped a bit, too. Also, I really don't know if anything from .0b4 or .0b5 helped with that but the only other parameter that was changed on the HA installation was the manual removal of HACS. The removal of HACS -happened some months ago- from within HA UI was not fully completed, because by searching the logs for info regarding the issue I've got with .0b3 update, I've found that HA was reporting an installation of HACS was present on the system which could not be found on HA UI. So, I've 'rmdir' the HACS installation folder manually from Terminal. I repeat, I do not know if this has to do anything with the devices becoming unavailable, but it was the only thing that was changed in between. Finally, I've also enabled debugging mode for ZHA, but no End Device became unavailable during this time.

HarvsG commented 1 year ago

I strongly suggest anyone affected by "devices randomly stop working/go offline" issues please take a look at https://skyconnect.home-assistant.io/connectivity/, especially the "How to counter interference" section. In exceptionally noisy environments, the threshold between "just barely working" and "not working" is low and may have been exacerbated by switching coordinators. Try a different coordinator placement, orientation, a different USB extension cable, a second USB extension cable, etc. RF issues aren't intuitive and won't be revealed with just a WiFi scan.

another thing that has silently changed is the radio channel of the ZigBee network

If you used the ZHA migration flow, the network channel did not change. However, if you set up a new network from scratch, it will be formed on channel 15.

The only known "issue" with Conbee migration is that a relatively-recent firmware version is required, as otherwise the Conbee doesn't provide a way to read the network key frame counter with older firmwares. If that counter isn't migrated, some brands of devices will refuse to receive commands from the coordinator and will only be able to send updates.

Can also confirm that this wasn't the issue for me. Both sticks were on the same USB 2 ext lead. WiFi access points on channels that don't overlap with Zigbee 15, commands still reached distant parts of the network with a similar reliability to the Conbee II. Issue was exclusively with battery-powered devices dropping off the network and/or having rapid battery drain.

lougreenwood commented 1 year ago

Likewise for me - I'm now ~5 days in with no dropouts from 5 SML003 Hue motion sensors whereas 13/14 Hue SML001 are unavailable.

So seems that it's a subset of battery devices that are affected.

timiman commented 1 year ago

Also, I do not know how to check if any firmware on the TRADFRI repeaters was silently applied OTA during the last 10 days or so. It might be a parameter that we've missed. I've IKEA OTA enabled on configuration.yaml. I will search for an official online release list of IKEA firmwares.

Hedda commented 1 year ago

Also, I do not know how to check if any firmware on the TRADFRI repeaters was silently applied OTA during the last 10 days or so. It might be a parameter that we've missed. I've IKEA OTA enabled on configuration.yaml. I will search for an official online release list of IKEA firmwares.

FYI, @MattWestb tries to maintain an unofficial release list of IKEA Zigbee OTA files under zigpy discussions -> https://github.com/zigpy/zigpy/discussions/660

d-0l commented 1 year ago

Well, I can say after reverting back to a backup from 2 days prior to the Skyconnect migration didn't help.

The problem persists between ZHA and zigbee2mqtt, even with an updated firmware on the Sonoff stick.

The problem: All 3 motion sensors are simply not connecting to the rest of the zigbee network, despite correctly reporting occupancy under devices. They can't be used to trigger automations.

TheFelix93 commented 1 year ago

Hello, another update from my side.

After the problem did not reoccur after update to 2023.2.5 since days. I decided to restore my full backup/snapshot of the VM in Proxmox to the point where problem existed in the first place.

Result: Still no problems since two days... As I wrote before the measured humidity values are changing all the time, so the sensor may not go to sleep, which can be the problem.

I keep the debug logging active and will wait for the problem to reoccur.

MattWestb commented 1 year ago

@TheFelix93 Is your sensor connected to one router or the coordinator for the moment ? Look on the visualization / network map in ZHA.

TheFelix93 commented 1 year ago

@TheFelix93 Is your sensor connected to one router or the coordinator for the moment ? Look on the visualization / network map in ZHA.

Directly to the coordinator "ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2" I have only one sensor/device connected.

lougreenwood commented 1 year ago

Just installed 2023.3 hoping it might fix things based on some earlier replies. But within 6 minutes of re-pairing one of my sensors, it became unavailable. 🤦

austwhite commented 1 year ago

Well, I got a chance to run a couple of tests again and for some stupid reason my issue is now resolved. It sounds absolutely ridiculous, but I mounted my Sky Connect 90 degrees turned from how it was before, so instead of the stick laying on the horizontal plane, it is now vertical. It sounds ridiculous, but for 3 days I have had no devices going unavailable at all. I have 6 Philips Hue Motion Senors, the SML01 version, and all of them have been rock solid for 3 days now. I am still running 2023.2.5, haven't updated to 2023.3

rchiileea commented 1 year ago

This is not good tbh, I was hopping this issue would be just something introduced I. 2023.2 I think I’ll sit it out on 2023.1 as I am travelling a lot over the next few weeks

Sent from Outlook for iOShttps://aka.ms/o0ukef

From: Lou Greenwood @.> Sent: Wednesday, March 1, 2023 9:45:03 PM To: home-assistant/core @.> Cc: Richard Bowzer @.>; Mention @.> Subject: Re: [home-assistant/core] Devices unavailable after Conbee to SkyConnect migration (Issue #86231)

Just installed 2023.3 hoping it might fix things based on some earlier replies. But within 6 minutes of re-pairing one of my sensors, it became unavailable. 🤦

— Reply to this email directly, view it on GitHubhttps://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhome-assistant%2Fcore%2Fissues%2F86231%23issuecomment-1450889009&data=05%7C01%7C%7Cbc3ee510064c45017eb608db1a9e373c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638133039058412965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yaVUn4cRTqBTMVgjPLZLXuFX%2Ftci583QiFiT3u0EEzc%3D&reserved=0, or unsubscribehttps://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAU4KVPZLDJ2TV5VFQ7TQLDLWZ67N7ANCNFSM6AAAAAAUALUYFM&data=05%7C01%7C%7Cbc3ee510064c45017eb608db1a9e373c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638133039058412965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ga8aHniU%2B29W9L%2F%2FPVV9Sio1MBT2F77orrRlk0rsdVw%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>

Hedda commented 1 year ago

It sounds absolutely ridiculous, but I mounted my Sky Connect 90 degrees turned from how it was before, so instead of the stick laying on the horizontal plane, it is now vertical. It sounds ridiculous, but for 3 days I have had no devices going unavailable at all.

FYI, Zigbee Coordinator radio adapter and antenna orientation is covered here -> https://community.home-assistant.io/t/guide-for-zigbee-interference-avoidance-and-network-range-coverage-optimization/515752/

lougreenwood commented 1 year ago

@puddly i don't mean to pester, but since you mentioned being a maintainer related to ZHA I thought it ok to ping you.

Is this issue being looked into or is there any news to share?

I keep coming over the same story - issues with ZHA and Sonoff/SkyConnect and Philips SML001 sensors (SML003 not affected) where the sensor drops out after some short (mins to 1 day) amount of time yet the rest of the network is stable. Also the same story that the user moved from some other platform to ZHA with one of these coordinators, previously the network was fine (same device positions) but now the network is seemingly broken.

It seems something is fundamentally going wrong in many setups.

In my case, I have 14 SML001 that keep dropping out. I've moved the coordinator (Sonoff E), it's already on an extension cable, I have 40 router devices (hue bulbs/lightstrips/plugs). I've tried changing channels twice (first to 20, which my Hue hub was using previously, then to 25 after inspecting Wi-Fi interference and researching good channels to use to co-exist with an Eero mesh Wi-Fi network). Nothing has made any meaningful difference, the behaviour of the devices on the network is fine except for the SML001 sensors.

I'm concerned with what appears to be silence given the number of issues here and threads on HA forums - and aside from the usual (useful and well intentioned) advice to fix up the network fundamentals it seems no one knows what is going on.

Are you able to provide any more info on this? I've spent a lot of time trying to figure this out (prob 10+ hours researching, tinkering, changing channels, pairing etc. This has taught me some useful stuff WRT zigbee network health, but I haven't solved the issue and now I'm considering moving back to my rock solid Hue hub (I literally had it under a sofa, on top of a pi, next to a stack of network switches, PSUs, modem, firewall and ring alarm system for the last year of it's life with no noticeable issues aside from speed of comms for automations from Hue > HA > NR > HA > Hue) or to try zigbee2mqtt.

I have logs for the past few days, including channel switching if it's useful for debugging.

Thanks in advance, and thanks for your work on the project!

puddly commented 1 year ago

Is this issue being looked into or is there any news to share?

I have one of each on order and will see if I can replicate the problem on my network.

Can you please open a new issue specifically for connectivity issues with the Philips SML001 with SiLabs coordinators (i.e. SkyConnect/Yellow/Sonoff E)? I'm afraid that these general "devices unavailable" GitHub issues become unmanageable after a while due to them aggregating so many unrelated problems (general network issues, problems with specific devices, other coordinator hardware, etc.).

I have logs for the past few days, including channel switching if it's useful for debugging.

How specifically did you switch channels? In the ZHA configuration page, does Channel: show what you expect? The YAML config is only used when forming a new network, since Zigbee doesn't handle channel switching smoothly.

TheJulianJES commented 1 year ago

@lougreenwood Can you check the Basic: sw_build_id attribute on your SML001 sensors? And also check current_file_version on the Ota cluster please. (The sensor should wake up automatically when reading those attributes)

(To read them: Settings -> Integrations -> ZHA: Configure -> Devices -> select your SML001 -> three dots on the left -> Manage Zigbee device -> cluster -> select Basic in the first drop-down, then sw_build_id in the second drop-down menu and click "Get Zigbee attribute". Then, Ota in the first menu and current_file_version in the second, press read again and paste the results here.)

lougreenwood commented 1 year ago

@puddly / @TheJulianJES - I created a new issue here and included the info you requested in that issue - thanks for your help!

austwhite commented 1 year ago

Just as a note, this issue seems to have mutliple tickets open under various titles, maybe need to combine them all as the issue is not just related to Hue SML001 or SML003 detectors. Hue RWL021 and RWL022 dimmer switches are affected and also Aqara Motion/light sensors, some Aqara Temp/humidty sensors and Tuya zigbee motion sensors. It seems to affect a lot of battery operated devices

Ultra9k commented 1 year ago

Same issue. Two of my four philips motion sensors constantly become unavailable and I have to remove and re-add them and one of them is 1m away from the skyconnect.

austwhite commented 1 year ago

@Ultra9k See the new issue. IT could be the Hue Motion Sensors. It has been proven, also in my testing, that Hue Motion Sensors, particularly SML001 version, like to attach to the worst parent, the weakest link so to speak. That said, mine magically started working reliably in 2023.4 but they still like to attach to the weakest parent. Mind you, they do that on the Hue Bridge also

Caligo82 commented 1 year ago

Just as a note, this issue seems to have mutliple tickets open under various titles, maybe need to combine them all as the issue is not just related to Hue SML001 or SML003 detectors. Hue RWL021 and RWL022 dimmer switches are affected and also Aqara Motion/light sensors, some Aqara Temp/humidty sensors and Tuya zigbee motion sensors. It seems to affect a lot of battery operated devices

This is really my experience as well. I can't tell if it's down to a ZHA update or in my case the switch from a Conbee II Stick to a Skyconnect. In my case I have Hue RWL021, SML001 and some Aqara AQ2 motion sensors acting up recently. My routers are mainly Tuya TS011F wall plugs. Funny thing is, that I have some of these devices that are rock solid while others just refuse to work reliably no matter how many times I repair them. I also noticed that they don't seem to always get paired the same way. I have one AQ2 where it just has the entity "motion" while others have "Iaszone" as a motion entity.

To be fair I thought it was all my mistake, as the Conbee II to Skyconnect migration was quite the disaster. (It failed to repair the devices as the ZHA migration process didn't respect the previous Zigbee channel and just decided to change it. And when I used a manual Zigbee backup it switched up all my identical devices on the network. So switch RWL021 A was suddenly switch RWL021 B and so on. This was especially messy with all my TS011F wall plugs which I used for my Energy Monitoring. Basically wiped all my cost history for the past months. But I guess as we always do, bit the bullet and rebuilt it. =] )

I'm glad to find out though that there is some larger problem here. Since I didn't get some of the Hue devices working reliably on the Skyconnect I switched them to the Hue Bridge. They're a bit slower now... but they work. One of the AQ2 is killing me though. It's like tossing a coin if it works or not. I'm at the point where I start betting with myself if it's going to work so I know it's time to ditch them. Don't know if I can wait for the fix of this. LOL

I have the following threads atm.:

WiFi interference from neighbours on my Zigbee Channel 15 (Hue Bridge is on 25). To be fair: overall it's a mess as it's in a relatively dense city. I have for example one prick neighbour now having three access points on 2.4ghz all on the same channel with HE80. One can only imagine...
TS011F wall plug not acting as a decent router
Skyconnect having more problems with weaker clients compared to the Conbee II
ZHA quirks not fully developed or adapted for some devices
some or all of the factors above combined

I wouldn't say it was 100% reliable with the Conbee II, especially some HUE RWL021 acted up similarly. But it's worse now. That's for sure.

issue-triage-workflows[bot] commented 1 year ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

pschneider87 commented 1 year ago

I still have some Sensors that turn unavailable regularly and need to be repaired, to work for some hours or days. Not sure if others experiencing the same.

It's happening with all latest software updates

puddly commented 1 year ago

Author of the original issue is no longer using ZHA so there's no way to further debug.

@pschneider87 The issue with your Hue sensors is unrelated. Take a look at https://github.com/home-assistant/core/issues/89311#issuecomment-1565740967 for more info and for a potential fix.

home-assistant / core