Skip to content
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

No issue, need explanation regarding intervals and battery consumption #23

Closed
nortuzar opened this issue Jan 24, 2021 · 20 comments
Closed
Labels
documentation Improvements or additions to documentation

Comments

@nortuzar
Copy link

Hi, I flashed the software on 3 LYWSD03MMC. Its working well, but Im not an expert so Im kind of lost when trying to optimize life battery.

  • Advertising interval is 2500, this is milliseconds? Can I increase this as much as I want? Like I only need 5 minutes updates

  • What happen when the option Sensor in "Low Power mode" is active?

  • I understand The RF TX Power is the strength of the signal, can I lower it making sure the signal is received by my ble host? (rasp w)

Thanks for the help, nice work!

@pvvx
Copy link
Owner

pvvx commented Jan 25, 2021

  • Advertising interval is 2500, this is milliseconds? Can I increase this as much as I want? Like I only need 5 minutes updates

Max 10 sec (10000 ms). Not all devices can connect if parameter above 3 seconds.

  • What happen when the option Sensor in "Low Power mode" is active?

Less consumption, less accurate temperature and humidity readings.
Factory setting + "Low Power" sensor installed - 4% reduction in energy consumption.

  • I understand The RF TX Power is the strength of the signal, can I lower it making sure the signal is received by my ble host? (rasp w)

Very little dependence on energy consumption.

@pvvx
Copy link
Owner

pvvx commented Jan 25, 2021

RF TX Power: 0 dB
Advertising interval: 10000 (10 sec)
Measure interval: 10 (100 sec)
LCD not show battery.

The expense is reduced by 53.2% of the default.

@nortuzar
Copy link
Author

nortuzar commented Jan 25, 2021

RF TX Power: 0 dB
Advertising interval: 10000 (10 sec)
Measure interval: 10 (100 sec)
LCD not show battery.

The expense is reduced by 53.2% of the default.

Great, using the last fw 1.6, set it up as you said and disable the "Low power mode" to gather better accurate readings. The RF TX Power could only select Vant +0.04dbm, is the same as 0db?
Like this should be ok?
Capture

Thanks for the great firmware

@pvvx
Copy link
Owner

pvvx commented Jan 25, 2021

What are you saving?
By default, if CR2032 is 200mAh, only change the beacon interval:
image
More accurate data cannot be obtained. Affected by humidity, battery quality, variation in chips parameters, options, number of connections, ...

@MacSass
Copy link

MacSass commented Feb 11, 2021

Hi @pvvx ,
can you quantify power usage for showing battery, vs. not showing battery on LCD? How much would it "cost" showing battery level vs. default settings?

Also, when I increase the "Minimum LCD refresh rate", to e.g. 5 seconds - does it mean LCD only refreshes every 5 seconds?

Would that have a beneficial effect for battery life? Does refresh need much more power compared to just "show" something on LCD? As LYWSD03MMC does not have e-paper but standard LCD I would think that "showing" would be similar to "refresh" (while real e-paper only needs power when refreshing)?

Thanks for your help getting the most out of those small devices ...

@pvvx
Copy link
Owner

pvvx commented Feb 12, 2021

can you quantify power usage for showing battery, vs. not showing battery on LCD? How much would it "cost" showing battery level vs. default settings?

Battery level measurement no more than 200 μs at 4 mA
The default battery measurement cycle is 10 seconds (10,000,000 μs).
Average consumption: (200 * 4) / 10,000,000 = 0.00008 mA = max(!) 80 nA

Also, when I increase the "Minimum LCD refresh rate", to e.g. 5 seconds - does it mean LCD only refreshes every 5 seconds?

image
The LCD is updated every 5 seconds (5000ms),
LCD refresh procedure takes less than 1ms at 4mA:
Average consumption: (1 * 4) / 5000 = 0.0008 mA = max(!) 0.8 μA

The rest of the equipment at default settings consumes less than 15 μA
CR2032 = 200+ mAh.

Would that have a beneficial effect for battery life? Does refresh need much more power compared to just "show" something on LCD? As LYWSD03MMC does not have e-paper but standard LCD I would think that "showing" would be similar to "refresh" (while real e-paper only needs power when refreshing)?

LCD consumption is less than EPD (Electronic-ink).
E-ink requires increased voltage for renewal and the consumption for DC-DC is quite large.
https://pvvx.github.io/MHO_C401/power_altfw.html

@MacSass
Copy link

MacSass commented Feb 12, 2021

Thanks a lot - looks like I don´t have to worry about LCD update cycle then and not about battery measurement ... so I guess I will leave all that at default values.
Eventually I will look at replacing the CR2032 with 2xAA Batteries where the sensor is hidden anyways - that should give really long life ...

Thanks a lot for our deep analysis and inputs.

@pvvx
Copy link
Owner

pvvx commented Feb 14, 2021

