Danalock V3 (New FW 0.20.0) Losing Connection

Describe the bug

I bought a Danalock V3 and integrated it into my Deconz system.
After a while the lock will always lose connection to the Zigbee Network and does not do anything anymore. I can neither send commands to it, Nor read clusters. This seems to happen after sending the open or close command. If the lock is just left unattended and only used for reading the clusters, the bug is not triggered.
After rebooting the lock it will work again.

Steps to reproduce the behavior

1.) Connect lock to network using click commands.
2.) Open / Close the lock multiple times

Expected behavior

The lock will always open / close (perhaps with some delay).

Screenshots


Environment

  • Host system: x86 PC
  • Running method: Assistent deCONZ Add-on
  • Firmware version: (26720700)
  • deCONZ version: (2.14.1)
  • Device: ConBee II
  • Do you use an USB extension cable: yes
  • Is there any other USB or serial devices connected to the host system? A serial adapter.

deCONZ Logs

15:52:57:149 read attributes of 0x00158D0000F2471C cluster: 0x0006: [ 15:52:57:149 0x0000 15:52:57:149 ]
15:52:57:150 add task 3810383 type 19 to 0x00158D0000F2471C cluster 0x0006 req.id 124
15:52:57:150 Poll APS request 124 to 0x00158D0000F2471C cluster: 0x0006
15:52:57:170 Poll APS confirm 124 status: 0x00
15:52:57:170 Erase task req-id: 124, type: 19 zcl seqno: 231 send time 0, profileId: 0x0104, clusterId: 0x0006
15:52:57:261 Node data 0x00158d0000f2471c profileId: 0x0104, clusterId: 0x0006
15:52:57:261 0x00158D0000F2471C: update ZCL value 0x01/0x0006/0x0000 after 0 s
15:52:57:263 Websocket 172.30.32.1:48864 send message: {"attr":{"colorcapabilities":31,"ctmax":1000,"ctmin":100,"id":"50","lastannounced":"2022-04-05T07:16:37Z","lastseen":"2022-04-10T13:52Z","manufacturername":"innr","modelid":"FL 120 C","name":"Living Room LED-Strip Sofa","swversion":"0x28002162","type":"Extended color light","uniqueid":"00:15:8d:00:00:f2:47:1c-01"},"e":"changed","id":"50","r":"lights","t":"event","uniqueid":"00:15:8d:00:00:f2:47:1c-01"} (ret = 405)
15:52:57:752 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x9922
15:52:57:960 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0
15:52:58:208 Door lock debug 0x50325FFFFECFBE4C, data 0x00000001 
15:52:58:213 Door lock debug 0x50325FFFFECFBE4C, data 0x00000001 
15:52:58:262 poll node 0c:43:14:ff:fe:6a:a1:02-01
15:52:58:263 Poll light node Kitchen Window Cover
15:52:58:460 Idle timer triggered
15:52:58:461 binding for attribute reporting SensorNode Motion Sensor Garage of cluster 0x0406 seems to be active
15:52:58:461 Force read attributes for ZHAPresence SensorNode Motion Sensor Garage
15:52:58:461 binding for attribute reporting of ep: 0x02 cluster 0x0000 seems to be active
15:52:58:461 binding for attribute reporting of ep: 0x02 cluster 0x0406 seems to be active
15:52:58:462 Force binding of attribute reporting for node Motion Sensor Garage
15:52:58:575 read attributes of 0x0C4314FFFE6AA102 cluster: 0x0102: [ 15:52:58:575 0x0008 15:52:58:575 ]
15:52:58:575 add task 3810390 type 19 to 0x0C4314FFFE6AA102 cluster 0x0102 req.id 142
15:52:58:576 Poll APS request 142 to 0x0C4314FFFE6AA102 cluster: 0x0102
15:52:58:597 Poll APS confirm 142 status: 0x00
15:52:58:597 Erase task req-id: 142, type: 19 zcl seqno: 232 send time 0, profileId: 0x0104, clusterId: 0x0102
15:52:58:655 Node data 0x0c4314fffe6aa102 profileId: 0x0104, clusterId: 0x0102
15:52:58:655 0x0C4314FFFE6AA102: update ZCL value 0x01/0x0102/0x0008 after 0 s
15:52:58:665 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"31","lastannounced":"2021-11-01T06:21:32Z","lastseen":"2022-04-10T13:52Z","manufacturername":"_TZ3000_vd43bbfq","modelid":"TS130F","name":"Kitchen Window Cover","productid":"QS-Zigbee-C01 Module","swversion":"0x00000040","type":"Window covering device","uniqueid":"0c:43:14:ff:fe:6a:a1:02-01"},"e":"changed","id":"31","r":"lights","t":"event","uniqueid":"0c:43:14:ff:fe:6a:a1:02-01"} (ret = 398)
15:52:59:252 poll node cc:86:ec:ff:fe:ba:aa:d2-01
15:52:59:253 Poll light node Office Window Cover
15:52:59:547 read attributes of 0xCC86ECFFFEBAAAD2 cluster: 0x0102: [ 15:52:59:547 0x0008 15:52:59:548 ]
15:52:59:548 add task 3810395 type 19 to 0xCC86ECFFFEBAAAD2 cluster 0x0102 req.id 154
15:52:59:548 Poll APS request 154 to 0xCC86ECFFFEBAAAD2 cluster: 0x0102
15:52:59:600 Poll APS confirm 154 status: 0x00
15:52:59:600 Erase task req-id: 154, type: 19 zcl seqno: 234 send time 0, profileId: 0x0104, clusterId: 0x0102
15:52:59:675 Node data 0xcc86ecfffebaaad2 profileId: 0x0104, clusterId: 0x0102
15:52:59:676 0xCC86ECFFFEBAAAD2: update ZCL value 0x01/0x0102/0x0008 after 0 s
15:52:59:678 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"28","lastannounced":"2022-03-30T12:55:20Z","lastseen":"2022-04-10T13:52Z","manufacturername":"_TZ3000_vd43bbfq","modelid":"TS130F","name":"Office Window Cover","productid":"QS-Zigbee-C01 Module","swversion":"0x00000040","type":"Window covering device","uniqueid":"cc:86:ec:ff:fe:ba:aa:d2-01"},"e":"changed","id":"28","r":"lights","t":"event","uniqueid":"cc:86:ec:ff:fe:ba:aa:d2-01"} (ret = 397)
15:52:59:726 Door lock debug 0x50325FFFFECFBE4C, data 0x00000001 
15:52:59:825 Door lock debug 0x50325FFFFECFBE4C, data 0x00000001 
15:53:00:047 Websocket 172.30.32.1:48864 send message: {"e":"changed","id":"61","r":"lights","state":{"alert":"none","on":false,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:8a:36:f2-01"} (ret = 143)
15:53:00:048 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"65","lastannounced":null,"lastseen":"2022-04-10T13:53Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Power 65","swversion":"09-06-2019","type":"ZHAPower","uniqueid":"04:cf:8c:df:3c:8a:36:f2-15-000c"},"e":"changed","id":"65","r":"sensors","t":"event","uniqueid":"04:cf:8c:df:3c:8a:36:f2-15-000c"} (ret = 328)
15:53:00:049 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"66","lastannounced":null,"lastseen":"2022-04-10T13:53Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Consumption 66","swversion":"09-06-2019","type":"ZHAConsumption","uniqueid":"04:cf:8c:df:3c:8a:36:f2-16-000c"},"e":"changed","id":"66","r":"sensors","t":"event","uniqueid":"04:cf:8c:df:3c:8a:36:f2-16-000c"} (ret = 340)
15:53:00:128 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 9, node: 0x977A
15:53:00:172 Websocket 172.30.32.1:48864 send message: {"e":"changed","id":"65","r":"sensors","state":{"current":0,"lastupdated":"2022-04-10T13:53:00.171","power":0,"voltage":216},"t":"event","uniqueid":"04:cf:8c:df:3c:8a:36:f2-15-000c"} (ret = 182)
15:53:00:175 poll node 80:4b:50:ff:fe:b7:27:ce-01
15:53:00:175 Poll light node Socket Bedroom Window Wall
15:53:00:222 Poll APS request to 0x804B50FFFEB727CE cluster: 0x0006 dropped, values are fresh enough
15:53:00:460 Skip idle timer callback, too early: elapsed 912 msec
15:53:01:117 poll node 00:15:8d:00:05:9f:f7:95-01
15:53:01:118 Poll light node Bathroom Upstairs Light
15:53:01:166 read attributes of 0x00158D00059FF795 cluster: 0x0006: [ 15:53:01:166 0x0000 15:53:01:167 ]
15:53:01:167 add task 3810402 type 19 to 0x00158D00059FF795 cluster 0x0006 req.id 182
15:53:01:167 Poll APS request 182 to 0x00158D00059FF795 cluster: 0x0006
15:53:01:176 skip create link for 0xA966 (lqi: 0) - 0x9737 (lqi: 0)
15:53:01:228 0x00158D00059FF7A5: update ZCL value 0x01/0x0019/0x1000 after 0 s
15:53:01:271 Poll APS confirm 182 status: 0x00
15:53:01:272 Erase task req-id: 182, type: 19 zcl seqno: 240 send time 0, profileId: 0x0104, clusterId: 0x0006
15:53:01:312 Door lock debug 0x50325FFFFECFBE4C, data 0x00000001 
15:53:02:014 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"72","lastannounced":"2022-04-01T22:37:20Z","lastseen":"2022-04-10T13:52Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Hallway Display Socket","swversion":"09-06-2019","type":"Smart plug","uniqueid":"04:cf:8c:df:3c:8a:39:91-01"},"e":"changed","id":"72","r":"lights","t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-01"} (ret = 351)
15:53:02:015 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"134","lastannounced":"2022-04-01T22:37:20Z","lastseen":"2022-04-10T13:52Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Power 134","swversion":"09-06-2019","type":"ZHAPower","uniqueid":"04:cf:8c:df:3c:8a:39:91-15-000c"},"e":"changed","id":"134","r":"sensors","t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-15-000c"} (ret = 349)
15:53:02:016 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"135","lastannounced":"2022-04-01T22:37:20Z","lastseen":"2022-04-10T13:52Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Consumption 135","swversion":"09-06-2019","type":"ZHAConsumption","uniqueid":"04:cf:8c:df:3c:8a:39:91-16-000c"},"e":"changed","id":"135","r":"sensors","t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-16-000c"} (ret = 361)
15:53:02:060 Websocket 172.30.32.1:48864 send message: {"e":"changed","id":"72","r":"lights","state":{"alert":"none","on":true,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-01"} (ret = 142)
15:53:02:128 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"72","lastannounced":"2022-04-01T22:37:20Z","lastseen":"2022-04-10T13:52Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Hallway Display Socket","swversion":"09-06-2019","type":"Smart plug","uniqueid":"04:cf:8c:df:3c:8a:39:91-01"},"e":"changed","id":"72","r":"lights","t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-01"} (ret = 351)
15:53:02:129 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"134","lastannounced":"2022-04-01T22:37:20Z","lastseen":"2022-04-10T13:52Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Power 134","swversion":"09-06-2019","type":"ZHAPower","uniqueid":"04:cf:8c:df:3c:8a:39:91-15-000c"},"e":"changed","id":"134","r":"sensors","t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-15-000c"} (ret = 349)
15:53:02:130 Websocket 172.30.32.1:48864 send message: {"attr":{"id":"135","lastannounced":"2022-04-01T22:37:20Z","lastseen":"2022-04-10T13:52Z","manufacturername":"LUMI","modelid":"lumi.plug.mmeu01","name":"Consumption 135","swversion":"09-06-2019","type":"ZHAConsumption","uniqueid":"04:cf:8c:df:3c:8a:39:91-16-000c"},"e":"changed","id":"135","r":"sensors","t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-16-000c"} (ret = 361)
15:53:02:284 poll node 00:15:8d:00:01:00:3c:d3-01
15:53:02:285 Poll light node Strip Kitchen 2
15:53:02:337 read attributes of 0x00158D0001003CD3 cluster: 0x0006: [ 15:53:02:338 0x0000 15:53:02:338 ]
15:53:02:339 add task 3810408 type 19 to 0x00158D0001003CD3 cluster 0x0006 req.id 199
15:53:02:339 Poll APS request 199 to 0x00158D0001003CD3 cluster: 0x0006
15:53:02:384 Poll APS confirm 199 status: 0x00
15:53:02:385 Erase task req-id: 199, type: 19 zcl seqno: 244 send time 0, profileId: 0x0104, clusterId: 0x0006
15:53:02:414 Node data 0x00158d0001003cd3 profileId: 0x0104, clusterId: 0x0006
15:53:02:415 0x00158D0001003CD3: update ZCL value 0x01/0x0006/0x0000 after 0 s
15:53:02:417 Websocket 172.30.32.1:48864 send message: {"attr":{"colorcapabilities":31,"ctmax":1000,"ctmin":100,"id":"74","lastannounced":"2022-04-09T15:35:54Z","lastseen":"2022-04-10T13:53Z","manufacturername":"innr","modelid":"FL 140 C","name":"Strip Kitchen 2","swversion":"0x28002162","type":"Extended color light","uniqueid":"00:15:8d:00:01:00:3c:d3-01"},"e":"changed","id":"74","r":"lights","t":"event","uniqueid":"00:15:8d:00:01:00:3c:d3-01"} (ret = 394)
15:53:02:941 Node data 0x00158d00059ff795 profileId: 0x0104, clusterId: 0x0006
15:53:02:942 0x00158D00059FF795: update ZCL value 0x01/0x0006/0x0000 after 0 s
15:53:02:945 Websocket 172.30.32.1:48864 send message: {"attr":{"colorcapabilities":0,"ctmax":65279,"ctmin":0,"id":"48","lastannounced":"2022-03-31T16:37:41Z","lastseen":"2022-04-10T13:53Z","manufacturername":"innr","modelid":"RB 285 C","name":"Bathroom Upstairs Light","swversion":"2.1","type":"Extended color light","uniqueid":"00:15:8d:00:05:9f:f7:95-01"},"e":"changed","id":"48","r":"lights","t":"event","uniqueid":"00:15:8d:00:05:9f:f7:95-01"} (ret = 393)
15:53:03:423 poll node 84:fd:27:ff:fe:92:1e:38-01
15:53:03:423 Poll light node Terrace Socket Ceiling Left
15:53:03:471 Poll APS request to 0x84FD27FFFE921E38 cluster: 0x0006 dropped, values are fresh enough
15:53:04:137 Websocket 172.30.32.1:48864 send message: {"e":"changed","id":"134","r":"sensors","state":{"current":277,"lastupdated":"2022-04-10T13:53:04.113","power":3,"voltage":218},"t":"event","uniqueid":"04:cf:8c:df:3c:8a:39:91-15-000c"} (ret = 185)
15:53:04:457 poll node 80:4b:50:ff:fe:b5:69:b9-01
15:53:04:458 Poll light node Socket Bedroom Cabinet Light
15:53:04:509 Poll APS request to 0x804B50FFFEB569B9 cluster: 0x0006 dropped, values are fresh enough
15:53:05:460 poll node 00:17:88:01:09:ef:cd:c4-0b
15:53:05:460 Poll light node Living Room TV Backlight Left
15:53:05:510 read attributes of 0x0017880109EFCDC4 cluster: 0x0006: [ 15:53:05:510 0x0000 15:53:05:511 ]
15:53:05:511 add task 3810422 type 19 to 0x0017880109EFCDC4 cluster 0x0006 req.id 228
15:53:05:511 Poll APS request 228 to 0x0017880109EFCDC4 cluster: 0x0006
15:53:06:460 sql exec SELECT conf FROM zbconf ORDER BY rowid desc limit 1
15:53:06:461 Idle timer triggered
15:53:06:461 binding for attribute reporting SensorNode Motion Kitchen of cluster 0x0406 seems to be active
15:53:06:461 Force read attributes for ZHAPresence SensorNode Motion Kitchen
15:53:06:462 binding for attribute reporting of ep: 0x02 cluster 0x0000 seems to be active
15:53:06:462 binding for attribute reporting of ep: 0x02 cluster 0x0406 seems to be active
15:53:06:462 Force binding of attribute reporting for node Motion Kitchen
15:53:06:960 GW firmware version: 0x26720700
15:53:06:960 GW firmware version is up to date: 0x26720700

