fix(execute): leave the discharge rate alone while charging during a car hold (#5419)

[chalfontchubby]

Posted by Claude on behalf of @chalfontchubby.

Closes #5419. Also fixes the house-battery half of #5467, which is the same fault on a GivEnergy Hybrid Gen 1.

What users see

On a night when the car charges, the house battery stays at its reserve for the whole cheap window. Predbat's status reads Charging, Hold for car, and the inverter has accepted every write: charge slot enabled, target 100%, charge rate 2600 W. The battery starts charging only after the car hold ends.

Cause

On an inverter without timed pause, "Hold for car" sets the battery discharge rate to 0 for the whole car slot (execute.py, the car-hold block in execute_plan). It does this even while the house battery is charging in a charge window. A charging battery cannot feed the car, so the write achieves nothing. On these GivEnergy hybrids, a discharge rate of 0 with the SoC on the reserve stops grid charging altogether.

The evidence comes from two installs:

• GivEnergy battery does not charge during "Charging, Hold for car" when SoC is at reserve (discharge rate 0) #5419 (GIV-HY3.6): the SoC stayed at 4% for every hour the rate was 0. Charging started within minutes of the rate going back to 2600 W, on three separate nights. The night the hold began at 15% SoC, it charged normally.
• House battery left empty all cheap window while status was Charging, Hold for car (Gen 1, v9.3.7) #5467 (Gen 1): the SoC stayed at 0.36 kWh (4%) from 23:01 to 06:00 with the rate at 0. The only charge came at 06:00:51, just after the rate was restored at 06:00:02. The inverter clock runs 1.4 minutes behind, so the inverter still thought it was inside the 00:00–06:00 window.

Fix

While the inverter's own status is Charging, the hold now skips the rate write. It already skipped the reserve bump in this state (#3899). Instead it logs that the hold is deferred. Once charging stops (Hold charging, Demand), the rate and reserve hold apply as before.

The condition reads this inverter's status (status_per_inverter), not the fleet-wide status, which can carry over from an inverter processed earlier.

Inverters with timed pause are deliberately unchanged and still pause discharge during the charge. The pause is one latched write that blocks only discharge. It also covers the moments when the inverter reaches its target before Predbat sees it, and no report ties it to the charging fault.

Known limits (deliberately out of scope)

• set_discharge_during_charge off (default on): on these inverters it still sets the rate to 0 for every charge window, so the same quirk could bite with no car involved. I have no report of that, so I've left it alone.
• "Charging" is plan-derived:
  • With set_soc_enable off, the status stays "Charging" even after the inverter reaches its own target.
  • With it on, there is a gap of up to one execute cycle after the target is reached.
  • In both cases a battery above reserve can now feed the car until Predbat notices. Before this change, the rate of 0 covered those moments.
  • At the reserve (the reported case), the reserve floor still blocks discharge.
• The , Hold for car status annotation stays while the hold is deferred, because the hold comes back as soon as charging stops. I'm happy to drop it if you'd rather the status show only holds actually applied.

How to check

• ./run_all --test execute:
  • car_charge_no_reserve_ratchet now expects the maximum discharge rate while charging. On main it fails with Discharge rate should be 1000 got 0.
  • The new car_charge2_no_pause pins the rate hold still applying under Hold charging on an inverter without timed pause. It fails if the skip is widened to cover "Hold charging".
• ./run_all --quick passes, and pre-commit passes.

🤖 Generated with Claude Code