Average power consumption of LYWSD03MMC custom firmware (v2.1)
https://pvvx.github.io/ATC_MiThermometer/CustPower.html

Average power consumption of Original Xiaomi LYWSD03MMC sw ver: 106.
https://pvvx.github.io/ATC_MiThermometer/OriginalPower.html

@pvvx pvvx added the documentation Improvements or additions to documentation label Feb 14, 2021
@jds11111
Copy link

jds11111 commented Mar 1, 2021

Am trying to decide if it is worth reflashing my 14 devices with your new firmware, instead of Aaron's. Did you happen to compare power consumption with that firmware?

@MichielioZ
Copy link

@penright Please just attach a file or provide a link to a file with this output. Right now it's so long, I think people will not read anything underneath it. Besides: the data only confirms that you were not lying about what you said, then again, nobody assumed you were lying...

@pvvx I use your custom firmware, so thank you for that. While I admire your expertise on this subject and can appreciate you making all the difficult calculations, as a user I just want simple settings...
I think most people will want the longest battery life possible, but have no idea how to use the settings, as they are too technical.
You mentioned earlier:
`RF TX Power: 0 dB
Advertising interval: 10000 (10 sec)
Measure interval: 10 (100 sec)
LCD not show battery.

The expense is reduced by 53.2% of the default.`

Did I read this right ? Do these settings make the battery last a LOT longer compared to the default settings ?
If so, why are these not the default ?

@penright
Copy link

penright commented Mar 4, 2021

As per @MichielioZ suggestion, here is the output of ESPHome log showing the Bluetooth advertisements received.
I was expecting to see a regular advertisement for the device (ATC_4F193D). Does it only advertise when a value has changed?

Trying to detect a failed or not responding device is what got me started down this path. Since from ESPHome perspective, the event is random. So I thought I would use HA last_updated state attribute. Looks like HA only updates the state if the state changed. So the question becomes what is the max time to allow for a temp change before declaring the ATC device missing. So I created a sensor that would be updated on every received advertisement. There are two ways, one is using the "on_value" event or baking it into the "atc_mithermometer" component. That is when I noticed the irregularity of the advertisement. I was searching for information and ran across this ticket. I thought the question would fit, but by adding the "and battery consumption" maybe I should open a new ticket?

The only explanation I can think of, ESPHome missing an advertisement, or ATC has some algorithm that skips trying to save battery. Understanding that will help set the "max" receive timeout.

ESPHome_Log_.txt

@MichielioZ
Copy link

MichielioZ commented Mar 4, 2021

@penright I use the "Passive BLE monitor" (ble_monitor) integrations in Home Assistant and with the default settings of the firmware I get a regular update interval of 1 minute. Sometimes it skips one, but that happens rarely. Maybe it's an ESPHome problem you are having ?

On a side note: everyone seems to constantly be confused by the term "Advertising interval", since as far as I understand this is not the same as "Send update of data"-interval (which everyone seems to think it is).

@pvvx
Copy link
Owner

pvvx commented Mar 14, 2021

Did I read this right ? Do these settings make the battery last a LOT longer compared to the default settings ?
If so, why are these not the default ?

The increased advertising interval makes it impossible to connect to the device with old BT hardware, Apple and other poorly written drivers and systems.
The default (2.5 seconds) is already on the verge of being compatible with older BT hardware.
Apple's recommendations say up to 2 seconds, and according to BLE standards, up to 10 seconds.
The default (2.5 sec) is already on the verge of compatibility with older BT hardware.

@MichielioZ
Copy link

@pvvx Ah, ok, that explains why it isn't the default, but 53.2% better power usage is still worth mentioning somewhere...
My phone has BT 5.0, so pretty new version.
Is it safe to try out loading these "optimal" settings with my phone ?

In daily use I use them with my Raspberry Pi 3B onboard BLE (BCM43438 chip).
If they don't work with my Pi I should be able to safely return the old firmware with my phone, right ?

@pvvx
Copy link
Owner

pvvx commented Mar 16, 2021

If they don't work with my Pi I should be able to safely return the old firmware with my phone, right ?

If it will be possible to connect to the device for which you set the interval of 10 seconds :)

For example, I'm interested in data with a step of no more than 10 seconds. Because the dropouts of BLE packets prima in a noisy environment of radio broadcast are about 8%, that is, 4 duplicate beacons with an interval of 2.5 seconds are a guarantee. I would like to have a measurement interval even less - about 1 second, but the battery is weak ...

At the same time, ESPHome users complain about its work - ESP32 has a lot of unaccepted packets, and data update gaps are tens of minutes when transferring a data device every 2.5 seconds.
At the same time, they require me to correct the program in the thermometer :)
This is possible only if the data is transferred dozens of times more often, which will drain the battery in a month. The main thing is for the ESP32 to work :) ESP32s are Espressif buggy chips and software, that don't have and are not open-source.

@MichielioZ
Copy link

