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?
By activating the debug mode of the Smart Lock. Read the MQTT specification for more information.
- I’ve an SL3 Pro, Wifi ist connected, Firmware 3.5.11.
MQTT API V1.4, Section 2.2 and 2.3 refers to a “Nuki Apps Device Administration
MQTT section” - what has to be done to activate that, I do not see such a section.
(Debug-Mode is enabled)
- according to Section 2.3 “The reconnect mechanism for the Smart Lock 3.0 WiFi connection is bound to a successful connection to the Nuki server. i.e. you can not isolate the Smart Lock from the internet”.
Why is a connection to a server necessary to connect to my local WiFi ? Are there plans to remove that ?
The section is not yet in the app, so the hard-coded server method has to be used.
If I understand correctly, debug mode won’t have to be enabled ass soon as this section will be added in the app. But for now it has to be enabled and it is the first step to connect to your broker, which has to be resolved as mqtt.local (MDNS) or mqtt (DNS) with user nuki and password as SHA256 of the configured wifi key.
Because the current - very power efficient - (re)connect logic uses the connectivity to the Nuki server to judge if the full IP stack is operational and will restart different layers if this is not the case. Seperating this into independent entities (e.g. lan, mqtt, remote connectivity) is not trivial and has therefore been taken out of the scope of the mqtt api. We do not comment about our roadmap here in the forum, therefore i can’t give you any details about future developments.
1 Like
