[Suggestion] Dynamic Sensor Data Notifications

[k-korn]

Currently the firmware just sends temperature and humidity at pre-configured interval.

In my similar projects with ESP32-based sensor I've used a dynamic approach which reduces the amount of data points sent to HA while maintaining precision. It can be described as follows:

• Let's define a sending threshold (say, 0.1C for T and 0.5% for H) and max send interval (say, 300 seconds).
• Values are measured (but not sent) at regular intervals, as previous.
• If the value is within +- threshold from the last value sent, and if max send interval (from the last time value has been sent) did not pass - do not send the value via BLE.
• If the value changed for more than the threshold, send the value and update time it was sent and update the last sent value.
• If the value did not change significantly, but max send interval passed - also send the value and update time it was sent and the last sent value.

This way, if the value changes fast we will still get frequent upgrades and fast sensor response. And if it changes slowly - we will get 1 value each 300 seconds, but we do know that it changed no more than the threshold from the last one.

This approach worked fine for me for a couple of years and will be great to see it implemented here.

I think I can actually produce the pull request for it, but would need a hint on where in the code this logic is implemented.

[pvvx]

1. How to connect to a BLE device that does not send BLE advertise?
2. Or when the advertise period is more than 10 sec (maximum by standard = 10 sec)?

Old versions of the Linux kernel do not support devices with advertising intervals longer than 4 seconds.
All Xiaomi, Tuya Ble devices use the BLE Advertise interval 1..1.6 sec.
(ESP32 does not support any standards, including TCP/IP, let alone BLE 5.0.)

Let's define a sending threshold (say, 0.1C for T and 0.5% for H) and max send interval (say, 300 seconds).

The described parameters are set in the ZigBee firmware. You can set thresholds in 10C and a period in days.

My air conditioner maintains the temperature more accurately than you describe.

I consider the optimal measurement step for BLE thermometers to be up to 30 seconds and the advertising transmission period to be 5 seconds when accuracy is not required.
The values ​​of one measurement must be transmitted at least twice - two takes. With a measurement step of 20 seconds and a transmission period of 10 seconds (maximum according to the BLE standard), it is not possible to transmit two takes if the sensor has additional parameters (all data does not fit into the short BT4.2 transmission block). Then a larger number of BLE advertisements are required between measurements.

(say, 300 seconds)

Such an interval makes no sense in automation (IoT, Smart Home).

---

AQARA temperature and humidity sensor (Lumi Weather, Zigbee) uses the parameters you specified. When using "Lumi Weather", automation is impossible - comparison with typical BL sensor settings:

[k-korn]

OK, I was not aware BLE needs to advertise every X seconds or the recipient does not get anything - and this might be a deal breaker here.

Anyway, I've used this approach for many years with MQTT-connected devices and it works just fine.

Such an interval makes no sense in automation (IoT, Smart Home).

We are not sacrificing response time or accuracy when setting "idle" interval to 300, or even 600 seconds.
Most automations trigged on "when temperature crossed X threshold", and in our case if the value is constantly rising you will get the fastest response possible, as the temperature will most likely rise fast past the threshold.

Here is an example:

At around 07:20, when the value rapidly changes, measurements are emitted as fast as possible. And then around 8:20 - 8:40, when the changes are minimal, the value gets updated every 10 minutes - and this is still fine.

As for the threshold values - these can be set lower or higher, of course. It was just my gut feeling that temperature changes below 0.1C are not significant for human perception anyway.

[pvvx]

It was just my gut feeling that temperature changes below 0.1C are not significant for human perception anyway.

For some automations, it is not the absolute value that is important, but the trend of change (derivative).

Inverter air conditioners have power regulation in steps, for example in the range from 170 W to 2 kW. A similarity to a PID controller is used and in this case the smaller the measurement discreteness in time and value, the better.

Even for controlling a simple heater, it is desirable to have smaller the measurement discreteness in time and value...

---

People mostly use firmware for LYWSD03MMC. And this thermometer does not have buttons to enable the connection mode (when BLE advertising is transmitted at short intervals).
And according to the history of the development of "Home Assistant", only not so long ago a modification was included for the possibility of receiving non-constantly transmitting BLE devices:
https://bthome.io/format/ -> bit 2: “Trigger based device flag”
This allows to implement the option of data transmission with irregular interval. I will try to implement this option a little later, but for thermometer options that have buttons.

This option does not particularly affect the overall battery life. Other factors have an effect. Usually, over a period of a year, due to the low current consumption, the battery contacts oxidize and the thermometer requires maintenance (you can knock it and the contact is restored).

But in general, the operating time of normal thermometers from one battery (CR2450),
such as MJWSD05MMC, exceeds one and a half years:

And this is when working in LE Long Range mode, i.e. with significantly higher consumption during reception and transmission...