Open tristone-cz opened 9 months ago
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.
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.
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.
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.
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 😄
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:
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:
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?
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.
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?
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:
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.
@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?
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?
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).
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.
https://github.com/devbis/z03mmc/issues/11#issuecomment-1804344704
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.
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.
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...
Have you done trials with adding such a capacitor? Would there actually be a significant improvement?
Have you done trials with adding such a capacitor? Would there actually be a significant improvement?
https://www.ti.com/lit/wp/swra349/swra349.pdf
https://github.com/devbis/z03mmc/issues/11#issuecomment-1841546441
@tristone-cz - What version of the thermometer?
But the same batteries in many other Aqara zigbee devices work for years.
Aqara zigbee:
Not a "Aqara" worked for a year. The limit was 10 months. In other cases - less. "Aqara" transmits an average of 3 measurements per hour.
Was there a connection to 5V? After exceeding the supply voltage, the microcircuit continues to operate, but consumes significantly more.
After the thermometer got wet, I was unable to “cure” it. Drying with a soldering station helped a little, but only temporarily. As a result, this Xiaomi LYWSD03MMC was thrown into the trash due to excessive battery consumption.
What is your case? Уou set measurements to be sent every 10 seconds?
Does not comply with Zigbee 3.0.
Sleep - 1.8 µA
When transmitting nothing - Average - 12.5 µA
When data is being transferred:
The capacitor is installed in the power circuit. But it doesn’t help the outdated nRF chip much, because... small capacity.
Sleeping processor - less than 1.8 µA. Screen and driver LСD - 4..5 µA. Sleeping sensor - 0.5..1 µA
In total, depending on the model (B1.4..B2.0), the minimum current is 6..10 µA. Added to this is work.
Disable screen display in the options, and the BLE version will consume less battery than the sleeping Aqara. But all measurements will be transmitted every 10 seconds with quadruple duplication over 3 radio channels.
PS: In the "BZdevice" version, consumption reduction is achieved due to the mismatch of intervals between transmissions of a message packet for Zigbee 3.0. Data packets are transmitted without standard intervals, just like LUMI does...
Based on the measurements taken, you can calculate how much LUMI will consume when transmitting measurements every 180 seconds. This will be (12.5 x 170+74.8 x 10)/180 = 15.96 µA When transmitting every 30 seconds (12.5 x 20+74.8 x 10)/30 = 33.27 µA :P
@pvvx I am using the LYWSD03MMC, version not exactly sure. I think the FW version during flashing was 1.7 or 1.8
Based on the measurements taken, you can calculate how much LUMI will consume when transmitting measurements every 180 seconds. This will be (12.5 x 170+74.8 x 10)/180 = 15.96 µA When transmitting every 30 seconds (12.5 x 20+74.8 x 10)/30 = 33.27 µA :P
I have no calculations to show for but I have multiple aqara zigbee temp/humidity sensors running for >1yr (even in the freezer at -18C)
I have no calculations to show for but I have multiple aqara zigbee temp/humidity sensors running for >1yr (even in the freezer at -18C)
in the freezer
Freezer with iron walls. BLE: LE Long range:
THB2 variant with measurement transmission every 2.5 seconds. The RTL BT adapter can't keep up.
An alternative program is being used. Average consumption is 14.2 µA from 2 x AAA batteries.
@alexw1982 - Tell me how to control heating using the Aqara sensor?
Or how to turn on the lighting when a door is opened using a Zigbee sensor? With a Zigbee sensor, the door is already open, and the light turns on after a second or more. That's just terrible. From the BLE sensor, the time from response to activation is 5..15 ms.
I'm not particularly adept at understanding electrical diagrams, but I believe this area is where the capacitor should be placed. (small one). The is 1.4 version LYWSD03MMC.
The installation of two capacitors is provided. С24 and С25.
But what about battery life? The original battery was depleted in 10 and 12 days (two devices).
I'm wondering the same thing. I currently have just one sensor that I serial flashed with the latest Zigbee firmware, and the battery is draining rather fast; first one was the included chinesium, the second was a Varta.
What "min/max/change" settings were used?
everything at defaults,
What's in reality? Z2M and ZHA set their own settings.
What's in reality? Z2M and ZHA set their own settings.
oh, I apologise, it's my first zigbee device and I'm still trying to wrap my head around it.
this is what turns up if I attempt to reconfigure the device in ZHA
What is the hw_version of the thermometer? B1.4....B2.0?
it's a B1.6
I don't have B1.5 and B1.6. At B1.4 and B2.0 the consumption is 14..20 µA. This is enough to last more than 6 months with the cheapest CR2032.
fair enough. thanks for the input nevertheless
I'm about to receive 4 more thermometers (maybe before the end of year if I'm lucky), and if they are a different hardware revision I will report back.
6 months of battery life would be really nice to have.
PS: I tried to enable LCD output on B1.4 at the same time as the output option on B1.6. This results in a small increase in average current consumption, no more than +1 µA. But this is work on two displays at once. B1.6 seems to have no other differences.
noted. I will probably wait for the other 4 sensors to arrive, and I will flash them with different firmware releases, to compare power usage, after which I'll report back
thank you again, much appreciated!
I have 4 Xiaomi thermometers LYWSD03MMC hw1.4, sw ver 0.1.1.1. My monthly statistics are very promising according to me. The best result is an increase (!) in battery status from 84% to 87%, a sensor with a new battery lost only 2%, another one (this one seems to have a battery contact problem - I have to check it) lost 6% and the worst case is a drop of almost 10%.
TS0201_TZ3000 Works simultaneously in BLE and Zigbee. The cheapest 2 AAA batteries.
MJWSD05MMC works in "Long Range LE" in another house. Distance 200 meters, several walls. The battery is included with the thermometer:
Zigbee does not take even 100 meters.
The installation of two capacitors is provided. С24 and С25.
Sorry for the silly question but what is recommended value for both capacitors ?
4.7..47 uF
Just an observation with Varta baterie, no noname Chinese ones.
Version 1.6
I'm off-site now. Will add new batteries then and try latest 0.1.1.8 ...
with 0.1.1.8 no more battery drain for me.
I got about 25-30% drain over 9 days with three brand new LYWSD03MMC B2.0, flashed to 1141-020a-01183001-Z03MMC.zigbee directly after box opening LQI (in ZHA) is about 70-120
min/max settings are the same as in picture above
I have Xiaomi LYWSD03MMC for 2 months now on an old battery previously used in the BLE version. All versions of Zigbee and other debugging options were flashed. I tried to turn off the coordinator for a couple of days (the biggest consumption when searching for a coordinator). The battery two months ago was 60% - now 54%.
@muzzy124 - опишите какой используется координатор сети Zigbee.
Для отладочных вариантов термометров (про которые описано выше) я использую Xiaomi Gateway 3 в ZHA. В этой сети много роутеров Tuya на "Умных розетках". Все конечные устройства периодически беспорядочно переключаются на работу через них. Напряжение батареек на других вариантах термометров, поддерживаемых в данном репозитории, ещё не опустились ниже 3.0В и показывают 100%. Они так же работают уже более 2-х месяцев, с постоянными перепрошивками для проверки всех версий прошивок.
i got ZHA with sonoff usb dongle cc2652 and a bunch of noname tuya relays and plugs
Me few cents guys. I switched my B1.6 to "0.1.1.8" 5 days ago and it looks better compared to "0.1.1.6". Too early to conclude, the graph is bit fluctuating, but my estimation is about 1 month to get to 0%. So better, but still problematic. Maybe the B1.6 is somehow weird?
One of the test groups of thermometers with Zigbee firmware. For 2 months no problems with batteries.
Except Xiaomi Aqara:
Maybe the B1.6 is somehow weird?
I ordered LYWSD03MMC from several other stores. I hope to get B1.6. Sent by mail. I'll check it when they arrive. I don't know what to do with the rest of the accumulated LYWSD03MMC... For the third year now I have been buying them every two months, but I don't come across versions B1.6 and B1.5.
I can send my LYWSD03MMC HW:B1.5 device from Russia for testing.
I had another two B1.6 so flashed to ATC 4.6 and placed to the same location at those Zigbee ones. Let's compare.
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.