IOG charging - Multiple inverter setpoint writes when charging car #5434

Activity

1. tmh88

   assigned

   springfall2008

   on Oct 7, 2026
2. springfall2008 commented on Oct 7, 2026

   

   springfall2008

   on Oct 7, 2026

   Owner

   More actions

   Automated first-pass triage — this summary comes from a bot run on current main; a maintainer will review before any action is taken.

   Classification: bug · component Octopus (IOG) · Priority: medium (every IOG user with the car charging overnight gets this; workarounds exist, the register-write volume itself is the harm)

   I confirmed the whole symptom from your attached predbat.log (v9.3.5 until 16:02 on 6 Oct, v9.3.6 from then on; your register-write graph window 6 Oct 20:00 → 7 Oct 06:00 is the v9.3.6 car-charging night) and the four debug dumps. What the log shows:

   1. The write burst is exactly the car-charging window. Register writes per hour: 2 in the 14 quiet daytime hours of 7 Oct (same version, car not charging) vs 24 (23:00), 14 (00:00), 9-10 (01:00-02:00), 23 (03:00), 20 (04:00) during the car's IOG session — your 53-write graph reproduced exactly.

   2. The values written flip because the plan's charge limit flips. Overnight the adopted charge limit walked 72 → 97 → 76 → 74 → 82 → (window off) → 74 → 77%…, and with Set Charge Low Power Mode on, each new target re-selected a trickle rate to just reach it by 05:30 (97% → 951W/18A, 76% → 483W/9A) versus the 4.2-5.3kW/80-100A full rate — precisely the "different battery charge SOC and max charge current" you see. Several adoptions are logged as "New plan metric is significantly better from previous plan, using new plan" with 2-98p deltas.

   3. Why the plan keeps re-deciding. Charging the house battery inside the 5.23p IOG band is metric-nearly-flat (import 5.23p vs energy worth ~12p export / ~30.8p avoided import), so the optimizer's limit sits on a plateau and moves whenever its inputs move — and while the car charges the inputs move almost every cycle:

   • The dynamic-load status flapped high ↔ baseline ↔ low 43 times in the log as the Audi/Hypervolt cycled on and off; each flip forces a full replan (dynamic_load() in plan.py → "Will recompute the plan as it is invalid" at predbat.py:1117).
   • Your watch-listed event.octopus_energy…octoplus_free_electricity_session_events re-reports its events every ~15 minutes (00:13:09, 00:28:09, 00:43:09…); every refire marks the plan invalid and triggers an unscheduled full replan, which is why plans also ran at :13/:28/:43/:58.
   • The car's SoC only moves in ~3kWh steps (50.44 → 54.32 → 57.23kWh), and the car plan's slot end (04:55) tracks it, shifting the load forecast each step.

   4. The worst single writes — the SoC 10% ↔ 100% cliffs in your graph. At 23:31:40, 01:50 and 02:43 the planner re-established the window at a later start than the inverter's already-started one (with Set Window Minutes 0), so execute.py:618-624 ("disabled charge window while waiting for schedule") switched scheduled charge off entirely — writing start/end times, the SoC target and the charge-stop service — and the following recompute re-established it minutes later.

   What it is not (checked against current main): not PR #5403's new car-need gate — your log has zero "dispatch minutes no car needs changed" replans (your overnight dispatch sits inside the fixed 23:30-05:30 IOG window, so no minutes turn surplus); and not a general v9.3.6 regression — the same version ran a whole quiet day (7 Oct, car not charging) on ~2 writes.

   Things you can change now (soften the symptom, don't cure it): turn off Set Charge Low Power Mode (removes the 8-18A ↔ 80-100A current churn; the SoC-target flipping remains), and/or remove octopus_free_session from watch_list in apps.yaml (removes the ~15-minute unscheduled replans).

   For the maintainer — the underlying issue is that per-cycle recomputes re-adjudicate a metric-flat choice on churning car-dependent inputs (recompute pressure from dynamic-load flapping and watch-list refires), and each adjudication that clears metric_min_improvement_plan (2.0p default, plan.py) or is merely less fragmented (plan.py:1745) is adopted and written. Related: #2649 (the general "reduce inverter writes" ask), #5330 (equal-cost placement of house-battery charge within an IOG band), #4840 (plan-adoption threshold lock-in). No unit test covers plan/limit churn over time, so I ran none — the evidence here is your log + debug dumps, which cover it fully.
3. springfall2008

   added

   BOT_TRIAGEDHas been through the triage botHas been through the triage bot

   bugSomething isn't workingSomething isn't working

   Octopus

   priority_medium

   on Oct 7, 2026
4. gcoan commented on Oct 7, 2026

   

   gcoan

   on Oct 7, 2026

   Collaborator

   More actions

   Things you can change now (soften the symptom, don't cure it): turn off ... and/or remove octopus_free_sessionfromwatch_list` in apps.yaml (removes the ~15-minute unscheduled replans).

   I checked the predbat templates and octopus_free_session is not included in any of the standard templates so must have been added by the raiser. The Bot is right, including this means that a predbat replan is forced every time a free electricity session is added and every 15 minutes as the event auto-updates in the BCD integration.
   The templates do include octopus_saving_session, so similar behaviour for the power up saving sessions, a replan will be triggered every 15 minutes and when a new session is announced and joined.

   Arguable whether either are need in watch_list. Including them means that Predbat is more responsive to these events appearing instead of waiting for the next automatic 10 minute update, but at the handicap of extra replans every 15 minutes when nothing has happened and in practice there is advance warning of saving/free sessions so predbat doesn't need to re-evaulate the plan immediately