New feature added: Global Message Filtering + Unit Tests. Shall we discuss merging this into develop?

Theengs OpenMQTTGateway
1

Hello,

I have submitted a PR ( [SYS] Feature/global filter and tests by Odyno · Pull Request #2252 · 1technophile/OpenMQTTGateway · GitHub ) for OMG that introduces a new feature, along with unit tests and some refactoring required to finalize the functionality. I hope I have followed the right path as described in the community discussion here: Maintainer Preferred Path: PR or Discussion First? + Long-Term Plan Inquiry .

The main feature is a filtering system that allows managing output messages from the broker. It works at both the message and topic levels, and it is possible to create rules for explicit allow or deny. (Full documentation here: OpenMQTTGateway/docs/use/gateway.md at feature/global-filter-and-tests · Odyno/OpenMQTTGateway · GitHub )

To support this feature, I also added unit test capabilities. It is now possible to create unit tests for both embedded and native environments (other documentation for test: OpenMQTTGateway/test at feature/global-filter-and-tests · Odyno/OpenMQTTGateway · GitHub ). Currently, there are already more than 150 unit tests available for this functionality.

This system is on top of the development branch but not based on the HEAD of the development branch; it builds on the PR we have been discussing for over a year regarding configuration management. ( The full story here [RF] Refactor RF Configuration Management ( first part of PR Introduced WhiteList and BlackList of RF Signal ) by Odyno · Pull Request #2181 · 1technophile/OpenMQTTGateway · GitHub and then [RF] Introduced WhiteList and BlackList of RF Signal ( code from #2181 PR) by Odyno · Pull Request #2237 · 1technophile/OpenMQTTGateway · GitHub and finally [RF] Refactor RF Configuration Management by Odyno · Pull Request #2245 · 1technophile/OpenMQTTGateway · GitHub )

Consequently, this branch includes necessary refactoring in the following areas:

Given the amount of work involved and the discussion, I would appreciate it if you could evaluate whether this approach is of interest.

If so, we could consider merging back into the developement branch and then proceed with further improvements (e.g., additional configurations or removing filters currently limited to Bluetooth, etc.) to avoid making this merge overly complex.

If this direction is not aligned with the project’s priorities, I will continue developing this version independently without further requests for integration. I simply need clarity so we can either move forward

2

Great, I like the filter functionality!

I have merged the RF configuration management, thank you.

Do you think as a next step we could isolate a PR related to Log management ?

I’m worried that we may have to remove some existing features due to this but would like to have a PR dedicated to this for better clarity.

3

Very good, I’m happy about that!

Regarding the LOG system, it was a big nightmare for me. The main problem is that it’s everywhere: it’s not explicitly imported, but it works because of a chain of inclusions, and it’s not really compatible between platforms. For example, if you use the F() function in Arduino logs, it causes issues on the 8266 architecture.

In the MR, I just exposed it in a separate file and tested it. That’s where I found the incompatibility with the F() function. After fixing that, I discovered a problem with cyclic inclusion when you explicitly add the include file at the top of modules.

Maybe I missed something; if it appears, it was not in my scope. However, I tried to maintain the same functionality. An extra MR just for the LOG system can be provided, but from my experience in this project, I’ve learned that issues only appear when you try to use it in a complex environment, which is not easy to simulate.