Additional context

Lock is running the new firmware 0.20.0
I’ve already contacted Danalock, they’ve sent me a new lock and assured me that they are testing the locks locally with a Conbee II stick and Zigbee2MQTT and do not have any problems there.

I tried different router of different manufacturers (Phillips, LUMI, innr) and the stick is 2m away from the lock. LQI is between 150 and 200.

1 Like

@de_employees Can you check if this is indeed a bug in deCONZ or something else?

We are in contact with the devs and they send us a device to test it in our environment.
@Prior99 when the lock disconnects did you power off or rebooted the gateway before?

It use direct connexion or use a router ?

@Prior99 I have a danalock and I will be trying to get a new one. Figured it was something with the conbee2 I have the same problem and is been like that for more than a year now. They claim the Smartthing hub is officially supported on their website. so got one just to try. it does the same thing there and that’s the only thing connected to the Samsung hub. so noting to interfere whit it and directly connected.
I have tried 3 different times whit there support but they stop responding after a while. But I’m hoping the new one they sent you works. Then there is hope for me :slight_smile:

1 Like

@discodogge I have the same problem with the new bell they’ve sent me.
@ChrisHae wow, awesome, thanks guys :slight_smile: I did not reboot the gateway before it drops out, but I tried rebooting the gateway, restarting deconz and also rebooting the host. Didn’t work.

