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?
@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.
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.
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.
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.
This is what may GET endpoint looks like (no mention of “/endpoint”). I use latest node-red from their git repo.
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:
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.
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.
@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