Climate.set_temperature fails to change target_temp_low, but target_temp_high works fine

Synopsis:

  • When I do a “service: climate.set_temperature” call (see example below) the target_temp_low will change, and then ~6.5 seconds later (according to the MQTT log), it reverts back to what it was previously.
  • The target_temp_high does not have this problem. It changes and stays at the new value.
  • This problem also does not happen if I manually change the value in the device thermostat card.
  • This problem also does not happen if I manually change the value in the ZWave-JS UI.
  • New thermostat. Removed malfunctioning Honeywell T6 Pro Z-Wave. Installed 2Gig CT100.
    This problem was not happening with the Honeywell.
  • I named the CT100 identical to the Honeywell to simplify not having to update all the scripts/automations.
  • HA service call: Problem
    HA Thermostat card: Not Problem
    Z-Wave JS UI: Not Problem

{sigh}
Long version:

I decided to replace the POS Honeywell T6 Pro that would randomly spew errors, saying it needed to be sent back to Honeywell for service. When the T6 was functioning and talking on ZWave correctly, it worked ok. I could update the target temperatures without any problems.

Now, with the CT100 installed, I’m running into problems where I can’t consistently set the target_temp_low. I say that I can’t consistently set it because I see it being set correctly, and then ~6.5 seconds later, another command appears to revert the value back to what it was previously. But this problem only happens if I issue the change like this;

(using the Dev Tools Actions tab to eliminate all other possible problems)

service: climate.set_temperature
data:
  hvac_mode: heat_cool
  target_temp_low: 62
  target_temp_high: 79
target:
  entity_id: climate.home_thermostat

Issuing that command and watching both the Z-Wave JS UI and MQTT Explorer, I see the values do this;

0:00:00  target_temp_low = old value -> new value
         target_temp_high = old_value -> new value
0:00:06  target_temp_low = new value -> old value
         target_temp_high = new value -> new value (no change)

However, if I use the Thermostat Card to make the change, I see this;

0:00:00  target_temp_low = old value -> new value
         target_temp_high = old_value -> new value
0:00:06  target_temp_low = new value -> new value (no change)
         target_temp_high = new value -> new value (no change)

The value change always gets sent twice. It’s just that if I change the value via the climate.set_temperature service, the old value always gets reverted back.

HA core: 2024.11.3
HA Frontend: 20241106.2
zwave-js-ui: 9.27.2.b0ade31
zwave-js: 14.3.2

Help?

So it works from the thermostat card but not from the action?

Correct. But only for target_low_temp. The target_high_temp works from both.

Ok, I’ve got further data points and a workaround. If I strip out the ‘hvac_mode’ from the service call, I can get the target_temp_low to change and stay fixed at the new value.

This works to change both the target_temp_low and target_temp_high successfully;

service: climate.set_temperature
data:
  target_temp_low: 62
  target_temp_high: 77
entity_id: climate.home_thermostat

This will only changes target_temp_high successfully;

service: climate.set_temperature
data:
  hvac_mode: heat_cool
  target_temp_low: 62
  target_temp_high: 77
entity_id: climate.home_thermostat

This fails completely (as expected);

service: climate.set_temperature
data:
  hvac_mode: heat_cool
entity_id: climate.home_thermostat

The order of the lines does not appear to make any difference (long shot, but just FYI).

Debug Logs from HA:
Working log: https://drive.google.com/file/d/1GnfIM_0MD3-PcMMns1q-mKsr16UvgsbW/view?usp=drive_link

Broken log: https://drive.google.com/file/d/1GxASHfQV9Dxs1735zXsKCNEgiQFcNBKf/view?usp=drive_link

Look at the ZUI driver debug logs. It may be setting all three parameters correctly, but the thermostat might not apply them. Removing the hvac mode might allow this to work properly. I have a CT32 that has a similar problem, setting too many values at nearly the same time doesn’t work reliably.

There is a specific service call to set hvac_mode. Does that work reliably?

There is a specific service call to set hvac_mode. Does that work reliably?
Setting the hvac_mode has never been a problem. As I said above, the hvac_mode without a target_temp_high and target_temp_low was expected to fail. (I only added it as a data point)

Yes, the climate.set_hvac_mode call works successfully. But that doesn’t do anything to solve the problem I describe, which is setting the temperature.

The more I debug this (when it’s not 3am), the more I believe this to be a Z-Wave race condition. Z-Wave JS is pumping out all three commands (hvac_mode, target_temp_low, target_temp_high, in that order), and the thermostat just can’t keep up. So, while it’s reacting to the first command (hvac_mode), the second command (target_temp_low) blows right by it. But then it’s caught up and handles the third command (target_temp_high) by the time it comes through.

Changing these values via the thermostat card works because it only changes one value at a time.

Although issuing the climate.set_temperature requires setting two values at the same time (target_temp_low and target_temp_high). And for some reason, that doesn’t hit the race condition. Maybe the thermostat takes longer to handle the hvac_mode change? {shrug} I’m running with this theory for the time being.