misc/soliscloud-inverter-control#8: Conceptual Difficulties with scheduling

Manual Schedules

The setup that I've built is quite simple

• Theres a schedule helper
• An automation fires when that helper changes state and places a request to startCharge or stopCharge

In principle, scheduling is therefore quite simple

However, it's not quite that simple.

HomeAssistant only fires the automation when the schedule changes state: moving from on -> off or vice versa.

When we call startCharge, the charge end time is set 3h in the future.

So, only the first 3h of any scheduled on period is honoured.

Schedule Helpers do (sort of) expose the block end time - there's an attribute called next_event which details when it's planning to change state next.

We probably need to implement the ability for an API request to include that for use as the end time (though that won't help with the next issue)

Intelligent Scheduling

The Octopus HA addon allows creation of a sensor which will turn on when electricity is cheapest and turn back off afterwards (all based on various criteria when setting up).

That would mean that rather than scheduling a slow charge between 00:00 - 06:00 we'd perhaps fast charge 0300-0500.

But, this is where things run into a bit of an issue.

The whole point in that overnight charge is to get us through the morning peak (roughly 06:30 - 09:30).

There isn't actually a way to tell the inverter to not discharge the battery until a certain time. The only way to do that, is to put it into charge mode.

So, the problem is, if our dynamic charging has elected to charge 0300-0500, the battery will start discharging an hour early.

I'm struggling (a bit) to see a good solution to either.

Although we could adjust the control server to accept an end time, it'd mean completely changing the way that HomeAssistant is currently set up: rather than changing the state of the dropdown helper, automations would instead need to call the API directly - meaning that that state is no longer particularly well tracked.

I guess it's probably possible to have the existing automation look up the state of the helper and include that - but that builds in an assumption that that helper will be the only source of change. I guess it is a reasonable start point though.

And actually, that might even work relatively well with the intelligent scheduling once I get to that.

If we imagine the following config

manual schedule: 0300-0600
intelligent range: 0000-0600

If the intelligent stuff selected 0300-0500, but we set the end time to be the next change in manual (0600), there'd be an overlap - we'd just need the automation for the end of intelligent to check whether manual was currently on and refuse to switch off if so.

Of course, that wouldn't work quite as well if it chose 0000-0200, but I think we'd still end up better off financially (if not quite as efficient as I'd like to be)

OK, let's start with that then - HomeAssistant will need to be updated to template the next state change of the scheduler into the request body.

The control server API will need to (optionally) accept and normalise that.

The control server can now accept a JSON payload:

curl -H "Content-type: application/json" -d '{"end": "2025-01-01 17:30:00+0000"}' http://127.0.0.1:8081/api/v1/startCharge

The date format is based on HomeAssistant.

In the example above, the end time would be set to 17:30.

However, the implementation isn't currently safe for deployment because there's no validation of the end-date. If an event fires at 16:00 and the next scheduled change is 01:00, we'll end up firing in something that the inverter can't work with.

Validation should be relatively simple: is end hour lower than start hour?

Whilst not perfect, this has done enough that I've been able to get manual scheduling moved to HomeAssistant.