TP-Link CS100 Door-Window Sensor Fails to Register IasZone Properly #76962
Comments
|
Hey there @dmulcahey, @Adminiuga, @puddly, mind taking a look at this issue as it has been labeled with an integration ( zha documentation |
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 |
|
Thanks for the super-quick response! As for the Essentially, I updated from 2022.07 to 2022.08.3 and all my Zigbee devices were unresponsive after multiple reboot/restarts. I saw the 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 |
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 I'm able to join it to a Conbee running firmware 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 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? |
|
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 ( 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 > I'm attaching a passing ( 1 home-assistant - 2658 - pass.log |
|
See anything interesting in the logs that would indicate why the TP-Link sensors stopped working? |
|
If you filter by In both cases:
Perhaps the device is confused by the proactive enroll response. Can you try disabling it and re-join the device? core/homeassistant/components/zha/core/channels/security.py Lines 383 to 384 in 0caf998 ZHA should instead reply when the device sends an enroll request. |
|
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 However, I did find something else interesting. After trying to pair the CS100 device a bunch of times with firmware In the logs where the device did not pair successfully, I saw something like: and this was not present in the case where the device paired successfully. Then, a little further down in the log, I see: and again, this is not present in the passing case. The lines indicating the 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. |
|
Also, what is the second number (after the NetworkID) in the log messages? e.g. |
|
After staring at the logs a little more (still a Zigbee n00b), the passing case shows the first ZCL lines as: Am correct that the coordinator is sending a request to read attributes Then in the failing case, we see: Note that the first 2 and last 2 lines of the passing/failing cases are identical. The lines between the I haven't dug into the specs enough to manually decode Zigbee frames, but this seems like either ZHA is incorrectly decoding the The raw frame lines above the responses are: in the passing case and in the failing case if that's helpful. |
It's formatted as
Correct. The two being interleaved is probably coincidence though.
The raw battery readings should be between 0-200 (they're reported as half-integer percentages). The raw value of
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. |
|
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. |
|
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. |
issue-triage-workflows
bot
closed this as not planned
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:
The text was updated successfully, but these errors were encountered: