Sigenergy: Freeze Charging template still forces grid-import at full price (discharge cutoff=100 in Maximum Self Consumption) — related to #2872

[a-teece]

Summary

The published Sigenergy "mode-bridge" automation template (https://springfall2008.github.io/batpred/inverter-setup/) sets, for Freeze Charging:

• number.sigen_plant_ess_charge_cut_off_state_of_charge → 100
• number.sigen_plant_ess_discharge_cut_off_state_of_charge → 100
• number.sigen_plant_grid_import_limitation → 0

On a real system (inverter mode Maximum Self Consumption, Predbat v8.46.9), this caused the battery to actively force-import from the grid at full peak price to chase the 100% discharge-cutoff floor, instead of just holding SoC in place as "Freeze Charging" implies. This happened twice in one evening, the second time for ~45 minutes at ~8-9kW import while the export rate was still one of the best of the day — a real, quantifiable financial loss, not a cosmetic bug.

Reproduction / evidence

• input_select.predbat_requested_mode transitioned Demand → Freeze Charging (confirmed via automation_trace).
• Within ~5s, discharge_cut_off_state_of_charge was set to 100 and predbat.status showed Hold for car.
• sensor.<plant>_battery_power flipped from ‑8.0kW (discharging/exporting) to +8.0kW (charging) within 10 seconds of that write, and grid power flipped from ‑7.0kW (exporting) to +9.0kW (importing) — and held there continuously for the duration of the Freeze Charging state.
• Add-on log: repeating Completed run status Hold for car / record_status Hold for car entries, one per ~5 min planning cycle, for the full duration.
• Reverting only discharge_cut_off_state_of_charge (leaving everything else alone) immediately dropped the battery back to idle (‑0.004kW) — confirming the 100% discharge floor alone is sufficient to cause forced grid-charging in Maximum Self Consumption mode, independent of any import-limit setting.

Relation to #2872

This is a related but distinct symptom to #2872 ("Freeze Charge not working as expected - Sigenergy"). That issue found Maximum Self Consumption mode doesn't properly action ess_max_discharging_limit (a kW cap) — the inverter needs to be in a Command Charging/Discharging state for that write to take effect. Our system shows the opposite problem: the SoC cutoff register is honored in Maximum Self Consumption mode, and setting it to a hardcoded 100% (above current SoC) actively drives the inverter to import from the grid to reach it. #2872 was closed, but the published docs template still contains this exact pattern — the discussed workaround (switching EMS mode to Command Discharging (PV First) for Freeze Charging, and using the kW limit instead of the SoC cutoff) never made it into the docs page.

Suggested fix

Rather than switching EMS modes (which has its own state-machine caveats per #2872, and appears to need extra config enabled on the Sigenergy integration side), we fixed this by keeping Maximum Self Consumption mode and pinning both cutoffs to the battery's current SoC instead of a hardcoded extreme:

# Freeze Charging: hold current SoC as the charge ceiling, normal discharge floor
- conditions: [{condition: state, entity_id: input_select.predbat_requested_mode, state: "Freeze Charging"}]
  sequence:
    - action: number.set_value
      data_template:
        entity_id: number.sigen_plant_ess_charge_cut_off_state_of_charge
        value: "{{ states('sensor.sigen_plant_battery_state_of_charge') | float(0) }}"
    - action: number.set_value
      data_template: {entity_id: number.sigen_plant_ess_discharge_cut_off_state_of_charge, value: 0}

# Freeze Discharging: hold current SoC as the discharge floor, normal charge ceiling
- conditions: [{condition: state, entity_id: input_select.predbat_requested_mode, state: "Freeze Discharging"}]
  sequence:
    - action: number.set_value
      data_template: {entity_id: number.sigen_plant_ess_charge_cut_off_state_of_charge, value: 100}
    - action: number.set_value
      data_template:
        entity_id: number.sigen_plant_ess_discharge_cut_off_state_of_charge
        value: "{{ states('sensor.sigen_plant_battery_state_of_charge') | float(100) }}"

This directly implements "freeze at current level" semantics with a one-line template change per branch, no EMS mode switching required, and has been running live for several hours without recurrence of the forced-import behaviour. We think it may be a simpler and more robust fix than the #2872 workaround, but haven't tested that alternative ourselves — flagging both here for the maintainer to weigh in on which (or both) should go into the published template.

Also worth checking

The published template also sets number.sigen_plant_grid_import_limitation. That entity does not exist at all in our Sigenergy integration (confirmed via HA entity registry search and direct state lookup — 404). Our real number.sigen_plant_ess_* entities are only: ess_backup_state_of_charge, ess_charge_cut_off_state_of_charge, ess_discharge_cut_off_state_of_charge, ess_max_charging_limit, ess_max_discharging_limit. Not sure if this is integration-version drift, a naming difference (grid_export_limitation vs grid_import_limitation — #2872 uses the former), or an optional entity that needs enabling — but as written those number.set_value calls are silent no-ops for us, which could mask real problems for anyone else copying the template.

Environment

• Predbat: v8.46.9
• Inverter: Sigenergy SigenStor (sigen integration)
• EMS mode used throughout: Maximum Self Consumption

[a-teece]

Follow-up on the grid_import_limitation entity note above — checked the integration source directly (TypQxQ/Sigenergy-Local-Modbus, commit 98b5252):

• custom_components/sigen/number.py#L189-L204 — the entity's real key is plant_grid_maximum_import_limitation (→ number.sigen_plant_grid_maximum_import_limitation), i.e. it has "maximum" in it. Predbat's docs/template reference number.sigen_plant_grid_import_limitation, missing that word — so the entity_id in the template is simply wrong, independent of anything else.
• Same file, entity_registry_enabled_default=False is set on that definition — so even with the correct id, it won't appear for anyone until they manually enable it (Settings → Devices & Services → entity → Enable). That lines up with the earlier comment on Freeze Charge not working as expected - Sigenergy #2872 about needing to "enable some things on the config side of the sig integration."
• The export counterpart has the same shape: #L173-L188, key plant_grid_point_maximum_export_limitation, also disabled by default. There are also plant-level PCS import/export limitation entities a bit further down the same file with the identical pattern (plant_pcs_maximum_export_limitation / plant_pcs_maximum_import_limitation).

So: not a missing feature, just a wrong entity_id in the docs template plus an opt-in entity that isn't called out as needing enabling. Our proposed fix above doesn't depend on this entity at all (that's incidental — we removed the need for it rather than fixing its name), but if the docs template keeps using it, it should reference the correct id and mention enabling it first.

[chalfontchubby]

(Posting as Claude, an AI assistant helping investigate this, working with @chalfontchubby)

Thanks for the detailed writeup and the follow-up on grid_import_limitation - really useful diagnostic work. One correction on that follow-up though, checked directly against the same integration (TypQxQ/Sigenergy-Local-Modbus, confirmed on a live v1.2.5 install):

number.py distinguishes the internal Modbus/coordinator lookup key from the entity's actual name:

SigenergyNumberEntityDescription(
    key="plant_grid_maximum_import_limitation",
    name="Grid Import Limitation",
    ...

Home Assistant generates the entity_id from name, not key - so number.sigen_plant_grid_import_limitation (no "maximum") is correct, not a typo. Confirmed live: it exists, is enabled, and is a real writable entity - so it isn't a silent no-op, and the docs template's entity_id doesn't need changing.

That actually raises a more interesting question rather than closing the loop, though: if grid_import_limitation genuinely was being set to 0 during your incident and the inverter was actually honouring it, a real 0kW cap should have made forced grid-import physically impossible regardless of what the SoC cutoffs were doing - which would mean the "hold at current SoC" rewiring you proposed for the cutoffs shouldn't have been necessary to fix the symptom you saw. Since forced import happened anyway, it'd be worth checking (if you still have the trace/history) whether grid_import_limitation actually read 0 at the moment the 8-9kW import was occurring, or whether the write wasn't taking effect / wasn't holding for some other reason. If it really was 0 and the inverter imported anyway, that points at the inverter not respecting that limit under these conditions in Maximum Self Consumption mode - a different and more concerning finding than a docs bug.

The core forced-import behaviour you found (100/100 SoC cutoffs) is still a real, well-evidenced issue independent of this - we're planning to test some variations on real Sigenergy hardware before settling on what goes into the published template, since your proposed fix changes Freeze Charging's discharge floor from "prohibited" (matching the docs' own stated intent) to fully unrestricted, which we'd like to avoid if a fix that preserves that intent is possible.

[chalfontchubby]

Quick update — @chalfontchubby has been testing this directly on their own Sigenergy hardware (same integration, TypQxQ/Sigenergy-Local-Modbus v1.2.5).

Findings so far, confirmed via live triggered tests, not just log inspection:

• With discharge_cut_off_state_of_charge set above current SoC (e.g. SoC at 41%, cutoff set to 43%), the inverter actively imports from grid to close that gap, then stops exactly at the threshold and reverts to normal solar-only charging. So the mechanism is specifically "discharge cutoff above current SoC" acting as an active charge target, not just a discharge cap.
• With charge_cut_off_state_of_charge left at 100 the whole time (unchanged), forced import still stopped precisely at the discharge-cutoff threshold — so the charge-side cutoff being 100 does not itself appear to cause forced import. The original "100/100" repro was a correlation, not the actual trigger.

Working fix being tested now: pin discharge_cut_off_state_of_charge to current SoC dynamically (via a template reading the battery SoC sensor) instead of a hardcoded value, leaving charge_cut_off_state_of_charge at 100 unchanged. This should close the gap the inverter was chasing while still satisfying "discharge prohibited" during Freeze Charging.

This is live on their system now for real-world testing (not just a one-off manual trigger). Will report back once it's held up over a few real Freeze Charging cycles, then update the docs template accordingly.