even if I’m IT professional, all the provided info wasn’t clear for me as Nuki-newbie (spread over different places), how to setup the MQTT on my newly purchased Nuki 3 Pro, so let me summarize the MQTT prerequisites.
to be able the current use of MQTT, following must be done:
Nuki 3 Pro has to be in debug mode
AND
“mqtt.local” has to be resolvable via mDNS
OR
“mqtt” has to be resolvable via DNS
and if I’ve understand it good, in the next beta version of the Nuki android App, the setup section for manual MQTT configuration will come and debug mode will not be required anymore
How often is not relevant. It will be “true” as long as the SL is connected and “false” when it is not connected anymore. This functionality is part of the MQTT standard. See Last Will and Testament - MQTT Essentials: Part 9
That is correct, because MQTT has not been offcially released yet. If you just wait a few more weeks/months it will be officially released and none of the above will be necessary (and avialable anymore) and you can simply enable it from the App as you would expect.
it seems all working fine now, except one thing:
there is no warning when someone tries to “brute force” the password via keypad.
I would like to suggest to implement sending out some warning MQTT message, let say, after 10 consecutive failures to enter correct code (and notification into app too)
and maybe some feature to temporarily disable the keypad remotely - but without unpairing it
(consider the scenario, that you’re somewhere, for example, on Salzstiegl or Kitzsteinhorn and someone enters repeatedly wrong codes on keypad at your home )
/MfG
ZoloN
if you are looking for energy savings, sending out the timestamp messages to each action message are IMHO pure waste of energy. when you process the messages, you don’t process the subsequent timestamp message (much effort needed for implementation of the logic). and when you save the messages into database, usually you will use (like me) some timeseries database instead of classical RDBMS (I use influxdb) which appends timestamp automatically to each entry stored.
I‘m not a real fan of the csv in the lockActionEvent topic, and unsure, how Loxone will parse this (possibly as floats like12345,54321).
I really don’t know about power consumption of a transferred byte, but a json with keys would be more flexible than a fixed csv.
{"a":3,"t":0,"aid":12345,"cid":54321,"au":0}
would also be possible without a json encoder on the Smartlock.
But workarounds in Loxone logic will be possible (e.g. INT() on wrongly parsed floats) to get the correct values.
This is unfortunately coming a little bit late … There was a ~4 month draft & beta phase of the 1.4 spec and it has been released just last week. Every change or feature request now needs to go through the usual “Feature request” process and every change from now on also needs to consider backwards compatibility.
sorry for that, I got my Nuki 3 Pro only last week - where the main decision point was the MQTT support without mandatory cloud account.
I know, backwards compatibility is always a tricky stuff causing a lot of headache, maybe this could be handled by: using 1.4 protocol by default and “new” protocol activated on demand via MQTT configuration command. then we can have plenty room for future protocol development without disturbing the current production one.
I’ve just realised: when the Nuki 3 Pro performs auto-lock after closing the door, the MQTT response is only via “/state” topic and no message is sent via “/lockActionEvent” topic.
is this intentional or design bug?
the sequence is following when unlocking via button, going out, returning and opening via keypad and finally locking via button:
next thing that I’ve realised, when I unlock the door from outside by physical key or from inside by turning the knob, the Nuki 3 Pro sends out following MQTT message:
1 = “Manual” in all other API specs that use trigger.
Most likely a relict from early beta testing of the function where it was not clear whether a manual lock action by turning the key or the knob would trigger such an event at all. Thanks. Will fix it in the spec.
thanks for update. sorry, that I came so late to participate on testing/debugging/proposing on the MQTT implementation.
I use for my home automation the mosquitto/nodered/influxdb/grafana stack, lot of my devices are running Tasmota FW, integration with Ikea Tradfri, Google Home (directly or via SmartNora)
I’m using MQTT on my smart lock pro 3.0 locks since it was added as a feature in firmware 3.5.11. It’s connected to my Mosquitto on my Raspberry pi device, to connect to Openhab.
I notice when I restart my router / disconnect the netwerk to the smartlock, The lock doesn’t reconnect to MQTT. I own 2 locks, but it looks random.Sometimes the front door lock isn’t connected anymore after router restart, sometimes the backdoor lock isn’t connected anymore to MQTT. Problem can be resolved by removing the batterypack and inserting it again. I give it several hours to reconnect but unfortunate it doesn’t.
Could this be a bug and is there a way to check the log’s from the lock why it doesn’t connect to MQTT?
After about 4 to 5 hours, the lock is suddenly connected. So i’m curious if this is intentional. And still curious if I could check some logging somewhere.
I use a smart lock pro with firmware 3.5.11. When I restart the mqtt broker, the lock reconnects within short but somehow it won’t react to commands via mqtt after that.
The current state gets updated, but I can’t issue any commands as they are ignored by the lock.
(spread over different places), how to setup the MQTT on my newly purchased Nuki 3 Pro, so let me summarize the MQTT prerequisites.
)