[RF] Introduced WhiteList and BlackList of RFSignal and refactor RF Configuration Management

[Odyno]

Introduced WhiteList and BlackList of RF Signal

• For the RF (RCSwitch) module, introduced the ability to filter the RF signal that must be loaded on the Mqtt broker
• Introduced the ability to configure WhiteBlackList via the MQTT command message

Refactor RF Configuration Management

• Introduced RFConfiguration class to encapsulate RF settings and operations.
• Direct usage of RFConfig structure was replaced with iRFConfig instance throughout the codebase.
• Updated methods for loading, saving, and managing RF configurations to use the new RFConfiguration class.
• The obsolete RFConfig_s structure and related functions were removed.
• Enhanced frequency validation and management in the new RFConfiguration class.
• Updated web UI handling to reflect changes in RF configuration management.
• Improved logging and error handling during RF configuration updates.

Checklist:

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

[Odyno]

@1technophile I introduced this new whitelist/blacklist feature based on how it's functionally implemented for Bluetooth devices. I did this because I believe I live in an area with a huge amount of RF frequencies, and my MQTT broker gets flooded with messages within 30 minutes... messages that are also handled by Home Assistant. The code looks good so far, and I'm currently testing it. The only issue I'm facing is reducing the binary size — it seems that for the esp32dev-all-test build, I've exceeded the maximum ELF size.

Checking size .pio/build/esp32dev-all-test/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  23.9% (used 78312 bytes from 327680 bytes)
Error: The program size (2034132 bytes) is greater than maximum allowed (2031616 bytes)
*** [checkprogsize] Explicit exit, status 1
Flash: [==========]  100.1% (used 2034132 bytes from 2031616 bytes)
========================= [FAILED] Took 214.93 seconds =========================

I'm trying to solve this over the next few days (any help is welcome!).

[1technophile]

@Odyno I’m thinking that we could have only one filtering common for all modules, give me a few days and I will propose something

[1technophile]

@Odyno Here is a commit that I haven't merged but could give some ideas about white and black listing at system level: https://github.com/1technophile/OpenMQTTGateway/commit/b708531c2d6aa7b51cd73f280395032224675bbe The goal is to be flexible on the keys to filter and accept wildcards for their content. IN the case of RF we would use the key "value" for example. Also we could add the origin module in the filtering in case one wants only to filter from one module. It avoids duplicating filtering code into each module and may help address the flash size challenge.

The WL and BL function could be a separate PR so that this PR focus only on the RF configuration refactoring. Also goal should be to have a configuration management that could be easily replicated or used by other modules.

[Odyno]

Hi @1technophile, I think it's a good idea to move this functionality to the system level, maybe integrating the UI also on mqtt and webui. However, in this pr I only focused on RF just because I didn't want to make too many changes to the system and RFconfig is just a consequence of this functionality.

So to go-ahead, Sorry, from comments I missed what you suggest to do:

• split the pr, just to have the RF configuration without *list?
• Or do the Spit and use the configuration strategy also on the sys?
• Or nothing?

[1technophile]

Hi @Odyno

split the pr, just to have the RF configuration without *list? This, I would suggest that we handle system level filter on a separate PR and keep this PR as a refactoring.

I think also that a part of the refactoring could be global (getting a configuration for a module) but let's do things step by step and start by having the refactoring only.

[Odyno]

Hello @1technophile and others, I am sorry for the delay, but I have finally found the time to do your request. I have looked at the pull request, and it is a refactoring of the RFs modules' configuration. I think it can be a good base for all the other modules, but I haven't applied it to all of them yet. In my opinion, it helps to fix some issues by making it clearer where the configuration is and how it is used. This code also allows for a more detailed refactoring of the RFs modules' abstraction. It is your decision to approve it or not.

[Odyno]

@1technophile, any news?

[1technophile]

I will take a look next month