To bad!
Hope @ChrisHae has better luck then :slight_smile:

For the integration I had a Danalock for a couple of weeks to test with. The problem did happen there too, in the sniffer the device did go completely radio silent and made no attempt to rejoin or continue contacting the coordinator. When the new sample arrives we can hopefully reproduce this while the sniffer is running. And then figure out a way to keep it connected or bring the insights and recommendations to Danalock so that they can check the firmware. There are robust approaches to assure devices stay in touch with the coordinator even in case of rogue routers, Philips Hue motion sensor does this very well :slight_smile:

1 Like

Is there a way in deconz to force an end device to use a specific route? Because in my case, the lock is just half a meter away from the coordinator, but it still rather connects to a light bulb close to it rather than going directly via the conbee 2. Perhaps the conbee’s routing table is full?

If there was any way to trick the conbee to choose the lock over other devices, this would at least do the trick for my specific use case.

Confirmed as well here.
I asked Danalock support to get the previous firmware because it is a critical issue in a daily use (I had to go through the garage tonight :sob:). I’m waiting for an answer.
Thank you so much the deconz team for your work, I am hopeful to see a stable firmware appear from Danalock with your collaborative spirit.

@0rsa Did it work for you on the previous firmware? my lock has always misbehaved even on previous firmware. I have the file and can arrange a download link if you like. but not sure if the lock will allow a downgrade.

@manup that would be awesome :smile: sounds good that the tec is already there with other manufacturers. my impression of Danalock is that Zigbee is not a priority because ist not even working properly whit smartthing that they claim is supported. Bought a hub just to check:stuck_out_tongue: the exact same problem still exists there. But hopefully, when they send the samples they are also more willing to work whit it :slight_smile:

With the previous firmware (0.17.x i don’t remember exactly but it is possible I was not with the latest firmware prior to 0.20.0), I was having issues when I was restarting deconz.
But once the danalock restarted as well after that and paired, it was reliable, at least for many days.

I got a response from support: this is not possible to downgrade so we have to stay with 0.20.0
They suggest to me to do a reset :

Remove one battery from the lock, insert it again, and give the lock 10 clicks (by inserting a paper clip into the small pinhole on the lock). The 10 clicks will reset the lock. After the reset give the lock 1 click (this will put it in inclusion mode).

Of everything I’ve tried, i don’t know what is really doing this reset because you still have access to the doorlock in the danalock app if you don’t have removed it before the reset. Also, the link in deconz is still up as well.
In my opinion, a “real” reset should clear all and make the existing danalock paired (in the danalock app or in deconz) completely unavailable until a new link will be done (but it’s an other debate).

Finally, I spent about two hours to reset, unpair, delete app device/deconz node and then to pair, add device again.

