Z-Wave USB stick not working after OH 3.1 update

Hi!
I have an issue with my Aeotec gen 5 Z-wave stick which has stopped working after I upgraded from OH 3.0.x to 3.1 recently. And I need help getting it working again.

Here is a debug log of the binding (and the serial binding) when I enable my z-wave thing:

2021-07-10 15:45:47.469 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - Creating ZWave discovery service for zwave:serial_zstick:ebf2caa1 with scan time of 60
2021-07-10 15:45:47.475 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - ZWave discovery: Active zwave:serial_zstick:ebf2caa1
2021-07-10 15:45:47.475 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2021-07-10 15:45:47.489 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:ebf2caa1' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2021-07-10 15:45:47.492 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2021-07-10 15:45:47.493 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:ebf2caa1.
2021-07-10 15:45:47.494 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:ebf2caa1' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2021-07-10 15:45:47.499 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:device:ebf2caa1:node2' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2021-07-10 15:45:47.502 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:ebf2caa1:node2.
2021-07-10 15:45:47.503 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:device:ebf2caa1:node2' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2021-07-10 15:45:52.495 [DEBUG] [ort.serial.internal.RxTxPortProvider] - No SerialPortIdentifier found for: /dev/ttyACM0

I am running OH on Ubuntu 20.04.2 LTS which is running inside a virtual machine powered by VMWare ESXI. The OS does see the USB stick… running lsusb:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 005: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 002 Device 004: ID 1cf1:0030 Dresden Elektronik VMware Virtual USB Mouse
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

The serial port /dev/ttyACM0 also exists.

Additional Java options inside of /etc/default/openhab are also configured:

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyZWAVE:/dev/ttyUSB0:/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyACM1:/dev/ttyAMA0"

Similar thing happened to me soon after I upgraded OH from 2.5 to 3.0. Back then I solved the issue by doing this:

Add the following line to the legacy.conf (as I said previously mine didn’t have d /run/lock line in it):

d /run/lock 0775 root dialout -

And then copy the legacy.conf to tmpfiles.d

cp /usr/lib/tmpfiles.d/legacy.conf /etc/tmpfiles.d/

I checked and this fix is still in place and OH is part of the dialout group (and checking the permissions on /dev/ttyACM0 it is owned by the dialout group. This fix worked just fine for months after I applied it.

I am at a loss in what else to do anymore. Can anyone help?

this is a link to another thread from about an hour ago. Maybe you guys need to compare notes

I looked it over and sadly it doesn’t seem like all that similar issue. As well as the fact that my problems only started when upgrading from 3.0 to 3.1. Generally it seems like Z-Wave has some sort of issues almost every time there is a major OH update though. The fix that I mentioned could help the person from that thread though.

that is possible, I linked your thread in his, hopefully he checks this out

Since this is a 3.1 upgrade issue, perhaps you should report it in the 3.1 release discussion thread I’ve seen what seems like a lot of folks having serial related problems. I believe the implementation of serial changed awhile back and I suspect there may be a few buggies that still need shaken out
edit: you are using 3.1 release version correct?

I am, yes.

Maybe it’s a security issue - the port may exist, but if the binding can’t access it, then it will not be able to find it.

I doubt that this is a binding issue - there have been very very few changes in the binding for quite some time now. Probably this is a wider system issue - possibly security, or possibly serial port drivers. There are some issues I think with the nrjavaserial driver that OH uses (the zwave binding doesn’t access the ports directly - it uses whatever the core provides to access the ports).

Any way to debug that? My knowledge of linux environment is not that excellent. Running ls -al for it I get this:

crw-rw----  1 root dialout 166,   0 Jul 10 17:52 ttyACM0

Running groups openhab I get this:

openhab : openhab tty dialout audio

So at least permissions wise it should be ok.

I agree. I doubt that it is connected with the binding directly… but the result is still the same - ZWave isn’t working.

I’m afraid that I’m not really an expert in this area. Serial connectivity with Java, and the interaction with the underlying OS is definitely a weak point of Java.

Sure - I understand. I’m just trying to help by pointing at where I think the issue is likely to be. If you can’t find the root cause, it’s hard to get the right people to look at it. If the issue is in the binding, then I can look at it, but if it’s elsewhere, then there’s probably not a lot I can do to help.

Could this be caused because the device in use by any other process ?

lsof /dev/ttyACM0

As you stated that you run OH in a VM I would suggest to run the lsof command in host as well in the guest.

1 Like

Running lsof produces nothing.

And I can’t run it in the host. The host is an ESXI hypervisor not a linux based one. If the host was configured wrongly the thing simply wouldn’t show up in the VM at all.

I ran lsof and openhab is the only process accessing the port. Still shows up as offline in the UI despite lsof reporting that openhab is accessing it. There’s several threads open on this subject since the 3.1 upgrade, some sending back to each other as potentially having the solution. unfortunately none of them do.

sorry if unrelated, but could still be worth a try

i had a similar ttyACM0 issue with z-stick gen5+ on a Pi4 after system upgrade around march/april (OH 2.5.12)

lsusb listing ZW090, but no ttyACM0 existing.
this is not your case, but since the related thread is reporting ttyACM0 switching to ttyACM1 and Zwave offline since months this could be a lead.

i tried every possible fix i could imagine or find online with my limited linux environment knowledge but i finally ended up restoring a previous openhabian 1.6.3 backup and ruled out an udev upgrade as culprit.

downgraded and put on hold.

it’s not really a solution but could be a hint or nothing at all.
i’m sorry i cannot provide more details or version numbers since i had to fix this as quick as possible and later forgot about it soon.

you could try do downgrade udev to the version included in openhabian 1.6.3

1 Like

I’ve had similar issues in the past. The following fixes it for me.


sudo nano /etc/tmpfiles.d/legacy.conf

Make sure the following is in the legacy.config file

d /run/lock 0775 root dialout -

sudo cp /usr/lib/tmpfiles.d/legacy.conf /etc/tmpfiles.d/

sudo reboot

I had similar troubles with nrjavaserial and locks it attempts to create. I spent a day or two trying to debug it and solve problem without luck.

Instead I made a serial port provider based on a plain java library called GitHub - nyholku/purejavacomm: Pure Java implementation of JavaComm SerialPort. It has no native parts. Native access for Linux/Windows/FreeBSD is provided through JNA.
I implemented a serial provider compatible with openHAB 3.x which works for me in places where rxtx can’t. Please download it and test if you wish. You will need openhab-runtime-jna installed. This serial provider ships purejavacomm 1.0.3 aligned with JNA 5.4.0 which is used in OH 3.x.

2 Likes

Hi, did you manage to sort this out? I’m trying to set up OH 3.1 in a docker container on a NUC w. Ubuntu and it can’t autodetect my Aeotec gen 5 z-wave stick…

No, I have not. I went on vacation before I could figure this out. I will probably try again once I return… or even more likely switch to Zigbee since I only have one Z-Wave device.

Ok, thanks. Trying to understand what’s going on is really difficult when not being a linux expert and this seems to have been an issue for some time. I really would love to have the z-wave gateway/controller separated from the OpenHAB-server, similar to Philips Hue…

@roli did you wind up sorting out your Z-Wave stick?

No, I have not. In the end I decided to abandon Z-Wave entirely and I am slowly transitioning everything in my house to Conbee (Zigbee).

I am sorry to hear that :frowning:
Just out of curiosity, do you happen to have your stick plugged into a physical USB hub, or have you tried that? Seemed to be a requirement for OH running on an RPi (but I believe both are Debian-based)…