The provided driver has built-in maximum values such that if the sensor reports above 100% or 102.4% (depending on precision setting), the maximum value is reported, rather than what the ADC is reading. However, given the stated accuracy from the data sheet, its possible to be in a state where the BME280 functions correctly, and still reports that value. That is, 99.4% relative humidity, +/- 3% humidity, includes 102.4%
Are those limits built into the hardware?
I removed the min/max values from the driver to see if I could characterize the accuracy in the top 5% of the sensor's stated range. However, the readings still maxed out at 102.4%. If that limit is built into the hardware, the range should more correctly be stated as (accuracy at min) to (100 - accuracy at max).
All compensate functions (double and fixed point), when out of range , MUST NOT report xxx_MAX ( or xxx_MIN),
rather they MUST report xxx_ERR.
It appears that recent changes to BME280_driver/bme290.c ignored the statments
var5 = (var5 < 0 ? 0 : var5);
var5 = (var5 > 419430400 ? 419430400 : var5);
// 419430400 is 0x19000 which is decimal 100<<12 in 22.10 format
Which (INCORRECTLY) set the return value to 100.00 when the value is greater than 100.00 (format 22.10)
Current coding practices suggest that these should be constants in the bme280.h file
For example something similar to:
#define TEMPERATURE_MIN -40.00
#define TEMPERATURE_MAX 85.000
#define TEMPERATURE_ERR 88.000
#define HUMIDITY_MIN 0.000
#define HUMIDITY_MAX. 100.00
#define HUMIDITY_ERR 200.000
#define HUMIDITY_MIN 0
#define HUMIDITY_MAX 100<<10
#define HUMIDITY_ERR 200<<10
And the code something like:
if ( (humidity < HUMIDITY_MIN) || (humidity > HUMIDITY_MAX ) ) return HUMIDITY_ERR;
It seems nearly impossible to correctly provide a code segment containing a hash symbol here as the web page insists on doing a search when one is entered.
I give up trying to make this a correct code segment.