High battery consumption about z03mmc

[pvvx]

With the same frequency of sending data, Zigbee has many times more consumption (!) than BLE.
The communication range in BLE Long Range mode (PHY Coded S=8) is two times longer than that of Zigbee. BLE Long Range - approximately 1 km in a straight line at TX 0 dB. The Bluetooth 5.4 standard completely overlaps ZigBee (a variant of BLE ‘advertising' PAwR, standardization of encryption of ‘advertising', ...).

PS: В итоге приходится производить обратные действия – перепрошивать самый дешевый термометр Tuya Zigbee TS0201 с али в BLE и включать BLE Long Range. Это экономит и на платформе HA. Не требуется ресурсоемкие приложения к HA и дорогие адаптеры для поддержки ZigBee

[pvvx]

Малая оптимизация по потреблению - среднее потребление 19 мкА для Xiaomi LYWSD03MMC B1.4, при опросе 10 сек.

(30ms*4.28mA+(10000ms-30ms)*0.0062mA)/10000us=0.0190214mA

Но в BLE Long Range выходит меньше, а передача длиннее и заголовки на 3-х каналах:

В таком-же window 30 ms - Average 2.55 мА. Т.е. при одинаковых интервалах передачи, с опросом датчиков, шифрованная передача (BTHome v2), в два раза большей дальностью, отношение примерно в 4.28/2.55 = 1.68 раз.
0.5 мА на диаграмме - это датчик SHTC3. С SHT4x можно давать команду измерения и в следующий опрос считывать и опять давать команду измерения. Уйдет пауза ожидания измерения в 6..7 ms с током 4.5 мА из диаграммы ZigBee (SHT4x сам входит в sleep после измерения и помнит данные до нового цикла измерения). Но будет передаваться прошлое измерение. При 10 сек опроса - такая задержка несущественна.

[pvvx]

Xiaomi LYWSD03MMC B1.4, fw: https://github.com/devbis/z03mmc/releases/download/1.0.2/z03mmc.bin

First run:

After binding with Xiaomi Gateway 3:

Averge: 108.9 uA

Typical impulse:

Window: 14 ms, 4.654 mA

Periodic strange pulses:

Window: 26 ms, 4.897 mA

The "Reset" contact does not reset the binding.

[pvvx]

The Reset contact was held for 30 seconds...

For comparison - the original firmware of Xiaomi LYWSD03MMC B1.4 fw ver 2.1.1_0159:

Average 18..19 uA

[pvvx]

Consumption measurements shows that current version could last for 9+ months from cr2032 battery

В среднем Xiaomi LYWSD03MMC от дешевых батареек CR2032 работает от 10 месяцев. От дорогих - более года.
При этом среднее потребление не более 16 мкА (разные версии). Тест на двадцати термометрах в течении более двух лет. При отключении дисплея, опцией в web конфигураторе, модно получить среднее потребление менее 10 мкА.
Это всё варианты без конденсаторов, которые Xiaomi пожадничали поставить в предусмотренные места на печатной плату, что сокращает срок службы батареи на 40%.
И если учитывать имеющиеся в продаже CR2032 с усреднением, то они не отдают и 60% от номинальной емкости при импульсном потреблении. И чем больше импульс по току - тем хуже.
Так что рассчитывать емкость CR2032 надо всего до сотни мАч...

---

@Alex500317 - Не утруждайтесь – уже сравнил. Сделал усреднение по множеству замеров, менял только прошивку.
Малая оптимизация и есть малая:

Прошивка от devbis потребляет в случае простого bind – 24.5 мкА, у варианта "с малой оптимизацией" – 21 мкА.

В случае с binding c активацией ответов по температуре и влажности – devbis 70..78 мкА, у варианта "с малой оптимизацией" – 54..58 мкА.
И это понятно - больше пробуждений SoC – больше набирает неоптимизированная часть кода в стандартном SDK от Telink, которую я вырезал (она не нужна).
Глобальной оптимизации по алгоритмам работы ещё не делалось – надеюсь на devbis, т.к. пока не хочу поддерживать ещё и ZigBee вариант данных термометров…

[devbis]

@jds11111 Battery remaining percentage is not linear. It would be nice if you could report about how many days your rechargeable battery will last until 0%

[devbis]

@vladimir1408v Sometimes, you need to rejoin the sensor after OTA to get lower consumption rate. I was told that sometimes after OTA it polls more frequently than during normal work.

[Ccrrocus]

[devbis]

@pvvx Thanks for measurements! Reset pin waits for 3 seconds to reset Zigbee internal state to avoid accidental resetting

[Ccrrocus]

[pvvx]

---

Analog - Tuya ZTU Module - the TLSR825x chip is used

ZTU Module Datasheet

TX and RX power consumption

Working status	Mode	Rate	Transmit power/receive	Average value	Peak value (Typical value)	Unit
Transmit	-	250Kbps	+0 dBm	4.64	23	mA
Transmit	-	250Kbps	+10 dBm	8.9	39	mA
Receive	-	250Kbps	Constantly receive	6.9	7	mA

Working mode	Working status, Ta = 25°C	Average value	Maximum value (Typical value)	Unit
Quick network connection state	The module is in the fast network connection state	9.5	13.5	mA
Network connection state	The module is connected to the network	8.9	10.5	mA
Deep sleep mode	Deep sleep mode, reserve 32-KB SRAM	2.8	-	μA

[Alex500317]

Малая оптимизация по потреблению

I started testing this fork. I have two sensors on the street, one was flashed with the version from pvvx, the second from devbis. The battery charge was the same for both sensors. I'm very curious what the difference will be. Now, since the release of 1.0.4, on all my 4 sensors (2 at home and 2 outdoors), on average, the battery charge has dropped by 5-6% (after about a week of use).

[pvvx]

I started testing this fork.

Previous versions in fork were intended for variant tests, not for work...
The current version fixed to work somehow... Measurement graph have been published.
It is not yet possible to make the consumption in the working version less than 54 µA.

Will have to test for about 4 months.
4 months is the estimated lifespan of an average CR2032 under these conditions.

[Alex500317]

Я начал тестировать эту вилку.

Предыдущие версии в форке предназначались для альтернативных тестов, а не для работы... Текущая версия исправлена, чтобы хоть как-то работать...

Я как раз вчера увидел, что вы обновили всё, и собрал последнюю версию. К тому же расчётные 4 месяца с зигби - очень даже хорошо, на вашей ble датчики прожили уже более полугода, но у меня не всегда стабильный приём из-за особенностей квартиры. Сейчас в прошивке от devbis всё-таки высоковато потребление

[devbis]

Consumption measurements shows that current version could last for 9+ months from cr2032 battery

[jds11111]

I am using a rechargeable battery. The new firmware has been installed only 3 days, new battery that started at 100%. It is now down to 86%. Loses about 5% a day. Sorry if this is irrelevant---I can't read many of these replies.

[pvvx]

https://habr.com/ru/companies/lamptest/articles/555158/

Differences in CR2032 battery capacities - 11...100%

@devbis - The range 0..100% is plotted according to the formula from the source code:

#define BATTERY_SAFETY_THRESHOLD 2200 // mV

    voltage = drv_get_adc_data(); // mV
	percentage = ((voltage - BATTERY_SAFETY_THRESHOLD) / 4);
	if (percentage > 0xc8) percentage = 0xc8;

Most of the new CR2032 under load during measurement (current 3..5 mA) have a voltage of 3.0..3.2 V.
Further, this voltage drops to 2.85..2.95 V in a few days.
And 80% of the operating time remains in this window. Then it rolls down to 2.0 V.
The moment of measuring the battery voltage when the SoC wakes up is important. If the measurement is carried out at the very start, the voltage will be greater than after the transmission cycle. With the installed capacity in the power supply, the dependencies can be even greater.
The voltage data is given at a temperature of +20..25 °C. There will be different voltages at different temperatures.
A fully discharged battery produces a voltage of 3.0 V at a megaohm load.

@jds11111 - Given the incorrect calculations of the remaining capacity in the current code, the real remainder of your battery is about 10..20%.

[devbis]

