Sorry do not know.
Separately, I have some yellow flags about the RazBerry 7 Pro. There was also a person with a problem on the zwave github site. One thing that seems odd for a 700 chip controller is that it uses ApplicationCommandHandler (0x04) for unsolicited messages (like the 500 chip), rather than BridgeApplicationCommand (0xa8) like the USB based 700 controllers. This makes me think that the SDK was modified so the device could work with bindings that had not yet implemented (0xa8) but raises a flag as to what else was modified. I also wonder since the stable OH4.1 release can handle (0xa8) that maybe the firmware in the Razberry might transition over? Are you on OH4.1.x?
Also, I have seen earlier versions of the SDK than 7.17.2 in some Razberry 7 debugs and there is a note on the Zwave JS site about recommended 700 SDK’s. I do not know what you have, but maybe use a OTW upgrade to 7.18.x, if you are not there already. I used 7.18.3 with all my 700 controller testing.
Lastly, (and I do not think this is the real problem) but it was recently found that orphan links can cause excess command polling of all channels. Might want to see if you have some (See post here.)
Again sorry I could not help with the reset via rule/cron, but the timeouts should not be happening unless something else is wrong.
edit: I did think of something similar (to the soft reset) that might be accessible by rule (but I don’t know how myself), that is to Stop and Start the Zwave binding within the karaf console. Also the API has install/uninstall binding option. Both should clear the zwave queues and reinitialize the RazBerry.