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

Passing /dev/hidraw* through to HA in docker #66

Open
ff4500 opened this issue Nov 26, 2019 · 27 comments
Open

Passing /dev/hidraw* through to HA in docker #66

ff4500 opened this issue Nov 26, 2019 · 27 comments

Comments

@ff4500
Copy link

ff4500 commented Nov 26, 2019

Previously, I had the component setup in my compose file to pass through with:

devices:
      - /dev/hidraw1:/dev/hidraw1

That worked out pretty well, until a reboot of the host system which changed the hidraw device. HA didn't open, had to remove from the config, yadda yadda.

So, I thought that the new version with device: auto would be the ticket. I'm sure that that it works great, but how would I go about passing a randomly assigned device to pass through in my compose file? I don't really want to mount the whole /dev dir and run in privileged mode if I can help it.

@kevinvincent
Copy link
Owner

kevinvincent commented Nov 28, 2019

I don't have much experience with docker but if you mount the whole /dev dir you don't need to run in privileged mode right? It should still be able to read / write to the device?

@tomhoover
Copy link
Contributor

@ff4500, here's how I did it:

  1. Create /etc/udev/rules.d/99-wyze.rules:
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="e024", SYMLINK+="wyzesense"
  1. Restart the host and verify the symlink /dev/wyzesense was created.
  2. Edit docker-compose.yml to include:
    devices:
      - /dev/wyzesense
  1. Edit configuration.yml to include:
binary_sensor:
  - platform: wyzesense
    device: /dev/wyzesense
  1. Don't forget to stop your home-assistant docker container (e.g. docker stop xxx or docker-compose down xxx), and restart it via docker-compose up -d. If you only restart hass itself (without recreating the docker container), docker won't pass-thru '/dev/wyzesense'. (Ask me how I know that to be the case 🤦‍♂)

@jes1417
Copy link

jes1417 commented Jan 15, 2020

This worked perfectly for me in my container.

@bepstein111
Copy link

bepstein111 commented Mar 28, 2020

@tomhoover

@ff4500, here's how I did it:
...
2. Edit docker-compose.yml to include:

Forgive me for my lack of knowledge, but when you refer to docker-compose.yml, do you mean one that we have set up previously, or is there one somewhere on the hassio-supervisor image that can be edited for launching the homeassistant container? Obviously I'm running hassio, not sure if this was meant specifically for HA Core?

@TheColtron
Copy link

@bepstein111 Did you ever figure this out by chance? I'm migrating to Hassio in docker and this is the one sticking point that I can't seem to get around.

@bepstein111
Copy link

bepstein111 commented Apr 9, 2020

@bepstein111 Did you ever figure this out by chance? I'm migrating to Hassio in docker and this is the one sticking point that I can't seem to get around.

unfortunately not. I ended up just buying a Nabu Casa subscription and adding the devices via Wyze App > Amazon Alexa Wyze Skill > HA Alexa Integration. Bit of a workaround, but most things in hassio seem to be, and it added some other features I was looking for like automagic SSL/HTTPS.

I did notice that I hadn't actually tagged the original commenter, so I just did that and maybe we'll get a reply.

@TheColtron
Copy link

@bepstein111 Thanks for the quick reply.

They have an Alexa skill now?! That's good enough for me, and I don't think I would've thought to look at that option. Thank you!

@kevinvincent
Copy link
Owner

kevinvincent commented Apr 9, 2020 via email

@ff4500
Copy link
Author

ff4500 commented Apr 9, 2020

Of note, I haven't tried the suggested steps above yet, since I moved my HA environment over to a NUC from my Hypervisor (Proxmox, Alpine VM running on a Dell server with USB passthrough setup). The NUC doesn't seem to reassign the hidraw device on reboot, and it's been rock solid.

If I move it back to the Hypervisor, I will definitely try the link steps again. And @kevinvincent, I have tried the Alexa HA integration before and it wasn't quick like local polling. As much as we lose power/internet in the spring, I appreciate being able to still use sensors to turn my lights on and off when I can't connect to the internet.

@bepstein111
Copy link

bepstein111 commented Apr 9, 2020

@kevinvincent If you do it within the Alexa app, it's immediate - I have motion sensors on mine and they're quite responsive. I hate not having EVERYTHING running through HA, but honestly, it works well, and I'm not opposed to opening up a second app when I need to. That said, I TOTALLY understand @ff4500 sentiment about losing power/internet. Not sure if Alexa remembers triggers during outages (internet, that is), so it may or may not work without internet.

@sdunnagan
Copy link

