Persistent "No entity_id for inverter_mode to write Eco" warning despite has_ge_inverter_mode: False on custom inverter, and forced discharge not applied to hardware

[jorgjansen1977-spec]

Predbat version

v8.46.4 (Predbat app / add-on installation on Home Assistant OS)

Setup

Custom inverter integration for a Pylontech Force H3X (12kW/30.72kWh), controlled via a custom Home Assistant bridge automation using input_boolean helpers mapped to charge_start_service / discharge_start_service / freeze services (following the Fronius-style bridge pattern from the docs). The inverter is not natively supported by Predbat.

Problem 1: Persistent inverter_mode warning

Since installation, Predbat continuously logs:

Warn: Inverter 0 write_and_poll_option: No entity_id for inverter_mode to write Eco

This warning persisted even before I had defined a custom inverter_type/inverter: block (at which point I assumed it defaulted to GivEnergy-style behaviour). After discovering in the docs that omitting inverter_type causes Predbat to assume a GivEnergy inverter (with a 2600W limit), I added a full custom inverter definition:

yaml
inverter_type: H3X
inverter:
name: "Pylontech Force H3X"
has_rest_api: False
has_mqtt_api: False
has_service_api: True
output_charge_control: "power"
charge_control_immediate: False
current_dp: 1
charge_discharge_with_rate: False
has_charge_enable_time: False
has_discharge_enable_time: False
has_target_soc: False
target_soc_used_for_discharge: True
has_reserve_soc: True
has_timed_pause: False
time_button_press: False
support_charge_freeze: True
support_discharge_freeze: True
has_ge_inverter_mode: False
has_fox_inverter_mode: False
has_idle_time: False
has_time_window: False
charge_time_format: "S"
charge_time_entity_is_option: False
can_span_midnight: False
clock_time_format: "%Y-%m-%d %H:%M:%S"
num_load_entities: 1
soc_units: "%"
write_and_poll_sleep: 2

Confirmed via the "Apps" tab in the web console that this was loaded correctly (inverter_type: H3X, has_ge_inverter_mode: False, apps.yaml reports 0 errors).

The warning persists identically after this change. Since has_ge_inverter_mode is explicitly False, I would expect Predbat to never attempt writing a GE-style "Eco" inverter_mode value. This suggests either:

another code path unconditionally attempts an inverter_mode write regardless of has_ge_inverter_mode, or
a config key/precedence issue causes the custom inverter block to not fully override default GE-style behaviour for this specific control path.
Problem 2: Plan shows forced export ("Exp") but hardware does not receive discharge command

Separately (possibly related, possibly not), I observed a case where the Predbat plan table showed a continuous "Exp↘" (forced export) state for a ~4 hour evening window (all quarter-hours marked Exp, Limit% decreasing steadily ~2-3%/15min). At a point within that window, I checked live entity states:

input_boolean.predbat_discharge_start = off
The bridge-controlled hardware register (number.pylontech_force_h3x_charge_discharge_power_ref) = -11% (a charging value, not discharge, per our sign convention)

So despite the plan indicating active forced export, discharge_start_service did not appear to have been triggered at that time, and the battery was not discharging at anywhere near the expected rate for a 10.8kW-capable system.

The ~2-3%/15min SoC decline observed in this window corresponds almost exactly to what a 2600W GivEnergy-default discharge rate would produce (rather than our real 10,800W battery_rate_max), which is consistent with Problem 1's default-inverter-type theory, though I have not yet re-tested this specific scenario after adding the inverter_type: H3X block.

Request
Is there a known cause for the inverter_mode/"Eco" write attempt persisting despite has_ge_inverter_mode: False? Is there an additional flag or precedence rule I'm missing?
Does has_service_api: True fully guarantee that discharge_start_service is called whenever the plan enters a forced-export slot, or are there additional conditions (e.g. switch.predbat_calculate_export_first, or discharge rate curve requirements) that could silently prevent the service call?

Happy to provide the full apps.yaml, log excerpts, or test further with debug logging enabled.

[jorgjansen1977-spec]

