Such things are usually made public in our official communication channels and not here in the forum. Launch date of MQTT API has been communicated as “in 2023”.
Question: I’m away from home and of course the lock is there sitting idle. Checking the MQTT server logs I’m seeing the following:
2022-12-21T14:23:16.135760953Z 1671632596: New connection from 192.168.38.67:52477 on port 1883.
2022-12-21T14:23:16.139606214Z 1671632596: New client connected from 192.168.38.67:52477 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-22T00:02:14.999744714Z 1671667334: New connection from 192.168.38.67:52480 on port 1883.
2022-12-22T00:02:14.999832547Z 1671667334: Client SL3P_3323C664 already connected, closing old connection.
2022-12-22T00:02:14.999859806Z 1671667334: New client connected from 192.168.38.67:52480 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-22T06:03:14.777978393Z 1671688994: Client SL3P_3323C664 has exceeded timeout, disconnecting.
2022-12-22T06:03:21.862273798Z 1671689001: New connection from 192.168.38.67:52483 on port 1883.
2022-12-22T06:03:21.862651573Z 1671689001: New client connected from 192.168.38.67:52483 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-22T06:16:08.681748086Z 1671689768: Client SL3P_3323C664 has exceeded timeout, disconnecting.
2022-12-22T06:16:28.807866095Z 1671689788: New connection from 192.168.38.67:52486 on port 1883.
2022-12-22T06:16:28.807960687Z 1671689788: New client connected from 192.168.38.67:52486 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-22T12:02:29.734042797Z 1671710549: New connection from 192.168.38.67:52489 on port 1883.
2022-12-22T12:02:29.734270851Z 1671710549: Client SL3P_3323C664 already connected, closing old connection.
2022-12-22T12:02:29.734350257Z 1671710549: New client connected from 192.168.38.67:52489 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-22T21:18:18.312125174Z 1671743898: New connection from 192.168.38.67:52492 on port 1883.
2022-12-22T21:18:18.312688076Z 1671743898: Client SL3P_3323C664 already connected, closing old connection.
2022-12-22T21:18:18.312774353Z 1671743898: New client connected from 192.168.38.67:52492 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-23T12:03:33.512318935Z 1671797013: New connection from 192.168.38.67:52495 on port 1883.
2022-12-23T12:03:33.512420008Z 1671797013: Client SL3P_3323C664 already connected, closing old connection.
2022-12-23T12:03:33.513159502Z 1671797013: New client connected from 192.168.38.67:52495 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-24T06:03:08.741965785Z 1671861788: Client SL3P_3323C664 has exceeded timeout, disconnecting.
2022-12-24T06:03:16.822219450Z 1671861796: New connection from 192.168.38.67:52498 on port 1883.
2022-12-24T06:03:16.822295338Z 1671861796: New client connected from 192.168.38.67:52498 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-25T03:52:56.699621394Z 1671940376: Client SL3P_3323C664 has exceeded timeout, disconnecting.
2022-12-25T03:53:44.654673024Z 1671940424: New connection from 192.168.38.67:52501 on port 1883.
2022-12-25T03:53:44.654754394Z 1671940424: New client connected from 192.168.38.67:52501 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-25T10:46:38.706316439Z 1671965198: Client SL3P_3323C664 has exceeded timeout, disconnecting.
2022-12-25T10:46:48.797231263Z 1671965208: New connection from 192.168.38.67:52504 on port 1883.
2022-12-25T10:46:48.797316521Z 1671965208: New client connected from 192.168.38.67:52504 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-25T12:03:24.009773752Z 1671969804: New connection from 192.168.38.67:52507 on port 1883.
2022-12-25T12:03:24.009851196Z 1671969804: Client SL3P_3323C664 already connected, closing old connection.
2022-12-25T12:03:24.009915306Z 1671969804: New client connected from 192.168.38.67:52507 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-26T06:03:02.733682281Z 1672034582: Client SL3P_3323C664 has exceeded timeout, disconnecting.
2022-12-26T06:03:41.114637768Z 1672034621: New connection from 192.168.38.67:52510 on port 1883.
2022-12-26T06:03:41.114798730Z 1672034621: New client connected from 192.168.38.67:52510 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-26T16:38:49.461421329Z 1672072729: New connection from 192.168.38.67:52513 on port 1883.
2022-12-26T16:38:49.461726326Z 1672072729: Client SL3P_3323C664 already connected, closing old connection.
2022-12-26T16:38:49.461848899Z 1672072729: New client connected from 192.168.38.67:52513 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-26T20:19:55.339217702Z 1672085995: New connection from 192.168.38.67:52516 on port 1883.
2022-12-26T20:19:55.339312071Z 1672085995: Client SL3P_3323C664 already connected, closing old connection.
2022-12-26T20:19:55.341078334Z 1672085995: New client connected from 192.168.38.67:52516 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-26T22:05:58.254681367Z 1672092358: Client SL3P_3323C664 closed its connection.
2022-12-26T22:08:51.001854848Z 1672092531: New connection from 192.168.38.67:52519 on port 1883.
2022-12-26T22:08:51.001951292Z 1672092531: New client connected from 192.168.38.67:52519 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-27T08:02:02.699334456Z 1672128122: Client SL3P_3323C664 has exceeded timeout, disconnecting.
2022-12-27T08:02:40.136739197Z 1672128160: New connection from 192.168.38.67:52522 on port 1883.
2022-12-27T08:02:40.136895622Z 1672128160: New client connected from 192.168.38.67:52522 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
2022-12-27T12:03:28.909520553Z 1672142608: New connection from 192.168.38.67:52525 on port 1883.
2022-12-27T12:03:28.909656403Z 1672142608: Client SL3P_3323C664 already connected, closing old connection.
2022-12-27T12:03:28.910221325Z 1672142608: New client connected from 192.168.38.67:52525 as SL3P_3323C664 (p2, c1, k300, u’nuki’).
Is that expected behaviour? Checking the logs it did not happen before (maybe because the lock was in constant use). It started disconnecting as soon as I’ve left
There is this remark in the API spec:
The reconnect mechanism for the Smart Lock 3.0 Pros WIFI connection is bound to
a successful connection to the Nuki server. i.e. you can not isolate the Smart Lock
from the internet as this will lead to reconnect attempts involving WIFI log off/ons
with exponentially growing downtimes in between. Likewise an unstable internet
connection can lead to MQTT reconnects and downtimes.
WiFi or internet connection drop outs are quite common. Especially for a low power, low data device. Your log looks pretty normal.
Will it be possible to adjust configuration over MQTT?
I would like to be able to switch Auto Open on/off on certain situations. My Home Assistant knows best what te situation is (how long have I been from home, was I by car or bike, are there any other people at home etc.) so it would be nice if HA can turn auto open on or off when I like to.
When I come at home by bike, I’ll go via the back door so there is no use for auto open. But by car it is.
Does nuki mqtt need port 1883 to work or can we change it? Background: I’m already using an instance with port 1883 and i don’t want to change the authentication in this instance as a lot of my smart home devices are connected without any authentication. So i have a second instance running on port 1884 for authentication only and i would like the nuki to connect to this instance instead of port 1883.
According to the latest specs, yes:
I read somewhere this will be changed in the final firmware release.
1 Like
Dear all,
This is a beta program, which means that the vendor wants to develop something for the future. You can be thankful for this openness. You yourself have the opportunity to read or see and understand, of course, this is here and there times a bit troublesome but the questions would then also answered! It is not about the productive operation of a single individual in a beta program. Anyone who takes the trouble to read through the specifications will find that Smartlock will deliver all valuable parameters via MQTT. What each individual then makes of it is his pot of beer! And who has HomeAssistant in use should know that he can then do what he wants!
It was already announced that the development will flow into the official firmware sometime this year and who would have simply read on there, who would now also know that, it will not be mandatory in the future to have a mDNS and thus the parameters for the MQTT server in the app will be customizable.
And also the demands regarding the bridge are for me zero comprehensible! There are other possibilities that you can already use. One should also leave a manufacturer the freedom to add something if he can take responsibility for it! You should deal with product liability and read for yourself what you write and demand, which would then have to be guaranteed. But you can not attach a condition because you bought a product in the past and expected something else. Why do you buy new smartphones, graphics cards, washing machines, refrigerators or anything else? Sometimes it would be nice if people would just think and maybe see themselves in the role of a manufacturer. Life and business is hard and in business you only survive if you can earn something with the further development! So you can be very happy and grateful that you are at all willing to add something and thus do something sustainable for our common world.
What is the reason of this long story of yours?
What additional answers are you giving which were not given before?
Who said he is not thankful for the efforts of the developers?
The reason for the longer story is the basic mood that resonates here in some contributions. Look around with pleasure a little bit it was not directed directly against you but rather a somewhat more general feedback to the community.
But let’s get back to the feedback of the beta firmware 3.5.5.
My experience with it so far is excellent the connection with MQTT seems stable and the communication runs very fast. I have the whole thing running in conjunction with HomeAssistant. In practical use, this is also felt much better than with the NUKI app because the APP always needs a little to check over which connection can or should be communicated. So far, I have not noticed any problems and I do not miss any information, so many thanks from me for this great job and the great expansion of the range of functions to @Juergen and his team.
2 Likes
Feedback for 3.5.6
My SL3 Pro sporadically does not respond for some time to “lockAction” event. It does however respond to the Simple lock action “lock” and “unlock”. Is there a safety precaution here how often a lockAction event may be executed or is a contact to the Nuki server required? Don’t understand why there are dropouts here today.
– After a hard restart, removing the battery and reinserting it, it works again.
Error or undefined what I noticed last already with 3.5.5:
-
for Simple Lock action “unlock” although knob is specified in the app, unlatch action is not executed. For API 1.3 is defined under point 3.5 that at knob an unlatch should follow. It is only unlocked then no further action takes place.
-
for “lockActionEvent” are obviously not all triggers under 3.7 recorded when opening via MQTT is given back to me as a trigger “172”.
Thank you for the feedback.
No there is no precaution. Could be a bug in the firmware. The firmware team will have a look at it.
It’s a bug in the current mqtt implementation. Will be fixed with the next beta release.
This has been added to the API some time ago, but the corresponding spec update was never released. It is contained in todays v1.4 spec though. MQTT API Specification v1.4
1 Like
Since fw 3.5.6 it apppears my lock doesn’t respond to the MQTT commands either, but for me it’s both lockAction and the simple lock/unlock topics. MQTT connection is OK, if I subscribe and change the lock from the Nuki app, it does show state changes and timestamps.
If the FW team needs anything tested or logs or something they can reach out. I am still impressed by the way you acted to the initial complaints of not being able to use the SL3P as a standalone device and am very willing to help you guys make this into a success.
1 Like
Dear Erik,
so you are still notified of the status changes via MQTT or only in the app? I have the 3.5.6 also in use with me it comes only sporadically to dropouts. As a workaround has helped me a hard reset so pull the battery. Have you already tried this?
I can confirm this behaviour. My SL3P initially did not respond to lock/unlock/lockAction commands on 3.5.6 but does after pulling the battery. Thanks for the hint!
I will report in case of future dropouts.
Mine shows the same behavior. On 3.5.5 everything was fine.
Taking out the battery helps. But after some time the problem occurs again.
Indeed, if I subscribe to MQTT topic with mosquitto_sub from my server and use the Nuki app or press the button on the lock, I will see updates so the MQTT connection itself is working. It is only sending commands to my lock through MQTT that is not working. I have tested with Home Assistant as well as mosquitto_pub and I do see those as well on the command line so it’s not a write permission issue or something like that.
@fritz_hh Missed your longer post from 2 weeks ago but I totally agree with you, it’s a beta, so things could stop working. It’s too bad that my automatic locking when going to bed doesn’t work anymore, but I can still use the app to lock the door.
A lot of people seem to forget that this functionality was created after requests from the community. Most companies will immediately shut the door for this kind of request and tell you to use their app instead. This fact alone makes me happy that I chose Nuki 
My SL3Pro has already automatically installed the firmware 3.5.7 
Since then, no more unlocks work or are no longer accepted by the lock when they are published via MQTT. I suspect that according to the API specification 1.4 the point 4.3 was implemented in the firmware.
How can I activate it now so that it works again as usual?
With this weeks release of Firmware 3.5.11 the MQTT API is now also available in the release firmware.
Provisioning through the Nuki Apps will be made available through subsequent App releases. Please follow the Apps Beta channels for further information.
If you do not want to use beta firmware for your Smart Lock anylonger, please opt-out of the beta by sending an E-Mail stating this to contact@nuki.io with your Smart Locks Nuki ID this week, as the 3.6.x beta is about to start next week.
1 Like
And how can you use the MQTT api without joining the Beta group?