First of all:
Happy new Year !
And now:
thank you for your help. My Lock is now connected with a “real Name” an I can control this trough my Applications .
Hello Guys, thanks for your efforts here.
I’ve had 2 of these locks for 2 years and never got them working with ZigBee for more than 2 weeks. Have now linked them to OpenHab via web and the cloud, which has advantages, you can query the locking status and the battery, but is also not 100% reliable.
So it’s all the happier that something’s happening here again, I had one of the locks at Dresden Electronics Support for a few weeks, but unfortunately they gave up too.
In any case, I have now imported Smanar’s (Thanks) DDF and additionally integrated the locks into OH via the Danalock interface for testing.
I’m curious if they will still work after 2 weeks.
I still have one question: Can anyone see the real battery status? My batteries are showing as empty in the deConz symbol even though one is at 88% and the other at 98%.
In the attributes they ar ok:
And in OpenHab I don’t see them at all, which is probably an OpenHab problem.
On attribute 0x0021, you just need to divide by 2, so you have 80% and 97 % from the device return.
And yes it’s not visible
{
"name": "state/battery",
"refresh.interval": 3700,
"public": false,
"awake": true
}
It’s the old version for doorlock, it create a light device, and light device don’t have config/battery, need to create too a ZHABattery.
You can try to enable it with removing “public”: false,
1 Like
Yes, but on the defaut DDF it’s hidden, perhaps for compatibility issue.
“Sensors” have a config/battery, but not “lights”. For “light” with battery we create too a ZHABattery tha use a state/battery", but it’s not present in the DDF.
Can try to enable it in the previous DDF, or use this one to create the ZHABattery.
{
"schema": "devcap1.schema.json",
"manufacturername": ["Danalock", "Danalock"],
"modelid": ["V3-BTZBE", "V3-BTZB"],
"product": "Danalock V3",
"sleeper": true,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_DOOR_LOCK",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x01"
],
"items": [
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/swversion",
"refresh.interval": 84000,
"read": {"cl": "0x0000", "at": "0x0006", "ep": 1, "fn": "zcl"},
"parse": {"cl": "0x0000", "at": "0x0006", "ep": 1, "eval": "Item.val = Attr.val", "fn": "zcl"}
},
{
"name": "config/pending",
"public": false
},
{
"name": "config/checkin",
"awake": true
},
{
"name": "state/alert",
"default": "none"
},
{
"name": "state/reachable"
},
{
"name": "state/on",
"read": {"cl": "0x0101", "at": "0x0000", "ep": 1, "fn": "zcl"},
"parse": {"cl": "0x0101", "at": "0x0000", "ep": 1, "eval": "Item.val = (Attr.val === 1)", "fn": "zcl"},
"refresh.interval": 600,
"awake": true
}
]
},
{
"type": "$TYPE_BATTERY_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0001"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/battery",
"awake": true,
"refresh.interval": 86400
},
{
"name": "state/lastupdated"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0101",
"report": [ {"at": "0x0000", "dt": "0x30", "min": 1, "max": 300 } ]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0020"
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0001",
"report": [ {"at": "0x0021", "dt": "0x20", "min": 600, "max": 3600, "change": "0x00" } ]
}
]
}
1 Like
In deConz things are now as they should be. Thank’s so much!
OpenHab doesn’t recognize the battery yet, but I think a developer needs to add that first.
Sorry it’s her! I just missed it because it’s a thing of its own.
Not sure, on the first DDF, there is no ZHABattery, and the state/battery (that is disabled) don’t need to be here.
It’s probably missing on the API.
The thing I’ve noticed with the Home Assistant integration is that you only see the lock state. No other info. Whereas in the Phoscon console shows data as mentioned above.
So you are using the second DDF ? I m seing the doorlock+The battery sensor ? Or you already have included the device previously and not delete it ?
OpenHAB recognizes it that way with deConz, but it also happens with other devices, such as sockets with a measuring function or the sensors from Xiaomi:
Do the locks work permanently for someone?
My locks were offline again after 6 days. Actually, only one was offline, the other was online, but could no longer be controlled via ZigBee.
The ZigBee firmware is still original on my devices.
When trying to import 17.2.0 from this thread, the locks did not react, there are probably different ZigBee modules.
There’s new firmware that fixes it. I’m on the latest firmware now and haven’t had any issues for weeks/months.
Thanks,
but do you mean the firmware of the lock (I have 20.06 there), which can be updated with the app, or that of the ZigBee module, which is updated via OTA? I can’t find any information where I can read this version.
The only problem I have now is that the Danalock app can’t find the lock again, which means that I can’t lock or unlock the lock since it is not calibrated. It turns really nice though when controlled by home assistant. Too bad I can’t lock or unlock.
This is an expected behaviour, you can read from the FAQ that the lock will disable Bluetooth when joining zigbee network before adding it to the app. How do I connect my Danalock to a Z-wave/Zigbee gateway and Bluetooth at the same time?
It would be great if we could configure settings from deconz i.e “End to end unlock”, is this possible?? Now I have to delete the device from the zigbee network and pair it with bluetooth to change the setting and then rejoin the device in deconz…
The new firmware works great. I think many of the comments in this thread regarding firmware mixes up the device firmware an the zigbee firmware. The fix to solve the zigbee connection issues is to update to this firmware with deconz OTA
My problem was the hardware V3-BTZB, this cannot be updated to the new zigbee firmware. Now i have V3-BTZBE with 17.4.0 and the locks are online since 10 days, this is longer than at any time in the last 3 years.
1 Like
Hello! Can someone tell me where I can download the latest full rom for the Homekit version? Including bootloader, Which is the full rom? If I want the lock full firmware to be overwritten without hack codes?