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.
Can MDNS/DNS host name be used or is it only enabled for hard-coded MQTT connection?
Because the field name is “Host name” I suppose it is possible almost for DNS name but I prefer to be sure in the case I would have to switch from IP to host name for any reason.
This approach can lead to some troubles if you don’t distinguish between “mqtt.local” and “mqtt.<< domain >>. local”. Lot of companies, and not only, use “.local” as TLD for their internal DNS/AD domain for separation from internet.
)