Random "HTTP 503 Unavailable"

Nuki APIs Bridge HTTP-API
62

I reduced the already serialized requests to a sleep of 0.1 seconds and it’s still working.

For our unserialized AJAX WebIf->Server->Bridge requests we will implement some kind of blocking locks on the server side, saving a hires timestamp of „Bridge request Running since“ and „Last Bridge request finished at“ to slow down and serialize the Ajax requests. It‘s tricky to implement (also to handle filesystem locks and deadlocks on the server side).

Would be great to accept eg 5 concurrent http connections and queue them on the bridge side, making everything more easy.

And at least after sending the Bridge response, the current single connection should be available again, to not play around with delays/sleeps.

63

There is a simple solution to this problem then.
throw this garbage out of the window.

There is no way in 2019 a device should only have one connection available…
this is utterly useless for a product like this.
this kind of of problems should not be solved at the end users level.

either make the choice to remove the API, or just make one that works.

and the fact that your V1 did not have this problem and your V2 has,
makes it the more not understandable.

And indeed I am better of using an other lock if this can not be fixed.

64

Yes, would be great, but is not feasible because of hardware restrictions.

We’re planning to further improve the behavior in a future firmware update. But this requires structural changes to the bridge firmware which take some time to develop and test and will not be available before Q4.

1 Like
65

Why not just implement MQTT support? And all concurrent connections will not be your headache?

1 Like
66

There have been no changes to the wifi hardware. The restriction is not new and has always been there.

67

Theoretically possible after the structural change. But HTTP API needs to remain because of backwards compatibility. You should post this request in the feature request section and start collecting votes for it. https://developer.nuki.io/c/feature-requests

68
2 Likes
69

I need to defend the nuki team here. I am the developer of the homebridge nuki plugin and have worked with the api from the very beginning. The problem always existed and was always clearly communicated by the team. I am so happy that there is a http api available at all, so dont blame them for restrictions. And since this is a developer forum I think there should not be a problem to implement the api respecting its restriction. Of course it would be better without this restriction.

3 Likes
70

well I did not have the problem with V1, in fact no one has.

Who made those restrictions, president trump?

I am glad there is an clear answer, you might as well close the topic , “works as intended”
so why wait almost 9 month to come to this conclusion?

For me it is also solved throw this sh*t out of the window, never advise any one to buy it.

71

Is there any better solution for EU locks? Except local control (via Web API) everything else works pretty well and stable for all of my two v2 locks that I have.
After we installed Nuki Lock it was first time when my wife said that smart lock is one of the best and useful smart device she ever get in touch with.

Right now we have a confirmation that Web API is not 100% reliable/predictable and nothing can be done in that area…

72

I just bought a danalock V3 I have Z-Wave, but they also work with homekit, and bluetooth.
And there bridge will be coming soon.

Because I literally don’t care how much I spend on something as long I am getting the job done.
and the V1 got the job done.

But because of some battery started leaking in the device and the plates got oxidation.
I bought a V2, but then I noticed it was not compatible with my old bridge so i bought the new bridge.
and from there the real mess was starting…

For a product that says it need to be compatible it is damn not compatible in every common sense

73

Is it planned a new version of the bridge firmware to stop these problems of HTTP 503?

1 Like
74

see above:

and also:

75

such an answer is not only unacceptable but also rude.
the people in this forum are not only trying to help but are also trying to figure a way to fix a problem that is caused by a flawed implementation of yours. i am implementing APIs at my fulltime job and working with the nuki bridge is the worst experience i ever had. if you compare your implementation with the quite comparable API from philipps in the hue bridge you can see what propper error handling should look like!

1 Like
76

After another night of debugging I am jumping ship.
Sorry girls and guys, but the following is going to be a bit of a rant.

When I had to find a solution to upgrade the doors in my company I chose Nuki because of one simple reason: the bridge with the local http API. I am simply not willing to sacrifice security by letting some third party server have full controll over my doors. Nuki promised to have an open API and while Nuki is not the cheapest solution on the market, I am willing to spend an extra buck for a good an open API.

We were planning to fully integrate the local Nuki HTTP API in our private app. The app is accessing several IOT bridges in the network directly. If two user choose to access one bridge at the same time, the two requests send the bridge on a long digital 503 hiatus. As the requests come from two different devices, there is no possibility for us to serialize the requests. And to be honest there should be no reason to serialize the request on our side. We have even built implementations with an ESP8266 (4$) and had no problems by simultaneous requests at all.

I am obviously not the only one who is fed up with the flawed implementation of the API. Your bridge is just too expensive to be such an unreliable piece of hardware. If you can’t handle GET requests from Chrome, which is ridiculous in its own, don’t implement GET requests.
And don’t even get me started about the static six digit token via GET in an unencrypted stream.

People in this forum are trying to help and asking for your colloboration - let them help you!
Sorry dudes for beeing honest but I have had it.

4 Likes
77

@zoli I agree. Though, have you tried using the Software Bridge?

78

Hi everyone, we recently bought a Nuki and want to use the Bridge API for automatisation.

I get that the bridge can handle only a single connection at a time (and it also seems to need a short delay of about 0.5s between subsequent connections, otherwise the second connection will almost always time out).

The real problem though is that it is apparently possible to crash the API by sending too much (or too frequent?) requests. If this happens (and we can reproduce it rather reliably), the API simply does not answer any more at all (all requests time out).

For now the only way we found to make the API responsive again is to restart the bridge by unplucking it for a short moment. This is simply unacceptable.

Is this a known bug? If so, is there a firmware update planned to fix it?

Bridge info:

 { 
  "bridgeType": 1,
  "ids": {
    "hardwareId": 408214058,
    "serverId": 1645843699
  },
  "versions": {
    "firmwareVersion": "2.2.13",
    "wifiFirmwareVersion": "2.0.0"
  },
  "uptime": 46,
  "currentTime": "2019-09-16T08:09:16+00:00",
  "wlanConnected": true,
  "serverConnected": true,
  "scanResults": [
    {
      "deviceType": 0,
      "nukiId": 437814069,
      "name": "Nuki_1A188335",
      "rssi": -56,
      "paired": true
    }
  ]
}
2 Likes
79

It is a known bug and it persists for at least a year now.
Sometimes even less frequent requests causes the bridge to stop working.

81

See above (Random "HTTP 503 Unavailable") in this topic:

82

In a few days it is Q4, can you be more specific with your time planning? I think the community would appreciate a few more deails because this bug annoys people now for nearly a year. Thanks!