[SOLVED] OH3: zwave binding Z-Wave Serial Controller Aeotec Z-Stick Gen5 remains offline

Hi,

have the same issue on my QNAP NAS with OH3 docker. But can’t find “legacy.conf”? Any ideas?

Thanks in advance

Rgds
André

I’m not super familiar with docker or QNAP’s OS, but I can ask a few questions that might helps steer you in the right direction.

Have you confirmed that the QNAP OS sees the USB interface? Run dmesg | grep tty on the QNAP to see what shows up. If your USB interface doesn’t appear, you’ll need to figure that out first, before passing it down to the container.

Have you presented the USB to the container through passthrough or some other means? This stackoverflow issue suggests how this might be done.

Listing out any configuration changes that you’ve made may help diagnose the issue as well as potentially help others with the same problem.

I am having the same weird issue all of a sudden. The weird thing is that this was working just fine for months after switching to OH3. But after a reboot it just suddenly stopped working. I am running Openhab 3 in a virtual machine on top of Ubuntu. And looking at
/usr/lib/tmpfiles.d/legacy.conf
I don’t see the
d /run/lock 0775 root root -
line anywhere. The closest to that is
d /run/lock/subsys 0755 root root -

I’ve tried adding it but that didn’t help. Any ideas?

What OS is your VM? Have you confirmed that the OS can see the device through dmesg?

I worded it a bit wrong when I first wrote my post. Openhab is running on Ubuntu (which could see the z-wave device just fine). And the virtual machine is running on vmware-esxi.

I have finally fixed the issue yesterday. I forgot to copy the legacy.conf to etc/tmpfiles.d. So in the end what I did was 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/
1 Like

Hi @HaKuNa ,

i wanted to try your workaround too, cause i have the same issue.
In OH2.5 the access to /dev/ttyACM0 is working without a problem, but on OH3 not.

As i run my OH on Docker i’m not 100% shure how to setup ser2net.
Also in my case it is not a ser2net.conf but a ser2net.yaml

