feat(heat pump): add COP, compressor sensors, refrigerant circuit and heating rod stats

[lackas]

Summary

Add comprehensive heat pump monitoring methods, primarily for Vitocal 300-G but applicable to other models exposing these API features.

New features:

• COP (Coefficient of Performance): heating, DHW, total, cooling, green
• Compressor: power, modulation, load class fallback for statistics.load path
• Refrigerant circuit: hot gas/suction gas pressure & temperature, liquid gas temperature
• Heating rod: runtime by level, power consumption summary (DHW & heating)
• Configuration: buffer temp max, damping factor, heater approvals
• Primary circuit pump rotation
• Circuit target temperature
• New CoolingCircuit class with type and reverse active status

Closes #677

Review guide

Total: ~290 lines of library code, ~280 lines of tests

Lines	Type	What to review
~35	Logic	Load class fallback in Compressor (lines 547-585) - tries statistics then statistics.load
~15	New class	CoolingCircuit class (lines 529-543)
~240	Boilerplate	Standard getters following existing pattern: @handleNotSupported decorator + single-line property access

The boilerplate getters all follow the exact same pattern as existing methods like getSeasonalPerformanceFactorHeating(). You can skim these quickly - they're just exposing new API properties.

Notes

• Rebased on master after chore(testdata): update Vitocal 300G CU401B sample data #697 (test data) was merged
• Squashed to single commit for cleaner review
• All 61 Vitocal300G tests now in one file (consolidated from separate CU401B file)

Test plan

• 61 tests in test_Vitocal300G.py covering all new methods
• 16 tests in test_Vitocal250A.py for heating rod power consumption summary
• Updated ignore list in test_TestForMissingProperties.py
• All 563 tests pass
• Ruff passes

[lackas]

Thanks for flagging this! Same issue as in #688 - my device exposes both heating.buffer.* and heating.bufferCylinder.* paths with identical values, so I added a fallback without realizing heating.buffer.* is deprecated.

Removed the fallback and reverted to using only bufferCylinder in bd628a1.

[CFenner]

Please separate the PR into dedicated PRs for:

• heating rod
• cooling circuit
• heating circuit
• COP
• compressors
• etc

Also consider adding the testate in a dedicated PR upfront.

Sorry, this is to much to review.

[lackas]

Thanks for the feedback @CFenner!

Changes made:

• Split test data into separate PR chore(testdata): update Vitocal 300G CU401B sample data #697
• Renamed getTemperature → getTargetTemperature and getTemperatureUnit → getTargetTemperatureUnit as suggested

Converted to draft until #697 is merged (tests depend on that data).

---

Review guide for the remaining ~365 lines of code changes:

The changes are grouped into repetitive boilerplate patterns. Here's a quick overview:

Group	Methods	Pattern
COP metrics	5	getCoefficientOfPerformance*() - simple getters from heating.cop.*
Heating rod summary	14	getHeatingRodPowerConsumptionSummary*() - getters from heating.heatingRod.power.consumption.summary.*
Heating rod runtime	3	getHeatingRodRuntimeLevel*() - getters from heating.heatingRod.runtime
Refrigerant sensors	10	get*Pressure(), get*Temperature() - getters from heating.sensors.*
ECU runtime	2	getMainECURuntime*()
Configuration	7	getConfiguration*() - getters from heating.configuration.*
Primary circuit pump	2	getPrimaryCircuitPumpRotation*()
Circuit target temp	2	getTargetTemperature*() on HeatingCircuit

Non-boilerplate changes:

1. Compressor load class fallback (getHoursLoadClass1-5): Some devices expose load class stats under statistics.load instead of statistics. Added fallback to try both paths.

2. Compressor power/modulation (4 methods): New getters for getPower(), getModulation() on Compressor class.

3. CoolingCircuit class (new): Detection logic for available cooling circuits + getType(), getReverseActive() methods.

---

I'm happy to split this further if you prefer. That said, my concern is that splitting into many small PRs might actually increase the review burden, and these features only provide full Vitocal 300G support when merged together. But I appreciate your time reviewing this and am glad to support your efforts however works best for you.

[lackas]

