core
core copied to clipboard
home-assistant
Z-Wave Climate validate temperature(s) out of range
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 https://github.com/home-assistant/core/pull/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?
Logger: homeassistant.components.websocket_api.http.connection
Källa: components/websocket_api/commands.py:283
integration: Home Assistant WebSocket API (dokumentation, ärenden)
Inträffade först: 20:12:38 (5 händelser)
Senast loggade: 20:41:27
[139966371298560] Provided temperature 4.5 is not valid. Accepted range is 7 to 35
[139966371298560] Provided temperature 4.0 is not valid. Accepted range is 7 to 35
[139966362485088] Provided temperature 4.0 is not valid. Accepted range is 7 to 35
[139966371298560] Provided temperature 6.0 is not valid. Accepted range is 7 to 35
Additional information
No response
Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (climate) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of climate can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign climateRemoves the current integration label and assignees on the issue, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
climate documentation climate source (message by IssueLinks)
![home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/97978?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm having the same issue, my zigbee thermostat supports down to 5c natively, and I've used customize.yaml to set min_temp: 3 which has been working well until updating to 2024.8. I now get the error message "Provided temperature 3.0 is not valid. Accepted range is 7.0 to 30.0." when setting it.
I can see that my custom value is being read in correctly, but the validation step doesn't seem to respect it. After looking at the code I did also try customizing _attr_min_temp as a workaround but that didn't help.
this got introduced in https://github.com/home-assistant/core/commit/a913587eb6dff0d5c9a5846d4067ef6974d3e405#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. See first post in this issue.
Hey there @home-assistant/z-wave, mind taking a look at this issue as it has been labeled with an integration (zwave_js) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of zwave_js can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign zwave_jsRemoves the current integration label and assignees on the issue, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
zwave_js documentation zwave_js source (message by IssueLinks)
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, I'm having a very similar issue, except the acceptable range values seem to be in F; everything else is set up in C.
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.
Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:283
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: September 19, 2024 at 9:46:06 PM (5 occurrences)
Last logged: 8:54:56 AM
[547913361024] Provided temperature 22.5 is not valid. Accepted range is 43 to 99
[547913361024] Provided temperature 22.0 is not valid. Accepted range is 43 to 99
[547673744880] Provided temperature 23.5 is not valid. Accepted range is 43 to 99
[548162193008] Provided temperature 23.5 is not valid. Accepted range is 43 to 99
[547803070816] Provided temperature 23.5 is not valid. Accepted range is 43 to 99
Climate entity:
hvac_modes:
- "off"
- heat
- cool
- heat_cool
min_temp: 5
max_temp: 35
fan_modes:
- Auto low
- Low
preset_modes:
- none
- Auxiliary
current_temperature: 22.4
temperature: 23
target_temp_high: null
target_temp_low: null
current_humidity: 44
fan_mode: Auto low
hvac_action: idle
preset_mode: none
fan_state: Running / running low
friendly_name: Greatroom Thermostat
supported_features: 411
Same here, different integration.
Logger: homeassistant.components.automation.agile_prices_high
Source: helpers/script.py:2026
integration: Automation (documentation, issues)
First occurred: 15:30:56 (2 occurrences)
Last logged: 15:30:56
Agile Prices High - reduce HP use: If at step 2: Error executing script. Error for call_service at pos 1: Provided temperature 1.0 is not valid. Accepted range is 7 to 35
Agile Prices High - reduce HP use: Error executing script. Error for if at pos 2: Provided temperature 1.0 is not valid. Accepted range is 7 to 35
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:
{
"property": "setpoint",
"propertyKey": 2,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Cooling)",
"ccSpecific": {
"setpointType": 2
},
"min": 43,
"max": 99,
"unit": "°C"
},
"value": 22,
"timestamp": "2024-09-23T19:28:58.911Z"
},
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
"Thermostat Setpoint": {
"isSupported": true,
"isControlled": false,
"secure": true,
"version": 3,
"values": [
{
"property": "supportedSetpointTypes",
"value": [
1,
2
],
"timestamp": "2024-09-23T19:28:58.086Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 1,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Heating)",
"ccSpecific": {
"setpointType": 1
},
"min": 40,
"max": 96,
"unit": "°C"
},
"value": 16,
"timestamp": "2024-09-23T19:28:58.815Z"
},
{
"property": "setpointScale",
"propertyKey": 1,
"value": 0,
"timestamp": "2024-09-23T19:28:58.819Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 2,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Cooling)",
"ccSpecific": {
"setpointType": 2
},
"min": 43,
"max": 99,
"unit": "°C"
},
"value": 22,
"timestamp": "2024-09-23T22:44:16.709Z"
},
{
"property": "setpointScale",
"propertyKey": 2,
"value": 0,
"timestamp": "2024-09-23T22:44:16.718Z",
"internal": true
},
{
"property": "setpointTypesInterpretation",
"internal": true
}
]
==============================================================
Set points when HA is set to °C & Thermostat is set to °F
"Thermostat Setpoint": {
"isSupported": true,
"isControlled": false,
"secure": true,
"version": 3,
"values": [
{
"property": "supportedSetpointTypes",
"value": [
1,
2
],
"timestamp": "2024-09-23T19:28:58.086Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 1,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Heating)",
"ccSpecific": {
"setpointType": 1
},
"min": 40,
"max": 96,
"unit": "°C"
},
"value": 16,
"timestamp": "2024-09-23T19:28:58.815Z"
},
{
"property": "setpointScale",
"propertyKey": 1,
"value": 0,
"timestamp": "2024-09-23T19:28:58.819Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 2,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Cooling)",
"ccSpecific": {
"setpointType": 2
},
"min": 43,
"max": 99,
"unit": "°C"
},
"value": 22,
"timestamp": "2024-09-23T22:44:16.709Z"
},
{
"property": "setpointScale",
"propertyKey": 2,
"value": 0,
"timestamp": "2024-09-23T22:44:16.718Z",
"internal": true
},
{
"property": "setpointTypesInterpretation",
"internal": true
}
]
==============================================================
3.
Set points when HA is set to °F & Thermostat is set to °F
"Thermostat Setpoint": {
"isSupported": true,
"isControlled": false,
"secure": true,
"version": 3,
"values": [
{
"property": "supportedSetpointTypes",
"value": [
1,
2
],
"timestamp": "2024-09-23T19:28:58.086Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 1,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Heating)",
"ccSpecific": {
"setpointType": 1
},
"min": 40,
"max": 96,
"unit": "°C"
},
"value": 16,
"timestamp": "2024-09-23T19:28:58.815Z"
},
{
"property": "setpointScale",
"propertyKey": 1,
"value": 0,
"timestamp": "2024-09-23T19:28:58.819Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 2,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Cooling)",
"ccSpecific": {
"setpointType": 2
},
"min": 43,
"max": 99,
"unit": "°C"
},
"value": 22,
"timestamp": "2024-09-23T22:44:16.709Z"
},
{
"property": "setpointScale",
"propertyKey": 2,
"value": 0,
"timestamp": "2024-09-23T22:44:16.718Z",
"internal": true
},
{
"property": "setpointTypesInterpretation",
"internal": true
}
]
=============================================================== 4. Set points when HA is set to °F & Thermostat is set to °C
"Thermostat Setpoint": {
"isSupported": true,
"isControlled": false,
"secure": true,
"version": 3,
"values": [
{
"property": "supportedSetpointTypes",
"value": [
1,
2
],
"timestamp": "2024-09-23T19:28:58.086Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 1,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Heating)",
"ccSpecific": {
"setpointType": 1
},
"min": 40,
"max": 96,
"unit": "°C"
},
"value": 16,
"timestamp": "2024-09-23T19:28:58.815Z"
},
{
"property": "setpointScale",
"propertyKey": 1,
"value": 0,
"timestamp": "2024-09-23T19:28:58.819Z",
"internal": true
},
{
"property": "setpoint",
"propertyKey": 2,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Cooling)",
"ccSpecific": {
"setpointType": 2
},
"min": 43,
"max": 99,
"unit": "°C"
},
"value": 22,
"timestamp": "2024-09-23T22:44:16.709Z"
},
{
"property": "setpointScale",
"propertyKey": 2,
"value": 0,
"timestamp": "2024-09-23T22:44:16.718Z",
"internal": true
},
{
"property": "setpointTypesInterpretation",
"internal": true
}
]
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 b) Because the thermo does not provide that data, the zwave_js integration defaults the limits to 45F - 95F (e.g. DEFAULT_MIN_TEMP and DEFAULT_MAX_TEMP) c) zwave_js does not validate setpoint limits when the device does not report them d) customize limits really only affected the range the UI would show in the Thermostat UI
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 b) change the Default Limits in zwave_js to return a wider range c) add an attribute to the climate interface to allow the integration to opt out of the setpoint validation (and perform it's own) d) change the DEFAULT_MIN_TEMP and DEFAULT_MAX_TEMP to a wider range e) implement device specific config files in zwave_js to determine the appropriate range for the device type.
My thoughts
e) will require us to add an unknown amount of device config files. it may be the cleanest approach a) was simple, perhaps we need to re-review the decision b) is simple to change (i have this prototype), we just need to pick what they are (32-100F)? d) is also simple to change but has a wide ranging affect c) could work
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 https://github.com/zwave-js/node-zwave-js/discussions/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.
Link to the mentioned architectural discussion: https://github.com/home-assistant/architecture/discussions/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
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 min_temp and max_temp attributes from the UI configuration. IMHO that would be an issue on it's own.
I'm having same issue with my thermostat - Nortek Security & Control LLC - Z-Wave Plus Thermostat. On latest HA and ZwaveJs. Temperature not valid, Accepted range error.
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 having same issue with my thermostat - Nortek Security & Control LLC - Z-Wave Plus Thermostat. On latest HA and ZwaveJs.
What is "latest" for you? This should be fixed for most people in 2024.10.3.
https://github.com/home-assistant/core/pull/128543
I'm having same issue with my thermostat - Nortek Security & Control LLC - Z-Wave Plus Thermostat. On latest HA and ZwaveJs. Temperature not valid, Accepted range error.
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.
I'm having same issue with my thermostat - Nortek Security & Control LLC - Z-Wave Plus Thermostat. On latest HA and ZwaveJs. Temperature not valid, Accepted range error.
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.
Here is more info :
Core 2024.10.4 Supervisor 2024.10.3 Operating System Debian 6.1.112-1 12 Frontend 20241002.4 Separate ZWave JS - v11.13 Instance with Zwave ZST39 LR Stick via mqtt to HASS
Thermostat Details
Manufacturer - Nortek Security & Control LLC Product Code - GoControl GC-TBZ48 Attached debug info from ZwaveJS thermostat-debug-info.txt
Attached debug info from ZwaveJS thermostat-debug-info.txt
@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.