Something is not working correctly regarding the door sensor.
Although the door sensor is removed now the mqtt api still reports it as closed. It should show a different state. From the description either “4-door state unknown” or “1-deactivated”.
Looks like 2 seperate problems:
-
We found a bug in the MQTT API implementation in 3.5.0: Manual lock actions (key or knob) are not properly handled. This leads to them not beeing reported and/or even the Smart Lock dropping the WIFI connection for a few minutes right after a manual lock action. We already have a fix for it which will be included in the next beta.
-
The Door sensor is not permanently connected with the Smart Lock. If you remove it, the Smart Lock only knows that it is removed if the door sensor reports that to the Smart Lock (which is what it does when it is powered and you take it off the door) or if there is no update from the door sensor for >24h (the door sensor sends every day at least once an update). → i.e. it might take some time until the state changes if the door sensor simply runs out of power. But we’ll have a look at the behavior of the MQTT API when the door sensor is removed.
Thanks for the insight. But i am just talking about the inconsistency between the other interfaces and the mqtt api.
All other interfaces show the door sensor as removed except for the mqtt api.
I removed the door sensor yesterday and since then all interfaces except the mqtt api show it as removed.
The door sensor reports a state of 240 via the mqtt api approximately 28 hours after the disconnection.
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