recent changes regarding measurement interval and nasty regression in april (battery drain)

[elmystico]

UPDATE: issue created: #214

Hi

Why is it necessary to allow interval between 3..30 sec?
Up until recently in most of my devices I was using intervals 180 s no problem- I don't need this to be more often.
I think the battery drain got worse now. Also please have a look at this- there was short-lived regression in april with terrible battery drain but it got fixed in a moth or so.
And know after recent changes - not 100% sure too short interval- battery drain got somehow worse again.
Two different sensors below.
I've upgraded all soldering additional capacitors in may (ceramic 1206; 100uF; 6,3V; X5R; (SMD); CL31A107MQHNNNE; Samsung so leakage current neglible)
EDIT: this caps are not so good eventually as they eat ~6uA @ 3VDC it should rather be <1uA so please don't use those caps

[pvvx]

1. Zigbee consumption is more than 60% dependent on the operation of routers and the coordinator.
2. The increase in consumption can be more than 90% at poor radio signal levels.
3. The user settings for "report" also have a strong effect.

The least influence among those listed is exerted by the influence of the sensor polling interval.
Similarly, the LongPoll interval has a low battery consumption value if it is set to more than 10 seconds.
The LongPoll interval setting in the thermometer is not limited.
However, any Zigbee 3.0 device with a communication interval greater than 20 seconds will cause timeout errors in Z2M/ZHA.
ZHA sets the device polling interval to 6 seconds, hardcoded into its code.

Setting the interval is a way to bypass the forced polling interval of 6 seconds for all ZigBee 3.0 devices in ZHA and Z2M.
Fix ZHA and Z2M. After that, you can restore the thermometer to work according to the Zigbee 3.0 standard. Then it will be possible to set any "PollControl" values ​​according to the Zigbee 3.0 specification.

---

It is also necessary to take into account what is described in this post: #210 (comment)
The capacitor in the power supply does not provide a significant increase for the operation of the CR2032 in the Zigbee version. The reasons are simple - Zigbee uses longer transmission and reception times. During this time, the capacitor's capacity is discharged and the battery experiences increased current, causing degradation of the CR2032. And a capacitance with a higher nominal value has increased leakage.

But users require to increase the transmitter power to +10 dBm. Then the pulse current will be more than 25 mA. But this will not help to increase the communication distance in Zigbee. It will be necessary to increase the power of the Zigbee coordinator so that the thermometer can hear it at a greater distance. But for most users this is not clear :)

---

Over a period of 4 years of operation of thermometers with CRxxxx batteries, the following has been noted: On average, over a period of 1 year, oxidation of the battery contacts occurs. The current is small and cannot "break through" the formed oxide film of the contacts or something in the battery itself. If the thermometer is hit, everything is restored. Sometimes, with a current pulse during transmission, the contact is restored by itself. The capacitor smooths out the pulses and the contact may not be restored. (This is the only negative phenomenon when using a capacitor in the power supply of thermometers.)

[elmystico]

quick update: I've checked some specs it looks that optimally you can get:
100uF 10V tantalum @3v 2.25uA
47uF 25V ceramic @3v 0.6uA

Those are 1€ each probably twice cheaper so comparable to battery or even less. My concern is to have possible low maintenance not necessarily cheapo what do you guys think 47uF? I would solder this one as a replacement to Sonoff as well.

[pvvx]

Those are 1€ each probably twice cheaper so comparable to battery or even less. My concern is to have possible low maintenance not necessarily cheapo what do you guys think 47uF? I would solder this one as a replacement to Sonoff as well.

When purchasing one piece or a batch of capacitors, the price may differ by hundreds of times. The same applies to who the purchase is made from... Therefore, I cannot recommend any specific option.
Only conditionally by nominal values, averaging all types of capacitors - this is about 20..60 μF and from 25B.
(Our price for these capacitors is less than $0.07 per piece. The cheapest CR2032 are in the Fix-price store ~$0.08..0.1 in a set of 8 pcs. These CR2032 work from 8 months in LYWSD03MMC in BLE with default settings and without capacitors. The included CR2032 batteries when you purchase the LYWSD03MMC last for over 10 months. CR2032 for over $4 - work for over a year. But not all - lots of fakes. CR2450 - more than 2 years. )

CR2050 fits LYWSD03MMC without modifications. But there are no statistics on operating time yet. So far they work...

There can be no statistics for Zigbee. The dependence on external factors is very strong - exceeds 80%.
In some Zigbee networks, one Zigbee OTA can consume more than 30% of the CR2032 capacity. Or when the Zigbee network is lost, the consumption for searching for the network increases the average consumption current from 20 μA to 120..800 μA (This problem can only be solved with a battery-powered Zigbee router).
For BLE - no more than 15%, subject to passive and active scanning. BLE connections or OTA operation are not taken into account.
Operating conditions - from +20C to +25C. If it deviates from this range, everything will be different. Then the best readings are given by CR2032 with a higher cost (more than $3).

PS: After using different thermometers for more than 4 years, I no longer use Xiaomi LYWSD03MMC and other thermometers with screens and CR2032 and do not recommend buying them. Only CR2450 or 2xAAA.
Today, in my working configuration in Home Assistant, I use only one Xiaomi LYWSD03MMC in BLE mode and even then, with the display turned off. The rest are only for testing firmware for you and their readings are not used in automation.

[pvvx]

Finally- you mention BT vs ZB... could you share what do you use personally in what circumstances?

Zigbee devices have to be used only as actuators. And for sensors, I always use BLE whenever possible. When the distance for sensors is large - then only BLE in the "LE Long Range" mode. This gives a distance twice as great as any Zigbee. And considering the quality of purchased Zigbee devices by antennas, especially from Tuya, the difference in distance reaches more than 4 times.
Conditions for radio pollution can be different. I have no noise from third-party WiFi, etc. Therefore, the connection in BLE works up to levels of -110 dBm, which no Zigbee or WiFi can provide. And operation at levels up to -115 dBm in BLE LE Long Range provides a communication range in a straight line of up to 1 km. Which completely satisfies the dimensions of my site.
If I were to use Zigbee to provide communication with all devices, I would have to have a bunch of Zigbee routers outside. And they consume significantly more, and there is no point in pulling wires throughout my entire living area.
3 regular USB-BT adapters used in one Home Assistant server accept all hundreds of my BLE. And the reliability of such an implementation in my conditions is higher than when switching to Zigbee. The lowest reliability for IoT is for WiFi devices, followed by Zigbee.

Average parameters for the confident reception level of modern chips:

• WiFi - up to -85 dBm (only 1 channel is used for communication and can be noisy)
• Zigbee - up to -95 dBm (only 1 channel is used for communication and can be noisy)
• BLE "LE Long Range" - up to -110 dBm (3 channels are used for beacons and all for connection with the choice of the least noisy)

Every 6 dB is a distance of 2 times.

[elmystico]

Thanks a lot.
This is against what I was thinking. I was avoiding BT sensors for no strong reason I was just assuming it's inferior to ZB furthermore I was guessing when "starting home automation hobby/just upgrading my place" 'binding' functionality when you can have something still working even when coordinator dies is much more common but it seems in reality it's implemented only for lights in reasonable amount.
Well now I'm thinking I'm going to switch firmwares eventually :-) but I rather stay with my current sensors for now their reliability is enough for me.
Last year I bought few dozens IKEA CR2032 cheaply. They we're phasing them out and I guess that's why you could buy them online elsewhere. I think they are working for a year more or less with ZB one of best batteries but sadly- I've just checked quickly- those are not available anymore. So I've got about two years left of supply :-) then I'll going to need to find next solution.
I wonder why are you not using sensors with display- is it just battery drain thing or is it something else?

[pvvx]

I wonder why are you not using sensors with display- is it just battery drain thing or is it something else?

