Sigenergy: Predbat and Axle contend for the inverter — VPP mode evicts Axle's NBI dispatch

[mgazza]

Summary

On a Sigenergy, Predbat's VPP mode and Axle's NorthBound Interface (NBI) are mutually exclusive — the inverter accepts one controller at a time. Today Predbat wins that contest by accident rather than by design, and evicts Axle mid-dispatch.

_manage_vpp_registration() in apps/predbat/sigenergy.py runs on the 5-minute poll tick and, whenever the system is not in VPP and the read-only switch is off, switches it straight back to VPP. It has no awareness of Axle at all (grep -ci axle apps/predbat/sigenergy.py → 0).

Evidence

From a live system on 2026-08-06 (identifiers redacted — this is a public repo). Axle had an export event scheduled 20:00–21:00 local, 100 p/kWh, which Predbat had already ingested as its own export window via load_axle_slot().

Operating-mode timeline:

19:35:18  ->  Northbound Integration      (Axle takes the inverter)
19:40:12  ->  VPP                          (back to Predbat)

Exactly one SIGENERGY_POLL_INTERVAL. Meanwhile, once per minute:

19:35:54 Warn: SigenergyAPI: System <redacted> is not in VPP mode
         (Northbound Integration) — controls skipped until onboard is approved
... 19:36:54, 19:38:01, 19:39:01, 19:40:01

The user's report was "it changed to NBI Scheduling and then went back to VPP" — with the reasonable follow-up question of why Axle appeared to own a mode that is actually Predbat's.

Two problems

1. Nobody decided who owns the inverter. Predbat wins on a 5-minute timer. It's not obviously wrong — Predbat plans the Axle session as its own export window, so the event still delivers — but it's a race, it's silent, and it overrides whatever Axle had scheduled.

2. axle_control exists and doesn't reach this component. Fetch.fetch_config_options() (apps/predbat/fetch.py:2408) already raises set_read_only_axle when axle_control is set and an Axle event is active. But that flag is only consumed in execute.py:63 and output.py:955. sigenergy.py reads the user-facing switch.predbat_set_read_only entity instead, so even with axle_control: true the component would still reclaim VPP and evict Axle. The stand-down feature does not work on Sigenergy.

Side effect worth fixing either way

While in NBI, onboard_status is derived as pending_approval. Downstream UIs render that as "approve this in the Sigenergy app" — so every Axle event raises a false onboarding alarm at a system that is fully onboarded. Both PRs below fix this.

Proposed alternatives

Two mutually-exclusive draft PRs. Only one should merge.

• A — Predbat owns the inverter, deliberately. Keeps today's outcome, removes the race: reclaim VPP every 60s instead of 300s, log the reclaim naming the controller displaced, expose contended_by on the status sensor. No config change; applies to everyone.
• B — Axle owns the inverter during its events. Wires the existing axle_control flag into the component: leave the mode untouched during an event (including not dropping to MSC, which would hand control to the owner's app rather than Axle), suppress battery commands for that window, reclaim VPP when it ends. Dormant unless axle_control: true.

The question that likely settles it

Does Axle credit delivery from meter data, or from its own NBI dispatch completing? If the latter, option A costs the customer the payment even though the energy flowed.

Scope

3 of 6 active Sigenergy systems in our fleet hit this in a single 20-hour window. It is structural and recurs on every Axle event. This is the Sigenergy expression of the same dual-control contention previously seen on GivEnergy.

[mgazza]

Candidate fixes are now open as mutually-exclusive drafts — only one should merge:

• Option A — Sigenergy: make Predbat's ownership of the inverter deliberate (option A for #4454) #4455 feat/sigenergy-predbat-owns-vpp — Predbat owns the inverter, made deliberate (60s reclaim, explicit logging, no config change).
• Option B — Sigenergy: let Axle keep the inverter during its events (option B for #4454) #4456 feat/sigenergy-axle-owns-during-events — Axle owns it during events, by wiring up the existing axle_control flag that never reached this component.

Both carry the same pending_approval fix, which is worth landing either way.

@springfall2008 — the open question that probably decides it is whether Axle credits delivery from meter data or from its own NBI dispatch completing. If it's the latter, option A silently costs the customer the VPP payment even though the energy flowed.

[mgazza]

Correction to the framing above: the two options were not alternatives.

A code review found that option A's faster reclaim actively defeats the axle_control option — fetch.py sets the runtime flag, not the HA switch that sigenergy.py reads, so speeding up the reclaim just evicts Axle sooner. Option A therefore had to honour axle_control regardless; silently overriding an explicit user opt-in, faster, is not defensible under any ownership policy. And once A honours it, A contains B.

So #4455 and #4456 are closed and replaced by a single PR, #4457, which combines them and fixes three review findings:

1. The stand-down flag is false exactly when it matters. reset() initialises set_read_only_axle to False and this phase-1 component runs before the first update_pred() (predbat.py:1648 vs :1748). A restart during a live event would reclaim VPP and kill the dispatch. Now axle_control and the event sensor are evaluated live, which also removes an up-to-5-minute lag on event start/end.
2. Faster reclaim defeating axle_control — fixed by putting the stand-down in the same path.
3. The contention marker was cleared before it was ever published — set on the minute tick, published every 5 minutes, cleared on recovery in between. Now published on the same cadence and never cleared.

What actually remains to decide is not a code choice but a policy one: should axle_control be enabled?

Worth being precise about scope, because I was not: axle_control is a global option. It sets self.set_read_only, gating the whole inverter-write path in execute.py for any inverter type. Enabling it is not a Sigenergy change — it would change who drives the battery during Axle events on every inverter, and would also be the lever for the GivEnergy dual-control contention.

#4457 is safe to merge either way: with axle_control unset — the current state everywhere — the only behaviour changes are the faster reclaim, clearer logs, and the pending_approval fix.

The question that likely decides the policy is still open: does Axle credit delivery from meter data, or from its own NBI dispatch completing?

[gcoan]

For info @mgazza this is caused by Axle changing their despatch mode in the last few days from VPP to NBI to resolve issues with inverters getting stuck in VPP mode and reduce load on the Sig servers

Predbat should ideally be changed to match setting NBI mode to reduce this race condition

There are similar issues with Predbat and GivEnergy inverters on Axle, Predbat sets the export time to 1 minute longer than the session duration, Axle sets it to precisely the session duration, and so during the session the end time flips back and forth as both Axle and Predbat wrestle for control. Not a major issue but is extra inverter writes

[mgazza]

Resolved: Axle settles on meter data.

That answers the open question and decides the ownership policy: Predbat keeps the inverter, axle_control stays off.

Because settlement is on metered export rather than on Axle's own dispatch completing, the customer is credited for the energy regardless of which controller commanded it. Reclaiming VPP therefore costs nobody the payment. And standing down would be actively worse — Predbat's plan respects the customer's reserve, SOC and next-day forecast; an external dispatch does not.

So for #4457:

• Merge it. The pending_approval fix and the honest contention logging are the live wins.
• The axle_control wiring stays as built but stays disabled, which is its current state everywhere. It is now a working fallback rather than a broken option, which is worth having even if we never enable it.
• No further work on the stand-down path is justified.

One residual risk worth naming, since it is the only way this can still cost a customer money: load_axle_slot() makes the Axle window a price signal, not a required delivery. If the optimiser declines to export — low SOC, reserve floor, keep-for-peak — then nobody exports, and the customer earns nothing where an external dispatch would have forced it. That is a Predbat planning question, not a contention one, and it is unaffected by this PR.

[mgazza]

Correction to my previous comment: disregard the "residual risk" about load_axle_slot() being a price signal rather than a required delivery.

Under meter-based settlement that design is correct. A 100p/kWh uplift on rate_export is a very strong signal, so if the optimiser declines to export it is because something was worth more than that — a reserve floor, or SOC held for an upcoming peak — and forcing the export would cost the customer more than the Axle payment returns. Non-export in an Axle window is the optimiser working as intended.

My concern only held under dispatch-based settlement, which is not the model. No follow-up needed.