top | item 45838005

(no title)

gregmac | 3 months ago

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

discuss

order

cameldrv|3 months ago

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.

05|3 months ago

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