Z-Wave timeouts

Thanks for that information.
Do you use it when z-wave is getting timeouts?

Indeed

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.

robjkamp,

I have discovered that the menu item “Reinitialize the device” is missing on a zwave device in the case that initialization did not yet complete. To confirm this is the case for your devices you can turn on DEBUG for zwave and hit “Heal the device”. I would expect to see “Can not start heal as initialisation is not complete” in the log file for that node. That log message will tell you the initialization state as well.

In my experience, in the case that the zwave device did not initialize after a startup or network heal after some short time ~3 minutes, then it will never initialize. I’m working on some coping mechanisms on how to detect this and reinitialize, etc.

I’m skeptical that this issue is directly related to your lightbulb problem, but could be tangentially related through the general problem of a zwave network performance issue.

I’m on OH4.1.1.

I get about 30000 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xa) per day.

The problem is the controller_softreset. On the UI code tab is that set to false? After that change, stop and start the ZWave binding (hopefully to clear) and never use softreset again. Then we can see what the underlying issue is.

tl;dr
From the ZW spec;

  1. This command is used to request the Z-Wave Module to perform a soft reset. The Soft Reset Command Identifier is 0x08.
  2. The frame flow for this command is an Acknowledged frame.
  3. I can’t quite see why the OH Zwave command is sent more than once per the JAVA doc. Maybe that is because your Razberry is sending NAK, not ACK, so the Soft Reset Command keeps repeating?
 /**
     * Sends a request to perform a soft reset on the controller. This will just
     * reset the controller - probably similar to a power cycle. It doesn't
     * reinitialise the network, or change the network configuration.
     * <p>
     * <b>NOTE</b>: On some (most!) sticks, this doesn't return a response. Therefore, the number of retries is set to
     * 1. <br>
     * <b>NOTE</b>: On some (most!) ZWave-Plus sticks, this can cause the stick to hang.
     *
     */
  1. Back to the Zwave spec (note that SHOULD does not need MUST)
    Note: A Z-Wave Module SHOULD issue a Z-Wave API Started Command when it has completed the reset operation. The Z-Wave API Started Command Command Identifier is 0x0A
    Your Razberry is sending this (Z-Wave API Started Command). The OpenHAB Zwave binding is not set up for this.

You could also open an issue on the zwave github to find why the command is still repeating, but I don’t think this is a helpful command.

This is part the code tab.

UID: zwave:serial_zstick:99c0ff6689
label: Z-Wave Serial Controller
thingTypeUID: zwave:serial_zstick
configuration:
  controller_softreset: false
  security_networkkey: A KEY
  security_inclusionmode: 0
  controller_sisnode: 1
  controller_maxawakeperiod: 20
  controller_sync: false
  controller_master: true
  inclusion_mode: 1
  port: /dev/ttyAMA0
  controller_wakeupperiod: 3600
  controller_exclude: false
  heal_time: 2
  controller_inclusiontimeout: 30
  controller_hardreset: false
...

That should be fine.

Did a soft reset on my test system with Aeotec Zstick and it worked. At this point all roads lead to the Razberry (IMO). Comparison to your debug (tried to line up the messages).
zwave-timeouts-reset controller.txt (3.4 KB)

As noted above I would stop using the Soft Reset and upgrade the Razberry firmware to see if that helps (or see what new adventures await). If you don’t want to do that you could save your network and factory reset the Razberry, then reload network. Once that is done a ZW Debug level startup might provide a clue to the root cause (if it is not fixed). Buying a USB backup stick could be a good idea too.

Good luck