The bug is confirmed and will be fixed with the next beta release of the mqtt api.
1 Like
It’s just a bash script, I run it from my Debian server on which HA and Mosquitto run in Docker. As I mentioned, this was mainly a little helper for myself, which I shared so other people don’t have to reinvent the wheel.
With todays Beta 3.5.1 this is fixed:
With todays Beta 3.5.2 additionally this 2 things are fixed:
1 Like
I’m unable to do any further testing as my SL3 Pro wont connect to my WiFi anymore. Reported it in the existing thread on this issue with further info and a screenrecording.
My thoughts were based on separation of concerns. One part of my integration does react to the lock events. Another one, completely separated from the other, prepares the lock action.
But, on second thought, this wouldn’t be useful, because the only information to be transferred would be the requested lock action, not the source of it. No information of a trigger would be available.
I think i will prepare the event within my integration, therefore it is better that the lock does not send such an event by itself. So, please forget my remark.
Hi Jürgen,
I have been using version 3.5.0 and 3.5.1 for only some days (not very long, unfortunately) and they were fine. Now with version 3.5.2 I am having problems with my setup (SL3Pro, Loxone with Loxberry): sometimes it takes some time (minutes) to open/close the lock.
Also the wifi connection drops from time to time, so opening and closing events from Loxone are not executed (btw: will a connection to nuki servers be mandatory in the final version?).
These two issues are not necessarily related to another, but I did not recognize either of them in v3.5.0 or 3.5.1.
I cannot find any pattern for this behaviour currently. Hope this helps anyway…
I’m seeing the exact same thing. Connection is very unreliable without a real pattern. Could you read this topic and investigate if you see the same behavior.
I have 2 SL3P. One of them (haustuer) drops the connection every few minutes, the other one (keller) is quite stable.
Both are connected to the same access point with the same configuration (different ip addresses only).
The one (haustuer) which is dropping the wifi is connected with a door sensor, the other (keller) is not.
For testing purposes i deactivated the door sensor, removed the sensor and the battery.
(The first grep uses a misspelled “haustuer” to show only the “keller”)
I will exchange the locations now. (at ca. 18:40, dns-Names and Ip address will stay the same.)
First results from the exchanged locations:
- the same lock drops the wifi connection regularly. (Not available via the Nuki App, dhcp requests in log.)
Could this still be a firmware issue or is this a hardware problem? Should i contact support for a replacement? Anything else i could try?
I did not use the locks much before 3.5.x beta firmware, at least no features which require wifi. Just basic open/close with fob, sometimes with mobile phone. So mostly bluetooth stuff.
One bug for the mqtt beta: renaming the lock does not trigger a publish of the new name to the topic nuki/<lockid>/name. Once a republish takes place, the old name is still used.
The names of my locks (via mqtt api) stayed the same after renaming.
I then published the new name to the topic manually, which got overwritten with the old name some time later.
Thanks. 3.5.3 looks good so far. (I just upgraded the problematic one.)
No dhcp requests from the lock since about 20 minutes. Within the Nuki app both locks are available immediately.
I am facing the same issue… What changes have you done/tried to make it work? Thank you, M
Hi @Juergen
Well, seems to me I tried everything yet not able to make the mqtt running…
I have hased the wifi pass as described > the pass works well via other apps and devices accross my network…
My setup is running mqqt broker on raspi - I can easilly connect from orher devices and watch the communication… no issues there… i can ping both mqtt.local and mqtt from orther devices on my network and all works wel…
Watching the mqtt communication I see all devices connecting to/from and sending messages… Strange thing is that the Lock does not even try to connect to the mqtt broker… No input in the log at all… I have latest beta and debug enabled…
Is there anyway how to check the log from Lock to see wether it even tries to connect?
M
Hi,
I have added these 2 DNS records to my DNS server:
- host: mqtt
ip: 192.168.1.2 - host: mqtt.local
ip: 192.168.1.2
If I had only the second record, the Nuki can´t connect to MQTT server.
Which IP address you´re using in your network?
Hi @Petr_Maizner ,
Im on same IP range as you… 192.168.1…
Where exactly did you add your 2 DNS records? (Sorry for dumb question) Somewhere within router or on the machine running mqtt broker? Any/more hits more than welocome.
Thank you, M
Hi,
my Wi-Fi router can´t run DNS server so I installed Dnsmasq add-on to Home Assistant with these records in configuration:
- host: mqtt
ip: 192.168.1.2 - host: mqtt.local
ip: 192.168.1.2
and change my DHCP server tu use this DNS server as the first DNS in the network. The you must reboot your Nuki device to obtain new settings from DHCP. Thas´t all. The Nuki try to connect to MQTT server immediatelly after start.
But if you´re able to ping mqtt and mqtt.local, it seems that you don´t need additional DNS server. I installed the server because in my network the resolve of mqtt does not worked.
PS: in the add-on in HA you can check if the Nuki asked for the correct DNS mqtt record.
PS2: have you created in the MQTT server the user nuki with the SHA-256 hash of your WiFi password?
Yep, I did… and I can connect to the broker from different devices across my network with those credentials…
I run into the same problem, dns records are set but nuki was not able to find and connect. All other devices could resolve it. My workaround was to publish them.
Try:
avahi-resolve -n mqtt.local -v
If that will not work, try to publish your mqtt ip:
avahi-publish-address mqtt.local 192.168.50.220 &
Thank you very much. This helped and now everything seems to work 
1 Like