FoxESS Community - Owners & Installers Forum

Hi all,

I’ve installed the foxess_modbus_EVO integration by Adam Newberry, but I’m seeing some strange behaviour when trying to change the inverter’s work mode.

Whenever I try to select Force Charge or Force Discharge, I get this error:

"Failed to perform the action select/select_option. Unknown error."

I’m also seeing incorrect mode changes. When I change the mode, the system initially accepts it, but then it automatically switches to a different mode. For example, if I’m in Peak Shaving and select Self Use, it changes to Feed In First instead. And if I then switch it to Back-up, the mode ends up showing as Unknown.

Has anyone come across this before? Any idea what’s causing it or how to fix it?

Thanks!

Brian

First check that there are no schedules set or enabled in the inverter via www.foxesscloud.com/v2 - delete any that are there.
It is also possible that some of the EVO's modbus registers are different to those used in that integration.

IIRC force charge/discharge via modbus may not be available on some firmware versions

I have checked there are no scheduled or enabled via www.foxesscloud.com/v2.

nrb501 wrote: ↑Fri Mar 27, 2026 8:35 am First check that there are no schedules set or enabled in the inverter via www.foxesscloud.com/v2 - delete any that are there.
It is also possible that some of the EVO's modbus registers are different to those used in that integration.

IIRC force charge/discharge via modbus may not be available on some firmware versions

I'm having the same experience, and looking at the code, version 2 some of the registers are incorrect. Despite correcting this I'm still not able to get the work mode to stick. Not sure why but I'm trying to troubleshoot

Hi all,

I’ve finally managed to get the mode setting working on the EVO through Home Assistant using modbus. I’ve been in contact with Fox ESS support, and after they updated my firmware, everything is now working correctly. I deleted the mode schedule on my phone app.

I have asked Fox support how I can set the force charge and discharge using modbus. Hopefully they will get back to me shortly. They have been very helpful so far.

The firmware versions I’m currently running are:

INV_Master: 1.15
INV_Slave: 1.00
INV_Manager: 0.30
AFCI: 0.37
Software: 2.09
BAT_BCU: 1.004

Would be interested in your results

I currently have another issue

If I set schedule to force charge it does nothing
If I set “remaining time mode” in the schedule to force charge out side the schedules time it force charges.

If I disable the schedule, not delete it, it also starts to force charges all feels back to front.

Fox tested it said it worked ok for them
I tried it after their email and it worked.
Hours later I tried again and it didn’t work.

UPDATE 11/5/26

My ISO app auto updated today
It’s now version 2.2.11

What’s new….
• Add relevant business functions for heat pumps;
• Optimization of quick setting function;
• Add one-click detection for battery faults;
• Optimize the password reset function.

Well unless it’s a coincidence my issue is now resolved with Mode Schedule
Hope yours is too

Yes I've just tested mine and force charge and discharge work now

Now hopefully my automations will work!

Are you IOS?

SoFather wrote: ↑Mon May 11, 2026 9:21 amAre you IOS?

Sorry I don't know what that is. I did however just get a fox cloud app update

IOS = Apple Phone
Android = well Android Phone lol

Oh right sorry, yes I have an android phone.

MattyS wrote: ↑Mon May 11, 2026 9:07 am Yes I've just tested mine and force charge and discharge work now

Now hopefully my automations will work!

However, self use and feed in no longer work.

I just got another update lol
2.2.12 now

I've been doing some digging and some testing too, and what I've personally found is that to write to the work mode on theEvo, you use a 0 based system ( 0=self use, 1=feed in, 2= back up) but when the modes are read from the inverter, it uses a 1 based system where all write values+1.

I've confirmed this via setting "feed in" via modbus, it sticks and switches correctly, but then when the value is read by modbus, it shows "Back up", which is number 3 on the 1 based system.

MattyS wrote: ↑Wed May 13, 2026 9:20 am I've been doing some digging and some testing too, and what I've personally found is that to write to the work mode on theEvo, you use a 0 based system ( 0=self use, 1=feed in, 2= back up) but when the modes are read from the inverter, it uses a 1 based system where all write values+1.

I've confirmed this via setting "feed in" via modbus, it sticks and switches correctly, but then when the value is read by modbus, it shows "Back up", which is number 3 on the 1 based system.

Hi MattyS,

Which register are you writing to? I use 49203 which works with the 1 based system. Are you also on the same firmware versions which I posted last week? I couldn’t get the modes to work until my firmware was updated.

I am using Adam Newberry’s integration, are you using the same?

I am interested in how you are setting the forced charge and forced discharge. Can you share it with us.

Brian

BOD wrote: ↑Wed May 13, 2026 4:29 pm

MattyS wrote: ↑Wed May 13, 2026 9:20 am I've been doing some digging and some testing too, and what I've personally found is that to write to the work mode on theEvo, you use a 0 based system ( 0=self use, 1=feed in, 2= back up) but when the modes are read from the inverter, it uses a 1 based system where all write values+1.

I've confirmed this via setting "feed in" via modbus, it sticks and switches correctly, but then when the value is read by modbus, it shows "Back up", which is number 3 on the 1 based system.

Hi MattyS,

Which register are you writing to? I use 49203 which works with the 1 based system. Are you also on the same firmware versions which I posted last week? I couldn’t get the modes to work until my firmware was updated.

I am using Adam Newberry’s integration, are you using the same?

I am interested in how you are setting the forced charge and forced discharge. Can you share it with us.

Brian

I am using Adams integration with a couple of test tweaks, yes.

See, if I use the 1 based system on register 49203 for writing to my inverter, it fails and reverts to the mode it was already on. Switching to the 0 based has enabled it to work. I've added the Evo to an appropriate inverter following that pattern in the entity description file, but I'm going to test a better fix.

I haven't yet tested the force settings. It's on the list though.

MattyS wrote: ↑Wed May 13, 2026 6:16 pm
See, if I use the 1 based system on register 49203 for writing to my inverter, it fails and reverts to the mode it was already on. Switching to the 0 based has enabled it to work. I've added the Evo to an appropriate inverter following that pattern in the entity description file, but I'm going to test a better fix.

I haven't yet tested the force settings. It's on the list though.

I'm having the exact same situation with register 49203 on mine (10-5-H though not 10-8-H).
Reads are 1 indexed same as the Modbus definition (V1.05.04.00) document but writes select the wrong mode or silently fail unless I zero index them.

Did you get any success with the force settings MattyS?

Unfortunately not.

I believe there are some push requests that might solve them though by another contributor to the git. It just needs to be agreed I think. Not sure how that works

Hi,
Im also using adam newberry's integration. It really doesnt work out of the box. i can only guess that adam didnt upload all the changes he had made. its taken a lot work with claude code to fix the issues. Matty your tip regarding the registers was the final fix. The force charge and discharge parts of the integration were not mapped for the evo. claude code fixed this easily by adding the evo in for these registers. Ive asked claude code to provide a list of the other tweaks required to get this to work:
# FoxESS EVO10 / foxess_modbus_evo — Work mode writes are off-by-one: full fix including Force Charge, Force Discharge and charge period registers

---

## Background

I'm running an EVO10-H with the `foxess_modbus_evo` integration (Adam Newberry's fork). Following on from MattyS's finding about the write/read offset on register 49203 — I've confirmed this and worked out a complete set of fixes covering not just the basic work modes but also Force Charge, Force Discharge, and the registers that control grid charging. Sharing the detail so others can apply it directly or use it as a prompt for an AI assistant.

---

## Problem 1 — Work mode register 49203 write/read offset

As MattyS found: the EVO10 uses 0-based values for *writes* but 1-based values for *reads* on register 49203.

| Operation | Self Use | Feed-in First | Back-up | Peak Shaving |
|---|---|---|---|---|
| Write to inverter | 0 | 1 | 2 | 3 |
| Read back from inverter | 1 | 2 | 3 | 4 |

The integration was using the read values (1, 2, 3) for writes too, so every write landed one step off:

