I think if the lock is turned one (360) or two times (720)
2 Likes
Hello,
thx for your answer.
I’ve read the document and it states the following which brought me to conclusion that I’m doing something wrong:
2.2 Provisioning
Provisioning of an MQTT server is done via the Nuki App in the Device Administration >
MQTT section.
It allows users to enable/disable the API, enter the credentials (username & password) and a
hostname or IPv4 address for the MQTT server.
In addition Home Assistant Discovery (Default: on) and “Allow Locking” (Default: on) can be
activated and deactivated.
Edit:
Nevermind, I just read this post again by Juergen again and it’s a “draft”, not yet implemented feature in the beta version.
Sorry for this confusion.
Correct. Full lock will always lock 2x (720), even if 1x (360) is selected in settings.
Ideally the platform (HA) can deal with those transition states. But in any case they should be optional and things should work without as well, because not all locks will have them and even the Nuki integrations via bridge API won’t have them. Not sure how HA deals with such compatibility requirements.
Yes, it will work without transitioning state. HA will report locked and unlocked, that’s all and durring transitional states the previous state will stay set as actual.
Because these transitional states are available with MQTT API, I think it could be good to have these information in Home Assistant even if Bridge integration does not provide these.
Finally this PR is only for locked and unlocked but I am also working on jammed state which is also not available with bridge integration but this state would be really useful if it could be implemented using MQTT.
If it is not, no issue with HA, same as I told about locking and unlocking, if motor is blocked when previous state for HA was locked the state will still be locked.
Maybe my suggestion arrives late but I did not know this script would be the base used by Nuki for HA auto-discovery, else I would have made it sooner and more for other point I disagree with this configuration, for example using lock name for unique ID which does not look reasonable in my opinion, IDs should not be set using an information which can change.
The choice for the script was because there seemed to be the consensus “that there is only one way to represent a Smart Lock in HA” in the Home Assistant MQTT auto-discovery implementation requirements topic. This maybe got lost because the topic went a bit off-topic …
Anyway it’s late, but not too late yet. Please contribute directly to the script on git (or at least write down all changes in the HA discovery topic) and we’ll add it to the requirements. Thank you.
1 Like
Hi there, is there a recommendation for a broker? Mosquitto seems to only accept SHA512, unless I am mistaken.
Thanks for your reply. I’ve made two PR on @MattDog_06 script, one for the IDs and other for typo which does not concern directly MQTT auto-discovery.
Now locking and unlocking have been merged, I’m going to make a PR also for that and will do so as soon as jammed will be supported.
What do you mean exactly?
A document with all MQTT topics and payloads for HA auto discovery?
Hi,
Mosquitto works well.
The sha256 is the encoding to use to generate the MQTT user’s password, create a user with login nuki and the password is your wi-fi key encoded using SHA256 so will be the same for any MQTT broker.
Or your question was about something else?
Hi Patrick, I appreciate the response.
Mosquitto uses SHA512 by default and I haven’t found an option to use SHA256. So do you simply add a SHA512 hash of the SHA256 of your WiFi password? Or a SHA512 hash of the WiFi pw?
I might overcomplicate things, so I’d appreciate any guidance you may have.
Yes. Just read the API spec in the top post. There is an example how to derive a string with the sha256 hash of your wifi password. Then you simply set this string as password for the nuki user on the mqtt broker.
1 Like
To make your changes either on git or write them down here in the forum.
You made them already on git, so everything is fine. Thank you.
@mattdog_06 do you think you could find some time to review my pull requests?
@Juergen another question comes to my mind even if I have an idea of the answer.
When the smartlock is jammed, we have the payload state 254 published.
But I don’t find any specific state when it is no longer jammed. So should we consider all is OK on next locking/locked/unlocking/unlocked state?
Because for jammed state, Home Assistant will expect two payloads: one for jammed and one when motor is OK. If my suposition is right it could be implemented this way but I prefer asking to be sure all is right.
EDIT: in fact if it could be possible to have a state when the lock is no longer jammed it would be helpful because the implementation will be as follow: there will be one topic for lock state:
- locking
- locked
- Unlocking
- unlocked
- jammed
- ok
But lock states will be treated independently from jammed state so even if the state change for example to unlocking, if no OK state as been received the lock will stay jammed.
EDIT2: pull request on Home Assistant has been adjusted by author: if no unjammed payload state is defined, any state other than jammed will change jammed state to unjammed. I hop it is OK.
Motor blocked is a transition state. It occurs when the motor of the Smart Lock is stuck before reaching the target position. The Smart Lock will transition to either locked or unlocked a few seconds later, depending to where the bolt really is. If you map jammed to motor blocked (254) it will obviously behave exactly the same. If you map jammed to also boot run (253) and undefined (255) its slightly different and won’t have such a strong transitional behavior any more.
If the lock command was initiated by the MQTT API there will also be an error code sent via the commandResponse topic.
Yep, makes sense.
About Home Assistant auto discovery, will it be republished when smartlock is renamed in the Nuki app?
In fact are there some case topics will be published again?
For the smartlock name it will be useful because if the name is not changed from Home Assistant interface, it would allow to also make the change in Home Assistant entities and device.
So the name should also be changed in the device information,.
Also are some people interested in having version information (firmware and why not smartlock version so only 4p for now)?
Because the script and even my fork does not set these information.
Yes. The Smart Lock will also republish them with every connect to the MQTT server.
Some services (e.g. door sensor, keypad battery) will only be published when the respective accessories are installed.
1 Like
My last questions about Home Assistant auto-discovery, are you also interested in publishing hw/sw version?
And what about a Full lock button?
If so I can add it to the script.
It would be nice to have more feedback from HA users because for example, some entities can be also disabled by default but published to be enabled by user in HA UI.
@Juergen if all addition should be stopped now it is OK on my side, ideas I suggest in this post are only some thoughts I have with all possibilities Home Assistant MQTT auto-discovery offers and I am aware I asked at the end of the original timeline. Essential is here IMHO and for example the full lock buton could also be added using YAML, about version info it is not a must of course 
For me it depends,
If there is an option as well through MQTT like a message to start updating to latest version, than yes.
Like to Home Assistant Update Card that i can see which version is running on the SLP3 and which is the latest one, and if there is a newer one, send a command with MQTT to go and update itself.
But if only showing your version, without knowing if there is an update or we cant do anything with it, it is not that useful for me.
Another point (more technical) came to my attention. Should we prefix IDs with nuki to avoid duplicate if another MQTT device is published and which would have the same ID?
Probability looks very low but I would like to have some advice to avoid future issue.
EDIT: I done it for each topic so I am going to publish the last version and won’t touch anything else to also prefix unique IDs with nuki_.
I hop memory constraints will be OK with payloads a little long like these.
For people using the forked script, I also added a remove_lock to the python_script service if you want to make the update because it will fail without a remove before.