Enhance config options

[iranl]

• [x] Add every config and advanced config option to MQTT (JSON)
• [x] Separate config state from config actions in MQTT (same as lockstate/action and keypad codes/action)
• [x] ACL for every separate config option
• [x] Make some config/advanced config options more human readable
• [x] Allow modifying every config and advanced config option through MQTT
• [x] Modify existing config Home Assistant auto discovery topics
• [x] Add new config Home Assistant auto discovery topics
• [x] Update README
• [x] Enable/disable all button for ACL options in WebCfg
• [x] Final minor adjustments and testing
• [x] Update Arduino Core to 2.0.15 (won't build otherwise using Actions/Dockerfile)

NOTE: Breaking change as the existing configuration MQTT topics can not be used for changing settings if this is merged.

Closes #327

[iranl]

@technyon This PR needs the most recent changes in I-Connect/NukiBleEsp32. Can you sync nuki_ble with upstream?

[technyon]

Hi,

Sorry I didn't see your comment. nuki_ble is now updated.

One more thing: Since there are breaking changes in this PR, could we have a discussion on discord? Not that I'm against it, I'd just like to hear some more opinions.

[iranl]

Binary available for testing from the Github Actions artifacts: https://github.com/technyon/nuki_hub/actions/runs/8644273771/artifacts/1404437356

[technyon]

@iranl Before merging, could you post a binary for testing on discord?

[iranl]

As requested, also posted on Discord.

nuki_hub-8.34-pre-2.zip

[iranl]

Converted to draft because of issues reported in #327

[iranl]

Added fixes for stability issues with the combination of an opener and lock.

nuki_hub-8.34-pre-3.zip

[technyon]

Hi. There are a lot of changes in this PR, and some potential stability issues have been reported. We should to some thorough testing before merging. Is the -pre-3 binary up-to-date?

[iranl]

Pre-3 is not up to date.

Do you want to include #340 in 8.34? #340 is a pretty minor addition which is basically a copy of the JSON keypad control.

If so I will build Pre-4 after merging #340 from master + this PR. If not I will build Pre-4 from the current state of this PR.

[technyon]

Hi,

I've merged your other PRs. Could you update and build an up-to-date binary

[iranl]

Binaries for pre-4:

esp32-assets.zip esp32-s3-assets.zip esp32-c3-assets.zip esp32solo1-assets.zip

Edit: Tested and working without obvious issues on the ESP32, ESP32-S3 and ESP32-C3 in combination with the Nuki Lock 4.0 Pro

[katiuskt]

Apologies if this is not the place to ask this but testing the 8.34pre4 release in a AtomS3 Lite + Atom PoE and configured as follows: it looks like the wifi fallback is being used: MAC does not change in router; if I check the option "Disable fallback to Wi-Fi / Wi-Fi config portal" I lost access completely; and:

Nuki Hub version: 8.34-pre-4
(...)
Network device: Built-in Wi-Fi

Same M5Stack Atom POE but with an Atom Lite (not S3 Lite) with 8.33 works fine (connectivity is done by ethernet if configured so)

Based on this snap from their store I would expect Atom PoE working for both Atom and AtomS3 but taking a closer look, the pinout of the S3Lite (G5/G6/G7/G8/G38/G39) is different from the non-S3 (G19/G21/G22/G23/G25/G33). 5V and GND remain in the same place. So not sure if this is something it could be managed in code somehow to get the M5Stack Atom PoE working also with the AtomS3 Lite or maybe things are not so easy or completely unrelated with nukihub could handle.

Thanks!

[iranl]

@katiuskt: I've pushed an update to the W5500 code to change the pinout for the AtomPOE on the S3 to 5/7/8/39 instead of 19/22/23/33

Can you try esp32-s3-assets.zip? Note: Will still show 8.34-pre4

[katiuskt]

Thanks @iranl . OTA updated to that new version but unfortunately, nothing changed: connectivity remains by wifi. Turned off/on PoE to restart (just in case it would be necessary) didn't help either. Not sure if there are some logs or something I could share (no idea how can this be debugged)

[iranl]

I've taken a good look at the pinouts and it seems the following pinouts translate to the different models:

Func	Atom S3 lite ESP32-S3	Atom lite ESP32
CLK	6	19
CS	5	22
MISO	7	23
MOSI	8	33

In my first try I assumed the pinout G5/G6/G7/G8/G38/G39 translated to G19/G21/G22/G23/G25/G33.

Please try esp32-s3-assets.zip

You can try debugging using the serial console with a program like hterm

[katiuskt]

Thanks @iranl , it worked now!

A couple of "weird" things (not sure if expected):

1. I had to turn off/on PoE and do several changes between Wifi-only and W5500 options before it worked properly.
2. I expected the device to have the same MAC address it already had with the Atom Lite but it is not the case. I mean, expected the MAC to be linked to the Atom POE adapter so regardless the ESP32 attached to it (Atom Lite or Atom S3 Lite), I expected the MAC being the same. However it is not (and thus also the device name changes from "WIZnetXXYYZZ" to "WIZnetAABBCC").

Beyond those two observations (probably not relevant), S3 lite seems to be working fine. I'll do further tests next days, though, but really appreciated your work supporting the S3!! 🙌

UPDATE: One suggestion related with the HA autodiscovery topics: Given the fact the reset command auto-resets to 0

maintenance/reset: Set to 1 to trigger a reboot of the ESP. Auto-resets to 0.

Wouldn't be a better choice to configure it as a "button" (https://www.home-assistant.io/integrations/button.mqtt/) rather than as a "switch"?

[iranl]

Good to hear the Atom POE now works on the S3.

As for the maintenance/reset button I agree, this is also the way I have recently implemented the query buttons. The choice to expose maintenance/reset through a switch was made a while ago and changing it would mean a breaking change for people using this switch in an automation. The pros of changing this behaviour don't outweigh the cons of a breaking change at this time in this case imho.