Nuki SL 3.0 Pro should not disconnect Wifi when Nuki Cloud is unreachable, as this will break local connection (local API, MQTT, etc).
Features
Do not disconnect the Wifi due to unreachable Cloud Servers
Reason
Nuki SL 3.0 Pro is “health checking” the Wifi by connecting to the Nuki Cloud servers. If the Nuki Cloud Servers are not reachable, for example because:
there is a problem with the local Internet Connection
there is a problem with the Nuki Cloud
Internet Access is not allowed for the nuki device (firewalled or airgapped).
More details in the discussion:
This is a long solved problem in the Nuki bridge by pinging the default gateway:
Examples
I would like to use the Nuki SL 3.0 Pro with a local MQTT broker and a local Home Asssistant instance, even though:
my internet is down
my internet is flapping
the Nuki Cloud is unreachable for whatever reason not related to my configuration
my firewall does not allow access to the Nuki Cloud
Considering that for the price of a SL 3.0 Pro you can get a SL 3.0 + Bridge and spend less money, while at the same time not having to deal with this bug and the increased battery consumption due to Wifi, the 3.0 Pro does not make sense for me.
I have therefor returned the 3.0 Pro and will look for other solutions (3.0 + Bridge or even better 3.0 + the ESP32 solution).
Ah, this explains the problem I had last night, when unexpectedly due to a regional internet outage, my front door Nuki 3.0 Pro was unreachable via MQTT (and Homeassistant). My internet is rock stable, so I did not notice till yesterday.
Nuki, please fix this. MQTT does not require internet, just local TCP/IP.
In extension, it would be nice if there was an option not to need Cloud services at all, that MQTT parameter serverConnected could be and remain false all the time.
Indeed, I have no need for a Cloud connection at all, as said above, only local connection to my MQTT broker.
So when the SL3 can’t reach Nuki Cloud, it disconnects wifi? Seriously?
It’s amazing. Basically you have a lock with some local functionality but dependent on the cloud. A sort of frankenstein vendor dependent.
I’m always amazed about how some vendors fail to understand the importance of LOCAL control for automation, cloud control can be added as an extra functionality, but LOCAL should always be first priority.
Both my NUKI 3.0 Pro’s (two locations, two different networks) are down this morning.
Both have Built-in WIFI and MQTT configured.
Is anything at NUKI causing this downtime? Even If I delete MQTT, then delete the WIFI, then reconnect (to an SSID that is 2.4GHZ only, no special features) I see success in the NUKI app. But immediately after that, the NUKI disconnects again. I see the network name with a red cross in front of it. “Network not available. Please check your WI-FI connection”.
I have changed nothing on both networks. ALL other devices on both networks work fine. Only the NUKI on each network is down. Both NUKI’s lost WIFI connection since this morning. Nuki service status pages does not show anything to be down. Nuki Status Dashboard – Check the Status of Nuki Services
So this bug today caused two Nuki 3.0 Pro’s to go offline (6+ hours since they went down), and lose their MQTT connection. Both on different locations, connected via different providers and networks.
I just called support and they conformed issues with the online services, making Nuki’s drop their MQTT connection. I wasted a good part of my day, as all services are (still) green on Nuki’s status page.
This needs dealing with. A local service (MQTT) should not go down, because a cloud server is down (or unreachable). That’s just stupid. I can ping the lock on my Network, so WIFI is connected.
Nuki, this is an excellent example why this needs fixing as soon as possible.
Update:
At least the status page now reflects the problems:
I just came here to check if there is a bug with NUKI, since it’s unavailable via MQTT. This is unbelievable and should be fixed ASAP. I have a full local setup and it should work despite servers down
Today, we experienced a multi-hour outage of the Nuki servers, resulting in the inability to control the Smart Lock via MQTT, even within our own WLAN. However, it’s important to note that MQTT only requires a local TCP/IP connection and does not rely on the internet. I believe that a Smart Home system should function within the local network independent of the manufacturer’s servers.
Nuki is one of the best Smart Locks I know (aside from the loud motor noise), and I appreciate the implementation of MQTT functionality. Nonetheless, I cannot comprehend why Nuki does not seem to understand or acknowledge the importance of LOCAL control for automation. While cloud control can be a valuable additional feature, LOCAL control should always be the top priority.
I assume everybody affected by this issue (disconnect local MQTT when internet of Nuki cloud servers are down) has actually upvoted this issue, so Nuki sees how many people want this issue fixed?
If not, See the big yellow VOTE button at the top left of this page? Please click on it
Well, the IONOS Cloud in Frankfurt was still having issue, apparently new issues even today:
Since 08:05 CET (07:05 UTC) we are experiencing similar behavior, access to our services is restricted.
We again have to deal with a major disruption at one of our colocation partners.
Our specialists are investigating this new occurrence with the highest priority.
Posted 12 hours ago. Nov 09, 2023 - 08:43 CET
I wish Nuki would use more than a single IONOS Cloud region for their services.
I would also urgently suggest to make the MQTT API available in a completely local scenario (without the NUKI lock talking to any server on the Internet, just local to the MQTT server).
