I thought of something like this, i now stopped my app on the phone manually. Works a little bit better, but still sometimes there is the error. I think while the bridge is syncing with the nuki cloud it does also not accept the api requests, right?
Do you know if there ist a way to use the bridge only with api requests and callback and fully without the nuki cloud?
I never open the app on the phone, so I never needed to stop it, it does not do any action in background as far as I can tell. The bridge talks to nuki cloud only when initializing the API, or upgrading the firmware, that’s all. The rest of its activities is BT/BLE communication with the Lock and other devices, plus the local communication for the callback or if queried from LAN.
Ok, thanks for explaining. Updated to Beta2, i’ll report tomorrow if input_text returns to false.
Use the binary sensor instead of the input_text, I might change the name of the input text, it’s an “internal” variable. 
thanks @alexdelprete. now it’s working!
can you please add an example of calling a restful service for lock & unlock
I want to be able to put it on a lovelace as a separate button on a dashboard. thanks
Stefan, here’s the documentation for the Bridge API from Nuki: https://developer.nuki.io/uploads/short-url/5tLp76dEJ1RYfkSUKxFTUSeyJNg.pdf
For Nuki Card I chose to use the /lockAction endpoint, which allows me to do lock/unlock for both the smartlock and the opener, passing only a few parameters:
rest_command:
nuki_lock_action:
url: "{{ states('input_text.nuki_bridge_url') }}/lockAction?deviceType={{ dev_type }}&action={{ action }}&nowait=1&nukiId={{ nuki_id }}&token={{ states('input_text.nuki_bridge_token') | urlencode }}"
Here’s the description of /lockAction from the document I linked you above.
If you want to use the Nuki Card, the rest_command can be used as a service in scripts or automations:
action:
- service: rest_command.nuki_lock_action
data:
nuki_id: (the id of the nuki device, smartlock or opener)
dev_type: (0 for the smartlock, 2 for the opener)
action: (1,2,3,4 or 5 - check the table below)
dev_type for smartlock: {{ state_attr('sensor.nuki_bridge_endpoint_list_lock','deviceType') }}
dev_type for opener: {{ state_attr('sensor.nuki_bridge_endpoint_list_opener','deviceType') }}
nuki_id for smartlock: {{ state_attr('sensor.nuki_bridge_endpoint_list_lock','nukiId') }}
nuki_id for opener: {{ state_attr('sensor.nuki_bridge_endpoint_list_opener','nukiId') }}
Or you can simply put the entity in your lovelace card:
- entity: lock.nuki_lock_action
- entity: lock.nuki_opener_action
1 Like
Hi Alex,
First of all big THANK YOU for this awesome integration.
I set it up and it worked well the first time and shows all the data correctly. I also managed to lock my door via HA.
But then right after that i noticed that the Lock FW version suddenly changed to unknown and i cannot lock/unlock the door anymore. connection is broken.
I restarted HA and again all worked until i unlocked the door again and right after that the same thing happens.
There are several errors in the logs:
Any idea what could be causing this?
Many thanks.
Hi Emre,
first of all, are you using the official version or the beta I just published?
second question: are you using the official HA Nuki integration?
From the logs you posted, the /info endpoint of the rest calls is not working correctly, probably because of the usual bridge problem that it only allows one command at a time.
So the usual suggestions: make sure you’re not using ANY other app/component/integration/script that interfaces the bridge in parallel, otherwise the rest calls could fail. So first make sure that no other software is communicating with the bridge, for example the mobile app, etc.
And last thing: you have a very old fw version for the bridge, you need to update it. As I wrote in the note of the first post:
- the code is based on Nuki Bridge API v1.12, make sure the bridge fw is updated to last available version before starting the configuration of this integration. min. version supported: v2.5.3
Let me know…
Ok, now both the binary_sensor and input_text stays on/true. In my understanding the binary_sensor.nuki_opener_ring_action_state should be the mirror of the doorbell, it turns on when it’s ringing and off when ringing is over. That would be usefull in my opinion, now you can see someone has rang the bell but it never returns to state off (so if the next one is ringing you would not recognize it).
The question now is, should i do it with an automation on my own (if binary_sensor.nuki_opener_ring_action_state = on for 5 seconds turn off) or should your automation do it, what do you think?
Second one, i pressed the unlock button on the opener card today 5 or 6 times before the state changed to ring to open, where do i have to look to check if my ha does a restcall when i press the unlock button, is it possible?
Mike
Hi Alex, thank you so much for your super fast answer
- I followed your instructions from the very top of this page (from May 29?). Didnt know actually that you just published a new beta version. Would be happy to test that. Where can i find the instructions for that?
-
I defnitely dont have the official HA NUKI integration running or installed. I actually tried setting that up and it always failed to connect, so thats how i ended up finding your awesome solution.
-
Its possible that me or my wife might have opened the mobile app around the same time. but not exactly at the same time though. dont know really. i mean i dont remember opening the app when i started testing this on the HA…
-
I also noticed from your screenshots the big difference in the bridge firmware. And i went to the app and checked it and it says there is no new firmware… strange. i will check again.
Again thanks so much!
Nope, the ringactionState is a separate status variable. When you ring the opener, the bridge should do a callback and send this (example):
We can also monitor the status of that variable with the /list command, as per documentation after 30secs it resets:
So when you activate RTO, and you see the updated state of the opener, ring and wait for the callback (you should see the bridge led blinking when it sends the callback), then after 5 seconds send the /list command and show the output, we need to monitor the ringactionState variable.
curl -X GET ‘http://bridge-ip:8080/list?token=xxxxx’
I noticed that problem sometimes too, but it requires only clicking two times here, I have to investigate a little. I noticed that the opener is not reactive as the lock…and it’s more difficult to debug. I’m thinking I have it too far from the bridge so it has communication issue. Will let you know about this one…
Which bridge do you have? HW rev 1 or 2? When did you buy it?
Effectively, if it was too old, nothing would’ve worked. You might have Nuki HW rev 1.
Yes i think i have version 1. I got this like 2 years ago roughly…
Should i buy a new one?
A few posts above: Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration) - #961 by alexdelprete
Thanks for your kind words, I developed this integration mainly because the official integration was really inefficiend and slow, but it was working. If it wasn’t connecting, my suspect is that you had communication issues also with that one. Do you have a good wifi setup? The bridge is a very limited device, make sure it has a strong wifi signal.
Please make sure no other sw is sending commands to the bridge, this can create issues.
You can also update from command line:
curl -X GET ‘http://bridge-ip:8080/fwupdate’
I don’t think it’s needed, if Stephan said it provides the same functionalities. But you never know.
Let’s try to make your v1 work. If we see that it’s too unreliable, then I would advice to get a v2, even though v2 is not very good either…the bridge hw is a severe limitation of the Nuki solution, unfortunately.
They had a sw bridge solution, but I read it’s not supported anymore, it would’ve been great having the Nuki Bridge as an HA component. 
Thanks again Alex. I dont want to cause you too much trouble. i tried updating the firmware but no change. i guess thats the latest one for the V1 bridge. I know the owner of NUKI and will talk to him about the bridge. Maybe they can upgrade it one day…
So let’s try to make your v1 work, no problem at all Emre. I can assure you the code works, it has been tested by many people and there are no main issues, so the problem is only the bridge limitation of being able to process only one command at a time, it can’t queue anything. We solved many issues by implementing a queue mechanism, but I can’t control if an external app sends commands at the same time.
If you talk to the owner of Nuki, tell him that we have several ideas on how to improve the solution. If he wants to do a conf.call I’ll be more than happy.
ok noted. will talk to them in the coming days and come back to you. Can you pls let me know your email address so i can set up the call with you directly?
And thanks again for trying to fix the V1 now much appreciated. So where do we start? Me or my wife are not using the app now.
Will send it privately.
Ok, first of all, if you have time available, try to install v11: like I wrote in the v11 post, you need to clean everything you did for the v10. If you have problems let me know.