Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hass.io + Rpi3: USB devices are not exposed to /dev/xxx (udev rules not working) #9335

Closed
panosnl opened this issue Sep 8, 2017 · 20 comments

Comments

@panosnl
Copy link

panosnl commented Sep 8, 2017

Home Assistant release (hass --version):
0.52.1

Python release (python3 --version):

Component/platform:
RPi3

Description of problem:
when an usb device is plugged in it is recognised correctly in dmesg.
However there is no /dev/ttyUBSx or /dev/serial/by-id/xxx

hassio host hardware reports /dev/ttyUSB1 but this is not present

core-ssh:/# ls /dev/ttyUSB1
ls: /dev/ttyUSB1: No such file or directory
core-ssh:/# hassio host hardware
{
  "serial": [
    "/dev/ttyUSB1"
  ],

I seems that udev is not applying its rules.

verification with udevadm -monitor I see the kernel is detecting the addition of the usb serial or storage devices but that not udev rules are triggered to create symlinks.

I cannot add RFlink or Mysensor serial gateways without access to the USB ports.

This problem is reported by several users in the forum. the reported solution is to use HASSbian.

Expected:

When a usb serial device is added to the RPi udev will expose these device under
/dev/ttyUSB0 or /dev/serial/by-id

Problem-relevant configuration.yaml entries and steps to reproduce:

Traceback (if applicable):

Additional info:

@szogi
Copy link
Contributor

szogi commented Oct 1, 2017

Hi @panosnl,

Do you have /etc/udev/rules.d/99-com.rules file with the following contents?

SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
        chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
        chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
        chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
'"

KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
                echo 0;\
        elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi\
'", SYMLINK+="serial%c"

KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
                echo 0; \
        elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi \
'", SYMLINK+="serial%c"

If you are running Home Assistant as homeassistant user,
# usermod -a -G dialout homeassistant
command will be necessary (as root).

Also, you may look at this thread:
https://stackoverflow.com/questions/42266709/raspbian-jessie-udev-not-triggering-when-i-plug-in-my-usb-device

@alexciurea
Copy link

alexciurea commented Oct 12, 2017

Hi

Not sure if my issue is due to same root cause.
hassio with HA 0.55.0 on raspi 3.

I have a TEMPer usb temp sensor & i placed the 99-tempsensor.rules in /etc/udev/rules.d
content of the file is:
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="0c45", ATTRS{idProduct}=="7401", MODE="666"

The device:
core-ssh:~# lsusb
Bus 001 Device 008: ID 0c45:7401

I replugged the TEMPer sensor and restarted the Home Assistant, after copying the rule.

But it seems that the rule is not applied because i get this kind of error:

2017-10-12 14:15:55 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform temper
Traceback (most recent call last):

  File "/usr/lib/python3.6/site-packages/homeassistant/helpers/entity_component.py", line 164, in _async_setup_platform
    SLOW_SETUP_MAX_WAIT, loop=self.hass.loop)
  File "/usr/lib/python3.6/asyncio/tasks.py", line 352, in wait_for
    return fut.result()
  File "/usr/lib/python3.6/asyncio/futures.py", line 244, in result
    raise self._exception
  File "/usr/lib/python3.6/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/lib/python3.6/site-packages/homeassistant/components/sensor/temper.py", line 45, in setup_platform
    temper_devices = get_temper_devices()
  File "/usr/lib/python3.6/site-packages/homeassistant/components/sensor/temper.py", line 33, in get_temper_devices
    return TemperHandler().get_devices()
  File "/usr/lib/python3.6/site-packages/temperusb/temper.py", line 420, in __init__
    usb.core.find(find_all=True, idVendor=vid, idProduct=pid)]
  File "/usr/lib/python3.6/site-packages/temperusb/temper.py", line 419, in <listcomp>
    self._devices += [TemperDevice(device) for device in \
  File "/usr/lib/python3.6/site-packages/temperusb/temper.py", line 95, in __init__
    self.lookup_sensor_count()
  File "/usr/lib/python3.6/site-packages/temperusb/temper.py", line 164, in lookup_sensor_count
    if (self._device.product == 'TEMPer1F_V1.3') or \
AttributeError: 'Device' object has no attribute 'product'

...as if the product is missing attribute, although it's specified in the rule file.

I tried also to restart the entire hassio box (not just the home assistant) - and the rules file get's deleted...

Please suggest if it should deserve different issue, but it looks like same root cause...

@jondye
Copy link

jondye commented Oct 16, 2017

I'm seeing the same issue.

core-ssh:~# ls /dev/tty*
/dev/tty
core-ssh:~# hassio host hardware
{
  "serial": [
    "/dev/ttyACM0",
    "/dev/ttyUSB0"
  ],
  "input": [],
  "disk": [],
  "audio": {
    "0": {
      "name": "bcm2835 - bcm2835 ALSA",
      "type": "ALSA",
      "devices": {
        "0": "digital audio playback",
        "1": "digital audio playback"
      }
    }
  }
}

@zachradtka
Copy link

I am having the same error as @jondye

I am running on a RPi3:
Home Assistant 0.56.2
HassIO 0.73

@Mori
Copy link

Mori commented Dec 2, 2017

Similar error here. I attempted to turn off the "disco lights" on the Aeotec Z-stick as described here, but I get this:

core-ssh:/config# echo -e -n "\x01\x08\x00\xF2\x51\x01\x00\x05\x01\x51" > /dev/serial/by-id/usb-0658_0200-if00
-ash: can't create /dev/serial/by-id/usb-0658_0200-if00: nonexistent directory

I'm running the latest hass.io on a RPi3. Noob here, so far I've just added a couple of components and switches. Any suggestions?

@lindadick
Copy link

I had this error too, but eventually got it working after reading the instructions at https://home-assistant.io/hassio/zwave/, in particular this section:

For some devices the /dev/ttyAMA0 device is not detected by udev and is therefore not mapped by Docker. To explicitly set this device for mapping to Home-Assistant, execute the following command using the ssh add-on:

$ curl -d '{"devices": ["ttyAMA0"]}' http://hassio/homeassistant/options

After that, you need to change usb_path to /dev/ttyAMA0 in your configuration.yaml.

zwave:
  usb_path: /dev/ttyAMA0

It took me a while to figure out that /dev/ttyAMA0 is just an example and should actually be replaced with the device that is listed when running hassio host hardware, which in my case is actually /dev/ttyACM0. Once I worked that out, and used the correct device name in both the curl command and the configuration.yaml file, it worked for me. I hope that helps!

@balloobbot
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

@bohtho
Copy link

bohtho commented Mar 4, 2018

This is still very much an issue for me. I can't for the life of me get my TAPKO USB (HID) (KNX-RF) stick to get an actual device address, or get anything to communicate with it under hass.io, as opposed to under Windows or other Linux OSes.

As said over I can see it recognised with dmesg but only generically under lsusb (vendor and product is there but the description is gone) and not at all as a /dev/xxx

@alexciurea
Copy link

alexciurea commented Mar 4, 2018

Still an issue also for me.
Running hass.io 0.64.3 with Host controller version 1.2 (latest as of today).
On this versions, the file /etc/udev/rules.d/99-tempsensor.rules does not get deleted anymore, but temper platform still not recognized, same error as earlier:
AttributeError: 'Device' object has no attribute 'product'

No /dev/tty* device.

temper sensor is visible in lsusb and appears in dmesg when plugged in.
Also the sensor is recognized by the hassio host hardware command:
core-ssh:/dev# hassio host hardware
...
"input": [
"RDing TEMPerV1.4"
...

@giuseppeg88
Copy link

giuseppeg88 commented Mar 20, 2018

I have the same problem with my RPi2 and hass.io 0.65.5.

[973905.332052] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[973905.444495] usb 1-1.2: New USB device found, idVendor=2a03, idProduct=804f
[973905.444523] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[973905.444539] usb 1-1.2: Product: Arduino M0 Pro
[973905.444554] usb 1-1.2: Manufacturer: Unknown
[973905.444570] usb 1-1.2: SerialNumber: 35FB41A85150334C414A2020FF040635
[973905.509489] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[973905.516572] usbcore: registered new interface driver cdc_acm
[973905.516600] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
core-ssh:~# hassio host hardware
{
    "result": "ok",
    "data": {
        "serial": [
            "/dev/ttyAMA0",
            "/dev/ttyACM0"
        ],
        "input": [],
        "disk": [],
        "gpio": [
            "gpiochip0"
        ],
        "audio": {
            "0": {
                "name": "bcm2835 - bcm2835 ALSA",
                "type": "ALSA",
                "devices": {
                    "0": "digital audio playback",
                    "1": "digital audio playback"
                }
            }
        }
    }
}
core-ssh:~# ls /dev/tty*
/dev/tty

@blkqi
Copy link

blkqi commented Mar 20, 2018

When you SSH to your hassio instance using the SSH add-on, you will get a shell inside of an add-ons container. Only specific resources are passed through to this container, and USB devices are not one of them. This does not mean that they are not available to HA.

I recommend you follow the documentation specific to hassio on the RPI3: https://home-assistant.io/hassio/zwave/

@alexciurea
Copy link

can you be more specific?
I can see my zwave aeon stick while logging to the container.
indeed i declared the controller in the configuration.yaml file, to a certain path.

For the temper sensor / platform, i did not do such thing - how to do it? what should be the path?

thanks,
a

@alexciurea
Copy link

seems there is no solution/recommendation/idea to this issue.
is it indeed acknowledged as an issue?

@MartinHjelmare
Copy link
Member

This is not an issue with home assistant but a config issue with Hass.io.

@lindadick
Copy link

lindadick commented Sep 18, 2018 via email

@JakobTewes
Copy link

Please give this a try:
https://community.home-assistant.io/t/using-bluetooth-and-dtoverlay-pi3-miniuart-bt/63971/3

Let me know, if it helps :-)

Jakob

@ir-fuel
Copy link

ir-fuel commented Dec 29, 2018

I fail to see the link between the url posted above and the issue in this ticket

@Velby
Copy link

Velby commented Apr 23, 2020

Ok I dug deeper and found the source of the issue:
temperusb requires the stable version of pyusb instead of the one being shipped with home assistant. I was able to do a temporary fix by:

  • getting a shell on the home assistant container
  • pip uninstall pysb
  • pip install pyusb

This installed the stable version of pyusb and got everything working, but it'll have to be done everytime I deploy a new container

@alexciurea
Copy link

wow, thanks Velby, i did not reach that far...
I am not familiar with the lifecycle of the issues, but this means the issue is real and can be reopened? (currently closed)

The temporary fix - in practice, it means that every time there's a new release update of the Home Assistant Core, these steps need to be done?
thanks!
-a

@Velby
Copy link

Velby commented Apr 25, 2020

The temporary fix - in practice, it means that every time there's a new release update of the Home Assistant Core, these steps need to be done?

Yes I imagine my fix would need to be redone every time the docker container is replaced.

but this means the issue is real and can be reopened?

The issue is definitely real but there are two ways to permanently fix it:

  1. Have home assistant use the version of pyusb that is compatible with the temperusb library
  2. Fix the temperusb library to support both versions of pyusb

I haven't looked into which solution is more sensible. I imagine home assistant chose its current version of pyusb for a reason in which case solution 1 is a no-go. I haven't looked into what it would take to implement solution 2, their github page is located here:
https://github.com/padelt/temper-python

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests