core: Setting Temperature in Devolo Thermostate is unreliable with zwave_js and service-call blocks for some seconds

The problem

Before: with old zwave-integration. I call the service to set the climate target temperature, the service returns immediately, as the thermostat awakens the temperature is successfully set to the device. This took approx. 5mins.

Now: with zwave_js. I call the service to set the climate target temperature, the service blocks for about 5-10 seconds, which interrups my automations. It takes longer to set all devices, because the value is not transmitted on the first wakeup reliably.

I triggered the changes on 00:49:43 The last of 4 service calls (set temp) returned 00:50:23 Node 12 and one other have been awake twice to set the temperature. See log.

What do I like to see:

  • Service call to set temp should return immediately, the plugin can do it’s work async as the old zwave integration did
  • Temperature should be transmitted at first wakeup
  • only the current temperature value should be transmitted to the thermostat, not all values of the queue

What is version of Home Assistant Core has the issue?

core-2021.2.2

What was the last working version of Home Assistant Core?

(not applicable, used old zwave integration)

What type of installation are you running?

Home Assistant OS

Integration causing the issue

zwave_js

Link to integration documentation on our website

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

00:52:24.657 CNTRLR « [Node 013] received wakeup notification
00:52:24.662 CNTRLR   [Node 013] The node is now awake.
00:52:24.665 CNTRLR   [Node 013] expects some queries after wake up, so it shall receive
00:52:24.666 CNTRLR   [Node 013] compat query "Battery"::get()
00:52:24.783 CNTRLR   [Node 013] API call successful
00:52:24.784 CNTRLR   [Node 013] compat query "Thermostat Setpoint"::get(1)
00:52:24.896 CNTRLR   [Node 013] API call successful
00:52:25.897 CNTRLR » [Node 013] Sending node back to sleep...
00:52:25.948 CNTRLR   [Node 013] The node is now asleep.
00:52:40.008 CNTRLR « [Node 016] received wakeup notification
00:52:40.010 CNTRLR   [Node 016] The node is now awake.
00:52:40.013 CNTRLR   [Node 016] expects some queries after wake up, so it shall receive
00:52:40.013 CNTRLR   [Node 016] compat query "Battery"::get()
00:52:40.095 CNTRLR   [Node 016] API call successful
00:52:40.095 CNTRLR   [Node 016] compat query "Thermostat Setpoint"::get(1)
00:52:40.184 CNTRLR   [Node 016] API call successful
00:52:41.184 CNTRLR » [Node 016] Sending node back to sleep...
00:52:41.232 CNTRLR   [Node 016] The node is now asleep.
00:54:37.311 CNTRLR « [Node 012] received wakeup notification
00:54:37.312 CNTRLR   [Node 012] The node is now awake.
00:54:37.314 CNTRLR   [Node 012] expects some queries after wake up, so it shall receive
00:54:37.315 CNTRLR   [Node 012] compat query "Battery"::get()
00:54:37.380 CNTRLR   [Node 012] API call successful
00:54:37.381 CNTRLR   [Node 012] compat query "Thermostat Setpoint"::get(1)
00:54:37.439 CNTRLR   [Node 012] API call successful
00:54:38.439 CNTRLR » [Node 012] Sending node back to sleep...
00:54:38.492 CNTRLR   [Node 012] The node is now asleep.
00:54:44.163 CNTRLR « [Node 010] received wakeup notification
00:54:44.164 CNTRLR   [Node 010] The node is now awake.
00:54:44.166 CNTRLR   [Node 010] expects some queries after wake up, so it shall receive
00:54:44.167 CNTRLR   [Node 010] compat query "Battery"::get()
00:54:44.278 CNTRLR   [Node 010] API call successful
00:54:44.279 CNTRLR   [Node 010] compat query "Thermostat Setpoint"::get(1)
00:54:44.340 CNTRLR   [Node 010] API call successful
00:54:45.339 CNTRLR » [Node 010] Sending node back to sleep...
00:54:45.389 CNTRLR   [Node 010] The node is now asleep.
00:57:17.753 CNTRLR « [Node 013] received wakeup notification
00:57:17.754 CNTRLR   [Node 013] The node is now awake.
00:57:17.758 CNTRLR   [Node 013] expects some queries after wake up, so it shall receive
00:57:17.759 CNTRLR   [Node 013] compat query "Battery"::get()
00:57:17.876 CNTRLR   [Node 013] API call successful
00:57:17.877 CNTRLR   [Node 013] compat query "Thermostat Setpoint"::get(1)
00:57:17.936 CNTRLR   [Node 013] API call successful
00:57:18.937 CNTRLR » [Node 013] Sending node back to sleep...
00:57:18.985 CNTRLR   [Node 013] The node is now asleep.
00:57:34.392 CNTRLR « [Node 016] received wakeup notification
00:57:34.393 CNTRLR   [Node 016] The node is now awake.
00:57:34.395 CNTRLR   [Node 016] expects some queries after wake up, so it shall receive
00:57:34.396 CNTRLR   [Node 016] compat query "Battery"::get()
00:57:34.505 CNTRLR   [Node 016] API call successful
00:57:34.507 CNTRLR   [Node 016] compat query "Thermostat Setpoint"::get(1)
00:57:34.580 CNTRLR   [Node 016] API call successful
00:57:35.581 CNTRLR » [Node 016] Sending node back to sleep...
00:57:35.635 CNTRLR   [Node 016] The node is now asleep.
00:59:32.890 CNTRLR « [Node 012] received wakeup notification
00:59:32.892 CNTRLR   [Node 012] The node is now awake.
00:59:32.895 CNTRLR   [Node 012] expects some queries after wake up, so it shall receive
00:59:32.895 CNTRLR   [Node 012] compat query "Battery"::get()
00:59:33.012 CNTRLR   [Node 012] API call successful
00:59:33.013 CNTRLR   [Node 012] compat query "Thermostat Setpoint"::get(1)
00:59:33.075 CNTRLR   [Node 012] API call successful
00:59:34.074 CNTRLR » [Node 012] Sending node back to sleep...
00:59:34.125 CNTRLR   [Node 012] The node is now asleep.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 23 (4 by maintainers)

Most upvoted comments

Hi Richard. I’m running Z-wave JS on a separate SD card so I can easily switch back to openzwave beta and all my old entities. It’s certainly unusable as it stands, like you I find all my other z-wave devices to be operating very well under Z-wave JS, but the battery TRV’s are not useable. I wonder if we’ve logged these bugs in the wrong place. I’ll try again next time there is a version change, but I don’t think there is anything I can do other than report the issue here. Rob

This issue is fixed in HA 2021.3 beta 2, at least the HA part is now resolved so nothing gets stuck anymore. Commands do still get queued up in zwavejs but at some point they will fix this by only sending the last command. Please reopen if the issue is not fixed for you. Thanks!

The Z-Wave JS integration is assigned to a Github Team so that’s why you do not see any person directly assigned. We’ll look into this and post an update on this issue when we find/fix something.

It seems that all triggered “climate.set_temperature” commands are stuck until the integration gets reloaded (they are canceled/killed for sure). Maybe it has nothing to do with the command itself, maybe thats a problem with battery powered devices wich are not responding immediately.

Would be nice if anyone with knowledge could read this issue and jump in, at least for me this is a big problem.

Regards Richard