I think there's a missing logic in the API commands that go out when WW decides that the timed discharge should not take place.
I have a daily smart timed charge in the early morning followed by a conditional timed discharge from 17:05 to 19:00 (peak selling time rate).
Today the battery performed as follows:
Based on the following (correct) decision pattern of WW:
The battery charged ok to the calculated 31% based on a 13.0 kWh solar prediction for the day.
The prediction was not the reality and the system only generated 1.8 instead of 13.0 kWh today - too bad, weather predictions remain predictions. (Usually however it works fine - which is why I did not yet encounter this bug before).
5 minutes before the planned timed export (17:00), WW ran the logic to verify whether discharge should take place and because the battery was only at 19% it correctly decided not to activate the discharge schedule, but it did send out two other API commands, and that's where it went wrong:
At 17:00:05 and API command was sent to disable DC discharge
At 17:00:06 the battery reserve % limit was changed from 4% to 20%
This caused the system to start pulling energy from the grid (at it's most expensive rate) and not using the available remaining battery capacity.
I discovered this and at 18:00:02 manually reset the battery % limit back to 4%. At that point (clearly visible in the graph) the house started pulling back from the battery.
Bottom line: when for whatever reason the battery ends up being lower than the target starting SOC for a timed discharge, WW should not touch the battery % limit which it reset each time at the end of a time discharge back to the original value. It did that in my case at 18:58:56 the previous day at the end of the timed discharge window (correctly):
@admin : kindly review this logic - this needs a fix
