That seems super weird that I see a hardware button that lists the hardware attached to your system…super weird
All devices ARE exposed already
Well /dev/zwave symlink isn’t.
What’s going to happen if I plug in a new USB-Serial device on my system and then reboot? Another device could acquire ttyACM0. Not fun.
I plan on having a Zigbee USB serial device hooked up soon. I don’t want to have to guess which device is mapped where everytime I reboot my system.
What if I remove hte Aeotec stick for manual pairing and once plugged back in it’s not assigned to ttyACM0 (because it wasn’t properly closed or something first time I unplugged it)?
I just can’t believe there is no way to manually expose symlink as devices…
I don’t want to stupidly rely on exposing ALL system ressource to a container. I want to have a certain control, and certainty on what’s exposed and why.
1 Like
I’ve never had that problem.
There is. If you don’t use hassio. Lol.
Then you’re using the wrong install method.
Yeah that’s what I’m starting to realize 
Anyway, I’m going to trust the Unix gods and use ttyACM0 in my HA config for now.
What are you going with hassio for?
Why not just try normal home assistant in docker?
Add-ons seemed like much added value on top of HA.
Getting notified of new versions and easily installing them.
Hass.io does makes it all easy to manage when you’re starting up with HA (and docker too in my case!).
Installing updates is a simple single command for me. I also prefer to wait until .1 releases. I never install .0 releases.
The add-ons are nothing more than docker containers. You can literally duplicate the functionality in normal docker.
I too am cautious about updates.I’ve seen a few threads where stuff just flat out broke. Thanks for the advice.
I now know that the add-ons could theoritically be manually installed.
I will probably change my install setup in the future. Just not right now.
Thanks!
Ended up using symlink in /dev/serial/by-id which is present in the container fs. Next best thing as I don’t plan on hooking up two Aeotec Z-wave dongles.
1 Like
Hi,
can you explain me what you did step by step? I have the same Problem on my rpi3 with HassOS 1.12
and Home Assistant 0.84.6. I tried the Aotec and the UZB1 and both are swapping from ACM0 to ACM1 after while.
I created “99-usb-serial.rules 99-usb-serial.rules” and inserted
SUBSYSTEM==“tty”,ATTRS{idVendor}==“0658”, ATTRS{idPrtoduct}==“0200”,SYMLINK+=“zwave”
That did not work.
In the config I tried to use “usb_path: /dev/serial/by-id/usb-0658_0200-if00” but that didn`t work either.
Thanks.
Mapping to “/dev/serial/by-id/” should definitely work. It should be exposed in the Home Assistant docker container. To be sure, launch a bash shell in it and list “/dev/serial/by-id/”. They should all be in there.
One last thing is I needed to delete the Z-Wave integration in HomeAssistant that was previously made using my initial Z-wave device mapping (/dev/zwave). Even if I changed the USB device used in my Configuration Yaml file to use the by-id device, it would still stick to using “/dev/zwave”. Deleted the Z-Wave integration in Home Assistant WebUI, restarted HA and it worked.
Enabling debug logging for the Zwave component helped me figure it out. Try to enable that as well and check the logs.
1 Like
Thank you! It works.
I had to delete the Z-Wave Integration.
Sorry for hijacking the thread. In my hass.io running on a Raspberry Pi 3 I lack the /dev/serial directory. I’ve searched the forum and rest of the web for information on exposing /dev/serial/by-id but I sort of get the feeling that it is supposed to be exposed in hass.io. I don’t understand why it’s not exposed in mine. My hass.io supervisor is at version 145. When I log in I do it through the SSH server add-on.
Is /dev/serial/by-id supposed to be visible when logging in through the SSH server add-on?
If it is, any idea how I can make it visible?
First of all, is /dev/serial/ present on root file system?
I don’t know. What is the recommended way to enter the root file system in Hass.io? I assumed that the container the SSH addob takes you to was the only place you should venture to as a Hass.io user.
Well it depends on the base OS that’s on your pi(or other platform) but usually, there is a SSH server running on the base OS, usually defaulting to port 22.
So basically, you connect to it same way as you do when ssh’ing in Hass.io container, only this time you use port 22.
Here’s a basic tutorial on how to use SSH on Raspbian and most derivative: https://www.raspberrypi.org/documentation/remote-access/ssh/
It will tell you how to enable ssh server if it’s not already up and how to connect via a client.
If they just flashed the hassio image, that base OS is HassOS
This doesn’t make sense. The SSH add-on uses port 22.
This doesn’t apply to Hassio
The answer is here:
https://developers.home-assistant.io/docs/en/hassio_debugging.html
1 Like
Sorry for misleading, I never used HassOS and I don’t use the SSH addon either.
Thanks for supplying the solution!
Back to the original issue, is it possible HassOS doesn’t implement device tree categorization that gives out /dev/serial/* listing?
If so, maybe there is a way to reinstate it.
1 Like
having some problems too, but refered to this docker issue:
any further work done here?