AlphaESS Modbus Integration

[jonphob]

TL;DR:

If you use inverter_type as a capability/decoy profile for an unsupported
inverter, pick one with has_discharge_enable_time: True. A profile with it set to
False (e.g. GE) makes Predbat write an internal dummy entity for
scheduled_discharge_enable instead of the entity you mapped in apps.yaml, so your
forced-export control is never actually written. Charging is unaffected, which makes it
very confusing to diagnose.

My setup (for context — this is not a natively supported config)

• Battery: AlphaESS SMILE-G3-S5 (13.68 kWh), no native Predbat support.
• Controlled locally over Modbus TCP via ⟨the AlphaESS Modbus TCP integration https://github.com/senalse/ha-alphaess-modbus.
• Predbat configured with inverter_type: "GE" purely as a decoy capability profile —
  nothing GivEnergy is connected. All of Predbat's control entities
  (scheduled_charge_enable, scheduled_discharge_enable, charge/discharge
  start/end times, rates, target SoC) are mapped in apps.yaml to helper/template
  entities (input_boolean / input_datetime / input_number, plus a template-switch
  proxy for the enables).
• A small pyscript "glue" watches those decoy entities and translates Predbat's plan
  into real AlphaESS Modbus dispatch writes.

Symptom

• Charging worked perfectly.
• Forced export never happened. Predbat computed Exp slots correctly and showed them
  in the Plan, predbat.status even went to Exporting — but
  scheduled_discharge_enable (my template switch + its input_boolean) stayed off,
  so the glue never received an export instruction. The battery never discharged to grid.

Root cause (Predbat v8.54.2)

The GE profile has has_discharge_enable_time: False (real GivEnergy inverters export
via inverter mode, not a timed discharge-enable). For such profiles Predbat creates an
internal dummy entity sensor.predbat_GE_0_scheduled_discharge_enable and writes that
for the enable, instead of the entity I mapped in apps.yaml. So my real switch — and
the input_boolean the glue watches — was never written.

Charging worked because GE has has_charge_enable_time: True → no dummy is created →
my real charge switch is written. That asymmetry was the whole mystery.

The one visible fingerprint was an easily-missed startup validation warning:
Warn: Validation of apps.yaml found configuration item 'scheduled_discharge_enable'
element sensor.predbat_GE_0_scheduled_discharge_enable returned value 'None', not a valid value

(For anyone who goes down the same rabbit hole I did: the execute.py forced-export call is
not the cause — its in-window branch passes a literal True regardless of profile. The
redirect happens at the entity-resolution/write layer, driven purely by
has_discharge_enable_time.)

Fix

Use a capability profile that satisfies the enable gate
has_discharge_enable_time and not (ge_eco_toggle or ge_inverter_mode), i.e.
has_discharge_enable_time: True, has_ge_eco_toggle: False, has_ge_inverter_mode: False.
I switched inverter_type: "GE" → "AlphaESSCloud" and forced export immediately drove
my real switch → glue → battery discharged to grid (verified, SoC dropped).

• ⚠️ GEC (GivEnergy Cloud) does not work — it has has_ge_eco_toggle: True, so the
  gate still collapses to False.
• Other profiles with the right flags (all equivalent for a decoy setup): DeyeCloud,
  SunsynkCloud, SolaxCloud. Avoid SolisCloud (has_reserve_soc: False).
• Minor differences vs GE to be aware of: soc_units changes kWh → % but is inert in
  the code (the attribute is assigned and never read; SoC units come from whether you set
  soc_kw vs soc_percent); and target_soc_used_for_discharge: True means
  charge_limit is also written during export (harmless for a decoy glue that ignores it
  while exporting).

Link to gist for the 'glue' file https://gist.github.com/jonphob/3f793178ec81ca002002f16242715db4

Suggestion (enhancement, not a bug)