@pvvx Your calculations are wrong. 100% is at 3.0v while the working range is 2.2 - 3.0V

[pvvx]

Yes, I forgot that Zigbee is all weird and not suitable for people. The current battery percentage in Zigbee is 200%. :)
Calculations are correct, Zigbee is incorrect.

---

Пример оптимизации по питанию окончен итогом: Итоговое среднее потребление LYWSD03MC B1.4 при измерении от источника 3.3V от 14 до 26 мкА в зависимости от динамики изменений температуры и влажности.
26 мкА при непрерывном изменении температуры и влажности. Заданы интервалы по умолчанию для отчетов по температуре и влажности в 20-120 (мин-мах) секунд, reportableChange: 0.1C и 1%.
Репозиторий с тестом, возможно, в скором времени будет удален...

[pvvx]

Release 1.0.6

Rejoinig cycles:

The battery will only last 2 weeks. It is necessary to reduce energy consumption to operate for a month on an average CR2032 battery.

Press key 3 sec and Join:

When polling a button, the SoC operates at full power, although an interrupt is used when the button's GPIO state changes...

Pasue, In between (re)joinig (Only sensor polling and display):

Lack of optimization.

---

Не оптимизированный цикл опроса датчика и отображения и оптимизированный:

[andrazek]

Reducing battery consumption should be top priority. Is it possible to make it as efficient as AQARA WSDCGQ11LM, which has 2 years of battery life with the same CR2032 battery?

[devbis]

@andrazek It probably could. But this sensor has a different philosophy. While other sensors can sleep longer and wake up to send data every 5 minutes, this sensor needs to update screen in reasonable period. For this device it is 10 seconds.

You can build your own fork: disable screen module and significantly increase coordinator poll period and sensor read period to increase battery life.

[vladimir1408v]

Заряд батареи сильно расходуется за сутки, почти на 10% прошивка 1.6 как это исправить?

[devbis]

@vladimir1408v You may revert to bluetooth firmware using https://github.com/pvvx/ATC_MiThermometer/tree/master/zigbee_ota and local OTA index in zigbee2mqtt.
Battery drain is not linear and one day is not enough to say how long it will work.

[vladimir1408v]

@vladimir1408v You may revert to bluetooth firmware using https://github.com/pvvx/ATC_MiThermometer/tree/master/zigbee_ota and local OTA index in zigbee2mqtt. Battery drain is not linear and one day is not enough to say how long it will work.

Спасибо за ответ и за проделанную работу, я останусь на вашей версии, и понаблюдаю. Мне кажется это началось на 1.6 до этого была 1.5 и расход был меньше, по ощущениям возможно я не прав

[pvvx]

Extremely high consumption is observed if the network coordinator is disabled.

Мне кажется это началось на 1.6 до этого была 1.5 и расход был меньше, по ощущениям возможно я не прав

Минимальное среднее потребление после связывания и если данные не передаются (заданы большие пороги и максимальное время) у Releases 1.0.6 от 23 мкА.
Если нет связи с координатором - более 0.5 мА. Свет на даче отключили и батарейке конец.

[breaver]

@vladimir1408v You may revert to bluetooth firmware using https://github.com/pvvx/ATC_MiThermometer/tree/master/zigbee_ota and local OTA index in zigbee2mqtt. Battery drain is not linear and one day is not enough to say how long it will work.

Thanks for that hint. I have 10 sensors which i am planning to convert to Zigbee using your firmware. Glad to hear that there is an easier way back to a bluetooth based firmware in case the power consumption is to high (6 months would be good).
Do you have an example for the local index file ? (manufacturer code, etc.)

[pvvx]

Do you have an example for the local index file ? (manufacturer code, etc.)

File name decryption?
Sample: "1141-020a-01103001-Z03MMC.zigbee"

Manufacturer Code	Image Type	File Version	Stack Version	Name	Ext OTA
1141	020a	0110	3001	Z03MMC	zigbee
0x1141 - Telink	0x02 - TLSR825x, 0x0a - Xiaomi LYWSD03MMC	App release 0.1, App build 1.0	Zigbee v3.0, Release 0.1	Z03MMC	OTA

