Random "HTTP 503 Unavailable"

[parsaria (SeyedGH)]

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.

[Juergen (Jürgen Pansy)]

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

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

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

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.

[aqualx (Oleksandr Kurbatov)]

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.

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

[Juergen (Jürgen Pansy)]

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

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

[Juergen (Jürgen Pansy)]

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

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

[christianTF (Christian Fenzl)]

Nuki Bridge MQTT Support

Product name Nuki Bridge Summary Support MQTT binding for status and commands Features Basics: Topic base configurable Subtopic Bridgeid Subtopic Nukiid LWT for Bridge State Broker Hostname:Port opt. Authentication Payload may be plain or json Publish Nuki status: Locked/Unlocked state Door open/closed state Bridge online state Nuki online state Commands Lock/Unlock commands from the Bridge API Possibly all the commands from the Bridge API The MQTT settings may be configured via the A…

[benzman81 (Markus Krüger)]

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.

[parsaria (SeyedGH)]

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

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

I am so happy that there is a http api available at all, so dont blame them for restrictions.

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.

[aqualx (Oleksandr Kurbatov)]

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

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…

[parsaria (SeyedGH)]

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

Theoretically possible after the structural change. But HTTP API needs to remain because of backwards compatibility.

[darkwinter (Vincent)]

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

[Stephan (Stephan Lendl)]

Is it planned a new version of the bridge firmware

see above:

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.

and also:

the bridge can handle only one connection at a time and if you don’t serialize at your end the API will always throw 503 errors

[zoli]

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!

[zoli]

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.

[Zefau]

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

[noniq (Stefan Daschek)]

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
    }
  ]
}

[zoli]

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.

[Stephan (Stephan Lendl)]

If so, is there a firmware update planned to fix it?

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

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.

[locke987]

If so, is there a firmware update planned to fix it?

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

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.

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!

[Stephan (Stephan Lendl)]

Sorry, but we can’t give a release date until we are 100% sure it will hold.
As soon as a beta is available it will be posted in this forum for interested users.