Battery life

[tristone-cz]

Hi all.

I had no troubles to upgrade the LYWSD03MMC to custom BLE and then to 1.1.4.
Z2M works fine, even upgrade to 1.1.7 was relatively smooth.

But what about battery life?
The original battery was depleted in 10 and 12 days (two devices).

Do you have the same experience?
Or there is something wrong with my ones?

Both are placed very near the Zigbee stick, LQI is around 150-200.

[pvvx]

Each Zigbee OTA update requires 20 times more power than BLE OTA.
Several test thermometers with Zigbee have been working for more than a month. There is no critical battery discharge on them.

On Xiaomi LYWSD03MMC B1.4 a month ago it was 2.82V. Today 2.79V. Before this, the battery worked for several months in the BLE version.

[tristone-cz]

OK. Is there some way to influence the update frequency? I did not found in documentation.
These thermometers will not be used in any critical env so even slow (each °C) updates would be OK.

[pvvx]

Compared to the BLE version with default settings (transmission every 2.5 seconds, sensor polling 10 seconds), Zigbee consumption (communication step every 10 seconds, sensor polling 10 seconds) is one and a half times 1.5 times higher.
Plus the dependence in Zigbee on the settings of the minimum and maximum interval and change delta.

Each iteration of transmission and reception in Zigbee requires 4 times more energy than in BLE. And since Zigbee uses a more powerful signal for transmission in dBm, the differences become even greater.

In Zigbee firmware, the sensor is polled every 10 seconds to display and analyze measurements.
This interval is fixed. As this interval increases, the display will no longer correspond to the measurements.

For stable operation in Zigbee 3.0, the communication interval is considered normal up to 7 seconds. If the interval is longer, the connection with the device will be unstable.
For these reasons, Tuya and Xiaomi do not comply with Zigbee standards using their own "standards".
This is the reality of Zigbee.

---

When using any of the Zigbee chips, significantly more battery power is required to meet the standards and functionality of routers and coordinators on the market than devices operating in the Bluetooth v5.
The communication range of Zigbee is 3-4 times less than that of Bluetooth 5.0 in LE Long Range.
And with the release of Bluetooth v5.4, Zigbee becomes completely unnecessary.
For this reason, Linux has not allowed users to use the new Bluetooth standards since 2016.

[pvvx]

I do not have long-term records of CR2032 battery consumption on thermometers with Zigbee firmware.
There are short measurements between different firmware versions.
For BLE option with Zigbee and battery CR2032:

Charts start from the moment of flashing.
This is one thermometer that works simultaneously in Zigbee and BLE.
In BLE, battery voltage data is transmitted with greater accuracy.
The Zigbee coordinator was temporarily disabled for the test, as can be seen in the temperature graph.

[tristone-cz]

OK, thanks for detailed info.
I replaced batteries and will watch it.
Weird is that on the news ones is immediately reported as 40%. I will pick up some serious brand for next round 😄

[pvvx]

Battery charge values are reported using average of 256 measurements. Otherwise the graph will be very noisy.

All batteries have a voltage dependence on temperature.

2 AAA batteries in the thermometer in the refrigerator freezer:

[JayFoxRox]

The original battery was depleted in 10 and 12 days (two devices).

I have been using the bluetooth version for a couple of months already. I don't think I ever swapped the preinstalled battery.

I flashed 9x LYWSD03MMC with the zigbee version last week.
If the zigbee version really dies this quickly then I'll return to the bluetooth version.

Currently the batteries report (in zigbee2mqtt) as 92%, 88.5%, 100%, 86%, 100%, 100%, 98.5%, 88% and 100% (obviously this is after flashing them with the custom bluetooth firmware to then reflash the zigbee firmware).
They all run the zigbee version with the preinstalled battery except the first one (which uses some fresh no-name battery).
They are all B1.7 (I think?) and were manufactured in 2023.02 according to the packaging, again, except the first one (not sure which HW revision).

When using any of the Zigbee chips, significantly more battery power is required to meet the standards and functionality of routers and coordinators on the market than devices operating in the Bluetooth v5.
The communication range of Zigbee is 3-4 times less than that of Bluetooth 5.0 in LE Long Range.
And with the release of Bluetooth v5.4, Zigbee becomes completely unnecessary.

Are you saying we should almost always prefer to operate these devices with bluetooth?
Why put so much effort in the zigbee firmware then?

Personally I'm using a lot of zigbee lamps / switches for cost reasons (although I consider switching buttons to cheap bluetooth camera shutter switches). I also don't want WiFi devices for security/privacy reasons.