I have almost never had the same behavior at each link in deconz GUI

  • A node without cluster appears in deconz gui, this is not identified as a door lock and it disappears when I restart deconz GUI
  • A node identified as a door lock appears with proper clusters, but it does not appear in deconz webui
  • A node identified as a door lock appears with proper clusters, and it is available in deconz webui

Sometimes, using webui, the state was never updated. Commands work but the state never changes.
Sometimes, nothing is working, commands and state.
Sometimes, all is working but for a short time.

I had something ok last night and this morning the commands are working but the status is no longer updating.

And the last but not the least: I have two danalocks
One is working perfectly currently since the 0.20.0 upgrade, even with my mutiple restarts of deconz yesterday. This danalock is placed 1 meter from the conbee II key without obstacle. In deconz GUI, I can see a direct green link with the configuration tool node.

FYI:
We work together with the Danalock support now.
I stable solution is planed, I will get you updated here.

1 Like

Thank you @Gautama
do you have an ETA? The situation since 0.20.0 is catastrophic on my side. I no longer open the door, I go through the garage.

We first have to see for what reason the devices drop out. We already had a customer device on site for this reason and could not find the problem. Since we are now working together and Danalock is also willing to solve the problem, we are in good spirits. There is currently no ETA, as we have only started this week.

1 Like

You guys are awesome. Thanks for the support.

1 Like

@Gautama this might also be a bit cheeky but throwing it in while we are talking about it anyway. If we also could get the battery working would be awesome too. can have it if i do a ddf but then the lock stops auto-updating the status. probably some binding that goes missing but I can’t for the life of me figure it out. :stuck_out_tongue:

2 Likes

Don´t worry, we will try to implement it 100% (with all features and views).

3 Likes