I know how HA works, but thanks anyway for the explanation. 
It’s not me saying they can’t coexist, Juergen asked to choose, if I interpreted wrongly it’s better for him to better explain what he meant. Probably he’s referring only to auto-discovery, he didn’t say you can’t configure other platforms manually. This thread is specific to HA auto-discovery.
My question was whether there is only one way to represent a Nuki Smart Lock in Home Assistant Auto-Discovery or if there are different ways to do it ? E.g. because some people prefer it one way and others in another way. Or because of different Smart Lock configurations requiring different Auto-Discovery configurations.
Like I wrote above, there’s only one way, documented in the OP. Basically the device integrates in HA by describing its entities in MQTT and the device will automatically appear in HA. That’s how Nuki Hub is working right now, that’s why I linked its source, to give you an idea of how it works. I replaced my bridge with a small ESP32 device, and I didn’t have to do anything in HA: I had the Nuki Lock immediately with all the entities and associated services.
it’s not a user-preference, a lock device has a minimum (and common among all locks) subset of entities, the device components are not chosen by the user, it’s a “physical” representation mapped to logical entities.
Sorry for my misunderstanding, I thought you were talking about the different automation platforms.
The only thing which can change is the auto-discovery topic prefix which can be set by user.
By default it is homeassistant so it would mean a field in the app, except that @alexdelprete told everything
Correct: the default autodiscovery topic is homeassistant, so in the app, when user has to fill in the MQTT server hostname, user/pw, etc. an option to enable/disable HA Autodiscovery and when enabled the app asks for the topic, presenting the default one that the user can adapt to his system.
Here’s the MQTT config page of Nuki Hub, as an example:
These are the entities created in MQTT for autodiscovery for my SL Pro + Door Sensor. I don’t have the opener, so I can’t show you the entities for that.
We currently do plan to integrate auto-discovery but we do not plan to make the auto-discovery topic changeable. Is it common to change it?
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 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).
If it is not possible to secure the MQTT connection, then this option would be even more important to me.
It’s a user option when you configure the MQTT integration, so can’t say how many people change it, I didn’t personally. If you don’t implement it as a configurable option, at least specify the pre-requirement in the documentation and obviously in the code if you don’t find that specific topic throw a specific error, otherwise I expect a lot of tickets will be created.
Users who have a custom discovery topic could implement some kind of automation that replicates the default topic to their custom one. Not nice, but it should do the job.
The device provides status and interface to its services to the automation platform. Secure MQTT has nothing to do with what you are asking, if you don’t want your automation platform to do any action on the lock, you can configure it not to do it (disable services, etc.), it’s not a device configuration but an automation configuration.
Furthermore, the Nuki Lock and the MQTT server are in the same local network typically for this use-case, so I don’t even think securing that channel is actually required, also because if you have user/pw to access MQTT, the secure channel doesn’t guarantee you any improved security. Secure MQTT is a must if you need to send data to an external broker and you don’t want to transmit data unencrypted. This is not the use-case here.
Here I have expressed myself misleadingly: I am not (only) concerned that my SmartHome does not have the ability to control the lock, but that no one in the network has the ability to do so. You should always consider your own network as compromised. And if someone has gained access to my Home Assistant server, then he necessarily also has access to the MQTT server. And then a very simple command is enough and the door is open. An unencrypted connection increases the risk in that a potential attacker can see which devices are communicating when logging network traffic - but I don’t really have to care about that, if the lock isn’t controllable via MQTT.
No one would enable complete read and write access to a firewall just to read out the status of a connection, for example. That would be extremely negligent - so why do it with the lock of an entrance door?
If this simple option does not exist, then it means that the MQTT connection cannot be used in the enterprise environment for security reasons - which would be a great pity, because I would have many practical uses for it for my employer. But even at home, I would much rather not have to grant unnecessary permissions on the device.
This is exactly what I have already requested. To be able to integrate Lock in HomeAssistant, to see the state changes, to be able to trigger actions based on state changes, like Ring in Opener, etc …
BUT have an option to NOT allow to perform unlock action! As I only trust the Nuki application to open the locks.
If you consider your home network ALWAYS compromised, it means you shouldn’t use your home network in the first place, let alone an automation platform. Your home door can be opened in traditional ways, so you always consider your door ALWAYS compromised too? What about the keypad accessories Nuki sells? Those are compromised too?
That is absolutely not correct, it depends on how you setup security of your network, your servers, your infrastructure in general, and access to the MQTT server. But even without MQTT, if someone has full access to your network, it can access Nuki via all the other interfaces (REST, Bluetooth, etc.). How are you using Nuki now in HA, with the nuki_ng component and the bridge? If not, are you simply using the mobile app? And don’t you consider your mobile phone TOTALLY compromised too? What about the cloud access, you trust opening the lock from the cloud?
In any case, what you ask (even if totally wrong conceptually) cannot be done, read HA documentation on MQTT locks (I underlined the relevant statement):
What does a firewall have to do with a lock? What a confusion. We’re talking about integration of a lock in a home automation platform, and there are pre-requirements and constraints in order to do so.
Another conceptual thing: Nuki will access MQTT but it won’t send COMMANDS. HA will send commands, and you can configure a secure MQTT connection between HA and MQTT, so the commands to open the lock through MQTT will go through a secure connection if you configure it properly. Furthermore, the secure connection between the lock and the broker only encrypts data flowing locally, but if you have user/pw to the broker, it doesn’t improve security. MQTT secure is necessary when sending sensitive data to a public broker, a LAN broker is not the proper use-case.
So concentrate on securing your network, your HA server, before thinking about the end device.
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?
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.
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?
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.
