feat(output): publish aggregated inverter config as a sensor

[springfall2008]

What

Publishes the static inputs the prediction runs from as a single new entity, sensor.<prefix>_inverter_config.

These values are aggregated across every inverter in fetch_inverter_data() but were never published. Anything backed by CONFIG_ITEMS already gets an input_number/switch/select entity of its own, but these come from apps.yaml or are read back off the inverters, so until now the only way to see them was to turn on debug logging and read the log. soc_max was the one exception, already exposed as an attribute of predbat.soc_kw.

The state is the fleet AC inverter limit in kW - the headline number, so it is graphable - with the rest in the attributes:

Attribute
inverter_limit, export_limit, pv_ac_limit	kW
battery_rate_max_charge, battery_rate_max_charge_dc, battery_rate_max_discharge, battery_rate_max_export, battery_rate_min	kW
soc_max, reserve	kWh
num_inverters, num_cars, inverter_can_charge_during_export	topology
metric_standing_charge, forecast_minutes, plan_interval_minutes	planning scalars

Power values are held internally in kW per minute and are converted to kW here to match the existing power sensors, which also carry device_class: power.

Published from the end of fetch_inverter_data(), next to publish_inverter_data(), so it refreshes each cycle and also via quick_inverter_data_update().

Notes

• The export_limit attribute is the inverter's AC export power cap, which is a different thing to the predbat.export_limit plan sensor. Called out in the docs.
• Curves (battery_charge_power_curve and friends) and the inverter-state-dependent values (reserve_current, current_charge_limit, charge_rate_now, discharge_rate_now) are deliberately left out - this sensor is the static configuration.

Testing

New test_inverter_config_sensor, registered in TEST_REGISTRY, covering the kW/minute to kW conversion, a zero limit not being dropped, and the aggregation across two stub inverters through the real fetch_inverter_data() path.

The test moves every value away from the fixture defaults to prove each is published from the attribute it claims to come from, so it snapshots and restores my_predbat state - all tests share one PredBat instance, and leaking a 48 hour forecast_minutes into model_kernel ran the C++ kernel off the end of the fixture's 24 hours of step data.

./run_all --quick passes (4 slow tests skipped), pre-commit clean.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The feature is well-scoped, follows existing publishing patterns, and includes targeted unit-test coverage; only a minor naming nit was found.

Pull request overview

Adds a new Home Assistant sensor to expose Predbat’s aggregated “static prediction inputs” (inverter/battery power caps, topology, and planning scalars) so users can inspect the effective configuration without enabling debug logs.

Changes:

• Publish sensor.<prefix>_inverter_config from fetch_inverter_data(), with fleet AC inverter limit as state and detailed configuration as attributes (with internal kW/min → kW conversion).
• Document the new sensor and its attributes in the output-data documentation.
• Add a unit test that validates conversion, zero-value publishing, and multi-inverter aggregation via the real fetch_inverter_data() path; register it in TEST_REGISTRY.

File summaries

File	Description
docs/output-data.md	Documents the new aggregated inverter-config sensor and clarifies attribute meanings.
apps/predbat/execute.py	Publishes the new aggregated config sensor each inverter-data refresh cycle.
apps/predbat/tests/test_inverter_config_sensor.py	Adds regression coverage for the new sensor’s values and conversions.
apps/predbat/unit_test.py	Registers the new test in the unit test runner.

Review details

• Files reviewed: 4/4 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.