Image Type	Device, note
0x0201	MHO-C401 (old version)
0x0202	CGG1 (old version)
0x0203	LYWSD03MMC ver https://github.com/devbis/z03mmc
0x0204	WATERMETER ver https://github.com/slacky1965/watermeter_zed
0x0206	CGDK2
0x0207	CGG1 (new version)
0x0208	MHO-C401 (new version)
0x0209	MJWSD05MMC
0x020A	LYWSD03MMC ver https://github.com/pvvx/ZigbeeTLc
0x020B	MHO-C122
0x0210	Water Tank sensors
0x0211	TS0201-TZ3000
0x0212	TS0202-TZ3000

Glad to hear that there is an easier way back to a bluetooth based firmware in case the power consumption is to high (6 months would be good).

TelinkMiFlasher.html v7.1 support downloading *.zigbee directly for all current BLE firmware (from version 4.6).
So is https://github.com/devbis/z03mmc/releases/download/1.0.6/1141-0203-10063001-z03mmc.zigbee

Current measurements of average consumption over a long period for Xiaomi LYWSD03MMC B1.4 (default settigs):

1141-0203-10063001-z03mmc.zigbee - from 30 µA, on average 32 µA
1141-020a-01123001-Z03MMC.zigbee ~ 20 µA
ATC_v46.bin ~ 14 µA

This will let you know how long your battery will last.

[andrazek]

@andrazek It probably could. But this sensor has a different philosophy. While other sensors can sleep longer and wake up to send data every 5 minutes, this sensor needs to update screen in reasonable period. For this device it is 10 seconds.

You can build your own fork: disable screen module and significantly increase coordinator poll period and sensor read period to increase battery life.

Thanks for clarification. Still, why would consume more on Zigbee compared to bluetooth, if both having the same update frequency? I always thought zigbee is the most efficient tech for battery devices. Would extending the reading interval to every 30s instead of 10s noticeable improve the battery life? Having a lot of these devices and short battery life is pain in the ass.

[pvvx]

I always thought zigbee is the most efficient tech for battery devices.

In BLE mode, with default settings, the screen refresh interval is 2.5 seconds. Data transmission via RF every 2.5 seconds on three channels. Sensor polling - 10 seconds.
When switching to LE Long Range mode (communication range of 1 km for RF transmit power 0 dB), battery consumption increases. The time for transmitting and receiving packets increases. But you can increase the transmission interval to 3..5 seconds for an equivalent level of battery consumption.
The Bluetooth 5.4 standard already implements all Zigbee options with lower consumption over long communication distances.

[jds11111]

An update on power consumption in my hygrometer. I am using a rechargeable battery, which has its own power curve. Within a couple of days it dropped to about 83%. I did update the firmware about that time, but the drain rate could just be the battery. It has now been about four weeks and is draining much more slowly. Unfortunately, HA is storing data on the device for only a couple of weeks. Here is the last 10 days to give an idea. I assume that the fluctuations are the temperature swings in the house. I would estimate the current rate to be about 0.4%/day.

[jds11111]

Yeah, the oscillations in battery are definitely the temperature:

[pvvx]

CR2032 batteries from different manufacturers have a difference in capacity of more than 4 times. There is no point in analyzing consumption based on the behavior of a specific battery. Differences may vary from operating temperature and battery storage conditions prior to use.
A quick check can be done using CR2016. But you will still get a difference of several times when using batteries from different manufacturers.

[jds11111]

There is no point in analyzing consumption based on the behavior of a specific battery.

I would argue that a single data point is more useful than zero data points.

[pvvx]

Dual zigbee--ble device - Xiaomi LYWSD03MMC B1.4 - 18 µA

[jds11111]

Do I understand this correctly? You are running both radios for simultaneous ZigBee and BLE, with just 18uA?? That is wild.

[pvvx]

Do I understand this correctly? You are running both radios for simultaneous ZigBee and BLE, with just 18uA?? That is wild.

Yes, this is a big battery drain.

Cycle = 5 sec = 5000 ms
Sleep current = 6 µA = 0.006 mA
The duration of the SoC activity and transmission cycle varies depending on the Zigbee report settings.
If we take an average of 10 ms and 6 mA, then we get:

