Matter and the lockActionEvent topic

Nuki APIs MQTT
,
1

I am using a Smart Lock Pro (4th Gen) running firmware version 4.8.6, connected to a Mosquitto MQTT broker (over Thread).

According to the Nuki MQTT API v1.5, the device should publish to the lockActionEvent topic whenever a lock action is about to be executed.

Therefore, I monitored the topic nuki/<REDACTED>/lockActionEvent, performed the following actions, and recorded the payloads:

Actions via Lock Unlock
Android app (Bluetooth off; Nuki reachable via Thread) 2,0,912,0,0 1,0,912,0,0
Android app (Internet off; Nuki reachable via Bluetooth) 2,0,912,0,0 1,0,912,0,0
Nuki Web 2,0,123838,0,0 1,0,123838,0,0
MQTT 2,172,0,0,0 1,172,0,0,0
Matter triggered (Home Assistant) (no message published) (no message published)

Observations:

  1. Matter-originated actions do not trigger a MQTT lockActionEvent publication.
  2. The MQTT lockActionEvent payload does not provide a way to distinguish whether an action was triggered via Matter, Bluetooth, or Wi-Fi.

Are these indicative of limitations in the current firmware?

2

Looks like a bug. There is a trigger for Matter based lock actions, so they should also be reported. Thank you for pointing it out, we’ll look into it.

According to the current spec Matter is a separate trigger, but Bluetooth/WiFi/Thread are not. If you want these you’d need to create a new feature request. Just fyi - the value add of it is relatively limited, because the Apps will choose whichever channel works best for them at the moment. i.e. a lock command from an App triggered via Thread does not necessarily mean that the user has been remote.

3

The bug regarding Matter based action not triggering a MQTT lockActionEvent has now been resolved in our latest Beta 5.7.5.

We would appreciate if you could give it a try and come back to us with your feedback.

Thanks for your support.

4

Hola Daniel,

I’m using the Smart Lock Pro (4th Gen), which is currently on version 4.9.2. It seems version 5.7.5 might be specific to the 5th Gen hardware.

Unfortunately, even with the latest v4.9.2, the issue is still persisting and not working as expected. Could you look into this for the 4th Gen model please?

1 Like
5

Thanks for your reply.

Smart Lock 4th Generation will also be available with this fix very soon.
Please stay tuned as I will let you know when the build is available :slight_smile:

1 Like
6

Smart Lock 4th Generation build 4.9.3 with this fix is already available.

Please see:

1 Like
7

It’s working. Thanks!

Here’s the updated table:

Actions via Lock Unlock
Android app (Bluetooth off; Nuki reachable via Thread) 2,0,912,0,0 1,0,912,0,0
Android app (Internet off; Nuki reachable via Bluetooth) 2,0,912,0,0 1,0,912,0,0
Nuki Web 2,0,123838,0,0 1,0,123838,0,0
MQTT 2,172,0,0,0 1,172,0,0,0
Matter triggered (Home Assistant) 2,171,0,0,0 1,171,0,0,0

Regarding my other observation:

The MQTT lockActionEvent payload does not provide a way to distinguish whether an action was triggered via Matter, Bluetooth, or Wi-Fi.

I have opened a feature request for that a few months ago (see bellow).

The rationale is that having an ID for Bluetooth separate from “system” can be useful for auditing, forensic analysis and troubleshooting.

1 Like