Things lose all their channels when openHAB and Z-Wave JS UI start at the same time

Add-ons Bindings
1

Does anyone else see this? I run openHAB 5.2.1 with the Z-Wave JS binding against Z-Wave JS UI 11.22.3 (54 nodes), and after a host reboot a number of Things come up with zero channels. Items linked to them silently go NULL — nothing errors, nothing warns.

Yesterday I found 11 of 54 Things empty, and 113 item-channel links pointing at channels that no longer existed. Some of those Things were ONLINE at the time, so it is not simply “the node is dead”.

What I measured

Both containers start at the same moment, and the bridge connects 29 seconds later:

zwave-js-ui   17:34:40.577Z
openhab       17:34:40.587Z
bridge ONLINE 17:35:09.177Z    <- 29 s after start
node70 ONLINE 17:35:09.325Z    <- 148 ms after the bridge

A Z-Wave network of 54 nodes is nowhere near finished interviewing after 29 seconds.

Reading the binding source (5.2.1), this seems to line up:

  • ZwaveJSBridgeHandler.requestNodeDetails() returns from lastNodeStates, a cache — it does not query Z-Wave JS.
  • That cache is filled in procesStateUpdate() from one full state dump, taken when the websocket connects, and it is not refreshed afterwards.
  • ZwaveJSNodeHandler.updateChannels() removes every existing channel that is not in the freshly generated result — and there is no check for the result being empty.
  • internalInitialize() does guard against null node details and against DEAD, but not against “alive, zero values”.

So a node that is alive but not yet interviewed when the bridge connects produces zero channels, and the existing ones are removed.

What fixes it here

No need to delete anything:

  1. run a Scan for the binding (that calls getFullState(), which refreshes the cache for all nodes, not only undiscovered ones);
  2. disable and re-enable the empty Thing.

The channels come back and the links reattach by themselves — links survive both the channel removal and even deleting the Thing, as long as it is recreated with the same UID.

Measured, as a natural experiment: disabling/enabling a Thing before the scan gave 0 channels; the same action after the scan gave 523 channels and 8 links restored.

My questions

  1. Does anyone else see empty Things after a reboot, rather than after removing a node?
  2. Does anyone delay openHAB’s start relative to Z-Wave JS UI, and does that help?
  3. Is there a supported way to make the binding re-read node details without a restart?

There is an older issue that looks like the same thing — openhab-addons#18967, “Ecolink flood sensor channel list empty” — with exactly this in the debug log:

Node 4. Building channels and configuration, containing 0 values
Node 4. Generated 0 channels and 0 configDescriptions

It was closed after the reporter removed and recreated the Thing, which works because by then the interview has finished. The underlying behaviour is still there.

2

yeah i’ve seen empty things after a reboot with zwave js ui + the binding. delaying openhab until zwave-js-ui is actually healthy usually stops it.

in compose i put a healthcheck on zwave-js-ui and depends_on with condition service_healthy for openhab. with 50+ nodes you probably want more than ~30s after the websocket comes up. interview is still going.

for a re-read without a full restart, the binding scan you found is basically it. i also run a small rule that fires a scan a couple minutes after startup so i dont have to remember.

reopen #18967 with your logs if you can. the zero-values wipe is still a landmine.