For context: this exact hardware (without the PV/solar section) is also sold in the Netherlands by energy supplier Zonneplan under the name "Nexus", where it is marketed with full imbalance-market trading control. This confirms the underlying hardware is capable of fast, precise, market-driven charge/discharge control — Zonneplan's control almost certainly bypasses the three consumer-facing EMS modes (User/Self-Consumption/Feed-in-priority) that we're limited to via the standard Home Assistant integration, likely through direct Modbus register access or a proprietary API.

I don't have visibility into Zonneplan's exact control method, so I can't confirm the specific register(s) involved — just flagging this as evidence that finer-grained control of this inverter family is technically possible, in case it's useful context for whether a deeper Modbus-based integration approach (similar to other directly-supported brands) would be more appropriate than the current select/EMS-mode-based approach.

[jorgjansen1977-spec]

Update

Following the overnight update to v8.46.6 (installed this morning), the persistent "No entity_id for inverter_mode to write Eco" warning has not reappeared, and the Dash status now shows "Config: OK" with no warnings after a fresh restart.

I can't say with certainty whether this was fixed by the version update itself, or by the combination of that update with the custom inverter_type/inverter: block I'd added yesterday (as described above) — I didn't get a chance to isolate the two changes. Either way, the symptom described in the original report is currently gone.

Separately (unrelated to Predbat itself, noting it here only for completeness in case it helps someone else): the "forced export not applied to hardware" issue turned out to have a contributing factor on my side — I had pv_forecast_today pointed at a Solcast sensor that only exposes a single daily total, rather than one with a detailedForecast attribute (half-hourly breakdown). After correcting this, the plan's PV kWh figures now line up correctly with Solcast's detailed forecast, and the plan's charge/discharge timing looks rational (e.g. charging during the cheapest import window of the day ahead of a high export window later on).

I'll continue monitoring over the next few days and will reopen or comment again if either issue resurfaces. Thanks for looking into it.

[jorgjansen1977-spec]

Follow-up: plan appears to leave significant charging capacity/profit on the table

After the fixes above (inverter_type + corrected pv_forecast_today), the plan is now behaviourally plausible (correct charge/discharge rates, sensible arbitrage direction), but I've found a pattern that looks sub-optimal from a cost-minimisation standpoint, and I'd like to check whether this is expected behaviour, a tuning issue on my end, or a genuine planning gap.

The pattern

• Battery starts the day at 5% SoC (after an intentional low reserve override overnight).
• Solcast forecasts ~32.7 kWh PV for the day (accurate — actual PV generation matched this well).
• Import rates overnight/early morning (00:00–11:00) sit around 28–31c, i.e. mid-range, not the day's cheapest.
• Plan schedules no charging at all during that 00:00–11:00 window, leaving the battery sat at the 15% reserve floor the whole time.
• At 11:30, the plan finally schedules a partial charge (Chrg → target 83%) at 16c import — notably cheaper, but the battery had already been sitting idle at the floor for ~11 hours despite rates never being prohibitively expensive.
• Later the same evening (19:30–20:15), the plan schedules forced export at 45–57c down to the 15% floor again.
• End-of-day totals (verified, energy balance checks out within ~1kWh):
  • PV: 32.7 kWh
  • Import: 5.1 kWh
  • Household load: 6.49 kWh
  • Export: 3.95 kWh
  • Battery: net +16.9 kWh (5% → 60%), ~17.8 kWh gross charge over the day (implying some cycling, not one clean fill)

The concern

Given a ~29–41c spread between the cheapest available charge price (16c) and the evening export price (45–57c), and a battery that never got anywhere near full (peaked at 60%, never near the 97% ceiling), it looks like the plan left a meaningful amount of profitable arbitrage on the table — i.e. it should have charged more aggressively (ideally to the 97% ceiling) at the cheapest available price ahead of the high-value export window, rather than partially charging late and never filling the battery.

Question

Is there a specific setting that governs how aggressively Predbat will pre-charge ahead of a known high export window (something like a cost-benefit threshold on calculate_export_first, or a cycle-cost/battery-wear penalty that discourages filling to 97%)? Or is this expected behaviour I should tune via input_number.predbat_metric_battery_cycle or similar, rather than a planning gap?

Happy to share the full plan HTML/debug yaml for this specific day if useful.

[jorgjansen1977-spec]

Small addendum to the above

