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)
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
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;
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?
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.