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).
Still no connection to the cloud. NUKI status shows no WIFI connection and no cloud but I have MQTT info in Home Assistant and I can open the door from there. I can not open the nuki remotely from the Nuki’s app because there is no cloud connection.
Ok, I upgraded SL3 Pro to 3.9.0 beta and this morning I disconnected my main router from the Internet for about 10 minutes.
Then I tested MQTT and it worked ok.
I will do a longer test as soon as I can
In our vacation home, which rarely has internet, I’m currently using the stable firmware version 3.8.7 for our Nuki Smart Lock. I’m hesitant to use beta versions in this setting, though I might consider them for testing at home. Since updating from version 3.7.x, the MQTT connection stays stable, but it seems the power pack uses a lot more energy. After just two weeks, the battery level has dropped to 50%, even though the door opener was rarely used. The Wi-Fi connection to the router is quite good with a signal strength of -47 dBm, so the high energy consumption is probably due to the integrated Wi-Fi, which always wants to connect to the Internet (just a guess).
To counter this, I’ve been using a Nuki Bridge for a week, which doesn’t support MQTT but has an API. Surprisingly, after 10 days of similar light use, the battery still shows 100%. Clearly, using the Nuki Bridge, which connects the Smart Lock via BT only, uses less power. I didn’t expect such a big difference. Ten days isn’t a long test period, and the main vacation season is just starting, but it will be interesting to see how the battery status holds up with more frequent use. I might also consider replacing the Nuki Bridge with an ESP32 with MQTT, as the Nuki Bridge solution seems too expensive for me. If it works well, I will also switch other Nukis to the nuki_hub.
Nuki Bridge update: The battery level is now at 98%. Messages can be received within the home network without internet access. However, the lock cannot be locked without a connection. I am now going to test the Nuki Hub…
Yesterday the nuki server was down a few times, but when it was offline mqtt disconnected i thought it should be stable even when the nuki servers are down? Did i missed something?
When there is a transient internet connection the Smart Lock will in some scenarios restart the full WIFI stack in order to make sure that all possible error cases are eliminated. This will also lead to an MQTT reconnect. Looks like you ran into such a scenario yesterday.
