[Bug]: Power Save mode broke on 2.5.16

[HarukiToreda]

Category

Other

Hardware

Heltec V3

Firmware Version

2.5.16

Description

I believe that power save mode broke on 2.5.16 I've seen this on the Heltec V3.2, Here's the logs of it's power behavior on 2.5.15 after a few seconds of inactivity, current cosumption drops to 8mA vs the normal operation of 102mA

and here it is on firmware 2.5.16 and higher. It never enters power save mode and remains at normal current levels of 102mA

Relevant log output

No response

[caveman99]

did you confirm those are on identical configuration? role and wifi spring to mind here...

[HarukiToreda]

did you confirm those are on identical configuration? role and wifi spring to mind here...

I did, settings are identical, these are the only settings I've modified from default.
Role: Client
Powersave: Enabled
Light Sleep duration: 1800

I've gone from 2.5.16 back to 2.5.15 and it works fine then, but when I reflash to 2.5.16 it behaves as the graphs show.

[todd-herbert]

I just had a very quick test of this with Wireless Paper and I think I'm seeing the same thing. The device did seem to correctly enter light sleep after disabling provide phone location to the mesh in the Android app, though. I got the same result from the two tests I performed, but it was only a quick investigation, so it could have been a coincidence.

[thebentern]

There was only one change to Lightsleep behavior and that was to disable it when connected to Wifi:
#5443

[todd-herbert]

I just got home and gave this another test. It does seem that the position and/or telemetry packets from the app are keeping the device awake, but this behavior seems to be the same on both 2.5.16 and 2.5.15. Has it always been this way and I just never noticed, or is this abnormal?

@HarukiToreda I wonder if in the process of downgrading from 2.5.16 to 2.5.15, you might have disabled using the phone as a position / time source? Maybe the lower firmware version wasn't what made the difference?

[thebentern]

I guess I am also not totally understanding why there is expectation of sleep while paired to the app at all. It seems pretty undesirable to sleep while pushing position data from the app. It pretty much renders things like smart position broadcast useless if you're operating with phone as a position source. I believe power saving mode should be reserved for devices without an active API connection, period, since this generates a lot of confusion and support.

[todd-herbert]

Ah okay, makes sense! I just wasn't clear on whether it was expected behavior or not, but I'm caught up now.

[HarukiToreda]

I guess I am also not totally understanding why there is expectation of sleep while paired to the app at all. It seems pretty undesirable to sleep while pushing position data from the app. It pretty much renders things like smart position broadcast useless if you're operating with phone as a position source. I believe power saving mode should be reserved for devices without an active API connection, period, since this generates a lot of confusion and support.

I understand your expectations regarding the ESP32 behavior, but up until version 2.5.16, the standard behavior for the ESP32 was as follows: when the screen of the node is off, it typically enters power-saving mode. This mode temporarily disconnects it from the phone to conserve energy. For example, during activities like hiking where I rely on the node to track other hikers, I wouldn't continuously use my phone. Instead, I’d rely on the node itself.

By waking the node, it would reconnect to the app and fetch the most recent positions. This behavior ensured efficient power use without needing the node to keep install a GPS module, as the ESP32 already has a high power draw. Similarly, when a message or packet was received, the node would also reconnect to the phone to deliver notifications.

Given that this behavior was functional and met the needs of many use cases, I believe it’s worth maintaining or at least honoring how it operated previously as you can see on the graphs, even if it differs from the current expectation or use case you’ve outlined.

[HarukiToreda]

I just had a very quick test of this with Wireless Paper and I think I'm seeing the same thing. The device did seem to correctly enter light sleep after disabling provide phone location to the mesh in the Android app, though. I got the same result from the two tests I performed, but it was only a quick investigation, so it could have been a coincidence.

you are right, I tested it today again with 2.0.15 and the provide phone location to the mesh is what causes it to stay awake. It's odd since I do most of my tests with that ON and have been able to get it to go to litesleep in the past. I guess it broke at some point with me just noticing till now.

[garthvh]

Given that this behavior was functional and met the needs of many use cases, I believe it’s worth maintaining or at least honoring how it operated previously as you can see on the graphs, even if it differs from the current expectation or use case you’ve outlined.

This behavior results in a lot of questions from users as to why their device does not stay connected to the app, manual intervention here is not expected by most users.

[HarukiToreda]

Given that this behavior was functional and met the needs of many use cases, I believe it’s worth maintaining or at least honoring how it operated previously as you can see on the graphs, even if it differs from the current expectation or use case you’ve outlined.

This behavior results in a lot of questions from users as to why their device does not stay connected to the app, manual intervention here is not expected by most users.

you care correct, it does result in many questions by users. unfortunately despite the documentation stating this behavior people just don't read it. There's nothing that can be done to prevent those questions. Just want to make sure features that extend battery life are not take away due to the inconvenience of answering some of these questions. I can add a note on the documentation that if the phone is sharing the location to the node, it will prevent Powersave mode from kicking in.

[todd-herbert]

I understand that the matter is considered closed, but I'd just like to go on record that I feel the ability to use light-sleep in combination with a client app probably does add a lot of value for users of ESP32-based portable nodes.

I recognise that these are gradually being superceeded by other designs, and that the manual interaction required is less than ideal, but I do feel that there may be a small group of existing users whose set-ups could be significantly disrupted if powersaving and the client API become mutually exclusive.

[thebentern]

Perhaps in the future (3.0), we could refactor power saving to an enum mode instead of simply a boolean to optionally unlock this behavior for the users wishing have the device sleep even with an API connection, but default to the less confusing mode.

[garthvh]

The expectation is that when you are connected to a phone it won't go to sleep and break that connection. This tiny subset can disconnect their device from the phone and have it sleep if that is the desired behavior, not sure why we would want to continue to confuse a larger segment of the user base.

[HarukiToreda]

so if it's too confusing to explain to users on discord and people don't read the docs, how about I suggest this simple clear solution to make users aware of the small inconvenience of pressing the wake button?

I say inconvenience cause the trade off for pressing the wake button, is that it doubles the runtime. Instead of having a novelty electronic that dies in less than a day, you end up with an item that lasts days on battery that is far more useful. Now the GPS part not letting the node sleep is inconvenient but understandable why it doesn't work.

[garthvh]

I still don't get why this small subset of advanced users can't manually disconnect from the app.

[HarukiToreda]

I still don't get why this small subset of advanced users can't manually disconnect from the app.

No worries, I found a work around. Power save mode while still getting gps location when node reconnects on wake.

[todd-herbert]

I still don't get why this small subset of advanced users can't manually disconnect from the app.

A benefit I see personally is that it does still allow incoming packets to be handed to the client app as they arrive. If the ToPhone queue in firmware did hold a longer history though, this would be less relevant.