What I wanted to clarifiy was: What you have given under “Port configuration” is the content of the Zwave Config, right? Normaly something like “/dev/ttyACM0” or something would be listed there. But for ser2net i would need " rfc2217://127.0.0.1:3001" ?
Did i understood your workaround correctly? (Maybe the IP has to be adapted, because not from this machine, but from the docker machine, but this is only a detail.

Because i get only the following errors:

java.net.SocketException: Broken pipe (Write failed)

In the meantime I use workaround #2:

You can find my ser2net config in the link to workaround #1

Looks promising, but on a Synology Diskstation they did not used the Systemd, so no legacy.conf to edit.
So at least for me on a Synology Diskstation with OH3 inside a Docker this is not working, sadly.

Anybody a idea what could be done to solve this issue?

I think might get you going.

Synology, Docker, OH3, Z-Wave working without root access

1 Like

My Aeotec Z-Stick stopped working suddenly (Ubuntu 20.04, OH 3.0.1). No explainable reason. Tried everything. This brought it back to life.

This z-wave stuff makes me crazy, but I think now I found the solution with OH3, RPI4 and Aeotec Stick.

As written above, I started 2018 with ZMEEUZB1 and change to Aeotec Gen5 V1 on my OH2.5, but never a real stable z-wave network.

After migration to OH3 the stick was only found with an activce USB hub, but totally instable on USB 2.0 and USB 3.0 port.

I tried a lot with z-wave configuration (e.g. polling time, etc.) for conutroller and devices, but without success.

Then I bought the new Aeotec Gen5 Plus Stick which should be RPI4 compatible and paired all device (just 8 fibaro switches and 1 battary) new. I put the Stick to USB 2.0 (because 2nd USB 3.0 Port is difficult to use, because of USB SSD in USB 3.0 Port 1).

Everthing was running stable for about 3 or 4 days, before it was getting instable like “Node is not communication with controller” again over the hole day. Using the Stick in PC with Domoticz everthing works fine.

Just before throwing the hole z-wave stuff away I put the Aeotec Stick in USB 3.0, and since 2 weeks everthing runs stable with a very quick response time. unbeliebale!!

Current stable config: OH3.1 M2, RPI4, Aeotec Gen5+ in USB 3.0 (!!). May be this helps someone :slight_smile:

So today I updated my Openhab from 3.0.x to 3.1 and guess what? The not working z-wave issue is back.

Same error as before:

2021-07-04 03:20:14.194 [DEBUG] [ort.serial.internal.RxTxPortProvider] - No SerialPortIdentifier found for: /dev/ttyACM0

The workaround that I mentioned a few posts above is still in place. Looking at /dev/:

crw-rw----  1 root dialout 166,   0 Jul  4 02:42 ttyACM0

The device is there and belongs to the dialout group, same as OH. So everything should be working - as it did before the 3.1 upgrade.

Any ideas why this would break again with OH 3.1?

1 Like

Same issue here. OH3.1 and Ubuntu 20.04

Debug_log_serial.txt (77.8 KB)

Grasping at straws here but have you rebooted? IME there is sometimes a weird interaction with the file ownership, group membership and, in your case, the dialout group.

A few ideas to try to work out if its an OS permissions issue or a OH3 issue:

And did you do a manual install or repo install?

With OH2.5, no problems with 2 identical ZWAVE GEN5 sticks.
When I upgraded to OH3, a lot of issues when I rebooted my server. Stopping, starting, clearing cache… and suddenly, it started working. So I was afraid of rebooting it. :cry:
I had to reboot my server today, and again issues. So instead of fooling around with OH3, I decided to upgrade my machine to all latest version, hoping that the issue was resolved.
But no luck anymore with the zwave sticks.

Some additional info about my current setup:

  • Hardware: Dell R720 server
  • Virtual machine under Proxmox 6, VM is running now Ubuntu 21.04
  • openHAB 3.1.0 - Release Build
  • 2x Zwave stick GEN5

lsusb

Bus 003 Device 003: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 003 Device 002: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

dmesg -T | grep ttyA

[Wed Jul 21 18:06:23 2021] cdc_acm 3-1:1.0: ttyACM0: USB ACM device
[Wed Jul 21 18:06:23 2021] cdc_acm 3-2:1.0: ttyACM1: USB ACM device

ll /dev/ttyA*

crw-rw---- 1 root dialout 166, 0 Jul 21 18:06 /dev/ttyACM0
crw-rw---- 1 root dialout 166, 1 Jul 21 18:06 /dev/ttyACM1

/etc/tmpfiles.d/legacy.conf

d /run/lock 0775 root root -

files are being created in the lock folder:
ll /run/lock/

-rw-r–r-- 1 openhab openhab 11 Jul 21 20:26 LCK…ttyACM0
-rw-r–r-- 1 openhab openhab 11 Jul 21 20:26 LCK…ttyACM1

/etc/default/openhab

EXTRA_JAVA_OPTS=“-Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyACM1”

I tried about 10 reboots, reinstall the binding, restart 10 times the binding, 5 openhab-cli clean-cache…
But no luck so far. :cry:

In attachment some debugs…
zwavedebug.txt (55.8 KB)

The only thing I didn’t tried, is a USB Hub. But since it was working for several years with the exact same setup, hard to believe that this could be the issue. :blush:

OH3 is the culprit for sure.
But I can live with the ser2net workaround on CentOS8.

1 Like

Just tried this with ubuntu (yaml file instead of config), but no luck. Can’t get the sticks coming online. :cry:
Maybe 1 strange thing I noticed with “netstat -an | grep 3001”, seems that this is only listening on tcp6? Not on tcp4? Not sure if it’s needed, but …

this is the output from CentOS8

# netstat -apn | grep 3001
tcp6       0      0 :::3001                 :::*                    LISTEN      11062/ser2net

That depends on if dualstack mode is disabled or not and on the OS that is being used.
See e.g. linux - Semantics of :: and 0.0.0.0 in dual-stack OSes - Server Fault

have you configured the thing port correctly?
and is a firewall active in the system? if yes try to disable it temporary.