Problem with setting up Zooz USB Z-Wave Plus S2 Stick ZST10

It’s what comes with openHABian.

openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-post-Raspbian-2deb10u1)
OpenJDK Server VM (build 11.0.12+7-post-Raspbian-2deb10u1, mixed mode)

Here are the contents of the /etc/udev/rules.d/99-com.rules file on my openHAB RPi. I compared the ttyAMA0 section to the 99-com.rules file on my other RPi (an octoPrint server) and it’s identical.

SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"
SUBSYSTEM=="rpivid-*", GROUP="video", MODE="0660"

KERNEL=="vcsm-cma", GROUP="video", MODE="0660"
SUBSYSTEM=="dma_heap", GROUP="video", MODE="0660"

SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
SUBSYSTEM=="gpio", KERNEL=="gpiochip*", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys/class/gpio && chmod -R g=u /sys/class/gpio'"
SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys%p && chmod -R g=u /sys%p'"

# PWM export results in a "change" action on the pwmchip device (not "add" of a new device), so match actions other than "remove".
SUBSYSTEM=="pwm", ACTION!="remove", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys%p && chmod -R g=u /sys%p'"

KERNEL=="ttyAMA0", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \
                echo 0;\
        elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi\
'", SYMLINK+="serial%c"

KERNEL=="ttyAMA1", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if [ -e /dev/ttyAMA0 ]; then \
                exit 1; \
        elif cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \
                echo 0;\
        elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi\
'", SYMLINK+="serial%c"

KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $$ALIASES/uart1 $$ALIASES/serial0; then \

Hi Russ:

Thanks for sticking with me!

This is a good idea. The Windows VM is on a completely different system. I’ll spin up “regular” openHAB on that system to see whether it has the same issue with this Zooz stick.

That’s actually one of the first things I did . . . even before I first posted here, I think. I have done it a couple times. Today I completely purged openHAB from the system to see whether I would have a different result after the “reset” of the stick on the different system. Same negative result, unfortunately.

Except that it was actually on a different system as noted above. I will try openHAB there in a bit.

That report is definitely a bit different than mine (also in version # – mine is newer). Perhaps OH is truly using Adop(tium)OpenJDK instead of “vanilla” OpenJDK

Wow. That’s a pretty extensive and complex udev. I usually only set these up to deal with Android phones and make them easy to target with AndroidSDK’s adb and other commands. Usually just one line per device . . .

You will note that our Zooz stick is part of a fairly complex loop – in part:

This further convinces me my server’s lack of such a udev rule may be (a significant?) part of the problem. Fully understanding this loop is likely beyond the time I want to commit to trying to get openHAB to work with this hardware!

I’ll try a new install on another platform first.

I’m running OH on a RasPi and have the same udev-file as rpwong. And the controller is represented as “/dev/ttyACM0” as well.
Note that “/dev/ttyACM0” is not the same as “/dev/ttyAMA0”, so I don’t think the udev-rules affect the controller device.

To summarize the setup, that is working here:
Port of the controller is “/dev/ttyACM0”.
Owner of the port is root with permissions “rw”.
Group of the port is “dialout” with permissions “rw”.

The user “openhab” (running the installation) is member of the following groups: tty, dialout, audio, bluetooth.
And there is the group “openhab” as well, which is the default group for the user “openhab”. No one else is member of that group.

To finalize it, here the output for the java version:

java -version
openjdk version "11.0.14" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14+9-post-Raspbian-1deb11u1)
OpenJDK Server VM (build 11.0.14+9-post-Raspbian-1deb11u1, mixed mode)

The controller is a UZB-1 and worked in OH 1.8 till OH 3.2.
The binding treats all controllers the same, regardless of the vendor.

One last idea from my side, Felix: Do you use the ZWave binding that comes with the OH installation or is it a snapshot you installed yourself? If it is the latter, the standard ZWave binding should be removed/uninstalled and in some cases the serial binding needs to be installed so that the ZWAVE binding can talk to the port representing the controller.

That is an interesting observation.

Do you think adding the serial binding might fix any missing dependencies that are lacking in some platforms? It is certainly not going to do anything harmful.

Installing bindings via GUI takes care of dependencies like this. It is only necessary to look at it when bundles are installed manually via dropping them into the addon folder. In this case the dependencies need to be taken care of by the user. Usually there should be an error message of some kind if something is missing. It’s been a long time ago that I ran into such a situation, so I cannot tell if a helpful message will occur in this case, I did not test it with OH 3.2.

Hi @stefan.oh and @robmac

Thanks for sticking with me! Sorry I was away for a day – other stuff intervened.

One thing I did accomplish yesterday (in relation to HomeAutomation here at my Mom’s house) was to have a conversation with Agnes at Zooz yesterday morning. There is no doubt that the Zooz stick is operational, so that is good! Using “PC Controller” I was unable to exclude the old Z-Wave switches, so I bought a handful more which will arrive later this afternoon. [ I don’t have a laptop here, so I can’t get the Zooz USB stick close enough (to exclude older, cheap Z-Wave switches). I’ll work on them when I get back to my own home and have a significantly better setup. ]

