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

Allow user-set devices #331

Closed
korylprince opened this issue Jan 26, 2018 · 6 comments
Closed

Allow user-set devices #331

korylprince opened this issue Jan 26, 2018 · 6 comments
Labels

Comments

@korylprince
Copy link

I'm running into an issue with my apcupsd add-on where I'm hitting the limits of the current Hass.io system. This is somewhat related to issue #201.

Issue

apcupsd can connect to USB devices directly or to a device or another server over the network. I have to include "devices": ["/dev/usb/hiddev0:/dev/usb/hiddev0:rwm"] for users who directly connect to the UPS, but this causes the add-on not to start for those using the add-on for a network device (i.e. no device connected) because the /dev/usb/hiddev0 doesn't exist.

Using /dev/usb/* or /dev/usb doesn't work because that directory doesn't exist unless an HID device exists and the add-on fails to start.

Using /dev/bus/usb doesn't work either, I think because those devices are raw access and not using the HID driver, but I can't find much information on the subject. I've tried using those device directly, however and they don't work.

Using auto_uart doesn't work because it's not a serial device.

Possible Solutions

I would love for someone to find a simple way to support both configurations, but I don't think it's possible. Here's some ideas I think would work.

HID Device Detection

You could add detection of HID devices like audio and serial devices are detected, then add an option like auto_uart to the add-on API to have those mounted automatically. This would solve the issue for my add-on, but I don't think it would solve the problem overall.

Conditional Devices

You could have the supervisor check if the device exists before passing it to docker. If it doesn't you could just drop the device from the devices passed to docker. I imagine this is possible with pyudev, but it sounds brittle, and some add-on authors may not want that functionality (the add-on might strongly depend on that device being present.)

User Set Devices

Finally, you could add an option to the add-on API whereby an add-on author could specify (a) user-set device(s) (with a default option.) This could work much like the port option where a user can change the listening port(s). Obviously this would require modifying the add-on API and the UI, but I think it's the most portable option.

@tboyce021
Copy link

I like the idea of user set devices. It seems flexible enough to accommodate a number of use cases. For example, I tested out OpenHAB using the addon but in order for it to access my zwave stick I had to copy the addon to my local repository and add the mappings in the config. With user set devices, I could just add the mappings in the UI while still using the original addon.

@genestealer
Copy link

Would you consider creating two docker images one for USB and one for ethernet?

@stale
Copy link

stale bot commented Apr 16, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 16, 2019
@genestealer
Copy link

This can be closed as you kindly created a new image with ethernet support.

@stale stale bot removed the stale label Apr 16, 2019
@korylprince
Copy link
Author

I did create a second add-on to get around this issue, but I think it's still an issue.

Maybe there's not that many add-ons that need or would use this functionality, so it's not worth it to spend the time to fix it, but it sure would be nice.

@stale
Copy link

stale bot commented Jun 15, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

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

No branches or pull requests

3 participants