Properly separate Nuki Hub from Nuki Smart Lock (and Opener) entities

[mundschenk-at]

PROBLEM DESCRIPTION

On the physical level, there are two or three devices involved with Nuki Hub (one of 2. and 3. is optional):

1. The ESP32 running the Nuki Hub firmware.
2. A Nuki Smart Lock
3. A Nuki Opener

Since historically support for the Opener was added later, the discovery information generated for Home Assistant has been blended together into a single device containing entities both retaining to the Nuki Hub (e.g. sensor.nuki_hub_ip_address) and to the Smart Lock (e.g. ' lock.smart_lock`). While this is a bit confusing for uses (which entities relate to which physical device?), when there's both a Lock and an Opener in play, all the NH-related entities are provided in both devices, resulting in a lot of redundancy.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• [x] Read the Contributing Guide and Policy and the Code of Conduct
• [x] Searched the problem in issues
• [x] Searched the problem in discussions
• [x] Searched the problem in the docs
• [x] Searched the problem in the chat
• [x] Device used (e.g., ESP32-S3): irrelevant
• [x] Nuki Hub binary firmware version number used: irrelevant
• [x] Provide the output of http://nukihubIP/info: irrelevant

SUGGESTED BEHAVIOUR

Home Assistant explicitely supports the concept of a hub or bridge device, i.e. devices can be linked to the hub device via the optional key via_device in their device description. This would reduce the number of generated entities and allow for more precise information targetting (e.g. regarding firmware versions etc.).

Suggested architecture:

1. Nuki Hub device (the unique ID should be either some internal ESP32 ID currently not exposed or the existing ESP32 MAC address).
2. Nuki Smart Lock device, linked to 1.
3. Nuki Opener, linked to 1.

All entities not directly relating to the Lock or Opener devices should be moved to the Nuki Hub device (e.g. sensor.mqtt_log, sensor.nuki_hub_uptime). (Regarding the *connected binary sensors, I'm not sure, do they measure whether the Lock is connected or whether Nuki Hub is working, for example, in Hybrid Mode?)

[iranl]

Work on this has started in #508 to first separate nuki hub, lock and opener mqtt topics more logically. When #508 is merged I'll work on this request.

As with more HA mqtt (discovery) features the via_device is pretty sparsely documented. Looking at how Z2M implements this feature should give enough of a start though.

[mundschenk-at]

Thanks! Since I implemented some parts of the Z2M discovery, what specifically do you want to know? I can post a (partial) example config here, if you'd like. However, it might be worthwhile to wait for HA 2024.11's device-based discovery (finally!), which would reduce the number of discovery topics to one per device (instead of one per entity).

[iranl]

Just looking at the Z2M topics in my own setup is enough to know how to implement the via_device.

But the new device based discovery might be a good moment to completely rethink HA discovery inside NukiHub as it is kind of a mess right now.

[iranl]

I looked at the documentation and ideas of device based discovery, but I am not yet convinced it would be that much of an improvement over component based discovery for NukiHub.

It would at the very least create one very large JSON payload that the ESP might struggle with. Also changing/adding/removing entities is not necessarily easier with device based discovery. And before implementing the user would have to be on HA 2024.11 or higher.

For now I have stuck with component based discovery, but have added a separate NukiHub device and implemented the via_device. #515 should close this feature request.