One possible contributing factor I noticed: the plan's "Load kWh" column shows very low values throughout the middle of the day (0.03–0.14 kWh per 15-min slot) on a day where I know a ~600W air conditioner was running continuously — that alone should be closer to 0.15 kWh/slot before any other household load is added.

I suspect this is simply days_previous: 7 not yet having "learned" this new, atypical usage pattern (the AC has only been running this heavily for the last day or two), rather than a bug — I'd expect the load forecast to catch up within a few days as the rolling history updates. Flagging it mainly in case it's a relevant contributing factor to the charge-timing question above (an underestimated load forecast would make the plan think less charging is needed to cover the gap until the next PV/cheap-rate window).

Not asking for action on this specific point yet — just noting it in case it's useful context, and will report back once the load history has had time to catch up.

[jorgjansen1977-spec]

Second confirmed occurrence: plan shows "Exp" but discharge_start_service is never called

I've now reproduced this a second time, this time with a precise live check that rules out my own bridge automation as the cause.

Live verification (30 July, ~19:45-19:50 slot)

The plan table showed the current slot as:

Time: Thu 19:45   State: Exp↘   Limit%: 55

At the same moment, I checked the actual entity states that my bridge automation uses to translate Predbat's charge_start_service/discharge_start_service calls into hardware commands:

• input_boolean.predbat_discharge_start = off
• input_boolean.predbat_charge_start = off
• number.pylontech_force_h3x_charge_discharge_power_ref = -9.0 (negative = charging in our sign convention, i.e. the opposite of what "Exp" should produce)
• automation.pylontech_live_overschot_volger (my own fallback automation, which my bridge only re-enables when Predbat has requested nothing) = on

I refreshed the plan a few minutes later (19:50) and the same slot still showed Exp with a 55% limit.

Why I believe this rules out my own integration as the cause

My bridge automation's logic is:

• If input_boolean.predbat_discharge_start = on → force User mode + fixed discharge %
• If nothing requested by Predbat → turn my own fallback automation back on and do nothing else

Since discharge_start was off, my bridge correctly did nothing and correctly handed control back to my own fallback automation (confirmed on). This means Predbat itself never called discharge_start_service despite the plan showing an active Exp slot at that exact time — the failure appears to be upstream of my apps.yaml service mapping, in whatever internal logic decides to actually invoke discharge_start_service for a plan slot.

Setup reminder

Custom inverter (inverter_type: H3X), has_service_api: True, discharge_start_service mapped to a plain input_boolean.turn_on action, as recommended for the "custom inverter" bridge pattern.

Happy to enable debug logging and capture the exact log output around a future occurrence if that would help narrow this down — let me know what to look for specifically.

[chalfontchubby]

Is the initial problem - Persistent "No entity_id for inverter_mode to write Eco" warning despite has_ge_inverter_mode: False on custom inverter, and forced discharge not applied to hardware" fixed? If so - please close the issue.

If there are other concerns that need attention - please separate them into separate issues since it's much easier to track what is needed. If you do - please include a screenshot of the plan and predbat_debug.yaml so someone can pick it up to debug.

[chalfontchubby]

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

If Problem 2 (plan shows an active Exp slot but discharge_start_service is never called) is still a concern, please raise it as its own issue - it's a distinct, reproducible bug separate from Problem 1 and the arbitrage/load-forecast follow-ups, and easier for someone to pick up in isolation.

If you do, please include:

• A predbat_debug.yaml and a screenshot of the plan, captured at the same moment a reproduction is visible (same ask as usual - a debug.yaml from a different moment than the screenshot can't be replayed against what you actually saw).
• A predbat.log excerpt covering that same window, specifically grepped for Calling service and Skipped service on the discharge domain (e.g. grep -i "service.*discharge" predbat.log around the timestamp).

That log grep is the key one: call_service_template() (inverter.py) suppresses a repeat call to discharge_start_service if the service name/data/extra_data hash matches the last call - fine for REST/entity-based inverters where Predbat can read back the real state, but for a service-API bridge like yours Predbat has no way to confirm the input_boolean is still actually on. If your fallback automation (or an HA restart) ever flips it back off mid-window, Predbat wouldn't know to re-send the command, because as far as Predbat's concerned nothing's changed. If the log shows "Skipped service ... as it was previously called" at the point you saw the mismatch, that would confirm it.