Note to self: Once #697 is merged, we can remove heating.configuration.dhwHeater from the ignore list in test_TestForMissingProperties.py since this PR implements getConfigurationDHWHeaterApproved() for that property.

[lackas]

While exploring the issue tracker, I noticed this PR addresses several open issues:

• Change in request load classes #650 - Load class path change (the statistics.load fallback)
• Natural cooling #363 - Natural cooling detection (getCircuitTemperature(), CoolingCircuit, cooling COP)
• Feature Request: Power Consumtion of Vitocal 250 #677 - Legacy device support (already in the PR description)

That's quite a few birds with one stone! 🪨🐦

No pressure of course - just thought it might be helpful to know the coverage. Happy to adjust anything if needed.

[lackas]

Hi @CFenner,

Just checking in on this PR. Is there anything I can do to help move it forward?

Regarding the split — I hope the review guide in the description helps: 240 of 290 lines are boilerplate getters, leaving only the load class fallback (~35 lines) and CoolingCircuit (~15 lines) as non-trivial code. I'm happy to split if you still prefer, though the individual PRs would only be fully useful once all are merged.

I've been running these features as a custom HA component for over a week now, everything works reliably.

This PR addresses several open issues:

• Change in request load classes #650 (@JeB2022Nov) — Load class path change
• Natural cooling #363 (@jchapuis, @bartcortooms) — Natural cooling detection
• Feature Request: Power Consumtion of Vitocal 250 #677 (@Samekz) — Power consumption for Vitocal 250

Older issues asked for similar features too: #265, #16. There's also a downstream HA Core PR (home-assistant/core#161422) building on this.

Let me know how you'd like to proceed!

[CFenner]

I simply do not have enough time, sorry, but I really appreciate your work, thanks!

I'm fine with the target temp and circulation pump flow addition. In think the cooling circuit could be a or of its own. For some of the other changes, they might be deprecated already (buffer, cop), have to look again.

[lackas]

Thanks for taking the time to review this, @CFenner — I really appreciate the guidance, especially given your limited time. It helps a lot!

I now understand why splitting things up makes sense. The cooling circuit is a distinct feature area, so I've moved it into its own PR: #706.

Other changes based on your feedback:

• Removed getCoefficientOfPerformanceGreen — heating.cop.green is deprecated by the API (removalDate: 2025-12-31, replaced by heating.cop.photovoltaic). Moved it to the deprecated properties list.
• Verified all remaining features against the API's deprecated field in recent device dumps — the other 4 COP endpoints (heating, dhw, cooling, total) are not deprecated.

The buffer paths were already cleaned up in an earlier commit. This PR no longer adds any code targeting deprecated API endpoints.

[CFenner]

Thanks, I think I should have added a test case to avoid that deprecated and removed datapoint ts are added again 😀

There is already an SFP for heating she and total, do you see any for cooling in sour device? Would you mind adding that to be consistent?

[lackas]

Thanks! The deprecation database PR (#707) should help with that going forward.

Regarding COP for cooling — it's already included in this PR: getCoefficientOfPerformanceCooling() at line 304 of PyViCareHeatPump.py, with a test case at line 25 of test_Vitocal300G.py. My device reports a value of 0 for it (no cooling season yet).

Or did you mean something else by "SFP"?

[CFenner]

Yes I meant SFP.

[lackas]

Checked our test data — no device has heating.spf.cooling. Our Vitocal 300G (VitoConnect, v1 API) only exposes heating.cop.*, no SPF at all. The devices with SPF (250A, 222S) are on the newer v2 API and only have heating.spf.{dhw,heating,total} — no cooling variant.

Happy to add getSeasonalPerformanceFactorCooling() if someone provides device data with it, but we can't test without real data.

[CFenner]

HeatingRod is a device component of its own, so using this like this looks a bit odd:

heatingRod1 = ..
heatingRod.GetHeatingRodPowerConsumption()

I would recommend to remove the heatingRod prefix.

[CFenner]

Ah, no it's not, sorry. So next question, would it not make sense to have this as a component like we have for compressors and so on?

[lackas]

You're right, made it a component class now — HeatingRod, consistent with Compressor/Condensor/Inverter. Access via device.heatingRod.getStarts(), device.heatingRod.getPowerConsumptionSummaryDHWCurrentDay(), etc.