Local MQTT connection fails there is no connectivity to Nuki Cloud Servers

Discussion
#1

Hello,

I have a Nuki 3.0 Pro, it connects to a MQTT Server on my local LAN, which is talking to my local Home Assistant.

I noticed that Nuki is “health checking” the Wifi Connection by connecting to the Nuki Cloud. If the connection to the Nuki Cloud fails, Nuki 3.0 Pro will disconnect from the Wifi.

Of course when Nuki disconnects from the Wifi, MQTT also stops working and my local Home Assistant cannot communicate with Nuki anymore.

I’m pretty sure the other local integrations like Homenet or the Bridge HTTP-API suffer from the same issue, when Nuki rejects or disconnects the Wifi due to lack of Cloud connectivity.

I would like to do reliable local controlling with MQTT/Homenet/HTTP-API, but:

  • not depend on the spotty internet connection of my place
  • not depend on cloud servers by Nuki (I would prefer Nuki to not connect to the Cloud at all, I don’t need or want any of the Cloud features)

I think this would be an important improvement.

This was considered a bug in the Bridge:

Thanks!

Nuki 3.0 Pro looses connection despite AP is next to it
SL3 Pro: do not disconnect Wifi when Nuki Cloud is unreachable, breaking local MQTT and other protocols
#2

If you want a new feature, please create a feature request and start collecting votes for it. Before you do that please check if there is already an existing one.

#3

In 2020 you considered this a bug when it was happening on the Nuki Bridge as per the thread linked above.

I understand you have a lot of roadmap items, I just think this is something a little more important than a specific, exotic and optional feature.

2 Likes
#4

I filed the feature request here:

1 Like
#5

I have just voted for your feature request. Can’t even imagine this should be a feature. Imho this is a bug. Otherwise the whole MQTT seems useless, because there is still dependency on the cloud. For me a reason to go for another product if it stays like this.

1 Like
#6

Is it easy to ‘spoof’ this behaviour or is it a complex call which is made to a random cloud server?

#7

Those are HTTPS requests to sse[0-9]-smartlock.nuki.io, all in the IONOS Cloud.

And ICMP unreachable in response to the SYN will lead to a timeout so it takes a few retries before Nuki ultimately times out and disconnects from the Wifi.

When a TCP RST is returned, Nuki disconnects from the Wifi within a few milliseconds.

I did not try to respond with my own HTTPS Server. I’m not really interested in workarounds on my site, because I consider that this is something that is either a core design principle, or the product is not what I’m looking for at all.

I have returned the 3.0 Pro at this point and will use a normal 3.0 with the ESP32 integration, which as far as I can tell is really well made.

Then I have a solution that actually fulfills my requirements without Cloud enforcement and I have about 100€ left to spend on nice things.

#8

Hmm… I can get my hands on a N3P for 189€ new. So that’s including the battery pack.

I totally agree that this should be core functionality. It should be able to ping the local gateway and that’s it (or a check of MQTT is connected).

Maybe I buy the N3P and still use it with the esp option, but this is a really bad design choice (bug). Food to think about.