Fix Sigenergy Cloud PV power key and MQTT-vs-REST field clobbering

[chalfontchubby]

Two independent bugs in the Sigenergy Cloud (openapi/MQTT) component, both root-caused from the reporter's logs on #4663.

1. pv_power permanently stuck at 0W

The realtimeInfo REST payload spells the field pVPower (capital V) - inconsistent with pvEnergyDaily/pvTotalPower alongside it, and with the MQTT period topic's "PV power". fetch_energy_flow_from_realtime read pvPower, which never matched, so PV silently defaulted to 0 forever.

That is exactly the reporter's "physically impossible" power-flow diagram: battery charging hard while PV reads 0.

Fixed with a fallback chain: pVPower → pvTotalPower → pvPower. pVPower is primary because across three consecutive samples in the log it tracked the string-derived power (4.26 → 4.33 → 4.67 kW) while pvTotalPower lagged flat at 4.38.

2. SoC resets to 0% within minutes of restart, forcing a mid-export replan

_handle_mqtt_period rebuilds energy_flow wholesale from a raw dict merged across period messages (added in #4172, so a field that stops changing isn't re-read as 0). That merge only helps once a field has been seen at least once.

This reporter's period messages carry only "PV power", so storageSOC% (and battery/grid power) were never present in the merged state, defaulted to 0, and overwrote the good values the REST poll had already fetched. The log confirms the sequence: 30.84kWh/85% from REST → an MQTT period message reporting SOC 0% → a 0.0kWh/0% status two minutes later.

Fixed by falling back to the previous energy_flow/system_status value for any field this system has never reported, rather than defaulting to 0.

Tests

New regression test for the never-reported-field case, both with and without a prior REST value. Verified failing without the fix - without the guard it throws KeyError on the first genuinely absent field, which is itself confirmation the guard is load-bearing rather than cosmetic.

./run_all --quick and pre-commit green, re-run after rebasing onto current main.

Notes for review

• Not dogfooded live. This is the Cloud (openapi/MQTT) component, not the local Modbus integration my own Sigenergy system uses, so I have no way to exercise it directly.
• ## Sigenergy Cloud integration: pv_power entity permanently stuck at 0W, no restart clears it #4663 is closed - the reporter closed it themselves after moving to the Modbus Sigenstor integration, which sidesteps this component entirely. Both bugs are still present on main, so this is referenced as context rather than as a fix-closes; anyone else on the Cloud component will still hit them.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The REST-side PV key fallback (pVPower/pvTotalPower) is not covered by a regression test in the newly added test block, which risks the original PV=0W bug recurring undetected.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Fixes two Sigenergy Cloud (OpenAPI + MQTT) data-integrity bugs that could (a) pin PV power to 0W due to a mis-cased REST field name and (b) let sparse MQTT period messages overwrite previously-correct REST-derived fields (notably SoC) with fabricated zeros.

Changes:

• Update REST realtimeInfo parsing to read PV power via a fallback chain (pVPower → pvTotalPower → pvPower).
• Update MQTT openapi/period handling to preserve previously-known energy_flow / system_status values when a field has never been reported by that system.
• Add a regression test covering the “never reported field” MQTT clobbering scenario and register it in the Sigenergy test suite.

File summaries

File	Description
apps/predbat/sigenergy.py	Fixes PV power key parsing from REST and prevents MQTT sparse updates from zeroing never-reported fields.
apps/predbat/tests/test_sigenergy.py	Adds regression coverage for the MQTT never-reported-field scenario and wires it into run_sigenergy_tests.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

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