Cannot pair zooz devices with a tubeszb POE hub

Product Support
1

I’ve purchased several smart plugs as well as the titan water valve, and I can’t get any of them to pair in home assistant. I’m using a tubbeszb POE zwave hub and zwave js ui. Using the QR code fails outright. If I pair via search for device and pin, it seems to pair, but then I think the security handshake fails, and now I’m out of my depth. I’ve included the debug logs from zwave js ui below:

2026-08-13 20:47:41.765 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.208 ms

2026-08-13 20:48:11.786 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.284 ms

2026-08-13 20:48:41.816 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.324 ms

2026-08-13 20:48:58.272 CNTRLR Starting inclusion process with strategy Default…

2026-08-13 20:48:58.588 CNTRLR The controller is now ready to add nodes

2026-08-13 20:48:58.588 INFO Z-WAVE: Controller status: Secure inclusion started

2026-08-13 20:49:05.259 CNTRLR finishing inclusion process…

2026-08-13 20:49:05.830 CNTRLR The inclusion process was stopped

2026-08-13 20:49:05.832 INFO Z-WAVE: Controller status: Inclusion stopped

2026-08-13 20:49:05.834 INFO Z-WAVE: [Node 017] Found

2026-08-13 20:49:05.835 CNTRLR finished adding node 17:

basic device class: Routing End Node

generic device class: Binary Switch

specific device class: Unused

supported CCs:

· Z-Wave Plus Info (0x5e)

· Security 2 (0x9f)

· Transport Service (0x55)

· Version (0x86)

· Supervision (0x6c)

· Powerlevel (0x73)

· Notification (0x71)

· Meter (0x32)

· Manufacturer Specific (0x72)

· Indicator (0x87)

· Firmware Update Meta Data (0x7a)

· Device Reset Locally (0x5a)

· Configuration (0x70)

· Binary Switch (0x25)

· Multi Channel Association (0x8e)

· Association Group Information (0x59)

· Association (0x85)

controlled CCs:

2026-08-13 20:49:05.835 CNTRLR » [Node 017] Assigning SUC return route…

2026-08-13 20:49:05.836 CNTRLR » [Node 017] Deleting SUC return route…

2026-08-13 20:49:06.680 CNTRLR [Node 017] Assigning SUC return route failed: Invalid callback received

2026-08-13 20:49:07.532 ERROR Z-WAVE-SERVER: Message error

InclusionPhaseNotInProgressError:

at ControllerMessageHandler.handle (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/controller/message_handler.js:28:27)

at Client.receiveMessage (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/server.js:132:100)

at WebSocket. (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/server.js:55:45)

at WebSocket.emit (node:events:509:28)

at Receiver.receiverOnMessage (/opt/node_modules/ws/lib/websocket.js:1239:20)

at Receiver.emit (node:events:509:28)

at Receiver.dataMessage (/opt/node_modules/ws/lib/receiver.js:650:14)

at /opt/node_modules/ws/lib/receiver.js:584:12

at /opt/node_modules/ws/lib/permessage-deflate.js:309:9

at /opt/node_modules/ws/lib/permessage-deflate.js:392:7

2026-08-13 20:49:07.533 ERROR Z-WAVE-SERVER: Message error

InclusionPhaseNotInProgressError:

at ControllerMessageHandler.handle (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/controller/message_handler.js:28:27)

at Client.receiveMessage (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/server.js:132:100)

at WebSocket. (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/server.js:55:45)

at WebSocket.emit (node:events:509:28)

at Receiver.receiverOnMessage (/opt/node_modules/ws/lib/websocket.js:1239:20)

at Receiver.emit (node:events:509:28)

at Receiver.dataMessage (/opt/node_modules/ws/lib/receiver.js:650:14)

at /opt/node_modules/ws/lib/receiver.js:584:12

at /opt/node_modules/ws/lib/permessage-deflate.js:309:9

at /opt/node_modules/ws/lib/permessage-deflate.js:392:7

2026-08-13 20:49:07.693 ERROR Z-WAVE-SERVER: Message error

InclusionPhaseNotInProgressError:

at ControllerMessageHandler.handle (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/controller/message_handler.js:28:27)

at Client.receiveMessage (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/server.js:132:100)

at WebSocket. (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/server.js:55:45)

at WebSocket.emit (node:events:509:28)

at Receiver.receiverOnMessage (/opt/node_modules/ws/lib/websocket.js:1239:20)

at Receiver.emit (node:events:509:28)

at Receiver.dataMessage (/opt/node_modules/ws/lib/receiver.js:650:14)

at /opt/node_modules/ws/lib/receiver.js:584:12

at /opt/node_modules/ws/lib/permessage-deflate.js:309:9

at /opt/node_modules/ws/lib/permessage-deflate.js:392:7

2026-08-13 20:49:11.835 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.201 ms

2026-08-13 20:49:31.683 CNTRLR [Node 017] in the process of replying to a NonceGet, won’t send another NonceR

eport

2026-08-13 20:49:31.970 CNTRLR [Node 017] in the process of replying to a NonceGet, won’t send another NonceR

eport

2026-08-13 20:49:41.121 CNTRLR [Node 017] Security S2 bootstrapping failed: a secure inclusion timer has elap

sed

2026-08-13 20:49:41.122 CNTRLR [Node 017] has failed S2 bootstrapping and cannot be interviewed

2026-08-13 20:49:41.126 INFO Z-WAVE: [Node 017] Added with security None

2026-08-13 20:49:41.881 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.304 ms

2026-08-13 20:50:11.902 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.264 ms

2026-08-13 20:50:41.927 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.248 ms

2026-08-13 20:51:11.969 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.847 ms

Any insights would be appreciated!

2

Hi @ForbiddenDonut, thanks for including the logs! Based on the inclusion log, the device is being detected by the Z-Wave controller and the inclusion process is progressing far enough to identify the node and begin S2 security negotiation. The failure appears to occur during S2 bootstrapping rather than during initial device discovery.

The most significant entries are:

Security S2 bootstrapping failed: a secure inclusion timer has elapsed

followed by:

has failed S2 bootstrapping and cannot be interviewed

The preceding NonceGet messages also indicate that security traffic is occurring between the controller and device, so this does not appear to be a simple case of the controller being unable to communicate with the device at all. The subsequent Added with security None confirms that Z-Wave JS UI ultimately falls back to an unsecured inclusion after the S2 exchange times out.

Because you are seeing this behavior with multiple devices, I would first investigate the common controller-side configuration rather than treating this as an issue with an individual device.

Since this is a TubeZB PoE controller running Z-Wave JS UI, could you provide the following information?

  1. The Z-Wave JS UI version and Z-Wave JS driver/server version.

  2. The TubeZB firmware version.

  3. The exact Z-Wave radio/module being used and its firmware version.

  4. The connection/transport configured in Z-Wave JS UI for the TubeZB controller. In particular, please let us know whether it is using the current ESPHome transport or the older TCP serial connection.

  5. Confirm that all four security keys are configured in Z-Wave JS UI: S2 Access Control, S2 Authenticated, S2 Unauthenticated, and S0 Legacy. If this is an established Z-Wave network, please do not regenerate the existing keys; we only want to verify that they are present and configured.

For testing, I would also recommend temporarily placing one of the devices within a few feet of the TubeZB controller and performing a fresh manual secure inclusion using the PIN rather than SmartStart/QR. This will help eliminate RF conditions as a variable and allow us to concentrate on the S2 negotiation itself.

The QR/SmartStart failure should probably be treated separately for now. The manual inclusion attempt is getting substantially farther: the controller finds the device, identifies its supported command classes, and begins S2 bootstrapping. Let’s first get a successful secure manual inclusion before troubleshooting the SmartStart portion.

If possible, please also provide a complete Z-Wave JS UI debug log beginning immediately before one clean inclusion attempt and continuing through the S2 timeout. The portion provided here is enough to identify the S2 timeout, but additional driver-level information surrounding the security exchange may help determine whether the failure is occurring at the Z-Wave transport/radio level or within the controller configuration.

