[Bug]: Always On means Always ShutDown?

[villamany]

Contact Details

No response

Checklist

• I am able to reproduce the bug with the latest version.

• I have updated to the latest Alpha firmware, and am able to reproduce the bug. Many issues are fixed quickly in alpha before the general beta release.

• I made sure that there are no existing OPEN or CLOSED issues which I could contribute my information to.

• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.

• This issue contains only one bug.

• I have read and understood the Contribution Guidelines.

• I agree to follow this project's Code of Conduct

• I actually read this list, and should be taken seriously.

Affected app version

2.7.13

Affected Android version

Android 14

Affected phone model

Galaxy

Affected node model

Heltec v4

Affected node firmware version

2.7.20

Steps to reproduce the bug

Setting the 'ShutDown on power loss" setting to AlwaysOn is shutting down the device Always when detect external.power supoly disconnection.

Setting to 72h is working as expected

Actual behavior

No response

Expected behavior

Screenshots/Screen recordings

No response

Relevant log output

Additional information

No response

[roberthadow]

Hello @villamany --

I took the advice of the documentation. "Don't use this setting if you ... are using a device without a user button." My devices are either in a tree or I want them to work without human intervention (a button push). I don't use it. My devices have power.onBatteryShutdownAfterSecs set to 43200 seconds.

This matter is touched upon in meshtastic/meshtastic#2324. Your issue is not properly classified as an Android issue. It would be a firmware issue. power.onBatteryShutdownAfterSecs is an integer type, which for every positve integer value is used for a countdown timer in seconds, The "Always on" option either disables the timer, or implicitly allows the timer to run forever (an infinite period). Infinity and NaN (0/0) are troublesome in most programming llanguages. Therefore zero has a unique meaning when assigned to power.onBatteryShutdownAfterSecs. This exception is an edge case. It is the kind of thing one would look for first in a software peer review.

As an experiment, I enabled "Power saving" on a Heltec V4 node running firmware 2.7.20 (exacty your configuration). While the device is plugged into USB, the OLED remains lit. Power saving is irrelevent when the device has external power. When I unplug the device from USB, the OLED remains lit. I waited awhile to observe how it operates differently. At approximately 540 seconds, the OLED shut down. That's compliant with the Screen Timeout setting of 600 seconds. After that, another nearby device sent a message on Channel 0. The OLED came back to life. Eventually it went off again, which is what Iwould expect. Later, when I plugged in again and attempted to reconnect to the web app, I had to go through the dance of reestablishing a USB session. This is exactly what I would expect from a device that has shut down BLE, Serial, WiFi, and the OLED.

No error observed in the Power save mode.

So conducted a another experiment. In the Web app, I disabled "Power save" and set power.onBatteryShutdownAfterSecs to 0 seconds. On disconnetion from USB the device continued to run. It did not turn off after 0 seconds. I don't have the patience to wait to see if the unit stays on forever, so I bet the zero seconds setting works fine.

Then, I connected to my Android. "Shutdown on power loss" had reverted to Unset. That is potentially a bug. I don't know how Unset is treated. Gemini says the default value for power.onBatteryShutdownAfterSecs is zero, but I don't trust AI. In any case, I changed the value to Always On. The device continued to operate after I unplugged it. I am led to believe Always On works.

So I conected again to the Web app. This required a manual reboot on the device. When the Web app was connected, I observed that "Shutdown on battery delay" had changed to 2147483647. That's not Always, but it is sixty years from now, which is close enough to forever for me. If the intent is never to shut the unit down, it's a waste of machine cycles to run a countdown timer through 2147483647 cycles, but I'm not the one writing embedded code.

I changed 2147483647 to zero then connected again to Andoid. "Shutdown on power loss" again changed to Unset.

I connected again to the Web app. What had been "Unset" appeared as "Shutdown on battery delay" = 0.

In short, yes, there is an inconsistency where the Web app and Android are concerned. It does not appear to me to be a bug that prevents proper operation. It would be nice, however, if the settings "Unset", "Always on", 0, and 2147483647 which are for all practical purposes the same, be made into one integer value and one equivalent text selection.

[villamany]

The main issue i found (after a few days going up to the roof to reset) is if you have an unattended device powered by a solar panel with a slightly incorrect ADC calibration. When the battery is at 100% and the device thinks it's receiving external power, a slight drop in the battery level return it to detect is battery powered, with the "Always On" option enabled, It will instantly go to sleep mode. In that case, you have to wake it manually.
Maybe removing this option from the dropdown menu is better than this unexpected behavior.

[roberthadow]

@villamany So your underlying problem is the need to manually reboot the device after a night or two outside. Right?

Have a look at meshtastic/firmware#9911.

You report, "When the battery is at 100% and the device thinks it's receiving external power, a slight drop in the battery level return it to detect is battery powered, with the "Always On" option enabled, It will instantly go to sleep mode."

I have a Heltec V4 unit by my desk and the patience to watch it and the USB power monitor I have between it and the PC. Here are the power consumption modes:

• OLED on. Battery indicating 100%. Red LED off. 0.14 A delivered by USB.
• OLED on. Battery indicating 100%. Red LED on. 0.24 A delivered by USB.
• OLED on. Battery indicating <100% Red LED on. 0.74 A delivered by USB.

The device cycles between the first two on an irregular schedule. If I starve her of USB and solar, upon reconnection I see the third.

When connected to my Android, the power consumption profile is the same. The Android app indicates only connection status and voltage, but not battery state. The battery state indication on the web app updates only if you refresh the web session, so it's not particualry useful.

After that shaggy dog story, I surmise that the Heltec V4 has three states: (a) charged, (b) almost charged, and (c) in need of a charge. When it's charged, it does run off the battery, even if external power is aviable. You observe that when your unit runs down to (b) almost charged, even though it indicates 100%, it goes to sleep. Mine doesn't. Mine has to use a lot of battery before it goes to sleep. Nevertheless, when it does, simply giving it power is not sufficient to get it to resume. Then, I too have to touch the RST button.