#define USE_BMP is disabled in FIRMWARE_WEBCAM

[belveder79]

I was wondering about the reason that the USE_BMP is explicitly #undefed in tasmota_configurations_ESP32.h in the first place, but in the second place, I was wondering about your thoughts of this creating a not-so-obvious flaw in the configuration by users for other #defines as well.

Because I have a multitude of ESP32 cams with an BME or BMP sensor attached, I repeatedly have to recompile Tasmota from GitPod. So far, so good. However, the change of the user config has no effect, so I have to resort to changing files that I'm not supposed to change, namely tasmota_configurations_ESP32.h. Because there is a hardcoded #undef, setting the USE_BMP in the user_config_override.h is overridden.

This is natural by the inclusion order in tasmota_options.h, which says

#include "../tasmota/my_user_config.h"
#include "../tasmota/include/tasmota_configurations.h"

I know that in a project using #defines and #undefs it is impossible to make "every option" work. I was just wondering if it wouldn't be doable to prepend any user-defined setting in my_user_config.h with some USER_ prefix or something and then create a Macro that sets the user option that way and enable an explicit override of the standard options, rather than just hard-coding an #undef somewhere.

[sfromis]

The intention is that you either use a ready-made build environment (like the webcam one), or make your own set of #define, possibly creating another build environment, with "inspiration" from existing ones. This means that you do not "have to resort to" modifying any build environments, that was just what you chose to do instead.

Sure, the number of lines needed to include features from a predefined build environment along with your own additions is more than what would be needed if having the ability to add/subtract individual features when using a predefined one...

[belveder79]

Sure, the number of lines needed to include features from a predefined build environment along with your own additions is more than what would be needed if having the ability to add/subtract individual features when using a predefined one...

That's exactly why I posted this as a thought/idea. I'm perfectly happy with the way it works, relying on my own swiss-cheese-like memory and notes to repeat what I did weeks ago and just redo it from time to time... 👍

It is just the fact that there are some (not all) particular #undefs for certain (and not all) types of sensors in certain (and not all) configurations, which makes an arguably minor tweak to an existing configuration a bit of a trial-and-error process. While I believe to be already pretty firm in getting out what I want in the end by doing whatever I need to do in the source, I think that there are more QA asked in the forum about things like this, simply because the user config does not reflect what it does in this special case, particularly for the more novice users...

[sfromis]

Where it can get tricky is when certain features needs more build setup tweaking than just having some #define/#undef. Other than that, the basic "rule" is that the hyphenated configs tasmota32-something are fixed when it comes to adding/subtracting features, with the non-hyphenated "tasmota32" being where amendments are open. And both allow defaults changes like Wifi credentials.

[belveder79]

true... just wanted to share my thoughts...