Create a CoP Sensor

[BenPru]

With this native historic values (#187 ) I can create a CoP Sensor with also statistic attributes.

[AJediIAm]

A COP would be a better as a blueprint instead of an enhancement to the integration. I'll try to gather the documentation for this and publish an example.

[rhammen]

@AJediIAm I'd like to re-open this feature request.
I think it would be a great enhancement to the integration to have COP sensors for Heating, DHW, and Cooling. I think it is something many users would appreciate, and saves everybody from having to re-invent the wheel again.

My current preference would be to include it in the integration in some form at some point in time, but let's take things step by step.
You suggested above that a blueprint could be a good way to start. I think that makes a lot of sense.
Additionally, in #325 already some ideas have been shared.

The blueprint should at least enable CoP sensors based on the available Luxtronik sensors; an option for users to pick other utility-meter like sensors like Shelly would be a bonus.
I'd like to able to track the CoP over time (eg per week and/or month, like in one of the examples in #325 )

Would you be willing to take the lead in creating such a blueprint that makes it easy for users to add COP sensors?

[AJediIAm]

This issue matches my goal to improve the documentation.

I'll start with the code for the automation and then look into making it a real blueprint. The code can be stored as code with a section in the documentation on how to use it.

[siedi]

With the latest firmware update (I think it was 3.89.x or so), my alpha innotec got the sensor.luxtronik2_current_power_consumption exposed. I have no external power measurement with KNX or shelly. Just created a helper sensor (template based) with the following code:

{% set q = states('sensor.luxtronik2_current_heat_output') | int %}
{% set w = states('sensor.luxtronik2_current_power_consumption') | int %}
{% if q >= 0 and w > 0 %}
{{ (q / w) | round(2) }}
{% else %}
0
{% endif %}

At least I got some reasonable values for the COP. Works for me. Could be easily created into the integration directly of course.

[AJediIAm]

Can the COP sensors be moved from "sensors" to "diagnostics"?

The DHW COP is only active for a short amount of time. To provide a more meaningful metric, the average COP over the last 24 hours could be taken. I have a template sensor for the 24 hour average COP and it's a useful metric.

[rhammen]

Thanks @AJediIAm — my take on both points:

On the 24h average: I'd like to try the statistics integration route first.

Rather than baking a fixed window into the integration, the HA statistics integration lets each user derive whatever averaging window they want — daily, weekly, monthly, yearly — from the existing COP sensors, without us picking one for them.

This works well precisely because the instantaneous COP sensors go unavailable when the pump isn't serving that circuit: statistics skips those samples, so the result is the average COP while actually running, which is the meaningful number and directly addresses your "DHW COP is only active for a short amount of time" point.

Both COP sensors also already carry state_class: measurement, so Home Assistant records long-term statistics for them automatically — a Statistics card with mean per hour/day/month needs no helper at all.

I'm still considering adding cop_heating_24h, cop_heating_7d, cop_heating_30d (and the DHW equivalents) as real entities later. But since the preferred averaging window looks quite user-dependent, I'd rather first see how users get on with the statistics approach before we commit to a fixed set. So my preference for now is to document this process properly — a section in ADVANCED_FEATURES.md, next to the existing COP documentation.

@AJediIAm, would you be willing to share your 24h-average template sensor? If a statistics helper can achieve the same thing, I'd rather document that (it's UI-configurable, no YAML), but your config is a useful starting point either way.

On moving the COP sensors to diagnostics: not convinced yet.

Given the above, and since the sensor going unavailable outside its operating mode is reasonable and deliberate behaviour, I don't think re-categorising is the right fix — COP is a performance metric rather than a diagnostic one.

Two alternatives I'd rather explore:

• Rename them to make clear they are an instantaneous calculation (e.g. "Instantaneous COP" / "Momentary COP"), so the availability gaps are self-explanatory. This only changes the display name, not entity IDs, so it's non-breaking for existing dashboards.
• Improve the documentation first on using the statistics integration to get the averaged view — which may remove the underlying need entirely.

Let me know what you think.

[AJediIAm]

I'm actually using statistics sensors for energy input and heat output and calculate the COP based in those. Calculating the COP first and using the statistics sensor is even better.