VPP Control don't affects the inverter as planned

[zlakes01]

My settings is:

VPP Control

Power Control Mode: select.solax_remotecontrol_power_control
Active Power Target: number.solax_remotecontrol_active_power
Autorepeat Duration: number.solax_remotecontrol_autorepeat_duration
Power Control Trigger: button.solax_powercontrol_trigger
Battery Minimum SOC: number.solax_selfuse_discharge_min_soc
Charger Use Mode: select.solax_charger_use_mode

This select Power -400 W for export period and the battery continue charges.

[johanzander]

Can you export debug logs and attach them here?

[zlakes01]

faaac926_bess_manager_2026-07-10T08-02-50.539Z.log

[zlakes01]

I'm also wondering where are all BESS entities?

[bess-agent]

Thanks for the report and the log file — I looked into it, but I need a different export to confirm what's going on.

What was attached is the BESS Manager add-on's raw application log, not the structured debug bundle. It's genuine BESS output (I can see the optimizer's core.bess.* log lines), but it only shows what BESS decided and sent — it has no sensor readback afterward, so I can't confirm what the inverter actually did in response.

From the log, BESS did compute and send the command you described:

• Period 40 (10:00): Intent=BATTERY_EXPORT, -400 W, DischargeRate=4%
• It issued the correct SolaX VPP sequence (select_option → "Enabled Battery Control", set_value → -400, autorepeat, button.press) as a real (non-test-mode) call, no errors.

That's as far as I can go without seeing battery_power / battery_soc / pv_power around 10:00–10:02, and without knowing your Charger Use Mode (solax_charger_use_mode) setting — this looks like it could be a firmware/config-level interaction with the SolaX inverter rather than a BESS bug, but I can't confirm that from a log alone.

Could you generate and attach the debug bundle instead? In the BESS Manager web UI:

1. Go to Settings → Diagnostics, click "Export Debug Data" (downloads a markdown file), or
2. Click the "Report a problem" icon in the header, which downloads the same bundle and opens a pre-filled GitHub issue for you.

Please try to generate it as close as possible to the time the battery kept charging instead of discharging, so the sensor data covers that window. Also worth including your current Charger Use Mode setting from the SolaX integration.

Separately: the log shows recurring InfluxDB connection errors (homeassistant.local:8086, [Errno 22] Invalid argument) throughout the session — unrelated to this issue, but worth checking your InfluxDB host config if you rely on historical/predicted savings data.

[zlakes01]

bess-debug-2026-07-10-130321.md

[bess-agent]

Thanks for the debug bundle — this confirms the symptom and lets us rule a few things in/out.

Current problem confirmed: the debug bundle shows the same pattern recurring at a later period (period 52, 13:00), not just the earlier period 40 report — so this is consistent, not a one-off log artifact.

What I checked in the code (core/bess/solax_controller.py, core/bess/ha_api_controller.py, core/bess/battery_system_manager.py):

1. No dual-register conflict. The DischargeRate=4% in the log is not a second hardware write — SolaX doesn't support charge-rate-register control (supports_charge_rate_control = False). It's purely a display-side derivation of the wattage from max_discharge_power_kw; 4% × 10kW = 400W, matching the log exactly. There's only one write path (set_solax_active_power_control), and it's the correct one.
2. BESS never touches Charger Use Mode. The entity is discovered/mapped but there is no get_solax_charger_use_mode()/set_solax_charger_use_mode() anywhere in the codebase — it's entirely under the inverter's own firmware/config, outside BESS's control.
3. Direct evidence the command was overridden at the inverter, not by BESS. At 13:01:06 BESS issued Period 52 (13:00): Intent=BATTERY_EXPORT, Action=-0.40 kW via the full VPP sequence with no errors. Two minutes later (export snapshot at 13:03:18), the live sensors show battery_power_charge = 3908 W (charging), pv_power_total = 5160 W, house_load = 1069 W — solar surplus (~4091 W) almost exactly matches the observed charge rate. The battery absorbed solar surplus instead of exporting, right when BESS's −400 W command should have been active.

Root cause: this looks like the SolaX inverter's own EMS logic (most likely driven by Charger Use Mode) overriding the VPP remote-control command in favor of its native self-use/solar-charging behavior, rather than a BESS-side bug. BESS computed and sent the correct command both times, through the one documented path, with no errors — there's no sign, register, or logic error on our end to fix. SolaX VPP is our newest and least hardware-validated platform, so an interaction like this between Charger Use Mode and remote active-power control wouldn't be surprising.

One gap: this bundle's compact log format doesn't capture the individual HA service-call lines for the VPP sequence (select_option/set_value/button.press), only the higher-level DECISION/HARDWARE lines — so we can't independently re-confirm from this bundle alone that all 4 calls succeeded at 13:01:06. We saw them succeed cleanly in your first raw log at period 40 on the same code path/config, so we don't have reason to think this run differed, but flagging it as a bundle limitation rather than a proven fact.

Could you help confirm the inverter-side theory?

1. What is select.solax_charger_use_mode currently set to (e.g. "Self Use", "Feed-in Priority", "Back-up Mode" — whatever your firmware's option list shows)?
2. As a test: if your firmware has a mode intended for remote/VPP control priority, switch to it and see if the −400 W export is then honored during solar surplus.
3. If available, enable sensor.solax_inverter_solax_remotecontrol_mode_8_battery_power_target_readback in Home Assistant (it's currently disabled by the integration in your entity registry). That sensor should show the power target the inverter's remote-control mode actually received — it would tell us definitively whether the inverter is receiving −400 W and ignoring it, or not receiving it at all.

Separately, unrelated to this issue: battery_charge_power and battery_discharge_power are both mapped to the same entity, and sensor.solax_charge_discharge_power (a combined signed sensor) isn't mapped at all — this only affects BESS's own monitoring/actuals math, not live control, so I'll track it separately rather than mixing it into this report.

[johanzander]

Please note that native Solax support is experimental, and you are the first one to try it out to my knowledge. Any feedback on how should work is appreciated!

[zlakes01]

I run Predbat due mode8 script and it works well. Predbat run set_solax_active_power_control fixed (10kW in my case).
Solax modbus has two battery sensors and both is single but oposite to each other.
Charger use mode is during summer "self use" and during winter "backup". Solax has 100.000 register writings capacity so it is good to avoid change use mode.

[johanzander]

Thanks for the extra detail on your Predbat setup — that's a useful data point since it means −400W (or a fixed target) can be honored on this hardware when driven correctly, which supports the theory that this is a Charger Use Mode/firmware interaction rather than something wrong in how BESS issues the command.

A couple of things would help pin this down:

1. Since Predbat successfully forces a fixed power target without changing Charger Use Mode, could you check whether your Charger Use Mode was set to "Self Use" or "Backup" at the time of the failed BESS test (13:00)? You mentioned it's seasonal (Self Use in summer, Backup in winter) — knowing which one was active during the 13:00 test would tell us if that's the actual variable.
2. If you still have sensor.solax_inverter_solax_remotecontrol_mode_8_battery_power_target_readback available, could you enable it and capture its value during a BESS export period? That would tell us definitively whether the inverter is receiving −400W and overriding it internally, or not receiving it at all — which points to two very different fixes.
3. Since Predbat writes a fixed power value successfully via the same underlying entity, could you share how it sequences its calls (e.g. does it also toggle Enabled Battery Control each time, or leave it enabled continuously)? If BESS is re-triggering the mode select on every period and that itself causes SolaX firmware to briefly hand control back to self-use, that would be a fixable sequencing bug on our side.

Given SolaX VPP is still experimental and you're the only person we've heard from running it, any of this detail is genuinely useful for us to get it right.

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

BESS Manager issued the correct SolaX VPP export command (Period 52, 13:00: Intent=BATTERY_EXPORT, -0.40 kW, i.e. −400 W) through its one and only SolaX write path, with no errors, and the mode-select entity read back "Enabled Battery Control" afterward. Two minutes later the battery was charging at 3908 W from a ~4091 W solar surplus (5160 W PV − 1069 W load), with both grid import and export sitting at exactly 0 W — a clean self-use pattern, not a partial override. This points to the SolaX inverter's own self-use/EMS logic taking precedence over the remote power-control command, rather than a bug in what BESS computed or sent. This confirms (independently re-derived, not just trusted) the conclusion reached in the previous analysis comment on this issue.

One refinement beyond that prior analysis: BESS re-issues the entire VPP enable sequence (select_option → "Enabled Battery Control", power target, autorepeat, trigger button) unconditionally on every ~15-minute optimization cycle, not only when the strategic intent changes (battery_system_manager.py:765-767 calls _apply_period_schedule outside the "should apply" branch, and _apply_period_schedule → apply_period → set_solax_active_power_control has no "only if changed" guard). This is a real, verified BESS behavior and a plausible trigger for a SolaX firmware handback to self-use — the maintainer specifically asked about this on 2026-08-08 (comparing against how Predbat's mode8 script sequences its calls), and it remains unconfirmed either way because the inverter's own power-target readback sensor was never captured.

Evidence

• core/bess/battery_system_manager.py:765-767 — _apply_period_schedule(current_period) runs on every cycle when not prepare_next_day, regardless of whether should_apply was true for the broader schedule.
• core/bess/battery_system_manager.py:2754-2761 — _apply_period_schedule unconditionally calls self._inverter_controller.apply_period(self.controller, grid_charge, discharge_rate, block_passive_charging, strategic_intent) every cycle.
• core/bess/solax_controller.py:145-159 (_write_period_to_hardware) — single write branch for a discharge: target_watts = -int(self.max_discharge_power_kw * discharge_rate / 100 * 1000); controller.set_solax_active_power_control(target_watts). No dual-register path exists.
• core/bess/ha_api_controller.py:2248-2278 (set_solax_active_power_control) — unconditionally issues select_option("Enabled Battery Control") then sets power/autorepeat and presses the trigger, every call, with no "already enabled" short-circuit.
• core/bess/solax_controller.py:51, :56 — supports_charge_rate_control = False, discharge_rate_is_load_following = False: the logged DischargeRate=4% is a display-only derivation of watts (4% × 10 kW = 400 W), not a second hardware register write.
• core/bess/ha_api_controller.py:747 and grep of core/bess/*.py — charger_use_mode appears only as a discovered/mapped entity; no getter or setter exists anywhere. BESS never reads or writes Charger Use Mode.
• Debug bundle bess-debug-2026-07-10-130321.md:28337-28340 — 2026-07-10 13:01:06 | INFO | core.bess.battery_system_manager:2368 - Period 52 (13:00): Intent=BATTERY_EXPORT, Action=-0.10 kWh (-0.40 kW), DischargeRate=4%, immediately followed by solax_controller:242 - SolaX: current period 52 (13:00) → BATTERY_EXPORT, no error/warning nearby.
• Debug bundle :4069-4075 (entity snapshot, 13:03:18) — sensor.solax_battery_power_charge=3908 W, sensor.solax_grid_export=0 W, sensor.solax_grid_import=0 W, sensor.solax_house_load=1069 W, sensor.solax_pv_power_total=5160 W.
• Debug bundle :73-77 — select.solax_remotecontrol_power_control read back "Enabled Battery Control" at the same snapshot, confirming the HA-side write was accepted.

Separately, unrelated to this failure: the bundle's config (:4018, :4030) shows battery_charge_power and battery_discharge_power both mapped to sensor.solax_battery_power_charge — a real bug in the reporter's version (BESS 9.8.1) that corrupted BESS's own derived net-battery-power and flow accounting, since fixed on main by commit e80d624 (#560, merged 2026-08-13, addressing #542). This does not explain the export command being ignored — it affects reporting/accounting, not the hardware write.

Proposed fix

No BESS-side code defect has been identified in the write path itself — the command computed and sent matches what the reporter configured, through the one documented path, with no errors. Before proposing any code change, this needs the inverter-side evidence the maintainer already requested: the Charger Use Mode setting active during a failed export, and — most importantly — the SolaX remote-control power-target readback sensor captured during a live BESS export period, to distinguish "inverter never received −400 W" from "inverter received it and overrode it internally." If the every-15-minute re-toggle of "Enabled Battery Control" turns out to be the trigger (comparing against how Predbat sequences the same calls), the fix would be to only re-issue the enable sequence when the intent/mode actually changes, rather than every cycle — but that should not be built until the readback sensor confirms it's the actual mechanism, since the "reconcile lost segment" cycle-repeat behavior (#551/#554) exists deliberately for platforms where the inverter can silently drop a programmed state.

Risks / open questions

• Charger Use Mode state during the 13:00 test was never captured (still open from 2026-08-08).
• The inverter's own power-target readback sensor (...mode_8_battery_power_target_readback) was never captured during an export period — this is the single piece of evidence that would resolve whether BESS's command reached the inverter's control logic at all.
• How Predbat sequences its VPP calls (every cycle vs. only on change) is still unconfirmed, so the every-cycle re-toggle remains a plausible but unproven contributing mechanism.
• SolaX VPP is experimental and hardware-unvalidated beyond this one reporter; any fix here should be treated as a hypothesis to test against real hardware, not applied blind.

---

Reply @claude-bot fix to implement and open a draft PR.