Sigenergy: Hold for car can block free grid import and cause EV to consume exportable solar

[liambresnahan]

I’m looking for some input on what the intended behaviour should be here, as I think I’ve hit an interaction between car_charging_from_battery: false, Hold for car, and the Sigenergy Freeze Charging implementation.

Setup

I’m using the non-cloud Sigenergy integration:

Predbat → Home Assistant helpers/services → Sigenergy Local Modbus → Remote EMS

Relevant settings:

• car_charging_from_battery: false
• Predbat controls EV charging slots
• Sigenergy EVDC
• fixed export rate: 12p/kWh
• a recent Octopus free electricity event: 0p/kWh import from 11:00–12:00
• battery was allowed to charge to 100% during the free period

The standard Sigenergy mode mapping is being used, including charge_freeze_service → Freeze Charging.

What happened

Predbat correctly recognised the free period and scheduled the EV into it.

At 11:40 the log showed:

Car 0 plan charging from 52.5kWh to 80.0% (60.0kWh)
Car 0 charging plan is:
[
  {'start': 700, 'end': 720, 'kwh': 4.167, 'average': 0.0, 'cost': 0.0, ...},
  ...
]

So the planning side looked correct.

Earlier in the hour the house was importing from grid and both the EV and stationary battery were charging.

At around 11:30 the stationary battery reached 100%. Predbat then logged:

Car charging from battery is off, next slot for car 0 is 09-06 11:30:00 - 09-06 12:00:00
Disabling battery discharge whilst car 0 is charging
Inverter 0 setting charging SoC to 100% as per target
...
Calling service charge_freeze_service ... option: 'Freeze Charging'

From that point until 12:00, grid import fell to almost zero and the EV effectively followed available solar generation.

The battery stayed full / held, which is expected, but the EV consumed PV that could otherwise have been exported at 12p/kWh.

Why this seems economically wrong

During this specific period:

• grid import = 0p/kWh
• export = 12p/kWh

So the economically preferable behaviour is:

• EV charges from free grid power
• stationary battery remains held / does not discharge into the EV
• surplus PV is exported at 12p/kWh

Instead, once Hold for car resulted in Freeze Charging, the Sigenergy grid_import_limitation = 0 behaviour appears to have prevented the site importing for the EV.

The result is effectively a ~12p/kWh opportunity cost on solar diverted into the car.

The semantic issue

As I understand the current behaviour, two different intents end up using the same Sigenergy action:

1. Freeze Charging
   • hold battery SoC
   • suppress grid import
2. Hold for car
   • prevent the home battery discharging into the EV

Those are not always equivalent.

For Hold for car, particularly during a cheap/free import slot, I want:

• battery discharge prevented
• grid import still allowed
• EV free to consume grid power
• PV free to export

Whereas for a genuine Freeze Charging state, the current zero-grid-import behaviour may still be exactly what is wanted.

Questions

I’d appreciate views on the intended design here:

• Is Hold for car deliberately expected to reuse charge_freeze_service?
• On Sigenergy, is the resulting grid_import_limitation = 0 during an EV hold considered expected behaviour?
• Should Predbat expose a separate service/state for Hold for car, so inverter integrations can distinguish it from generic Freeze Charging?
• Or is there already a supported state/entity that can be used in Home Assistant to distinguish Freeze charging from Hold for car reliably?

I could work around this locally by detecting an active Predbat EV slot and using the normal grid import limit instead of 0 kW when Freeze Charging is requested, but I’d rather understand the intended upstream behaviour before adding a Sigenergy-specific exception.

Happy to provide the relevant Predbat log and HA power history if useful.

[gcoan]

Is Hold for car deliberately expected to reuse charge_freeze_service?
On Sigenergy, is the resulting grid_import_limitation = 0 during an EV hold considered expected behaviour?
Should Predbat expose a separate service/state for Hold for car, so inverter integrations can distinguish it from generic Freeze Charging?
Or is there already a supported state/entity that can be used in Home Assistant to distinguish Freeze charging from Hold for car reliably?

I'll give you my perspective on your questions.

Yes I believe Predbat treats hold for car and freeze charge as the same thing, in both cases it wants to stop the battery discharging but will allow it to charge from excess PV.

There isn't a separate hold for car service/state. That wouldn't be a trivial introduction that could require lots of other Predbat users to change their apps.yaml to use the new service in order to keep running.

As for how freeze charge is implemented on SigEnergy, I can't really comment, needs input from other Sig users.

If you want to detect what predbat is doing and add extra processing, predbat.status could be a good place to start