It’s called “reducing vectors of attacks”.
Just a note: When MQTT access uses its own “user”, then like for all other users, I can simply disable “Allow locking”. Case solved.
Yes, and in order to reduce the vectors of attacks, avoid using your mobile or the cloud and concentrate on having as much as possible locally, in a central HA platform, so you can better secure it with a proper firewall and proper security rules/procedures. That’s why we prefer platforms like Home Assistant, that allows to do (almost) everything locally.
What user are you referring to?
Anyway, you can solve the problem at the MQTT broker level: configure ACLs on topics, and set HA’s mqtt user to readonly on the nuki device topics, so HA can’t write and it won’t trigger an action on the device. Mosquitto supports it, other brokers too.
I understand you. Just my perception of security is a little bit different, so unfortunately, I won’t be able to use this feature.
1 Like
That’s nice to have, but I still stand by my opinion that a safety-critical device must have such an option. After all, the cloud API can do that too.
MQTT support for the Nuki bridge is not planned at the moment. Currently everything MQTT is just SL3P, because there does not exist an alternate local API for it.
We agree with that view and will implement a setting to “Allow Lock Commands” through MQTT (Default: On).
2 Likes
I know that now the beta is only for SL3P, I was referring to the future. When this all started we asked some questions, and one of them was if MQTT support would be there for all SL, you said yes. Then you said beta was only for SL3P.
So just to be clear, the question is: will there be MQTT support for owners of previous locks with the Bridge?
You keep on asking the same question over and over again. I’ll answer it for one last time:
- We do not comment about future product releases or our roadmap here in the forum. If we communicate something it is done through official channels (e.g. our blog, a press release)
- We have the MQTT API in beta for SL3P and communicated already that we plan to release it in 2023.
This means that (for you) the future of MQTT in SL3P is clear and in the bridge is unclear (and will remain unclear until there is any further communication from Nuki).
1 Like
If the answers are not clear, what do you expect?
That is not true, you opened the MQTT API discussion, announced support for MQTT on the forum and asked for feedbacks: everything here, on the forum.
That was clear, obviously, but we asked about the other locks and the bridge, because it makes no sense (other than sales interest) to not give your FIRST users the possibility to have MQTT support.
It’s not FOR ME, I don’t care personally, I already replaced the crappy/limited/buggy bridge, that costs €99 with a €6 ESP32 device with open source firmware that is a million times better (hw&sw wise) than the bridge, so I have MQTT support, fast responses, no weird errors, etc… But there are many other users with the bridge that would benefit from official MQTT support from Nuki, but nobody cares there.
Having said that: good luck to everybody waiting for official MQTT support for the bridge, it’s clear Nuki wants SL2 users to throw the $200-300 spent on the SL2+Bridge+Accessories and move to SL3.
Time to look around for less expensive and technically better alternatives to this, with proper hw and proper fw, and most of all with a transparent company policy. I still remember when Nuki announced the first lock with Zigbee support (that’s why I chose it) and you never delivered. Same again now with MQTT.
Goodbye Nuki, and good luck everybody.
Bye Alessandro and thank you for your customer insight.
Personally I dont mind if there are vendor specific autodiscovery topics, for me it is more important to build on the given topics to create or get some integration. If the convention matches to a popular vendor: integration is of course easier. But from a product perspective - e.g. announcing a auto discovery feature for xy - this would maybe even create a vendor dependency as customers assume and expect a compatibily to a given solution like homebridge/hoobs, home assistant, iobroker, you-name-it - which will put nuki under pressure to monitor these vendors regarding API changes. I think this is not very easy with community driven / hobby projects as there are no contracts / agreements on lifecycle management etc. It seems like best effort.
So in the interest of nuki I respect the openess and discussions about new features but totally understand that it is not easy to not listen to the loudest voice. At least this is developer forum and not a general customer support center. And I am relieved that nuki is testing and discussing product features beforehand to improve the market fit and totally understand if a feature is dropped because it does not create the needed added value proposition or it is technically not even possible due to resource constraints, though this may be personally disappointing. Anyway I like to support you with beta tests, reviews and so on - as a customer I am not only using your product but of course identify with your brand - and I want just to thank you for your work, community support and that I am happy with using your products 
Thanks for your kind reply Benedict, but I have to correct you on some things:
-
I am not discussing the autodiscovery specific to one platform, my question was MQTT support in general, and Nuki is failing to commit on SL2 users that bought the $99 bridge (that only supports one http connection) to have a functional local API to integrate it. If they deliver MQTT only for SL3 customers, SL2 customers have the right to think it’s a sales decision (Apple style), not a technical one.
-
Zigbee was publicly announced, before it was ready, but many customers like me trusted the company to deliver and bought the device anyway: that was a big mistake. I’m seeing the same exact behaviour with MQTT. Keep in mind that MQTT would solve a lot (I’d say the vast majority) of problems people are facing when integrating Nuki and its API in their automation platforms. Both Zigbee & MQTT would’ve been a way to overcome the severly limited hardware of the bridge, and the overall approach to the integration of the product.
-
The fact that with a simple ESP32 device, worth 10 bucks (vs the useless $99 bridge), and an open-source firmware (Nuki Hub) you can overcome every integration issues by leveraging MQTT and communicating directly with the lock via BT API, says it all. Nuki should create a new Bridge (properly priced) and implement proper local API through MQTT directly. But since I lost trust, I’ll look for other products with a different approach to customers feedbacks and a clear commitment to a flexible API, local + cloud, and having it integrated in the major automation platforms. We’re talking about very basic requirements, not fancy stuff, that can be fully implemented on an ESP32.
I loved Nuki, I even had a 1h virtual meeting with the Product Manager 1y ago, sharing with him everything I thought was not working properly and some ideas for the future that could be implemented, he was very nice and took note of everything, but in the end, after all these months, many customers were forced to look for an open source alternative to properly address all the issues of the Bridge, and that’s a real shame if you ask me, also because the Bridge is still massively overpriced and massively underperforming because of the bad hardware design.
Goodbye again, and thanks a lot for the interaction, it allowed me to express myself more clearly.
1 Like
I won’t comment all this claims, which seem to stem from a series of wrong assumptions.
Please lets return to the topic of this thread which is about MQTT in SL3P and Home Assistant auto-discovery specifically. Thank you!
1 Like
Just to have said it: I‘ve no problem that currently no TLS is in place, as long as user/pass can be set by the user.
About MQTT support for the bridge:
Would be nice, but I understand the point of Jürgen, not to promise further support for other devices as long as the current project has not finished.
Lg, Christian
1 Like
As I said, this is the YAML configuration I use now:
Nuki Smartlock YAML configuration
mqtt:
lock:
- name: "Front door"
unique_id: "nuki_12345ABC_lock"
command_topic: "nuki/12345ABC/lockAction"
payload_lock: "6"
payload_unlock: "1"
payload_open: "3"
state_topic: "nuki/12345ABC/state"
state_locked: "1"
state_unlocked: "3"
availability_topic: "nuki/12345ABC/connected"
payload_available: "true"
payload_not_available: "false"
device:
identifiers: "12345ABC"
name: "Front door"
manufacturer: "Nuki home solutions GMBH"
model: "Smartlock 3.0 pro"
hw_version: "3.0p"
sw_version: "3.5.5"
suggested_area: "Entrence"
binary_sensor:
- name: "Front door"
device_class: "door"
unique_id: "nuki_12345ABC_door_sensor"
state_topic: "nuki/12345ABC/doorsensorState"
payload_on: "3"
payload_off: "2"
availability_topic: "nuki/12345ABC/connected"
payload_available: "true"
payload_not_available: "false"
device:
identifiers: "12345ABC"
name: "Front door"
manufacturer: "Nuki home solutions GMBH"
model: "Smartlock 3.0 pro"
hw_version: "3.0p"
sw_version: "3.5.5"
suggested_area: "Entrence"
- name: "Front door charging"
device_class: "battery_charging"
unique_id: "nuki_12345ABC_battery_charging"
state_topic: "nuki/12345ABC/batteryCharging"
payload_on: "true"
payload_off: "false"
availability_topic: "nuki/12345ABC/connected"
payload_available: "true"
payload_not_available: "false"
device:
identifiers: "12345ABC"
name: "Front door"
manufacturer: "Nuki home solutions GMBH"
model: "Smartlock 3.0 pro"
hw_version: "3.0p"
sw_version: "3.5.5"
suggested_area: "Entrence"
- name: "Front door lock battery critical"
device_class: "battery"
unique_id: "nuki_12345ABC_lock_critical"
state_topic: "nuki/12345ABC/batteryCritical"
payload_on: "true"
payload_off: "false"
availability_topic: "nuki/12345ABC/connected"
payload_available: "true"
payload_not_available: "false"
device:
identifiers: "12345ABC"
name: "Front door"
manufacturer: "Nuki home solutions GMBH"
model: "Smartlock 3.0 pro"
hw_version: "3.0p"
sw_version: "3.5.5"
suggested_area: "Entrence"
- name: "Front door sensor battery critical"
device_class: "battery"
unique_id: "nuki_12345ABC_door_critical"
state_topic: "nuki/12345ABC/doorsensorBatteryCritical"
payload_on: "true"
payload_off: "false"
availability_topic: "nuki/12345ABC/connected"
payload_available: "true"
payload_not_available: "false"
device:
identifiers: "12345ABC"
name: "Front door"
manufacturer: "Nuki home solutions GMBH"
model: "Smartlock 3.0 pro"
hw_version: "3.0p"
sw_version: "3.5.5"
suggested_area: "Entrence"
sensor:
- name: "Front door battery"
device_class: "battery"
state_class: "measurement"
unit_of_measurement: "%"
unique_id: "nuki_12345ABC_battery_percentage"
state_topic: "nuki/12345ABC/batteryChargeState"
availability_topic: "nuki/12345ABC/connected"
payload_available: "true"
payload_not_available: "false"
device:
identifiers: "12345ABC"
name: "Front door"
manufacturer: "Nuki home solutions GMBH"
model: "Smartlock 3.0 pro"
hw_version: "3.0p"
sw_version: "3.5.5"
suggested_area: "Entrence"
It works as expected for me, even if by reading again there might be some point to change:
- The device ID should be prefixed by
nuki_to be sure it is really unique - the
unique_ids maybe should be lowercase, in fact maybe all IDs.
I hop this helps to give a better idea about what could be an integration in Home Assistant as auto-discovery payloads are the same as YAML configuration.
Can you please make the suggested changes also in the script you published on github?
We plan to use the output of your script for the representation of HA auto discovery inside SL3 
I think the script you mention is made by @MattDog_06.
IIRC there are some points I added in my config which could be added to this script but I should compare again.
If I find something I’ll make a PR.
You’re right. My fault. I was referring to GitHub - MattDog06/Nuki-MQTT-auto.-Discovery: Python Script creating HA auto. discovery topics for you Nuki Lock 3 Pro with MQTT enabled (Beta Firmware)
Draft for v1.4 of the MQTT spec is released. It contains HA discovery. Please have a look and make comments if you have some. MQTT API Specification v1.4
2 Likes