(4990ms*0.006mA+10ms*6mA)/5000ms  = 0.017988 mA = 18 µA

But the big cycle is 10 seconds (5x2). And it has one short active processor period, in which only BLE is transmitted. And this is a couple of ms. The second phase accounts for more - BLE transmission, sensor polling, Zigbee.

[pvvx]

Dual zigbee-ble device, RF TX +3dB

If there are no additional Zigbee polls:

((10000-9-26)*0.006+9*3.7+26*3.99)/10000=0.019683mA

[Bolukan]

I would benchmark against 1 year endurance, a CR2032 gives 240mAh (220-240 mAh is common presumed). With these numbers the budget would be 27,4 µA of which 6 µA seems to be consumed for the continuous sleep mode. The latest configuration (poll+lcd+ble+zigbee) would just fit (97% of budget)

[pvvx]

Only a fresh CR2032 from the best manufacturers produces 240 mAh at a constant test load with a current of less than 0.5 mA.
With a pulsed load, the final power will be 60% of the rated power.
Commercially available CR2032 have capacities ranging from 20% to 100%. With a price difference of more than 50 times for one CR2032 element. A good CR2032 cell with 240 mAh has a higher price than Xiaomi LYWSD03MMC.
#11 (comment)

As a result, with a consumption of about 20 μA, the average life of Xiaomi LYWSD03MMC for users will be no more than 6 months. The main reason is the large pulse current for Zigbee at RF TX +3dB (23 mA !). Reducing the transmit power significantly affects the operating time of the CR2032.

At +0dB the peak current does not reach 8 mA.
For LE Long Range this is a distance of 1 km in a straight line, because a regular BLE chip in this mode has reception levels of up to -110 dB and beyond (plus additional recovery bits.). For Zigbee - no more than 200 meters (subject to the use of new chips with reception levels from - 98 dB for Coded PHY).

https://www.ti.com/lit/wp/swra349/swra349.pdf

CC2530 datasheet:

TLSR825x datasheet:

RTL8761BU

---

Due to the massive use of ancient chips in Zigbee routers and coordinators, for most, provided RF TX +2 dBm in LYWSD03MMC (set by default), the operating range will be up to 10 meters without obstacles. In this case, the battery will last about 6 months when using ZigbeeTLc and less when using firmware from the current repository.

[Ccrrocus]

Установил для пробы параллельно CR2032 электролитический конденсатор 200µF*10V. Батарея, как видно на графике имела заряд около 15%. Конденсатор припаял на проводах к имеющимся контактам на плате. Там, где предполагалась его штатная установка. SMD вариант сходу не нашел, но для теста это не важно. Результат меня удивил - заряд батареи поднялся до 45%, притом он стабилен. Интересно, сколько протянет.

[Ccrrocus]

Теперь я взял дохлую батарею, с которой уже термометр не работает. Подпаял аналогичный конденсатор, но вдвое большей ёмкостью 470µF. И прибор заработал! Понятно, что чудес не бывает и заряд батареи сильно просел, но он работает до сих пор!

[pvvx]

The larger the capacitance of the capacitor, the greater its leakage current. Balance required.

[adrianromero]

Just to comment that in my case the battery completely drained after I flashed the device with the zigbee firmware in less than one week. It was a new battery.

[Christian-fhs]

Just to comment that in my case the battery completely drained after I flashed the device with the zigbee firmware in less than one week. It was a new battery.

After flashing custom firmware onto five LYWSD03MMC devices, I observed a complete battery drain within just two weeks. While my initial assumption pointed towards low-quality stock batteries, upon further reflection, it seems more likely that the issue lies with the Zigbee firmware.

[wf2020]

How about fitting in a CR2450? Some other from the shelf Zigbee thermometers seem to use one. From first sight it might be possible to just 3d print a new PCB cover so a CR2450 possibly fits in.

[pvvx]

Firmware version 1.1.0.0, Xiaomi LYWSD03MMC HW: B 1.4.
With 4 reports in 8 minutes:

Average 29.3 uA.