At this point I would not recommend regenerating security keys, rebuilding the Z-Wave network, healing the network, or changing SUC/SIS settings. The Invalid callback received message related to the SUC return route occurs after the inclusion process has already begun shutting down and does not, by itself, establish that SUC/SIS is the cause of the failure.

Once we have the TubeZB/Z-Wave JS versions, transport configuration, security-key status, and one clean debug capture, we should be able to narrow this down considerably.

3

Thanks, Sara.

Here’s what I have:

  1. Z-Wave JS UI version: 11.19.1, z-wave JS driver/server version: 15.24.2
  2. TubeZB firmware version is 2.20
  3. The exact z-awave radio/module is a ZAC93. 2.20
  4. I’m not entirely sure where to find this, but if I look under zwave js ui settings and the Z-wave settings, it shows a serial port which points to my tubezb port 6638. I’m not sure this is the right place, as there’s no other options here than TCP.
  5. All the keys are set. I was able to pair the titan water valve last night by going through the UI and stating to use S0 legacy security, and it worked.

I don’t have the time at the moment to do more pairing and debug logging as I’m about to leave on vacation (bad timing on my part, sorry about that), but will include an updated debug log in about a week.

Really appreciate your insights.

4

Thank you for the additional details!

ZAC93: up to date, so you’re all good there. Your Z-Wave JS UI 11.19.1 installation also corresponds with Z-Wave JS 15.24.2, so the versions you’ve reported there are consistent with one another.

The fact that you were able to successfully include the Titan using S0 security is also useful. Combined with the original log, this confirms that the ZAC93 and device are communicating and are capable of completing an inclusion. The behavior we’ve been looking at appears to occur specifically during the S2 security negotiation, where the original log showed the S2 bootstrap timing out.

There is one additional item I’d like to clarify before we do any more device-level troubleshooting.

You mentioned that the Serial Port setting in Z-Wave JS UI points to the TubeZB on port 6638. That is the correct place to look, and it indicates that your TubeZB is currently using its original raw TCP serial connection.

TubeZB has recently changed the recommended connection method for its Z-Wave kits. Beginning with TubeZB firmware 2026.07.11.0, their Z-Wave devices use the native ESPHome Z-Wave Proxy rather than the previous raw TCP serial stream. With the newer firmware, the Z-Wave JS UI connection changes from:

tcp://<device-ip>:6638

to:

esphome://<device-ip>:6053

TubeZB documents the change and migration procedure here:

Their current Z-Wave PoE setup documentation also identifies the TCP connection on port 6638 as the method used by firmware prior to 2026.07.11.0:

I want to be careful not to imply that the older TCP connection is necessarily responsible for the S2 timeout we’re seeing. TubeZB’s documented reason for moving to the ESPHome proxy relates to Z-Wave JS reconnection behavior over serial-over-TCP, not specifically to S2 inclusion. However, since your system is using the older connection method and we’re troubleshooting an unusual communication issue affecting S2 inclusion across multiple devices, I think it makes sense to bring that portion of the controller setup up to TubeZB’s currently supported configuration before we dig further into the individual devices.

One thing we’ll need to clarify when you’re back is the TubeZB firmware version itself. The 2.20 version you provided is the ZAC93 radio firmware version. TubeZB’s ESPHome firmware uses a separate version number; current versions are date-based (for example, 2026.07.11.0). Their documentation indicates that you can verify this under “TubesZB ESPHome FW Version.”

Once you’re back, I’d suggest first checking the TubeZB ESPHome firmware version. If it is an older version still using the TCP connection on port 6638, we can start by following TubeZB’s documented update procedure and moving the Z-Wave JS UI connection to the ESPHome proxy.

According to TubeZB’s documentation, this update does not change the existing Z-Wave network stored on the Z-Wave radio module, and their migration instructions specifically state to leave the existing Z-Wave security keys unchanged. They do recommend taking a controller backup before updating as a precaution.

Once that’s complete, we can try a fresh S2 inclusion with one device. If S2 still fails, a new debug log from that attempt should give us a much cleaner baseline for determining what is happening during the security exchange.

Enjoy your vacation, and no rush on the additional testing.

1 Like