Why isn't zwave_js.invoke_cc_api working like "Refresh values" in Z-Wave JS UI?

Configuration Z-Wave
1

I have one node that almost always is dead when Z-Wave JS UI starts up (yes, I have tried to fix and remove/add again, and it’s one wall and one meter from the controller), and ping does not work. I can fix it easily by going to the GUI of Z-Wave JS UI and click “Advanced”, “Refresh values”. That works every time. But I am trying to automate a zwave_js.invoke_cc_api like this:

action: zwave_js.invoke_cc_api
data:
  command_class: "112"
  method_name: get
  parameters: [5]
  device_id:
    - dc6d18d59fe9244c4c28f64c4eaf2ee3

That does not work when the node is dead. When the node is alive in Z-Wave JS UI again, it works. Shouldn’t those two work in the same way?

2

you can use easier method like below, I use it to have a forced retreival of a lot of sensors in the network, but can also do any other entity

data:
  refresh_all_values: true
  entity_id:
    - sensor.xxx
action: zwave_js.refresh_value

it targets a wider range of values, your ‘get’ might be too limited target

3

Thanks, but nope, that’s not the same. That only queries Z-Wave JS for the info from the node, the invoke_cc method forces Z-Wave JS to query the actual node.

4

Thats not how i percieved this. But it’s been long time ago that i’ve looked at it in detail. AFAIK is the ‘refresh values’ button in Zwave JSUI the same as HA refresh values and does query the zwave device

5

Well, I don’t think they can be the same. The Hass service fails when the node is dead, the GUI version wakes the node to life.

6

If you’re going to skip all the auto-magical things by using zwave_js.invoke_cc_api, then you should use all the parameters that are necessary. endpoint, parameters, and command_class.

Otherewise, it’s no different than using set_value or refresh_value

7

Thank you! Yeah, I guess I have to, the auto-magical things didn’t work in this case.

I thought I did at least have the endpoint, since endpoint will be 0 when not specified (if I understood it correctly). But I have now added 0 as the endpoint. But I have problems understanding the format of parameters. Can this be correct? I have added the battery level, which is command class 128 and parameter 2.

action: zwave_js.invoke_cc_api
data:
  command_class: "128"
  method_name: get
  parameters: [2]
  entity_id:
    - lock.id_lock_150
  endpoint: "0"

This does not fail when the node is dead, but it runs only a second or two then, while it takes a lot longer when the node is alive. The problem right now is that the last 10-20 times I have restarted Z-Wave JS UI the node has not been dead on startup, maybe because I have called it so many times now? So I will have to wait until I get it back to dead before I know if that command actually does it.

But is it correct? I have tried to read the manual for Z-Wave JS UI, but it’s way over my head to understand.

8

Never mind, I found out how to do it directly in X-Wave JS UI with MQTT messages.

Topic: zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/api/refreshCCValues/set

JSON payload: { "args": [48, 112] }

Or as an action:

action: mqtt.publish
metadata: {}
data:
  evaluate_payload: false
  qos: 0
  topic: "zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/api/refreshCCValues/set"
  payload: "{     \"args\": [43, 112] }"
9

Just curious, what is it you want to accomplish by refreshing these values? The “dead” status is just an indicator of the result of the last communication with the device (it timed out). It doesn’t have any bearing on future communication, and doesn’t impair any abilities in Home Assistant. Refreshing the values may make it come back “alive”, but that doesn’t have any affect on the behavior. Are you seeing something to the contrary?

Addressing the reasons why the node goes dead would still be a better approach.

10

I have tried the approach, and it doesn’t work no matter what I do. I have exactly the same type of node in another location, and that has the same problem.

The reason is that when the command to the node is sendt and the node is “dead”, that delays the reaction with up to 20 seconds. It’s a door lock, and my wife does NOT like to wait outside, especially when it’s raining… :joy: If it’s a live, it opens within a couple of seconds.

Mind you I didn’t have this problem before, but then I was running an Aeoteck Z-Stick 5, I have upgraded to a Home Seer 800 on both locations, and everything else has been better. Only those nodes are dead on almost every start. Some other nodes are dead on a few starts every now and then, so something has happened, and I have tried healing and reinterviewing and updating routes, nothing helps.