TKB Home TZ68 going dead

Configuration Z-Wave
1

Hi,
I have two TKB Home TZ68 Z Wave sockets, and I have been using them for at least 3 years without any issues. Recently I noticed that when I try to toggle their status, the toggle is executed and then they go to dead state. Issue started at the same time for both devices. Other Z Wave devices are working fine.

To change state to Alive, I press the physical button on the socket and after some time it connects back to the network.

Any ideas what the issue might be? Could it be an issue with the latest Z-Wave JS ?

2

I have both TZ68 and TZ88 working with the latest zwave-js without any issues:
Driver Version: 10.3.0
Server Version: 1.24.0

My guess would be a change in radio propagation - move another mains powered Z-Wave device (as all are mesh routers) closer perhaps?

You could try:

  • Settings → Devices & Services → Z-Wave JS → Configure → Logs → Log Level = Verbose
  • Turn the device ON
  • Turn the device OFF
  • Settings → Devices & Services → Z-Wave JS → Configure → Logs → Log Level = Info

One TKB UK socket died of a hardware failure which when pronounced dead, had to be excluded from the network controller manually - Z-Wave networks can pause randomly for +120S trying to contact dead nodes. Software “marked unresponsive” isn’t enough to prevent this delay.

If this helps, :heart: this post!

3

Thanks for your reply. Tried what you suggested, log below - it seems the device is not respondong.
I am not sure about radio propagation, since I did not change anything in my setup, will try to move one of the sockets near the USB dongle and test again once I am back home.

Subscribed to Z-Wave JS Log Messages…
Log Level changed to: Verbose
2022-10-10T14:22:59.408Z DRIVER » [Node 005] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 148
└─[BinarySwitchCCSet]
target value: true
2022-10-10T14:22:59.415Z DRIVER « [RES] [SendData]
was sent: true
2022-10-10T14:23:03.693Z DRIVER « [REQ] [SendData]
callback id: 148
transmit status: NoAck
2022-10-10T14:23:03.698Z CNTRLR [Node 005] did not respond after 1/3 attempts. Scheduling next try in 500 ms.
2022-10-10T14:23:04.203Z DRIVER » [Node 005] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 148
└─[BinarySwitchCCSet]
target value: true
2022-10-10T14:23:04.214Z DRIVER « [RES] [SendData]
was sent: true
2022-10-10T14:23:08.316Z DRIVER « [REQ] [SendData]
callback id: 148
transmit status: NoAck
2022-10-10T14:23:08.318Z CNTRLR [Node 005] did not respond after 2/3 attempts. Scheduling next try in 500 ms.
2022-10-10T14:23:08.824Z DRIVER » [Node 005] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 148
└─[BinarySwitchCCSet]
target value: true
2022-10-10T14:23:08.835Z DRIVER « [RES] [SendData]
was sent: true
2022-10-10T14:23:12.969Z DRIVER « [REQ] [SendData]
callback id: 148
transmit status: NoAck
2022-10-10T14:23:12.975Z CNTRLR [Node 005] The node did not respond after 3 attempts, it is presumed dead
2022-10-10T14:23:12.976Z CNTRLR [Node 005] The node is now dead.

4

Try power cycling the device. May just be in a crashed state due to a brownout.

5

you were right, I moved one of the devices nearer to the hub and now both are working fine. for some reason radio coverage deteriorated. is there a way to check the signal on the device?

6

i done that multiple times … issue was radio signal for some reason is now weak

7

I’ve not seen a means of seeing RF signal strength for Z-Wave (unlike Tasmota WLAN which gives RSSI). ISTR Z-Wave hides radio settings as they “should just work”.

The device menus give some options - e.g. Heal which should re-interview adjacent nodes and to calculate a new mesh.