-
Notifications
You must be signed in to change notification settings - Fork 659
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
Comments
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. |
Would you consider creating two docker images one for USB and one for ethernet? |
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. |
This can be closed as you kindly created a new image with ethernet support. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: