Z-Wave Climate validate temperature(s) out of range #123612
Comments
|
Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) climate documentation |
|
I'm having the same issue, my zigbee thermostat supports down to 5c natively, and I've used customize.yaml to set |
|
this got introduced in a913587#diff-14696dfbc0bdc777c176a63e9303d80207ed356388f69621644f03a9304e5e5f reading the code naively, it seems to look for HeatLowerSetptLimit (passing by comment) |
|
I have the same Problem with my 12 Homematic Devices. when opening a window, i set the Temp to 4.5 via Automation. Now the lowest setable Temp is 5 Degress but this don`t switch off the Device. So all my automations are broken.
We have to set Temperatures to lower values, even if they are "out of Range" |
|
@gjohansson-ST Could you please take a look at this. |
|
Which integration? |
Z-wave JS |
|
Hey there @home-assistant/z-wave, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) zwave_js documentation |
|
I'm having the same issues except I'm not using the z-wave integration, it only began occurring after i updated my core os to 2024.8, prior to the update I had no issues so I'm unsure that it has to do with that integeraation |
|
Hi All, This is via Z-Wave JS. Thermostat is Ecolink ZWave Plus Smart Thermostat, The issue also started happening for me after the recent update. No automation in play for me, I simply am unable to adjust the temperature at all using the climate entity. Climate entity: |
|
Same here, different integration. |
|
Word of advice. Unless you report your own issues targeting the correct integration the right people might not see it and therefore not fix it. |
|
Hi All, I found this in the export of the Driver JSON from ZWave JS. A reinterview of the node didn't seem to help. Not clear to me why this would suddenly be of issue though: I've tried setting and resetting the units for both the device and HomeAssistant. There definitely seems to be some confusion converting from C to F or vice versa. Any help here would be very much appreciated - I can no longer set the temperature for the thermostat.
|
|
Adding on here - if anyone with more experience here can point me to the best place to create a dedicated ticket for this, please let me know. Ran a four tests - switching the units (°C or °F) for both the ZWave device and HomeAssistant. Provided the dump of the ZWave Drive JSON and the UI in Home Assistant below. Set points when HA is set to °C & Thermostat is set to °C
============================================================== Set points when HA is set to °C & Thermostat is set to °F
==============================================================
===============================================================
|
MartinHjelmare
changed the title
|
I've taken a look at zwave_js and specifically the Honeywell T6 thermostat - since i have 4 of these and currently use customize to widen the range. The thermostat supports a range of 40-99 F. Here is what I've discovered: a) The T6 thermostat does not report min or max temperatures in it's metadata With the change to climate/init.py to validate the setpoints using the entity reported min and max, you can no longer set the T6 outside of the 45 - 95 range. Here are some solutions which could work - what do you think is the best approach? a) update the climate code to use the customize settings - this seemed like the simplest - this approach however has been rejected in #126924 My thoughts e) will require us to add an unknown amount of device config files. it may be the cleanest approach Thoughts? |
|
I'd recommend opening one issue per device. Different devices will probably require different solutions since the behavior causing the issue isn't the same. This issue is already a mix of different devices and even integrations and therefore the chances are high it will not be solved. |
|
make sense, i'll open one for the T6. Perhaps we should implement a temporary change to not raise a exception and instead create a log entry with the details of what needs to get fixed (and let the setpoint go through) - like we do with deprecations? That will get people back on-line and give us time to sort through the dozens of breakages? |
|
Strictly validating a setpoint using an assumed range due to lack of known capabilities does not seem right. The Z-Wave integration at least will need an escape hatch to fulfill certification requirements (allowing the user to freely define the setpoint value). |
|
@MartinHjelmare This issue isn't about specific devices, but rather the new number validation which conflicts with older Z-Wave devices. As per Z-Wave spec (posted by @AlCalzone in zwave-js/node-zwave-js#7202):
As @AlCalzone mentioned having an assumed range on these devices IMHO isn't the way to go. And why settle on 7-35°C and not liquid water state (1-99°C)? Or why not 4-40°C? What I'm trying to say is that the default range feels pretty arbitrary to me. And doesn't always align with device properties. Before strict validation this wasn't an issue because of customize, but it is now. Fact is that older devices don't report a min/max value as do newer (Z-Wave+) devices. A couple of excerpts from Z-Wave diagnostics: Honeywell T6 (without min/max) (from #128117){
"id": "22-67-0-setpoint-1",
"nodeId": 22,
"toUpdate": false,
"commandClass": 67,
"commandClassName": "Thermostat Setpoint",
"endpoint": 0,
"property": "setpoint",
"propertyName": "setpoint",
"propertyKey": 1,
"propertyKeyName": "Heating",
"type": "number",
"readable": true,
"writeable": true,
"label": "setpoint (property)",
"ccSpecific": {
"setpointType": 1
},
"stateless": false,
"commandClassVersion": 2,
"unit": "°F",
"list": false,
"value": 40,
"lastUpdate": 1727456494361,
"newValue": 40
}Danfoss Popp TRV (without min/max)"19-67-0-setpoint-1": {
"endpoint": 0,
"commandClass": 67,
"commandClassName": "Thermostat Setpoint",
"property": "setpoint",
"propertyKey": 1,
"propertyName": "setpoint",
"propertyKeyName": "Heating",
"ccVersion": 2,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Heating)",
"ccSpecific": {
"setpointType": 1
},
"unit": "\u00b0C",
"stateful": true,
"secret": false
},
"value": 4
}Fibaro The Heat Controller (with min/max)"20-67-1-setpoint-1": {
"endpoint": 1,
"commandClass": 67,
"commandClassName": "Thermostat Setpoint",
"property": "setpoint",
"propertyKey": 1,
"propertyName": "setpoint",
"propertyKeyName": "Heating",
"ccVersion": 3,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Heating)",
"ccSpecific": {
"setpointType": 1
},
"min": 10,
"max": 30,
"unit": "\u00b0C",
"stateful": true,
"secret": false
},
"value": 16.5
}For me this issue has some kind of urgency. It's October now and I'm on the northern hemisphere. My heating system 'partially broke' because I completely rely on Home Assistant. I have a workaround in place, but I still have limited control from the UI and there is currently no solution in sight. For me an ideal middle ground would be to validate if the input setpoint is a valid (floating) number, maybe in liquid water state. Because that would cover almost all devices with a setpoint as far as I can tell. And let the user customize the climate entity in the UI as was previously the case. |
|
Should we open an architectural discussion to determine solutions? I'm happy to fix, but need guidance on which of the half-dozen options we want to do. There's also #128118 - which is about a design flaw in the current setpoint validation. |
|
I already did |
|
Link to the mentioned architectural discussion: home-assistant/architecture#1152. Since it wasn't backlinked, I wasn't aware of the discussion. Thanks @AlCalzone for creating it 😄. I'm fully behind the proposal. |
|
Although I appreciate that the title of this issue is about Z-Wave devices, it is not limited to just these. I have the same issue with a ZigBee climate device and a generic thermostat. I believe it affects all climate devices |
I would recommend to create another issue specifically for your Zigbee coordinator. Either ZHA, deCONZ or Zigbee2MQTT. The implementation and characteristics are probably differ vastly. I thought there wouldn't be an issue for Generic Thermostats but it seems not all configuration options are available for frontend configuration. That means you cannot set the |
|
I'm having same issue with my thermostat - Nortek Security & Control LLC - Z-Wave Plus Thermostat. On latest HA and ZwaveJs. Believe issue with ZwaveJs, no issue in HA when thermostat was paired with Vera Hub. Issue now when thermostat paired with Zooz 800 Series Stick and ZwaveJS. |
I'm suspecting that you aren't experiencing the same, but a similar issue. Maybe even the same as @gloseem above. This device will most likely report it's minimum and maximum temperatures. I suspect as much because it's a Z-Wave Plus device which makes it very unlikely to be Setpoint version 1 or 2. Unlike this issue which is about device that don't report min/max temperatures. |
|
If you're still having a problem on 2024.10.3+, at minimum you're going need to provide some information about your thermostat, such as the product name/model, and the min and max temperatures reported in the States Dev Tools page. A device diagnostic file would be helpful. |
Here is more info : Core 2024.10.4 Thermostat DetailsManufacturer - Nortek Security & Control LLC |
@b0ddu I see that this file is from Z-Wave JS UI and you have MQTT enabled. Are you using MQTT integration with HA, or the Z-Wave integration? This issue only pertains to the Z-Wave integration. If you are using the Z-Wave integration, please provide the Device diagnostic file from HA. If you are using MQTT instead (not recommended), you'll need to go to https://github.com/zwave-js/zwave-js-ui and ask for configurable min/max values to be supported. I can see in the debug text that the MQTT topic is setting min and max to 5 and 40, and the unit is F. That might be the problem. |
|
@kpine - thank you for quick response. |
If you mean "physically move", you don't need to do that, just enable the HA websocket server on the existing installation and connect the integration. https://zwave-js.github.io/zwave-js-ui/#/homeassistant/homeassistant-official |
|
Hi @kpine , Thank you for the quick response. The comment above (quoted here) was posted from the wrong account. The details on my device are above and the behavior has not changed after recent updates to the latest versions. Sorry for the confusion!
|
|
@gloseem I would suggest re-interviewing your device and then attaching the complete HA Device Diagnostic file (see https://www.home-assistant.io/integrations/zwave_js/#network-devices). Based on your earlier comment you are having a different issue than the one reported here. Having up-to-date info would confirm that. |
|
Hi @kpine , Thanks again for the quick response! I ran the reinterview and captured the diagnostic JSON. Attached here. Best Eric |
|
@gloseem Your problem seems to be the same you reported before. Z-Wave JS is reporting wrong values. "30-67-0-setpoint-1": {
"endpoint": 0,
"commandClass": 67,
"commandClassName": "Thermostat Setpoint",
"property": "setpoint",
"propertyKey": 1,
"propertyName": "setpoint",
"propertyKeyName": "Heating",
"ccVersion": 3,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Heating)",
"ccSpecific": {
"setpointType": 1
},
"min": 40,
"max": 96,
"unit": "\u00b0C",
"stateful": true,
"secret": false
},
"value": 20
},Max and Min are reported as 40 and 96, those are likely F values but the metadata says they are C. If you have a debug log of the interview it might show what happened. I think you'll need to report an issue at https://github.com/zwave-js/node-zwave-js/issues/new/choose, including the interview log. See https://zwave-js.github.io/zwave-js-ui/#/troubleshooting/generating-logs?id=driver-logs if you have not enabled driver debug logs. |
The metadata for the setpoint is provided by Z-Wave JS and your HA settings have no influence on its behavior. Either the device reported something wrong, or Z-Wave JS mixed something up. In the ZUI Z-Wave settings you can configure your preferred scales, not sure if that would help in this case or not but you could try it. Either way, I'd think it should work by default w/o the configuration.
|
The problem
After update to 2024.8 it is no longer possible to send temp outside value 7-35 to my Z-wave Danfoss (Popp) TRV.
Popp Wireless Thermostatic Valve TRV | 010101
The TRV does support 4-28 degrees.
I suspect it has something to do with #118649
What version of Home Assistant Core has the issue?
core-2024.8.1
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
Climate
Link to integration documentation on our website
https://www.home-assistant.io/integrations/climate
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
No response
The text was updated successfully, but these errors were encountered: