Installed 4.2.1 Beta today and after the Update it first didnt connected to my Broker until I have removed the Battery. Since then no new malformed package errors in the Mosquitto Log:
2024-03-08T16:06:58: New client connected from 192.168.1.103:51951 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-08T16:06:59: Client Nuki_39C748EC disconnected due to malformed packet.
2024-03-08T16:07:51: New client connected from 192.168.1.103:49867 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
2024-03-08T16:08:26: Client Nuki_39C748EC already connected, closing old connection.
2024-03-08T16:08:26: New client connected from 192.168.1.103:51601 as Nuki_39C748EC (p2, c1, k300, u'loxberry').
root@loxberry:/opt/loxberry
We discovered another issue which can lead to the malformed packages problem. It only occurs if “Home Assistant auto discovery” is turned off. We therefore advise you to turn it on if you are using 4.2.1 beta. Issue will be fixed in the next beta.
Today my SL4P - running with Beta Firmware 4.2.1 - doesnt responded again to MQTT commands, although according to the Nuki App it was connected to my Broker:
I reconnected it manually (this time with “Home Assistant auto discovery” is turned on, even when I dont need this) and this time this immediately worked and MQTT commands worked again.
Update:
1 of the 2 locks with the new firmware (4.2.1) was unavailable starting 11-03-2024 01:35:59.
I needed to disconnect the power around 07:18:05 to get it working again.
Timestamps are from Home Assistant.
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!
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:
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:
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.
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.
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
