[Feature Request]: Option to turn off LED inducators on ESP32 Heltec V3 about firmware HOT 11 CLOSED

Going to have to implement at an even lower hardware level:

from firmware.

Coming from yet another perspective… being able to switch off LEDs would also have a positive impact on battery life. Every little counts sometimes.

from firmware.

Hi, I raised a draft PR to allow users to turn the LED off. #3674

Right now, the only option for those of us who have nodes we can see from our beds, or run a solar node and want the power saving, is to desolder/remove the status LED.

Also, for products like RAK4361 on RAK19007, the solar panel is connected to the battery charging IC, resulting in a 1Hz on-off cycle for the status LED to indicate charging, which does consume more power than the regular 1ms flash.

from firmware.

I don't see this as useful for power savings, but I do appreciate being able to turn off the Heltec white LED 😆

from firmware.

in my opinion, that would be a great option.
Preferably the user could choose to have the LED always off, always blink, or blink when there's an unread message.
I'm not exactly sure how the different LED indicators work on different boards. As I see it now, the bright white LED on many Heltec boards just blinks every wake cycle or so, while other boards also have a power on LED, a GNSS LED...?

from firmware.

I suppose one function of the blink is that it indicates the crucial OSThread system is still running happily; not bogged down with one big blocking task. I'm not sure whether this was the original intention.

It lights up the window and room at night in which the Heltec V3 is in.

I could certainly see the benefit in having a setting to disable the blink, for situations like this.

[it could] blink when there's an unread message.

This could be another useful option, certainly on boards with only the one LED. There is already support for an alert LED, through the External Notification module. It would actually be fairly straight-forward to allow repurposing of the blink LED for alerts through this module. This isn't as user friendly as a simple toggle switch in settings would be, but it would avoid the hurdle of getting a new setting added, so it might make a good back-up option?

from firmware.

Problem is that we generally only control one or two of the up to 4 led's.

from firmware.

Is the hurdle of adding a config option a big one? And how would one go about such a thing?

From a technical standpoint:

• the protobufs are defined in https://github.com/meshtastic/protobufs/, that would be the place where a pull-request would need to be made.
• a good example commit showing a new setting added to the protobufs might be meshtastic/protobufs@6ae27a2
• what I have done previously for testing:
  • locally clone the git repos for firmware, protobufs and the python cli
  • make your changes in the protobufs repo
  • in both the firmware and python repo, change the protobufs submodule to point at your local protobufs repo
  • in both the firmware and python repo, use the scripts in the bin folder to rebuild their protobufs code. From memory the python script needed some tweaking (have been told that the python repo is a bit broken)
  • flash your device with the now updated protobufs code
  • use the python cli to test out changing your device's user config
• I assume that wider changes (apps, web-ui etc.) require manual intervention. See this Andoird App commit and its matching protobuf code: meshtastic/Meshtastic-Android@4f29e7a, config.proto L187

From a decision making standpoint:

• my impression is that changes to user settings are more carefully considered, and that currently the general desire is to simplify user settings rather than add to them, though I do believe that new settings are still an option if the case is very strong.

from firmware.

While the power savings would be negligible, it certainly sounds there's a demand for this behavior as a customisation option.

from firmware.

I implemented this last week as a user configuration option, and stalled on "now how do I check this in since it depends on a change to protobuf, and that seems kind of major..." I was imagining "dark hours" to not blink during certain (or all. or none if you're into that sort of thing) hours, instead of just a. boolean, but so far I only implemented the boolean.

Is the hurdle of adding a config option a big one? And how would one go about such a thing?

from firmware.

Coming from yet another perspective… being able to switch off LEDs would also have a positive impact on battery life. Every little counts sometimes.

This is not going to have any appreciable battery life impact, and will not enable dark mode, all I see this doing is causing confusion

from firmware.