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?
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 
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
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:
- Can use screen to connect to the serial device (20.5.2. Using screen to Connect to the Serial Console)
- Can you use a NodeJS Z-Wave library to open the device?
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. 
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.
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. 
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.
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.
I had following ports in the paperUI:
- rfc2217://127.0.0.1:3001
- rfc2217://127.0.0.1:3002
These correspond with the ports in the yaml file, and that were listening (netstat).
No local firewall in place.
I trust only on my central firewall. Much easier to maintain it all. 
Current status: I just booted my old virtual server (I took a clone before upgrading). And after restarting that one machine 3 times, clearing the cache 2 times, and perform a soft reset of the sticks, 1 stick is now up and running?
Configuration is 99,99% identical for stick 1 and 2. Very weird.
7 hours of chasing down this issue. Will have another try tomorrow… With a fresh head, new motiviation…
Not an expert, never ran two z-stacks. From the partial log it looks like two different UIDs on the Zsticks. Deactivate zwave:serial_zstick:2f4ef5d0;Active zwave:serial_zstick:30038385 What UID do the nodes have? Are there two separate networks? Anyway if it was I, I might just try to get one working first and make sure the node UIDs have the same as the Zstick. Just thoughts.
Indeed, 2 different UID’s, different wireless networks… Reason is that I’ve got a house, and a studio, about 30m from each other, with very bad bricks for wireless signals. But for several years, this is working fine.
- Stick 1: 30038385
- Stick 2: 2f4ef5d0
After restarting/cleaning/… my setup from before (same hardware, just different virtual machine), 1 stick came online. I just now restarted openhab on this machine, and both sticks are back offline. grrrr, getting crazy about this, very unreliably…
Trying the ser2net workaround:
cat /etc/ser2net.yaml
connection: &con0096
accepter: tcp,3001
enable: on
options:
kickolduser: true
connector: serialdev,/dev/ttyACM0,115200n81,local
connection: &con1096
accepter: tcp,3002
enable: on
options:
kickolduser: true
connector: serialdev,/dev/ttyACM1,115200n81,local
systemctl status ser2net
● ser2net.service - Serial port to network proxy
Loaded: loaded (/lib/systemd/system/ser2net.service; disabled; vendor preset: enabled)
Active: active (running) since Thu 2021-07-22 08:11:05 CEST; 3s ago
Docs: man:ser2net(8)
Main PID: 6202 (ser2net)
Tasks: 1 (limit: 19105)
Memory: 1.0M
CGroup: /system.slice/ser2net.service
└─6202 /usr/sbin/ser2net -n -c /etc/ser2net.yaml -P /run/ser2net.pid
Jul 22 08:11:05 doornroosje systemd[1]: Starting Serial port to network proxy...
Jul 22 08:11:05 doornroosje systemd[1]: Started Serial port to network proxy.
netstat -apn | grep ser2net
tcp6 0 0 :::3001 :::* LISTEN 6202/ser2net
tcp6 0 0 :::3002 :::* LISTEN 6202/ser2net
unix 3 [ ] STREAM CONNECTED 1137419 6202/ser2net
unix 3 [ ] STREAM CONNECTED 1137417 6202/ser2net
telnet 127.0.0.1 3001
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
1"�
1"�
1"�
1"�
Configuration in paperUI for the serial port on stick 1:
rfc2217://127.0.0.1:3001
Configuration in paperUI for the serial port on stick 2:
rfc2217://127.0.0.1:3002
And the output of some logs:
2021-07-22 08:28:14.651 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2021-07-22 08:28:14.652 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2021-07-22 08:28:14.653 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2021-07-22 08:28:14.656 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2021-07-22 08:28:14.657 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2021-07-22 08:28:14.660 [DEBUG] [ve.internal.protocol.ZWaveController] - Shutting down ZWave controller
2021-07-22 08:28:14.661 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Shutting down transaction manager
2021-07-22 08:28:14.664 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Exiting ZWave Receive Thread
2021-07-22 08:28:14.665 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction manager shutdown
2021-07-22 08:28:14.666 [DEBUG] [ve.internal.protocol.ZWaveController] - ZWave controller shutdown
2021-07-22 08:28:14.667 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2021-07-22 08:28:14.668 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:30038385.
2021-07-22 08:28:14.885 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:30038385
2021-07-22 08:28:15.718 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 49 06 31 05 01 22 00 EA 45
2021-07-22 08:28:15.724 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=73, callback=0, payload=00 49 06 31 05 01 22 00 EA
2021-07-22 08:28:15.727 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=73, callback=0, payload=00 49 06 31 05 01 22 00 EA
2021-07-22 08:28:15.728 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-07-22 08:28:15.729 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 73: Not initialized (ie node unknown), ignoring message.
2021-07-22 08:28:15.729 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
PaperUI
I’ve also removed the sticks from paperUI, and recreated them with the same UID, but no luck.
Any suggestion is welcome.
1 Like