All zwave stopped working

Raspberry Pi 4 with 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

I update my setup regularly (need to update to new raspberry pi os though) and just recently all of my zwave devices stopped responding. I was cleaning the area where I keep the device and I also unplugged it by accident.

Its been about 4-5 days now and i’ve tried to “heal the device” for all devices one by one but also “synchronize network” from the zwave controller. it did help some devices appear as “online” in the things list but all devices seem to constantly go from online to “error: comm” (node is not communicating with controller"

the funny thing is that it seems most contact sensor are sending data to the controller and some hard wired switching also send data back but they dont receive any data and the mobile app and basic ui seem to think that the status got changed, resulting in inaccurate representation.

the logs in events.log seem to sow that items are working fine:

2022-09-16 20:12:42.539 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘LivingRoomLamp_Switch’ received command OFF
2022-09-16 20:12:42.542 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘LivingRoomLamp_Switch’ predicted to become OFF
2022-09-16 20:12:42.553 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘LivingRoomLamp_Switch’ changed from ON to OFF
2022-09-16 20:12:45.649 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘LivingRoomLamp_Switch’ received command ON
2022-09-16 20:12:45.651 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘LivingRoomLamp_Switch’ predicted to become ON
2022-09-16 20:12:45.657 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘LivingRoomLamp_Switch’ changed from OFF to ON

yet the switch did not light up at all.

i’ve had zwave stop working the past – like when i reboot sometimes – but it generally starts working again after a day or 2. this time its starting to feel more permanent.

any ideas?

What does lsusb return?

$ lsusb
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6
Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So the zstick is plugged directly into the Pi? Is it the rpi4 compatible version?

what version of openHAB?

openHAB 3.2.0

It’s the same zstick on the same rpi4 i’ve had for a few years (since oh2 days).

the fact that it worked on a few lights a few times makes me think that outbound signals from the stick work too (vs just reading) but its just strange that the zwave network is all messed up

Normally after a sudden power loss, SD card corruption is suspect, but it looks like you have an attached HD, so probably not. Do you see anything odd with dmesg? I had a similar setup, but occasionally the HD would act up. I ended up applying “quirks”.

I do not recall any zwave issues with OH3.2, but it has been 9 months, so I might have forgotten. Most of the Zwave devices have been fixed with the “strict validation” of OH3.3. I’m on OH3.4M2 for a week without any issue. Maybe an upgrade?

If you have a spare USB2.0 hub I would try separating the zstick from the Pi. I realize it was working, but maybe something is off now. I think there were cases where aeotec worked with the Rpi4 for a while, then lost it.

Also you could try putting the zwave in Debug for a while and see what is happening in more detail. Use the zwave debug log viewer

Sorry for no real answers.

Are there any “dead nodes”? Devices that no longer exist but were not excluded from the network? If yes, try to delete them from the controller.

Is network healing active?

Try to deactivate messages from the devices that are not necessary. You may suffer from network congestion, meaning too much traffic and not every message can be transported and gets lost.

Maybe this thread is of help, as it helped me understand the root cause behind by problem.

Next 2 things to do are
Stop openhab
Clear the tmp and cache folders
Restart openhab

check which ACM ie /dev/ACM0 or 1 the deice is connected to and is correct (likely as can communicate with some)

ls /dev

ensure that openhab user is a member of the dialout group

groups <user>

where is user name - if not add it. Although usu with this fault you can’t connect zwave stick at all

then as others have said look for dead nodes - once zwave stick gets full it becomes unstable and may need connect to zwave stcik reader eg zway or openzwave to remove dead nodes from the stick allowing more space.

Edit - Ok that’s 4

Thanks @Cplant , the problem seemed a bit different but that thread does mention another dongle that also does zigbee and that’s tempting to switch to. I’m not sure if I can just swap out the zwave dongle without having to include each device one by one or if they are associated with OH so swapping the hardware will be transparent.

I’ve enabled zwave debug logging and I did see a ton of messages (too much to post here) but some interesting ones that stand out are along the lines of “NODE 41: Retry count exceeded. Discarding message: TID 3404: [CANCELLED]”

I waited for the noise to settle and I tried 1 action (toggle a switch) from basicui and got these log messages:

2022-09-18 20:09:33.646 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Command received zwave:device:831e87fd:node4:switch_binary --> OFF [OnOffType]
2022-09-18 20:09:33.649 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 4: Creating new message for application command SWITCH_BINARY_SET
2022-09-18 20:09:33.651 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-09-18 20:09:33.653 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Command Class COMMAND_CLASS_SWITCH_BINARY is NOT required to be secured
2022-09-18 20:09:33.655 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Adding to device queue
2022-09-18 20:09:33.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Added 3407 to queue - size 29
2022-09-18 20:09:33.660 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-09-18 20:09:33.662 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 04 03 25 01 00 25 A7 47 
2022-09-18 20:09:33.665 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 4: Sending REQUEST Message = 01 0A 00 13 04 03 25 01 00 25 A7 47 
2022-09-18 20:09:33.667 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2022-09-18 20:09:33.669 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2022-09-18 20:09:33.670 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 167
2022-09-18 20:09:33.672 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2022-09-18 20:09:33.672 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling initialised at 7200 seconds - start in 1500 milliseconds.
2022-09-18 20:09:33.675 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2022-09-18 20:09:33.676 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 00 E9 
2022-09-18 20:09:33.677 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 167
2022-09-18 20:09:33.679 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2022-09-18 20:09:33.680 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:33.681 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-09-18 20:09:33.683 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2022-09-18 20:09:33.685 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:33.687 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 167
2022-09-18 20:09:33.689 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2022-09-18 20:09:33.691 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 167
2022-09-18 20:09:33.693 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:33.695 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 4: sentData was not placed on stack.
2022-09-18 20:09:33.697 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 3407: Transaction CANCELLED
2022-09-18 20:09:33.699 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Holdoff Timer started...
2022-09-18 20:09:33.701 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2022-09-18 20:09:33.704 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: CANCEL while sending message. Requeueing - 2 attempts left!
2022-09-18 20:09:33.706 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 3407: Transaction RESET with 2 retries remaining.
2022-09-18 20:09:33.707 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Adding to device queue
2022-09-18 20:09:33.708 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Added 3407 to queue - size 29
2022-09-18 20:09:33.710 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff true.
2022-09-18 20:09:33.711 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: TID 3407: Transaction not completed
2022-09-18 20:09:33.712 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-09-18 20:09:33.713 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff true.
2022-09-18 20:09:33.951 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-09-18 20:09:33.953 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 04 03 25 01 00 25 A8 48 
2022-09-18 20:09:33.954 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 4: Sending REQUEST Message = 01 0A 00 13 04 03 25 01 00 25 A8 48 
2022-09-18 20:09:33.955 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2022-09-18 20:09:33.956 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 168
2022-09-18 20:09:33.956 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2022-09-18 20:09:33.957 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2022-09-18 20:09:33.958 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2022-09-18 20:09:33.958 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 00 E9 
2022-09-18 20:09:33.959 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 168
2022-09-18 20:09:33.959 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:33.960 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2022-09-18 20:09:33.960 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:33.961 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 168
2022-09-18 20:09:33.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2022-09-18 20:09:33.963 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 168
2022-09-18 20:09:33.964 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:33.965 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 4: sentData was not placed on stack.
2022-09-18 20:09:33.965 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 3407: Transaction CANCELLED
2022-09-18 20:09:33.966 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Holdoff Timer started...
2022-09-18 20:09:33.967 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2022-09-18 20:09:33.968 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: CANCEL while sending message. Requeueing - 1 attempts left!
2022-09-18 20:09:33.969 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 3407: Transaction RESET with 1 retries remaining.
2022-09-18 20:09:33.970 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Adding to device queue
2022-09-18 20:09:33.970 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Added 3407 to queue - size 29
2022-09-18 20:09:33.971 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff true.
2022-09-18 20:09:33.972 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: TID 3407: Transaction not completed
2022-09-18 20:09:33.973 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-09-18 20:09:33.974 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff true.
2022-09-18 20:09:34.217 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-09-18 20:09:34.218 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 04 03 25 01 00 25 A9 49 
2022-09-18 20:09:34.219 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 4: Sending REQUEST Message = 01 0A 00 13 04 03 25 01 00 25 A9 49 
2022-09-18 20:09:34.220 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2022-09-18 20:09:34.221 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 169
2022-09-18 20:09:34.222 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2022-09-18 20:09:34.223 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2022-09-18 20:09:34.225 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2022-09-18 20:09:34.225 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 00 E9 
2022-09-18 20:09:34.225 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 169
2022-09-18 20:09:34.226 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2022-09-18 20:09:34.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:34.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-09-18 20:09:34.228 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2022-09-18 20:09:34.229 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:34.230 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 169
2022-09-18 20:09:34.231 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2022-09-18 20:09:34.232 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 3407: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 169
2022-09-18 20:09:34.233 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=00 
2022-09-18 20:09:34.234 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 4: sentData was not placed on stack.
2022-09-18 20:09:34.234 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 3407: Transaction CANCELLED
2022-09-18 20:09:34.235 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Holdoff Timer started...
2022-09-18 20:09:34.236 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2022-09-18 20:09:34.237 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Retry count exceeded. Discarding message: TID 3407: [CANCELLED] priority=Set, requiresResponse=true, callback: 169
2022-09-18 20:09:34.238 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: TID 3407: Transaction completed
2022-09-18 20:09:34.239 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: notifyTransactionResponse TID:3407 CANCELLED
2022-09-18 20:09:34.240 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2022-09-18 20:09:34.241 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-09-18 20:09:34.242 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff true.
2022-09-18 20:09:34.487 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

@stefan.oh I’m pretty sure I have some dead nodes, I’ll try to figure out which I can remove and see if that helps.

Is there a way to prevent them from reappearing in the inbox? I’ve ignored them in the past but OH seems to keep record of them forever which is kind of annoying as some devices are things that just didn’t work in OH at the time and I’ve since removed them.

A few other dead nodes are actually contact sensors that seemed to only partially get included as I get no events from them but I left them in with hopes that they would eventually magically work.

Inclusion in Z-Wave is basically the same as “pairing” in Bluetooth: controller and device get to know each other. The information of included devices is not held in OH but on the controller itself. Only excluding or deletion of a device from the controller will eleminate the info and thus a reappearance of the device in the inbox.

That can only happen when they are battery operated devices and the inclusion process finishes over time when the devices wake up regularly (or you manually force a wakeup of the device until the process is finished). Provided they are in the Z-Wave database the binding has included.
You can check the database here whether the devices are known.

Using the Zwave viewer I linked above provides a more readable output. Your snippet shows this


It seems to me there is a problem with the controller. I would still try the hub idea, but if you buy another, you can you the Silabs PC controller to backup the current stick and copy the network to the new one. However, there is the risk of backing up bad information and transferring it to the new controller

I’ll try the hub but I’m not sure I have a powered hub.

I’m assuming the “controller” is the dongle and I did read that included devices won’t just magically switch over so I was having second thoughts. I’m now considering moving off rpi4 and instead running it in docker as it appears there’s enough people using it that way without too many issues. I like the idea of recycling 1 physical device but I know it comes with the risk of my docker host going down since I do update that more frequently.

Would I be able to migrate to docker with a simple backup from rpi and restore to docker host on x86_64? I feel like that can be a non-destructive test with nothing more than a few local dns changes for some wifi devices and mqtt.

yes. It doesn’t have to be powered. I like powered however because I feel a separate power supply for the zwave radio helps. I don’t know if this will work, but it is the easiest to try.

I’m not an expert on all the reasons the controller will reject commands. However, one major candidate is that it is overwhelmed (not defective). If you look at the timing in the snippet the binding is set to wait 250 ms before resending the command, but after 3 times it gives up. The binding looks good to me. That leads back to the ideas by others regarding zombie nodes. Also, if I picked this up correctly from your file you have polling at 2 hours. I have polling for powered devices at 10 days (the max) and for battery devices 1 day (just to get a daily battery reading). Increasing the polling interval probably won’t solve the problem, but it could help reduce traffic. I also do not use the command poll, but that is controversial. Between auto-update and visual confirmation (yes, the light is on!) I feel I’m covered. A great post on Zwave issues is here. IMO -I’d try to get the current situation better, before going the docker route

Lastly I have no experience with docker but agree it does seem popular. I have two OH/zwave instances; an Rpi4 with a zooz zstick on a powered hub (for radio power purity) and a rpi3b with an aeotec zstick directly plugged in (old model that will not run directly off the Rpi4- found out the hard way). Both very stable. I also have a zniffer to see what is going on with the controller, but that is for another day.

to follow up on what Bob is saying, how many nodes in your zwave network?
how many mains powered how many battery
rough layout (number of floors, construction - frame/masonry)

I need to find a better drawing tool but this is what my setup looks like:

  • single floor, wood construction, house is about 45’ wide by 60’, garage about 16’x18’
  • detached garage on northeast with 3 wired switches (2 switches, 1 motion sensor)
  • smaller detached room to northwest is pool shed with 1 switch for pool light, wood shed
  • red box in larger area (home) is the chimney – causes wifi issues it seems so i figured i’d include it
  • blue dots around the edges of house are window contact sensors (battery) and thermostat (battery) in the center of hallway
  • green dots are 1 or more switches or scene controller switches, all wired.

as you can see, some wired devices are outside and in metal enclosures but have worked pretty well since initial headache of inclusion.

total nodes please?

taking a stab at this after watching conversation.
this was a working system
How many nodes are still offline?
how many of the battery nodes are offline?
battery nodes often need woken up numerous times. Waiting doesn’t help
What is reporting rates for sensors? Could the new more strict settings syntax returned some nodes to a default reporting level and be swamping the network?
Zombie nodes… do you have a laptop which could run the PC controller software