I bought a Nuki Lock yesterday and successfully installed it. Everything was working fine and I was able to communicate well with the lock issuing cURL commands to the bridge app I have running on an old Samsung Galaxy S2 that serves as bridge.
I then performed an update to Firmware 2.5.0 and since then, I’m having issues that the API calls do not respond. When I issue something like
What bridge firmware do you have at the moment (check in the bridge management where you activated the the Bridge API)
The bridge firmware upates automatically by checking for new versions on our server (which can obiously only be done if it is online), so I want to make sure it is not running on an old one.
EDIT: Sorry, read over the fact, that you are using the Bridge App. Did you try to remove the Smart Lock from the bridge and add it again?
I downloaded the app from the App Store, so I assume it’s got the one that it gets then. I will take a look later when I’m back home.
I assume there’s not a way to connect the app-bridge with the Nuki app on my phone to be able to look for that info remotely (I can login via VPN to my home network)?
No - I haven’t removed and re-added it. Might the relatively old Galaxy S2 be a reason? I’ll check with a different phone later which has more CPU power and more recent Android version and keep you posted.
The problem with the Android Bridge App is in fact, that we can’t test it on every device (and every Android device and its Bluetooth stack is a bit different).
But you said it worked before the firmware update of the Smart Lock (which should make no difference)?
Also Smart Lock firmware 2.5.0 is an older beta version. So you should either have gotten 2.4.5 (latest public) or 2.5.2 (latest beta) as a suggested update.
Might be the update process messed something up (it got interrupted due to bluetooth connection issue). I’ve reset the lock to factory defaults and use a different phone for the bridge and it’s now working, as it did before it stopped yesterday. So the lock replies with the JSON-formatted information about the success of the command and I can request the lock’s state.
Thanks for your help. Keep this cool thing going. I’d be glad to see a more narrow version of it that I can put on the terrace doors (which open to the outside).
Hmmm – too early. Happening now the same again. After some time (I had the API polled every minute for lockState I do not get responses within 30 seconds (timeout).
Yet, the lock itself acts upon a lockAction, but neither the lockAction nor the lockState return the JSON string that contains info, whether the command was successful, lock state, battery critical information, etc.
Any help would be appreciated. It’s two phones now - the Galaxy S2 and a relatively modern HTC 10 with Android 9.
So I issue a request and that’s what it looks like until I kill the app on the phone:
$ time curl -v "http://<ip-phone>:8080/lockState?token=<myToken>&nukiId=<myNukiLock>" | python -m json.tool
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying <ip-phone>...
* TCP_NODELAY set
* Connected to <ip-phone> (<ip-phone>) port 8080 (#0)
> GET /lockState?token=...&nukiId=... HTTP/1.1
> Host: <ip-phone>:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
0 0 0 0 0 0 0 0 --:--:-- 0:02:37 --:--:-- 0* Empty reply from server
0 0 0 0 0 0 0 0 --:--:-- 0:02:37 --:--:-- 0
* Connection #0 to host <ip-phone> left intact
curl: (52) Empty reply from server
No JSON object could be decoded
real 2m37.438s
user 0m0.050s
sys 0m0.056s
OK - I played around a bit more and it seems to me that the Android app could be making trouble here. I have connected it to the internet and I can without problems issue commands through your cloud to the lock via the app bridge.
However, when I start talking to the bridge as above via cURL, same issues happen. Only the /list command works reliable for me.
If you tell me what to look for in logcat (or does the bridge store logs somewhere else), I can post the info to track down the issues.
You can access the error logs of the Bridge App from the Help menu (top right → Help → scroll down and best activate Debug mode before trying to reproduce the problem)
thank you for your help. I’ve decided to go with the Bridge to avoid the issues above. However, now I’m facing much bigger issues, when I try to connect the (hardware) bridge to my Wifi. It does not want to join my local WiFi network that has no internet connection. As soon as I let it join the Wifi that has internet access, however, then it connects.
In API information for the bridge, it says it has IP address 0.0.0.0 while my Unifi Controller says that it got a 192.168.x.y address. Is it possible, that the bridge software has issues with no-internet wifi? That would be a pity, as I don’t want anything else than access my Nuki through OpenHAB and have no internet connection needed for that (I connect home through VPN).
Hi @bblattschuss
In general the Bridge should connect to a Wifi without internet connection. We had some problems with this lately but at least the latest beta firmware (which should be live soon) should be able to handle the setup as described by you without problems.
Can you check your current Bridge FW version for me?
This is an older factory FW version.
The firmware checks for updates automatically 1 hour after restart and then all subsequent 24 hours.
So I would recomend you get it only once for some hours and it should update to 2.2.9
Maybe this already solves your issue.
Else you can apply for the beta as described here:
EDIT:
This is also bc this FW didn’t support the HTTP API before an update.
I will restart the bridge then in a network with internet connection. Seems Hornbach is selling older stuff then (the batteries shipped with the lock were completely empty).
it’s upgraded to 2.2.9 but still the connection cannot be made and the bridge says Connection reset by peer after some time when calling /list (I obfuscated token and IP):
iMac:~ user$ curl <bridge-ip>:8080/list?token=<token>
curl: (56) Recv failure: Connection reset by peer
iMac:~ user$ curl -v <bridge-ip>:8080/list?token=<token>
* Trying <bridge-ip>...
* TCP_NODELAY set
* Connected to <bridge-ip> (<bridge-ip>) port 8080 (#0)
> GET /list?token=ibYUBP HTTP/1.1
> Host: <bridge-ip>:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host <bridge-ip> left intact
curl: (52) Empty reply from server
Within perhaps 20 attempts of cURL-ing the same again and again, I got once (!) a response with the expected JSON where my door is listed (though it looks different than on the Android bridge):
This is less info than I got from the Android app (there was batteryCritical, lock state, etc.) and then again no reply and the same as above. Another 10 tries resulted in connection resets. Very strange.
I checked wifi is good (Unifi equipment):
Does the bridge itself offer some (minimalistic) web interface where one can see state, available API commands (potentially executable) and/or logs? That would help a lot in debugging.
P.S.: I’ve executed the cURL calls also with quoted ‘’ URLs to avoid issues with & signs on Linux.
With /lockState you will get the state directly from the Smart Lock (waking it up and consuming battery on every call, so don’t use this for ongoing polling). Does this work for you?
Sorry, this is still a missing feature in FW 2.x we can hopefully offer soon.
Yes, correct way to do it.
P.S.: On a side-note: If you had your Smart Locks batteries run completely empty and experience any problems with it we recommend a factory reset to be o nthe safe side.
Hmmm… I had my Smart Lock reset already and I reset the bridge as well. As you can see, it also still shows 0.0.0.0 as IP address.
The /list command unfortunately does still not work. I might perhaps try a beta firmware and see whether that helps.
At least the /list command was working reliably from the Android app (which also showed correctly the local IP address). Yet, lockState and lockAction got no response from the lock as described above, after a certain time of operation (is there perhaps a buffer that is running full?).
I will send you a photo of the lock and bridge label to get beta firmware (I assume that is then automatically installed via the internet / the app?) and see whether that helps, though I was actually not planning to invest that much effort in simply getting a lock up and running (in total it’s actually going to be three) with my OpenHAB instance, especially as it’s relatively costly.
the beta firmware also no luck. The bridge even won’t respond to /list requests. To clarify my setup. I have a Wifi with ESSID called “intern” which via router firewall is denied access to the internet. To this I have added the bridge.
The bridge after initial setup shows a correct IP address, but after saving the configuration (bridge restarts) and then entering bridge configuration in the Nuki app again shows the bridge’s IP with 0.0.0.0 and the cURLs are either things like
curl: (56) Recv failure: Connection reset by peer
or
$ curl -vvv 'http://<ip-bridge>:8080/list?token=<token>'
* Trying <ip-bridge>...
* TCP_NODELAY set
* Connected to <ip-bridge> (<ip-bridge>) port 8080 (#0)
> GET /list?token=<token> HTTP/1.1
> Host: <ip-bridge>:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host <ip-bridge> left intact
curl: (52) Empty reply from server
I also figured that the bridge loses the smart lock that I already added before (and saw after connecting to the bridge again after restart of it).
I now put the bridge in maintenance mode and opened it on the Nuki App and the door lock is not listed in the Android app. On iOS, however, I can see it.
Current firmware 2.2.12.
I’ve upgraded the lock to the latest beta now as well and put the bridge on the internet-connected Wifi. Now I no reply or once this
$ curl -vvv 'http://<ip-bridge>:8080/list?token=<token>'
* Trying <ip-bridge>...
* TCP_NODELAY set
* Connected to <ip-bridge> (<ip-bridge>) port 8080 (#0)
> GET /list?token=<token> HTTP/1.1
> Host: <ip-bridge>:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 503 Service Unavailable
< Connection: Close
< Content-Length: 20
<
* Closing connection 0
HTTP 503 Unavailable
Are you sure that the bridge can work on a network that has forbidden internet connection? I wonder why on that internet-free wifi it always shows itself having an IP of 0.0.0.0, while when on the internet-connected wifi, it has a “normal” local IP address.
Also - the only “successful” connects when I got at least some response on list, were when it was on the internet-connected wifi but not the internet-declined one.
Is it possible, that the API doesn’t recognize requests to itself as it sees 0.0.0.0 as it’s IP instead of 192.168.x.y? A ping to the bridge works, but the commands don’t.
