Problem with setting up Zooz USB Z-Wave Plus S2 Stick ZST10

I installed 3.2.0 earlier today and am not able to set up my first “thing,” a Zooz USB Z-Wave Plus S2 Stick, model ZST10

  • Platform information:
    • Hardware: Intel Core i7-4770S CPU @ 3.10GHz × 4, 16GB ram
    • OS: Fedora 35
    • other services on server: 2 media streamers (and a small media library), MariaDB + some extremely small inward facing web applications – the server should be easily “beefy” enough to handle the mixed load. Also, I turned off the services when I ran into this problem with OpenHAB so quickly.
    • Java Runtime Environment: 18.9 (build
    • openHAB version: 3.2.0
  • Issue of the topic:

I successfully set up the Z-Wave binding. Installing the ZST10 as a thing, however, yields “error: bridge (controller is offline)

To identify the serial port used by the controller I had issued dmesg | grep tty* in the terminal, which reported:

[31307.250522] cdc_acm 3-14:1.0: ttyACM0: USB ACM device
[31309.163661] cdc_acm 3-14:1.0: ttyACM0: USB ACM device
[32853.752622] cdc_acm 3-14:1.0: ttyACM0: USB ACM device

so I put /dev/ttyACM0 into the serial port configuration field of the Z-Wave Serial Controller / thing setup form

This device worked under Domotics and HomeAssistant, both of which I played with a while back. OpenHAB is of greater interest for a number of reasons, but this instantaneous blocker is disheartening to say the least.

The first thing which jumps to mind is tht Fedora is by default significantly more locked down than Ubuntu which was being used on this server until a few days ago. That said, I don’t think “holes” need to be punched into a firewall for Z-Wave devices. Perhaps I am misunderstanding something fundamental?

Any ideas? Thanks in advance for your help!

I should mention I have:

  • soft reset the controller
  • hard reset the controller
  • unplugged the controller for a couple hours to (hopefully) “clear out” any residual configuration in the controller (this device does not have a battery so it should not be an issue . . .)
  • disabled the “ModemManager” service as suggested in another post

Unfortunately, none of these efforts made any noticeable change

The best first step would be to put the zwave binding into DEBUG mode so that you can see what’s going on when it tries to open the serial port.

Also, what does lsusb report about the zwave controller stick?

Info on troubleshooting zwave binding issues.

I think this is a 700 series controller which isn’t supported by the binding at this time.

Yep. Good catch. I completely missed which stick was being used.

Reading skills are so important. :roll_eyes: :laughing:

That might not be the case. Zooz appears to have named their new 700 stick exactly the same thing as their old 500 stick (which I have), but with “700 Series” tacked on the end.

Weird that they didn’t change the model number.

Thank you @ mhilbush for your prompt response.

lsusb reports:

Bus 003 Device 009: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

This is interesting because the stick is definitely a Zooz S2 Z-Wave Plus. I have the original box and the stick also looks like every photo I have ever seen of the Zooz S2 Z-Wave Plus.

I will try DEBUG mode in a moment.

Thanks @rpwong

Correct! My stick does not have the yellow cap which seems to be the visual differentiator for the 700 series.

This stick was bought 1.5+ years ago before the 700 series was released.

Strangely, lsusb reports something different entirely! Please see above.

Thanks for the response @jswim788

Mine predates the 700 series and does not have the yellow “cap” associated with the 700 series.

I think the issue is something else.

I’ll try the DEBUG mode in a moment.

The events.log reports:

2022-03-28 08:49:18.536 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:72485ce4cb' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to UNINITIALIZED
2022-03-28 08:49:18.544 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:72485ce4cb' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2022-03-28 08:49:21.179 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:72485ce4cb' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2022-03-28 08:49:21.185 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:72485ce4cb' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline

The openhab.log reports:

2022-03-28 03:46:51.456 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2022-03-28 08:49:15.446 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:72485ce4cb
2022-03-28 08:49:18.539 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2022-03-28 08:49:18.540 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2022-03-28 08:49:18.540 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2022-03-28 08:49:18.540 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2022-03-28 08:49:18.541 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2022-03-28 08:49:18.542 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - ZWave discovery: Deactivate zwave:serial_zstick:72485ce4cb
2022-03-28 08:49:21.161 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - Creating ZWave discovery service for zwave:serial_zstick:72485ce4cb with scan time of 60
2022-03-28 08:49:21.162 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - ZWave discovery: Active zwave:serial_zstick:72485ce4cb
2022-03-28 08:49:21.163 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2022-03-28 08:49:21.183 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2022-03-28 08:49:21.184 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:72485ce4cb.

No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:72485ce4cb

suggests to me I should be putting a UID into the controller (i.e. thing) configuration somewhere, but I don’t see such a field, nor do I know how to find the bridgeUID (which may not even “manifest” itself when the bridge is erroring in the first place . . .

Just a thought: is the user running OH member of the “dialout” group? From an OS p.o.v. the controller is a “modem”, thus requiring the membership to allow the user proper access to the port.

I think this is the config issue again. Something in the new config code is failing.

Hi @stefan.oh

Interesting thought. The user “openhab” was definitely already in the dialout group.

I have added myself there too as I am invoking the setup routines in the web interface . . . just in case that is somehow germane (probably is not, however).

Unfortunately, my addition to the dialout group has made no difference.

thus requiring the membership to allow the user proper access to the port

Port(s), hmmmm . . . I asked earlier whether this could conceivably involve firewall permissions. This does not seem likely as we are talking about a program on one host accessing hardware on the same host.

Still, it would be nice to get a confirmation I should not be looking at firewalld as the “villain” in this scenario!

Hi @robmac

Thanks for weighing in!

Is there a text file I can edit manually to enable this particular Z-Wave controller “thing” ?

First welcome!

I don’t know if it is the config code since you are on 3.2 and the config problems started with 3.3M1. Might want to review the posting here anyway. It shows some config files and Debug logs for comparison, including mine (and I have the same zooz stick as you do.)

The debug log you posted looks normal up to this point. The bridge UID message is nothing to worry about.

2022-03-28 08:49:21.163 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null

What should happen after (in about 5 seconds) is (INFO level logging, but you get the idea)

2022-03-28 15:38:45.000 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2022-03-28 15:38:50.116 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2022-03-28 15:38:50.116 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.


Hi @apella12

Thanks for the warm welcome! :slight_smile:

I am starting to think my controller somehow needs to be reset. Perhaps my Domotics setup (the last system I experimented with) left some cruft behind (such as a security key) which now precludes OpenHAB from properly invoking the controller.

I have reached out to the hardware vendor, but have a feeling we may be able to solve this quicker here . . .

For those following along . . .

Because virtually all my (few) problems with *nix over the years have stemmed from permissions issues . . . I also

$ ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Mar 28 09:53 /dev/ttyACM0

So, the controller is owned by root with group “dialout” – as hinted at by @stefan.oh

For giggles, I added the root user to group: dialout (as well as tty) and restarted the openhab service. [ root should, of course, not require sunch memberships as it is all powerful, right? ] As before, the openhab user is a member of dialout and tty groups (as well as audio and lock groups)

Still no joy!

Hey, does this “file” (i.e. device) possibly need execute privileges ?!

There is no firewall preventing anything as long as the communication happens locally.

User root is the owner of the port/device, so adding this user to dialout does not change anything as the owner root already has read and write access. The OH service usually runs with the user openhab, so that is the user that should be a member of the group dialout. Which you already confirmed is the case. Just mentioned it for clarity for readers at a later time.

I don’t think so. The OH wants to read and write to the device, not to execute anything. Also I’ve never seen execute privileges on a device file in the various Unix/Linux distributions I’ve stumbled across.

When you plug in the controller does that provoke any entries in the system logs?

Edit: What USB port do you use with the controller? I suggest to avoid USB3 and use a USB2 port. If you have a USB extension cable, try to use it with that cable to achieve a bit of distance between the controller and the PC. Or use a powered USB hub for that. Maybe you suffer from interference issues.

If it is the stick that needs resetting which I doubt. Create an account at silicon labs and download simplicity studio which will install PC Controller. Use PC Controller to hard reset your controller. You can also test the stick is OK in this app which makes it a worthwhile exercise to rule out bad hardware.

I had forgotten the config issue was first seen on 3.3 so the permissions and port configuration does appear to be the most likely. Google turned up this Not sure if you have a patched version.

The other location that might not have correct permissions is the userdata zwave folder which is where the binding stores node configuration files. You should find a file network_xxxxxxxx__node_1.xml there that openHAB user can read and write to. I am sure the log would have had errors if this was an issue though.

The easiest place to start with openHAB is to use openHabian to install and configure. It might be worth setting a test environment on something like a PI to get familiar with openHAB.