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

no, see port config here

Thanks @HaKuNa. I may give this a shot. In the meantime I have a lead on the issue. If I run openHAB manually as root, the Z-Stick works. So this is definitely some sort of permissions issue even though the openhab user account should have access via the uucp group:

crw-rw---- 1 root uucp 166, 0 Dec 22 11:48 /dev/ttyACM0

uucp:x:14:openhab

I’ll let you know if I figure this out.

Getting closer. I ran the openHAB start.sh manually as the openhab user which brought me to the openHAB console and it spit out this error repeatedly:

openhab> check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file.
FAILED TO OPEN: No such file or directory

1 Like

Ok @HaKuNa and @chris I think I figured out what’s wrong. It appears that openHAB 3.0 requires access to /var/lock. On ArchLinux, this is symlinked to /run/lock, which has permissions set to 755 root root so the openhab user cannot access. /run/lock is considered a temp directory and is configured via /usr/lib/tmpfiles.d/legacy.conf, which Systemd uses to create /run/lock in volatile memory at system boot with those permissions. To override these permissions, I was able to copy legacy.conf to /etc/tmpfiles.d and adjust the permissions to 775 root uucp. After rebooting my system, /run/lock now allows the uucp group and the openhab user to access the Z-Stick and my Wave controller shows online. When I look in /run/lock, I now see a LCK…ttyACM0 file for /dev/ttyACM0, the serial port for my Z-Stick.

That said, I still consider this a workaround as I had to override a system default and this was working fine under openHAB 2.5. I’m wondering if there was a regression that now requires openHAB 3.0 to write to /var/lock when it didn’t before.

5 Likes

This is all handled in the nrjavaserial bundle. OH3 uses a newer version and I seem to recall some changes to fix some issues with locking on some variants of linux.

I can confirm that this works. Pi4 and aeotec z-stick. Simple USB hub does the trick

1 Like

it‘s not pi related

well that might be the case Remo. I do not know.

