So I hit the add/remove tools and get
Then I hit package manager & navigate to the tools tab
Are you signed in? All this is without the controller being plugged into the pc.
So I hit the add/remove tools and get
Are you signed in? All this is without the controller being plugged into the pc.
Hi Bob @apella12 Thanks!
It turns out Zooz sent me the (standalone) “PC Controller” package by e-mail right before lunch. I ran that completely independently of Simplicity Studio and while the PC Controller software is able to run, it was not able to update the firmware as I got blocked at step 6 of Zooz’s firmware update instructions – the device can not get “added” in they way they suggest.
See attached screenshot
After lunch I removed, reset, etc. everything I could between the slaves and the controller (let’s hope that doesn’t turn out to have been a bad decision! )
Now I seem to be able to do even less with the provided “PC Controller” software (including “re”-adding the Zooz stick)
I am again waiting on hearing from the company for advice on bending their controller to my will.
BTW: yes, I was logged in to Simplicity Studio, but I had the stick plugged in. Perhaps that is why I did not see the package manager (I had only device and product group options).
BTW#2: your Simplicity Studio looks quite different than mine. Looks like you are running on Linux (I am/was on Win 10 in a VM as they – Zooz et al – seem to prefer that. Only Ubuntu is “supported” in Linux and I am mostly working on new Fedora installs here. I don’t want them to claim it is not working because of platform issues.
Thanks for checking on your similar (likely “same”) hardware. Good to get confirmation on this.
I don’t have a Pi around. Not only am I a fan of Odroid (over Pi), but I am trying to do all this home automation for my octagenarian Mom and am thus 300 miles away from my handful of single-board machines . . .
I might install openHABian in a VM later today to check.
I’m hoping Zooz will call me so I don’t have to go through 20 permutations in back-and-forth e-mails.
Curious: are you on openHAB 2.x or 3.x?
OH 3.2, but I’ve had my Zooz stick since OH 2.4. Shouldn’t make a difference.
I’m not sure that will prove anything, because it’ll still be attached to the same computer. I’m wondering how it’ll respond on a completely different system.
This is going to sound really basic, but have you tried deleting the Z-Wave controller thing from openHAB and then adding a new one? I have no reason to think that there’s a problem with the thing, but it just doesn’t make sense that other software can access the controller and OH can’t at the same
Hi Russ @rpwong
Do you have anything in
/etc/udev related to the Zooz S2?
I am reading the thread: [SOLVED] OH3: zwave binding Z-Wave Serial Controller Aeotec Z-Stick Gen5 remains offline - #4 by hmerk recommended by @robmac
That thread indicates the stick in question has the file
/etc/udev/99-usb-serial.rules My install has nothing in udev . . .
Bad Felix! I am just noticing OH Prerequisites
Can someone weigh in on how likely my problem might stem from using OpenJDK instead of AdoptOpenJDK ?! I know virtually nothing about Java and am a bit surprised that OH seems to care about this so specifically.
The more likely issue seems to be the potentially “missing” file at /etc/udev/ – but this has not yet been answered.
I don’t think that has anything to do with this. Have you tried the solutions from Rob’s link to that thread?
I feel like that should be where you start. Scanning the thread, there are a few other things mentioned later on, since the post is quite old.
I don’t know anything about Java either, so I can’t comment on that.
Hi Russ @rpwong:
Except that udev rules help keep device names as you want them and also static, if desired. A little corner of my brain thinks UDEV rules could somehow be leveraged to bend this USB stick to my will.
Will be working through the ideas this evening.
Curious: What OS platform are you on? What Java version are you using? (in Linux terminal: java -version )?
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 \
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.
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 "126.96.36.199" 2022-02-08 LTS OpenJDK Runtime Environment Zulu11.54+25-CA (build 188.8.131.52+1-LTS) OpenJDK 64-Bit Server VM Zulu11.54+25-CA (build 184.108.40.206+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.
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 I restarted OH and everything came back 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.
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.
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
Main PID: 7254 (java)
Tasks: 118 (limit: 18738)
CPU: 1min 40.123s
└─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: 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: 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