I have never thought it a good idea unless you have added or removed nodes. One of the strengths of zwave is that it learns the best route based the last route used to successfully communicate with another node.
This is the first method a node uses to try and communicate with a destination. If this fails then, if the option is set, it always is in the OpenHab binding, the node tries other routes based on neighbours. The last it tries is an explorer frame and again the OpenHab binding sets this option. This takes a long time as each try times out.
You can see these options are set for calls in the log file. This was the standard recommendation before the latest release of zwave. The retries are all made within the zwave protocol. A mysterious piece of code that is still not open to prying eyes. If all of the retries fail then the software (openHab Binding) can make more retries and in the case of openHab does. The development guides are not clear on this but Chris has a lot of experience so I am sure in general it is a better choice. It should rarely happen anyway but you did succeed with your many calls.
In a network that has not had any changes the communication settles to mainly the last route used and everything works well and the protocol will rarely make any retries.
Running a heal clears all of the last working routes. The network then has to start learning them again and does not necessarily pick up a good route first time. Particularly on large networks where the command causes a vast amount of traffic.Then you are into retries again while the network settles down.
If you have no issues I would recommend to try not to. If you have issues try to heal just the nodes that cause issues.
I also recommend you stop reading now unless very interested as the next bit is not implemented in the OpenHab binding
In the new version of the zwave SDK the recommendations and implementation in the software supplied have changed slightly.
Rather than calling with all options first time the first call is made with no options set so if the call fails the protocol returns to the software with no retries and therefore a shorter time. The failing message is then put on a lower priority (long) queue and next time the call is made with some options set so the protocol will retry with neighbours. If this fails it is returned to the long queue and only then is it tried with all options including explorer frames. This has the effect of prioritising first attempt calls and failing fast so other messages are not blocked.
It is easy to prove this is a superior strategy by testing the new SDK with a number of nodes, turn one off and control them all starting with the one switched off. The delay before the other nodes react is considerably less than with the older strategy as the protocol return control to the software faster so the messages for the other nodes can be sent as they are in the high priority queue and not blocked by the failed nodes command. After all other nodes have been controlled the system tries the turned off node again a couple of times obviously eventually failing even after an explorer frame.
A friend of mine has just implemented this on a new fork of OZW and reports that it works very well.
If you are very interested you can get a UZB3 and flash it with a zniffer firmware. You can then see all of the network traffic and retries. If you keep having issues this is my next recommendation. It reveals a level of detail a lot greater than the logs as you see all the commands sent by the stick not just the commands going across the serial interface.
