Unoffical danalock web API

Key use cases:

  • :white_check_mark: Lock
  • :white_check_mark: Unlock
  • :white_check_mark: Lock status, i.e. determine if the lock is open or locked

Requirements:

Implementation instructions are provided in README.md. Changed are tracked in changelog.md.

4 Likes

do you plan an Home Assistant integration?

No plans - but if you’re interested I could share a node-red implementation + basic configuration in home-assistant that would enable easy integration in home-assistant?

I would also be interested :slight_smile:

Hi all! I’ve update this project. See first post for more info.

I just bought a Danalock v3 used and will try and mount it this weekend.
Looking forward to use this also!

Has anyone asked if there is a local API on the bridge that can be used?

I get this message:

image

Which oauth palette is it you are using?
This one?

Yeah! I think it’s that one. Thanks for the feedback, I’ll add a note about it later.

@Hellis81, I haven’t looked for a local api, but perhaps it exists

@gechu do you have to have a Danalock Bridge to be able to use your GitHub code? I ask, as it says about the 2 calls, one to bridge and one to lock. I got my Danalock yesterday which fitted well and was detected by HA ZHA (Zigbee/bluetooth version)without problems but this project seems interesting. I also bought the DanaPad (which I have yet to fit) and I didn’t get the Danabridge though.

They have this on their webpage…

I’ll send them an email and see what is needed to get the SDK and API documentations.

I found this when googling.

Software Development Kit (danalock.com)

This seems to indicate that there is no local API for the bridge, that it has to go through their server first.

Log- and lock information (top 2 options in list below), does not require a Danabridge - However, any interaction with the actual lock requires a bridge to “bridge” between web and Bluetooth.

Interaction with the lock could be done using zigbee or zwave as well, assuming your lock supports it, but such functionality is outside of scope here. Here the focus is web APIs that require a danabridge to work.

http://node-red-host:1880/log/v1/lock
http://node-red-host:1880/locks/v1

http://node-red-host:1880/bridge/v1/execute/status
http://node-red-host:1880/bridge/v1/execute/lock
http://node-red-host:1880/bridge/v1/execute/unlock

1 Like

I get a parse error on the Call API node when I use the “bridge” URLS.
When I use the Log I get:

{"error":"not_found","message":"The requested URL (GET http://api.danalock.com/log/v1/lock/%2A) was not found."}

When I use the Lock, the message goes to the “need refresh access token” node

Oddly enough, I can’t see the bridge when I open the web account, but in the app I see the bridge.
Could that be part of the problem?

The links in your post is missing /endpoint

The “log” endpoint implementation in Node-RED was broken. Its fixed now.

For some strange reason I also had issues when executing requests towards the “bridge API”. Somehow they seemed to be related to the flow context variable “danalock-lock” not being set - even though the information was successfully retrieved during initization of the flow. I updated Node-RED and rebooted. Then it all worked again.

Are you still having issues?

Regarding "The links in your post is missing /endpoint" - how do you mean?

EDIT: unofficial-danalock-web-api.yaml is missing the API call for posting a log entry. If you use the Danalock app, then at lock/unlock, such call will be executed - resulting in a log record that can be retrieved using a request to the “log endpoint”. So, if you simply use the lock / unlock API calls, there will be no log records, hence you have to manually create such records.

When I try as your link says

However if I add /endpoint (as node red says I should)
image
image

The sequence runs at least. It does not work since I need to refresh the token.

If I add a debug in the subflow and inject the upper injection node I see this:

But I also noticed I can’t unlock (or lock) when out of Bluetooth range. Isn’t that the point of the bridge?
It seems the issue is in the hardware to be honest.

Hi! This looks really strange! :slight_smile:

This is what may GET endpoint looks like (no mention of “/endpoint”). I use latest node-red from their git repo.
image

Regarding the image with an arrow - the debug message is from the Oauth node - however that is not the node your arrow is pointing at?

Perhaps you’ve re-arranged the nodes, but from the partial screenshots you show, the flow seems a bit disconnected. Perhaps my export was not proper - anyway. This is what the complete flow should look like:

Finally, did you set your danalock usernamn and password in the flow?

Yes that arrow is to the correct node.
You can see that by hovering the mouse over the node name in the debug and the corresponding debug node will light up with a dashed red line around it, just like on the image.

My flow looks the same, but the image was taken from inside the subflow Oauth2.

I can now use the bridge so that seems promising on this end.

I imported the flow again and this time it looks different in the subflow. I see what you mean now.

But I still get errors…
Here I connected one debug to two nodes and the red arrows indicate which is which.

It looks correct! - Can’t understand why you get a 400 though …

What does the oauth2 node look like?

There’s a sample flow at the botton of https://flows.nodered.org/node/node-red-contrib-oauth2 - Study the “password grant” flow and see if you can pinpoint the issue.

Also, the flow I provided does make heavy use of context variables. I noticed some, for me, unexpected behaviour, when I noticed that context variables were not cleared at re-deploy.

You can use https://flows.nodered.org/node/node-red-contrib-contextbrowser to see context variables.

I’m really shooting in all possible directions. No clear target in sight though

@Hellis81 - I run Node-RED in a proxmox container that I backup weekly. I noticed that flow context variables that were set at init of the flow had gotten lost.

I added a control to the flow that would re-set these variables if they were lost. The change is untested, but I think it will work :+1: :slight_smile: