Deep discharge counter: strange behavior

Measurements showed that the deep discharge counter (data object DeepDisCount) increased to values >2000 within a few days, which should not happen.

Browsing the code, the counter is incremented if we have the discharge active AND the voltage gets too low.
Then discharge is disallowed.
The only times when discharge active becomes true again, are restarts since a couple of init functions set this to true unconditionally or if the battery voltage passes a certain threshold.
So in order to achieve such a high count, either the controller restarts frequently (watchdog) while being fairly discharged or the thresholds for discharge off (deep discharge) and on again are small enough that after charge and reenabling the load, the voltage drops again below the deep discharge voltage under load, creating some kind of oscillation.
In any case, the battery must be close or below to discharge cutoff voltage. If not, then there is may something else wrong in the code, but I did not see it.

There's a point, maybe the controller restarts frequently setting the discharge to true , again talking about oscillation, adding hysterisis on the setpoint , or allow the counter once if PV is disconnected , re-enable and stay awaiting if PV is reconnected and charge battery for a set time with set current . Or maybe the PV wasn't enough for the load , so the current starts to swing , thereby enabling and disabling counter .

Well, of course the controller should not restart 2000x times. For the hysteresis, in normal cases (default configuration) there is a sufficient hysteresis between disconnect voltage and reconnect voltage.
But with an accidental reconfiguration to inappropriate values this could become an issue.

I tried to reproduce it with a power supply and was only able to increment the counter by changing the battery voltage between load disconnect and load reconnect voltage, which is as intended. If that happens so quickly, the hysteresis might not be large enough, see here:

charge-controller-firmware/src/bat_charger.cpp

Line 55 in 7ee248c

    
           bat->voltage_load_reconnect = num_cells * 2.05;     // maybe increase to 2.10, if hysteresis observed?

I selected the thresholds according to suggestions in EN 62509:2011. However, they provide a range and I took a quite narrow range because the switch-off behavior is current compensated in our case. This means, if the load current is higher, the battery is switched off at a lower voltage.

I really hope it didn't happen because of watchdog resets. But it's a valid point, @hogthrob. That device had a GSM module installed at the UEXT port, which might have got stalled. I'll need to double-check that.

See PR #40 for possible solutions. What do you think, how long we should wait at least until reconnecting the load?

Closed with 45e29e1.

Issue will be reopened if it is shown to be an insufficient solution.