Restart Home Assistant docker container, need to replug USB stick

Whenever restart the Home Assistant docker container it tells me that there is no USB-stick in the server. I then have to plug the stick out, then in for it to work again. The Z-Wave stick is a Aeotec Z-Stick Gen5

I’m running Docker directly installed on Ubuntu Server 18.04 which is running on a computer (no virtualization).

Here’s my docker-compose.yml:

version: '3'
services:
  homeassistant:
    container_name: home-assistant
    image: homeassistant/home-assistant
    ports:
      - "8123:8123"
    volumes:
      - /home/magnus/config/home-assistant:/config
      - /etc/localtime:/etc/localtime:ro
    devices:
#      - /dev/ttyUSB0:/dev/ttyUSB0
#      - /dev/ttyUSB1:/dev/ttyUSB1
      - /dev/ttyACM0:zwaveusbstick:rwm
    restart: always
#    network_mode: host

I also have to take the plug out and in again after rebooting the Ubuntu Server for the Home Assistant docker container to start again.

Any ideas on what I’m doing wrong?

1 Like

I am running Debian 9 on a NUC with HA running in docker.

I solved the issue with changing USB addresses by setting a udev rule.

in etc/udev/rules.d/99-com.rules add the following line to the end:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyUSB-ZStick-5G"

then in your docker run command use:

--device /dev/ttyUSB-ZStick-5G:/dev/ttyUSB-ZStick-5G

or docker-compose:

devices:
  - /dev/ttyUSB-ZStick-5G:/dev/ttyUSB-ZStick-5G

Then in configuration use:

zwave:
  usb_path: /dev/ttyUSB-ZStick-5G

Thanks for answering. I have tried doing what you said, but I get this error:

Traceback (most recent call last):
  File "/usr/src/app/homeassistant/setup.py", line 145, in _async_setup_component
    hass, processed_config)
  File "/usr/src/app/homeassistant/components/zwave/__init__.py", line 244, in async_setup
    config_path=config[DOMAIN].get(CONF_CONFIG_PATH))
  File "/usr/local/lib/python3.6/site-packages/openzwave/option.py", line 81, in __init__
    raise ZWaveException(u"Error when retrieving device %s : %s" % (device, traceback.format_exception(*sys.exc_info())))
openzwave.object.ZWaveException: 'Zwave Generic Exception : Error when retrieving device /dev/ttyUSB-ZStick-5G : [\'Traceback (most recent call last):\\n\', \'  File "/usr/local/lib/python3.6/site-packages/openzwave/option.py", line 78, in __init__\\n    raise ZWaveException(u"Can\\\'t find device %s : %s" % (device, traceback.format_exception(*sys.exc_info())))\\n\', \'openzwave.object.ZWaveException: "Zwave Generic Exception : Can\\\'t find device /dev/ttyUSB-ZStick-5G : [\\\'NoneType: None\\\\\\\\n\\\']"\\n\']'

Have you seen this before?

The first thing I would do is go back and check my typing. A single character wrong will sink you.

Did you reboot your machine after the change of your udev rule?

also you can check to see if the machine sees the stick by using terminal on the host and typing:

ls -a /dev/tty*

it should be listed somewhere in the output.

Finity you are one the right track. he needs to run:

lsusb

To figure out what his vendor and product ID are. Copy pasting your example won’t do anything for him.

He could also just symlink it to /dev/zwave to make typing it easier.

Also to OP,why do you not have your docker compose setup as

- /dev/ttyACM0:/dev/ttyACM0

Then all you put in your hass config is:

zwave:
  usb_path: /dev/ttyACM0

I understand what you are are saying and I would agree normally to check to make sure of the bendor ID and such. And that could end up being good advice.

But if he is running an Aeotec Z-Stick Gen 5 then the info I gave him should work. As far as I know they all have that same info. Everything I’ve seen in researching this gives the same info for that stick. So copy and pasting my example should work.

However it is possible that they may have changed it recently so your above advice still is good to check.

And yes he could name the symlink whatever he wants. I just wanted to keep things simple and post up exactly what I had that worked for me. I’m not afraid of a little extra typing. :wink:

As to the last part, that will work as long as the USB stick is always assigned that address. If it changes on a reboot then he will lose functionality unless he makes the name persistent. Which is the point of the udev rule.

Doh, good point. I run the z-wave.me usb stick, so of course my values are different. I tried to make udev rules for the NUC I just moved to but that didn’t seem to work. I have rebooted twice and still have it at /dev/ttyACM0. If it gives me any issues I will pursue making the udev rules work right.

No problems with extra typing, I just like to keep things tidy. I think OP tried this and didn’t read the official hass z-wave docs or the docker install example. he could have put two and two together as to why he had this wrong, with correct examples commented out.

    devices:
#      - /dev/ttyUSB0:/dev/ttyUSB0
#      - /dev/ttyUSB1:/dev/ttyUSB1
      - /dev/ttyACM0:zwaveusbstick:rwm

not even sure where “zwaveusbstick:rwm” even came from.

Yeah I didn’t understand where that came from either.

I’m pretty sure what I told him to use should work.

Thanks for the discussion. As it turns out the udev-rule didn’t work for me, and I don’t know why. I did check the vendor id and spelling and whatnot. I probably did something wront, but it doesn’t matter. I changed back to

  • /dev/ttyACM0:/dev/ttyACM0

and now it works. Even when i tear down, and rebuild the ha container. It still doesn’t work when restarting the server. I then have to unplug and plug the usb, but I can live with that - I’m not planning on restarting the server that often.

when you restart your server and do the ls command from my post above is the stick listed there at ttyACM0?

By using /dev/serial/by-id there is no need to create a udev rule. The device will work even if you move your configuration to a new machine.
ls /dev/serial/by-id and put the resultant path in your config

1 Like

I tried that when I moved to docker but I couldn’t get it to see the z stick. So I just stuck with the udev rule that was already working fine.