| HA tried to set | Inverter received | Inverter actually did | Showed in HA |
|---|---|---|---|
| Self Use | 1 | Feed-in First | Feed-in First |
| Feed-in First | 2 | Back-up | Back-up |
| Back-up | 3 | *(undefined)* | Unknown |

**Fix** — in `entities/entity_descriptions.py`, find the `ModbusWorkModeSelectDescription` for `Inv.EVO_10_H` and add a `write_options_map` with 0-based write values. Also add `0: "Self Use"` as an alias key in `options_map` to prevent a 5-second "unknown" flash caused by the controller's write-cache returning the written value (0) before the next poll confirms the read-back (1):

```python
yield ModbusWorkModeSelectDescription(
key="work_mode",
address=[ModbusAddressSpec(holding=49203, models=Inv.EVO_10_H)],
name="Work Mode",
options_map={
0: "Self Use", # write-cache alias (5s window after write)
1: "Self Use", # confirmed read-back after writing 0
2: "Feed-in First",
3: "Back-up",
4: "Peak Shaving",
},
write_options_map={
"Self Use": 0,
"Feed-in First": 1,
"Back-up": 2,
"Peak Shaving": 3,
},
)
```

Because two keys (0 and 1) now map to "Self Use", also patch `ModbusSelect.__init__` in `entities/modbus_select.py` to deduplicate the options list so the HA dropdown shows "Self Use" only once:

```python
# Replace:
self._attr_options = list(self.entity_description.options_map.values())

# With:
seen: set[str] = set()
self._attr_options = []
for v in self.entity_description.options_map.values():
if v not in seen:
seen.add(v)
self._attr_options.append(v)
```

---

## Problem 2 — Force Charge and Force Discharge use a separate remote control system

Selecting Force Charge or Force Discharge in HA does *not* just write 49203. It goes through a **remote control manager** using three separate registers:

| Register | Name | Purpose |
|---|---|---|
| 46001 | `remote_enable` | Write 1 to activate remote control, 0 to release it |
| 46002 | `timeout_set` | Watchdog in seconds — inverter reverts to fallback mode if no active-power write arrives within this time |
| 46003 / 46004 | `active_power` | Signed watts — negative = import/charge, positive = export/discharge |

When Force Charge is active, the integration writes negative active-power values every poll cycle to pull power from the grid. It also writes a **fallback work mode** to register 49203 — the mode the inverter will use if the watchdog fires. Force Charge uses **Self Use** as its fallback; Force Discharge uses **Feed-in First**.

The `work_mode_map` in `entities/remote_control_description.py` for the EVO10 block was also using wrong (1-based) write values for this fallback write. Fix it:

```python
# In the EVO_10_H RemoteControlAddressSpec:

# Wrong:
work_mode_map={
WorkMode.SELF_USE: 1,
WorkMode.FEED_IN_FIRST: 2,
WorkMode.BACK_UP: 3,
},

# Correct:
work_mode_map={
WorkMode.SELF_USE: 0,
WorkMode.FEED_IN_FIRST: 1,
WorkMode.BACK_UP: 2,
},
```

Without this fix, Force Discharge writes `2` to 49203 as its fallback, but the inverter treats `2` as Back-up. When the watchdog fires the inverter settles in Back-up rather than Feed-in First. Worse, if HA restarts while remote control is active, the in-memory `_remote_control_enabled` flag resets to False and the integration won't write 46001=0 to release remote control on the next cycle. The inverter then sits with 46001=1 permanently, ignoring all subsequent work mode writes until explicitly released.

**Recovery if already stuck** — use the `foxess_modbus_evo.write_registers` service in Developer Tools:

```yaml
# Release remote control
service: foxess_modbus_evo.write_registers
data:
inverter: FoxEvo10
start_address: 46001
values: "0"

# Set Self Use (0-based)
service: foxess_modbus_evo.write_registers
data:
inverter: FoxEvo10
start_address: 49203
values: "0"
```

---

## Problem 3 — Force Charge from grid needs charge period registers, not just work mode

This caught us out. Setting work mode to Force Charge is *necessary* but not *sufficient* for the battery to charge from the grid. The inverter also requires a **charge period** to be configured — the time window during which grid charging is permitted.

