[FR] Disable bootloop recovery

[flashmark]

Is your feature request related to a problem? Please describe. I am running an ESPeasy application using a battery and solar cell charger. I am using deepsleep to reduce power consumption. The application switches on the power to a sensor. During winter (or other low sunshine periods) battery will get low and the ESP32 may reboot while booting. Due to the implemented bootloop protection plugins, controllers and rules will be disabled. This makes my application not working when the battery is charged again.

Describe the solution you'd like I found the bootloop protection code in espeasy_setup.cpp. By adding a #ifndef section I can switch off the bootloop protection using a define in Custom.h. I compile by custom target with the bootloop protection disabled. This works as expected. Proposed switch: #define DISABLE_BOOTLOOP_RECOVERY

Describe alternatives you've considered No alternatives considered. It will be difficult to act on a brown out situation in software without still enabling a kind of retry to probe when the power is back. hardware options will be more complex. What is implemented is a longer deepsleep period when the measured power supply is below a threshold, but that will only stretch the time until brown out kicks in.

Additional context I did write plugins in VScode and can deliver this feature myself if it is seen as a useful addition. Application is a capacitive soil moisture sensor with analog output located in the garden. Sensor is powered using a high side mosfet.

[tonhuisman]

An different twist on your idea:

• Use feature-flag #define FEATURE_ENABLE_BOOTLOOP_RECOVERY 0 in Custom.h and add

  #ifndef FEATURE_ENABLE_BOOTLOOP_RECOVERY 
  #define FEATURE_ENABLE_BOOTLOOP_RECOVERY 1 // Enabled by default
  #endif

  as a default-value check in define_plugin_sets.h

• Check the feature flag using #if FEATURE_ENABLE_BOOTLOOP_RECOVERY / #endif

This allows to explicitly enable this feature if desired, and gets it more in line with other FEATURE_ (compile-time) flags.

[flashmark]

Indeed best to keep it aligned with the other compile time features. I will prepare a pull request, but that might take some time as I will not behind my computer for some time.

[TD-er]

Or maybe another approach and make sure you're using some protection circuit to prevent deep discharge of the battery. For example LilyGo has several boards with some 18650 battery and a power management chip like the AXP192. (or similar chip, but at least the AXP192 is already supported in ESPEasy, others are pending) This chip can be configured to completely turn off the power supply when the battery voltage drops below some set threshold (e.g. 2600 mV)

As a matter of fact, I was just experimenting with such a board (the T-beam 1.0 with LoRa chip) and it does consume about 1 mA when in 'sleep mode' and 60-ish uA when turned off.

The reason I'm suggesting this is because it is rather tricky when you allow your battery to get discharged too far as it may get damaged and then it might refuse to charge again or even worse it might blow up like a balloon and cause a fire hazard..

Also there is another issue which is rather specific to ESP32-classic boards as far as I know, that it might trip the brown-out detection from which it might not recover even if the voltage is back to normal 3V3 until you power cycle it.

Turning off the tasks/controllers etc. is not saved to the flash, so you can check this from within rules and re-enable tasks from the rules. You can check if a task is enabled. See: Rules: Task-specific settings

[TD-er]

Some example of a board with AXP2101 chip (more advanced version of the AXP192, soon supported in ESPEasy) which isn't too expensive: https://www.tinytronics.nl/nl/development-boards/microcontroller-boards/met-wi-fi/lilygo-t-pcie-v1.2-axp2101-esp32-wrover-16mb

It can be connected to various kinds of 3V7 Lithium cells. (not just 18650)

[flashmark]

Thanks for the suggestions. Next project I will definitely look into better handling of low battery conditions and solar charging. The current project uses a 18650 with protection which should, as far as I know, protect against over and under voltage. I use a Lolin32 like board with a 3v3 low drop power supply and a TP4045 LiPo charger onboard. The solar cell is connected using a separate charger board. Just a collection of cheap Ali stuff... I think the main problem is that I use a rule to switch on the sensor power a few seconds after boot. This will charge some small capacitors probabaly causing a dip in the power supply. Voltage is measured by ESPeasy through an analog input and sent to Domotics together with the sensor value after a acquisition delay. The supply voltage is indeed dropping below 3v3 before "shit happens". When I charge the battery through USB all plugins, controllers and rules appeared to be switched off. After disabling the "bootloop protection" the board just works as expected after an overnight battery drain test and USB charge. So it seems to work for me. Currently it is installed and working fine, charged to 4V2 each day. It is in the garden in a ABS box placed such that a small fire won't harm (roof of the shed, tied to a brick). Let's see what happens in winter.

Main question is if delivering this feature to mega branch brings benefits for other developers. If so, I can make a pull request. If judged otherwise I keep it at home :-)

[TD-er]

Like I said, you can in rules check for the voltage and then decide to re-enable the disabled plugins. So for this use case it should not be required to have this code in place, unless the rules parsing is also disabled by this bootloop protection code.

Also I wonder if removing this protection isn't going to bite you later (or anyone who tries to disable it). If the bootloop protection code is also disabling the rules, then I guess it would make sense to have a build flag to disable this step.

Another thing for you to check... You mentioned there is some analog input measuring the battery voltage. I guess this is done using some resistors, which are permanently connected to the battery? If so, please keep in mind that most discharge protection circuits need some minimum current to properly work. Having resistors with high resistance values over a 18650 cell will eventually discharge the cell to a voltage which is too low to recover from.... Ask me how I know...