Meanwhile . . .

I reread the udev rule only after I posted my prior comments and saw the difference. I agree that this rule does not seem to affect the Zooz controller. Still, the fact there is no udev rule on my system at all when you (everyone?) have it is puzzling!

I just did a reinstall, a few moments ago. This time I installed the recommended " Azul Zulu Build of OpenJDK"

My new install reports the same!

Well, I am at a different openjdk version as I have installed as recommended for a new OH 3.2 installation (and am NOT on an RPI ):

openjdk version "11.0.14.1" 2022-02-08 LTS
OpenJDK Runtime Environment Zulu11.54+25-CA (build 11.0.14.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.54+25-CA (build 11.0.14.1+1-LTS, mixed mode)

As this is the official OH 3.2 reccommendation, this difference is not likely germane.

This is very good to know. Alas, still no joy.

I installed through the OH webpage at localhost:8080 This is pretty much the first thing it suggests after inputting a new UID, PW and location

Man – this seemed sooo promising! I was very excited when I read this as I know the original OH installation on this host did not have this binding installed.

I installed that binding. Unfortunately, the controller is still offline.

Did you ever try the LCK file permissions either from my post or the second solution in the thread @robmac posted? Or run OH as root as @mhilbush suggested?

Here’s a short story. I create a modified zwave binding for a variety of reasons (unimportant here). I recently tried a shortcut and controller would not start :frowning_face: I restarted OH and everything came back :smiley: Interesting in relation to this thread is this;

note the removal of the LCK file

Also info level logging for this same restart showed this ;

Note the time of the stale lock removal and the first INFO (controller is null).

Lastly I found an earlier Debug log level start-up

The debug you posted above is identical but doesn’t connect to the serial port. Since all the other permissions seem in place, it seems like the LCK file or something specific to the serial port. Maybe that will narrow down your search.

On the serial binding there is an obvious error message (unfortunately I run across this when I get sloppy). I found a recent post showing the message and solution.


I do not think that is an issue here because you would have noticed.

Bob

Hi All:

This was a nonstarter. As I thought about it (if I thought it through correctly . . .), I would have needed to emulate RPI hardware.

I did quickly install OH on a LinuxMint 20.3 machine about a half hour ago.

[EDIT: the idea being it might work differently on an Ubuntu/Debian-based distro than a Fedora/RedHat-based distro ]

Same (not working Zooz stick) result.

Hi Bob @apella12

)*^#$@%!!

Sorry, I missed coming back to that, which I was going to do a couple nights ago.

OK:

hostname.redacted@redacted: ~$ sudo systemctl status openhab.service

● openhab.service - openHAB - empowering the smart home
Loaded: loaded (/usr/lib/systemd/system/openhab.service; disabled; vendor preset: disabled)
Active: active (running) since Fri 2022-04-01 14:15:41 PDT; 1h 37min ago
Docs: Introduction | openHAB
https://community.openhab.org
Main PID: 7254 (java)
Tasks: 118 (limit: 18738)
Memory: 1001.8M
CPU: 1min 40.123s
CGroup: /system.slice/openhab.service
└─7254 /usr/bin/java -XX:-UsePerfData -Dopenhab.home=/usr/share/openhab -Dopenhab.conf=/etc/openhab -Dopenhab.runtime=/usr/share/openhab/runtime -Dopenhab.userdata=/var/lib/openhab -Dopenhab.logdir=>

Apr 01 15:52:22 hostname.redacted karaf[7254]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file.
Apr 01 15:52:22 hostname.redacted karaf[7254]: FAILED TO OPEN: No such file or directory

Indeed, there is no relevant file at /run/lock

please stand by a few moments while I figure out how to start openHAB manually

I believe it is linked via /var/lock. Try that.

That message in karat seems to point that way. Edit: I mean this

Bob

1 Like

Hi @apella12 @mhilbush @robmac @rpwong @stefan.oh and anyone else I may have overlooked

OK, the easiest way I could see to do this (i.e. run openhab as root) quickly (since there are a bunch of startup parameters I do not yet know or understand) was to edit the openhab.service and set the user and group arguments to “root”

OK, now we are getting somewhere.

sudo systemctl status openhab.service reports no error!

Lock file appears:

Zooz Z-Wave USB stick available and online!


Please understand I know this is not safe(!) way of operating and I have already stopped the service running as root!


I am quite embarrassed to have overlooked my note to follow up on this “test” instruction the other night. Sorry to have wasted more time for everyone on on this!

That said . . . The question now is how to best address this (both for me and the larger community)?

At the macro level: This looks like a pretty major oversight in the openHAB codebase and from what I can see has been biting people in the rear for at least 1.5 years (i.e. since the Nov. 2020 forum post) While persons running OpenHabian are seemingly not affected, it seems to affect persons running both inside Docker containers or on “bare metal” on a “high powered” host like me.

I am sorry to infer that this type of (100% blocking) problem may well be why I had so many automation “experts” steer me away from openHAB.

