[SOLVED] OH3 Z-Wave Serial Controller offline (RaZberry)

since the years I use OpenHAB 2 without problems. With OpenHAB3 I want start a new installation. So I take my PI 3 (from working OH2 Installation) and use new sdcard with fresh OH3 installation. I use openHABian v1.6.2 for install.

I added my HUE with all ligths this work.
After that I added my Z-Wave Controller but this is not working. The controller is still offline. The serial port was found. Port is there in system.

When I switch to sdcard with OH2, all is working fine Z-Wave controller is working.
How can I debug futher in OH3? Has someone a idea?

  • Platform information:

  • Release = Raspbian GNU/Linux 10 (buster)

  • Kernel = Linux 5.4.79-v7+

  • Platform = Raspberry Pi 3 Model B Plus Rev 1.3

  • openHAB version: 3.0.0

  • Z-Wave controller RaZberry

  • If logs where generated please post these here using code fences:

2020-12-29 14:01:58.051 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2020-12-29 14:01:58.055 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2020-12-29 14:01:58.058 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2020-12-29 14:01:58.062 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2020-12-29 14:01:58.066 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2020-12-29 14:01:58.084 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - ZWave discovery: Deactivate zwave:serial_zstick:0693512b67
2020-12-29 14:01:58.009 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘zwave:serial_zstick:0693512b67’ changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to UNINITIALIZED
2020-12-29 14:01:58.113 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘zwave:serial_zstick:0693512b67’ changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2020-12-29 14:02:17.826 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - Creating ZWave discovery service for zwave:serial_zstick:0693512b67 with scan time of 60
2020-12-29 14:02:17.833 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - ZWave discovery: Active zwave:serial_zstick:0693512b67
2020-12-29 14:02:17.838 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2020-12-29 14:02:18.016 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2020-12-29 14:02:18.019 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:0693512b67.
2020-12-29 14:02:17.986 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘zwave:serial_zstick:0693512b67’ changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2020-12-29 14:02:18.026 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘zwave:serial_zstick:0693512b67’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-12-29 14:18:54.149 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:0693512b67


How did you add it? Through the UI or a text file?


I add it through the UI. Install Z-Wave binding. Then add Thing. Use serial controller. Only serial port for devices was /dev/ttyAMA0.


Is that what the OS sees? What does dmesg | grep -i tty return?

Yes OS say right serial I think.

dmesg | grep -i tty
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000 console=ttyAMA0,115200 console=tty1 root=PARTUUID=1ceb473a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.000877] printk: console [tty1] enabled
[ 2.519130] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 3.524892] printk: console [ttyAMA0] enabled
[ 3.533294] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 50000000) is a 16550

This looks related.

The RaZberry UART may be conflicting with Bluetooth?


I done this via openhabian-config. I must deactivate serial port and change bluethooth to mini-UART.

Now controller is online. Thanks!

2020-12-29_15:28:22_CET [openHABian] Beginning configuration of serial console for serial port peripherals… OK
2020-12-29_15:28:27_CET [openHABian] Enabling serial port and disabling serial console… OK (reboot required)
2020-12-29_15:28:32_CET [openHABian] Making Bluetooth use mini-UART… OK

best regards,

1 Like

@chris Should there be a section in the binding docs for specific controller tips?

In this case with the Pi 3 & RaZberry, there is some further configuration needed.

I don’t overly mind adding something, although if it’s specific to hardware, then maybe it should be in the hardware installation?

I don’t mind either way though.

I was thinking of something similar to the coordinator section of the Zigbee binding.

I don’t mind. Most of the zigbee coordinator section is talking about different coordinators. Here we only have 1 zwave controller, but the quirk is with the host hardware (I assume).

Anyway - no problem with me to add it :slight_smile:

Yes and specific to RPis. I don’t mind you add something but frankly I do not think this belongs into the binding docs. It’s host HW specific.

Would it belong in the openHABian docs then? It is focused mainly on that hardware.

I’d think anybody to buy specific HW should know how to install it himself.
We cannot add instructions for each and everything.
However, if someone wrote a PR to contribute to docs/openhabian.md I wouldn’t mind accepting it.

Hi all,

I have exactly the same issue but on a Raspi 4. I installed openhabian-pi-raspios32-v1.6.5 (OpenHAB 3.1) and everything was working without problem. However, I can’t get the RaZberry 2 card to work. The two LEDs on the card are on for 2 secs when powering up the Raspi which should indicate the card works correctly.

