Nuki (3.0 pro) öffnet automatisch die Tür über MQTT

Nuki APIs MQTT API
1

Hallo,

zuerst meine Konfiguration:

Nuki 3.0 pro
FW 3.7.7
Android-App: 2024.2.1

iObroker: v6.13.16
mqtt Adapter (aktuelle Version)

Home Assistant 2024.2.2, greift auf den ioBroker-mqqt-Broker zu.
Da bei heruntergefahrenem HA aber die gleichen Probleme auftreten, hat dieser meiner Meinung nach keinen Einfluss auf das Problem.

Problem: Wenn ich in der Nuki-App MQTT aktiviere und die Server-Einstellungen eingebe, öffnet sich direkt nach der Verbindung die Türe (“Falle ziehen”) und es kommt eine Fehlermeldung im Nuki-Protokoll (Smart Lock besetzt (0x04)).

Darauf hin öffnet sich sporadisch, nicht nachvollziehbar die Türe mit immer der gleichen Fehlermeldung (Smart Lock besetzt (0x04)).

Screenshot_2024-02-19-21-15-11-26
Screenshot_2024-02-19-21-15-11-261440×3120 162 KB

Ich habe folgende Einstellungen in ioBroker:

image
image1315×501 17.7 KB

image
image1338×399 16.7 KB

image
image1358×768 30.7 KB

Im Protokoll von ioBroker finden sich dazu keine Hinweise.
Es ist natürlich höchst bedenklich, wenn sich die Haustüre automatisch öffnet.

Hier wurde sowas schon mal beschrieben, allerdings ohne die Fehlermeldungen.
Ich habe darauf hin den Haken im ioBroker-mqtt bei “Eigene States beim Verbinden publizieren” rausgenommen, das Problem bleibt aber bestehen.

Hat jemand von euch einen Ratschlag, was ich noch probieren könnte? Die MQTT-Funktionalität wäre mir schon lieb, da ich über ioBroker bzw. HA den Türstatus abfragen kann und die Türe abschließen kann.

Viele Grüße
Markus

2

Ich habe zwischendurch mehrmals den Nuki neu in ioBroker eingebunden, die MQTT-Schnittstelle konfiguriert, alles ohne Erfolg.

Das Türschloss öffnet sporadisch die Tür. Das Debug-Protokoll von der MQTT-Schnittstelle enthält zu den Zeitpunkten der unbeabsichtigten Türöffnung keinen Eintrag.

Ideen?

3

I’d connect another client (e.g. MQTT explorer) to the same broker and monitor the Smart Locks lockAction topic there.
I assume you’ll see that the lockAction topic gets written (likely by ioBroker itself) on the occasions where it performs the lock actions.

4

The issue that I have this week is that Home Assistant or MQTTX can write on the lockAction topic… but Nuki seems that I doesn’t read it, so nothing happens. But Nuki write on that topic when used with the app.

5

Thanks for the advice. I have already read the MQTT log from ioBorker, but there is no indication of this. Also not in the Homeassistant → MQTT-Explorer.

I’ve just tried your tip in the Android app with the password when changing the MQTT settings (disable lock). As soon as I had entered and confirmed the changes, the door opened again. The error message in the log is again: Smart Lock occupied (0x04). And no information about it in the ioBroker log or in the MQTT explorer

Viele Grüße
Markus

6

The Smart Lock won’t perform a action if it is not asked to.
With MQTT explorer I meant this.

Unfortunately I have never used ioBroker so cannot really tell what this is doing in the background.
I just can tell you that using Mosquitto together with HA does not do that.

0x04 is returned because MQTT lock action commands are received by the Smart Lock although the previous lock action is still ongoing.

7

The Nuki app does not use MQTT to execute the lock actions and therefore also does not write on the lockAction topic when performing a lock action.
But it will update the lockActionEvent.
You’re sure you’re not mixing them up?

8

I have a Nuki 4 Pro, and it always worked with Mqtt integration on Home Assistant. From monday it doesn’t work anymore… it seems that it doesn’t read the mqtt messages sent from Home Assistant or Mqttx. But it does update the topic as you said.

9

And within the MQTT config in the Nuki app, “allow locking” is still enabled?

10

I have and mean the same MQTT Explorer in HomeAssistant :wink:

image
image1737×689 31.2 KB

11

Oh, sorry.
Never have seen MQTT explorer directly inside Home Assistant.
Knew it only as external application.

But yes then select the lockAction topic and monitor the history there.
I assume you’ll see it getting written whenever an action is performing.

12

yes :slight_smile:

13

I’ve seen in the other topic that you’re using QoS 0.
Can you try to send it with QoS 2?

Just to be sure, the Activity log of the Nuki app is also not showing the action (or the attempt to execute the action).

14

Now it’s working without any changes O_O

But yes, the activity log on the Nuki App didn’t show any action.

16

It’s always exciting to join someone else’s thread and then write “everything works now” :laughing:

17

Ok Marc, now that SaintTDI is done with his topic, we can continue here:

I have the following entries in the MQTT explorer immediately after I checked the “Allow locking” box (and of course the door opened spontaneously):

image
image2294×653 35.1 KB

(I didn’t know if it would be bad if I put the ID of the Nuki here in plain text)

What can I do now, what is interesting about the settings or what do you need to help me so that the door does not open regularly.

Thank you for your help,
Greetings Markus

18

You can share the screenshot with me directly as well to avoid publishing your Nuki-ID.

But again, please select lockAction:
image

And then check the history, once you add the device in order to check if and which commands have been transmitted:

image
image581×670 20.3 KB

1 Like
19

Here is the protocol:

image
image2471×395 21.9 KB

image
image1476×318 3.41 KB

At this point, the door was opened again unintentionally.

If I select the “nuki_unlatch_button” under “homeassistant” in the MQTT explorer, I get the following in the log:

{"~":"nuki/386XXXXX","avty_t":"~/connected","pl_avail":"true", "pl_not_avail":"false","dev":{"ids":"[386XXXXX]","mf":"Nuki","name":"Sesam","mdl":"Smart Lock 3.0 Pro"},"name":"Sesam Unlatch","uniq_id":"386XXXXX_unlatch_button","cmd_t":"~/lockAction","pl_prs":"3"}

(Screenshot send you per PN)

20

Hello,

I had more or less a similar occurence with the previous firmware 3.7.7 (same than you mentioned). With the current firmware 3.8.7 I couldn’t reproduce it anymore. I checked in my mqtt adapter in ioBroker if there was any unlock request triggered through the mqtt api. But it was not. In the iOS App protocol I saw some messages saying MQTT API - Door opened - Smart Lock busy (0x04)

Nuki 3.0 pro
FW 3.8.7
iOS-App: 2024.3.1 (2511)

Im will continue to check with the latest firmware.

(Happy to see that I’m not alone :grinning:)

Cheers,
Johannes

21

Hello everyone,

I had the same problem at the beginning (ioBroker and Nuki 3.0 Pro).
Sporadic opening always happened when the MQTT connection was reestablished and the lockAction = 3 was permanent.
The solution to the problem is simple: I set lockAction = 3 only for a short time and then set it to 0.
Now no matter what problem occurs between the lock and the control (MQTT or WLAN connection interruption), the lock remains unchangeable.

Best regards
Vadim

1 Like