Zigbee solutions seems to be ~10mA, while WiFi / ESP32 seems to be ~100mA.
The 10x difference in power can be papered away by running the radio 1/10th the frequency. Ex: instead of updating every minute (Zigbee), you can update every 10-minutes (WiFi).
--------
I think a lot of these WiFi internet-of-things are fine with the ~15 minute update routine to minimize the use of the (relatively power heavy) 100mA+ WiFi radio.
Zigbee is simpler, but not so simple that you can program it yourself. It is found in cheaper $5 microcontrollers with less oomph than the ESP32... and those microcontrollers also use less power since its just innately a slower protocol. Though... I guess ESP32 is also $5 so cost really isn't a factor anymore.
-------
The absolute limit of 10mA vs 100mA is also pretty interesting.
10mA is just barely what is reasonable to push out of a CR2032 coin cell battery. 40-ohms internal resistance at 3V, so 10mA is a .4V drop... which can be solved with enough capacitors to buffer up the current. A lot of these devices still work at 2.3V or so (-.3 volts from age, -.4 volts from internal resistance), so you have enough headroom for an IoT Zigbee radio with CR2032 coin cells.
You ain't getting 100mA out of a coin cell battery (lol 4V drop on a 3V cell), unless you're also adding a super-capacitor to the circuit or other rather significant forms of power-storage. Then again, 100mA is more than reasonable out of Li-ion / AA NiMH / etc. etc. So ESP32 is still a battery-operated device... just a larger one than any Zigbee solution.
Mind you, the CR2032 coin cell is designed to average ~0.4 mA or less. So you really need to keep the radio "sleeping" most of the time. 10mA is really close to the "temporary burst" limits of the cell, and you're already suffering from significant degradation of the cell's lifespan by running it at 10mA, even temporarily. But the fact that Zigbee "fits" inside of this means that you can design devices around CR2032 cells, rather than AA or Li-ion packs.
-------
EDIT: The setup/teardown speed of Zigbee is also much faster. IIRC, you can connect, send data, and disconnect in ~30 milliseconds on Zigbee. But it requires seconds on WiFi (find an Access Point. Call Access Point. Setup negotiations, etc. etc. 3-way TCP handshake: Syn, Syn-ack, Ack. And then HTTP finally begins...).
A 470uF capacitor can power 5mA across a .4V drop for 36 milliseconds. (I = C * dv/dt). Assuming half the power comes from CR2032 + the other half the power from the capacitor (that's not how electronics work but I'm doing quickie napkin math), that's 5mA from the CR2032 + 5mA from the capacitor. So the 470uF capacitor gives you the headroom to run other parts (sensors / uC, etc. etc.) within the 10mA limits of the CR2032 cell.
Good luck getting a capacitor to do that kind of work across the ~5 seconds needed to setup / teardown a WiFi connection.
Since "Energy" == "Power * Time", the 100x time to connect + 10x power leads to ~1000x energy usage in practice, for WiFi vs Zigbee.
I was recently playing with an ESP32-C3 and was astonished at how fast it could boot and make an http request. (Can’t remember if it was ssl or not). I was measuring just under 1 second. Still an eternity compared to Zigbee, but I was quite surprised. I expected it to be more like 5-10 seconds.
It makes me wonder why far more powerful devices (iPhone, MacBook) take so long to connect to or change WiFi networks.
Its probably just the nature of optimizing for your customer.
iPhones / MacBooks don't care about battery life, or connecting/disconnecting from WiFi all the time. Optimizing from 5s connection to 1s connection is completely irrelevant. Its not like people normally disconnect/reconnect to WiFi. The few times I do it (ie: walk into my house / WiFi is back in range), my phone reconnects long before I even take it out of my pocket. Once connected, it stays connected and active.
ESP32 however, is an IoT chip. Optimizing from 5s to 1s connection time is a reduction of 80% of your power usage in practice. Because almost every IoT device will immediately sleep after the WiFi message is sent.
That is impressive though. Good on them for making this process more efficient. It'd never beat a specially designed protocol like Zigbee (or any of the 802.15.4 stuff). But so many people use 802.11 / WiFi these days that these kinds of optimizations are hugely relevant.
The 10x difference in power can be papered away by running the radio 1/10th the frequency. Ex: instead of updating every minute (Zigbee), you can update every 10-minutes (WiFi).
--------
I think a lot of these WiFi internet-of-things are fine with the ~15 minute update routine to minimize the use of the (relatively power heavy) 100mA+ WiFi radio.
Zigbee is simpler, but not so simple that you can program it yourself. It is found in cheaper $5 microcontrollers with less oomph than the ESP32... and those microcontrollers also use less power since its just innately a slower protocol. Though... I guess ESP32 is also $5 so cost really isn't a factor anymore.
-------
The absolute limit of 10mA vs 100mA is also pretty interesting.
10mA is just barely what is reasonable to push out of a CR2032 coin cell battery. 40-ohms internal resistance at 3V, so 10mA is a .4V drop... which can be solved with enough capacitors to buffer up the current. A lot of these devices still work at 2.3V or so (-.3 volts from age, -.4 volts from internal resistance), so you have enough headroom for an IoT Zigbee radio with CR2032 coin cells.
You ain't getting 100mA out of a coin cell battery (lol 4V drop on a 3V cell), unless you're also adding a super-capacitor to the circuit or other rather significant forms of power-storage. Then again, 100mA is more than reasonable out of Li-ion / AA NiMH / etc. etc. So ESP32 is still a battery-operated device... just a larger one than any Zigbee solution.
Mind you, the CR2032 coin cell is designed to average ~0.4 mA or less. So you really need to keep the radio "sleeping" most of the time. 10mA is really close to the "temporary burst" limits of the cell, and you're already suffering from significant degradation of the cell's lifespan by running it at 10mA, even temporarily. But the fact that Zigbee "fits" inside of this means that you can design devices around CR2032 cells, rather than AA or Li-ion packs.
-------
EDIT: The setup/teardown speed of Zigbee is also much faster. IIRC, you can connect, send data, and disconnect in ~30 milliseconds on Zigbee. But it requires seconds on WiFi (find an Access Point. Call Access Point. Setup negotiations, etc. etc. 3-way TCP handshake: Syn, Syn-ack, Ack. And then HTTP finally begins...).
A 470uF capacitor can power 5mA across a .4V drop for 36 milliseconds. (I = C * dv/dt). Assuming half the power comes from CR2032 + the other half the power from the capacitor (that's not how electronics work but I'm doing quickie napkin math), that's 5mA from the CR2032 + 5mA from the capacitor. So the 470uF capacitor gives you the headroom to run other parts (sensors / uC, etc. etc.) within the 10mA limits of the CR2032 cell.
Good luck getting a capacitor to do that kind of work across the ~5 seconds needed to setup / teardown a WiFi connection.
Since "Energy" == "Power * Time", the 100x time to connect + 10x power leads to ~1000x energy usage in practice, for WiFi vs Zigbee.