Error reasons in automations

[Paul-HomeAssistant]

Hi there,

First of all, thanks for the great work on this integration! It’s been very nice and provides deep insights into the Luxtronik controllers.

I’ve noticed that while the error_reason sensor shows translated names in the UI (thanks to the translation files), the actual state of the entity in Home Assistant remains a numeric code (e.g., 759).

This makes creating useful automations slightly difficult. For example, if the heat pump enters a "Thermal Disinfection (TDI)" error state (Code 759), the user currently needs to manually map these codes in a templates to get a readable notification. Furthermore, some errors like 759 require a "soft reset" before DHW (Domestic Hot Water) production is allowed again, which is critical information for the user.

Would it be possble to do something like:
Entity: sensor.luxtronik_error_reason
State: "Thermal disinfection message"
Attributes:
code: 759
description: "Thermal disinfection could not be completed successfully five times in succession."
remedy: "Check second heat generator configuration and acknowledge the message."
severity: "info" (or warning/error)

Many thx and keep up the good work!

Paul

[kwlorenz]

I have written an alarm message / automation for my heatpump with the alarm code (in my case)

"{{ states.sensor.luxtronik_210117_091_error_reason.attributes.code }}"

and translation using

"{{ state_translated('sensor.luxtronik_210117_091_error_reason') }}"

Perhaps you can try something similar?

KW

[Paul-HomeAssistant]

The thing that looks weird to me is that the value and the attributes of the entity all show the error code. Maybe I missed something somewhere but I would have expected the info that is listed in the manual for those errors would be populated there.

edit:

After looking in sensor_entities_predefined.py it seems that the attributes are just populated with the code:

    descr(
        key=SensorKey.ERROR_REASON,
        luxtronik_key=LC.C0100_ERROR_REASON,
        extra_attributes=(
            attr(SA.TIMESTAMP, LC.C0095_ERROR_TIME),
            attr(SA.CODE, LC.C0100_ERROR_REASON),
            attr(SA.CAUSE, LC.C0100_ERROR_REASON),
            attr(SA.REMEDY, LC.C0100_ERROR_REASON),
        ),
    ),

[rhammen]

Thanks for the detailed report, @Paul-HomeAssistant — and for the workaround, @kwlorenz.

Dug into this and the root cause turned out to be different from what it looked like: the cause/remedy attribute wiring in the integration was actually correct all along — it stores the raw error code so Home Assistant's translation system can localize it, the same mechanism used for the main state. German, Dutch, Polish, and Czech translations already had this fully built out (~74 codes each with real cause/remedy text). English was simply missing the whole translation block, so there was nothing for the UI to translate to and it fell back to showing the raw code — that's why you were seeing duplicated numbers.

Fixed in #685:

• Added the missing English cause/remedy translations for all error codes, transcribed from the official manual (cross-referenced across English/German/Dutch editions to catch a few translation errors along the way)
• Filled in several error codes that were missing entirely (730, 731, 739, 786, 794-807)
• Found and fixed the identical bug in an unrelated sensor (switchoff_reason) while I was at it
• Added an automated check so this class of bug (a locale silently missing translation content that others have) gets caught in CI going forward

state stays numeric (matches how every other coded sensor in this integration behaves, and keeps it stable for automations) — the cause/remedy/code attributes are where the readable text now lives. For a fully translated state string, state_translated() in a template still works as kwlorenz suggested.

Would appreciate a review/test on real hardware once #685 is merged, especially since a couple of the newly-added codes only have best-effort (not manual-sourced) Polish/Czech translations.