Don’t get me wrong… NETWORK_INTERFACE_CELLULAR will certainly help but it still consumes a lot of power for an IoT device when sleeping the MCU with the Cellular Radio on.
In my simple mind, I equate it to keeping your cell phone “ON” but the screen turned off. It’ll use a little less battery but no where near as if you turning the entire cell phone off. In my experience I can go from ~7 days to maybe ~10 days on a 6600 mAh battery. It helps directionally but doesn’t make it a low power device.
To exacerbate this even more are you using BRN402, BRN404 or BRN404X? The latest BRN404X was recently discovered to use 2.4X the amount of power anytime the radio is “on”. The table shared above is not correct for BRN404X. So when I was getting ~7 days I now get maybe 2-3 days. This was highlighted in this post here: BRN404 vs BRN404X - 2.4X increase in power consumption?
Hoping the wonderful team at Particle is able to address this with a firmware update. Your use case, I believe is the perfect example of why we need “eDRX mode” capability to be developed by Particle. I’m sure I’m oversimplifying it but this would allow for a 10X reduction in sleep current when keeping the cellular modem “partially awake”.
In the absence of all of that, what I personally do is have different modes I can put a device into from the cloud. This includes, Always On, Sleep with network, normal sleep (connect every 20 minutes) and deep sleep (connect every 2 hours). When I want to interact with the device more real time, I just flip it from sleep mode to always on. The next time it connects, it’ll then honor that selection and from that point forward I can control real time. When I’m done, I can flip it back to a sleep mode. It does take a little advance planning but for my use case, that is just fine. I just need to remember to change modes before it wakes up and connects or I have to wait another 20 minutes. Does that make sense? This likely does take some backend system to develop.