Z-Wave JS binding only tries to reconnect once

1

Hello. It seems only one actual reconnect attempt is made, so if the zwave js docker container is down for more than 2 minutes, the z wave js bridge stays disconnected forever.

2026-02-18 12:39:45.731 [DEBUG] [g.zwavejs.internal.api.ZWaveJSClient] - onWebSocketClose(1005, ‘null’)
2026-02-18 12:39:45.733 [INFO ] [g.zwavejs.internal.api.ZWaveJSClient] - Scheduling reconnect to Z-Wave JS Webservice every 2 minutes
2026-02-18 12:41:45.734 [DEBUG] [g.zwavejs.internal.api.ZWaveJSClient] - Connecting to Z-Wave JS Webservice
2026-02-18 12:41:45.738 [DEBUG] [g.zwavejs.internal.api.ZWaveJSClient] - Error during websocket communication: Connection refused

..after that nothing more happens. I have to either disable/enable the binding to get it to reconnect or restart openhab.

If the zwave js container is down for less than two minutes, the reconnect happens normally and things recover automatically.

I have enabled DEBUG logs for the zwave js binding so the above log is all there is. It doesn’t matter how long I wait. The reconnection never happens if the first reconnect attempt after 2 minutes fails.

My environment is that I run everything in docker on a minipc, and I am also using a custom port number 8092 for the zwave js websocket, but I don’t think that is relevant in this context.

Docker version numbers:
openhab/openhab:5.1.2
zwavejs/zwave-js-ui:11.11.0 (zwavejs driver version 15.20.1)

Sorry if I missed some important info in this message. Let me know if I should add more logs, do more tests, etc.

2

It doesn’t help with the overall problem, but it might be easier to disable/enable just the bridge Thing instead of the whole binding.

If that works, as a temporary work-around you could even put it in a rule to do it automatically.

Obviously this needs to get fixed in the binding but in the meantime this might get you by.

If you can rely on the Thing’s status change from ONLINE, I trigger a rule when the Thing changes. In the rule I’d set a timer (just in case it comes back on it’s own). If the Thing comes back ONLINE cancel the timer. When the Timer goes off, disable, wait a sec and enable the Z-Wave JS bridge Thing.

In JS the script action would look something something like:

if(event.newStatus == "ONLINE") {
  cache.private.get('timer')?.cancel();
  cache.private.remove('timer');
}
else if(!cache.private.exists('timer')) {
  cache.priate.put('timer', actions.ScriptExecution.createTimer(time.toZDT('PT5S'), () => {
    things.getThing('id:of:zwavejs:bridge:thing').setEnabled(false);
    setTimeout(() => things.getThing('id:of:zwavejs:bridge:thing').setEnabled(true), 1000);
    cache.private.remove('timer');
  })
}
// do nothing if the timer already exists
3

Thanks for your reply.

First of all… Sorry, it was actually the Bridge Thing I disabled / enabled to get it working again, not the binding. I was not very precise in my first message.

Great minds think alike I guess, as I did complete a javascript rule that automated that before I saw your message. That works as a stop-gap, but it is not incredibly smart or aggressive in terms of polling frequency or how often to attempt restarting the Bridge. I am cautious of making a bad situation worse.

4

You can trigger the rule on changes to the status of the Bridge Thing instead of polling. Beyond that, whether to try multiple times and how often would need to be figured out through experimentation.

Do file an issue on the binding though.

5

Ok. I have opened an issue now: