You may have ploughed through my posts on z-wave and you may want some evidence.
If you have not and want to go backwards Z-Wave - getting the best out of it
or from the top
Here are some test runs using PC Controller and my test UZB3 controller.
I have it all backed up so not too worried.
You can run these test yourself on your network
I have upped some of the reporting to try to make things fail and have a few sensors that I can force to send a load of reports.
First test 3 devices all binary switches z-wave plus.
the first is a direct route the second 1 hop the third 3 hop. You can see the increase in response time.
The test looks like this
You can see in the log I have a slow rate of reports constantly arriving so this is like a real network but I am going to intentionally trigger some inbound and you can see a batch of reports.
The delay between commands is set to 100ms so not pushing.
here it goes and it is looking fine
but I trigger a load of reports and
I blow the UART
and then with 5 and only 1ms so pumping those commands as soon as one do the next
trigger a load of reports to arrive and again I make it fail but this time one of the commands times out and never gets a response.
Clearly neither of these are routing issues. All routes are good but when traffic increases above a certain point, particularly with lots of unsolicited traffic things break.
You can try this on your network but strongly suggest you backup your NVM.
If you do you will find out how much traffic your network can run before you get failures. A test configured similar to your scripts will show if a few pauses would help so that unsolicited reports and commands live together without causing retries or failures.
If your report load is above the capability of the network then outbound commands will regularly fail.
Z-wave works well but it can not process a constant stream of commands and returns. It relies on timeouts and backoffs to manage collisions and slow responses cause timeouts and retries.
As soon as the mix of traffic exceeds the limits and retries start, if the traffic does not reduce it is likely that reports or commands are going to fail.
With a z-wave network and many reporting nodes and command triggers that can combine to peaks resilience can only be achieved by making sure that scripts and reporting are designed to give interactive actions space to work in. If there is no space for interactive actions and retry or even failures happen then the network will not be good to live with.
I hope this information helps people design a practical network that has space left for interactive actions to execute quickly.