Charge status is not set when in a charge slot until after midnight

[stevebuk1]

When charging has started and Pv_opt recognises it is in a charge slot, this message is shown:

10/01, 23:30:34     INFO: Currently in charge/discharge/hold slot
10/01, 23:30:34     INFO: Current charge/discharge window ends in 419.4 minutes.
10/01, 23:30:34     INFO: Charge status is not active, setting start time value now
10/01, 23:30:34     INFO: Setting start time to 10-Jan 23:30 GMT
10/01, 23:30:34     INFO: Setting end time to 11-Jan 06:30 GMT

10/01, 23:40:14     INFO: Currently in charge/discharge/hold slot
10/01, 23:40:14     INFO: Current charge/discharge window ends in 409.8 minutes.
10/01, 23:40:14     INFO: Charge status is not active, setting start time value now
10/01, 23:40:14     INFO: Setting start time to 10-Jan 23:40 GMT
10/01, 23:40:14     INFO: Setting end time to 11-Jan 06:30 GMT

This repeats every optimiser run.
The status reported by the third line is incorrect, and as a consequence the start time is written and continually incremented on each optimiser run.

At midnight, the issue then corrects itself, charge status is shown as active and the write to the start time is omitted:

11/01, 00:00:38     INFO: Currently in charge/discharge/hold slot
11/01, 00:00:38     INFO: Current charge/discharge window ends in 389.4 minutes.
11/01, 00:00:38     INFO: Charge status is active, not setting start time
11/01, 00:00:38     INFO: Setting end time to 11-Jan 06:30 GMT

This then continues correctly until charging finishes at 6.30am.

Expected behaviour would be that once a charge window has started the start time is not written again to the inverter, this avoids the risk of EEPROM/FLASH wearout due to continual updates. This functioned correctly in v3.x.x.

pv_opt.log
pv_opt.log.1.log

[fboundy]

I think this is because the Solis inverter can't cope with slots spanning midnight. I had to fix it before but it must have got lost in the re-factor of solis.py.

[fboundy]

See latest commit to patch

[stevebuk1]

Thanks, have also added a fix for #372 into patch and will trial overnight.