Closed tlewsey closed 4 years ago
Hey there @dmulcahey, @adminiuga, mind taking a look at this issue as its been labeled with a integration (zha
) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)
The error is being reported by the ConBee I don't know if much could be done here. Try updating the conBee firmware, as in the latest there were supposed to be some improvements in handling the errors in routing.
Thanks. For some reason the Phoscon app is showing "The version is up to date" (v2.5.75 246A0700) but if I look at the changelog it's two versions behind. I guess I'll try on a different machine
I manually updated the Conbee II to 26580700 but unfortunately no change. In terms of routing I have no other devices connected to the Conbee (other than a recently added battery operated xiaomi door sensor).
I've just re-found #31820 which describes my issue exactly but @thimic's solution only fixes my problem until the next reboot.
What is the part number of the Zigbee module installed in the lock?
There are a bunch of stickers on it but I think the important ones are YRMZB2 and AYR202-ZB-HA V261
That's looks fine, just wanted to make sure it is not a C4 variation
I can confirm your findings. After a restart, the lock does send attribute reports successfully, yet any command sent to the lock fails with MAC_NO_ACK/0xE9
TX status. What is strange, the error comes in almost immediately after the request, while I'd expect there to be some delay, as the lock is a battery powered device so it is polling its parent device (ConBee) on a regular intervals, but not immediatly. In HA1.2 parent devices are supposed to held messages for their children for about 7s and this is not what's happening here. Almost like ConBee doeesn't know it's a child device.
But after you power-cycle the lock, there's almost 5s between the request being sent out and a TXConfirm to come in, which is more inline with a battery operated device
2020-06-11 14:23:15 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_request (18, 29, 0, <DeconzAddressEndpoint address_mode=2 address=0x0bb7 endpoint=1>, 260, 257, 1, b'\x01\x1c\x00', 2, 0)
...
2020-06-11 14:23:20 DEBUG (MainThread) [zigpy_deconz.uart] Frame received: 0x04560013000c00221d02b70b01010000000000
2020-06-11 14:23:20 DEBUG (MainThread) [zigpy_deconz.api] APS data confirm response for request with id 29: 00
2020-06-11 14:23:20 DEBUG (MainThread) [zigpy_deconz.api] Request id: 0x1d 'aps_data_confirm' for <DeconzAddressEndpoint address_mode=ADDRESS_MODE.NWK address=0x0bb7 endpoint=1>, status: 0x00
can you try a few things for me:
zha_map.scan_now
/config/neighbours
folder, post this file here. I'd like to see if ConBee reports its child devices2) after a restart, try calling lock.unlock
service on your lock a few times in successions, eg 5 times with 1s delays between the service calls
3) can you try a get another mains powered device to act as a Zigbee router and join the lock through that device?
Just chiming in that I’m still experiencing this issue too. Not on every single restart, but the great majority of the time. I also always have the lock report its status correctly, but can’t control it when this occurs.
My workaround is also to take one battery out, wait a few seconds and put it back in. After that, the lock comes back up fine and can be controlled again - no re-pair necessary.
I had it working reliably before upgrading from 0.103.x to 0.104.x but as discussed before, there doesn’t seem to have been an update to the ZHA component between those releases.
@thimic use the same troubleshoot ing steps. Particularly withzha_map confirm which device is the parent device for the lock.l
Neighbour file after HA reboot (lock not working): neighbours_00212effff054d8d - after HA reboot.txt
Neighbour file after lock reboot (lock working): neighbours_00212effff054d8d - after lock reboot.txt
Log after HA reboot and 5x fast service calls: zha-zigpy-ha-log2.log
I have a Xiaomi zigbee smart plug I will add close to the lock and try and re-pair later today.
Thanks for your help.
@thimic I'm not sure if I'm happy or sad you still have the same problem :)
Neighbour file after HA reboot (lock not working):
{
"device_type": "unk",
"ieee": "00:21:2e:ff:ff:04:f5:26",
"lqi": null,
"manufacturer": "dresden elektronik",
"model": "ConBee II",
"neighbours": [],
"nwk": "0x0000",
"offline": false
}
Neighbour file after lock reboot (lock working):
{
"device_type": "unk",
"ieee": "00:21:2e:ff:ff:04:f5:26",
"lqi": null,
"manufacturer": "dresden elektronik",
"model": "ConBee II",
"neighbours": [
{
"depth": 1,
"device_type": "End_Device",
"ieee": "00:0d:6f:00:11:27:ad:24",
"lqi": 252,
"manufacturer": "Yale",
"model": "YRL226 TS",
"new_joins_accepted": "Not_Accepting",
"nwk": "0x4c0f",
"offline": false,
"pan_id": "00:21:2e:ff:ff:04:f5:26",
"relation": "Child",
"rx_on_when_idle": "Off",
"supported": true
}
],
"nwk": "0x0000",
"offline": false
}
Log after HA reboot and 5x fast service calls:
2020-06-22 23:10:47 ERROR (MainThread) [homeassistant.components.zha.entity] lock.yale_yrl226_ts_24ad2711_door_lock: Error with unlock_door: [0x4c0f:1:0x0101]: Message send failure
2020-06-22 23:10:49 ERROR (MainThread) [homeassistant.components.zha.entity] lock.yale_yrl226_ts_24ad2711_door_lock: Error with unlock_door: [0x4c0f:1:0x0101]: Message send failure
2020-06-22 23:10:50 ERROR (MainThread) [homeassistant.components.zha.entity] lock.yale_yrl226_ts_24ad2711_door_lock: Error with unlock_door: [0x4c0f:1:0x0101]: Message send failure
2020-06-22 23:10:51 ERROR (MainThread) [homeassistant.components.zha.entity] lock.yale_yrl226_ts_24ad2711_door_lock: Error with unlock_door: [0x4c0f:1:0x0101]: Message send failure
2020-06-22 23:10:58 ERROR (MainThread) [homeassistant.components.zha.entity] lock.yale_yrl226_ts_24ad2711_door_lock: Error with unlock_door: [0x4c0f:1:0x0101]: Message send failure
Huh, so it does loose its child device for some reason. Lemme see if I can reproduce it. This is surprising, as parent devices are supposed to keep their childs even through power cycles. As a work around, you need to get a Zigbee router on your network and join lock through that router. Ikea signal repeater should work.
I'll try to ping Manuel from dresden, but he's quite busy so won't expect a quick reply.
I can't reproduce the issue with ConBee I and Centralite thermostat, if I just restart the Home Assistant Core. But if I powercycle the ConBee, then it looses it child device.
Thanks for looking into it @Adminiuga. I live in New Zealand where we don’t have IKEA quite yet (it’s coming), but I might have a look for other router options.
I fiddled around a bit today but wasn't able to get the lock to pair with my Xiaomi smart plug. It was showing as a 'sibling' to the Conbee but no luck with the ZHA>Plug>'Add Device' option.
@thimic if it comes to it and the ikea repeater is the only workaround I can send you one from across the ditch :)
get the lock to pair with my Xiaomi smart plug
Yeah, with xiaomi you never know if it is xiaomi or the code :) if you enable debug, when you do ZHA -> Plug -> Add device
you should see a ZDO request going out to the device and device should respond with a success.
did some more testing, it appears deCONZ is using some undocumented command. Would need to hear from dresden on how to use it though. Had the centralite thermostat connected to ConBee staying all night and it still did not appear back in the neighbour table. However after joining a router, at some point centralite switched its parent from ConBee to router and as soon as ConBee discovers the router, it can communicate just fine with the Thermostat
Had another go at pairing via the Xiaomi plug and super happy to report the lock now survives reboots! Thanks @Adminiuga you have made my day.
That’s good news @tlewsey! I’ll check this weekend if I can find a device in NZ that can act as a router.
Edit: I had trouble finding any wired Zigbee accessories in NZ that aren't lights. I already have all the lights I need, so ended up ordering a Xiaomi plug from AliExpress. Might take a while for it to arrive. I'll post when it does.
The Xiaomi plug finally arrived. Pairing the lock via the plug seems to solve the issue for me too.
@thimic have you upgraded to 0.113 yet? I did and seem to be having issues again. Haven't had time to diagnose or re-pair though
@tlewsey I think I was running 0.113.1 when I installed the Xiaomi plug. I since updated to 0.113.2 and did a few more restarts while remaining connected. So so far so good here.
Updating to 0.113.3 now. I'll update here when done.
Edit: Still works after updating to 0.113.3.
Fixed in HA 0.115.4
The problem
My Yale YRD226 door lock (integrated via ZHA) becomes uncontrollable after a HA restart. Lock status continues to report correctly when manually operated in this state, however lock/unlock commands result in "message send failure" in logs. The only fix is to take a battery out the lock for a few seconds and reinstall. The lock seems to re-initialise with ZHA and is happy until the next restart.
I got this lock about 6 weeks ago and have never had it working fully. It has taken me this long to reliably reproduce the problem and exhaust my knowledge and google searching abilities.
Environment
Hass.io on RPi3+ with Conbee II stick arch armv7l chassis embedded dev false docker true docker_version 19.03.8 hassio true host_os HassOS 4.10 installation_type Home Assistant os_name Linux os_version 4.19.126-v7 python_version 3.7.7 supervisor 227 version 0.111.1 virtualenv false
Problem-relevant
configuration.yaml
Configured entirely through integrations page
Traceback/Error logs
Increased logging in configuration.yaml as per below:
Attached log is filtered for zigpy and zha zha-zigpy-ha-log.log
Log shows
Additional information
In my countless hours of debugging I have:
Other options considered: