[SOLVED] Z-Wave Serial Controller shows "OFFLINE - BRIDGE_OFFLINE Controller is offline"

I am running openhabian on an older RPi 2 something and I’m trying to get my Aeon ZWave Stick set up and talking to the zwave devices. I’ve added the Thing for the Z-Wave Serial Controller, but it says the Status is OFFLINE - BRIDGE_OFFLINE Controller is offline. I click the pencil to edit this Thing and the Serial Port shows the only selection is /dev/ttyS0. However, in the openhab.log file, I see this:

2019-04-04 10:00:33.819 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2019-04-04 10:00:35.097 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node5' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2019-04-04 10:00:35.257 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node5' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2019-04-04 10:00:36.772 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2019-04-04 10:00:37.506 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node6' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2019-04-04 10:00:37.732 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node6' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2019-04-04 10:00:37.914 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node7' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2019-04-04 10:00:38.001 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node9' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2019-04-04 10:00:38.109 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2019-04-04 10:00:38.194 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node3' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2019-04-04 10:00:38.209 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2019-04-04 10:00:38.309 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node3' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2019-04-04 10:00:38.454 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node7' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2019-04-04 10:00:38.554 [hingStatusInfoChangedEvent] - 'zwave:device:931baffe:node9' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2019-04-04 10:00:38.640 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'zwave:serial_zstick:931baffe' takes more than 5000ms.

Which I think means the controller is connecting to /dev/ttyACM0. Using ps aux, it looks like the openhab user is running the openhab service, so:

[10:51:42] openhabian@openHABianPi:~$ groups openhab
openhab : openhab tty dialout audio bluetooth gpio
[10:51:53] openhabian@openHABianPi:~$ 
[10:52:00] openhabian@openHABianPi:~$ ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Apr  4 10:52 /dev/ttyACM0

Edit ttyS0 isn’t even a thing:

[18:37:25] openhabian@openHABianPi:~$ ls -l /dev/ttyS*
ls: cannot access '/dev/ttyS*': No such file or directory
[18:37:31] openhabian@openHABianPi:~$ 

These are the EXTRA_JAVA_OPTS values I have:

[10:34:30] openhabian@openHABianPi:~$ cat /etc/default/openhab2 | grep SerialPorts
##   EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0"
##   EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyAMA0"
##   EXTRA_JAVA_OPTS="-Djna.library.path=/lib/arm-linux-gnueabihf/ -Duser.timezone=Europe/Berlin -Dgnu.io.rxtx.SerialPorts=/dev/ttyS0"
EXTRA_JAVA_OPTS="-Xms250m -Xmx350m -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyAMA0"
[10:34:41] openhabian@openHABianPi:~$ 

So my hunch is that the controller comes up fine on /dev/ttyACM0, but for some reason the PaperUI doesn’t let me select /dev/ttyACM0 as the serial port, so openhab can’t find the controller:

I checked these posts that have similar, but slightly different issues, but the resolution doesn’t seem to apply in my case:

The “Welcome to openHAB2” on https://address:8080/start/index shows my openHab version as openHAB 2.5.0.M1 Milestone Build. But the ssh welcome message shows openHAB 2.4.0-1 (Release Build). All the bindings show the 2.5.0 value though.

Edit: Added ls for ttyS0.

Did you add the openhab account to tty?

Oops… sorry… long post and just saw that it is in there.

Yea, that looks ok. It definitely seems like it is the openhab user who isn’t able to see the ttyACM0 device. I’m out of ideas :frowning:

Did you verify via dmesg -T | grep tty ?

I had the same issues with snapshots #1564 and #1566 - all zwave devices that ran perfectly before were offline due to controller port issues. Switched back to #1560 and I am back in business after a

sudo shutdown -r  now

This is the output:

[08:47:25] openhabian@openHABianPi:~$ dmesg -T | grep tty
[Thu Apr  4 17:17:17 2019] Kernel command line: bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=PARTUUID=567cab14-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[Thu Apr  4 17:17:17 2019] console [tty1] enabled
[Thu Apr  4 17:17:17 2019] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[Thu Apr  4 17:17:18 2019] console [ttyAMA0] enabled
[Thu Apr  4 17:17:30 2019] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[08:47:31] openhabian@openHABianPi:~$ 

@frankie.delure, I’m not sure how to tell what snapshot I’m using, where would I find that? the http://openhabianpi:8080/start/index shows me “openHAB 2.5.0.M1 Milestone Build”. I found the ssh console but I’m not sure how to get the version info. I found this, but it doesn’t seem to list the snapshot:

openhab> bundle:list -s | grep wave
219 │ Active   │  80 │ 2.4.0                  │ org.openhab.binding.zwave

Thanks for the replies guys!

That is you zwave stick controller.

You did not properly upgrade to a snapshot. If you upgraded to the snapshot core, something is really wrong in your setup.
If you just upgraded the zwave binding to snapshot, you did something wrong, too.

Upgrading to the snapshot zwave binding:
Uninstall the zwave binding through PaperUI (or addons.cfg, whatever you are using)
Download the zwave snapshot binding, put the jar into your addons folder, restart openHAB.

The zwave binding was recently changed to use the new ESH serial classes. I’m wondering if this is causing the issue here, and maybe the feature needs to be updated. I’ll take a look at this.

From a quick look at the features, I don’t think this should have changed with the use of the ESH classes. The features call up openhab-transport-serial which should cover all the serial classes. Also, if it was the problem, I wouldn’t expect the binding to start at all, which doesn’t appear to be the situation here so my comment above might be incorrect that it’s related to these changes.

It still might be related to this, but from my testing with these changes before the merge, the port access worked fine with the ESH classes.

No problems here on snapshot #1549:

What about a more recent version? The change was merged on the 3rd, which would make 1565 the first version to have this. At least this probably means the problems from @frankie.delure are unrelated as there was no change in #1564 where he is reporting issues above.

Sorry, did not realize that.
Now you forced me to upgrade :grinning:

Snapshot #1566, still working fine:

Thanks for confirming :slight_smile: - it’s good to know it’s not just my system where it’s working…

Hey guys,
Where can I find this “snapshot number”? I don’t see any kind of 4 digit number next to the zwave binding. I see “2.5.0.M1”. I googled how to install a snapshot for openhab and found this post:

So I did all that, using this jar file:

[18:23:10] openhabian@openHABianPi:/usr/share/openhab2$ ll ./addons/
total 2.6M
drwxrwxr-x+ 2 openhab    openhabian 4.0K Apr  7 18:15 ./
drwxr-xr-x  4 openhab    openhab    4.0K Apr  2 19:39 ../
-rw-rw-r--  1 openhabian openhabian 2.6M Apr  6 17:57 org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar
-rw-r--r--  1 openhab    openhab      70 Dec 17 00:01 README
[18:23:15] openhabian@openHABianPi:/usr/share/openhab2$ 

And rebooted the pi. But the binding doesn’t show up in PaperUI. Since @sihui seems to be using HABmin, I thought that might have a snapshot somewhere or something, but it also does not show the zwave binding as installed and does not show me a snapshot number.

So I’m not sure where to go from here.
Where would I find this snapshot number? Is it listed next to the 2.5.0 in the bindings screen? I’ll have to dig into why it wasn’t picked up when I put the .jar into my addons folder.

Log into the console. You’re using openHABian, which is a package repository installation, so connect through ssh and run…

openhab-cli console

… although, there may be a menu for this too (I’m not familiar with openHABian).

Manually installed bindings through the addons folder don’t show up in any GUI.
Just perform what you already did above to find the number and to see if it is installed:

That would explain a lot. Ok, so after stopping the openhab2 service, dropping the jar file into the $OPENHAB_HOME/addons and then rm -rf $OPENHAB_USERDATA/{cache,tmp}/*, this shows in the console:

openhab> bundle:list -s | grep wave                                                                                                                                 
 13 │ Installed │  80 │     │ org.openhab.binding.zwave

So is that snapshot 0025?

(Incidentally, the console shows 2.4.0 Release Build in the welcome message, but paper ui shows 2.5.0.M1)

But then the openhab.log file freaks out:

2019-04-08 09:08:48.584 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [13]
  Unresolved requirement: Import-Package: com.google.common.collect

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

But I can’t sort out where to find this com.google.common.collect package. A few posts, such as here and here seem to indicate this comes with the Guava bundle but I’m really just grasping at straws here.

I think you somehow messed up your openHAB installation during an upgrade.

Never seen any numbering like that. No, your openHAB zwave binding is snapshot #610:


But don’t worry about snapshot versions for manually installed bindings, the important part is to use a recent one and yours is from 20190407

Yep, I’m a moron. I have to plead 100% and total incompetency. I moved everything to a raspberry pi a couple of months ago, but I had a bookmark for the old openhab that was still running… which is why the zwave controller was stubbornly showing as offline… because it was plugged into the pi, but I was looking at the old laptop.

This is where I have to eat my hat with a large slice of humble pie. I really really appreciate all your help. Man I feel stupid.

1 Like

Just installed #1569. Same issues - z-wave Controller is offline. Back to#1560 and z-wave is online and devices work as they should without any further input.

I will stay with #1560 as long as there is no hint what might cause the troubles.