Short battery life with devices with bad signal strength

[JsBergbau]

Since 25.02.2020 my script dramatically reduces power consumption. However I have one sensor which needed 4 batteries sice then. That's a lot. Look at the graph

So I dug deeper into this. Powersaving of the script is working. I've measured the power draw and noticed about 100 μA on bad reception. It seems that there is some error correction in the BLE protocol that just retransmits the data and thus causing the high power consumption. I even had the situation when it drew 450 μA and even moving it 50 cm beside the reading Raspberry PI Zero W didn't reduce power consumption. Only a reconnect did. However saidly I was never able to reproduce this situation. Seems to be quite rare hopefully.
I doubt that you would save power using the passive mode used by Homeassistant Plugin. I expect in this situations to miss a lot of the advertisments.

So what do do about? I tried to use RSSI as an idicator for high battery drain, but that wasn't successful. It is even not possible to get the RSSI while connected. You have to close the script and then scan for new bluetooth devices and get the RSSI with btmon. RSSI varied between -92 and -100 dBm. 8 dBm is almost 10 times more or less signal strength, so not very practicable.

Since I have a lot of sensors, I have also a lot of experience. If you notice a lot of reconnects (you also see them with btmon), then signal strength is definitively too weak. Try moving a bit. A few centimeters can do a lot. Not only the reconnecting process uses a lot of energy (it takes a few seconds until sensor goes to powersaving mode), but also the higher current with weak signals (see above).

So the only solution I can offer at the moment is to have an eye on your battery levels. If one sensor needs new batteries in a short time, than reduce distance between reciever and Xiaomi sensor.

Here is a diagram with the voltage level in the past 1.5 month. Lets focus on the 4 with the highest voltage. All 4 were deployed at the same day. Voltage level trend is quite parallel. All sensors should have good connection quality. So I think its just different battery capacity or individuell slightly different power draw or this sensor with red chart really has a slightly lower signal strength.
The sensor with the green chart has very low reception level and often disconnects. That uses a lot of energy, too.

So the only solution I can offer is to monitor for your battery level. If it drops by 0.1 V in 1.5 month, then everything is perfect.

[jaggil]

Hello,
A possible circumstance that can occur, when the signal level is not good, is that the command to change the communication interval does not correctly reach the sensor and it continues with the default interval.
@JsBergbau Is this possible? or does the script have confirmation that the parameter has actually been changed to 500ms?

[jaggil]

Hello @JsBergbau , as I have already commented in #23 I am not using your script, and I really don't know in detail how it works.
So I want to ask you if the script includes the possibility to stop the notifications that the sensor sends every 6 seconds and resume them at a specific interval.

[JsBergbau]

Hello,
A possible circumstance that can occur, when the signal level is not good, is that the command to change the communication interval does not correctly reach the sensor and it continues with the default interval.
@JsBergbau Is this possible? or does the script have confirmation that the parameter has actually been changed to 500ms?

The power draw changed in the middle of the connection, so I think there is a layer in BLE that ensures all messages arrive when there is an established connection. And because of this layer the powerdraw rises on bad signal strength, because it retransmits the data.

I've never seen any of the 6 seconds measurements was lost and than another was received later.
Since this layer also ensures that the connection is still alive disabling this notifications every 6 seconds and then enabling it, wouldn't save much power. Do you have the possibility to measure the powerdraw?

[jaggil]

Sorry @JsBergbau , I have no instrumentation to measure the powerdraw, at least with something more precise than a simple multimeter.

[hancockks]

I just received my sensors yesterday and got one hooked up to my rpi 4B. Sensor is within 6 feet of the Pi4 and seeing some odd results on battery level. I thought perhaps temperature related, but it doesn't seem to correlate.

Battery Level

Voltage

Temperature

[JsBergbau]

Up and down in Voltage is quite normal. Here the diagram of a few sensors of the last 7 days

[pvvx]

In the connection mode with the original Xiaomi LYWSD03MMC firmware, if the program does not adjust the connection intervals, the sensor will remove 10 times more energy than in the advertising mode.
Advertising mode - an interval of approximately 1700 ms and a TX packet for each of the 3 channels.
Connection mode - interval 25..50 ms, delay 0, timeout 1000. 50-60 TX packets per second.
Examples of consumption measurements:
https://pvvx.github.io/ATC_MiThermometer/OriginalPower.html
+
https://pvvx.github.io/MHO_C401/power_original.html
https://pvvx.github.io/MHO_C401/power_altfw.html

https://pvvx.github.io/ATC_MiThermometer/CustPower.html

In BLE, the connection intervals are set by the client - the BT adapter. The settings described in the device are sometimes ignored. Depends on BT adapter. Once connected, the device may ask you to change the intervals. Acceptance of new settings depends on the BT adapter.

[JsBergbau]

Hi pvvx. MiTemperature2 script sends BT packets to change connection interval and powerdraw is reduced.
However sometimes on bad connection power draw rises and doesn't go back to low level as with good connection. Only upon reconnect powerdraw gets back.
Since we now have ATC mode this problem isn't so important anymore. All my sensors now work in ATC mode.

[pvvx]

ATC
Advertising interval: 3000 * 0.625 = 1875 ms (+31.25)

#define ADVERTISING_INTERVAL 3000
bls_ll_setAdvParam(  ADVERTISING_INTERVAL, ADVERTISING_INTERVAL+50, ADV_TYPE_CONNECTABLE_UNDIRECTED, OWN_ADDRESS_PUBLIC, 0,  NULL, BLT_ENABLE_ADV_ALL, ADV_FP_NONE);

https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/ble.c#L155

Start Connect interval: 20 * 1.25 .. 40 * 1.25 = 25 .. 50 ms

static const gap_periConnectParams_t my_periConnParameters = {20, 40, 0, 1000};

https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/app_att.c#L49

The intervals requested by the device after connection, taking into account the latency: 8 * 1.25 * (99+1) = 1000 ms

bls_l2cap_requestConnParamUpdate (8, 8, 99, 400);  //1S

https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/ble.c#L81

[HubKing]

Battery life question: When using the stock firmware and the "normal mode", what if I don't need that frequent reading of every 6 seconds? The script does not seem to have an interval option, so the device emits (whether you like it or not) the data every 6 seconds? If so, if I only need to read the data, say once every minute, would it better for saving battery to connect, read values only once, disconnect and repeat this per every minute? If it depends on the interval length, from what length does periodic reconnection become better for the battery life? Because I am sure if I only need to read values once per hour, it would be better to disconnect.

[JsBergbau]

For this usecase you have the -c --count option. Then it gathers one measurement, then the script exits. You can exute it for every hour via cron.
Be aware, that this connection mode is legacy and will be removed it a future version. You should use pvvx firmware https://github.com/pvvx/ATC_MiThermometer