Closed gsemet closed 3 years ago
Hey there @home-assistant/z-wave, mind taking a look at this issue as its been labeled with an integration (zwave_js
) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)
@gsemet please create a new dump with core-2021.3.0 of your Z-Wave network and upload the dump as a text file here. I'm looking at addressing part of this issue but your old dump is not compatible anymore with our latest schema version.
Thanks!
Here what I have:
The dump above is for the SRT322. That's a different device, right?
Not, the transmitter is the same. I don't know why its name has changed, I can not reset it.
SECURE SRT322-5 Z‑Wave+ (Gen5) = Pack Thermostat transmitter SRT321-5 + Thermostat receiver Z-Wave+ SSR303-5
This is the pack I brought indeed, but I always saw reference to SRT321
Ok, thanks.
Looking at the dump, there are no setpoints reported, hence the missing support for setting temperature currently. I'll open a PR to fix the attribute error for unit. It will not fix the missing setpoints of course.
@kpine do you know anything about this device?
I haven't seen this before. The first question is if this device is really supposed to have a setpoint or not. Is this just an SRT321 with an addon? I know the SRT321 supports a Heating setpoint value. If this is the same, then I would submit an issue to node-zwave-js with the interview logs, maybe the command class needs to be added manually?
The device is the same old SRT321 that is a thermostat (and use to work as a classic climate entity on ozw). I did a patch for supporting the climate entity now it is seen but the setpoint seems to be misconfigured
Ohhhh my mistake it is the receiver ! I’ll repost the transmitter ASAP !
OK, this is probably related to the changes to the discovery schema, as thermostat mode climate entities used to be based on Generic and Specific types. Maybe the Thermostat Mode discovery needs to require at least one setpoint value. A climate entity probably shouldn't be created for this receiver.
Here the real thermotat transmitter SRT321
That one should be supported. Do you have two climate entities?
Not sure if this helps, but I saw both my SR321 and another thermostat input device fall off after upgrading Z-Wave JS from 0.1.07 (iirc) to 0.1.10. Other attributes (temp etc.) are still relayed, but not the thermostat entity.
I only have one climate and it displays the right temperature and setpoint value. But as soon as I try to change I see this error in the log
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/core.py", line 1504, in catch_exceptions
await coro_or_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/zwave_js/climate.py", line 401, in async_set_hvac_mode
raise ValueError(
ValueError: Thermostat climate.main_heater_thermostat_main does not support setting a mode
Which node ID is the climate entity associated with, 19 or 20?
Sorry for the misunderstanding
Node 19 is the thermostat transmitter SRT321
node 20 is the receiver SSR303-5, that seems to be seen as SRT322.
Sure, I understand that part, my question is to determine which node HA is creating the climate entity for. If you go to the Devices page, you can select one of the nodes (each node is a device), and it will list the node ID plus its entities. It sounds like you only have one climate entity, so which of those nodes is it assigned to?
Node 19
Not sure if this helps, but I saw both my SR321 and another thermostat input device fall off after upgrading Z-Wave JS from 0.1.07 (iirc) to 0.1.10. Other attributes (temp etc.) are still relayed, but not the thermostat entity.
@GreatAlbatross I think this is a different problem. HA 2021.2.X is not compatible with the newer versions of the server, with regards to thermostats and RGB devices. So if you upgrade the server (e.g. zwave-js addon) but stay at HA Core 2021.2.3, you won't see a thermostat.
@gsemet Can you clarify, was the thermostat working in 2021.2, and is now broken in 2021.3.0, or is this the first time you've tried it?
Not the climate never worked on zwavejs. I just switched to zwavejs2mqtt. The climate was working on ozw.
On 2021.2.x, the thermostat SRT321 devices only added 3 entities out of 4 (see #46570), the climate was missing.
I did this patch I guess that helped the setpoint command to be translated into climate entity. Read is ok (both temperature sensor and the setpoint value) but changing the setpoint value from HA fails.
Could it comes from this utf-8 character for the setpoint property?
{
"endpoint": 0,
"commandClass": 67,
"commandClassName": "Thermostat Setpoint",
"property": "setpoint",
"propertyKey": 1,
"propertyName": "setpoint",
"propertyKeyName": "Heating",
"ccVersion": 1,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"unit": "\u00b0C", # <===== weird character here (or it is a copy paste issue)
"ccSpecific": {
"setpointType": 1
}
},
which differs from some unit test I can see.
Looks like this condition is not met so self._unit_value
is None, which lead to this exception:
File "/usr/src/homeassistant/homeassistant/components/zwave_js/climate.py", line 218, in temperature_unit
if "f" in self._unit_value.metadata.unit.lower():
AttributeError: 'NoneType' object has no attribute 'metadata'
Any news for this issue ? This is still a bit annoying not to be able to change the setpoint value from HA, and I am sure it is not a big issue, just I don’t know how to help
The AttributeError was fixed in release core-2021.3.1.
The unicode degree sign should not be a problem.
Ok I do not have the attribute error indeed.
But still this issue:
Last logged: 07:30:00
Error executing service: <ServiceCall climate.set_hvac_mode (c:a3cff9948165c1d4c674e142c9165749): hvac_mode=heat, entity_id=['climate.main_heater_thermostat_main']>
Error executing service: <ServiceCall climate.set_hvac_mode (c:25f07ba8e5b75d8fc8091c70806d385c): hvac_mode=heat, entity_id=['climate.main_heater_thermostat_main']>
Error executing service: <ServiceCall climate.set_hvac_mode (c:b43f9deb1820b0665a4450332246a216): hvac_mode=heat, entity_id=['climate.main_heater_thermostat_main']>
Error executing service: <ServiceCall climate.set_hvac_mode (c:c949ff875ab670d468b10edfde57a6d6): hvac_mode=heat, entity_id=['climate.main_heater_thermostat_main']>
Error executing service: <ServiceCall climate.set_hvac_mode (c:e1269a79bee09f769e7e604ab3c56f71): hvac_mode=heat, entity_id=['climate.main_heater_thermostat_main']>
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/core.py", line 1504, in catch_exceptions
await coro_or_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/zwave_js/climate.py", line 399, in async_set_hvac_mode
raise ValueError(
ValueError: Thermostat climate.main_heater_thermostat_main does not support setting a mode
Why are you calling the set hvac mode service when you want to change temperature?
I think because the set temperature attribute of the thermostat is not being made available. Similar to gsemet, I'm only getting 4 entities: HVAC, Air Temperature, Battery %, and low battery alert.
So, because the setpoint attribute isn't isolated, we're trying the next best, HVAC, which isn't compatible with the call. Edit: And trying to manually change the setpoint through HVAC does not work, I just attempted.
To change the setpoint temperature you should call the climate.set_temperature
service. Have you tried that?
I think because the set temperature attribute of the thermostat is not being made available. Similar to gsemet, I'm only getting 4 entities: HVAC, Air Temperature, Battery %, and low battery alert.
So, because the setpoint attribute isn't isolated, we're trying the next best, HVAC, which isn't compatible with the call. Edit: And trying to manually change the setpoint through HVAC does not work, I just attempted.
When you say HVAC, what do you mean? Do you mean the climate entity?
It is possible there is a disalignment between this line:
# thermostats supporting setpoint only (and thus not mode)
ZWaveDiscoverySchema(
platform="climate",
primary_value=ZWaveValueDiscoverySchema(
command_class={CommandClass.THERMOSTAT_SETPOINT},
property={"setpoint"},
type={"number"},
),
absent_values=[ # mode must not be present to prevent dupes
ZWaveValueDiscoverySchema(
command_class={CommandClass.THERMOSTAT_MODE},
property={"mode"},
type={"number"},
),
],
),
and this command class:
{
"endpoint": 0,
"commandClass": 67,
"commandClassName": "Thermostat Setpoint",
"property": "setpoint",
"propertyKey": 1,
"propertyName": "setpoint",
"propertyKeyName": "Heating",
"ccVersion": 1,
"metadata": {
"type": "number",
"readable": true,
"writeable": true,
"unit": "\u00b0C",
"ccSpecific": {
"setpointType": 1
}
},
"value": 17
},
or maybe because this is evaluated before (and so it thinks it a thermostat with mode (no check on absence of mode
property) but fails when trying to set it) ?
# thermostats supporting mode (and optional setpoint)
ZWaveDiscoverySchema(
platform="climate",
primary_value=ZWaveValueDiscoverySchema(
command_class={CommandClass.THERMOSTAT_MODE},
property={"mode"},
type={"number"},
),
),
I think because the set temperature attribute of the thermostat is not being made available. Similar to gsemet, I'm only getting 4 entities: HVAC, Air Temperature, Battery %, and low battery alert. So, because the setpoint attribute isn't isolated, we're trying the next best, HVAC, which isn't compatible with the call. Edit: And trying to manually change the setpoint through HVAC does not work, I just attempted.
When you say HVAC, what do you mean? Do you mean the climate entity?
Yes, apologies, the one which shoes up like this:
I confirm calling the service climate.set_temperature
works.
I'll have to dig to see where in the logs it shows up, but for me calling against the SR321, it doesn't seem to do anything on that command. But also doesn't give an error.
You ll have to wait for the device to awake, by default it is extremely long.
I've now tested both provided dumps for node 19 and node 20 in unit tests, successfully. Node 19 is able to set temperature and node 20 is able to change mode (between off and heat).
Please let us know if there are any remaining issues.
is there a version that fix this issue already ? newer than "core-2021.3.3" ?
I've now tested my unit test on the master branch which is currently released as core-2021.3.3. That works as well.
What is it that doesn't work for you? Please describe more in detail what you are testing.
Please see my comment here. I still get this error with core-2021.3.3. I am pretty sure it is something like the first ZWaveDiscoverySchema
is matched so the device is thought to be supporting setting the "mode", so it appears with the "Operation" field in its entity UI.
Please see my comment here. I still get this error with core-2021.3.3. I am pretty sure it is something like the first
ZWaveDiscoverySchema
is matched so the device is thought to be supporting setting the "mode", so it appears with the "Operation" field in its entity UI.
The discovery schema for the thermostat is just deciding whether a climate entity is created or not. That schema does not match your node 19 because the node does not have the Thermostat Mode CC, so it has no effect. Whether mode is supported or not is detected when the entity is created. Again, your node does not support the Thermostat Mode CC so that self._current_mode
is None.
Can you clarify what action is giving you the error? Is it the frontend or service call? Clicking the temperature arrow buttons, or what?
I don't think Preset shouldn't even be shown. That is hardcoded in zwave_js, but presets are only assigned for mode thermostats.
Service call works. Setting using the climate widget (yes button + and -) in the front end generates this exception.
That may just be a frontend problem for what the +/- buttons do. Are the buttons supposed to change temperature?
Yes, the buttons set the temperature individually, using the set_temperature
service call (from my understanding of the frontend code). I wonder if the frontend is getting confused and the hvac mode setting is getting triggered?
I tested this on my mode-based thermostat, and clicking on the arrow sends the expected set_temperature call, with only the temperature set.
2021-03-12 10:44:17 INFO (MainThread) [homeassistant.components.zwave_js.climate] In async_set_temperature, kwargs = {'temperature': 68.0, 'entity_id': ['climate.z_wave_thermostat']}
No service calls for async_set_hvac mode are seen unless I change it.
So, if it only comes from the UI button, how do we do to avoid calling the set_hvac_mode service when only dealing with the + or - buttons?
Can't it comes from zwave_js/climate.py#L377 ?
if hvac_mode is not None:
await self.async_set_hvac_mode(hvac_mode)
I feel like the information coming from the UI get a default "mode" value (here "Heating", because we see the UI shows a mode dropbox), so this test is indeed not None
, so it tries to set the mode and it crashes later because if not self._current_mode:
is not set (because this is not a device that can change the mode).
If I understand the frontend code correctly, when you change the temperature, the service call from the frontend doesn't specify hvac mode, it only sets the temperature:
private _targetTemperatureChanged(ev) {
const newVal = ev.target.value;
this._callServiceHelper(
this.stateObj!.attributes.temperature,
newVal,
"set_temperature",
{ temperature: newVal }
);
}
Unless the async await
affects the stack trace, your trace above doesn't show async_set_temperature
in the call stack, it looks like it's directly invoking async_set_hvac_mode
from the service handler.
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/zwave_js/climate.py", line 399, in async_set_hvac_mode
raise ValueError(
ValueError: Thermostat climate.main_heater_thermostat_main does not support setting a mode
If you can edit the source code (directly or via a custom component) you could confirm with some logging calls.
Based on those assumptions, I thought that the frontend might be setting the hvac mode mistakenly. I'm not sure how that would happen though. I added logging to set_hvac_mode and it was not invoked for me when only changing the temperature.
Hello. i still think as well the frontend trigger hvac mode my mistake, because service works. I manage with the scheduler widget to change the temperature based on time, but it is a little bit annoying not to be able to change it with the widget.
Isn't something to do in order to have the widget not displaying these mode and preset that is not relevant to this device?
Maybe this will have the widget not wanting to change mode.
So it looks fixed in 2021.4.0. I now have the ability to change the setpoint throught the UI and service, and no exception is raised whatsoever ^^
The problem
SRT321/HRT4-ZW Thermostat setpoint is well discovered and converted to climate entity but cannot set the setpoint.
What is version of Home Assistant Core has the issue?
core-2021.3.0
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
ZWave2JSMQTT
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zwave_js/
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Stacktrace:
I also see:
Follow up of #46570
The zwave trace is available here.