I reflashed the zigbee version for a number of reasons:
Primarily, setting up a bluetooth bridge is really annoying and I'm also concerned with the range of bluetooth (as I have many zigbee devices which extend the mesh, but I don't have any powered bluetooth devices).
I knew that zigbee would consume slightly more battery, however, I'm also hoping that battery performance will be optimized over time (hopefully more customization options).

If bluetooth is truly better, then I'd probably return to that.
Both, zigbee and bluetooth end up in MQTT on the same raspberry pi for me anyway.
However, I had problems with sharing my bluetooth device with multiple docker containers in the past, so zigbee using zigbee2mqtt is simpler.

I think it would be great if the README explained the actual benefits. Things like:

• With bluetooth, what is the expected range and when should one use zigbee?
• How long is battery life in practice with the same kind of battery in the bluetooth version vs zigbee?
• ...

In Zigbee firmware, the sensor is polled every 10 seconds to display and analyze measurements.
This interval is fixed. As this interval increases, the display will no longer correspond to the measurements.

Personally I don't care too much about the display. I'd rather have a long battery time and the measurements taken every 60 seconds or so.
Temperature doesn't change too quickly where most of my thermometers are installed anyway.

I'd be much more concerned with the accuracy of the displayed values (so I'd like to see 2-point calibration mode so the device displays more accurate values).

I think a hybrid mode would also be cool, where it would display the clock for 30 seconds or so, and then when the next temperature measurement is ready, it would display the temperature again.

For this reason, Linux has not allowed users to use the new Bluetooth standards since 2016.

I'm not sure what you mean here? Doesn't linux support them? Also if they are so good, why wouldn't they be supported in Linux?

[pvvx]

Are you saying we should almost always prefer to operate these devices with bluetooth?
Why put so much effort in the zigbee firmware then?

I haven't put much effort into the Zigbee firmware. The example provided to everyone in the Telink SDK is used as a basis.

http://wiki.telink-semi.cn/wiki/chip-series/TLSR825x-Series/

Zigbee	TLSR8258/8656	Quick Guide	SDK V3.6.8.6	Development ManualDevelopment Manual (CN)

And I previously described that this would not be a very correct path for thermometers with CR2032. But there was an advertisement about devbis firmware. And I’m just trying to optimize consumption and expand functions.

Personally I don't care too much about the display. I'd rather have a long battery time and the measurements taken every 60 seconds or so.

This greatly limits the scope of application of these thermometers.
If the interval transmission of results exceeds 10 seconds, the thermometer becomes a game thermometer and is not applicable in IoT.
In such conditions, there is no point in transmitting measurements at all, because sometimes it is enough to look at the display.

According to Lewis Carroll, a clock that does not go at all is better: it shows the correct time twice a day, while a clock that is slow one minute a day shows the correct time only once every two years.

I'm not sure what you mean here? Doesn't linux support them? Also if they are so good, why wouldn't they be supported in Linux?

I don't analyze global conspiracies, corporate struggles and other wars. :)

I only know that the Bluetoth standard is open, and in stores for almost ten years there have been cheap chips and adapters available to everyone that work in new versions of Bluetooth. But there is no implementation of their support in Linux. This limits the Web bluetooth API in Chrome and much more. Only Android has support for the new Bluetooth standards in its low-level API. There the kernel is fixed by Google.

[pvvx]

I think a hybrid mode would also be cool, where it would display the clock for 30 seconds or so, and then when the next temperature measurement is ready, it would display the temperature again.

Measuring and displaying does not significantly affect battery consumption. And it does not create large pulsed currents, which have a bad effect on the operating life of CR2032 series batteries.

Transmission current and response wait in the Zigbee protocol have a much greater impact.
This does not depend on the type of chip. Zigbee simply requires more energy per bit to transmit than typical BLE.
Since the duration of transmission of one bit in Zigbee is 4 times longer. Plus, an increase in the transmitter power level is required for reliable reception for older chips in router and coordinator adapters.
To this must be added the more complex software processing of Zigbee messages, which also requires more performance and resources in the chips.

Any device with Zigbee was always more expensive, which affected other protocols. Why sell a product cheaper if you can flash Zigbee and increase the cost?
By organizing this action, a link to the products of one corporation and forcing the user to buy other devices to organize communication between them. At the same time, distribute advertising that Zigbee is the most energy-efficient solution.

Also if they are so good, why wouldn't they be supported in Linux?

