All zwave stopped working

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

46 when ctrl+f for “:node” but…
16 wired switches
15 battery

then a cluster devices that i added but didn’t seem to work and i left in case they would work later.

I did a soft reset of the controller, updated the tty device name and everything showed up as online but it’s still not sending out messages.

i recently updated the following:

polling period 7200
command poll has always been 1500 (default?)
wakeup interval 86400 but i had tried to change it to 14400 in an attempt to fix the issue but it didn’t stick.


actually as i was reviewing my settings, i noticed a lot of the notes are showing up as offline againt. i kept zwave logging on and i’ll try to run the logs through that log viewer to see if there is anything fun going on there.

for the laptop, are you suggesting to try to run openhab in debug mode locally?

no, if you have a windows pc, you can run the pc controller software to remove zombie nodes

The partial battery devices are not causing your problem because they are not involved in routing between other nodes. However if you upgrade to OH3.3 there were improvements in the initialization for battery devices. You will still have to manually wake the device a time or two, but it should complete. As noted above, waiting only works if the initialization has gotten to the point where the wakeup parameters have been set. That is why your wakeup change is not sticking.

Polling at 7200 is more likely to cause problems and not fix any.

Once you have the Silabs PC controller here is a zombie removal guide.
Z-Wave Zombies.pdf (571.9 KB)

thanks. i’m on linux and this seems related… Simplicity Studio - Silicon Labs

i’m installing it to see if it works.

i’ve ordered this and i’ll move things to this new controller and probably run it on docker from now on:

I physically inspected the usb dongle and its branded as Zooz but lsusb shows Aeotec, thought that might be interesting to some.