What is the criterion based on which Tasmota sensor support is compiled in by default or not?

[ntninja]

In particular, I noticed that Tasmota appears to support several different I²C ambient light sensors, but none of them are supported by default. According to https://github.com/arendst/Tasmota/blob/development/tasmota/include/tasmota_configurations_ESP32.h the MAX44009 would only add 0,8kiB of code size, SEN0390 LuxV30b only 0,5kiB and the VEML770 a larger 4,5kiB. On the other hand the AS3935 Lightning/Thunderstorm Sensor is enabled by default?

Is there any particular rationale behind these decisions, because I find it hard to believe that a Thunderstorm detection sensor would be more popular than a basic ambient light detector? (And obviously I’d like an ALS sensor to also be enabled-by-default, but again, I’m sure everyone has their favourite pet-peeve-sensor they’d assume “obviously” should be enabled-by-default…)

[sfromis]

There are no "rules" or defined criteria, but when it comes to commonality there are indeed several ambient light sensors available, meaning that each of those does not count strongly in "popularity", and contrary to what you state, standard ESP32 builds includes BH1750, analog LDR, and also UV sensor VEML6070.

OTOH, the AS3935 has a lot less "competition", and while it may be less popular than the whole category of ambient light sensors, that is not in itself an argument for adding further specific ones of the latter. Not trying to argue about what "should" be added, or making claims about what's widespread in the wild, more to illustrate the complexities.

History plays a role too, and there is a tendency for drivers added more recently not being seen as something which immediately "belongs" in the default builds. Risk of I2C address clashes can also count against particular sensor drivers, and of course size requirements. As you can see in the linked builds table, standard-included sensor drivers largely match what's in the space-restricted sensor build for the 1 MB ESP8266 memory model.

Of course, with the browser-based build tools available (no install needed), adding your favorite one(s) is not much work or complexity.

[ntninja]

Thanks for pointing out the BH1750! I had only searched for “light sensor”, so I missed this one since the description instead says “luminosity sensor”. As it is also sunlight compatible, I based my design on that sensor (Adafruit board) instead!

I suppose the argument there boils down to: BH1750 support was there first, so MAX44009 and SEN0390 didn’t get added by default after that. As long as there is no outstanding characteristic of the newer sensors that the older sensor didn’t also support, that is fair I suppose.

As for browser-based build tools: For me at least, having a ready-to-flash one-size-fits-all image is kinda the unique selling point of Tasmota over ESPHome to me. It’s just very nice to have things be that simple (updates!) on that front!

[sfromis]

With the many ESP32 variants available (different models, and also with variations in having octal/quad/standard SPI), even expanding the current standard build set across all would lead to an impractical high number of builds every time.

What I'm doing is to make a "my expanded" build (within a chip architecture) to be used across devices where the default builds did not include my selection of options, avoiding getting close to per-device builds.

My experience with the BH1750 is that it works well, only smaller weakness is that integer-only lux values does not pick up variations in rather low levels of light.