Modify new BT config using MQTT

[BadWolf42]

Description:

Hello Team,

In the continuity of #1256, this PR introduces the ability to modify BT configurations with MQTT payloads.
It also brings the capability to store the configuration directly in chip Non-volatile storage (if desired by the user).

This only adds new functionalities, it does not change current behavior for users that does not use them.

To achieve this, the following changes were made:

• Move BT Config initialisation BTConfig_default to ZgatewayBT.ino as BTConfig_init()
• Move BT configuration parameters in function BTConfig_fromJson()
• Add new parameters to json payload on .../commands/MQTTtoBT/config : presenceEnable, presenceTopic, presenceUseBeaconUuid, extDecoderEnable, extDecoderTopic, filterConnectable, pubKnownServiceData, pubUnknownServiceData, pubKnownManufData, pubUnknownManufData, pubServiceDataUUID, pubBeaconUuidForTopic
• Add ignoreWBlist as new configuration parameter
• Report all configuration change on topic .../commands/BTtoMQTT/config
• Add BT config bool commands (init, load, erase & save) to persist config parameters
• Update the documentation accordingly

The next (and last) step will be:

• Review White/Black-lists to handle "wildcard" mac adresses/uuid (point raised in issues Ibeacons with random MAC addresses #1139, iBeacon: Flag to use UUID in topic or presence (and fixes) #1226 and PR Basic whitelisting/blacklisting support for ZgatewayRF #919 for ZgatewayRF) and add a parameter to disable black/white-listing (point raised in issue BLE Whitelist. #331 and PR Add support to disable/enable white list control #615)

As usual, tell me if this is going in the right way for you,

Bad

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[BadWolf42]

OK, there are 2 issues here:

• first one is fixed by reverting commit c63b550, in commit cbf92dc (sorry pre-compilation is really tricky with ino files),
• second one is related to usage of Preference to store BT configuration and I would like your opinion on that.

Currently Preference is a ESP32 specific built-in lib.
A Preference lib for ESP82* and Arduino exists: vshymanskyy/Preferences@^2.0.0

So, should I:

• modify platformio.ini to include this lib on the required platforms (to have functional parity on all platforms), or
• do not add any lib and avoid using Preference on non-ESP32 platforms (and only store BT Config in NVS on ESP32) ?

Thanks,
Bad

[BadWolf42]

The declaration trick also seems to work for Code Format issue regarding this (redacted) warning:

I spent a lot of time to figure out that the template declaration line 118 will prevent compilation to succeed:

if there is a space between template and <typename T> as OMG format guidelines demands:

Code Format is now fixed with commit 9392ad0.

[1technophile]

Good that you did this only for ESP32 as we are planning to drop the support of HM10 , so no need to save this BLE configuration for ESP8266 or Arduino

[1technophile]

Thanks this is great !

Tested it, LGTM