@tomhoover Thanks for your solution with the symbolic link to the hidraw device. I see the link getting created,sometimes to hidraw0, sometimes hidraw1, etc. The only problem is that I don't know how to update the Docker containers used by Home Assistant Supervised.

@tomhoover
Copy link
Contributor

tomhoover commented Apr 11, 2020

@bepstein111, @TheColtron, @sdunnagan, I do not use Home Assistant Supervised, so the following suggestion is based upon a quick review of the Home Assistant Supervised installer. Beware this is untested, and should only be used if you're comfortable with the command line.

  1. Find the script hassio-supervisor (installed in /usr/sbin by default).
  2. Create a backup of the file in case this doesn't work for you.
  3. Edit hassio-supervisor and search for the line -v /run/dbus:/run/dbus \
  4. Immediately following that line, add the following line:
-v /dev/wyzesense:/dev/wyzesense \
  1. From a command line, execute systemctl restart hassio-supervisor.service. (If that doesn't restart the service, you may need to restart your system for it to read the new file.)

If anything breaks, please restore the backup file you made earlier, and reboot your system. As mentioned above, this has not been tested by me, so BE CAREFUL!

@sdunnagan
Copy link

sdunnagan commented Apr 11, 2020

Very helpful, thanks!

My HA config looks like:

/usr/share/hassio/homeassistant/configuration.yaml
--------------------------------------------------
...
binary_sensor:
  - platform: wyzesense
    device: /dev/wyzesense
    initial_state:
      77793176: "on"
      77793193: "off"

Docker is getting run as you suggested with the volume mount of the device file:

    docker run --name hassio_supervisor \
        --privileged \
        $APPARMOR \
        --security-opt seccomp=unconfined \
        -v /run/docker.sock:/run/docker.sock \
        -v /run/dbus:/run/dbus \
        -v /dev/wyzesense:/dev/wyzesense \
        -v "${HASSIO_DATA}":/data \
        -e SUPERVISOR_SHARE="${HASSIO_DATA}" \
        -e SUPERVISOR_NAME=hassio_supervisor \
        -e HOMEASSISTANT_REPOSITORY="${HOMEASSISTANT}" \
        "${SUPERVISOR}"

But device isn't detected, and I see this in the log:

FileNotFoundError: [Errno 2] No such file or directory: '/dev/wyzesense'

However, udev did in fact create the symbolic link:

$ ls -al /dev/wyzesense
lrwxrwxrwx 1 root root 7 Apr 11 14:41 /dev/wyzesense -> hidraw0

Anyway, I can live with configuring HA with "device: auto". But it's an interesting problem.

@bepstein111
Copy link

@sdunnagan with hassio supervised, the problem is that /dev/wyzesense exists on the local machine, but not inside the container that HA runs inside of. @tomhoover 's latest reply should fix that, hopefully.

@haxx0r07
Copy link

The issue with @tomhoover 's changes is that that only passes the device into the container for the supervisor. This does not actually pass the device into the container where Home Assistant actually runs. I've been looking through all of the supervisor configuration/script but I can't find where or what it uses to create the container running home assistant.

@bepstein111
Copy link

bepstein111 commented Apr 14, 2020

The issue with @tomhoover 's changes is that that only passes the device into the container for the supervisor. This does not actually pass the device into the container where Home Assistant actually runs. I've been looking through all of the supervisor configuration/script but I can't find where or what it uses to create the container running home assistant.

This was the brick wall I faced as well. Bummer that the latest attempt by tom wasn't successful. Definitely interested in any solutions, but for now, 5 bucks a month was worth it to me.

@TheColtron
Copy link

Just curious, how quick is the alexa trigger method? Honestly even though I developed this I'd prefer a more first-party supported integration given the weird quirks the custom component has.

I finally got some time to test the Alexa integration and ended up reverting back to this component pretty quickly. The Alexa route is very responsive, but the major downside is that node-red control is much more difficult. Some of my motion rules are pretty elaborate and can't really be translated into Alexa routines, so this component is much more valuable imo.

@RonSpawnson
Copy link

RonSpawnson commented Apr 27, 2020

Following this issue, as if we can determine how to make this work for HA supervised, it will unlock my ability to create auto-restart for the sensors not responding issue: #114.

I'm noticing occasionally my sensors stop responding, and the hidraw device has changed. When I try re-initializing the entire component, it says the new /dev/hidrawN file is not found, even though I can see it in /sys/class/hidraw. Suspect I'm running into the issue you all are, and keen to see if someone figures out how to fix it.

@RonSpawnson
Copy link

RonSpawnson commented Apr 27, 2020

@haxx0r07 I think this is where supervisor runs the homeassistant container, and this is where they configure which volumes are to be used/bound.

Perhaps we can add a volume binding here? The only issue is I'm not exactly sure how to locally make a change to this and run it locally. The README for homeassistant supervisor seems to make it sound like you need to use hassio-builder with custom tagged image, it's not clear to me at all how I'd modify this and test it locally.

@RonSpawnson
Copy link

Talking with Supervisor devs, sounds like Supervisor has a hardware abstraction layer to support udev devices. Looks like "hidraw" devices are not yet looked for in this abstraction layer, so we should look into adding them: https://github.com/home-assistant/supervisor/blob/dev/supervisor/misc/hardware.py

@haxx0r07
Copy link

Nice work @RonSpawnson I'm not the best with python, but I'll look through that file and see if I can come up with anything.

@RonSpawnson
Copy link

RonSpawnson commented Apr 29, 2020

I've got a diff I can share this evening, I just cannot figure out how to use hassio-build to create a test image to try it out as per README, so I have no way of testing. I opened an issue asking for clarification and did receive a tip, so that's next on my plan of action when I get more free time home-assistant/supervisor#1685 (comment)

@carltonwb
Copy link

I am running hassio in a VM on unraid installed witha a quecow2 file.
I can plug in the device and run lsusb and it does find it.
I have enabled it in the unraid VM. I do not have access to a docker container to change the udev rules. Did try to do it on the unraid server but every time the file would disappear.
I have run dmesg | grep hidraw and this is the result

[ 10.421011] hidraw: raw HID events driver (C) Jiri Kosina [ 12.632714] hid-generic 0003:051D:0002.0001: hiddev96,hidraw0: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [ 13.202984] hid-generic 0003:1A86:E024.0002: hiddev97,hidraw1: USB HID v1.00 Device [HID 1a86:e024] on usb-0000:00:14.0-13/input0 [ 781.737274] hid-generic 0003:051D:0002.0003: hiddev96,hidraw0: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [23912.624848] hid-generic 0003:1A86:E024.0004: hiddev96,hidraw0: USB HID v1.00 Device [HID 1a86:e024] on usb-0000:00:14.0-13/input0 [23914.086048] hid-generic 0003:051D:0002.0005: hiddev97,hidraw1: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [23926.641196] hid-generic 0003:051D:0002.0006: hiddev96,hidraw0: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [25611.752758] hid-generic 0003:051D:0002.0007: hiddev96,hidraw0: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [25619.450795] hid-generic 0003:051D:0002.0008: hiddev96,hidraw0: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [27991.703708] hid-generic 0003:1A86:E024.0009: hiddev96,hidraw0: USB HID v1.00 Device [HID 1a86:e024] on usb-0000:00:14.0-13/input0 [27993.165598] hid-generic 0003:051D:0002.000A: hiddev97,hidraw1: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [28028.016852] hid-generic 0003:051D:0002.000B: hiddev96,hidraw0: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [29130.877253] hid-generic 0003:1A86:E024.000C: hiddev96,hidraw0: USB HID v1.00 Device [HID 1a86:e024] on usb-0000:00:14.0-4/input0 [30401.157644] hid-generic 0003:051D:0002.000D: hiddev97,hidraw1: USB HID v1.00 Device [American Power Conversion Back-UPS NS 1500M2 FW:957.e3 .D USB FW:e3 ] on usb-0000:00:14.0-10/input0 [31160.267145] hid-generic 0003:1A86:E024.000E: hiddev96,hidraw0: USB HID v1.00 Device [HID 1a86:e024] on usb-0000:00:14.0-4/input0

I have added the appropriate binary sensor in my yaml file.
I do not see the hidraw listed in my system hardware.
Any help is truly appreciated.

@xenocidex
Copy link

I am also I am running hassio in a VM on unraid installed witha a quecow2 file @carltonwb did you ever find a resolution?

@chabad360
Copy link

I've got a diff I can share this evening, I just cannot figure out how to use hassio-build to create a test image to try it out as per README, so I have no way of testing. I opened an issue asking for clarification and did receive a tip, so that's next on my plan of action when I get more free time home-assistant/supervisor#1685 (comment)

Did you ever get it working?

@RonSpawnson
Copy link

RonSpawnson commented Nov 13, 2020 via email

@fortwally
Copy link

tomhoover commented on Dec 28, 2019.
This method worked for me. Just running HA in docker

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