Closed ErikSGross closed 1 year ago
probot-home-assistant[bot]
commented
2 years ago Hey there @dmulcahey, @adminiuga, @puddly, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
zha documentation zha source (message by IssueLinks)
puddly
commented
2 years ago As of Home Assistant 2022.08.x, that ConBee II firmware generates a ZHA error of
Writing network frame counter is not supported with this firmware, and none of my Zigbee devices respond to controls or send sensor updates. Thus a firmware update seems necessary.
This warning is only generated when a Conbee has no network settings and ZHA has to form a new network to start up, either by restoring from a backup (2022.8.2 or newer), or randomly generating settings (any earlier version). Updating the firmware on a Conbee does not touch its network settings.
Are you saying you have seen this warning multiple times? Can you enable https://www.home-assistant.io/integrations/zha/#debug-logging and post a log of it happening?
As for the missing IasZone:enroll command, can you upload the diagnostic info for your sensor as well?
ErikSGross
commented
2 years ago Thanks for the super-quick response!
As for the Writing network frame counter is not supported with this firmware warning, I think that's a red herring for the CS100 issue. I included that as an answer to the question, "why did you update the ConBee II firmware if everything was working?"
Essentially, I updated from 2022.07 to 2022.08.3 and all my Zigbee devices were unresponsive after multiple reboot/restarts. I saw the network frame counter warning in the logs and figured my really-old ConBee II firmware might be the cause. Unfortuately, I didn't save the logs, and I haven't seen the error since. If I see it again, I'll enable the debug output and post logs.
Regarding the CS100 sensor - I didn't catch that it wasn't included in the ZHA integration diagnostics. I'll attach them here.
zha-3f9c70374ed85700f78f4e321500b09f-TP-Link CS100-c74fbf1d349c4222b3179a0fbf83ca9c.json.txt
puddly
commented
2 years ago I think that's a red herring for the CS100 issue. I included that as an answer to the question
It probably is. However, you shouldn't be seeing it in the first place when using ZHA: your network should never be reset unless you wipe the stick externally, which is only possible with the Conbee if you use deCONZ and "leave" the current network, or factory reset from Phoscon. If you do manage to get this to happen again, I'd really appreciate a debug log, as it would indicate that somehow ZHA is either inappropriately reading the network settings from your Conbee and detecting a "no network" state where there is one, or is somehow erasing the network settings (very unlikely).
Regarding your door/window sensor: I don't have the exact model but I have a similar standards-compliant motion sensor. I've disabled ZHA's proactive IasZone:enroll_response so that ZHA waits for a device to contact it.
I'm able to join it to a Conbee running firmware 0x26780700 and ZHA correctly handles the device sending it a IasZone:enroll request:
2022-08-17 23:21:24.560 DEBUG (MainThread) [zigpy.zcl] [0x7EBB:5:0x0500] Received command 0x01 (TSN 0): enroll(zone_type=<ZoneType.Motion_Sensor: 13>, manufacturer_code=4403)
2022-08-17 23:21:24.561 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x7EBB:5:0x0500]: Enroll requested
2022-08-17 23:21:24.561 DEBUG (MainThread) [zigpy.zcl] [0x7EBB:5:0x0500] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False, *is_reply=False), tsn=78, command_id=0, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
2022-08-17 23:21:24.561 DEBUG (MainThread) [zigpy.zcl] [0x7EBB:5:0x0500] Sending request: enroll_response(enroll_response_code=<EnrollResponse.Success: 0>, zone_id=0)Similarly with firmware 0x26580700:
2022-08-17 23:36:42.939 DEBUG (MainThread) [zigpy.zcl] [0x81D3:5:0x0500] Received command 0x01 (TSN 0): enroll(zone_type=<ZoneType.Motion_Sensor: 13>, manufacturer_code=4403)
2022-08-17 23:36:42.941 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x81D3:5:0x0500]: Enroll requested
2022-08-17 23:36:42.941 DEBUG (MainThread) [zigpy.zcl] [0x81D3:5:0x0500] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False, *is_reply=False), tsn=76, command_id=0, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
2022-08-17 23:36:42.942 DEBUG (MainThread) [zigpy.zcl] [0x81D3:5:0x0500] Sending request: enroll_response(enroll_response_code=<EnrollResponse.Success: 0>, zone_id=0)Everything seems to be working as intended with both Conbee firmware versions. Both times I removed the ZHA integration, formed a brand new network on the Conbee, and then joined the device.
Could you upload both the working and not working ZHA/zigpy debug logs you captured earlier?
ErikSGross
commented
2 years ago Regarding the network reset: I wasn't doing anything special when that happened, just updating HA from 2022.07.7 to 2022.08.3. I have about 80 devices in the Zigbee network, with about 25 of them being mains-powered lights (repeaters). I didn't touch the ConBee II or mess with ZHA settings at all when upgrading HA. If I can reproduce the failure, I'll definitely grab some logs.
Regarding the CS100 sensor:
As another datapoint, I do have other door/window sensors in my prod system, and they all work fine with the latest (0x26780700) ConBee II firmware. Those sensors are from Samsung, CentraLite, and Linkind; all of which have functional IasZone entities.
The TP-Link CS100 sensors seem to be special in this regard. Maybe it's not fully compliant with the Zigbee spec? I find it really odd, though, that using an HA instance with ConBee II firmware > 0X26580700 seems to make HA not recognize the IasZone properly, even when reverting the Conbee II firmware back to a version that worked previously.
I'm attaching a passing (0x26580700) log and a failing (0x26650700) log from my dev HA instance that just has the ConBee II and a single CS100 sensor. The logs cover the scenario of starting HA with just the ConBee II, adding the CS100 sensor, opening/closing the sensor a few times, and then removing the sensor.
1 home-assistant - 2658 - pass.log 2 home-assistant - 2665 - fail.log
ErikSGross
commented
2 years ago See anything interesting in the logs that would indicate why the TP-Link sensors stopped working?
puddly
commented
2 years ago If you filter by zigpy.zcl, 0x4037|0x91F7, and Sending request|Sending reply|Decoded ZCL frame, you can see a high level view of what's being sent/received.
In both cases:
The coordinator's IEEE address is written to the cie_addr attribute of the IasZone cluster:
2022-08-17 16:16:17.032 DEBUG (MainThread) [zigpy.zcl] [0x91F7:1:0x0500] Sending request: Write_Attributes(attributes=[Attribute(attrid=0x0010, value=TypeValue(type=EUI64, value=00:21:2e:ff:ff:05:ce:14))])
2022-08-17 16:16:17.264 DEBUG (MainThread) [zigpy.zcl] [0x91F7:1:0x0500] Decoded ZCL frame: IasZone:Write_Attributes_rsp(status_records=[WriteAttributesStatusRecord(status=<Status.SUCCESS: 0>)])IasZone:enroll request in the failing case, ZHA just ends up sending its proactive IasZone:enroll response.Perhaps the device is confused by the proactive enroll response. Can you try disabling it and re-join the device? https://github.com/home-assistant/core/blob/0caf998547e84e229792a6fe29840dce31b30c06/homeassistant/components/zha/core/channels/security.py#L383-L384
ZHA should instead reply when the device sends an enroll request.
ErikSGross
commented
2 years ago I attempted to modify the HA code to skip the proacticve enroll response, and I never saw that part of the code get executed... so I don't think I actually tested the scenario you suggested.
Since my dev box was on 2022.08.3, I grabbed the 2022.08.3 version of the zha component, added it to the custom_components directory, commented out line 384 as suggested above, and then changed the debug message on 383 so that I'd know it acutally got executed. I never saw the debug message.
However, I did find something else interesting. After trying to pair the CS100 device a bunch of times with firmware 0x26650700, eventually it worked correctly. Or at least I get a reasonable report of battery level and the IASZone seems to work properly. I tried removing and re-pairing the same device a few more times, and sometimes it worked and sometimes it didn't. The single AA battery was at 83% (1.39V vs nominal 1.50V), and I also tried with a brand new (1.61V) battery with the same results. I also tried a few other CS100 sensors and saw the same behavior, both when adopting via the Zigbee coordinator and when adopting via a router out on the mesh. So apparently, it's not that the device won't pair at all with the new HA and new FW, it's that something is making it pair very unreliably.
In the logs where the device did not pair successfully, I saw something like:
[zigpy.application] Received frame on uninitialized device <Device model=None manuf=None nwk=0x5F6B ieee=00:12:4b:00:07:fc:cf:a5 is_initialized=False> from ep 1 to ep 1, cluster 1280: b'\t\x01\x00!\x00\x00\x00\x00\x00'
[zigpy.device] [0x5f6b] Received ZCL while uninitialized on endpoint id 1, cluster 0x0500 id, hdr: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False, *is_reply=True), tsn=1, command_id=0, *direction=<Direction.Client_to_Server: 1>, *is_reply=True), payload: b'!\x00\x00\x00\x00\x00'and this was not present in the case where the device paired successfully.
Then, a little further down in the log, I see:
[zigpy.zcl] [0x5F6B:1:0x0001] Received ZCL frame: b'\x08\x02\n!\x00 \xa6'
[zigpy.zcl] [0x5F6B:1:0x0001] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=2, command_id=10, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0x5F6B:1:0x0001] Decoded ZCL frame: PowerConfiguration:Report_Attributes(attribute_reports=[Attribute(attrid=0x0021, value=TypeValue(type=uint8_t, value=166))])
[zigpy.zcl] [0x5F6B:1:0x0001] Received command 0x0A (TSN 2): Report_Attributes(attribute_reports=[Attribute(attrid=0x0021, value=TypeValue(type=uint8_t, value=166))])
[zigpy.zcl] [0x5F6B:1:0x0001] Attribute report received: battery_percentage_remaining=166
[zigpy.zcl] [0x5F6B:1:0x0001] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=2, command_id=<GeneralCommand.Default_Response: 11>, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0x5F6B:1:0x0001] Sending reply: Default_Response(command_id=10, status=<Status.SUCCESS: 0>)and again, this is not present in the passing case. The lines indicating the PowerConfiguration:Report_Attributes appear in the same general location in the log as the enroll entries in the passing case, which look like this:
[zigpy.zcl] [0x03C7:1:0x0500] Received ZCL frame: b'\t\x01\x01\x15\x00\x88\x11'
[zigpy.zcl] [0x03C7:1:0x0500] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False, *is_reply=True), tsn=1, command_id=1, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0x03C7:1:0x0500] Decoded ZCL frame: IasZone:enroll(zone_type=<ZoneType.Contact_Switch: 21>, manufacturer_code=4488)
[zigpy.zcl] [0x03C7:1:0x0500] Received command 0x01 (TSN 1): enroll(zone_type=<ZoneType.Contact_Switch: 21>, manufacturer_code=4488)At this point, after [re]trying to pair the devices many times, I eventually got all 5 of them to pair, and they've been operational for about 24h.
I'm not sure how many folks are using these sensors with HA, as I believe they've been discontinued by TP-Link for a while now. From an intellectual perspective, I'd love to know what's going on in the failing case and get them to pair reliably. However, I also know there are lots of bugs/features that need attention as well. If few others chime in that they are having issues and mine are still working properly after a week or so, there might be low ROI on pursuing this one... unless you think the root cause could affect more than just these sensors.
ErikSGross
commented
2 years ago Also, what is the second number (after the NetworkID) in the log messages?
e.g. 0x0500 in [0x03C7:1:0x0500]
ErikSGross
commented
2 years ago After staring at the logs a little more (still a Zigbee n00b), the passing case shows the first ZCL lines as:
[zigpy.zcl] [0xNWKID:1:0x0000] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=False), tsn=XX, command_id=<GeneralCommand.Read_Attributes: 0>, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
[zigpy.zcl] [0xNWKID:1:0x0000] Sending request: Read_Attributes(attribute_ids=[4, 5])
[zigpy.zcl] [0xNWKID:1:0x0500] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False, *is_reply=True), tsn=XX, command_id=1, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0xNWKID:1:0x0500] Decoded ZCL frame: IasZone:enroll(zone_type=<ZoneType.Contact_Switch: 21>, manufacturer_code=4488)
[zigpy.zcl] [0xNWKID:1:0x0000] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=XX, command_id=1, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0xNWKID:1:0x0000] Decoded ZCL frame: Basic:Read_Attributes_rsp(status_records=[ReadAttributeRecord(attrid=0x0004, status=<Status.SUCCESS: 0>, value=TypeValue(type=CharacterString, value='TP-Link')), ReadAttributeRecord(attrid=0x0005, status=<Status.SUCCESS: 0>, value=TypeValue(type=CharacterString, value='CS100'))])Am correct that the coordinator is sending a request to read attributes 4 and 5 from the device and then the device is sending a IasZone:enroll response back along with a Basic:Read_Attributes_rsp that has the data for both attribute IDs? It looks like Atrribute 4 is the manufacturer and Attribute 5 is the model, so that seems to make sense. I'm not sure if the enroll response timing is related to the request to read attributes, but they seem to appear together in the logs.
Then in the failing case, we see:
[zigpy.zcl] [0xNWKID:1:0x0000] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=False), tsn=XX, command_id=<GeneralCommand.Read_Attributes: 0>, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
[zigpy.zcl] [0xNWKID:1:0x0000] Sending request: Read_Attributes(attribute_ids=[4, 5])
[zigpy.zcl] [0xNWKID:1:0x0001] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=XX, command_id=10, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0xNWKID:1:0x0001] Decoded ZCL frame: PowerConfiguration:Report_Attributes(attribute_reports=[Attribute(attrid=0x0021, value=TypeValue(type=uint8_t, value=166))])
[zigpy.zcl] [0xNWKID:1:0x0001] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=XX, command_id=<GeneralCommand.Default_Response: 11>, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0xNWKID:1:0x0001] Sending reply: Default_Response(command_id=10, status=<Status.SUCCESS: 0>)
[zigpy.zcl] [0xNWKID:1:0x0000] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=XX, command_id=1, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
[zigpy.zcl] [0xNWKID:1:0x0000] Decoded ZCL frame: Basic:Read_Attributes_rsp(status_records=[ReadAttributeRecord(attrid=0x0004, status=<Status.SUCCESS: 0>, value=TypeValue(type=CharacterString, value='TP-Link')), ReadAttributeRecord(attrid=0x0005, status=<Status.SUCCESS: 0>, value=TypeValue(type=CharacterString, value='CS100'))])Note that the first 2 and last 2 lines of the passing/failing cases are identical.
The lines between the GeneralCommand.Read_Attributes request at the top and the Basic:Read_Attributes_rsp lines at the bottom are interpreted as PowerConfiguration:Report_Attributes instead of IasZone:enroll. I'm not sure if it's a coincidence, but the 0x21 value that seems to indicate a Contact Switch zone type in the passing case is also the attrib_id value associated with the PowerConfiguration:Report_Attributes response in the failing case. Further, the value associated with the battery percentage returned by the PowerConfiguration:Report_Attributes response in the failing case is reported as 106% by Home Assistant, so that seems suspicious as well.
I haven't dug into the specs enough to manually decode Zigbee frames, but this seems like either ZHA is incorrectly decoding the enroll response frame or the device is sending a corrupted frame to ZHA, which can't interpret it. Is there a good manual frame decoder tool that could shed some light on this?
The raw frame lines above the responses are:
[zigpy_deconz.uart] Frame received: 0x17970025001e002202fdff0102c703010401000507000901011500881100afff00000000d6
[zigpy_deconz.api] APS data indication response: [30, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0xfffd>, 1, <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0x03c7>, 1, 260, 1280, b'\t\x01\x01\x15\x00\x88\x11', 0, 175, 255, 0, 0, 0, 0, -42]in the passing case and
[zigpy_deconz.uart] Frame received: 0x17490025001e002202000001026b5f0104010100070008020a210020a600afff00000000c3
[zigpy_deconz.api] APS data indication response: [30, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0x0000>, 1, <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0x5f6b>, 1, 260, 1, b'\x08\x02\n!\x00 \xa6', 0, 175, 255, 0, 0, 0, 0, -61]in the failing case if that's helpful.
puddly
commented
2 years ago Also, what is the second number (after the NetworkID) in the log messages?
It's formatted as [device_nwk:endpoint_id:cluster_id].
Am correct that the coordinator is sending a request to read attributes 4 and 5 from the device and then the device is sending a
IasZone:enrollresponse back along with aBasic:Read_Attributes_rspthat has the data for both attribute IDs?
Correct. The two being interleaved is probably coincidence though.
Further, the value associated with the battery percentage returned by the
PowerConfiguration:Report_Attributesresponse in the failing case is reported as 106% by Home Assistant, so that seems suspicious as well.
The raw battery readings should be between 0-200 (they're reported as half-integer percentages). The raw value of 166 should be displayed as 83%. For HA to show 106%, the device would need to have reported 212, which isn't right.
this seems like either ZHA is incorrectly decoding the enroll response frame or the device is sending a corrupted frame to ZHA, which can't interpret it.
The ZCL decoding code within zigpy is solid and well-tested, I wouldn't expect it to have problems like this.
If you're really curious to see what's going on, I suggest you buy a $10 nRF52840 stick or a Silicon Labs EFR32 Zigbee coordinator, both of which can sniff Zigbee traffic via Wireshark. Wireshark has its own independent ZCL dissector.
ErikSGross
commented
2 years ago It's been almost 3 weeks since I was able to get my sensors back into my ZHA mesh by repeatedly trying to add them until they succeed. All of those sensors are still working - i.e. IASZone sensor working, battery level reported
I've updated to 2022.09.4, and I'm still seeing the (already added) sensors operating properly.
Given that nobody else has chimed in that their CS100 sensors are having this issue and I've been able to get mine functional again with a workaround (multiple pairing attempts until success), I'm good with closing this issue as won't be fixed.
If the problem increases in severity or many others start reporting the problem, we can revisit it.
github-actions[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.
The problem
With a ConBee II Zigbee stick and firmware
0x264a0700, my TP-Link CS100 Door/Window sensors have operated properly for over a year.As of Home Assistant 2022.08.x, that ConBee II firmware generates a ZHA error of
Writing network frame counter is not supported with this firmware, and none of my Zigbee devices respond to controls or send sensor updates. Thus a firmware update seems necessary.I updated my ConBee II to firmware
0x26780700(and had to rebuild my Zigbee network), and now all my devices EXCEPT the CS100 devices work properly. The CS100 devices should have IasZone and Battery entities. The entities are present after adoption, but the IasZone sensor never updates its value.I've tried multiple CS100 devices as well as adding/removing them multiple times. I've tried on an Intel NUC running HAOS, and I've tried on a Home Assistant Blue with the same results.
After some further debugging to narrow down the reproduction steps, I've found: on a fresh build of HA 2022.08.5, I've found that ConBee II firmware up to (and including)
0x26580700allows the CS100 to work properly (IasZone updates as sensor opened/closed). Using firmware0x26650700or later results in the IasZone not working.The reason I'm filing a ZHA issue: once a Home Assistant instance has been used with a firmware of
0x26650700or later, changing the ConBee II firmware back to an earlier version does not allow the CS100's IasZone sensors to work properly. The only way I've found to get the sensors to work again is to reimage the Home Assistant host or restore from a Home Assistant backup that has never used a ConBee II with a firmware of0x26650700or later.What version of Home Assistant Core has the issue?
core-2022.8.5
What was the last working version of Home Assistant Core?
No response
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
Example YAML snippet
PASSing case: