K series unable to Force Charge/Discharge

[williamjeccles]

My setup is two KH10.5 wired in parallel (master/slave enabled) and connected to full stacks of HV2600 8* batteries per inverter.
The inverter and batteries are all on the very latest firmware using the latest version of HA and the modbus plugin.

If I set a force discharge/charge period via the Fox Cloud web UI the inverters are able to discharge/charge without issue, no fighting or flapping.

However, I can reproduce the issue if I use HA via the plugin to set the inverters into Force Charge workmode or Force Discharge workmode the inverters start flapping and fighting as per the video example.

https://youtu.be/1LQeiYCD9vs - Repro example video

I have a suspicion that the kW limit is causing the issue for systems that are parallel. Almost like its telling the systems to discharge at say 7kW total instead of per inverter.

I would like to bypass the UI limit as I believe this might be causing the inverters to flap/fight.
So I'm happy to test and rule out this suspicion if someone could point me which file and line I should comment or adjust to test out my theory.

I believe if I could set the force discharge limit to 21kW then it would allow both inverters to max out their charge/discharge amount instead of fight. It's not a perfect fix but at least it would unblock and validate my current belief.

[williamjeccles]

@canton7 we discussed this a while back but would like to reopen the topic and see if we can solve it for all parallel users.

[FozzieUK]

That's an interesting one, with parallel inverters do you set one of them to force charge/discharge and then they 'share' the output ? - as this might be a bit more complex to unravel.

Whilst we're waiting on Antony, it's a quick change to hard code the limit and test the theory, the file you are looking to change is

https://github.com/nathanmarlor/foxess_modbus/blob/main/custom_components/foxess_modbus/inverter_profiles.py

I think a change in line 77 is all that is needed to test with i.e.

Change

            capacity = int(float(capacity_str) * 1000)

To this

            capacity = int(21000)

[williamjeccles]

That's an interesting one, with parallel inverters do you set one of them to force charge/discharge and then they 'share' the output ? - as this might be a bit more complex to unravel.

Whilst we're waiting on Antony, it's a quick change to hard code the limit and test the theory, the file you are looking to change is

https://github.com/nathanmarlor/foxess_modbus/blob/main/custom_components/foxess_modbus/inverter_profiles.py

I think a change in line 77 is all that is needed to test with i.e.

Change

            capacity = int(float(capacity_str) * 1000)

To this

            capacity = int(21000)

Thank you! Testing shortly once the free octopus power hour is over.

[canton7]

We have some inverters (IIRC it was the KH) which do entirely the wrong thing if you tell them to import / export more than their capacity. That's why we detect the capacity of the inverter, and we limit the import/export rate to that power. See #518 (comment) and posts around it.

[canton7]

It's entirely possibly that foxess cloud uses a different mechanism for doing force export than we have access to over modbus (which is limited to the remote control registers), and remote control doesn't work properly with master/slave setups.

[williamjeccles]

Yeh I think it's just broken, the limit increase didn't resolve it from what I can see. Anything you'd like to help troubleshoot or implement just let me know.

[FozzieUK]

I've been doing some testing on my H1 to see if the schedules uses a similar method to control the inverter, and if so are there any differences.

For now i've only tested force discharge as that is the one of interest, it would appear both use the remote control registers albeit with some differences.

I know Antony knows this, but i'll write down what my testing has shown for the integration and for the scheduler and highlight any differences as i've learned a few things from the scheduler.

Force Discharge - Integration first.

The integration uses the remote control registers, specifically -

Remote Enable (44000) - master enable switch
Timeout (44001) - when this timeout expires it will terminate the action
Active Power (44002) - AC output power in watts (covers load first, remainder export)

Remote Enable is used as a master switch to enable the action
Timeout is set to poll speed * 2 - I assume so that if a poll is missed the next poll will set it prior to timeout.
Active Power is set to a positive value in watts for Force Discharge (Charge is negative signed)

When the force discharge mode is set the integration sets the timeout value to (poll *2), then remote enable to 1, then active power to x watts

The integration continually resets the timeout value every poll whilst in force discharge

When the work mode is changed, the integration sets remote enable to 0 and the force discharge ends.

Force Discharge - Scheduler.

The scheduler appears to use the remote registers but it does so in a different way

It manipulates the same 3 registers plus one other

Remote Enable (44000) - master enable
Timeout (44001) - when this timeout expires it will terminate the action
Active Power (44002) - AC output power in watts (covers load first, remainder export)
Remote Take Effect (44005) - if set zero no action will take place, when set to 1 timeout countdown starts

The scheduler sets Timeout to be the number of seconds that the action will run for i.e. 1 hour = 3,600
The scheduler sets Remote Enable to 1 to enable remote control (Remote Take effect is zero until the schedule is ready to run)
At the scheduled time it sets Active Power to a positive value in watts for Force Discharge which sets Remote Take effect to 1 - this starts the force discharge.

No further writes take place and the timeout counts downs to zero at which point it will terminate. This sets Remote Take effect to 0, which in turn sets Remote Not Active Reason (44006) to 2 ('host off line') but leaves all of the other values set

If the schedule is disabled Remote Take effect is set to zero the force discharge is terminated - all other registers stay as they were set, Remote not Active Reason shows the reason code.

Differences?

The integration sets timeout value every poll, whereas the scheduler sets it to the duration the action will run for.

The integration sets Remote Enable to turn on remote control, the scheduler sets it the first time it runs and leaves it set.

The integration/scheduler sets Active Power and as a result the inverter internally sets Remote Take Effect.

Once Remote Take effect is set the force discharge countdown will begin.

If a schedule is terminated early the Remote Take effect register is set to 0 (other registers stay as they were), the Remote not Active Reason is set to 1 ('enable set').

The integration writes the Timeout register every poll cycle, the scheduler does not change any of the registers once they have been set.

Problems

As I recall there may be a problem with reading the Remote Take effect register as the KH did not expose registers above 44003 - it would be useful to know if this is still the case and needs to be re-checked on a KH

44004 is Timeout Countdown - this counts down each second, and at zero will terminate action with result in Remote no active Reason
44005 is Remote take effect - zero no action, set to 1 action starts countdown
Note: This is a read only register, yet watching the scheduler it sets this to zero when a schedule is terminated - I cannot find how it is doing that as it leaves Remote Enable set
44006 is Remote not Active Reason - the reason why it's not running.

This command will try and read the 7 holding registers in one read

modpoll.exe -m tcp -p 502 -a 247 -t 3 -0 -1 -c 7 -r 44000 192.168.x.x

failing that try them as single reads

modpoll.exe -m tcp -p 502 -a 247 -t 3 -0 -1 -c 1 -r 44004 192.168.x.x
modpoll.exe -m tcp -p 502 -a 247 -t 3 -0 -1 -c 1 -r 44005 192.168.x.x
modpoll.exe -m tcp -p 502 -a 247 -t 3 -0 -1 -c 1 -r 44006 192.168.x.x

I'm not sure yet whether not being able to read them will a problem as these values seem to triggered by other actions - so useful when testing.

Parallel running ?

The parallel operation is likely managed as a higher function to the remote control, i.e. the scheduler simply asks for force discharge at x power for x seconds and the inverters work this out between them.

This is just a hypothesis but it is possible the action of repeatedly writing to the Timeout register is upsetting the higher management function which is why they are 'fighting' (approx every poll cycle)

If this is the case, the KH(s) may balance the force discharge correctly if the registers are set in the same way as the scheduler i.e. set timeout to number of seconds, but do not repeatedly write to the timeout register.

@williamjeccles the foxess integration can't set them this way as it has no concept of start and end times (yet), but the theory can be tested as an automation using the integrations modbus write register function.

Add the following 3 actions like this -

With these registers and values, in this order -

44001 set to 60 ' give it 60 seconds of force discharge
44000 set to 1 ' enable it
44002 set to 1000 ' 1000 watts discharge power - the active power setting automatically sets remote take effect

This will run a force discharge at 1000 watts for 60 seconds after which the timeout will expire terminating the action.

If it performs without fighting, clearly this mechanism works - if not, then that's a much bigger problem.

[FozzieUK]

I've just tested remote control to Force Charge and setting a fixed power - it charged my batteries and kept solar enabled with spare being used to export.

So it looks like when Fox fixed the bug where force charge disabled solar power - it 'may' have been a bug in the way remote control worked (now resolved) and much of the complexity that had to be added to modulate the power limit to keep solar on, appears not to be required on the latest firmware versions - you just set a fixed negative power and the inverter does the rest.

[williamjeccles]

Sorry for the delay @FozzieUK, just seen this. working through your last detailed reply and will update you.

[williamjeccles]

Hey @FozzieUK / @canton7 Good news! writing directly to the registers as you showed in your screenshot worked!
I now have both inverters discharging without fighting. Amazing! I hope confirming this will enable better compatibility with the features in a future release for parallel owners. Maybe a flag during setup for is this a parallel connected system so features and code paths are separated from those single inverter users? For now I'll just use an automation that writes to the registers directly. I've also tested it with a negative figure for force charging and it works well also without fighting.

[FozzieUK]

That's brilliant, i'd hoped as much but couldn't test it on a single inverter 👍

[williamjeccles]

Updated title as it appears to be solo and parallel k series systems that aren't working with the force charge/discharge implementation. Works great if using automation to write to the registers as shown above.

[canton7]

Just catching up...

