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?
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.
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.
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).
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.
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.
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- 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.
)…
Safest to use a second system.
