Better MQTT Auto. Discovery for Home Assistant

[MattDog06]

In general a better MQTT auto. discovery for Home Assistant would be nice. I have created some payloads and added them manually. It would be nice if someone could add them to the source: Front Door Lock.zip .

Originally posted by @MattDog06 in https://github.com/technyon/nuki_hub/issues/27#issuecomment-1209282129

[technyon]

Hi,

noticed and some are already implemented. It's very tedious to generate the home assistant JSON in C++.

Which of the sensors and switches are most important to add?

[mundschenk-at]

Not sure if it works, but there appears to be a library to help with that.

Edit: I read up a bit on the library and it appears to do more than just generate the autodiscovery topics. Probably not to useful then.

[michelnet]

Hi, for me personal is the most import the lock/doorSensorState.

[technyon]

Yes the door sensor makes a lot of sense. I've added it in release 5.11.

[mundschenk-at]

Bringing over the various configuration switches would be nice in the long run. Also some diagnostic sensors like uptime (to detect restarts) and #33,

[kvj]

I believe that MQTT discovery payloads can be improved a bit (based on my experience implementing similar stuff):

1. I see that you use device name to generate entity names, by adding prefixes to it, like name + "bluetooth signal strength". Instead, you can set name to "Bluetooth signal strength" and additionally generate object_id field using uidString. In this case, HASS will use object_id to generate entity ID, and it won't depend of device name (which is mutable) and entity name will be short but still linked to the correct device entity
2. I've got better results by using "optimistic": true mode, because, when Nuki and ESP32 aren't fast enough in connecting/executing/pushing state back, you can experience entity state flickering as HASS expects nearly immediate broadcast of updated status.
3. You generate JSONs as strings by concatenation, is there a reason for not using ArduinoJson library for that? Size constraints maybe? The library is small and handy and improves code readability and maintenance a lot

[alexdelprete]

I believe that MQTT discovery payloads can be improved a bit (based on my experience implementing similar stuff):

@kvj your knowledge on Nuki APIs and HA could be really valuable if you decide to contribute to this project. I just received some M5AtomU and M5AtomLite to test. I hope we can finally get rid of the Nuki Bridge thanks to the work of @technyon. :)