-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Short battery life with devices with bad signal strength #32
Comments
Hello, |
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. |
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. |
Sorry @JsBergbau , I have no instrumentation to measure the powerdraw, at least with something more precise than a simple multimeter. |
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. 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. |
Hi pvvx. MiTemperature2 script sends BT packets to change connection interval and powerdraw is reduced. |
ATC
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
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
https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/ble.c#L81 |
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. |
For this usecase you have the |
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
![grafik](https://user-images.githubusercontent.com/37013344/82160788-4b53a000-9887-11ea-8a80-e1bc16225e26.png)
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.
The text was updated successfully, but these errors were encountered: