Why 1 attempt to send the command failed?

[duylong]

Hi,

When we have an error like this "ERROR Z-WAVE: Error while writing 0 on 38-0-targetValue: Failed to send the command after 1 attempts (ZW0202)", why is there only one attempt?

Couldn't we increase the number of attempts? Sometimes, for me it goes into error and then if I try again it goes through without problem.

[AlCalzone]

That's one attempt of Z-Wave JS telling the controller to send the command to the node. There's really no point in trying that again.
The controller will do many more attempts under the hood, trying different routes and speeds. If you look at the driver logs, you should see that in the SendData callback ("routing attempts").

Sometimes, for me it goes into error and then if I try again it goes through without problem.

Sounds like a flaky connection. I recommend working through https://zwave-js.github.io/node-zwave-js/#/troubleshooting/first-steps if you haven't already.

[duylong]

I have a lamp that did not turn off as expected even though it had always worked until then. A failure is still a failure and randomness does not reassure me.

I did my best, I have more than 55% of equipment powered for the relays. The background RSSI of my controller is at -95dBm and a reconstruction of the routes was done on the powered modules.
My network remains stable despite some "Timeout ACK" and "Dropped RX" (total Commands: 0.08% dropped, messages: 0.58% dropped), nothing is perfect even if I would have liked 0%.

I might look into assigning the routes manually, although I prefer it to be automatic especially if a node goes dead.

[duylong]

I can no longer reproduce the problem, I no longer have FAILs. Further attempts would have resolved the problem at this point.

I added a priority and return route in direct connection for each module in the same room. Dynamic routes did not seem optimal.

Is the route speed dependent on the module? If I set 100Kbps and the module does not support this speed, what will happen?

The "Priority route" option for the return route is only useful if there are 2 return routes? If I only have one and I haven't checked this option, we agree that it's the same thing?

I saw that we were losing our customizations each time we rebuilt the routes. Can we have an option to keep our changes? Otherwise I would have to make my modification on my dozens of modules each time.

[AlCalzone]

Is the route speed dependent on the module? If I set 100Kbps and the module does not support this speed, what will happen?

All devices from the last few years support 100 kbps. If not, the priority route would fail and the controller would revert to dynamic route resolution to send the message.

The "Priority route" option for the return route is only useful if there are 2 return routes? If I only have one and I haven't checked this option, we agree that it's the same thing?

This is mainly for unsolicited communication initiated by the device. When responding, it will use the route the controller used, so "just" a priority route should be enough. With the priority return route, you prevent it drifting to another one though.

I saw that we were losing our customizations each time we rebuilt the routes. Can we have an option to keep our changes?

If you want my honest opinion: don't rebuild routes. It's rarely making things better. Especially if you already have a priority route for a device, there's no need to rebuild its routes.

[duylong]

All devices from the last few years support 100 kbps. If not, the priority route would fail and the controller would revert to dynamic route resolution to send the message.

According to my diagram, I still have dynamic routes in 9.6 kbit/s. So if I understand correctly, the list is fixed and the selection does not display the real speed of the module.

This is mainly for unsolicited communication initiated by the device. When responding, it will use the route the controller used, so "just" a priority route should be enough. With the priority return route, you prevent it drifting to another one though.

Ok, in doubt, I did both, I risk nothing as they are direct connections.

If you want my honest opinion: don't rebuild routes. It's rarely making things better. Especially if you already have a priority route for a device, there's no need to rebuild its routes.

This is more for "General actions", because from time to time I redo my routes following a change in my network. In this action, we can ignore the modules on battery, it would be nice to be able not to overwrite the custom routes.

[AlCalzone]

So if I understand correctly, the list is fixed and the selection does not display the real speed of the module.

Yes. A couple of points:

• 9.6k means you have a very bad link there - this is essentially the Z-Wave protocol trying to reach the device by all means necessary
• the link statistics only update after communication happens, so you may need to ping a device after setting the priority route for the change to be reflected on the map

In this action, we can ignore the modules on battery, it would be nice to be able not to overwrite the custom routes.

I'll add that as a feature request to ignore devices with a priority route.

[AlCalzone]

#7147