What i`m saying is the combination of OH3 + PI4 + aeotec z-stick does not work out of the box, but does work with a USB hub.

Hi, same here, Opensuse 15.2, I just upgrade from OH 2.5 to 3.0 and my Aeotec Stick doesn’t go online anymore… Everything was working fine before upgrade. I tried with and without the tty symbolic link without any success. Any idea to point me in the good direction are welcome.

If you really have the same issue as described in the 1st post, you have three options. If not, open a new thread as this one here is marked as solved.

Option 1) Use the marked solution (I know it’s a workaround)

Option 2) use this workaround (I have not yet tried it)

Option 3) Wait and hope someone will fix it permanently.

1 Like

Same problem with official docker image openhab/openhab:milestone-alpine. Docker running on Arch Linux host. It worked with OpenHab 2.5.

EDIT: in milestone-alpine x86_64 the java crashed when opening the Z-Wave bridge for configuration. In milestone-debian X86_64, the configuration page opens, however, the log shows No SerialPortIdentifier found for: /dev/ttyACM0. Interestingly, the same setup of /dev/ttyUSB0 for Ebus 3.0.10 (unofficial binding be csowada) works well.


In docker-compose.yml:

    devices:
      - "/dev/zwave-stick:/dev/ttyACM0" # See /etc/udev.d/rules/ for static naming
      - "/dev/ebus-coupler:/dev/ttyUSB0"
    environment:
      EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0 -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0"

Within the docker container, I can see that /dev/ttyACM0 is owned by root:uucp with r/w perms and that openhab is member of uucp group.
Unfortunatelly, applying chmod o+rwx -R /var/lock did not help.

I also have a local user and group openhab on Arch Linux host with the same uid and gid as the one used within the container - but no change.

[arch] # cat /etc/group | grep uucp:
uucp:x:14:openhab

[arch] # ls -la /dev/*{ACM,wave}*
crw-rw---- 1 root uucp 166, 0 Jan  1 17:40 /dev/ttyACM0
lrwxrwxrwx 1 root root      7 Jan  1 17:40 /dev/zwave-stick -> ttyACM0

[arch] # ls -la /run/lock
total 0
drwxrwxr-x  5 root uucp   100 Jan  1 17:40 .
drwxr-xr-x 27 root root   820 Jan  1 18:10 ..
drwx------  2 root root    40 Jan  1 17:40 lvm
drwxrwx---  6 root pkcs11 120 Jan  1 17:40 opencryptoki
drwxrwxr-x  2 root uucp    40 Jan  1 17:40 subsys

Thank you, I will probably open a new thread. I was wondering if I will change my Z stick as I discover that is Gen2 that is not supported anymore by Aeotec.

I have had the same challenge with the Aeotec Z-wave stick Gen5 version 1.01 as some of you describe, and maybe found some of the issue…

I started by upgrading my Openhabian 2.5.11 to 3.0.0 on Raspberry PI4, after the upgrade the Z-wave stick attach to a USB-hub was still running online.

However due to other reason I wanted to start from scratch with a clean setup using “openhabian-pi-raspios32-v1.6.2b” this default install version 3.0.0

After the installation I could not make the Z-wave to go online, spending a lot of time reading all the thread on z-wave, without solving my issue.

Ok moving on to next on the list, installing other binding like Netatmo, Network, Deconz, … all working.

Then installing Mosquitto from openHabian Configuration option 23, it did not work…, the log did show something on not access to ZRAM…

Uninstalling ZRAM, and now Mosquitto could be install, back to Z-wave Thing, Disable it, follow by Enable and now the Z-Wave went online :blush:

My old version 2.5.11 did not have ZRAM installed, but “openhabian-pi-raspios32-v1.6.2b” and version 3.0.0 by default install ZRAM

Hey all,
seems like I trapped into the same thing. My Aotec Zwave stick does not come ONLINE any more.
I tried gatekeeper6838’s option and amended the /var/lock permissions. Now OH3 is able to create the lockfile again. It contains the PID of the openhab java process.
But the controller does not come online though.
Will continue testing the USB-Hub solution, but would be good to have a proper permanent fix for this.

My system details:
Hardware: NUC with Intel Celeron D x86_64 arch
OS: Debian 8
Java: Zulu 11
OH: 3.0.0

Update:
I added an old USB hub from the 90ties between NUC and zwave stick, and it started working again. So this leds me to the conclusion that its Aotec zwave stick related. I can imagine the the usb-hub is abstracting the hardware IDs or whatnot from the stick on only forwards the data in its own name.

It seems that only the Aeotec Z-stick Gen5-plus is compatible with pi4
This is on the Aeotec side:

New Pi from Raspberry, new Z-Stick from Aeotec. As it was built upon an older Z-Wave stack, the non-plus model of Z-Stick Gen5 isn’t compatible with Raspberry 4. But Z-Stick Gen5+ is. That opens up your home automation software to Raspberry’s new architecture including 8GB of RAM and an ARM v8 1.5GHz CPU.

The Aeotec stick z-wave 5plus works fine with pi4

Thanks @gatekeeper6838 ! Your workaround did solve my issue. (Just upgraded from 2.5 to 3.0 with rpi4 Aeotec Z-Stick)
Just wanted to n00biefy the steps incase someone as noob as me comes by

sudo nano /usr/lib/tmpfiles.d/legacy.conf
change:
d /run/lock 0755 root root -
to
d /run/lock 0775 root root -

(feel free to correct the steps if they are incorrect or somewhat dangerous)

I’ve just changed the above as per @putrid posted.

Ive got a z-stick with a rpi4 into a 7 port usb hub.

[13:29:13] openhabian@openHABianDevice:~$ sudo lsusb
Bus 002 Device 009: ID 05e3:0617 Genesys Logic, Inc. 
Bus 002 Device 008: ID 05e3:0617 Genesys Logic, Inc. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 028: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 026: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 025: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

ive tried using the following as the serial port without any luck
/dev/ttyAMA0
/dev/ttyACM4
/dev/ttyAMA0
ttyAMA0
ttyACM4
ttyAMA0

[13:26:30] openhabian@openHABianDevice:~$ ll /dev | grep tty
crw-rw-rw-  1 root tty       5,   2 Jan 11 13:29 ptmx
lrwxrwxrwx  1 root root           7 Jan  2 18:55 serial1 -> ttyAMA0
crw-rw-rw-  1 root tty       5,   0 Jan 11 13:14 tty
crw--w----  1 root tty       4,   0 Jan  2 18:55 tty0
crw--w----  1 root tty       4,   1 Jan  2 21:48 tty1
crw--w----  1 root tty       4,  10 Jan  2 18:55 tty10
crw--w----  1 root tty       4,  11 Jan  2 18:55 tty11
crw--w----  1 root tty       4,  12 Jan  2 18:55 tty12
crw--w----  1 root tty       4,  13 Jan  2 18:55 tty13
crw--w----  1 root tty       4,  14 Jan  2 18:55 tty14
crw--w----  1 root tty       4,  15 Jan  2 18:55 tty15
crw--w----  1 root tty       4,  16 Jan  2 18:55 tty16
crw--w----  1 root tty       4,  17 Jan  2 18:55 tty17
crw--w----  1 root tty       4,  18 Jan  2 18:55 tty18
crw--w----  1 root tty       4,  19 Jan  2 18:55 tty19
crw--w----  1 root tty       4,   2 Jan  2 18:55 tty2
crw--w----  1 root tty       4,  20 Jan  2 18:55 tty20
crw--w----  1 root tty       4,  21 Jan  2 18:55 tty21
crw--w----  1 root tty       4,  22 Jan  2 18:55 tty22
crw--w----  1 root tty       4,  23 Jan  2 18:55 tty23
crw--w----  1 root tty       4,  24 Jan  2 18:55 tty24
crw--w----  1 root tty       4,  25 Jan  2 18:55 tty25
crw--w----  1 root tty       4,  26 Jan  2 18:55 tty26
crw--w----  1 root tty       4,  27 Jan  2 18:55 tty27
crw--w----  1 root tty       4,  28 Jan  2 18:55 tty28
crw--w----  1 root tty       4,  29 Jan  2 18:55 tty29
crw--w----  1 root tty       4,   3 Jan  2 18:55 tty3
crw--w----  1 root tty       4,  30 Jan  2 18:55 tty30
crw--w----  1 root tty       4,  31 Jan  2 18:55 tty31
crw--w----  1 root tty       4,  32 Jan  2 18:55 tty32
crw--w----  1 root tty       4,  33 Jan  2 18:55 tty33
crw--w----  1 root tty       4,  34 Jan  2 18:55 tty34
crw--w----  1 root tty       4,  35 Jan  2 18:55 tty35
crw--w----  1 root tty       4,  36 Jan  2 18:55 tty36
crw--w----  1 root tty       4,  37 Jan  2 18:55 tty37
crw--w----  1 root tty       4,  38 Jan  2 18:55 tty38
crw--w----  1 root tty       4,  39 Jan  2 18:55 tty39
crw--w----  1 root tty       4,   4 Jan  2 18:55 tty4
crw--w----  1 root tty       4,  40 Jan  2 18:55 tty40
crw--w----  1 root tty       4,  41 Jan  2 18:55 tty41
crw--w----  1 root tty       4,  42 Jan  2 18:55 tty42
crw--w----  1 root tty       4,  43 Jan  2 18:55 tty43
crw--w----  1 root tty       4,  44 Jan  2 18:55 tty44
crw--w----  1 root tty       4,  45 Jan  2 18:55 tty45
crw--w----  1 root tty       4,  46 Jan  2 18:55 tty46
crw--w----  1 root tty       4,  47 Jan  2 18:55 tty47
crw--w----  1 root tty       4,  48 Jan  2 18:55 tty48
crw--w----  1 root tty       4,  49 Jan  2 18:55 tty49
crw--w----  1 root tty       4,   5 Jan  2 18:55 tty5
crw--w----  1 root tty       4,  50 Jan  2 18:55 tty50
crw--w----  1 root tty       4,  51 Jan  2 18:55 tty51
crw--w----  1 root tty       4,  52 Jan  2 18:55 tty52
crw--w----  1 root tty       4,  53 Jan  2 18:55 tty53
crw--w----  1 root tty       4,  54 Jan  2 18:55 tty54
crw--w----  1 root tty       4,  55 Jan  2 18:55 tty55
crw--w----  1 root tty       4,  56 Jan  2 18:55 tty56
crw--w----  1 root tty       4,  57 Jan  2 18:55 tty57
crw--w----  1 root tty       4,  58 Jan  2 18:55 tty58
crw--w----  1 root tty       4,  59 Jan  2 18:55 tty59
crw--w----  1 root tty       4,   6 Jan  2 18:55 tty6
crw--w----  1 root tty       4,  60 Jan  2 18:55 tty60
crw--w----  1 root tty       4,  61 Jan  2 18:55 tty61
crw--w----  1 root tty       4,  62 Jan  2 18:55 tty62
crw--w----  1 root tty       4,  63 Jan  2 18:55 tty63
crw--w----  1 root tty       4,   7 Jan  2 18:55 tty7
crw--w----  1 root tty       4,   8 Jan  2 18:55 tty8
crw--w----  1 root tty       4,   9 Jan  2 18:55 tty9
crw-rw----  1 root dialout 166,   4 Jan 11 13:26 ttyACM4
crw-rw----  1 root dialout 204,  64 Jan  2 18:59 ttyAMA0
crw-------  1 root root      5,   3 Jan  2 18:55 ttyprintk
crw-rw----  1 root tty       7,   0 Jan  2 18:55 vcs
crw-rw----  1 root tty       7,   1 Jan  2 18:55 vcs1
crw-rw----  1 root tty       7,   2 Jan  2 18:55 vcs2
crw-rw----  1 root tty       7,   3 Jan  2 18:55 vcs3
crw-rw----  1 root tty       7,   4 Jan  2 18:55 vcs4
crw-rw----  1 root tty       7,   5 Jan  2 18:55 vcs5
crw-rw----  1 root tty       7,   6 Jan  2 18:55 vcs6
crw-rw----  1 root tty       7, 128 Jan  2 18:55 vcsa
crw-rw----  1 root tty       7, 129 Jan  2 18:55 vcsa1
crw-rw----  1 root tty       7, 130 Jan  2 18:55 vcsa2
crw-rw----  1 root tty       7, 131 Jan  2 18:55 vcsa3
crw-rw----  1 root tty       7, 132 Jan  2 18:55 vcsa4
crw-rw----  1 root tty       7, 133 Jan  2 18:55 vcsa5
crw-rw----  1 root tty       7, 134 Jan  2 18:55 vcsa6
crw-rw----  1 root tty       7,  64 Jan  2 18:55 vcsu
crw-rw----  1 root tty       7,  65 Jan  2 18:55 vcsu1
crw-rw----  1 root tty       7,  66 Jan  2 18:55 vcsu2
crw-rw----  1 root tty       7,  67 Jan  2 18:55 vcsu3
crw-rw----  1 root tty       7,  68 Jan  2 18:55 vcsu4
crw-rw----  1 root tty       7,  69 Jan  2 18:55 vcsu5
crw-rw----  1 root tty       7,  70 Jan  2 18:55 vcsu6
```.
Any help would be appreciated

I may have done a totalt reboot after the changes above. I cant recall

try:
dmesg | grep tty

My Port Configurations was /dev/ttyACM0


image

I dont recall if I did a soft-reset or a sudo systemctl restart openhab.service after the change of Serial Port

My skills are very limited. Hope someone may be of better assistance for you, if this does not solve your problem

Restarting the service wasn’t enough for me and I restarted the VM instead. Thanks for your tips, very useful