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.

[EddieTH]

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?

[pvvx]

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

devbis/z03mmc#11 (comment)

@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.

1. Was there a connection to 5V?
   After exceeding the supply voltage, the microcircuit continues to operate, but consumes significantly more.

2. 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?

[pvvx]

Aqara lumi.weather

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.

---

Xiaomi LYWSD03MMC B1.4

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...

[pvvx]

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

[tristone-cz]

@pvvx I am using the LYWSD03MMC, version not exactly sure. I think the FW version during flashing was 1.7 or 1.8

[somebody-somewhere-over-the-rainbow]

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)

[pvvx]

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)

1. A clock that doesn't go at all shows the correct time twice a day.
2. If LUMI starts transmitting measurements every 180 seconds, then the consumption will be the same as that of the BLE version of Xiaomi LYWSD03MMC. At the same time, Xiaomi LYWSD03MMC BLE transmits measurements every 10 seconds. The difference will be 18 times. :P

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.

[pvvx]

@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.

[Neo2SHYAlien]

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.

[pvvx]

The installation of two capacitors is provided. С24 and С25.

[victorlucachi]

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.

[pvvx]

1. What "min/max/change" settings were used?
   
2. What Zigbee Network Coordinator is used?
3. What is the communication distance to the thermometer?

[victorlucachi]

What "min/max/change" settings were used?

1. everything at defaults, I sent a command only to remove the smiley face from the display, but I had a feeling that might've glitched the sensor somehow (and hence the battery drain) so I removed it from the zigbee network, and repaired it.
2. the coordinator is a sonoff zigbee dongle E
3. probably around 3m, through a rather thick concrete wall

[pvvx]

everything at defaults,

What's in reality? Z2M and ZHA set their own settings.

[victorlucachi]

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

[NorDroN]

I can send my LYWSD03MMC HW:B1.5 device from Russia for testing.

[tristone-cz]

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.

[pvvx]

Test Xiaomi LYWSD03MMC B1.5.
Xiaomi's original BLE firmware has an average consumption of 23 µA.
BLE firmware ATC_v46.bin at default settings consumes less than 17 µA.
Firmware Zigbee 1141-020a-02043001-Z03MMC.zigbee:

Measurement with the settings specified in this issues.

Xiaomi LYWSD03MMC B1.5 has the highest consumption in sleep mode (> 8 µA) and when polling the sensor.
The remaining versions (V1.4, V1.6, V1.7, V1.9, V2.0) have lower consumption.

In ZigBee mode, consumption depends on the coordinator. If it does not know how to work in Zigbey 3.0 or is terribly slow, then the consumption will be terrible.

PS: The topic about consumption in Zigbee mode can be closed. The reasons for the increased consumption are known and do not relate to the thermometer firmware.

[tristone-cz]

Probably my last note.

The 0.1.1.8 version provides significant difference compared to 0.1.1.6.
BT sensors in graph are on ATC 46, the other two at Zigbee 0.1.1.8. Located in the same place, 1,5m from coordinator.

[pvvx]

Versions below 0.1.1.8 have all interfaces: Touchlink commissioning, ZCL_GROUP.
In version 0.1.1.8, all additional Zigbee features are disabled. (People mostly have outdated Zigbee coordinators.)
Xiaomi and Tuya devices do not adhere to Zigbee 3.0 and operate according to their own rules.
Some people make settings in Z2M from devbis firmware for firmware from this repository, setting the broadcast of measurements every 10 seconds. :)
Others are trying to make a CR2032 thermometer transmit data to old blind coordinators over a distance of tens of meters or through reinforced concrete walls...

[muzzy124]

Как тебе такое, Илон Маск? :)
I found that my sonoff-p coordinator firmware was rather old (2022***), so I upgraded it to the latest 20230507 on Jan 17th.
Afterwards it's been a kind of magic :) Battery level of two devices (orange and blue ones) began to go up.

[pvvx]

Уже давно понятно, что c sonoff всё плохо.

[drwalr]

It is possible to insert a larger battery into this sensor, it will take a CR2450 battery

https://www.olx.pl/d/oferta/wieksza-bateria-cr2450-do-xiaomi-lywsd03mmc-zigbee-CID99-IDYmMwB.html?bs=olx_pro_listing

[slingel]

my comment from December:

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.

v1.1.1.7:

v1.1.1.9:

[pvvx]

@slingel - what version (B1.4..B2.0) of the thermometer?

[slingel]

1.6

[zombie4000]

Just to add to this.
Device: LYWSD03MMC
This was my battery percentage on firmware 0x01183001 with a brand new battery, the same was happening with the included battery.

I upgraded to firmware 0x01193001 and its looking a lot more promising after 2 days:

On the earlier version the battery would be around 72-75% after 2 days. This was consistent between 3 different devices with included batteries and new batteries in all 3 devices. After all three devices behaved the same same with two sets of batteries I stopped using them until I upgraded one of them.

Update after two weeks in use:

This looks really good.

[pvvx]

Next test: Firmware ZigbeeTLc version 0.1.1.9, Xiaomi LYWSD03MMC HW: B 1.4.
With 6 reports in 8 minutes:

Average 14.6 uA.

Almost two times less than in the version devbis/z03mmc#11

[gurkburk76]

Any advice on settings for firmware 4.7 when it comes to max power savings?
I have a few sensors in hard to reach spots that report to HA via esp32 relays that i don't actually need to visually see and would like to max out the battery on these devices. I guess reports once every hour would be fine really.

[trablin45]

are there any recommended reporting values for z2mqtt ? default is fine?

[pvvx]

All settings depend on the necessary conditions for solving the problem in which this sensor is used.
Most IoT tasks when regulating temperature and humidity require data transfer with periods of several seconds and the maximum possible resolution. Not necessarily absolutely, but with the maximum possible resolution. Especially for control of PID.
Zigbee cannot cope with such tasks when using CR2032 batteries. With the same stream of data, BLE consumes from 8 times less on any chipset.

If you need an indicator that you look at, then there is no need to transmit data from it.
The measurements once per hour and a resolution of less than 4 significant numbers do not carry any information for use in a "smart home".
This can only be suitable for the game.

B Zigbee Network is not reliable.
The Zigbee network requires autonomous routers when interrupting the coordinator or rebooting the server. Otherwise, at such moments, all the battered Zigbee devices are looking for working routers or coordinator. It requires a lot of energy. And the search continues until they find routers or coordinator of their network. Or fall out of the network forever.
As a result, the total consumption and price of the Zigbee network is always greater, and the quality is average.
For this reason, Zigbee firmware support is secondary in relation to BLE.

Zigbee is suitable only for executive devices, where consumption is not particularly important compared to the controlled load. And for sensors is not at all suitable.

[pvvx]

TS0201 - 2xAAA cheapest alkaline batteries.
Power TS0201-bz - Works simultaneously in BLE and Zigbee.

[mikezs]

It is possible to insert a larger battery into this sensor, it will take a CR2450 battery

https://www.olx.pl/d/oferta/wieksza-bateria-cr2450-do-xiaomi-lywsd03mmc-zigbee-CID99-IDYmMwB.html?bs=olx_pro_listing

Do you have a link to this STL? The URL you previously posted is no longer wokring

[tearandfix]

I've recently designed two cases with 2xAAA batteries for LYWSD03MMC

https://www.printables.com/model/1095832-xiaomi-mijia-bluetoothzigbee-thermometer-aaa-batte

https://www.printables.com/model/1098300-yet-another-aaa-battery-case-for-xiaomi-bluetoothz

[drwalr]

@mikezs The URL led to a place where you could buy a ready-made print, but I have an STL file for this model

[mikezs]

@mikezs The URL led to a place where you could buy a ready-made print, but I have an STL file for this model

Would you mind sharing it, please? No worries if not. I have a gmail address with this username.

[pvvx]

TS0201 2xAAA BLE LE Long Range

Defrosting the refrigerator gives new strength to the battery :)

TS0201 2xAAA Zigbee&BLE

PS: To test these devices I use the cheapest AAA batteries I could find...

[wlfbck]

All settings depend on the necessary conditions for solving the problem in which this sensor is used. Most IoT tasks when regulating temperature and humidity require data transfer with periods of several seconds and the maximum possible resolution. Not necessarily absolutely, but with the maximum possible resolution. Especially for control of PID. Zigbee cannot cope with such tasks when using CR2032 batteries. With the same stream of data, BLE consumes from 8 times less on any chipset.

If you need an indicator that you look at, then there is no need to transmit data from it. The measurements once per hour and a resolution of less than 4 significant numbers do not carry any information for use in a "smart home". This can only be suitable for the game.

B Zigbee Network is not reliable. The Zigbee network requires autonomous routers when interrupting the coordinator or rebooting the server. Otherwise, at such moments, all the battered Zigbee devices are looking for working routers or coordinator. It requires a lot of energy. And the search continues until they find routers or coordinator of their network. Or fall out of the network forever. As a result, the total consumption and price of the Zigbee network is always greater, and the quality is average. For this reason, Zigbee firmware support is secondary in relation to BLE.

Zigbee is suitable only for executive devices, where consumption is not particularly important compared to the controlled load. And for sensors is not at all suitable.

I get all your arguments for BLE and against Zigbee, but is it possible to create a network of BLE devices which can be integrated into home assistant like it is possible with zigbee2mqtt and zigbee routers like ikea smart plugs? What i mean is, the energy savings dont do anything for me if i can not easily integrate them, or they are out of range.

[pvvx]

What i mean is, the energy savings dont do anything for me if i can not easily integrate them, or they are out of range.

You are limited by what is provided to you for use.

To cover my residential area, I need more than a dozen Zigbee routers distributed along the street. And there is no power supply. However, BLE in LE Long Range mode easily copes without any routers.

zigbee routers like ikea smart plugs?

The Ikea smart plugs only has a range of 30 meters.
I need 500 meters.

Example:
LE Long Range signal reception level from a sensor in a garage located 80 meters from the house where the receiver is located.

Regular users cannot use BLE in LE Long Range mode because it is not implemented in Linux. That is, Linux has created artificial restrictions for you. And you are forced to use only outdated technologies and standards that are more than a decade old.

If you like Zigbee, then there is also this /~https://github.com/pvvx/TLB2Z

PS: I have no problem covering my existing private territory. And I don't care what transmission protocol to use. But in my experience, BLE wins for sensors. For actuators - Zigbee.

[wlfbck]

Interesting, i wasn't aware long range was that long. Being used to bluetooth devices with at best a couple meters range kinda set my expectations low.

Thank you for the insights!

[agittins]

@wlfbck
is it possible to create a network of BLE devices which can be integrated into home assistant

Multiple esp32 devices configured as bluetooth proxies will give you exactly that, and works very well. Not well enough for pvvx, I think, but good enough for the rest of us! :P