HomeAssistant has been eating it up and as a fairly linux-skilled automation “newbie” this particular experience does validate their success quite a bit. As I mentioned the other day, I had HA running with this same Zooz stick in a VM [ i.e. conceptually (and in implementation!) much more complex than “sudo dnf install openhab” ] in just a few minutes (granted, I have gotten fairly good at VMs lately, but virtual machine first-timers would be completely lost and just that would likely take them hours – hence RPI installations).

I understand software can suffer regressions, but there have been ~2 point releases since this was surfaced.

So . . . How does this get fixed? [ I will post an issue on Github in a few moments as a starter. ] Do the developers listen here?


At the personal level: with regards specifically to my install for my mom . . .

She has waved off openHAB: “if a guy with as much computer experience as you can not get this running in a couple evenings (when she saw how fast HA and Domotics had been tested a year or so ago), I don’t want it.”

She asked me to evaluate Hubitat in between struggles here and has decided to test-implement that. We’ll start tomorrow.

At my own house where I have the twin of this server I will attempt another openHAB installation (I also have the exact same Zooz USB Z-Wave stick) maybe in May or so.

Maybe by then this permissions issue will be fixed in OH 3.3.x Otherwise I will need to figure out the best way to allow OH access to the folder in question.

The “solution” discussed here by Stephen @gatekeeper6838 seems risky and impermanent. Others further down in the thread also point to the negative security implications.

Most are also referring to group “uucp” while my installation(s) don’t even have such a group and indeed suggest the OH group in question (for the serial device) would be “dialout”.

Anyway, groupings may have changed between 3.0.x and 3.2.x, but it seems worth mentioning as another potential blocker.

Hi Bob @apella12

That is correct. You wrote as I was penning a “novel” right below you.

Giving /var/lock different permissions will likely not persist across reboot.

Lots of challenges here! . . . but I’ll give it some more tries. :crazy_face:

Hi Everyone:

I have posted an issue to openhab-addons at Github

Hopefully this will get some quick attention from the developers.

Extensive (deeper) reading today in other threads shows that it has even affected some new installs on RPi (openHABian)

When a home automation hub blocks installation of a critical communication device, new users will likely flee. This is really a problem . . . I think I am fairly rare in not giving up easily!

1 Like

I’m glad you have it working.

I almost didn’t post again out of respect that everyone has their problem-solving process, but as you are new, decided to try to refocus a bit on what I was pretty convinced was the issue.

As to the “novel” you wrote that is above my pay grade.

Again congrats.

Bob

Hi Bob @apella12

Well, not really! A non-persistent workaround and/or loosening security is unacceptable.

I will further test this in my home lab, but as I implied in my “novel,” at the current moment in my opinion this absolutely blocks the use of openHAB in a production environment.

Thanks for prodding me again. My usual process is to hunt down every lead.

The “wall” of text in the lengthy post to which you had referred me made me attempt some other stuff first . . . and then I missed it on my checklist when I came back around. That’s actually embarrassing to me!

So…I agree with your mother. But you weren’t asking my opinion on that, so I didn’t offer it.

I don’t recommend openHAB to family/friends or set it up for others to run. I don’t want to be in a position where they’re dependent on a system that only I can update, change, or fix when something goes wrong. So, I always talk about home automation and openHAB as a hobby that I enjoy, not as a robust, consumer-ready solution that I think people should use. It’s too complex for that.

MainUI in OH 3 is a major step forward in usability, but even then it’s still a lot. That’s no one’s fault, it’s just what happens when a system has tons of capabilities. It’s always funny to me when anyone promises tons of features with a simple interface. You end up with a single button that does ten different things, depending on how you press it.

Well, no. openHABian with Z-Wave works. openHAB without Z-Wave works. You’ve run into a specific problem on a specific OS. That’s why I suggested trying it on a different platform.

As to why this issue persists, that other thread pretty much explains it. As far as I can tell, none of the people who were impacted reported an issue in GitHub. They may not have realized that it’s something that should be reported, or maybe they just didn’t care enough to prevent it from happening to anyone else. Whatever the case, I’m grateful to you for determining the root cause and opening an issue to alert developers. That’s how openHAB gets better.

Sorry that this hasn’t been a smooth experience for you, but it’s probably for the best that you aren’t setting OH up for your mom and walking away. I hope you’ll stick around as this is a good community.

Oh my,

should have read

My apoligies for this misleading advice. The serial BINDING has (as far as I know) nothing to to with the communication between the ZWave binding and the port the controller is represented by on OS level.

This is just one of many differences between the various Linux distributions. In this case between my RasPi OS and your Fedora. Obviosly they handle some security aspects in a different way.

Now I see, you found out what blocked your success. Good to see that and I try to remember that as a possiblee obstacle for non openhabian users.

@FBachofner Glad you got to root (no pun intended) cause. :wink:

But, wow, that nrjavaserial issue referred to by @wborn in the GitHub issue is really nasty. Six years and still not solved. :sob: Not sure what the path forward will be from here.

I guess it also explains why Ubuntu works fine (for now), but I fear it just might be a matter of time before Ubuntu breaks, too.

Can I ask a question? Did this issue get resolved? Was it a problem with nrjavaserial and the file lock bug?