I have configured the serial port to relocate the Bluetooth module.

And I find the corresponding entry in /boot/config.txt at the end of the file.


As @Lars_Reidelbach I added the Z-Wave binding and afterwards the Z-Wave Serial controller. As serial port I used /dev/ttyAMA0.

However it remains in state BRIDGE_OFFLINE.

When I debug Z-Wave, I get:

2021-09-25 21:34:11.107 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2021-09-25 21:34:11.116 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - Creating ZWave discovery service for zwave:serial_zstick:Razberry2 with scan time of 60
2021-09-25 21:34:11.117 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - ZWave discovery: Active zwave:serial_zstick:Razberry2
2021-09-25 21:34:11.118 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2021-09-25 21:34:11.193 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2021-09-25 21:34:11.195 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:Razberry2.
2021-09-25 21:35:10.510 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:Razberry2
2021-09-25 21:36:01.932 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:Razberry2

Does anybody have a clue what is wrong here?

What I find a bit strange is how the devices look:

crw--w----  1 root tty     204,  64 Sep 25 21:33 ttyAMA0
crw-------  1 root root      5,   3 Sep 25 21:33 ttyprintk
crw-rw----  1 root dialout   4,  64 Sep 25 21:33 ttyS0
crw-rw----  1 root dialout 188,   0 Sep 25 21:34 ttyUSB0

On anohter Raspi4 I run successful with RaZberry it will show ttyAMA0 with the r flag on group and well and the group is set to dialout as with ttyS0. Btw, I have tried as well /dev/ttyS0 but same result.

Does someone has a clue here?

Thanks, Bernd

Yes like this the openhab user cannot access the device. Just change it to be like your other Raspi.

Hi Markus, I tried to change the permissions and the user on /dev/ttyAMA0 before, but after reboot it will be changed back. But I think I have a clue now.

Have a look at this: https://www.raspberrypi.org/forums/viewtopic.php?t=180254

It says:

Never add a user to the tty group. A serial device being in tty group suggests that a getty (serial login manager) is running on the port; otherwise it should be in dialout group. Trying to use the port if a getty is also running will just cause other problems.

Disable the login shell on the serial port in the interfacing options of “sudo raspi-config”, and reboot. For B+ that may be all that is required.

For Pi3, and possibly in future, disabling the getty will also put the physical pins back to general-purpose mode. To have them as serial by default, you should add “enable_uart=1” to /boot/config.txt. For best compatibility across Pi models, it may be better to use /dev/serial0, instead of ttyAMA0 or ttyS0.

When I check on processes, I find this here:

openhabian@hestia:~ $ ps -ef | grep getty
root       843     1  0 22:55 ?        00:00:00 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyAMA0 vt220
root       844     1  0 22:55 tty1     00:00:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
openhab+  2061  1340  0 22:59 pts/0    00:00:00 grep --color=auto getty

Now how can I turn this serial login manager off? raspi-config is not available on openHABian. BTW I have not installed anything else, it is a clean openHABian.

You can use the openhabian menu to do that but I don’t think it affects if a getty is started on /dev/ttyAMA0 which is your problem.

@mstormi where can I do this in openhabian-config?

I have disabled it now using systemctl:

openhabian@hestia:~ $ sudo systemctl disable getty@ttyAMA0

Then checked:

openhabian@hestia:/dev $ sudo systemctl status getty@ttyAMA0
[sudo] password for openhabian: 
● getty@ttyAMA0.service - Getty on ttyAMA0
   Loaded: loaded (/lib/systemd/system/getty@.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:agetty(8)

Rebooted … and then permissions on /dev/ttyAMA0 were automatically changed to rw for the group and dialout as gid:

crw-rw---- 1 root dialout 204, 64 Sep 25 23:20 ttyAMA0

Afterwards Z-Wave Controller went online after adding. Puh! Took me the whole evening to get this sorted. Now the question is, why was getty@ttyAMA0.service enabled? systemctl says vendor preset: enabled. Maybe something to look into …


Now I understand … You have to check both items in openHABian-config. I thought the first setting is only applicable to older PI models. But it must be done for all as it disables the console. So for everybody trying to get a Z-Wave RaZberry controller running, both settings need to be enabled:

This leads to following settings in /boot/config.txt


Thanks to the maintainers for all the hard work.