ZHA with Danfoss TRV - error: 'Failed to call service climate/set_hvac_mode - INVALID_VALUE: 135'

[vaughanharper]

The problem

I had been using a Moes TS0601 Thermostatic Radiator Valve with ZHA, and that worked fine. Now I have installed a Hive UK7004240 TRV (which shows up as 'Danfoss TRV003'), still with ZHA, and I am having two problems: (a) If I click the 'power off' icon for this device, I get this error: Failed to write attribute system_mode=<SystemMode.Off: 0>: <Status.INVALID_VALUE: 135> (b) Home Assistant can read current_temperature and temperature from the TRV, and it can set temperature, but the TRV ignores this setting - it will not turn on or off to set the room to that temperature. But if I manually change temperature, then the TRV will then turn on or off as necessary. Can you advise me as to what I should do, please? Many thanks.

What version of Home Assistant Core has the issue?

core-2023.12.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Zigbee Home Automation

Link to integration documentation on our website

No response

Diagnostics information

config_entry-zha-b05a8a2ca514db10664f6c3f6a2c87d1.json.txt home-assistant_2023-12-28T11-22-11.847Z.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @dmulcahey, @adminiuga, @puddly, @thejulianjes, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `zha` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign zha` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

zha documentation zha source _{^{(message by IssueLinks)}}

[TheJulianJES]

Might be improved once these PRs are merged:

• https://github.com/zigpy/zha-device-handlers/pull/2150
• https://github.com/home-assistant/core/pull/86907

[AllardKatan]

These are two separate issues. The first one is easy: The Danfoss Ally specification tells you switching the device off is not a valid command, this is how they meant it to be: https://assets.danfoss.com/documents/284715/AM375549618098en-000103.pdf. It's always on, but it will open or close the valve to switch the heat on and off. You can't directly control the valve but you can change the setpoint and that will have a similar effect. I know there's someone working on fixing this, iirc it re-program the 'switch off' command to send the command that sets the TRV to the minimum temperature. But if you can change the setpoint in HA you can do this same thing already The second one is a bit puzzling to me. I have ten of these and they all work, both when programmed from HA and when using the knob. How do you conclude it is not heating? By feeling the temperature of the radiator? Can you hear the motor run when you change the setpoint? Or do you also read out the setting of the actuator? You can do that in HA by creating a template sensor, with this line to define the state (replace the obvious with the correct name in your system) state: >- {{ state_attr( "climate_entity_ID_here","pi_heating_demand") }}

[Caius-Bonus]

I have these running with the PRs and can say a few things about it. The algorithm on these devices is a black box to me and I don't think it is very intuitive. The actuation is not only dependent on the temperature of the room, but also on the delta of the previous and new setpoint (i.e. 5 -> 20 degrees Celcius =/= 18 -> 20 degrees Celcius in a room at 16 degrees Celcius). This is with external temperature sensors sending correct information every 5-30 minutes and radiator_covered (prioritize_external_temperature_sensor in the PR) set to true, because the temperature sensor on these is completely useless when the radiator gets hot.

[vaughanharper]

Folks, thanks very much for your responses - all very interesting.

With regard to the question by AllardKatan, it was mainly by listening for the sound of the motor, and feeling the radiator. I have done some more testing: it seems that if I move the control manually, then pi_heating_demand changes more rapidly and more decisively, than if I change the temperature through Home Assistant.

Test 1 For example, I start with current_temperature: 23.6, temperature: 25; pi_heating_demand: 94. Then I manually set the temperature to 7 degrees, and pi_heating_demand immediately drops to 1.

Here is the full set of attributes after that:

hvac_modes: off, heat
min_temp: 5
max_temp: 32
current_temperature: 23.6
temperature: 7
hvac_action: heating
system_mode: [<SystemMode.Heat: 4>]/heat
occupied_heating_setpoint: 700
pi_heating_demand: 1
friendly_name: Danfoss TRV003 new lounge Thermostat
supported_features: 1

Test 2 For the second test, I start with current_temperature: 23.9, temperature: 25; pi_heating_demand: 98. Then, using the Home Assistant dashboard, I set temperature to 7 degrees. pi_heating_demand remains at 98. Then I manually increase the temperature from 7 to 8 degrees, and pi_heating_demand immediately drops to 35.

Here is the full set of attributes at the start of the second test:

hvac_modes: off, heat
min_temp: 5
max_temp: 32
current_temperature: 23.9
temperature: 25
hvac_action: heating
system_mode: [<SystemMode.Heat: 4>]/heat
occupied_heating_setpoint: 2500
pi_heating_demand: 98
friendly_name: Danfoss TRV003 new lounge Thermostat
supported_features: 1

After using the dashboard to change temp to 7 degrees:

current_temperature: 23.9
temperature: 7
hvac_action: heating
system_mode: [<SystemMode.Heat: 4>]/heat
occupied_heating_setpoint: 700
pi_heating_demand: 98

After manually setting it to 8 degrees:

current_temperature: 23.9
temperature: 8
hvac_action: heating
system_mode: [<SystemMode.Heat: 4>]/heat
occupied_heating_setpoint: 800
pi_heating_demand: 35

I have no idea whether this helps, but it's certainly consistent with the algorithm on these devices being a black box!

Many thanks.

[AllardKatan]

@Caius-bonus, Actually, I don't think it is surprising that the temperature you switch from matters for the settings, I assume this is because of the integral part of the PID control algorithm, which 'remembers' for a while after changing the setpoint the time when the difference between the actual temperature and the setpoint was large. It may not be intuitive at first sight but it is very common in control theory and it works if tuned right. The fact you can't switch the control off, but need to set it to a low value is not so handy, since it feeds the algorithm with wrong information. As for the difference between manual and remote setting, I know there are two parameters that can change the reaction time. There is a 'slow' and 'fast' mode (forgot the actual names and I am not at home right now to check), and there is also a numerical factor with a name like 'control algorithm strength' or something of that order. Perhaps changing those can speed up the remote control. However, heating systems are typically quite slow reacting systems and trying to control those with a fast algorithm will lead to instability unless you tune it just right. I think there is some builtin method to tune the PID gains that the TRVs apply automatically, but I don't know what that takes into account. Eg in my case, the water temperature changes with outside temperature because of how my boiler works, so that will throw off the calibration for sure.

[Caius-Bonus]

@AllardKatan, I didn't know that about control theory.

From what I could gather (I also used some of Zigbee2MQTT info as reference), there are 2 methods to change the setpoint as explained here https://assets.danfoss.com/documents/latest/284715/AM375549618098en-000103.pdf under Thermostat Commands 0x201 - 0x40. There is a "Scheduled" change, which is slow and a "Manual" change, which is fast. The Scheduled change is the default change when setting the temperature attribute. The Manual change is the default change when turning the valve. ZHA has mapped the temperature attribute to the Manual change for a while now and this PR keeps the same behaviour. This is because, when manually selecting a temperature, it is expected to behave the same as turning the valve. This does however remove the possibility to have a scheduled change be optimized by the valve. The alternative was doing the same as Zigbee2MQTT does and invent a new attribute and manage that in the quirk, which I didn't really like.

@vaughanharper Another thing that I noticed was that pi_heating_demand isn't immediately reported when changing the setpoint from ZHA. This is however in line with the setting of min interval of 300seconds from danfoss, which takes precedence over the ZHA setting of 30seconds (even though manually turning seems to report it sooner). I determined the reporting was delayed because of hearing the motor turn, but no change in pi_heating_demand.

[vaughanharper]

Thinking about the user requirement, I'd like the TRV to behave the same way whether the temperature is controlled manually or using Home Assistant. If I'm too hot I can turn the control knob down by a few degrees, and the TRV responds immediately. If I turn the temperature down by a few degrees using Home Assistant, I'd like the TRV to react in the same way. It was this difference in behaviour that prompted me to raise this Issue. Many thanks.

[vaughanharper]

There is a Danfoss Ally Feature Catalogue at https://assets.danfoss.com/documents/202524/AU417130778872en-000101.pdf In section 2.1 it speaks about 'Reaction aggressiveness at user interaction', and it says "During a User Interaction (setpoint change by turning the dial or setpoint change via ”SetpointCommand + UI=1”) the motor jumps to a much different position regardless of limitations for battery saving and energy efficiency" So the behaviour that I described above may be attributable to this. The Zigbee2mqtt page on my TRV can be found here: https://www.zigbee2mqtt.io/devices/UK7004240.html and the page on the Danfoss-badged TRV can be found here: https://www.zigbee2mqtt.io/devices/014G2461.html They describe an attribute section "Occupied heating setpoint scheduled (numeric): Scheduled change of the setpoint. Alternative method for changing the setpoint. In the opposite to occupied_heating_setpoint it does not trigger an aggressive response from the actuator. (more suitable for scheduled changes)." So it may be that the ZHA behaviour is controlling the equivalent of 'Occupied heating setpoint scheduled', which therefore results in a non-aggressive response from the actuator.

[Caius-Bonus]

@vaughanharper ZHA already has a quirk right now which does aggressive setpoint setting for: (DANFOSS, "TRV001"), (DANFOSS, "eTRV0100"), (DANFOSS, "eTRV0101"), (DANFOSS, "eTRV0103"), (D5X84YU, "eT093WRO"),

As yours isn't in here, this could explain the slow behaviour. I forgot about this.

My PR, among many other changes, adds support for: (DANFOSS, "TRV003"), (D5X84YU, "eT093WRG"),

Also, these Danfoss TRVs do not support SystemMode.Off and this is a separate issue from the setpoint change. One of the things my PR does is emulate this with Setting the setpoint (aggressively) to 5.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.