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