In my case the reason for this where the malformed packages, which was fixed/workarounded with Firmware 4.2.1.
Now the Connection is way more stable and when the problem of not accepting MQTT commands is occuring again, an manuell reconnect or battery pull/push will resut in an immediately successfull reconnect.
Long Story short, for me (as an Thread opener) the core / “nightmare” problem is fixed, thanks!
@Juergen Hi, good morning. Bad news: after about 60 hours i got again disconnection.
Mosquitto logs:
1710148006: Client Nuki_xxxxx closed its connection
So in my case 4.2.1 does not solve the issue 
Before to buy nuki 4 pro i had nuki 3 pro for 12 months and i never never never got any disconnection
@Juergen, MQTT Commands are not handled again from the Nuki even with 4.2.1 beta:
Again Confirmed: MQTT Reconnecting via App triggered (although Nuki App and my Tracking/Monitoring said MQTT is still connected [1] ) and the SL4P is immediately accepting MQTT commands again:
[1]
According to our logs, the message arrived at the Smart Lock and was denied because of
lockAction = 30
was sent. Your screenshot also says 3.000. Maybe there is a problem with the “.” and how the numbers are sent in general and/or interpreted by the Smart Lock. Can you please DM me the pcap from your screen shot?
Great that we have a confirmation that the TCP MQTT Package was received from the Nuki and that we have a Logfile entry with the reason. I didnt have updated the MQTT Broker|Mosquitto recently so I dont know, why it is sending sometimes an i.e. 30 instead of 3.
Update: According to the Payload the Broker has sent an 3 and not an 30:
The 3.00 is just the Number from the Loxone Output I am Monitoring, and not the MQTT Command.
I tried it but I get…:
Sorry, the file you are trying to upload is not authorized (authorized extensions: jpg, jpeg, png, gif, heic, heif, webp, avif).
…thus I have sent you an Google Drive Link.
Yes, looks like that. We think we found the problem and are currently testing it. Will be included in the next beta. There is no workaround for the time beeing.
Hi Jürgen,
my nuki don’t show the beta update! I still in hang on 4.2.0.
I try to reset completly my app and lock but nothing works.
can you give me a suggestion? what can I check?
Thanks
Luca
Installed beta 4.2.1, but after 24h or so the lock doesn’t respond to the MQTT orders from Home Assistant. The auto discovery is on. The only difference with new fw is, I can open the MQTT settings, enter the password and it works again for 24h. So fw 4.2.1 doesn’t fix the issue for me.
Update:
The second lock is not available in HA anymore.
Also in the Nuki app offline.
Best regards,
Jacob
Same procedure, now it lastet arround ten hours until I noticed, that MQTT Commands are not working and I had to manually reconnect my Broker again.
I’m note sure but…i have to report this.
I assigned into my router settings a static ip to my Nuki smart lock and It Is 3 days that i havent issue…
I Will update you if i get a disconnection or not in next hours/days
Yes, same problem as last time. And …
I have installed the brand new 4.2.3 beta this morning and during the day, I noticed a few times that my SL4P was not responding - My Broker also noticed this and I had again to reconfigure the MQTT Connection within the Nuki App: After that everything was fine again for a unknown amount of time.
Will Monitor it and update this Thread accordingly.
root@loxberry:/opt/loxberry# grep Nuki_3 /var/log/mosquitto/mosquitto.log
2024-03-15T13:02:56: Client Nuki_39C748EC already connected, closing old connection.
2024-03-15T13:02:56: New client connected from 192.168.1.103:52434 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-15T13:25:44: Client Nuki_39C748EC has exceeded timeout, disconnecting.
2024-03-15T13:35:46: New client connected from 192.168.1.103:52434 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-15T14:48:26: Client Nuki_39C748EC has exceeded timeout, disconnecting.
2024-03-15T15:46:56: New client connected from 192.168.1.103:52433 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
UniFi WiFi Report:
2024-03-15T16:05:15: Client Nuki_39C748EC already connected, closing old connection.
2024-03-15T16:05:15: New client connected from 192.168.1.103:52434 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
And again:
root@loxberry:/opt/loxberry# grep Nuki /var/log/mosquitto/mosquitto.log
2024-03-15T13:02:56: Client Nuki_39C748EC already connected, closing old connection.
2024-03-15T13:02:56: New client connected from 192.168.1.103:52434 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-15T13:25:44: Client Nuki_39C748EC has exceeded timeout, disconnecting.
2024-03-15T13:35:46: New client connected from 192.168.1.103:52434 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-15T14:48:26: Client Nuki_39C748EC has exceeded timeout, disconnecting.
2024-03-15T15:46:56: New client connected from 192.168.1.103:52433 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-15T16:05:15: Client Nuki_39C748EC already connected, closing old connection.
2024-03-15T16:05:15: New client connected from 192.168.1.103:52434 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-15T16:38:32: Client Nuki_39C748EC has exceeded timeout, disconnecting.
root@loxberry:/opt/loxberry#
Thanks. Please do not send any more updates. From looking at the logs it’s pretty clear why you are seeing the reconnects (and it’s most likely not coming from changes on MQTT side, but the many updates that happened in this build for Matter 1.2 support). This requires an investigation by our team which will not happen over the weekend. 
I have also the issue with fw 4.2.3. It happened, while the lock stops responding to the command from Home Assistant, it executes the command, when I open the Nuki App and keeps working for some time, until it stops again…
The same here
Same issue for me