Force Export vs force discharge

[Javert1969]

Just checking but I see you are using force_export for the discharge service of Predbat.

I am not sure if the HACS integration works the same, but in the one I am using, force_export continuously adds the house load to the dicharge rate whereas force_discharge just discharges the battery at a constant rate (so your discharge rate will be continuously altered to keep the export rate constant).

Did you confirm that force_export is the correct one to use to match with how predbat will do the planning?

[PlainSeer]

Good spot — I’ve gone back and checked this properly rather than relying on the fact that it was successfully exporting.

You are right about the distinction. PredBat describes its discharge rate as the battery discharge rate in watts. AlphaESS Force Export, on the other hand, treats the value as the required grid export and continually adjusts the battery output to compensate for the current house load and solar generation.

I checked a recent export on my own system as well. PredBat was requesting 8,000 W, but the battery output settled at around 7.3 kW while the grid export remained at roughly 7 kW, which confirms that Force Export was compensating for the load and PV rather than applying PredBat’s requested value directly to the battery.

So the existing configuration does work in the sense that it exports and follows the planned target SoC, but it doesn’t match PredBat’s power model as closely as Force Discharging should.

I don’t want to simply change the example without testing the full sequence, particularly the target SoC, duration, stop and replanning behaviour. I’m going to test the Force Discharging route properly and, assuming that behaves as expected, update the example.

Thanks for spotting this — it’s a useful catch.

[PlainSeer]

Thanks again for raising this — I’ve now tested the Force Discharging route on the live system and you were right.

With PredBat requesting 8,000 W, Force Discharging made the battery output follow that battery-side request, while the resulting grid export varied according to the house load and PV. That matches PredBat’s discharge-rate model much more closely than Force Export, which was treating the requested value as the grid-export target and compensating for the load.

I’ve therefore updated the example to use AlphaESS Force Discharging for discharge_start_service. PredBat’s {target_soc} is now written directly to the Force Discharging stop-at-SOC control, with no added percentage offset. So, for example, a PredBat export shown as 55% to 45% sets the inverter’s stop target to 45%.

The Home Assistant rate bridge has also been changed to write to Force Discharging Power and to resend the requested rate when Force Discharging starts. The old Force Export SOC script and resync automation are no longer required and have been removed from the examples.

The short live test completed successfully and everything returned to normal afterwards. PredBat also reloaded the updated configuration cleanly.

Really useful catch — thank you.

[Javert1969]

OK - I will have to read through this again tomorrow - I think we are right about the Predbat planning, but for me this might also create an interesting situation. Forced discharge Modbus mode with Alpha ESS doesn’t respect the DNO export limit, so if Predbat requests a forced discharge at 4KW, but significant solar is still being generated at that time, I will technically breach the export limit. In the real world this doesn’t matter much unless the voltage gets too high. I have separate automations running that will reset the inverter if the voltage goes above 252v, and even after that the installer set voltage cutouts will trigger, but even if this works it might create an opposite planning issue where Predbat assumes that my inverter is blocking export above 4KW when actually it’s not.

For you this isn’t an issue if your export limit is the same as your inverter size as you won’t be able to export higher anyway.

Since Predbat is only in the end guessing what your house load is during each 30 minute period and will presumably update the plan accordingly and regularly, maybe it doesn’t matter that much which mode is used.

This is why I actually like the forced export option in the integration but as I raised, it doesn’t seem to be consistent with Predbat planning process.

[PlainSeer]

Yes, that’s a very fair point, and I think the distinction is now clearer.

Force Discharging matches PredBat’s battery-power model, but it does not dynamically enforce a grid-export ceiling. If the battery is discharging at 4 kW and there is also significant solar after the house load has been covered, the combined grid export could exceed a lower DNO limit.

PredBat’s export_limit setting models that limit when producing the plan, but it does not itself enforce the limit at the inverter. Likewise, inverter_limit_export can cap the requested battery discharge power, but it cannot dynamically account for changing solar and house load.

That means Force Discharging is the closest match to PredBat’s planning model, but Force Export may still be the safer practical option on a system where the permitted grid-export limit is below the possible combined battery and solar output, because AlphaESS then regulates the actual grid export.

I think the example should make that trade-off explicit rather than presenting Force Discharging as universally correct. For systems with a restrictive DNO limit, Force Discharging would need either a separate export-limiting control or a suitably conservative battery-discharge cap.

There was also a second issue during my testing: the raw {target_soc} supplied to the service was not always the final SoC displayed by PredBat. I have corrected the example so the inverter now receives the final displayed endpoint exactly — for example, 65%-58% sets 58%. I confirmed that with a short live test.

Thanks again — this is exactly the sort of inverter-specific behaviour that is useful to document properly.