Hi. I am running the HomeAssistant rockon and need to give it access to my USB Z wave stick. Can anyone point me in the right direction please? Found plenty of examples for other systems but I can’t seem to find the relevant files to alter. Thanks!
Did you ever receive an answer on this? I am looking for the same info?
Chas
Hi,
I’m not familiar with this particular rock-on, but trying to mount Z-wave stick device at docker run time should be a good start (at the very least), and it apparently seems to have been the way to go for some users, although with some variation:
As to how to apply this to the Home Assistant rock-on, we unfortunately do not support adding a device to an already installed rock-on (although this is on my to-do list). We do have the option to add a device at the install step, however, if the JSON definition file is altered to support it. As the latter is optional, this could be a valuable addition to this rock-on.
If you want to try this option, you’ll find some documentation on the rock-on devices object in the README:
An example of a rock-on using this feature is Emby, with the following:
I could be completely out of the park here, but this could be the answer to this issue. As I mentioned earlier, I do plan on making it possible to mount a device to a rock-on post-install, but I do have other aspects on my list first, however.
Hope this helps,
1 Like
Flox, I apologize for my lack of understanding. As I read the information that you sent, I think that I am following the gist but kinda lost on the specifics.
Please feel free to speak to me like a 5 year old.
What I believe you are telling me is this:
In order to have HA use the Zwave usbstick, I will need to edit the Json for HA before installation. Yes?
What info do I enter ?
I pulled [root@rockstor ~]# crw-rw---- 1 root dialout 166, 0 Apr 18 08:32 /dev/ttyACM0
With this command; [root@rockstor ~]# [root@rockstor ~]# ls -ltr /dev/tty*|tail -n 1
and this: [root@rockstor ~]# [36905.828554] cdc_acm 8-1:1.0: ttyACM0: USB ACM device
With ; [root@rockstor ~]# dmesg | grep USB
My guess is that I need to do something like this;
“devices”: {
“ZwaveUSBStick”: {
“description”: “Optional: /dev/ttyACM0. Leave blank if not needed.”,
“label”: “ZwaveUSBStick”
}
},
But I’m also pretty sure that if I try this I will find myself FUBAR
Am I even in the right Zip Code?
Chas
Hi @kysdaddy,
First, let me apologize for such a delay in getting back with you with regards to this… I should have been a lot quicker than that. I am sincerely sorry.
The good news, is that you were absolutely correct and that your edits are following the proper syntax. I tried an edited version of the json file including your changes, and it works as intended.
Now, to actually use them, I see two points for now:
- If these changes actually do allow you to use the Zwave stick, it would be really helpful if you could submit an issue and corresponding PR on the rockon-registry repository on Github (linking to this forum thread for context) so that this change can be integrated with the default
Home assistantrock-on. - If you want to start testing whether mounting the ZWave usb stick works when mounted this way–as the link from the Home assistant community I shared above seems to indicate–you will need to create a separate rock-on in the rockons-metastore folder (as explained in our readme here). In order to prevent conflicts, however, you will need to change the rock-on name and container name, such as I did below for instance:
{
"Home Assistant with Device": {
"description": "Home Assistant is an open-source home automation platform running on Python 3. Track and control all devices at home and automate control.",
"ui": {
"slug": ""
},
"website": "https://home-assistant.io/",
"version": "1.0",
"containers": {
"home-assistant-device": {
"image": "homeassistant/home-assistant",
"launch_order": 1,
"opts": [
[
"--net",
"host"
]
],
"devices": {
"ZwaveUSBStick": {
"description": "Optional: /dev/ttyACM0. Leave blank if not needed.",
"label": "ZwabeUSBStick"
}
},
"uid": -1,
"ports": {
"8123": {
"description": "Home Assistant UI port. You may need to open it(protocol: tcp) on your firewall.",
"host_default": 8123,
"label": "Server port",
"protocol": "tcp",
"ui": true
}
},
"volumes": {
"/config": {
"description": "Choose a Share for Home Assintant configuration.",
"label": "Home Assistant Config"
}
}
}
}
}
}
It will create a duplicate Home Assistant entry in your list of available rock-ons, however. It is also important to note that this rock-on uses the --net=host option, which means that the port mapping is pretty much ignored and has the following consequences:
- Port 8123 needs to be the value entered for the port number during the rock-on install. You will see that Rockstor will use by default 8124 for this duplicate json as 8123 is already supposed to be in use by the original Home Assistant rock-on. Make sure to input 8123 during the rock-on install.
- If port 8123 is already in use by something else on your machine, you will likely get conflicts.
- You can input a different port than 8123 during the install, but then the UI button will direct you to a non-functional address, as the home-assistant server will only be accessible at port 8123. That’s actually something we can try to better account for and deal with in the future.
Thanks for keeping us updated, that seems like a very nice addition if that can make Home assistant to work with the Zwave stick.
1 Like
@Flox @kysdaddy Gentlemen, how did this end up getting resolved? I’m running the CentOS based Rockstor 3.9.2-57 and just installed the Home Assistant RockOn, and it does not recognize my USB Zwave stick. I plugged it in prior to install thinking that would get it recognized, but I was wrong. After reading this post if I understand things correctly, I don’t have any option from the command line to pass the USB stick through at this point. However, since this post is 5 years old, I want to see if that’s still true. If it is, it looks like following the instructions to add a new entry in the metastore is the answer, but I’m not finding that folder in my system. Is this a Suse reference? I’m using the openVPN RockOn so I’ve got the basic prep work for running RockOns completed, I just need to figure out the USB portion. If someone has already written the json, I’d like to know where to find it. I checked github repository, and I don’t see a device section in the existing so I assume if the change was made it was never committed. Any help greatly appreciated.
thanks, Del
@D_Jones hello again.
I don’t believe this was ever resolved, so you probably have to create your own Rockon for this.
The rockons-metastore folder also applies to the now out-of-maintenance CentOS version of Rockstor. On both CentOS and the openSUSE version you have to create the folder yourself, so you can place a custom Rockon into it, that will then be recognized once you select the Update on the Rockon screen.
Just remember, that the Rockon needs to have different names for the containers inside the json file, otherwise Rockstor will complain about it.
Hope, you will get an opportunity though to upgrade to the latest Release Candidate under 5.x soon, to take advantage of the latest security and some additional functionality pieces that have been added since the last CentOS-based version 
2 Likes
@Hooverdan thank you for the quick response. I would love to move to the openSUSE system. I tired about 2 years ago, but had some pool import errors so fell back to Cent OS, and haven’t found time to try again. I used a 2nd SSD for the OS, so fall back was quick and easy. At this point it’s been so long I’ll need to do a new install on the 2nd SSD with the most recent version and try again. In the meantime I’m going to try and get HA working on the legacy install. So if I’ve understood all the previous conversations I think this is the road ahead. Sanity check requested please.
To pass through the USB, I need to uninstall the current version, and probably delete the contents of the config directory for good luck since I don’t really have anything set up. Then create a new .json with a unique name and store it locally in the newly created metastore directory. When I refresh the RockOns page in the Rockstor the UI should pick up the local .json and add it to the list, and I can install from there as before with this time with an opportunity to add the Zwave USB.
If I understand what I need to do it should go something like this.
Create metastore directory
mkdir /opt/rockstor/rockons-metastore
Grab the existing .json from here
Save in the metastore directory with a unique name home-assistant-linuxserver-with-USB
Edit that file and add a devices section following this model
"devices": {
"VAAPI": {
"description": "<u>Optional:</u> path to hardware transcoding device (/dev/dri/renderD128). Leave blank if not needed.",
"label": "VAAPI device"
}
},
Final .json should look like this
{
"Home Assistant Linuxserver with USB pass through": {
"description": "Open source home automation that puts local control and privacy first.<p>Note that this container uses host networking to allow for multi-cast and uPnP functionality that Home Assistant provides. This version also using a non-root user.</p><p>If you intend to add Zwave or Zigbee networks this will give you the option to pass those through to the container.</p><p>Based on a custom docker image: <a href='https://hub.docker.com/r/linuxserver/homeassistant' target='_blank'>https://hub.docker.com/r/linuxserver/homeassistant</a>, available for amd64 and arm64 architecture.</p>",
"ui": {
"slug": ""
},
"website": "https://home-assistant.io/",
"version": "1.2",
"containers": {
"homeassistantusb": {
"image": "lscr.io/linuxserver/homeassistant",
"tag": "latest",
"launch_order": 1,
"opts": [
[
"--net",
"host"
]
],
"devices": {
"ZwaveUSBStick": {
"description": "Optional: /dev/ttyACM# or /dev/ttyUSB#. Can be found with command ls -l /dev/serial/by-id. Leave blank if not needed.",
"label": "ZwaveUSBStick"
},
"ZigbeeUSBStick": {
"description": "Optional: /dev/ttyACM# or /dev/ttyUSB#. Can be found with command ls -l /dev/serial/by-id. Leave blank if not needed.",
"label": "ZigbeeUSBStick"
}
},
"ports": {
"8123": {
"description": "Home Assistant UI port. Because host network mode is used, this must be set to port 8123. You may need to open the same port on your firewall (protocol: tcp).",
"host_default": 8123,
"label": "Server port",
"protocol": "tcp",
"ui": true
}
},
"volumes": {
"/config": {
"description": "Choose a Share for configuration. E.g.: create a Share called ha-config for this purpose alone.",
"label": "Home Assistant Config Share"
}
},
"environment": {
"PUID": {
"description": "Enter a valid User ID (UID) to run Home Assistant with. It must have full permissions to all Shares mapped in the previous step.",
"label": "UID",
"index": 1
},
"PGID": {
"description": "Enter a valid Group ID (GID) to use along with the above UID. It(or the above UID) must have full permissions to all Shares mapped in the previous step.",
"label": "GID",
"index": 2
}
}
}
}
}
}
I know Zwave and Zigbee are 2 popular networks for home automation devices so I duplicated the device section so you could add either or both. I assume that works, and since they’re optional the user can do some, none, or all if desired. If anyone wants to peer review my code, I’m happy to get comments.
I’d be happy to contribute this to the github repository, but I’m probably not going to get to it any time soon so if someone wants to grab this and contribute you won’t hurt my feelings. I’ve contributed to docs before, but not the code base.
I’d be interested to know if anyone thinks this is worthy of a howto, I’d be happy to write one up, but I feel like all of this already exists so my not be worth it.
Thanks again for the help and feedback, Del
2 Likes
Progress update. I took the original json I wrote added it to the metastore folder, ran an update and it threw a duplicate container error so updated the json with homeassistantusb in place of original homeassistantlsio. It now shows up in the list with no errors. I’ve edited the post above to include this correction.
2 Likes
One more progress update. Deleted the files in the old config directory and uninstalled the old rockon. Installed the new one and it prompted me for the device. When I got the summary after install the device has no name, I don’t know if that’s a problem or not.
If it is, I’ll have to go look at the json and figure out what to change.
After install I went to the home assistant UI and it recognized me as already having an account and had my previous integrations so some data must have lingered. That surprised me. I tried to add the USB stick and still got an error. I have to enter the path to the USB stick when I try and add it in home assistant, and the default path is suggests is localhost:3000 I tried changing it to /dev/ttyACM0 and go an error. I think I need to figure out how to determine if the container actually does see the USB stick, and then what path to enter for the device. I am unfortunately not proficient in containers so would love a couple suggestions.
@Hooverdan @Flox @phillxnet do you know if the missing label in the summary table a problem that needs to be corrected for the container to address the USB device? If it’s not the problem I’ll focus my troubleshooting elsewhere, if it is, I’ll fix the json.
Thanks,
Del
1 Like
The missing label in the summary table is the normal behavior (see for example the write-up for the Plex rockon in our docs that shows the same: Plex Server Rock-on — Rockstor documentation). It’s mostly a display quirk that we haven’t improved yet, unfortunately.
I would have to refresh myself about adding such a device to he HA container, I’m afraid. I’m really sorry for not being able to help further at the moment. Note that any result you would find after searching online for people having the same issue for the Home Assistant docker container should be applicable here as well as that’s pretty much what Rockstor is doing: running the docker container.
I’ll try to have a better look soon.
Edit:
By the way, could you clarify whether you verified your device path was indeed seen as that by your machine? This would listed when running the following on your Rockstor machine:
ls -l /dev/serial/by-id
2 Likes
@Flox Thanks for the response, sorry I left that out of the post, yes my system sees the device
[root@jonesville HA-Config]# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Nov 23 16:18 usb-Zooz_800_Z-Wave_Stick_533D004242-if00 → …/…/ttyACM0
and if I ls /dev I see a ttyACM0 device
I started a container shell
> docker exec -it <container-id> /bin/bash
and ran a ls -l /dev/tty* and here’s what I got.
root@jonesville:/# ls -l /dev/tty*
ls: cannot access ‘/dev/tty’: Operation not permitted
ls: cannot access ‘/dev/ttyACM0’: Operation not permitted
I made my home assistant user part of the user group and make sure it had rw for the config share, but I’m guessing it doesn’t have the necessary permissions to access the USB device. If you think that’s a valid assumption I can assign it to a new group. I was thinking sys but would appreciate some guidance on that decision. Least privilege is the goal.
Thank you very much for you help with this.
Del
Did a little more research on Home Assistant forums, and I think the user isn’t the problem, I think it’s container privileges, I need to figure out how to restart the container in privileged mode and if that gives container access to the USB stick, where to make that change permanent.
Ooooh, that does make a lot of sense. I believe it is referring to the following: docker run | Docker Docs
Have a look at the scrutiny rock-on for an example on how to use it: rockon-registry/scrutiny.json at b3a6b7aaedfd122c8fe179819a870149965d4b25 · rockstor/rockon-registry · GitHub
@Flox Great reference with the scrutiny file, I will see about working the privilege opt into the HA json later today and reinstall. If this fixes the problem, I think the more secure option is probably a cap-add option in the final version to add access to the USB without giving the image the keys to the kingdom. I just out about cap-add so will need to figure out if doing that for serial devices if even possible. Thanks again for the help.
Del
I think the new opt section of the HA json will look like this.
“opts”: [
[
“–net”,
“host”
],
[
“–privileged”,
“”
]
],
From what I can tell the “” after --privileged is looking for a value, but I’m not sure what value it’s looking for. I don’t see any comments in the scrutiny json that defines what that’s for. Do I need to keep the empty quotes?
Yes, keep the empty quotes.
It seems awkward at first, but it’s actually normal as it relates to how we parse the json file. If I remember correctly, we parse that as a python Dict, which means it expects a key:value pair. The thing is that we need to account for options that take a key:value pair (like the --net=host one) and those that don’t like --privileged. That’s pretty much the first of it.
I do wonder why HA needs the additional privileges indeed. The --device flag exists exactly for the purpose of giving privileges to that device only and not everything. I’m rusty on that one so I’m probably missing a key nuance here (it may be for the same reason as for the scrutiny rock-on, actually, so I’m very likely to be missing a key nuance). Like you said, if we can pinpoint to a specific set of cap-add needed, that would be great. For testing at least, though, using --privileged should tell us if we’re on the right track at least.
2 Likes
Here I found a reference (not fact-checked further, though) that pluggable/ephemeral devices are not supported using the --device option (along with privileged). The poster here recommends modeling it as a volume instead, though it will give all USB device access …
3 Likes
@Hooverdan Thanks for the reference, I hadn’t found that one in my searches. I’m not sure if this is an issue I need to address right now. I only have a single USB device connected to the system, and only one container that is looking for a USB device. That being the case, I’m thinking removing the device section I added for a Zigbee stick and adding the --privilege opt might work in my very limited case. If that works it clarifies that it’s a lack of privileges that’s preventing HA from talking to the device, and then I can find a more elegant and flexible solution next. Does that logic check, or did I miss something in the references?
Changing the angle of attack, would it be easier, or better to try and fix this from the permissions end? Here’s the current permissions.
[root@jonesville /]# stat /dev/ttyACM0
File: ‘/dev/ttyACM0’
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 6h/6d Inode: 14198088 Links: 1 Device type: a6,0
Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 18/ dialout)
Access: 2024-11-23 16:18:10.415240281 -0800
Modify: 2024-11-23 16:18:10.415240281 -0800
Change: 2024-11-23 16:18:10.415240281 -0800
I’m not sure if adding the HA user to the dialout group would fix it because I’m assuming the container privileges are different than the user privileges. Does that sound right?
If that assumption is true than chmod 666 should add rw to users, but again not sure if that applies to the container. I think the container runs with the privileges of the user so I think this should work. My other thought is to put the HA user in the sys or root group.
Any thoughts try --privileged with 1 device first or go the permission route first?
I would try with the --device and privileged route first… If it works, then you can try narrowing down things progressively and see where it starts falling over. If it doesn’t work, we can explore further
3 Likes
I agree, I just tried a sudo -u with the HA user I created and was able to list all the tty devices and the container wasn’t even able to list them.
@Flox making progress. Just updated the json with priv reinstalled HA RockOn and was able to list the tty devices
root@jonesville:/# ls -l /dev/ttyA*
crw-rw---- 1 root audio 166, 0 Nov 26 13:02 /dev/ttyACM0
Now to see if I can get HA to talk to it.
2 Likes