Note that "Remote take effect" is read-only. We can't write it from the integration. It's just a status register, saying what the remote control system is doing. The timeout is started (and reset) by writing a power. Re-reading your analysis with that in mind, I'm comfortable that the integration and the scheduler are doing the same thing (except that the scheduler writes a single power with a long time-out, and the integration continuously updates the power, with a short time-out).

So it does sound like it's specifically the logic which the integration adds to avoid the PV clipping which is causing you problems. While I'd love to just rip all of that out, I'm slightly wary of breaking people who currently rely on it... I guess I could make it an advanced setting, but I'm unsure on whether to enable or disable it by default...

[FozzieUK]

@williamjeccles i'm pretty sure the K series (single) works ok with force charge, I've written an automation for someone recently with a KH9 that uses the integrations Force Charge mode and the automation throttles the battery charge current when it hits maxSoC - I think the confusion for the post on Facebook might well be that fact that schedules and integration Force Charge/Discharge do not play well together. I'll try and get some confirmation around that.

@canton7 yes I think this might be a tough one, it would be an interesting test to strip out all of the PV clipping logic to see if it would work but I suspect what the KH in parallel mode is actually looking for is when you enable force charge the integration would make a single set of writes to enable i.e. set active power, set a duration and set remote enable on - and then do nothing until either the duration expires, or you disable 'force charge'.

Interestingly whilst 'remote take effect' is read only to us over modbus, the scheduler somehow manages to uniquely access this - if you disable a schedule whilst it is running, it leaves 'remote enable' and 'active power' set ass they were, the timeout stops counting - but only because 'remote take effect' has gone zero - a nice party trick.

[canton7]

I strongly doubt that setting the power multiple times to the same value is what's confusing it. I rather suspect there's some weirdness with the feedback from the inverter which we use to set the remote control power. Some debug logs (which I don't think we've had yet, despite how long this has been open!) would help clarify!

[FozzieUK]

As the KH battery power limit register doesn't exist, when in force charge work mode, I believe the remote control manager is only ever writing max_import_power, it's not able to calculate it as a variable - it will be the same value written to active power each cycle (which resets the timeout).

[Chip2786]

With these registers and values, in this order -

44001 set to 60 ' give it 60 seconds of force discharge 44000 set to 1 ' enable it 44002 set to 1000 ' 1000 watts discharge power - the active power setting automatically sets remote take effect

This will run a force discharge at 1000 watts for 60 seconds after which the timeout will expire terminating the action.

If it performs without fighting, clearly this mechanism works - if not, then that's a much bigger problem.

This ^ saved my life, my force charge/discharge stopped working weeks ago, using this I created my own "macro" to charge/ discharge to/ from grid. Thank you!

(Fox H1-5.0-E-G2)

[canton7]

As the KH battery power limit register doesn't exist, when in force charge work mode, I believe the remote control manager is only ever writing max_import_power, it's not able to calculate it as a variable - it will be the same value written to active power each cycle (which resets the timeout).

Ah yes, fair enough.

@williamjeccles Can you try changing this line:

        self._remote_control_manager = (
-            RemoteControlManager(self, remote_control_config, poll_rate) if remote_control_config is not None else None
+            RemoteControlManager(self, remote_control_config, 60) if remote_control_config is not None else None
        )

See if that makes it behave any better? It might only go weird once a minute, or it might be able to handle it? Would be interesting to see.

I'm reluctant to have a timeout which is too long if we cna avoid it, as it means that your inverter will be stuck in force charge / force discharge if HA fails.

[williamjeccles]

For those following with a KH and wanting to update the addresses directly via modbus use something like this as an automation:

actions:

• parallel:

  • action: foxess_modbus.write_registers
    metadata: {}
    data:
    start_address: 44001
    values: "3600" how many seconds to run for
    inverter: YOUR INVERTER ID IN HA

  • action: foxess_modbus.write_registers
    metadata: {}
    data:
    inverter: YOUR INVERTER ID IN HA
    values: "5000" how many watts to discharge positive figure or charge negative figure
    start_address: 44002

  • action: foxess_modbus.write_registers
    metadata: {}
    data:
    start_address: 44000
    values: "1" enables the above to work like an on off switch I think
    inverter: YOUR INVERTER ID IN HA

[WyndStryke]

Just noticed in the modbus protocol document (20240516, v1.05) that it lists 46000-46020 as the remote control registers, and doesn't mention the 44000 range.

On my KH >1.33, 44000-44002 seems to contain identical data to 46001-46003. I have to assume that means that they intend to depreciate 44000 in the future?

I see in the code that the H3 Pro is already looking at 46xxx.

With a 60s timeout, would register writes be a concern? I note that Trevor has mentioned register writes quite a bit recently (albeit in the context of GivEnergy).