Core: Yale YRD226/246 TSDB zigbee lock inoperable after HA restart.

[tlewsey]

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

• Home Assistant Core release with the issue: 0.111.1
• Last working Home Assistant Core release (if known): Never
• Operating environment (Home Assistant/Supervised/Docker/venv): Home Assistant
• Integration causing this issue: ZHA
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/zha/

Problem-relevant configuration.yaml

Configured entirely through integrations page

Traceback/Error logs

Increased logging in configuration.yaml as per below:

logger:
  default: info
  logs:
    asyncio: debug
    homeassistant.components.zha: debug
    zigpy: debug
    bellows.zigbee.application: debug
    bellows.ezsp: debug
    zigpy_xbee.zigbee.application: debug
    zigpy_xbee.api: debug
    zigpy_deconz.zigbee.application: debug
    zigpy_deconz.api: debug
    zigpy_zigate: debug

Attached log is filtered for zigpy and zha
zha-zigpy-ha-log.log

Log shows

1. Startup from reboot
2. Attempt to operate lock (Message send failure)
3. Lock reboot (via removing battery)
4. Attempt to operate lock (succeed)

Additional information

In my countless hours of debugging I have:

• Tried the Conbee II with and without USB extension cables but same result. I even got a second extension cable to rule out an issue with the first.
• Tried using both the fulldevice name "/dev/serial/by-id/usb..." and the standard "/dev/ttyACM0" but same result.
• Changed zigbee channels and ensured not overlap with Wifi. I have even tried with 2.4GHz Wifi completely disabled.
• Uninstalled and reinstalled ZHA mulitple times.
• Re-paired the lock multiple times.
• Changed lock batteries for new ones.
• Moved the RPi and Conbee 2 within a few metres of the lock
• I had a few Xiaomi Door Sensors and Motion sensors also paired so have removed all of them to confirm that is not causing the problem. (Note logs show I have re-added one back)

Other options considered:

• Powered USB hub for the conbee, however I don't own one and this does not seem to be a needed based on other users experiences. I also have the official RPi PSU and no other USB loads.
• I use bluetooth and 5GHz wifi on the RPi so could try disabling those but this does not seem to be related to signal strength.

[probot-home-assistant[bot]]

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)}}

[Adminiuga]

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.

[tlewsey]

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

[tlewsey]

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.

[Adminiuga]

What is the part number of the Zigbee module installed in the lock?

[tlewsey]

There are a bunch of stickers on it but I think the important ones are
YRMZB2 and AYR202-ZB-HA V261

[Adminiuga]

That's looks fine, just wanted to make sure it is not a C4 variation

[Adminiuga]

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:

1. Install https://github.com/zha-ng/zha-map (available on HACS) (no need for the card, just the custom component)
2. after HA restart, call service zha_map.scan_now
3. you should get one neighbour file in /config/neighbours folder, post this file here. I'd like to see if ConBee reports its child devices

2) 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?

[thimic]

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.

[Adminiuga]

@thimic use the same troubleshoot ing steps. Particularly withzha_map confirm which device is the parent device for the lock.l

[tlewsey]

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 :)

[thimic]

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

[Adminiuga]

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.

[Adminiuga]

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.

[thimic]

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.

[tlewsey]

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 :)

[Adminiuga]

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.

[Adminiuga]

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

[tlewsey]

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.

[thimic]

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.

[thimic]

The Xiaomi plug finally arrived. Pairing the lock via the plug seems to solve the issue for me too.

[tlewsey]

@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

[thimic]

@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.

[Adminiuga]

Fixed in HA 0.115.4