I updated to last zwave binding (3.1.0M1) and set the polling period off the zwave actors (fibaro double switch) from 1500 to 5000.
Now everything runs fine and I have a very fast reaction time, when switching on or off.
Maybe this information could help someone who fight with Aeotec Stick, too
Has anyone figured out how to solve this for a Raspberry Pi (3B+) with openhabian (3.0.1)? Neither: sudo nano /usr/lib/tmpfiles.d/legacy.conf
nor cp /usr/lib/tmpfiles.d/legacy.conf /etc/tmpfiles.d/ sudo nano /etc/tmpfiles.d/legacy.conf
seems to work
(In both cases followed by changing: d /run/lock 0755 root root -
to d /run/lock 0775 root root -
I still get the Bridge_Offline (Controller is offline) error. I deleted the Thing between trying each approach, and threw in some reboots for good measure!
I’ve got a few notes from my own install that I can pass onto you. Aside from the legacy.conf change, you don’t mention anything else, so I’ll post everything I have, including information in the first post as a general summary. Feel free to jump over what you don’t need. I would note that my OS is Centos 7, but these changes should translate.
I read somewhere (and I can’t find where in the forums now) that some people were having issues with the built in USB ports on the Raspberry Pi. An external USB hub may help the physical device to be seen. Make sure the one you use supports UART. To confirm if your hub is even being seen by the OS, run dmesg | grep tty. You should see a device show up and if it’s attached to anything, it should say as much. In my case, I see [ 7.245376] usb 1-1.3.4: cp210x converter now attached to ttyUSB0 [ 7.265568] usb 1-1.3.4: cp210x converter now attached to ttyUSB1
Make sure you’ve set EXTRA_JAVA_OPTS in your /etc/default/openhab config file.
Change the legacy.conf file as you did. However, I ended up changing the line you edited to d /run/lock 0755 root lock -. Note that the group is set to lock. I also added the openhab user to that group. Finally, I modified the permissions on /run/lock with chmod g+w /run/lock. Once done, the controller should come online. There is a caveat, however. Every time I reboot, I have to run the chmod command again. Annoying, but workable for the time being.
If none of that does it, list out everything you’ve tried and I can try to help further.
Thanks - that seems to have solved it. My set-up is Raspberry Pi (3B+) with openhabian (3.0.1). Aeotec Z-Stick Gen 5 plugged directly into USB on Pi (no hub). Note, I had no issues previously when using openhab 2.5 on this hardware.
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?
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):
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.
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?