home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.28k stars 30.6k forks source link

Yale YRD226/246 TSDB zigbee lock inoperable after HA restart. #36824

Closed tlewsey closed 4 years ago

tlewsey commented 4 years ago

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:

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:

Other options considered:

probot-home-assistant[bot] commented 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)

Adminiuga commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tlewsey commented 4 years ago

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

Adminiuga commented 4 years ago

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

Adminiuga commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tlewsey commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tlewsey commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

Fixed in HA 0.115.4