Why are smartphones equipped with a BLE chip that has full Zigbee hardware support, but do not work with Zigbee devices?

[pvvx]

I think it would be great if the README explained the actual benefits. Things like:

• With bluetooth, what is the expected range and when should one use zigbee?
• How long is battery life in practice with the same kind of battery in the bluetooth version vs zigbee?

It is impossible to answer these questions unambiguously.
The charge level of the CR2032 battery from different manufacturers and operating conditions vary many times. Some batteries provide only 15% of the capacity of others.

Xiaomi specifically does not install a capacitor in the power circuit so that the use of the battery is limited to 60% of its capacity. At a level of 40% of the actual capacity, the battery is discarded, since with a pulse of transmission current there is no longer enough voltage to operate the chips used. Chip manufacturers and thermometer developers provided space for installing a capacitor, but marketing...

Measured average consumption on Xiaomi LYWSD03MMC B1.4:

1. Firmware version BZdevice - 18..20 µA.
2. Firmware option ZigbeeTLc - 14..25 µA.
3. BLE firmware option - 14 µA.
4. Firmware option z03mmc - 20..40 µA.

Measurements were taken using the default setting (BLE).
The settings for Zigbee were also taken by default, which is what the thermometer itself gives.
The measurements were carried out with minimal deviations in temperature and humidity. When transmissions on a Zigbee network are minimal.
The difference in one average current measurement over a period of several minutes depends on the network activity, transmitting information at random intervals about the OTA to Zigbee (average 60 sec), and the quality of the communication. Many periods include a random delay to reduce network collisions.

• When the coordinator is turned off, the average current consumption of the device increases beyond 0.1 mA.
• When operating OTA - more than 1 mA. For Zigbee this is several minutes, for BLE - up to 30 seconds.
• When connecting a BLE thermometer to ESPHome during data transfer, the average current is more than 3.5 mA.
• When connecting BLE to standard BT adapters, consumption increases slightly. If there is no active data transfer, then consumption is equal to working in advertising mode.
• When the pin code is enabled, the matching also consumes significantly - 3.5 mA, but this is a short moment - up to a couple of seconds.
• Enabled active scanning increases consumption by 5..10% (what may affect the CR2032 battery differently.).

@JayFoxRox - I gave you some of the use cases. The battery capacity is unknown and the effect of pulsed currents on the battery is unknown. Can you write instructions?

[somebody-somewhere-over-the-rainbow]

Measured average consumption on Xiaomi LYWSD03MMC B1.4:

1. Firmware version [BZdevice](https://github.com/pvvx/BZdevice) - 18..20 µA.

2. Firmware option [ZigbeeTLc](https://github.com/pvvx/ZigbeeTLc) - 14..25 µA.

3. [BLE firmware](https://github.com/pvvx/ATC_MiThermometer) option - 14 µA.

4. Firmware option [z03mmc](https://github.com/devbis/z03mmc) - 20..40 µA.

So your zigbee firmware showed almost the same power consumption during normal operations (not including update / flashing) - is that the correct intepretation?

[pvvx]

Not really. 14 µA is obtained if there is practically no transmission between the thermometer and the coordinator.
This can be done artificially - do not subscribe (not bind clusters) to the transfer of measurements (or unsubscribe from the transfer of measurements - unbind clusters).
For example, the transmission of firmware update data - cluster 0x0019 is transmitted at random intervals. And if during the measurement, at least for a minute, they were not there, then there will be a low average flow rate for this period.
It's the same with other surveys on the Zigbee network.
As a result, one measurement of the current period average will have a difference with the other measurements. And the result is determined by many settings of the entire Zigbee network system.
Including transmission confirmation time (processing speed of all network components - routers and coordinator, presence of interference in the radio airwaves).

[slingel]

I'm seeing around 1mA with all your firmwares after interview with Sonoff CC2652P dongle on all my LYWSD03MMC.
Every few seconds current drops below 10µA then right back to 1mA.
With devbis firmware devices immediately sleep at less than 10µA after interview.
I haven't tried 1117 yet.
TS0201 is not affected.

[pvvx]

devbis/z03mmc#11 (comment)

Every few seconds current drops below 10µA then right back to 1mA.

For measurements, the cheapest nRF Power Profiler II is on sale. Has dynamic measurement errors, but this is enough for tests.

[tristone-cz]

Just some graph of original and then "new" Chinese battery. Today I will put there something more serious and let's see.
But the same batteries in many other Aqara zigbee devices work for years.