When a profile overrides a user-mapped control with an internal dummy, could Predbat make
this louder than the current soft returned value 'None' warning? e.g. a one-line startup
note: "NOTE: profile GE does not use scheduled_discharge_enable; your mapped entity
switch.xxx will not be written." For the decoy-profile / unsupported-inverter crowd this
would turn a silent, week-long head-scratcher into a 10-second fix.

[gcoan]

Thanks for the information and advice for others.

Couple of comments I would make:

• don't use inverter_type's that are not the same as your inverter as you won't get the right behaviours! Generally should create a custom inverter type as described in the documentation

• if an inverter doesn't support certain capabilities (either the in built types or a custom definition) then it will create dummy entities to use for the missing features (and ignores any apps.yaml config). I'll add a further note to the documentation to highlight this.

[jonphob]

Thank you! Will take a look

[jonphob]

@gcoan

I've dropped the borrowed AlphaESSCloud profile and defined a custom inverter type as you suggested. For anyone else bridging an unsupported inverter to Predbat via decoy helper entities + a glue script, this is what worked for a local-Modbus AlphaESS — basing it on GE and only overriding the two flags needed for forced export:

inverter_type: "AlphaESS_Modbus"    # any non-built-in name -> Predbat copies GE as the base
 inverter:
   has_ge_inverter_mode: false        # let Predbat auto-create the inverter_mode decoy rather than demand a real one
   has_discharge_enable_time: true    # write the REAL scheduled_discharge_enable entity, not an auto-dummy

Basing it on GE keeps the charge side that already worked (timed charge-enable, power control, kWh SoC) and only changes what's needed for export. With this, forced export now correctly drives my real scheduled_discharge_enable switch — verified end to end, the battery actually discharges to grid — instead of Predbat writing the sensor.predbat_..._scheduled_discharge_enable dummy it created under the mismatched profile.

Your point #2 was exactly the root cause: with GE, has_discharge_enable_time is False, so Predbat created that dummy and ignored my apps.yaml mapping, silently — the only visible trace was the ... returned value 'None' validation warning.

Verification

With the custom type, I tested end-to-end (watching the real switches, real SoC, and the AlphaESS app independently):

Scenario	Result
Forced export — real switch on, battery → grid, SoC drops (incl. a 10-min run)	✅
Forced charge — real switch on, grid → battery, SoC rises	✅
Export-freeze / hold (battery held at 0 W)	✅
Power clamp — dropping the inverter AC limit to 3 kW clamped a 5 kW request to 3 kW with a warning	✅
Reload the glue mid-dispatch — reconciles device state on startup, dispatch continues	✅
Restart Predbat mid-dispatch — dispatch continues uninterrupted	✅
No dummy created for either enable; validation warning gone	✅

[gcoan]

Great to hear you have got it all working. If you'd like to create a PR to add the template and installation instructions into the predbat documentation, that'd be great for other people to benefit from

[jonphob]

Hi @gcoan just have a passive test to do, which should run over night based on current plan, once thats done will look at doing the PR

[jonphob]

@gcoan

Sorry been on holiday for 2 weeks and just got home cpl of days ago.

Whilst away i got my export tariff activated and everything has been running as expected since so all looks good.

Before i do anything what is it you are wanting me to do re PR etc. Just slightly wary as i dont want to screw anything up

[Javert1969]

Hi - just so you know at least a couple of folks have also been working on this topic of Alpha ESS integration when using local Modbus controls.

User Plainseer loaded an sample configuration here:
https://github.com/PlainSeer/predbat-alphaess-example

I have also been working to adapt this configuration to the older integration designed by Axel Koegler at Projects @ Hillview site. This older integration is what the HACS integration from Senalse. It's not clear whether that Senalse version will be supported going forward as the author has gone silent (apparently). The older integration is still being updated from time to time but it requires manual installation and has a lot of different entity names.

Anyway - if you want to see our approach generally, take a look at the Github above - not sure if you are following a similar approach or not. We are not using scheduled start/end times - we are triggering timers for each of the Predbat services based on the real time service status commands issued by Predbat.