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)
Hello Stephan,
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?
Hello @MatthiasK
thanks for your help. The Bridge SW-Version is shown as 2.1.34
How can I get the latest beta on the Bridge?
Weird is also that the bridge responds like this:
$ curl <bridge-ip>:8080/list
HTTP 503 Unavailable - Contact support at contact@nuki.io
$ curl <bridge-ip>:8080/list?token=myToken
curl: (56) Recv failure: Connection reset by peerThis 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.
Thank you @MatthiasK
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).
Hello @MatthiasK
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):
$ curl <ip-bridge>:8080/list?token=<token>
[{"deviceType": 0, "nukiId": <nuki-id>, "name": "Front"}]
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.
I tried to reproduce this and also got a stripped done reply the first time I called /list after my Bridge restartet. 
Most propably due to the Bridge not having current data from the Smart Lock yet (/liost takes cached values).
After that I always got correct responses (see https://developer.nuki.io/page/nuki-bridge-http-api-190/4/#heading--list) and could call it without problems repeatedly.
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?
No.
you can find those here: https://developer.nuki.io/page/nuki-bridge-http-api-190/4/#heading--endpoints
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
or
$ curl -s 'http://<bridge-ip>:8080/list?token=<token>'
HTTP 401 Unauthorized
Any idea? I’m thinking of just bringing the lock and bridge back to vendor, as without local access it’s useless for me.
Weird that the badly working android bridge app, worked still better in a local network than the bridge does.
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.
Hello @MatthiasK,
after re-setting everything again and starting over and playing around with it half the night I figured that it has to be the fact, that the bridge is LAN-only.
Now with the newest beta-firmwares installed and reset, it works reliable since about 6 hours to call the API, when the bridge is connected to the internet. When it is LAN-only it stops working properly and gives me all the above headaches.
Could you please revisit the LAN-only behavior of the API and make sure the bridge can work reliable when not connected to the internet?
This is a bug in the Android App which is fixed in the newest beta (going live soon).
Thanks for the work you put into testing. I will further investigate on our side and put up some testing scenarios. We have several users with a local offline-setup, but there definitly seems to be a problem related to the bridge showing an IP of 0.0.0.0.
Thank you @MatthiasK,
please let me know when you have something ready for testing. I’ll be happy to try it out.
i know this is my third entry to this problem.
But i have exactly the same issue. I’m using the Software Android Bridge (my LAN is unifi too) …
it is not working without internet access.
Did you find any workaround for the issue? Without any hint for an upcloming patch, i. e. a sane solution I was thinking of rate limiting the packets to the nuki servers or to try to introduce a fake local one. The last idea wouldn’t work if the certificate is pinned.
Patrick
no, it took me the last night to figure out why the sw bridge wasn‘t responding.
today i finished my first version for knx but if this bug will stay i‘m going to remove the bridge solution.
cloud isn‘t a solution for me!
Hello,
is that issue with not obtaining a local IP address properly finally solved and can the Bridge work LAN-only? I don’t want it to talk to the internet. I want my local server to talk to it and process all events. I have several bridges and locks in different places and I want to have them finally proper integrated in my “house management” solution, have rules triggered, etc. without that I need to give them access to the internet (which I don’t have in two places - yes, believe it or not, there’s houses that don’t have internet access and don’t need it 
).
Hi everyone,
I started using the Nuki Bridge HTTP API with firmware 2.14.0 to integrate a Nuki Smart Lock 3.0 Pro (firmware 3.5.12) in my home automation software Jeedom.
The cURL requests very often return the error ‘Recv failure: Connection reset by peer’ (as mentioned above by @bblattschuss) for following URLs:
How can I solve this issue?
Thank you for you help and kind regards,
Christian