RFXcom and Zwave stick stay offline after reboot

  • Platform information:
    • Hardware: RPI 4B 4GB, Aeotec Zwave 5 stick, RFXcom 433 XL
    • OS: Openhabian
    • openHAB version: 3.3.4 / 3.4.1 release build

I’m using Openhab for 2 years now and all worked well until now. What happened?

A couple of weeks back I decided to install auto backup mirroring (menu option 53). Yesterday I wanted to check if the backup was working properly.

So, after pulling the power plug of the RPI (I didn’t stop Openhab) I removed the memory card and changed it with the one with the backup. Openhab started well but both the zwave bridge and the rfxcom bridge were offline. I unplugged both and after a short while I put them back. With the same result: offline. Disabling / enabling gave no better result.

I changed the memory card back and started up with original card but both bridges showed offline. Unplugging and plugging, stopping, rebooting and restarting again with no result. No errors in the log, just info (“Handler factory not found”) . And after a few restarts with the stick and rfxcom plugged in and a few without, the situation is that they are still offline.

Then I set the serial ports with the config tool (menu option 35). After that I checked with dmesg | grep tty the correct names of the ports. Very strange: the port names had changed: the rfxcom went from /dev/ttyUSB0 to /dev/ttyS0 and the zwave stick from /dev/ttyACM0 to /dev/ttyAMA0. I adopted the new names in the configuration but nothing changed: still offline.

I decided to upgrade to the latest version of Openhab, 3.4.1 release build. That didn’t help, everything works fine except the rfxcom and the zwave stick that are still offline

For two days I’m working (and reading topics with similar problems) on it with no result. At this moment I ran out of ideas so I hope that out here some one can give me a hint for a solution!

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.

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!

@Ap15e: 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? :slight_smile: 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

@Ap15e: 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
Lists OSGi services.
service:list [options] [objectClass]
Name of service objectClass to filter for
-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:

  1. Use only USB 2 ports for adapters
  2. Create bash script /home/openhabian/clear-locks.sh
  3. Add permission sudo chmod ugo+x /home/openhabian/*sh

IMPORTANT: Please change the file here:


if [ -f "$file" ] ; then
    rm "$file"
  1. Create rule onstart.rules
rule "OH Start"
    System started
    val mydata =  executeCommandLine("/home/openhabian/clear-locks.sh")
    logInfo("reboot script executed", mydata)

you know this sounded a little like the old nrjavaserial file lock bug
read more about it here in this thread

@Andrew_Rowe I do not understand, it was fixed, yes?

i thought so but…
Best way to find out is to check for the lock files