This commands needs to be entered in the karaf console not in the linux shell/console.
To open the karaf console login to the linux shell of your openhab system.
Then run:
openhab-cli console
The password that you need to enter is: habopen
I strongly recommend using udev rules:
We need an unabridged debug log for further analysis.
Are you sure that you are not hit by this with regard to your Aeotec stick ?
Which other bindings are in use ?
What makes you think so? 
I see a PL011 and a 16550 UART, but the link to the corresponding USB device seems to be missing.
Thank you for your very responses!
I’m not at home this weekend but Monday I’m gonna work on it.
Kind regards
Anne
@anon71759204: you are right. I jumped to the wrong conclusion about the bridges being on the proper ports. Sorry for that. It was a relief to me that both devices were present and that both ports seem to exist.
Regarding UDEV: a couple of years ago I found a useful manual to make symlinks (as I remember well). I can find it anymore due to probably the wrong keywords.
For the ZWave stick I already use a non-powered USB hub and it worked well for the last two years. Even though thank you for the suggestion.
I just got the karaf console running. I was able to activate the logging for ZWave. I made a log when starting the system and a separate log when stopping the system. I hope I can send them with this reply (it’s is my first question on this forum). Maybe you get some useful info out of it. It’s too technical for me.
When I tried “openhab> ls -al /dev/serial/by-id” I got an error:
openhab> ls -all /dev/serial/by-id
Error executing command service:list: undefined option -all
Try --help’ for more information.
openhab> ls --help
DESCRIPTION
service:list
Lists OSGi services.
SYNTAX
service:list [options] [objectClass]
ARGUMENTS
objectClass
Name of service objectClass to filter for
OPTIONS
-a Shows all services. (By default Karaf commands are hidden)
–help Display this help message
-n Shows only service class names
openhab> ls -a /dev/serial/by-id
The command didn’t give any result, only the prompt. So I cannot provide you with further information at this point. Suggestions are still welcome.
Openhabian stop 15 10 log.pdf (397.4 KB)
Openhabian start 14 40 log.pdf (225.2 KB)
udev isn’t about symbolic links but about telling the Unix kernel to attach a particular (external) USB device to a particular port in the filesystem. Please use udev to save yourself from further hassle.
ls -al /dev/serial/by-id
(mind typos …) is a Unix command, not a command to be executed from within the karaf console.
Thanks for posting the logs - unfortunately the PDF format is unusable for further analysis. Please post the raw logs as text files (rename the log files to something the forum software is happy with).
The log files again, and this time in a txt format. Let’s hope you find some clue’s in this.
Today I’ll dive into UDEV
Openhabian start 14 40 log.txt (108.2 KB)
Openhabian stop 15 10 log.txt (230.1 KB)
Unfortunately no further hints in the log files.
The relevant lines are:
2023-01-16 14:41:15.219 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2023-01-16 14:41:15.221 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:8391c27eeb.
==> /var/log/openhab/events.log <==
2023-01-16 14:41:15.242 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:8391c27eeb' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
Putting the Z-Wave Binding into TRACE mode might reveal additional hints.
For the making symlinks for usb ports I tried the method described in the following post:
[How to make symlinks for usb ports in linux (EXTRA_JAVA_OPTS)]
But that didn’t work. At the end the result of ls /dev/tty* turned out to the old and existing /dev/ttyAMA0 and /dev/ttyS0
And I tried it also with this:
sudo nano /etc/udev/rules.d/99-usb-serial.rules
SUBSYSTEM==“tty”, ATTRS{idVendor}==“0403”, ATTRS{idProduct}==“6015”, ATTRS{serial}==“DO2ZW4FJ”, SYMLINK+=“ttyUSB_RFXcom”
SUBSYSTEM==“tty”, ATTRS{idVendor}==“0658”, ATTRS{idProduct}==“0200”, SYMLINK+=“ttyUSB_ZWaveStick”
After saving I used sudo udevadm trigger to get the rules to work.
That didn’t work either. I become a little pessimistic in finding a solution.
IDs look right. That’s all I know.
I am using the second rule as well.
It might be just a “problem” of rendering in the forum but do you use " or “ as quotation marks ?
Did you try to unplug and plug the sticks ?
@Anne hi! I had the same issue, and I understand this is so ugly(
I had a problem with the locks.
After reboot, please try to go to /var/lock, here you can potentially find file with name like ‘LCK…ttyUSB0’
My solution here:
- Use only USB 2 ports for adapters
- Create bash script
/home/openhabian/clear-locks.sh - Add permission
sudo chmod ugo+x /home/openhabian/*sh
IMPORTANT: Please change the file here:
file="/var/lock/LCK..ttyUSB0"
if [ -f "$file" ] ; then
rm "$file"
fi
- Create rule
onstart.rules
rule "OH Start"
when
System started
then
val mydata = executeCommandLine("/home/openhabian/clear-locks.sh")
logInfo("reboot script executed", mydata)
end
you know this sounded a little like the old nrjavaserial file lock bug
read more about it here in this thread
i thought so but…
Best way to find out is to check for the lock files
Thank you Sasha for your input, I think you point in the right direction!
I checked /var/lock and it turned out that there were three file in this directory: “Asound.state.lock”, “LCK…ttyAMA0”, “LCK…ttyS0”. I removed both LCK files (with “sudo rm LCK…ttyAMA0” ) and let the Asound file untouched. After stopping (and automatically starting Openhab?) both files were back. So I think it can’t be done manually? Or do I something wrong? As I pointed out, I’m not a Linux guru.
Then I followed your solution:
I made the files, in fact I copied your phrases and changed the filename as you can see. When
it’s working the next question: is it possible to delete both lock files in one clear-locks.sh file? How to?
I changed the permissions for the directory but after a reboot both the LCK files were still in place.
Where did I go wrong?
@Anne have you created onstart.rules?
What do you see in logs?
your bash script has to be:
ttyAMA0file="/var/lock/LCK..ttyAMA0"
if [ -f "$ttyAMA0file" ] ; then
rm "$ttyAMA0file"
fi
ttyS0file="/var/lock/LCK..ttyS0"
if [ -f "$ttyS0file" ] ; then
rm "$ttyS0file"
fi
Yes, I created the file onstart.rules and I changed the permission for /home/openhabian/*sh.
The file clear-locks looks now like:
After done this I rebooted the system and unfortunately both lock files were still present:
A second and a third reboot had the same result.
So it didn’t work. I decided to start a fresh instance with a new memory card but on the same RPI and with the same RFXcom and ZWave stick. Both were recognized by the bindings and I could assign the ports ttyUSB0 to the RFXcom and ttyACM0 to the ZWvave stick. Mind you: this are the same ports as that were used before I broke Openhab (see my first post).
And it works! That is why I decided to put no further effort in fixing the broken installation. I’m very grateful to all of you who were trying to help me out and solve this annoying problem.
In one of the threads I linked to there is an example of a script that deletes the lock files. It is a bash script that runs before openHAB starts