Of course.
Mqtt worked fine with 3.5.5 and 3.5.6.
After flashing to 3.5.7 it stopped working.
Nothing has changed since on the broker side.
Looks like my question was not formulated correctly 
which method do you use to make your MQTT found by your smartlock? MDNS or DNS?
I used MDNS.
Same here 
3.5.7 contains elements of the final provisioning implementation. Maybe that’s the reason. We will have a look at it on Monday.
2 Likes
Firmware auto update was not disabled
MQTT broken too.
Nightmare comes back…
1 Like
If you are affected by MQTT connection problem, please turn off debug mode of the Smart Lock until there is a new update available.
1 Like
Same here
Would be nice to have release dates for the versions - easier to correlate behaviors with specific release
Please can you propose 3.5.6 as update or can you tag the old 3.5.6 as 3.5.8 if downgrade is impossible?
I cannot control my doors anymore and I cannot have an online quickview on their states, it’s critical.
3 Likes
We were able to reproduce and fix the problem. There will be a new release tomorrow (which also contains HA auto-discovery).
6 Likes
Good news! Which payloads will be used for HA auto-discoveries?
Because I am aware I proposed some updates after the timeline…
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 ?