Home Assistant MQTT auto-discovery implementation requirements

[alexdelprete (Alessandro Del Prete)]

@Juergen

Somehow related, but a bit off topic is the problem that we can not offer secure MQTT because of memory restrictions that we run into with the SSL connection. If the memory restrictions are resolved in a future product, we would still use it without certificate pinning. e.g. no uploading of a custom certificate is supported.

I replaced Nuki Bridge with a $10 ESP32 based device with Nuki Hub firmware (while waiting for official MQTT support on Nuki Bridge) and it supports MQTT secure connections with certificate and all the rest. I hope a future Nuki bridge will have at least the capabilites of an ESP32 to overcome all the limitations of the current bridge. BTW: will there be a beta fw for Nuki Bridge or will we have to wait for the official version to test it?

[mclei]

It’s mandatory for locks to support lock and unlock

It is nothing against it. It will just ignore or reject the unlock.

BTW, originally I have requested the permission to allow lock and unlock separately, so I can lock through the HA, but cannot unlock.

[alexdelprete (Alessandro Del Prete)]

@mclei

It is nothing against it. It will just ignore or reject the unlock.

BTW, originally I have requested the permission to allow lock and unlock separately, so I can lock through the HA, but cannot unlock.

The lock ignores it, while HA waits for a state transition, what do you want the lock to do? Fake the state?

What a confusion…if you don’t trust integrating the lock in HA, don’t integrate it. There are people that have home alarms integrated in HA.

Another question: why do you trust so much the app on your mobile phone, do you think that is secure? Do you use Nuki web features? Do you think those are 100% secure too?

[mclei]

@alexdelprete

What a confusion…if you don’t trust integrating the lock in HA, don’t integrate it. There are people that have home alarms integrated in HA.

Another question: why do you trust so much the app on your mobile phone, do you think that is secure? Do you use Nuki web features? Do you think those are 100% secure too?

It’s called “reducing vectors of attacks”.

[mclei]

Just a note: When MQTT access uses its own “user”, then like for all other users, I can simply disable “Allow locking”. Case solved.

[alexdelprete (Alessandro Del Prete)]

@mclei

It’s called “reducing vectors of attacks”.

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.

@mclei

When MQTT access uses its own “user”, then like for all other users, I can simply disable “Allow locking”.

What user are you referring to?

[alexdelprete (Alessandro Del Prete)]

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.

[mclei]

I understand you. Just my perception of security is a little bit different, so unfortunately, I won’t be able to use this feature.

[nicohirsch]

@mclei

It’s called “reducing vectors of attacks”.

@alexdelprete

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.

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.

[Juergen (Jürgen Pansy)]

@alexdelprete

will there be a beta fw for Nuki Bridge or will we have to wait for the official version to test it?

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.

[Juergen (Jürgen Pansy)]

@nicohirsch

I would really like to have the option to set the lock’s MQTT connection to “read-only” / sensors-only so that my “potentially insecure” SmartHome has the ability to read the status of the lock and react on it, but does not have the ability to control the lock - i.e. cannot open the door (in theory, the lock should only have to ignore the command topic if the connection is set to sensors-only).

We agree with that view and will implement a setting to “Allow Lock Commands” through MQTT (Default: On).

[alexdelprete (Alessandro Del Prete)]

@Juergen

MQTT support for the Nuki bridge is not planned at the moment.

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?

[Juergen (Jürgen Pansy)]

You keep on asking the same question over and over again. I’ll answer it for one last time:

1. 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)
2. 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).

[alexdelprete (Alessandro Del Prete)]

@Juergen

You keep on asking the same question over and over again. I’ll answer it for one last time

If the answers are not clear, what do you expect?

@Juergen

We do not comment about future product releases or our roadmap here in the forum.

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.

@Juergen

We have the MQTT API in beta for SL3P and communicated already that we plan to release it in 2023.

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.

@Juergen

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).

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.

[bju (Benedict)]

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

[alexdelprete (Alessandro Del Prete)]

Thanks for your kind reply Benedict, but I have to correct you on some things:

1. 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.

2. 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.

3. 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.

[Juergen (Jürgen Pansy)]

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!

[christianTF (Christian Fenzl)]

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

[Nardol (Patrick Zajda)]

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.

[Juergen (Jürgen Pansy)]

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