The EVO10 uses the same charge period register layout as the H1 G2:

| Register | Purpose |
|---|---|
| 41001 | Period 1 — enable charge from grid (0=off, 1=on) |
| 41002 | Period 1 — start time |
| 41003 | Period 1 — end time |
| 41004 | Period 2 — enable charge from grid |
| 41005 | Period 2 — start time |
| 41006 | Period 2 — end time |

The `foxess_modbus_evo` fork correctly maps the EVO10 to these registers (same as `Inv.H1_G2_SET`) in `entities/charge_period_descriptions.py`. If you're using Predbat, note that **Predbat only writes to the work mode selector — it does not write charge period registers**. You must configure at least one period with `enable_charge_from_grid=on` and a valid time window yourself. A permanently-wide window (e.g. 00:00–23:59) with `enable_charge_from_grid=on` is the simplest approach if you want Predbat to handle all scheduling.

---

## Min/Max SoC registers

The EVO10 uses the same SoC limit registers as the H3 Pro:

| Register | Entity | Purpose |
|---|---|---|
| 46609 | `number.foxevo10_min_soc` | Minimum SoC — battery won't discharge below this |
| 46610 | `number.foxevo10_max_soc` | Maximum SoC for remote control Force Charge |
| 46611 | `number.foxevo10_min_soc_on_grid` | Minimum SoC when on grid |

Note: if you have the FoxESS app's **Scheduler** feature enabled, it blocks external Modbus writes to register 46609 with exception 0x03 "Illegal Data Value". Disable the scheduler in the FoxESS app to restore write access.

---

## Prompt for AI assistants

> I have the `foxess_modbus_evo` Home Assistant custom integration (Adam Newberry's fork of `foxess_modbus` with EVO10 support). Three fixes are needed:
>
> **Fix 1** — `entities/entity_descriptions.py`: Find the `ModbusWorkModeSelectDescription` for `Inv.EVO_10_H` at register 49203. Add `write_options_map={"Self Use": 0, "Feed-in First": 1, "Back-up": 2, "Peak Shaving": 3}` because the EVO10 uses 0-based write values. Also update `options_map` to include both `0: "Self Use"` (write-cache alias) and `1: "Self Use"` (confirmed read-back) alongside the existing entries for 2, 3, 4.
>
> **Fix 2** — `entities/modbus_select.py`: In `ModbusSelect.__init__`, replace `self._attr_options = list(self.entity_description.options_map.values())` with a version that deduplicates the list using a `seen` set, so "Self Use" only appears once in the HA dropdown despite having two keys in `options_map`.
>
> **Fix 3** — `entities/remote_control_description.py`: Find the `RemoteControlAddressSpec` for `Inv.EVO_10_H`. Change its `work_mode_map` from `{SELF_USE: 1, FEED_IN_FIRST: 2, BACK_UP: 3}` to `{SELF_USE: 0, FEED_IN_FIRST: 1, BACK_UP: 2}`. This controls the fallback work mode written to register 49203 during Force Charge and Force Discharge remote control sessions — the wrong values cause the inverter to revert to Back-up instead of Self Use/Feed-in First when the watchdog fires, and can leave the inverter stuck ignoring all work mode writes after an HA restart.
>
> **Context on charge period registers**: The EVO10 charge period registers (41001–41006) are mapped using the H1 G2 layout in `charge_period_descriptions.py` (`models=Inv.H1_G2_SET | Inv.EVO_10_H`). Force Charge from grid requires both the work mode set to Force Charge AND at least one charge period with `enable_charge_from_grid=on` and a valid time window. The min/max SoC registers (46609, 46610, 46611) are mapped using the H3 Pro layout. If the FoxESS app Scheduler is enabled, it blocks writes to 46609 — disable it in the app first.
>
> After making all three code changes, do a full HA restart (required for custom component code changes).

Great thanks for figuring that out. Have you managed to test it at all?

Matt,
Testing still in progress only figured out the last bits yesterday. Charge and discharge worked nicely last night. Last bits to test are around car charging and battery charging at the same time which i should get sorted tonight.

Laurence