Openzwave & ZWaveJS using both own usb stick failing

I am running openzwave and want to migrate gradually to zwavejs. I bought an extra aeotec gen5+ stick, connected it to my homeassistant and want to connect that to the zwavejs addon. Then I want to exclude and include each device etc.

But I am failing to install the 2nd stick to zwavejs. I get this error:

Both sticks appear with exactly the same name. After restarting home assistant I had zwavejs to “not start” and I thought openzwave would pick “the right” one (?). Then for zwavejs I would pick the second one.

I can see in the drop down list for openzwave addon the top stick is selected.

When I go to the zwavejs addon I select the bottom stick. But saving gives me the error above and after going to the addon configuration again I see the top stick selected.

How can I differentiate between the sticks and select the “old” stick for the openzwave addon and the “new” stick for the zwavejs addon?

See if this is of any help:
How to uniquely identify two identical USB-serial adapters in Linux - Stack Overflow

Hi Rick, thank you, how would I have to do that in homeassistant core? I am not really a linux amateur (lower than an amateur :slight_smile:)…

The best way would be to use one stick per system, but you could use SSH to the HA box using key authentication ( Debugging the Home Assistant Operating System | Home Assistant Developer Docs ( )

As you mentioned, you’re lower than amateur skill level, so I’d recommend not going down the rabbit hole and try to set up a second system/Docker with the second stick.

Thanks Rick, for responding. I hope that:

  • there is another easy option/solution to make this work
  • Someone else has some good idea

The way I differentiated two USB’s was to create a “symlink” that is loaded by a UDEV rule, which looks like the suggestion in the article posted above. This article might help a little more explain how to do that.

Here’s another one

Basically, you list the USB attributes for each device by running
udevadm info --name=/dev/ttyACMx --attribute-walk

Hopefully there will be some attribute that is different between the two sticks, even though they are the same model. Then you create a “symbolic link” where the stick can be found by a name versus the ttyACM0 with a UDEV rule by matching the unique attributes. The two different names - ie TTYOld for one TTYNew for the other would appear as selectable entries under the device options in the zwave addons.

This command and steps in the guide worked fine on a normal linux system (I have Home Assistant container installed over Ubuntu). I’m honestly not sure if there are extra steps needed in HassOS. According to this article it appears possible to write UDEV rules that will be persistent in HassOS, but you have to boot with a USB stick - operating-system/ at 50749052aecbff623aa1d6b56bc281e23380c20d · home-assistant/operating-system · GitHub

I wouldn’t say this is “easy” but other then running two systems simultaneously I can’t think of another way to get the system to differentiate the two sticks.

If I understand the OPs question right, then his problem is not the inconsistent ttyACM* or ttyUSB* mapping between the two sticks on boot, but simply that HA is unable to distinguish between the two sticks because they have the same ID and the UI only looks in /dev/serial/by-id/. So zwavejs is trying to access the same port as OZW and fails, because the port is already locked (obviously).

Typically the entries under /dev/serial/by-id are already symlinked by the system to their respective devices under /dev/tty*. Typically that would be something like /dev/ttyACMx or /dev/ttyUSBx and these will be unique. There’s also /dev/serial/by-path you can use, which should also be unique even for identical devices.

I have zero experiences with the Home Assistant OS. AFAIK it’s a very stripped down buildroot. Can you access a command line to check what’s in /dev and /dev/serial/by-path ? If not, you can just blindly try /dev/ttyACM0, /dev/ttyACM1, etc, until you find the two sticks. You seem to have more sticks in there too, so the Conbee et al will also show up in those mappings somewhere.

I tried digging around for more info and found this thread. The sticks need to map from the os to the containers the addons run in properly. This user said restarting was necessary.

Could it be as simple as shut down, plug in the sticks while off, and then turn on and they’ll show up? I think if you plug them in while the device is on they won’t be recognized in the addons until restart. There was some other info in the thread that might help too.

FWIW, the next version of Home Assistant (2021.9.0) will include ‘USB discovery’. It will attempt to match the appropriate integration when a known USB device is plugged in. It might help to automatically sort out the issue mentioned in this thread (or not).


Ok, I’ll wait and see what that brings for me

Saw the release notes on usb discovery. Looks like it can recognize the usb as soon as its plugged in now. Would be curious if this fixes the issue.

This is a (huge) bug in the Aeon sticks :frowning: Safest to use a second system.

If you can access another machine running a regular version of linux, plug in the stick, and run

udevadm info --name=/dev/ttyACM0 --attribute-walk

Then it will print out a bunch of attributes. You then can do this for the other zstick and compare the values. If ANY attribute is different at all between the two sticks, a UDEV rule can be written to create a symlink and differentiate the sticks.

If all the attributes are exactly the same though, it would be very difficult for any system to differentiate the two sticks.

They can be distinguished by the USB port ID they’re plugged into. These shouldn’t change as they’re sequentially enumerated from the USB host controller. Unless the OP swaps the sticks around all the time, /dev/serial/by-path can be used or an udev rule can be created by using the port number.

This has nothing to do with the Aeotec sticks. It’s a problem in the Linux kernel, which can be circumvented by using port IDs. If HAOS doesn’t support port IDs, then this is a bug in HAOS.

1 Like

if you check in /dev/serial/by-id, I have the following
usb-0658_0200-if00 → Aeon Stick
usb-RFXCOM_RFXtrx433_A13E7GZ-if00-port0 → RFXCom
usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE1963330-if00 → Conbee2

So the other manufacturs include a serial number in the device name … Aeon doesn’t do that properly.

Exactly, see my initial screenshot.

I don’t do that, see screenshots in 1st post.

So ? Use /dev/serial/by-path.

You’re using /dev/serial/by-id, not /dev/serial/by-path.

But how can I in homeassistant os? I only see the screenshot in my addons

I don’t know. That’s the problem when using a totally locked down OS with a hardware setup that isn’t very common.

Can you ssh into it ? If yes, see if /dev/serial/by-path exists and what is in it. And what about the new USB discovery thing they added, does that help in some way ?

I checked on my HassOS install on a VM and used Portainer to see the ZwaveJS addon.

The entire dev directory from the OS is mapped to the container, and connecting to the command line into the container shows there is a /dev/serial/by-path folder listed in the container. I connected my Zstick in and this is what it showed (I only have one though)

So, its there, the question is, how to pick it from the drop down config? Can you type it in instead of selecting from the drop down? If not I still think you’ll need to do a UDEV rule either by attribute or /dev/serial/by-path to create something that will show in the zwavejs addon as a selectable option

Update- It appears you can manually type that path in the config in YamL, no UDEV rule needed:

Update- I appreciate the concerns I’ve received from the community around security about posting a network key in the screenshot. The key was auto-generated in a test environment of Hassos I have, and is not the real one I use in production. Still, I’ve updated the image to block it out.