If they don't work with my Pi I should be able to safely return the old firmware with my phone, right ?

If it will be possible to connect to the device for which you set the interval of 10 seconds :)

Yes, that's why I asked if my Phone (with Bluetooth 5.0, so newer version) could still connect if I set the interval to 10 seconds.
That way I could test it with my Raspberry Pi and if it didn't work, go back to the old settings...
Guess I will just try my luck with 1, no pain no gain ;-)

I understand it is hard for you to try and satisfy everyone.
Also to cover all implementations of Bluetooth seems impossible.
But if the difference in settings can be 1 month battery and up to 1 year battery, we just have to test and let people know what works...

If for example I find that I can safely test up to 10 secs interval with my Phone
(Qualcomm SDM730 Snapdragon 730, Bluetooth 5.0, A2DP, LE) we can let other people know it is safe to test with similar hardware...
ESP32 boards may be quirky when it comes to Bluetooth, but it doesn't matter if I have a Phone or another device that I can use to adjust the firmware settings...
I will let you (and others) know my experiences after I know the limitations of my Phone (I have some ESP32 boards to test with).

@MichielioZ
Copy link

MichielioZ commented Mar 16, 2021

Testing update:

For the time being I only tested with the Advertising interval and Measure interval combination.
I didn't touch any other settings except I hide the annoying smiley ;-)
So I did not set RX TX Power to 0, but left it at VANT +3.01 dbm.
A/M of 5000/5: working, no further testing done yet.
A/M of 8000/8: working, no further testing done yet.
A/M of 10000/10: slow to connect and update, but working.
Last setting also works with my Raspberry Pi 3B but it doesn't pick up most of the broadcasts at 3 meters distance.
In Home Assistant the update interval seems to be between 10 and 20 minutes, so yeah, not great...
Going to go back 1 step and test some more... I'll be back ;-)

Edit: Went all the way back to 5000/5 combo, but at 3 meters still not a regular update interval in HA. Moved it to like 20 cm from my Raspberry Pi and now I get regular intervals of 1 minute (default setting in Passive BLE Monitor add-on in HA, it takes all measurements from 60s and stores the median). Conclusion for now: For all 3 test settings I am still able to update with my Phone. Anything other then the default settings (2.5s) and further away then approx. 1m has updates on my Pi that are irregular and with (much) longer periods in between...

Edit 2: All my sensors further away then 1 meter (all but 1) are now back to default settings (2.5s) as my Raspberry Pi has trouble getting regular updates otherwise. The one next to my Pi has the 10000/10 setting with an RX TX Power of +0.04 dbm and is updating regularly. My guess is that with a decent antenna the chip (BCM43438) should be able to use the optimum settings further away...

@pvvx
Copy link
Owner

pvvx commented Mar 17, 2021

But if the difference in settings can be 1 month battery and up to 1 year battery, we just have to test and let people know what works...

The default settings should be comparable to the original firmware in terms of consumption.
At current default settings, consumption is less than that of the original.

@pvvx
Copy link
Owner

pvvx commented Mar 17, 2021

Testing for the number of drops in receiving Advertising packages from the sensor.
The default settings are 10 meters to the sensor, the radio environment is noisy - more than 3 thousand third-party beacons per second, several WiFi routers.

Any USB-BT adapter - not received packets > 90%.
Any Sniffer - about 5% not received packets due to collisions on the radio air from nearby sources (mainly WiFi routers).

@pvvx
Copy link
Owner

pvvx commented Mar 17, 2021

@MichielioZ

I understand it is hard for you to try and satisfy everyone.
Also to cover all implementations of Bluetooth seems impossible.

There are sources-code for any case.
The my license does not prohibit copying, distributing and modify parts of the project at your discretion, even without pointing out the source from me. Reference to other sources should be requested from the authors. Create your repository and describe what you like there...
I do not have the opportunity to test all the options and support this project for more than a couple of months. Moreover, I don’t know and don’t want to learn English. Much not to describe with the help of a google translator.


The main trouble with Xiaomi LYWSD03MMC is that greedy Xiaomi did not supply the power capacitors that are provided on the PCB. Because of this, the device has a large scatter of measurements the temperature and humidity, and the TLSR8251 cannot provide the calculated RF output power.
CR2032 has a large internal resistance and cannot deliver the required current for transmitting an RF packet already at 0 dB.
In this option, it is not necessary to talk about some duration of work CR2032. A strong dependence on the manufacturer and manufacturing technology CR2032 will be observed.
Practice shows that the absence of capacitors in the power supply does not allow making connection with the cr2032 that have sat down.
When a capacitor is installed in the LYWSD03MMC, operation from the CR2032 continues until discharge to 1.8 V.
Also LYWSD03MMC has a terrible LCD display.
I do not recommend using LYWSD03MMC at all.
In CGG1, everything is done much better and more accurate... But this product is not Xiaomi.

@pvvx pvvx closed this as completed May 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

6 participants