API does not respond on commands

#1

Hello,

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

curl -s "http://bridgeIP:8080/lockAction?action=1&token=ac6dcx&nukiId=12345678"

the command is performed and the lock executes the exception but the connection never returns and thus blocks my program.

Before the upgrade I got a JSON notification about the success of the action, but now I get no response and the call just hangs.

The bridge app is not connected to the internet, as for privacy reasons I specifically chose Nuki to be able to have all done in my own home network.

Anything I can do about this? The only command so far I can tell that responds is /list

#2

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?

#3

Hello Stephan,

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)?

#4

I just edited my answer above as I first thought you use the hardware bridge!

#5

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.

#6

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.

#7

You are right - it’s 2.4.5.

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). :slight_smile:

#8

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

HTH

#9

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.

#10

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)

#11

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).

#12

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?

#13

Hello @Stephan

thanks for your help. The Bridge SW-Version is shown as 2.1.34

17
Bildschirmfoto 2019-07-08 um 16.35.17.png592×894 139 KB

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 peer
#14

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.

#15

Thank you @Stephan

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).

#16

Hello @Stephan

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):

12

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.

#17

I tried to reproduce this and also got a stripped done reply the first time I called /list after my Bridge restartet. :thinking:

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.

#18

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. :roll_eyes::disappointed:

#19

@Stephan

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.

#20

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.