hardware? os?
VM on QNAP virtualisation station, USB3 (has worked on this configuration for years) - Ubuntu 20.x
Then I suggest to open a new thread.
Different HW, different OS and this thread here is marked as solved. There are 2 ways descibed as solution and both are working.
Using info from elsewhere I ran after stopping instance
sudo open-cli start
Stopped it
then ran openhab as service as at boot and voila worked fine
I have zigbee - ttyUSB*
and ZWave - ttyACM*
It is only the ACM that is the problem USB works fine
Hello,
I’ve got the same issue with a basic VM and OH3.1
it looks like openhab is trying to create its lock file in /run/lock
so I’ve just do a chmod 777 /var/lock and it solved the issue.
The unique drawback (except security 
) is that it needs to be done every reboot.
Any idea to let openhab put its lock somewhere else ?
Thank
I think one of the reasons that this happens that the lock is created by a different user than the the one that is used when OH is started automatically. This for example can happen when you start OH manually via sudo and then reboot. At least that was once the root cause why this happened to me. Can you check which user has written the lock and compare that with the user that OH runs with?
yes, easy , the folder is supposed to be writable by root only, and openhab is started as a service via systemctl and run as openhab user
I’ve reread another post and found maybe an entry to change the default mode on the lock folder (need to reboot again to see the result)
But maybe the path could be somewhere else where openhab (or other) user has writing rights.
Or add somekind of self checkup to warm user to change the default OS setup to allow write rights ?
Thanks
Hey
I didn´t manage it to get the Aeotec Stick running on my RPi4 and OH3.2.0
All the configs in the treads failed
My Elero Stick (ttyUSB0) is working fine and showen up, but the ZWave Stick not:
~ $ dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=0 bcm2708_fb.fbheight=0 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:9E:D2:53 vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000 console=ttyS0,115200 console=tty1 root=PARTUUID=4d915286-02 rootfstype=ext4 fsck.repair=yes rootwait
[ 0.001824] printk: console [tty1] enabled
[ 1.461311] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 36, base_baud = 0) is a PL011 rev2
[ 3.142609] systemd[1]: Created slice system-getty.slice.
[ 5.428786] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
I want to try it with an hub.
Do I need an active or passive hub in between?
THX René
Either hub will work. I like the idea of powered so the radio signal is not degraded if the pi starts to get busy.
Bob
Is the USB version of the hub relevant?
It should be usb 2.0.
Bob
1 Like
I can confirm that the Gen5 works with a USB2 hub (it has an issue related with RPI internal resistor setup which is kind of fixed when using the hub) as already mentioned. I eventually changed to the newer GEN5+ which works on the RPI4 directly without the hub.
For some users the hub solution works, for others - like myself - this did not solve it.
I ended up selling the stick, replacing it by a Z-Wave HAT for 10 Euro and now having a rock solid Z-Wave controller plus the Z-Ways software that helps managing the network, where the binding has its limitations.
Never figured out what was the root cause why the stick went offline from time to time.
Maybe the stick pulls a lot of power from the USB, maybe other hard- or software issues. 
So it may be a valid scenario to simply replace the stick before the network grows and it becomes hard to do so.
It works for me after (in karaf):
feature:install openhab-transport-serial
and
bundle:start org.openhab.binding.zwave
This is the real solution. You might get it to work somewhat with an external USB hub, or other workarounds, but the real cause of the problem is quite simple:
There are 3 versions of the Aeotec Z-Stick Gen5 in addition to Aeotec Z-Stick Gen5+, so there are 4 versions of this stick in total. The two earliest versions doesn’t follow the USB specification during “handshake”. The last “non-pluss version” and the “pluss version” have been redesign to address the problem.
It turns out that most equipment don’t care if the stick isn’t behaving as it should, so it was never “revealed”. This includes all RPis prior to version 4. RPi 4 however, has a new USB controller that isn’t as forgiving, so it will reject the stick most of the time. You can get lucky at times, but it won’t be stable. But, since the least iterations of the stick is fixed, and you can’t tell them apart by looking at them, some will work on the RPi while others won’t.
I had the same problem and read through lots of threads on the subject before I found the thread with the real fix at the HA forum. I have done the “mod”, and it’s absolutely day and night. The stick is detected instantly, and it’s there without disappearing during reboots etc.
If you have a solder station with a small (electronics) tip, some magnification equipment and a steady hand: go for it. It’s not complicated at all, it’s just very small. The resistor you have to “reroute” is extremely tiny, and I managed to lose mine when I tried to pick it up with some tweezers. I never found it again, it’s virtually impossible to recover if you lose sight of it.
So, I would recommend anybody that are to do this to have a “regular” 1.5kΩ resistor available in case you lose or break the tiny one. I didn’t, so I had to get creative and use what I could find at home, so I ended up with 3x 390Ω and 1x 330Ω resistors soldered in series. It’s not pretty, but it works perfectly. I could even get the cover back on despite the 4 “huge” resistors, so you can’t tell that it’s been modified.
Here is another link to the thread with the solution:
2 Likes
In Centos 7, the group has to be changed to “lock”, of which openhab is made a member of during installation. So:
d /run/lock 0775 root lock -
The thread is solved for a long time and I use CentOS8. And you are replying to a post which is 8 month old ???
Yes
I am using a Aeotec Z-stick Gen5 with OH3.4 on a Windows 10 machine. I was having issues with the Z-stick Thing going OFFLINE after machine reboots or a restart of the OH service, and not coming back online until the stick was physically unplugged and replugged.
I did the soldering fix above and so far my Z-stick has come back online after a reboot and a service restart. So seems to have worked successfully so far.
1 Like
Quick follow up -
This soldering fix has substantially improved the reliability of my Z-wave network, as well as my confidence in it.
If only Aeotec had made a quality product to begin with!
1 Like