H1-6.0-E-G2 Work Mode Settings not respected

[icornish72]

I have an H1-6.0-E-G2 connecter via ModBus and data is flowing.
Manager 1.37
Master 1.22
Slave 1.02

If I set Work Mode to Force Charge, there is still no grid import - all house needs are met by the PV and a small amount of discharge (it's early!). It's like it's it Self-Use mode.
If I set work Mode to Force Discharge, I get discharge - feed Out.

If I then set work mode to Self-Use, things work as expected.

Interestingly, when I have looked in Fox 2 app, when work mode is not set to Self Use, where work mode is (top right) it says unsupported Mode.

So, my question is about Work Mode - is force charge fully supported? Or do I need to do something else?

[FozzieUK]

Just a few questions to start -

Has it ever worked on an early firmware - or is this the first time you have tried it ?

How is your MaxSoC set ?

How is your Maximum Charge Current set ?

How is your Force Charge Power set ?

When you select Force Charge, does the integration show the work mode as 'Force Charge' and does anything change on load, charge / discharge i.e. is there any kind of effect if even an undesired one ?

Have you tried it when PV is not present, is there any difference ?

[icornish72]

Just a few questions to start -

Has it ever worked on an early firmware - or is this the first time you have tried it ?
Can't say really. I've been only on this firmware, and this is the first time I've really looked at it

How is your MaxSoC set ?
100%

How is your Maximum Charge Current set ?
25A

How is your Force Charge Power set ?
6KW

When you select Force Charge, does the integration show the work mode as 'Force Charge' and does anything change on load, charge / discharge i.e. is there any kind of effect if even an undesired one ?
Yes, the work mode is set to Force Charge, and there is no other apparent change in behaviour.

Have you tried it when PV is not present, is there any difference ?
I had to wait for this one... No pv, still the same issue.

[FozzieUK]

I have just done the update, but Battery is full, so a Force Charge wont work yet... Will try later.

Great, thanks - let us know how it goes 👍

[u4h37u]

I seem to have this same issue on an H1 G2, and running the latest firmware as FozzieUK will know (Manager v1.44, Master v1.27, Slave v1.02). I did my first ever Force Charge last night using HA and it was fine, but during the day it failed, which reading the thread is due to current PV generation conflicting with some of the integration logic. I've not yet made a change to the code as suggested above:

pwr_limit_bat_up=[44012], to pwr_limit_bat_up=None

Assume this will go into a release at some point? What though is this register doing and how does it fix the issue?

[FozzieUK]

@u4h37u There's a lot of history here to explain how we got to this point, but keeping it short the original force charge/discharge modes added by Fox disabled PV generation whilst in operation, it didn't respect maxSoC and we only had gen 1 inverters.

Antony did the testing and wrote the integrations force charge/discharge simulated 'modes' using the remote control registers to take PV generation into account which needed a lot of information about what the battery was able to do in order to calculate the active power to keep PV running.

Scroll forward in time and we now have Gen 2 inverters (and KH, and H3 Pro etc...) all of which have different modbus register maps which have changed over time and we have lost access to quite a few registers, the G2 inverter (and KH) don't provide the battery power registers so the integration is unable to calculate active power correctly and it fell backup to a protected work mode 'backup' (and even that is now no longer supported on the latest gen inverters).

but in the meantime Fox have modified the Force work modes to take into account PV and on the latest versions even maxSoC so if you are on the latest firmware and set the active power to what you want to charge/discharge at, the inverter will take care of the blending to moderate the power.

The change to integration to disable the battery power register on G2 and KH inverters, allows it to work at the full power you have specified and if you have latest firmware it will balance PV generation as well.

(That's the short version)

The changes are made and tested, and i'm hearing there are quite a few G2 users waiting for this, so hopefully @canton7 will be able to do us a pre-release shortly rather than you having to modify the code directly.

[u4h37u]

Update released yesterday applied and all working for me. Force charge results in the inverter balancing battery input from PV and grid quite happily.

I noticed when switching back to Self Use that it seems to jump via Backup mode and then to Self Use, assume that's normal

[FozzieUK]

@u4h37u great, thanks for reporting back.

Yes the work mode jump is ok, the integration sets a fallback (backup) in case the force discharge mode fails, and when you change to self use, it updates the work mode and terminates the force charge but there is a poll cycle until the new work mode setting is read back which is why you see the fallback of ‘backup’

[paultweedy77]

Another H1_G2 quirk evident after Fox upgraded firmware to Manager 1.44 / Master 1.27 / Slave 1.02.

EPS Power (holding register 31012) now contains the same value as Inverter Power, even though EPS mode is not active and there’s nothing drawing from the EPS port.

31047 & 31048, the KH registers, aren't valid either (IllegalAddress response).

Spot when the firmware upgrade took hold..

Not sure whether this should be considered a bug, or Fox have changed the purpose of that register.

[paultweedy77]

Thanks @FozzieUK , did a quick EPS mode test and got these values on those registers, all of which look right according to the spec and what the load was at the time.

  "39210": 0
  "39211": 239
  "39218": 4999
  "39219": 0
  "39220": 201
  "39225": 0
  "39226": 210
  "39201": 2350
  "39204": 0
  "39205": 3100

[FozzieUK]

Thanks Paul, at least we know they are in line with the 'new' spec.
The biggest problem in making changes is that it's changed several times depending on inverter firmware version.

[paultweedy77]

Seems inevitable that the integration is going to have to accommodate different register maps for firmware versions and each inverter model. I can see how that's not straightforward though.

[canton7]

The irritating thing is that we have to give HA the list of entities before we've had a chance to talk to the inverter (unless there's some way around thay I haven't found yet). That and foxess keep moving the version register and changing its format.

[iancg]

The irritating thing is that we have to give HA the list of entities before we've had a chance to talk to the inverter (unless there's some way around thay I haven't found yet). That and foxess keep moving the version register and changing its format.

I'm surprised by this - I believe at least two of the other integrations I use talk to the end device before exposing a list of entities - although HA does complain that the integration is taking over 10s to start up. The reason I believe this is that when I change the downstream devices (outside HA), on the next HA restart, they pick up the changes and expose new entities and states.

The only one I'm vaguely familiar with the source code for has a function:

def setup_platform(hass, config, add_devices, discovery_info=None)

and that function connects to the end device (tcp in that case) before calling add_devices passing a collection of the devices to add. As far as I understand the entities and their properties are not defined until this point (some of them are dimmable and they expose brightness as an extra state in that case and ditto some support colours and gain a state for that). When I've replaced a non-dimmable with dimmable, on the next restart the new state appears on that entity.