Does increasing the log level help to gather more information ?
By pulling the power plug without proper shutdown you might have damaged the openHAB installation on your primary memory card.
There is no guarantee that a particular USB device will be assigned to a particular device at boot time.
Use
ls -al /dev/serial/by-id
to check the current hardware/device associations.
It might be possible to use the ‘by-id’ device IDs but IIRC, I ran into some problems (at least for some Bindings).
It might be necessary to write some udev rules to force a particular USB device to associate with a particular device in the filesystem.
As @Wolfgang_S points out in the previous post:
If your ports settings are correct and the Bindings are still offline, the next step is to increase the log level and check the logs for hints:
Thank you both for your reply!
@anon71759204: Unfortunately your prompt ls -al /dev/serial/by-id gave back “no such file or directory”. That’s why I searched the internet for in alternative. I checked the hardware/device associations with lsusb command. The result was:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 003: ID 0409:005a NEC Corp. HighSpeed 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.
So I think the devices are recognized: Bus 001, device 004 is the rfxcom and Bus 001, device 005 is the ZWave stick.
After that I used dmesg to check the portnames:
openhabian@openHABianDevice:~ $ dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 smsc95xx.macaddr=DC:A6:32:F3:2E:B3 vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000 console=tty1 root=PARTUUID=cec06579-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.001808] printk: console [tty1] enabled
[ 1.418912] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 36, base_baud = 0) is a PL011 rev2
[ 1.427281] fe215040.serial: ttyS0 at MMIO 0xfe215040 (irq = 37, base_baud = 62500000) is a 16550
@Wolfgang_S: Also I didn’t manage to turn on the debug log for zwave. When I used the command:
“log:set DEBUG org.openhab.binding.zwave”
the reaction was: ”-bash: log:set: command not found”
My knowledge of Linux is very limited so I don’t know how to go further under the hood. It looks like both bridges are on the right port but they still keep offline. I cleared the cache and I restarted Openhab many times but it didn’t help. To me it looks like Openhab blocks the ports or something like that. Probably due to pulling the plug without stopping Openhab (shame, shame).
I would be very pleased to get more hints. It’s very uncomfortable to switch each light by hand….
Thank you in advance!
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?