using OpenAPI v3/device/schedule/enable
Hi All,
I'm new to the forum. Anyway, I've been building a Python based Home Dashboard that includes many things (Weather forecast, upcoming calendar events, Smart Devices control etc.) as well as a dashboard of the Fox-ESS System. This shows most of the working status of the system (PV generation, grid in/out, house load, battery SoC and power in/out). This is all working very well. The next step is to add control of the current mode (Mode Scheduler). Can anyone share examples of working v3/device/schedule/enable json messages. My concern is around Fox-ESS's new (ish) "defualt mode" it uses in its Web and Phones Apps. Their json's include a "isRemainMode" flag is there v3/device/schedule/enable commands. This seems to allow for overlaping schedules (you see it on the apps). So you can have a "Force Discharge" for 16:00 to 19:00 and there will be the "default" (fall back) schedule set to say "selfuse" for 00:00 to 23:59. Which appears to be a no no, for using the public API. How is this managed when using the Open API that does not have the "isRemainMode" flag?
Many thanks in advance.
Rob
PS Yes, I am reinventing the wheel as I could use Home Assistant etc. I'm retired, I've got the time, and I'm learning stuff.
Inverter: H3-10.0-Smart
Batteries: EQ4800-L9
PV's: 13.6kw Who Flung Dung (unknown Chinese Panels?)
PV Inverter: 10kw Solaris
Re: using OpenAPI v3/device/schedule/enable
Please post an example of some JSON including the flag as this isn't in the public docs.

My guess is that this is flagging the Remainng Time Slots periods 00:00-23:59 and sets the default work mode. It probably only works when attached to that time period.
H1-6.0-E hybrid inverter
6 x HV2600 v2 batteries
16 x JA Solar 405w panels
7 x Tigo TS4-A-O optimisers
Re: using OpenAPI v3/device/schedule/enable
From a quick test, the isRemainMode flag isn't processed by Open API. You can send overlapping time periods via Open API though and these are accepted. However, it isn't clear how these will be processed by the inverter.

The best advice when setting schedules via the API is always send explicit non-overlapping times and modes to cover the whole day. In this case, there is no need to try to send a remaining time period.

If you get a remaining time period fetching schedule data, the best approach seems to be to delete it for reliable operation of your schedules.
H1-6.0-E hybrid inverter
6 x HV2600 v2 batteries
16 x JA Solar 405w panels
7 x Tigo TS4-A-O optimisers
Re: using OpenAPI v3/device/schedule/enable
I'm probably not being clear. if you look at the Fox Phone App and Web App Mode scheduler you see the current versions have a way to set the "default mode". On the Web app, its called "Remaining Time Slots" on the Phone "Remaining Time Mode". These set a default (fall back) mode when using the Mode Scheduler. If you look at messaging of the fox system (it uses paths "/dew/v2/device/scheduler/set" and "/dew/v3/device/scheduler/get") there is a flag in the message called "isRemainMode" ie. GET returns.
"result": {
"schedulerList": [
{
"enable": true,
"startHour": 18,
"startMinute": 30,
"endHour": 18,
"endMinute": 50,
"workMode": "ForceDischarge",
"minsocongrid": 10,
"fdsoc": 75,
"fdpwr": 2000.0,
"maxsoc": 100,
"isRemainMode": false
},
{
"enable": true,
"startHour": 0,
"startMinute": 0,
"endHour": 23,
"endMinute": 59,
"workMode": "SelfUse",
"minsocongrid": 10,
"fdsoc": 95,
"fdpwr": 5000.0,
"maxsoc": 95,
"isRemainMode": true
}
Here you can see the second schedule is set for 00:00-23:95 (all day) and "isRemainMode" = true. This schedule doesn't appear in the list of schedules on the Web or Phone (its hidden). also you see the 2 active schedules overlap, which isn't allowed using the public API?
Hers the POST after the visible (my schedule) was disabled
"schedulerList":[
{
"startHour":18,
"startMinute":0,
"endHour":19,
"endMinute":0,
"workMode":"ForceDischarge",
"enable":false,
"minsocongrid":10,
"maxsoc":95,
"fdsoc":70,
"fdpwr":5000,
"isRemainMode":false
},
{
"enable":true,
"startHour":0,
"startMinute":0,
"endHour":23,
"endMinute":59,
"workMode":"SelfUse",
"minsocongrid":10,
"fdsoc":95,
"fdpwr":5000,
"maxsoc":95,
"isRemainMode":true}
],
again you see isRemianMode flag.

My concern is the Public API doesn't support the isRemainMode flag.
When I do a schedule get ('/op/v3/device/scheduler/get') the schedule included this "default" schedule (00:00-23:59 etc.) and is enabled as well as any custom schedules I've added. When I modified my schedules upload including the downloaded default untouched ('/op/v3/device/scheduler/enable') it was accepted (Success) but the Phone app Mode Scheduler didn't work properly anymore (assume because there's now an over lapping schedules). I was hoping to see an example of a full working json message showing how the default mode was handled and ask how the Fox apps looked after these were uploaded.
To me it looks like Fox has made a mistake (intentional?) by making their internal API (dew/v2) and the public API (/op/v3/) not compatible with the "default" mode they now use in their apps, as its not supported in the Public API.
Again, if you do a GET using Public API the default mode schedule is included but isn't flagged as default (well I haven't seen it). Its just another schedule that is enabled and overlaps any custom scheds. So I gather you need to remove it/replace it with something different before uploading the new schedules...
Inverter: H3-10.0-Smart
Batteries: EQ4800-L9
PV's: 13.6kw Who Flung Dung (unknown Chinese Panels?)
PV Inverter: 10kw Solaris
Re: using OpenAPI v3/device/schedule/enable
Thanks for posting the JSON.

No, what you asked was clear and I understood first time. The API used by the app and Open API are completely separate. Fox often updates their own API without updating Open API. Sometimes, there are problems caused by this that we have had to deal with for many months before they (eventually / hopefully) update Open API.

There is no way to configure the Remain Time Mode period via Open API currently. Even if you try to add 'isRemainMode' to the JSON sent to Open API, it won't be processed and all of your time periods will be set as user defined periods.

The best approach is to check for and filter out the time period 00:00-23:59 when reading schedules from Open API as setting this via Open API may stop your other scheduled time periods from working.

If you want to set a different mode at a specific time, you need to add an explicit time period for this.

This is what 3rd parties that are using Open API to configure schedules are doing now.
H1-6.0-E hybrid inverter
6 x HV2600 v2 batteries
16 x JA Solar 405w panels
7 x Tigo TS4-A-O optimisers
Post Reply