fix: send this cycle's planned rate as {power} to service-driven inverters (#3311, #5252)

[chalfontchubby]

Posted by Claude on Rik's behalf.

Fixes #3311
Fixes #5252

Replaces #4645 and #5254, both now closed.

Problem

Some setups drive the inverter through Home Assistant services, such as the Solax SX4 template, which runs a script. Predbat passes those services the charge or discharge power as {power}, and that value was wrong in two ways:

• It came a cycle late (Service-driven inverters receive the previous cycle's rate as {power} #5252). execute_plan() calls the start services inside its per-inverter loop. The rates are only written after that loop, so that the balancer can see the whole fleet first. So {power} was always the previous cycle's rate: the first call of a low power window carried the maximum, and every rate change lagged a cycle.
• It was always the maximum (Low power mode does not work on Solax #3311). The power is read back from the charge_rate/discharge_rate entity. A script-driven inverter has no such entity, so the read-back fell back to battery_rate_max, and a low power charge ran at full power.

Change

1. Start services are called after the rates are set (execute.py). This only applies where a start or freeze service actually sends {power}. A service counts if it's given by name alone, which passes every default option, or if it's a template with a value referencing {power}, including forms like {power:.0f} (services_send_power()). Only a string value counts, or the inverter's own entry of a per-inverter list, as those are what get filled in; a {power} nested inside a mapping is never filled in. In those setups, the loop queues its adjust_charge_immediate()/adjust_export_immediate() calls and makes them in the same order once balancing and apply_rate_intent() are done. {power} is then the rate actually set this cycle, after balancing. Every other setup is unaffected, including the many service templates that never use {power}: their calls run where they did, in the same order against the inverter's other writes.
2. Predbat remembers the rate it set when there is nowhere else to store it (inverter.py). This applies to a "power" inverter that has a {power} service in that direction but neither a rate entity nor a rate percentage of its own. Predbat keeps the last rate set on the Inverter object, which persists between plan cycles (fix(inverter): Persist inverters across planning cycles #5126), and reads that back instead of battery_rate_max. A plain number in charge_rate also counts as "no entity" and is never written to. In a mixed fleet, that number is another inverter's default. Likewise a charge_rate_percent bound only for another inverter (Mixed inverter setups: the charge/discharge rate is read and written by "is the key set", not by each inverter's own entry #5359): this inverter holds its rate rather than reading its empty entry as 100%, and neither control is written for it.
3. The remembered rate moves as a register would. A change inside the usual 5% deadband is held, so {power}, which is part of the start service's dedup, doesn't make the script run again every cycle. The one exception is a move to or from 0W, which always counts as a change. On a 10kW battery the deadband is 500W, so a 400W low power charge straight after an export would otherwise stay at the export's 0W and never start. A rate register is left out of that exception: one that stores a small rate as 0 (GivEnergy's whole-percent step, or a *_rate_percent under 1%) would otherwise be rewritten every cycle.

If another inverter enters calibration partway through the loop, the calls already queued are made after calibration's full-rate writes and before control ownership is dropped, as they were inline.

With main's control-failure monitor (#5563), each inverter's control expectation is recorded after the queued start calls, so the monitor's grace period starts once the service has actually been called. A test pins that order.

Also fixed along the way: self_test() passed kW-per-minute values as rates, and the "is not a number" errors had the inverter id and the value swapped.

Why not #4645 or #5254?

• fix(inverter): auto-create charge_rate entity for script-driven "power" inverters (#3311) #4645 created a dummy charge_rate entity so there was something to read back. Most of its five weeks of review went into problems the dummy entity caused: keeping each inverter's entry in the per-inverter lists, the interaction with charge_rate_percent and components, the GivEnergy maximum-rate lookup, and a new inverter-type flag. Predbat chose the rate itself, so remembering it needs none of that.
• fix(execute): send this cycle's rate to service-driven inverters as {power} (#5252) #5254 passed the planned rate into the start services instead of moving the calls. That sent the rate from before balancing, needed a second deadband in the service path, and still sent the planned rate ahead of calibration. Calling the services after the rates are set avoids all three.

Known limits

• Balancing. The balancer's 60-second poll can change a remembered rate without calling the service. The script picks up the new rate on the next plan cycle, up to 5 minutes later.
• Errors partway through a cycle. If execute_plan() raises partway through, the queued calls for that cycle aren't made. They used to have gone out already for the inverters handled before the error.
• Solis FB00. The FB00 mode switch is written inside the immediate calls, so it moves after the reserve reset, but only on a setup that also has a {power} service.
• Inverters with a rate register above about 8kW still keep a low power charge after an export at 0W, because the 400W is inside their deadband. This is unchanged from main and is tracked separately in A rate register held at 0W ignores a low power rate inside its deadband (batteries above 8kW) #5381.
• Restarts. After a Predbat restart, the remembered rate reads as the maximum until the next rate is set.

Tests

• test_execute. The scenarios now configure start services. The test double records the {power} a real call would send, and every scenario asserts it equals the rate written that cycle. Without commit 1, the first charging scenario fails with "power 1000 should match … 2000".

• inverter_rate_no_entity covers:

  • the read-back;
  • the register-like deadband and the 0W rule;
  • surviving a config refresh;
  • an entity still being read, including a decimal string with no unit;
  • a register reading 0W not being rewritten, in both watts and percent;
  • a plain number in the rate entry being treated as no entity;
  • a percentage bound only for another inverter, with this inverter's rate entry a number, missing or empty, for charge and discharge;
  • a {power} in only another inverter's entry of a per-inverter list;
  • no remembered rate when no service sends {power};
  • services_send_power() and queue_immediate().

  It uses the SX4 template's own inverter: block.

• inverter_rate_no_entity_execute (6kW) and inverter_rate_no_entity_execute_10kw drive execute_plan() through idle→charge and idle→export→charge. Each asserts that the first charge_start carries the planned rate and that the next cycle sends nothing new.

• execute calibration ownership. A calibration break leaves no control owned by the calls queued before it.

• Mutation checks. Each change was reverted in turn, and its test fails:

  • deferring the calls;
  • remembering the rate;
  • the 0W rule;
  • keeping the 0W rule off registers;
  • treating a plain number as no entity;
  • the {power}-service gate.

• Every commit passes ./run_all --quick and pre-commit on its own.

Before Predbat sets a rate after a restart, a held rate reads as the maximum after any inverter_limit_charge/inverter_limit_discharge, not the raw battery_rate_max, so a limit close to the maximum still reaches {power} (7879ce5).

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🟡 Changes recommended

Power-service detection must distinguish charge from discharge to avoid remembering rates that are never applied.

Review effort: Balanced
Findings: 1

Open (1)

• Track charge and discharge power flags separately · New

What changed in this PR

Fixes service-driven inverter power values so {power} reflects the current cycle’s balanced rate.

Changes:

• Defers power-dependent service calls until rates are applied.
• Remembers rates for inverters without rate entities.
• Adds regression tests and documentation.

File	Description
docs/​inverter-setup.md	Documents {power} rate behavior.
apps/​predbat/​const.py	Defines power-aware service names.
apps/​predbat/​utils.py	Detects services using {power}.
apps/​predbat/​inverter.py	Adds remembered-rate handling.
apps/​predbat/​execute.py	Defers immediate service calls.
apps/​predbat/​unit_test.py	Registers new tests.
apps/​predbat/​tests/​test_execute.py	Verifies current-cycle service power.
apps/​predbat/​tests/​test_inverter_rate_no_entity.py	Tests entity-free rate handling.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

Unresolved moderate findings affect call ordering, per-inverter service handling, and regression-test coverage.

0 open findings

1 resolved since last review

• Track charge and discharge power flags separately

Previously missed (2)

In code that hasn't changed since last review

Defer only calls with power-bearing payloads

apps/​predbat/​execute.py:364

This global gate queues every immediate call whenever any configured service anywhere in self.args mentions {power}. In a mixed setup where only one direction or one inverter uses a power-bearing service, the other inverter/direction's non-power start/stop calls are now all delayed until after apply_rate_intent(), changing the established ordering even though their payload cannot be stale. Determine queueing per call's inverter/direction (or keep separate affected/unaffected queues) so only calls that actually send {power} are deferred.

Document percentage-controlled discharge rate sources

docs/​inverter-setup.md:3689

This documents the discharge payload as coming from discharge_rate, but get_current_discharge_rate() first uses discharge_rate_percent when that control is configured, and the new no-entity path can use Predbat's remembered rate. Please mirror the charge description here so percentage-controlled and service-driven discharge setups are documented accurately.

🧠 Review effort: Lite

[chalfontchubby]

Posted by Claude on behalf of @chalfontchubby.

Replying to the two "previously missed" points in the latest Copilot review:

Document percentage-controlled discharge rate sources: agreed, fixed in 82a98cb. The discharge power entry in docs/inverter-setup.md now matches the charge one. It names discharge_rate_percent, a discharge_rate entity, and the remembered rate for a power inverter that has neither.

Defer only calls with power-bearing payloads: no change here. The split it suggests wouldn't isolate anything:

• The start, stop and freeze services are global apps.yaml settings. call_service_template() reads them from self.base.args, not per inverter, so every inverter's calls use the same templates.
• Each immediate call uses services from both directions. adjust_export_immediate() calls charge_stop_service and then discharge_start_service, and adjust_charge_immediate() can fall back to discharge_stop_service. So a queue split by direction can't tell which calls carry {power}.
• The only effect on a call that doesn't send {power} is that it runs after apply_rate_intent() in the same cycle, instead of between rate writes. The immediate calls still run in the order the loop chose.

[Copilot]

🔵 Needs a closer look

Two moderate execution issues remain unresolved, along with a self-test regression-coverage nit.

0 open findings

🧠 Review effort: Lite

[Copilot]

🔵 Needs a closer look

Two moderate issues remain involving stale remembered rates and per-inverter {power} detection.

0 open findings

🧠 Review effort: Lite