I have four of these on a zoned heat (gas) / AC system, and have a problem that seems to have started recently. I don’t know if this is a hardware issue, z-wave issue, something in HA…
These will periodically go into a state where they say the HVAC action is “Heating” even when it is clearly not. Here is an example, please note that the state of the thermostat (i.e. mode) is off.
I had previously left these in auto and adjusted the low/high set point, and I thought maybe that was working incorrectly so I started turning them off and on (hvac_mode=off). One of them still says “Heating”. Actually three of them did, but after turning hvac_mode off/auto/cool/heat (from the thermostat itself) a few times they worked OK, this fourth did not.
It does not seem to be a HA thing per se, if I go into the zwave setup it shows this:
So that’s consistent with the attribute of the entity. On this one I’ve turned it through all modes without the Heating going away. Even with mode = cool it says “Heating”. The set point is not calling for heat or cool by the way.
My main question is whether this seems likely to be some software glitch and I should be checking a different attribute?
Secondarily, if something is broken – what? The thermostat, or could this be the zone controller and/or furnace (which is inaccessible (to me) in the attic).
Some more context. I’ve power cycled the furnace/air-handler as well as AC, no change, “heating” persists.
I’ve power cycled the T6 including removing the batteries.
I swapped two of the T6’s, the one saying heating with one showing idle. The problem remained with the T6, so it would not appear to be a signal coming from the system but something in the thermostat or Zwave stuff.
Click the “Refresh” button in the header of the Thermostat Operating State panel, it will query the device for the current sensor values. If the value persists, it means the device is reporting the value incorrectly. You can monitor the driver debug logs to see how the value is reported. https://zwave-js.github.io/zwave-js-ui/#/troubleshooting/generating-logs?id=driver-logs
If the value is corrected, then it means the device is not properly updating state.
The driver logs are fairly clear but I went well back in time and never see it sending something that corresponds to operating state, at least nothing that said heating. The last one was this:
I need to run the refresh again with more attention to exact time to separate it out, but nothing about the state, the state was hours earlier.
I’m confused then from the log, that first one I posted looks like the controller sent a request for operating state? That’s just a guess from the CNTRLR followed by what appears to be a response including the state.
I’m going to update the rPi that runs zwavejs (and -ui), then upgrade that docker (it’s one version behind I think), just to see if anything changes, then will try a refresh with more careful timing. I have 27 devices so it’s a busy log. More in a bit.
There’s nothing in your screenshot that indicates the controller made that request. The log is truncated so it’s not possible to see from my POV. It could just be the device reporting it the change once the heater has turned on, which would be normal. The device is reporting Heating, if that conflicts with what you see in real life, the problem is with your device.
OK, updated rPi’s linux, updated zwavejs-ui, did a refresh just as the clock rolled to 18:49:00 UTC. Filtered a bit with grep with -A10 so there is some extraneous stuff in there but mostly its responses. I don’t see the state updated anywhere.
2025-01-30T18:49:11.217Z CNTRLR » [Node 005] querying current thermostat mode...
2025-01-30T18:49:11.408Z DRIVER one or more queues busy
2025-01-30T18:49:11.428Z SERIAL » 0x011c00a9000100050e9f031800261edadedea3636e273325000000004ff6 (30 bytes)
2025-01-30T18:49:11.431Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 79
└─[Security2CCMessageEncapsulation]
│ sequence number: 24
└─[ThermostatModeCCGet]
2025-01-30T18:49:11.440Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:11.444Z SERIAL « 0x010401a90152 (6 bytes)
2025-01-30T18:49:11.454Z SERIAL » [ACK] (0x06)
2025-01-30T18:49:11.460Z DRIVER « [RES] [SendDataBridge]
--
2025-01-30T18:49:11.512Z CNTRLR [Node 005] [~] [Thermostat Mode] mode: 0 => 0 [Endpoint 0]
2025-01-30T18:49:11.523Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 43
│ security class: S2_Authenticated
└─[ThermostatModeCCReport]
mode: Off
2025-01-30T18:49:11.530Z CNTRLR « [Node 005] received current thermostat mode: Off
2025-01-30T18:49:11.539Z CNTRLR » [Node 005] querying current value of setpoint Heating...
2025-01-30T18:49:11.737Z SERIAL » 0x011d00a9000100050f9f0319005ec54f365b53f5562dbf86250000000050ed (31 bytes)
2025-01-30T18:49:11.741Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 80
└─[Security2CCMessageEncapsulation]
│ sequence number: 25
└─[ThermostatSetpointCCGet]
setpoint type: Heating
2025-01-30T18:49:11.759Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:11.765Z SERIAL « 0x010401a90152 (6 bytes)
2025-01-30T18:49:11.768Z SERIAL » [ACK] (0x06)
--
2025-01-30T18:49:11.861Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpoint[1]: 60 => 60 [Endpoint 0]
2025-01-30T18:49:11.878Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpointScale[1]: [Endpoint 0] [internal]
1 => 1
2025-01-30T18:49:11.883Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 44
│ security class: S2_Authenticated
└─[ThermostatSetpointCCReport]
setpoint type: Heating
value: 60 °F
2025-01-30T18:49:11.889Z CNTRLR « [Node 005] received current value of setpoint Heating: 60 °F
2025-01-30T18:49:11.891Z CNTRLR » [Node 005] querying current value of setpoint Cooling...
2025-01-30T18:49:11.935Z SERIAL » 0x011d00a9000100050f9f031a003053000668a6308267f86f2500000000515b (31 bytes)
2025-01-30T18:49:11.939Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 81
└─[Security2CCMessageEncapsulation]
│ sequence number: 26
└─[ThermostatSetpointCCGet]
setpoint type: Cooling
2025-01-30T18:49:11.968Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:11.975Z SERIAL « 0x010401a90152 (6 bytes)
2025-01-30T18:49:11.978Z SERIAL » [ACK] (0x06)
--
2025-01-30T18:49:12.061Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpoint[2]: 85 => 85 [Endpoint 0]
2025-01-30T18:49:12.075Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpointScale[2]: [Endpoint 0] [internal]
1 => 1
2025-01-30T18:49:12.078Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 45
│ security class: S2_Authenticated
└─[ThermostatSetpointCCReport]
setpoint type: Cooling
value: 85 °F
2025-01-30T18:49:12.091Z CNTRLR « [Node 005] received current value of setpoint Cooling: 85 °F
2025-01-30T18:49:12.093Z CNTRLR » [Node 005] querying current value of setpoint Energy Save Heating...
2025-01-30T18:49:12.114Z SERIAL » 0x011d00a9000100050f9f031b00e13783d09ee7e0341277b525000000005248 (31 bytes)
2025-01-30T18:49:12.117Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 82
└─[Security2CCMessageEncapsulation]
│ sequence number: 27
└─[ThermostatSetpointCCGet]
setpoint type: Energy Save Heating
2025-01-30T18:49:12.188Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:12.196Z SERIAL « 0x010401a90152 (6 bytes)
2025-01-30T18:49:12.200Z SERIAL » [ACK] (0x06)
--
2025-01-30T18:49:12.264Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpoint[11]: 62 => 62 [Endpoint 0]
2025-01-30T18:49:12.277Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpointScale[11] [Endpoint 0] [internal]
: 1 => 1
2025-01-30T18:49:12.280Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 46
│ security class: S2_Authenticated
└─[ThermostatSetpointCCReport]
setpoint type: Energy Save Heating
value: 62 °F
2025-01-30T18:49:12.284Z CNTRLR « [Node 005] received current value of setpoint Energy Save Heating: 62 °F
2025-01-30T18:49:12.286Z CNTRLR » [Node 005] querying current value of setpoint Energy Save Cooling...
2025-01-30T18:49:12.311Z SERIAL » 0x011d00a9000100050f9f031c006268c5b8f8aeda15e51a61250000000053c6 (31 bytes)
2025-01-30T18:49:12.313Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 83
└─[Security2CCMessageEncapsulation]
│ sequence number: 28
└─[ThermostatSetpointCCGet]
setpoint type: Energy Save Cooling
2025-01-30T18:49:12.329Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:12.333Z SERIAL « 0x010401a90152 (6 bytes)
2025-01-30T18:49:12.335Z SERIAL » [ACK] (0x06)
--
2025-01-30T18:49:12.377Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpoint[12]: 85 => 85 [Endpoint 0]
2025-01-30T18:49:12.392Z CNTRLR [Node 005] [~] [Thermostat Setpoint] setpointScale[12] [Endpoint 0] [internal]
: 1 => 1
2025-01-30T18:49:12.395Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 47
│ security class: S2_Authenticated
└─[ThermostatSetpointCCReport]
setpoint type: Energy Save Cooling
value: 85 °F
2025-01-30T18:49:12.398Z CNTRLR « [Node 005] received current value of setpoint Energy Save Cooling: 85 °F
2025-01-30T18:49:12.405Z CNTRLR » [Node 005] querying Air temperature sensor reading...
2025-01-30T18:49:12.412Z CNTRLR [Node 005] No scale preference for sensor type 1, using the last-used scale 1
2025-01-30T18:49:12.493Z SERIAL » 0x011e00a900010005109f031d001891a06199e4bb1363837ddb25000000005477 (32 bytes)
2025-01-30T18:49:12.497Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 84
└─[Security2CCMessageEncapsulation]
│ sequence number: 29
└─[MultilevelSensorCCGet]
sensor type: Air temperature
scale: Fahrenheit
2025-01-30T18:49:12.523Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:12.527Z SERIAL « 0x010401a90152 (6 bytes)
--
2025-01-30T18:49:12.574Z CNTRLR [Node 005] [Multilevel Sensor] Air temperature: metadata updated [Endpoint 0]
2025-01-30T18:49:12.585Z CNTRLR [Node 005] [~] [Multilevel Sensor] Air temperature: 67 => 67 [Endpoint 0]
2025-01-30T18:49:12.594Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 48
│ security class: S2_Authenticated
└─[MultilevelSensorCCReport]
sensor type: Air temperature
scale: Fahrenheit
value: 67
2025-01-30T18:49:12.600Z CNTRLR « [Node 005] received current Air temperature sensor reading: 67 °F
2025-01-30T18:49:12.601Z CNTRLR » [Node 005] querying Humidity sensor reading...
2025-01-30T18:49:12.603Z CNTRLR [Node 005] No scale preference for sensor type 5, using the last-used scale 0
2025-01-30T18:49:12.621Z SERIAL » 0x011e00a900010005109f031e00106b42a1a2be9a6b81433ece250000000055e9 (32 bytes)
2025-01-30T18:49:12.624Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 85
└─[Security2CCMessageEncapsulation]
│ sequence number: 30
└─[MultilevelSensorCCGet]
sensor type: Humidity
scale: Percentage value
2025-01-30T18:49:12.643Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:12.648Z SERIAL « 0x010401a90152 (6 bytes)
--
2025-01-30T18:49:12.697Z CNTRLR [Node 005] [Multilevel Sensor] Humidity: metadata updated [Endpoint 0]
2025-01-30T18:49:12.706Z CNTRLR [Node 005] [~] [Multilevel Sensor] Humidity: 38 => 38 [Endpoint 0]
2025-01-30T18:49:12.714Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 49
│ security class: S2_Authenticated
└─[MultilevelSensorCCReport]
sensor type: Humidity
scale: Percentage value
value: 38
2025-01-30T18:49:12.718Z CNTRLR « [Node 005] received current Humidity sensor reading: 38 %
2025-01-30T18:49:12.721Z CNTRLR » [Node 005] querying battery status...
2025-01-30T18:49:12.763Z SERIAL » 0x011c00a9000100050e9f031f00cac16fcf44254558431f2500000000563b (30 bytes)
2025-01-30T18:49:12.766Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 86
└─[Security2CCMessageEncapsulation]
│ sequence number: 31
└─[BatteryCCGet]
2025-01-30T18:49:12.784Z SERIAL « [ACK] (0x06)
2025-01-30T18:49:12.790Z SERIAL « 0x010401a90152 (6 bytes)
2025-01-30T18:49:12.793Z SERIAL » [ACK] (0x06)
2025-01-30T18:49:12.801Z DRIVER « [RES] [SendDataBridge]
--
2025-01-30T18:49:12.952Z CNTRLR [Node 005] [~] [Battery] isLow: false => false [Endpoint 0]
2025-01-30T18:49:12.962Z CNTRLR [Node 005] [~] [Battery] level: 95 => 95 [Endpoint 0]
2025-01-30T18:49:12.974Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 50
│ security class: S2_Authenticated
└─[BatteryCCReport]
level: 95
is low: false
2025-01-30T18:49:12.978Z CNTRLR « [Node 005] received response for battery information:
level: 95
2025-01-30T18:49:13.000Z DRIVER all queues idle
I’m not sure what you’re refreshing exactly. It should just be the Thermostat Operating State, which is a single value. There shouldn’t be so many commands for this.
No, I don’t think you should. Whatever being reported from z-wave should show up in HA.
And based on the screen dumps in your first post, looks like this specific z-wave thermostat is reporting “Heating”, so your HA is picking that up correctly, based on what the T6 (via z-wave) is telling HA.
So sounds like there is something going on, somewhere between T6 and z-wave.
Just an idea: Have you considered excluding the T6 from z-wave js ui, and re-include again? Could it be something due to incomplete interview?
I would expect that to work too, just with all the extra noise. If that’s not working properly, you’ll need to get assistance from https://github.com/zwave-js/zwave-js-ui.
That’s really impossible to answer from here. Could be any of those, or even that your ZUI was offline during that time.
If you do implement that with the refresh_value service, be sure to set attribute refresh_all_values: true and use the climate entity so it includes the operating state, but this includes everything else related to that entity too (so extra noise). ZUI itself also has the ability to do polling in its own configuration, so you can just poll the operating state value directly.
I haven’t. I could of course. But all other attributes, both innate (e.g. ambient temp) as well as pushed-down (set points for example) are updating near instantly. So far it’s just been this.
What’s odd about this is this started in the wee hours this morning on three of these at once. The other two reset by just cycling through modes (from their front panel), but not this one.
There was no event I could see this morning - HA was up continually, as was the ZWave box, power was unchanged, heat was turning off and on all night as normal. I run a network monitor as well as SNMP polling of UPS’s, so I would see most glitches (not zwave loss unless it lost the entire device).
Is it critical? I can probably program around it. The NodeRed flow uses the knowledge whether that zone is currently heating (or cooling) to know whether to apply a hysteresis to deciding if it should turn that zone on or off. Because it was incorrectly deemed to be heating, it did the turn-on about 1.8 degrees too hot, then fairly quickly turned off, short-cycling that zone badly but also keeping it too hot. I can rewrite the flow to let the state “Off” (not hvac_action) signal it is idle even if the action says otherwise. But… it makes me worry if I’m missing other attributes or state updates.
The zwave stick (Zooz 800 LR) is in a Raspberry Pi 3B, so it’s running on kind of a wimpy computer. Is there any chance I’m reaching some limit and it’s not keeping up? As things go it’s probably not a large network, but there are a couple dozen devices on it, some probably kind of chatty (most are sensors of various sorts).
Is it a combo stick or a dedicated stick? I’ve noticed with my combo sticks (which I’ve been replacing on my various HA instances) that if either the zwave or the zigbee side are having communication issues with their respective mesh that it can cause the other side of the stick to not respond well (which is a big reason for my working on separating the controllers)
You might consider doing a full system restart of HA to get the controller device to see a power cycle and possibly clear out anything gumming up the firmware. I’ve found that sometimes helps. Alternatively, just do a restart of your ZWave-JS UI add-on which will do a warm restart of the device.
All of that was done with no change in this particular problem, all the way down to restarting the HAOS VM, as well as the rPi and docker. The latter were also power cycled not just restarted.
The only thing that made a difference was doing that refreshs on the inner part of the zwave entry (not the top level). Since the latter is more chatty it made me wonder if I was somehow missing pieces of the update for some reason.
