> there’s not good support for very low power devices that use WiFi
That's why we have Thread. Wifi just isn't a very efficient protocol for using with deep sleep. The radio takes more power to run, the overhead of connecting is higher, and the device needs a full IP stack. Even with power save mode (if supported by client and AP), the radio is on for hundreds of milliseconds to send a message.
Thread has "sleepy end device" profile built-in where the hub will queue messages and expects the device to be in deep sleep most of the time. And since it doesn't have so much overhead, the radio only has to be on for tens of milliseconds.
Thread is fine, but also wifi is fine. Sleepy end device doesn't work very well with wifi, as I understand it, (from trying to implement it using the ESP32 SDK), because Matter generally wants all devices to check in several times an hour at least.
Take a smart scale for example. Mine uses wifi and is in deep sleep almost all of the time. When you step on it, it weighs you, connects to wifi, and sends the measurement. This does fine on battery because it only gets used a few times a day max, and I think it may power up the radios to look for a software update once a day or something. If it had to power up the radios every 5 minutes though it wouldn't last a year on a charge.
Another example would be a water/flood sensor. The overwhelming majority of the time, it has nothing to report. Maybe once a day or so it should report the battery level and that it's still there. You can still get great battery life as long as you don't have to turn on the radio all the time, but Matter doesn't really let you do this, in my understanding, at least as of the current revision.
ESP32 has inherent sleep issues and before their latest chip (c6 I think) 'deep sleep' was really a gpio- or rtc- triggered boot followed by a power off. Doesn't mean it's impossible to implement wifi sleep efficiently, but if you do the math anything wifi based won't work off cr2032 for even a year unless daily updates is all you need. Motion sensors are supposed to fire more often, and with much less latency that can be done via WiFi, so it doesn't really work for battery powered sensors in the general case. You could probably use ESPNow and a custom gateway node but at that point it's just another custom RF protocol and you're better off with something standard like 802.15.4 or BLE..
You can put the ESP32 into deep sleep, and it can wake based on a timer, or it can run the ultra-low-power core which is a very slow, very low memory, very low power core. It's good enough to look at ADC or I2C devices and do a little math. This can be woken up fairly frequently to check a sensor, and say, compare against a previous measurement, and then wake up the main core if you need to process the measurement or do WiFi.
I think you're right that this won't work well with a CR2032, but if you're careful about using good voltage regulators it can last a long time on 4 AAs.
That's why we have Thread. Wifi just isn't a very efficient protocol for using with deep sleep. The radio takes more power to run, the overhead of connecting is higher, and the device needs a full IP stack. Even with power save mode (if supported by client and AP), the radio is on for hundreds of milliseconds to send a message.
Thread has "sleepy end device" profile built-in where the hub will queue messages and expects the device to be in deep sleep most of the time. And since it doesn't have so much overhead, the radio only has to be on for tens of milliseconds.