Octopus API Charge Windows being overridden

I've recently started encountering an issue where a server API call is interfering with the Octopus API Time Charge Window. Around midnight each night, the Octopus API successfully configures a charge window to top up the battery. However, another server API call overrides this a few minutes later, resetting the charge window to 00:00 - 23:00.

Even if I stop the automation or make manual changes during the day, this API call will overwrite any adjustments I make and restore the 00:00 to 23:00 charging window. This behaviour is not ideal.

Has anyone encountered and how to I fix ?

2025-01-12 00:30:12 Server AC Charge 1 End Time Written Successfully 07:00 23:00 23:00 API - Inverter Settings - Automation Scheduling
2025-01-12 00:30:12 Server AC Charge 1 Start Time Written Successfully 04:00 00:00 00:00 API - Inverter Settings - Automation Scheduling
2025-01-12 00:05:05 GivEnergy-Octopus S. (GivEnergy) AC Charge 1 End Time Written Successfully 23:00 07:00 07:00 API - Inverter Settings
2025-01-12 00:05:05 GivEnergy-Octopus S. (GivEnergy) AC Charge 1 Start Time Written Successfully 00:00 04:00 04:00 API - Inverter Settings

Have you any intelligent tariff running? What tariff are you on
Are you using the smart tariff beta?
Are you using HA and any automations and/or predbat
What do inverter logs on the GivEnergy portal page show- any indication where the command is coming from

SandersonEH14 it sounds like you have two conflicting smart tariff optimisations fighting over your system. Perhaps revoke API access token and see if one or both give up.

What model of inverter do you have? And what tariff are you currently on? One schedule is perhaps for Cosy?

Or is it the new "problem", winter conditioning turned on...

I’ve been using the beta smart tariff automation successfully until a few nights ago. As you mentioned, there are two automation processes involved, but I’m struggling to identify what the second one is. From the logs, I can see the Octopus API (user: GivEnergy-Octopus S. (GivEnergy)) is working correctly, setting the charge window each night according to the Octopus Agile rates. However, right after this is set, another routine, initiated by the user "Server", changes the recharge window to 00:00 - 23:00. This is frustrating because it recharge windows is 23hrs long , and as a result, it doesn’t allow for discharging since it’s continuously in recharge mode. What I don’t understand is how this second setting is being applied. The logs indicate that the task is being run by the "Server" user via the API under Inverter Settings > Automation Scheduling.

Logs below show problem - Octopus API sets value to 04:00 hrs from old 00:00 value - which I would expect.
Then API - Inverter Settings - Automation Scheduling backs this out by putting back the 00:00hrs

I will look at winter battery conditioning to rule out and also revoke all API tokens and start from scratch - what is annoying is not knowing what changed.....very odd

2025-01-12 00:30:12 Server AC Charge 1 Start Time Written Successfully 04:00 00:00 00:00 API - Inverter Settings - Automation Scheduling

2025-01-12 00:05:05 GivEnergy-Octopus S. (GivEnergy) AC Charge 1 Start Time Written Successfully 00:00 04:00 04:00 API - Inverter Settings

SandersonEH14 The logs indicate that the task is being run by the "Server" user via the API under Inverter Settings > Automation Scheduling.

Hmm... I think "Server" might be the generic term for Givenergy's automated processes.

Looking in my own logs, 'Server' is used to mark cases where the cloud has detected changes I've made locally through modbus - ie it is just updating the portal to match changes I've already made. But looking back to the end of October, it was 'Server' that adjusted the time on my server at the end of BST, for example.

If that's the case, would probably need to ask Givenergy support to see what's going on.

I’ve updated everything, removing all API tokens and confirming that the smart tariff automation has been disabled in both the app and portal.

Despite this, the user "server" continues to make an API call and inexplicably changes the Timed Charge settings to a 23-hour charge window, spanning from 00:00 to 23:00. During that time you can't discharge as its wanting to charge and it typically charges at the highest agile rates.

The most frustrating part is the complete lack of support from GivEnergy. Since November, there’s been no telephone support—only a web form to request assistance, which no one at GivEnergy seems to respond to. Is the company on the verge of collapse?

TX200 Confirmed not using - battery is inside.

SteveCook its coming from a user called server - an internal invertor process, as I can't see how or where that is configured. Any ideas on how to trace inside the inverter processes?