Mi Flora battery life

I’m not sure now, but I also think that the battery got worse after moving from using the RPi’s BT to ESPHome.

I have three of those slightly green bodied sensors and have to replace batteries every two months. I am ready to ditch them now, because that is just wasteful.
Sad that there’s no open source firmware, because this surely is a software fix.

That simply isn’t possible. ESPhome has no effect whatsoever on the device. It listens passively for the device’s broadcast messages.

If they could be reverse engineered the broadcast interval could be made greater to improve battery life. However…

Looking at the graphs of my sensor It seems it broadcasts after a % change in level of the sensor rather than at a fixed interval. Sometimes up to every 30 seconds. If this was made 3 minutes minimum you might get up to 12 months battery life. Probably substantially less though, as it’s not often that I see an update every 30 seconds.

The real issue is that they chose the wrong battery. Two CR123A batteries would be a better choice but would substantially change the “sleek” look of the product.

Hey Tom

How is the battery life going with the franken-flora?
In general, how is it fairing in its new housing?

It’s still going. That’s all I can tell from 5400km away. The broadcast messages no longer contain battery voltage.

That’s not entirely true. For example, by default it uses active scanning, which requests a SCAN_RSP from the device:

I’m also not 100% sure if a scan does not transmit anything, but maybe just setting active scanning to false solves the battery issue?

Not according to the docs:

Unless I’m missing something in the code, the docs are wrong.

scan_type / scan_active_ is not defined in the sensor so that parameter defaults to BLE_SCAN_TYPE_PASSIVE.

Completely agree with this. I have been using miflora for more than a year with a bluetooth dongle and command line readings from a linux script. I changed battery two months ago and that happens at the same time I was migrating to home assistant with an ESP32 reading with ESPHome the miflora unit. It has last for only two months with that config.

Also note that I upgraded the miflora firmware with the updated version which says in the release notes something about ‘fixing issues with battery’.

If fixing issues with battery makes the battery last for two months now, I prefer when it was ‘broken’ and lasts one year for sure.

1 Like

The default for that config is true, with results BLE_SCAN_TYPE_ACTIVE:


Huh. So it is. Bug report?

Or is the scan type defined somewhere else?

Should we create a bug report? It reads like a possibility.


I was about to create bug report, but then checked the documentation, which states that it defaults to active scanning.
Now I added this to my esphome sketch:

    active: false

This should turn off active scanning. All my Mi floras are out of battery, so I will do a test with one mi flora and hope it’s battery lasts longer.

No it doesn’t.

Well yes, it states that for the sensor type, but the parenting tracker type defaults to active scanning, which is the piece of code you abmantis linked to. If you search for it a bit, people are using the combo of switching the BLE tracker to passive plus the flora sensor.

Edit: But feel free to create a bug report if you feel it is one.

Which firmware are you referring to?

I upgraded all my sensors to 3.2.2 and after that I have changing batteries like crazy.

I use the Xiaomi passive BLE custom component though and not EspHome.

…I updated to 3.2.2 too. (don’t remember from which version, I suppose the previous one). Updating and high levels of battery consumption matches with firmware upgrade.

I’m using an esp32 board with bluetooth and ESPHome firmware on it. At the same time I change battery I change the way of reading miflora info. Thats why I’m not sure which is the culprit. Previously I used a bluetooth dongle on a raspberry pi.

Maybe the firmware upgrade was the culprit. It will be nice if there is someway of downgrading our units. To test.

Yes it would seem like a firmware issue then. Don’t know what to do about it though :frowning: