MQTT API Specification v1.4

[Juergen (Jürgen Pansy)]

@tgaywood

Does that MQTT / ESP32 integration expose (to Home Assistant) HOW the lock was unlocked / locked (e.g. auto / keypad / manual)?

No it does not.

This discussion is also off topic in the SL3P MQTT thread. Please open a seperate topic if you wish to discuss about the ESP32 module.

[alexdelprete (Alessandro Del Prete)]

@tgaywood

Does that MQTT / ESP32 integration expose (to Home Assistant) HOW the lock was unlocked / locked (e.g. auto / keypad / manual)?

Did you check the repo?

[alexdelprete (Alessandro Del Prete)]

@Juergen

No it does not.

Yes it does.

@Juergen

This discussion is also off topic in the SL3P MQTT thread. Please open a seperate topic if you wish to discuss about the ESP32 module.

You’re right, it’s better to have a separate topic.

UPDATE: opened a new topic here.

[ZoloN]

@Juergen

Yes, problem is identified and will be fixed in an upcoming firmware update (most likely 3.6.2).

thanks!

[peter_pan]

Hi Jürgen, is it possible to pull a request for state of my Nuki smart look? I want to have this when I sometimes need to startup my node red server after a maintenance. Now I have to wait until a state change, but with triggering a pull request I get all data over the device. If this exists, what I can’t find, can you give me the syntax?
Thanks
Per

[Tommy11 (Tom)]

Hi @Juergen,

Any plans to support MQTT encryption or at least add an ability to prevent unlocking via MQTT - similar to the granular permissions you can have over API?

Thanks

[Juergen (Jürgen Pansy)]

It’s all in the forum. Just search or read through the topics.

@Tommy11

Any plans to support MQTT encryption

Home Assistant MQTT auto-discovery implementation requirements

We currently do plan to integrate auto-discovery but we do not plan to make the auto-discovery topic changeable. Is it common to change it? Somehow related, but a bit off topic is the problem that we can not offer secure MQTT because of memory restrictions that we run into with the SSL connection. If the memory restrictions are resolved in a future product, we would still use it without certificate pinning. e.g. no uploading of a custom certificate is supported.

@Tommy11

prevent unlocking via MQTT

Home Assistant MQTT auto-discovery implementation requirements

We agree with that view and will implement a setting to “Allow Lock Commands” through MQTT (Default: On).

[Juergen (Jürgen Pansy)]

@peter_pan

is it possible to pull a request for state of my Nuki smart look

You don’t need that. states are retained by the MQTT server. I.e. whenever you connect to the server you will receive the latest state that was sent by the Smart Lock to the server.

[Tommy11 (Tom)]

Hi @Juergen ,

Thanks for your answer.

Just to clarify the second part regarding prevent unlocking.
I’m aware to the “Allow Lock Commands” toggle. I was referring to more granular permissions. My use case is to allow locking via MQTT but prevent UNLOCKING due to security concerns.

P.S. - It’s 2 days since I have added the MQTT and it seems that the WEB API (used by google assistant) is having a lot of connectivity issues since then. Are you aware to such issue?

Thanks again.

[ZoloN]

hallo Jürgen,

@Juergen

Yes, problem is identified and will be fixed in an upcoming firmware update, most likely 3.6.2

got FW 3.6.9 and I can confirm, the autolock messages are send out via lockActionEvent, code “2,6,0,0,0”

/MfG
Zoltan

[mpeterson (Michel Peterson)]

Hey, I added the door sensor to my setup and noticed that HA auto-discovery is not published for it even though it is part of the 1.4 spec. I think there might be a bug related to adding it after MQTT has been enabled? Deactivating and activating MQTT fixes this.

Lock FW version: 3.6.9
Sensor FW version: 1.1.2

(I did a quick search on this post to see if was already brought up and couldn’t find any, I’m sorry if I missed this)

[RomanSch90 (Roman Sch)]

Hi all,
has anyone achieved to request the BatteryChargeState proactively? I am using nodered with a mosquitto mqtt. I am able to send messages to mqtt to lock and unlock my Nuki but I am not able to get the BatteryChargeState back from it. What do i need to pass to the mqtt to make Nuki answer with the right battery charge state?
Thanks.

[giejay (Gert Jan)]

I have the same issue, anyone know a fix?

[Juergen (Jürgen Pansy)]

@RomanSch90

What do i need to pass to the mqtt to make Nuki answer with the right battery charge state?

You can not send a message to ask for a battery state. The battery state is published by the Smart Lock in regular intervals and as it is retained you will always get the latest value when you connect to the mqtt broker and read the nuki/nuki_id_in_hex/batteryChargeState topic.

[RomanSch90 (Roman Sch)]

But how do I read it? What do I need to send to the Mqtt? To return it. The topic is clear. But when I just send the topic nothing is returned to me. So I expect that I have to send something as a message.

[Juergen (Jürgen Pansy)]

You just have to subscribe to the topic. Maybe this helps: What are Retained Messages in MQTT? – MQTT Essentials: Part 8

[Peter_Kornalsky]

Can anyone help me to figure out what am I doing wrong that my commands over mqtt does not work. I am running my own broker. I see that device connects but when other client publishes command to unlock it almost instantly drops connection. I had a moment, when it started to work with lockAction command (5 commands went through successfully after calibrating my lock). But suddenly, it stopped working again without obvious reason.

I followed v1.4 specification and I have already successfully implemented mqtt connectivity with other products and never run into such problems.

What am I doing wrong? Is there some way to read some traces from lock why the connection has been dropped? Is this feature still in some kind of Beta, because app is not mentioning any Beta word?

A bit of my traces:

– here I see it subscribes to lock and unlock actions
2023-07-08 13:27:13.8998|17656|61|TRACE|Hub|Client Subscribed: SL3P_AABBCC99, nuki/AABBCC99/lockAction
2023-07-08 13:27:13.8998|17656|60|TRACE|Hub|Client Subscribed: SL3P_AABBCC99, nuki/AABBCC99/lock
2023-07-08 13:27:13.9981|17656|62|TRACE|Hub|Client Subscribed: SL3P_AABBCC99, nuki/AABBCC99/unlock

– here different client send the command.
2023-07-08 13:27:45.7581|17656|68|TRACE|Hub|MQTT Client Publish: Topic = nuki/AABBCC99/unlock, Payload = true
2023-07-08 13:27:47.4382|17656|74|TRACE|Hub|MQTT Client Command: waiting…

– lock does nothing and reports connected, false
2023-07-08 13:27:48.2135|17656|81|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, nuki/AABBCC99/connected, false

[Thomas_Claes]

Hi Peter,
checks the client ID used by each device/user. If the client ID is the same, every connection and action by one client will disconnect another.
If the Client IDs are different, which should always be the case with an mqtt broker, you shouldn’t have this behavior.

regards,

[Peter_Kornalsky]

Hi Thomas

clients has different ids:
– device is connecting under SL3P_AABBCCDD:
2023-07-17 17:44:48.4304|15996|26|TRACE|Hub|Client Connected: 192.168.100.113:52464, SL3P_AABBCCDD, V311

– client which sends command goes under (2e3e17a0b1e7449b913e6cf16cde97ee):
2023-07-17 17:46:20.7830|15996|20|TRACE|Hub|Client Connected: 192.168.100.202:59097, 2e3e17a0b1e7449b913e6cf16cde97ee, V311

[Thomas_Claes]

ok, so you can rule out a simple problem with the broker (no acl in your configuration?)
the lock doesn’t reboot after disconnection (I don’t think the mqtt api gives the uptime like it does for the bridge)?