z03mmc
z03mmc copied to clipboard
devbis
High battery consumption
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
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 Thanks for measurements! Reset pin waits for 3 seconds to reset Zigbee internal state to avoid accidental resetting
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
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 |
Малая оптимизация по потреблению - среднее потребление 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 сек опроса - такая задержка несущественна.
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).
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.
Я начал тестировать эту вилку.
Предыдущие версии в форке предназначались для альтернативных тестов, а не для работы... Текущая версия исправлена, чтобы хоть как-то работать...
Я как раз вчера увидел, что вы обновили всё, и собрал последнюю версию. К тому же расчётные 4 месяца с зигби - очень даже хорошо, на вашей ble датчики прожили уже более полугода, но у меня не всегда стабильный приём из-за особенностей квартиры. Сейчас в прошивке от devbis всё-таки высоковато потребление
Consumption measurements shows that current version could last for 9+ months from cr2032 battery
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 вариант данных термометров…
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.
@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%
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%.
@pvvx Your calculations are wrong. 100% is at 3.0v while the working range is 2.2 - 3.0V
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%. Репозиторий с тестом, возможно, в скором времени будет удален...
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.
Не оптимизированный цикл опроса датчика и отображения и оптимизированный:
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?
@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.
Заряд батареи сильно расходуется за сутки, почти на 10% прошивка 1.6 как это исправить?
@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 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 и расход был меньше, по ощущениям возможно я не прав
@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.
Extremely high consumption is observed if the network coordinator is disabled.
Мне кажется это началось на 1.6 до этого была 1.5 и расход был меньше, по ощущениям возможно я не прав
Минимальное среднее потребление после связывания и если данные не передаются (заданы большие пороги и максимальное время) у Releases 1.0.6 от 23 мкА. Если нет связи с координатором - более 0.5 мА. Свет на даче отключили и батарейке конец.
@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.)
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 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.
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.