Custom inverter — plan never shows discharge, battery sits at 100% through 37p peak slots

[SkiLtY]

Hi gcoan / team,

Spent the evening trying to figure out why Predbat refuses to plan any discharge for our setup — battery sits at 100% (or whatever the autonomous self-consumption mode leaves it at) for the entire 48h plan horizon, even through clearly expensive slots, with grid covering all load. Looking for guidance on what we're missing in our custom inverter config.

Setup

Custom inverter type EP_CUBE defined entirely in apps.yaml (no built-in support — we maintain a Home Assistant integration for the Canadian Solar EP Cube: https://github.com/SkiLtY/ha-ep-cube). Service-based dispatch via has_service_api: True.

• Predbat v8.39.5, running in Docker (nipar44/predbat_addon)
• Octopus Agile import (no export tariff yet — G99 paperwork pending)
• 20 kWh battery, 7.3 kW AC inverter (EP Cube S7)
• Solcast PV forecast working, load tracking working (Load kWh column populated)

Problem

Plan view shows battery frozen at high SoC through expensive slots:

Time	Import p	SoC %	Grid cost
Sat 18:00	35.69p	100%	+11p
Sat 18:30	37.02p (peak)	100%	+11p
Sun 18:30	37.02p (peak)	100%	+41p

Battery has 20 kWh capacity but Predbat plans to import ~50 kWh from grid over 48h while battery does nothing. Clear economic case for discharge during peaks (~12p/kWh savings vs overnight refill) but Predbat never plans one.

Asymmetric behavior is the smoking gun: Predbat correctly models PV charging the battery up (e.g., 75% → 100% via solar over morning hours), but doesn't model any autonomous discharge — SoC stays perfectly flat during load-only periods, suggesting Predbat's self-consumption simulation isn't running for this inverter type.

What we've tried

All of these in apps.yaml or via input_number entities:

• has_reserve_soc: True ✓
• set_charge_window: True ✓
• set_discharge_window: True ✓
• inverter_can_force_export: True ✓ (despite no SEG tariff, to test)
• select.predbat_mode → "Control charge & discharge"
• input_number.predbat_best_soc_keep = 1.0 (5%)
• input_number.predbat_best_soc_min = 5.0 (25%)
• input_number.predbat_metric_battery_cycle = 0
• input_number.predbat_metric_battery_value_scaling = 1.0 (default)
• Static battery_charge_power_curve / battery_discharge_power_curve (after the "near full rate" issue from discussion Warn: Cannot find battery discharge curve #3750 — confirmed warnings cleared)

All input_number metrics at defaults that should permit discharge planning. Plan still shows no discharge windows. Predbat logs are silent — no errors, no "discharge skipped because..." messages.

Relevant capability flags in apps.yaml

inverter:
  has_service_api: True
  has_target_soc: False
  target_soc_used_for_discharge: True
  has_charge_enable_time: False
  has_discharge_enable_time: False
  has_ge_inverter_mode: False
  has_fox_inverter_mode: False
  has_reserve_soc: True
  has_idle_time: True
  has_time_window: False
  support_charge_freeze: True
  support_discharge_freeze: True
  can_span_midnight: True

Question

What capability flag (or other config) tells Predbat that this inverter handles autonomous self-consumption discharge — so the plan view reflects the battery covering overnight load when PV is unavailable, instead of leaving it frozen at high SoC?

Is has_ge_inverter_mode / has_fox_inverter_mode gating the self-consumption simulation? Should I claim one of these for a non-GE/non-Fox inverter that has equivalent autonomous behavior, or is there a different flag we're missing?

Happy to share the full apps.yaml if useful — pointer: https://github.com/SkiLtY/ha-ep-cube-dev/blob/main/predbat_config/apps.yaml (private repo, but I can paste it inline if you can't view).

Thanks for any guidance — your responses on #3750 last week were already enormously helpful.

[gcoan]

There is no 'gate' control you need to set for predbat to let the battery discharge to meet house load when there's no solar. Predbat calls this Demand mode.

It sounds like the error is probably with the plan rather than the inverter execution, which usually points to an error in the configuration. In your inverter definition I don't see you have defined the inverter_name clause, which needs to match inverter_type in apps.yaml

https://springfall2008.github.io/batpred/inverter-setup/#i-want-to-add-an-unsupported-inverter-to-predbat

Try this

If not, please supply your full log file and apps.yaml, as I said its probably a misconfiguration but there should be an error in the logs to indicate this

[SkiLtY]

Thanks gcoan, really appreciate you taking the time to look at this.

Quick update: I found the root cause and it was entirely self-inflicted on my side — sharing in case it helps anyone else hitting similar symptoms.

TL;DR: my apps.yaml had inverter_limit: 7.3 (intending 7.3 kW). Predbat was reading it as 7.3 watts, which clamped battery_draw to ~0.0006 kWh per 5-min step in the ECO Mode branch (prediction.py:940). That looked exactly like "plan never models discharge" — battery sat flat through peak slots because the per-slot draw was being floored to noise.

Bisected it by instrumenting prediction.py with a debug line after the battery_draw = min(...) clamp, which immediately showed inv_lim=0.0006 as the binding constraint. Tracked it back to inverter.py:477 reading via get_arg(..., required_unit="W") / MINUTE_WATT, and predbat.py:234's unit_conversion() only firing when units is populated — which only happens for entity references (it reads unit_of_measurement from the HA entity). Literal apps.yaml values have no entity and no unit metadata, so the conversion bails at if not units: return state and the raw 7.3 gets passed through as watts.

Fix was a one-liner: inverter_limit: 7.3 → inverter_limit: 7300. Predbat now plans 6+ daily charge windows targeting cheap Agile slots, with best_metric converging to -81.85p (net profit over the 2-day horizon vs the previously projected ~75p/night cost), and the plan_html shows the expected SoC trajectory — climbing through the day on PV, then dropping cleanly as the battery covers evening load.

The trap applies to any required_unit="W" key set as a literal: inverter_limit, export_limit, inverter_limit_charge/discharge/export/override/charge_dc, battery_rate_max, inverter_battery_rate_min. Possibly worth a docs note that literal power values should always be in watts? Happy to PR something if useful.

And yes — you're spot on that I'm missing the top-level inverter_name clause too; I'll add that next session as a hygiene fix. Thanks for pointing at the unsupported-inverter doc, I'll work through it properly.

Thanks again for jumping on this so fast, especially for a custom inverter that isn't really yours to support.

[gcoan]

The trap applies to any required_unit="W" key set as a literal: inverter_limit, export_limit, inverter_limit_charge/discharge/export/override/charge_dc, battery_rate_max, inverter_battery_rate_min. Possibly worth a docs note that literal power values should always be in watts? Happy to PR something if useful.

glad you were able to work through and find the issue, especially by adding extra debug to find the issue

I just checked the docs and they do detail limits have to be in watts, but all doc updates are welcome, please do PR something to make it more explicit that the values must be in watts not kW

https://springfall2008.github.io/batpred/apps-yaml/#inverter-control-configurations