Should be the latest version of your script, but please check it once it’s released.
1 Like
I’ve just upgraded to firmware 3.5.8 and payloads are not from the last version, in fact these are the topics from the first version I published 2.0.0 when last version is 2.1.
My fault with these two version where format could be confusing and for all the changes I submitted in a short period.
Thx, with 3.5.8 MQTT is working again 
As far as i see the only difference is the “nuki_” prefix for the uniq_id. Correct?
Working with 3.5.8 thanks
It is one of the differences yes if we talk about all entities unique_id, there is also a difference in the template to determine if it is unlocked, I reverted to consider unlatching and unlatched as unlocked particularly because there are consideration to implement these state one day in Home Assistant.
Device id (ids in device section) also has nuki prefix.
EDIT: removed last point as I was wrong about abbreviation which are implemented since version 2.0.
Original post has been updated with release notes for the Smart Lock 3.0 Beta 3.5.8.
Please install this beta and share your experiences in terms of stability, the MQTT API (beta) and the availability of the Home Assistant Auto Discovery via MQTT here.
1 Like
Since 3.5.8 I noticed connection issues.
It has happened some times before but now it is really more frequently.
I made a pastebin with anonymized data and only Nuki related to avoid having too much lines:
https://paste.debian.net/1270099/
My Wi-Fi network is made with 4 TP-Link Deco M5, there is an access point in the same roomm the smartlock is in, I even tried to disable mesh for the smartlock using the Deco app without success.
I checked the Mosquitto log, before the update to 3.5.8 connection was really more stable.
Taping seven times on Network in the Nuki Android app shows Wi-Fi signal is 4.
And it looks like the smartlock really disconnect as I cannot see its state using the Android app sometimes for some minutes.
I can of course open a support ticket specifying I posted here if it could help to diagnose.
Since 3.5.8 I have problems with Lock ‘n’ Go.
With every Lock ‘n’ Go action, whether via MQTT or button, Smart Lock ignores the door sensor. After 10 seconds (the default value of 20 seconds in the app is enabled), the door will be locked, whether the door is closed or open. The door sensor status is displayed correctly in the MQTT. A bug ?
since 3.5.6 I have issues using the https webhook: sometimes the lock starts closing again while door is still open - sometimes only 360*, sometimes 720*, then sometimes lock responds as blocked what isn‘t the case as door is already open. There is no pattern, calibration doesn‘t help, no difference with 3.5.8
Original post has been updated with release notes for the Smart Lock 3.0 Beta 3.5.9.
Please install this build and share your experience, especially if you are using the MQTT API beta. Any feedback is highly appreciated.
1 Like
I have been experiencing connection drops all day since the update of 3.5.9. I’ll remove the battery when I get home (i monitor the connection status through Home Assistant) as this has worked before in solving connection issues.
But it seems to me that this it something that should not happen after a firmware update. It’s OK for beta versions but is this something that Nuki is aware of? Don’t think you want that happening on stable.
I’ve also been observing MQTT/Home Assistant-related unavailability with my SL3P with firmware 3.5.8:
On Feb 11 it lost connectivity to Home Assistant and has been displayed as unavailable:
Could it be that the timestamp published via MQTT is not updated when the lock is not actively triggered via the app so that HA considers it stale?
This only changed after unlocking through the Android app today. WiFi connectivity (via an UniFi U6 Pro AP) has been stable all the time, though.
Using Mosquitto as MQTT broker.
Currently updating to 3.5.9.
Removing the battery indeed fixed the connection drops again. As mentioned this shouldn’t happen though. If there is anything I can do to help identify the issue, please let me know.
The issue described above is something else. In my case the actual WiFi connection was unstable. Everything with MQTT is working fine for me.
So far the lock stayed online and available in HA.
It requires one lock/unlock command after restart in order for the Battery report and auto-detection to properly work. Maybe that’s the reason for the error message.
Updated to firmware 3.5.9 aswell. Lock connects to wifi according to the wifi stats. But it’s not connecting in the app…
1 Like
Got my SL3 Pro today, requested the beta firmware, got it within a few hours. Installed it and because I already had (coincidentally) a mqtt.local domain registered for my broker, it got registered in my HA immediately:)
All working perfect until now, very fast with the lock responses and also when manually locking, the status gets reflected within a few seconds in HA.
Thanks!
Edit: after about 18 hours, I also have my first Wifi disconnect. It was quite hard to get it connected again (after taking out powerpack etc.).
Are there any debug logs I can share from the SL3 perspective?