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.
You just have to subscribe to the topic. Maybe this helps: What are Retained Messages in MQTT? – MQTT Essentials: Part 8
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
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,
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
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)?
no ACL at this level (if you mean access control list). I just started to play with it 10 days ago - it was not working (disconnection after command) - I wrote here some new topic, but nobody responded to that for 10 days. Yesterday, I gave that a second try: lock was not calibrated so I calibrated it, connect it to MQTT, sent the command and it worked fo r 5 times. I was super happy, that I solved the problem. I started to test marginal scenarios like server disconnection and reconnections (how long will it take to reconnect). But after single reconnection it stopped working again. I wrote to support via Nuki App - no response for 24 hrs…
So I am pretty sure, that command is constructed according specification - as it was working for a while.
I forgot to mention, that lock had fw 3.7.2 Beta - yesterday. Today I have upgdraded it to 3.7.3 Beta - but no difference. My concert here is also with the Beta word. I’d like to have some stable fw in there.
I haven’t looked at the topic but it’s not the best place to discuss this. I’ve found your other post, so I suggest going over it and closing this aside in this post.
Sure, no problem - lets go there.
Shouldn’t this not be considered a bug, just like on the regular bridge? Bridge HTTP-API only sporadically reachable when no internet connection is avaiable (firmware 2.4.21) - #32 by Raimund_Scheiber
Btw, there is a feature request now. Which feels strange, since on the bridge it has been processed as a bug.
Hello Christian, I see you are probably a Loxone user.
Could you give me a hint how to create the udp output to manage the lock?
I actually bought a smartlock 4.0 pro
Thanks in advance
I’m using the ioBroker MQTT Broker to read the data from Nuki. Unfortunately the lockActionEvent does not contain anything readable. It seems there is an error in the format Nuki is transmitting this value so the broker cannot interpretate the array as array (instead it’s interpretated as binary)
There’s a full topic about this on github:
Basically the raw data of this object looks like this:
val":"\u0002\u0000̀\u0000\u0000
if you look careful you can see the third backslash looks weird
Unfortunately (for you) that seems to be an ioBroker problem, because the mqtt data is exactly coming in like described in the api specs in the first post.
You may install a mqtt sniffer (Mqtt Explorer or mqtt.fx or whatever) and see the raw data:
1,172,0,0,0 (Example from my SL3P, connected to openHAB, read from MQTT Explorer)
Then compare that to the api docs:
Unlatch via Keypad with
Auth-ID 54321 from Code-ID
12345:
3,0,54321,12345,1
Maybe developers can point us to some hints how encoding the data sent for iobroker.mqtt adapter.
In mosquitto i can see following data:
Received PUBLISH from Nuki_xxxxxxxxx (d0, q2, r0, m59102, 'nuki/xxxxxxxxxx/lockActionEvent', ... (14 bytes))
In MQTT Explorer i can see correct conversion:
on ioBroker i see som Escape Sequences: ( kind of wrong encoding? )
Thanks
Why are only some of the available MQTT topics created in HomeAssistant upon autodiscovery? Especially “state” would be very interesting as one could trigger an automation in HomeAssistant if the SmartLock is locked. (e.g. enable surveillance cam recording in Frigate)
Hi Elronzo, state is published.
alias: Nuki lock state notification
description: “”
trigger:
- platform: state
entity_id:- lock.entree
condition: []
action:
- lock.entree
- if:
- condition: device
device_id: d2280
domain: lock
entity_id: dc21d9
type: is_locked
then: - service: notify.mobile_app_iphone
data:
message: Nuki locked
alias: locked
mode: single
- condition: device
So you can activate recording via a mqtt publish to your frigate (I do that).
1 Like
Is it true that the Nuki MQTT integration won’t work if the Nuki cloud is not reachable? I am reading this here and there but hope that this is not true. Or is it only the case when using a Nuki bridge?
(SmartLock 4 Pro user, Firmware version: 4.1.8)
False, mqtt is working without cloud (Nuki Web)
maybe, after initialisation. But for activating mqtt, internet connection is a must have…
I can live with that as the initial setup also requires the app.