I use sensors with a screen and CR2450 batteries. For example, Xiaomi MJWSD05MMC and MJWSD06MMC. And other types with 2xAAA batteries.
A sensor with a display requires a screen refresh.
An adequate screen refresh period should be less than 10 seconds. A CR2032 battery is not enough to operate the screen for a year.
If you turn off the screen and unsolder the display chip, then even the cheapest CR2032 will work for more than a year and a half in BLE. This is with a beacon with a period of 5 seconds and a temperature and humidity measurement step of 20..30 seconds.

Power consumption of Xiaomi LYWSD03MMC HW: B1.4:
In pause (sleep mode):
up to 2 μA without display chip
from 6.5 μA when display is on
For other types of HW LYWSD03MMC is much higher.
As a result, the total average consumption without display at default settings will be about 7..8 μA, and with display more than 14 μA.
Software display shutdown is not possible on all versions of Xiaomi LYWSD03MMC.
The procedure of data transfer to the display takes a very long time for the CPU on the latest version of HW: B1.6 LYWSD03MMC, which went on sale in 2025. This significantly increases battery consumption. That is, the LYWSD03MMC package is constantly getting worse...

---

And what's the point of looking at the temperature and humidity on a small screen if there are always the same readings when the automatic humidity and temperature maintenance in the living space is working?
The screen will always show the readings set in Home Asistant.
As a result, a couple of screens with temperature and humidity, but showing data from the street, are enough.

Many years ago, when I started building a Smart Home system, I still looked at the temperature and humidity on such thermometers. But after several years of the system's operation, I became completely uninterested in it. I noticed that I was no longer interested in the fact that they show the same values ​​there. Sometimes I look at the graphs in Home Assistant to debug new scenarios and control.

In utility rooms, everything is similar. For example, in the garage - turning on additional heating is still done through the smart home system and knowledge of the current temperature does not mean anything and will not help to heat or cool the room faster. You will have to turn to Home Assistant. And there are all the readings and more visual ones.

---

The habit of looking at small displays comes from the desire for control. And the desire for control arises from the unreliability of the system. If your system has been working without failures for many years, then all these desires will disappear.
And for the reliability of the system, you first need to exclude all sensors on WiFi, install autonomous Zigbee routers and switch most sensors to BLE. Then you will only be bothered by periodic change of batteries according to the schedule and monitoring of the failure of actuators.
And this is a completely different topic - the topic of reliability and control. And nothing on the topic of reliability is implemented in systems such as Home Assistant. As a result, you have to create your own modules that duplicate the work in case of failure of the main system and control of each actuator (including the refrigerator :) ).
Here it turns out that Zigbee and others cannot work in a duplicate version for communication with sensors. Only BLE is suitable, since any sensor transmits data to everyone...

---

Example: a water storage tank in the attic.
Data from it goes to the pump via Home Assistant.
The pump is generally outside the house. It has a control and monitoring system: leaks, excess start current (jamming), temperature. On/off commands come via Zigbee from Home Assistant. But BLE also works, receiving data from the tank and a beacon from Home Assistant directly. If the signal from Home Assistant disappears for a specified period, then control switches directly from the tank signals. Otherwise, the level may overflow, which will cause an emergency drain... And also, even without power supply, you can always view the water level in the tank on any smartphone via BLE and any panel with an autonomous power supply can show the water level, without any Home Assistant or WiFi routers.
And so with all actuators. The external unit of the air conditioner is duplicated and monitored for energy consumption, operation of the anti-icing system and the outlet temperature of the refrigerant... With the help of graphs, you can always find out when maintenance is required and determine the quality and energy efficiency of using different systems to maintain the temperature in the room...
Also, all existing systems with autonomous power supply transmit data on batteries for monitoring...
Example: Power supply and Li-On battery of the system itself with Home Assistant:

Refrigerators are also monitored for compressor operation and are switched off in emergency cases (with notification)...
Small refrigerator:

...

I have been doing approximately such modifications of the system lately as a hobby. And thermometers are only a very small part and are no longer interesting at all.
As a result, Home Assistant receives more technical information via BLE than data from stupid thermometers...

[kbullet]

Any updates or workaround for this? Maybe I should roll back to earlier versions as currently I have to replace every 1-2 months which is not really sustainable