Regular readers will know that my Energy Smart home includes a storage battery. That battery is either charged from my solar panels (effectively free electricity), or low cost electricity bought from the grid, or some combination of the two depending on the solar forecast for the day ahead.
Powervault storage 
Solar forecast
The logic of how much battery charging is required has until now been driven by a set value for the number of charging hours required. The number of hours of solar charging predicted is deducted from the the number of charging hours required to calculate the number of bought charging hours required outside the solar production window.
Bought charging hours required :=
Total hours required – Solar hours predicted
However with experience this appears to be a sub-optimal arrangement. At one extreme on a very sunny day the battery will fully charge and then be allowed to discharge continuously through all other hours, there is no middle ground in which the battery is not permitted to discharge through the night. However at the other extreme if the battery is replenished entirely from the grid then there will be hours when discharge is not permitted since, after accounting for cycle efficiency, the value of the electricity in the battery is higher than the cost of that from the grid and thus it’s better value to use grid electricity than stored electricity. As there are fewer discharging hours then fewer hours of charging will be required to refill. Thus the depth of discharge is greater when charged from solar than from the grid requiring more charging hours to refill. Leaving the longer charge time for a full charge in use then creates a risk of charging the battery when the grid price is higher than necessary leaving the battery possibly full by the time the lowest cost grid energy is available. Having a more accurate target for the charge time would enable the lowest cost charging periods to be selected more precisely.
The new refinement is to automatically adjust the bought charging hours between two existing user-defined values: the existing target hours and the maximum charging hours currently used just to cap charging hours during plunge pricing events (i.e those with negative cost events). The new algorithm can adjust to any value between the two limits in half hour intervals. As currently configured that’s anything between five and seven hours. The new algorithm is:
Total hours required := minimum (Maximum hours from plunge,
maximum (Target hours, Solar hours predicted + 1))
| max hours (A) | Target hours (B) | Solar hours (C) | C + 1 | Max (B, c+1) | Min (A, Max(B, C+1)) |
|---|---|---|---|---|---|
| 7.0 | 5.0 | >= 6.5 | >= 7.5 | >= 7.5 | 7.0 |
| 7.0 | 5.0 | 6.0 | 7.0 | 7.0 | 7.0 |
| 7.0 | 5.0 | 5.5 | 6.5 | 6.5 | 6.5 |
| 7.0 | 5.0 | 5.0 | 6.0 | 6.0 | 6.0 |
| 7.0 | 5.0 | 4.5 | 5.5 | 5.5 | 5.5 |
| 7.0 | 5.0 | 4.0 | 5.0 | 5.0 | 5.0 |
| 7.0 | 5.0 | <= 3.5 | <= 4.5 | 5.0 | 5.0 |
