I am using the rpi-rf python package to sniff and issue RF commands using simple RF TX/RX boards connected to GPIO pins on my Pi3.
Everything works fine as long as I issue the commands with sudo, e.g. sudo rpi-rf_send 12345.
When I try to get RF sending working using Home Assistant (or using the command above without sudo), I get an error:
No access to /dev/mem. Try running as root!
Searching in the Home Assistant forums indicates that adding the user homeassistant to the group gpio fixes the issue. This group doesn’t exist on OSMC however.
What is the appropriate method of giving a user on OSMC (in my case, user homeassistant) appropriate permissions to interface with the GPIO pins?
I think @sam_nazarko 's comment here might be relevant, but I’m not sure how…
Hi According the link you’ve provided, if you are running the latest version of osmc; root is not required for devmem.
Do you know whet version of OSMC you are running? Failing that try updating via MyOSMC.
Thanks Tom.
I’m running the latest OSMC update.
I have a Pi1 running Raspbian and a Pi 3 running OSMC and there are quite a few differences between the two as far as gpio goes - and possibly some more I’ve not found.
Although we don’t have raspi-config to help us, we can try a few obvious things and see if that’s enough to get you working.
sudo groupadd -g 997 gpio
sudo adduser homeassistant gpio
sudo chown root:gpio /dev/gpiomem
sudo chmod g+rw /dev/gpiomem
Those last two commands will not survive a reboot, so should also be added (minus the sudo part) to /etc/rc.local before the exit 0 line.
Raspbian also has a file /etc/udev/rules.d/99-com.rules that (amongst other things) contains the lines:
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\
You’ll probably need this, as well (create using sudo). The number might need changing, but for now we’ll see if it works as it is.
No joy unfortunately. Executing the first block of commands didn’t help. I added the file you noted, with content you noted, and rebooted. Still getting the same error:
File "/usr/local/lib/python3.4/dist-packages/rpi_rf/rpi_rf.py", line 77, in enable_tx
GPIO.setup(self.gpio, GPIO.OUT)
RuntimeError: No access to /dev/mem. Try running as root!
Worth a try. On further examination, Raspbian and OSMC seem have even more differences than I’d originally found.
I think that Sam’s inscrutable pronouncement regarding strict devmem might not be of help here since, AFAIK, you still need to be root to access /dev/mem.
The udev rules will need a bit of work to fit in with the OSMC environment. Perhaps @sam_nazarko has another (hopefully easier/better) approach.
Can OSMC user access everything fine?
No, osmc user gets the same error when trying to manually execute the rf send from command line - see OP for example.
Should I revert these changes?
Yes, revert them.
On reflection, the way you originally framed the question, I had the impression that you don’t want to use sudo for some reason. And in post #10 you also state:
but forgetting to memtion that it does work if you use sudo, which is a little confusing/misleading.
So, unless you have an objection to using sudo, that’s the answer. From user osmc run:
sudo adduser homeassistant sudo
and prefix your commands with sudo.
Sorry if it wasn’t clear to you.
The GPIO commands work from the command line as long as they are prefixed by sudo.
I need to be able to run the commands without using sudo so that Home Assistant (home automation software) can utilise the GPIO pins while it is running as a service on my Pi.
I’ve reverted the 99-com.rules file change, I’m going to leave the others in because I’m afraid I’ll break things further if I try to revert them and I don’t believe they are causing any harm.
Edit: I don’t think I actually need the user homeassistant to have access to GPIO, as I am running Home Assistant as user osmc. So, I’d be happy if user osmc could get access without needing sudo.
Thr gpio group is harmless.
It doesn’t look to be easy without sudo. Please explain in concrete terms why sudo cannot be used. And this is the first time you mentioned running a service, I assume using systemd.
I’m not certain in concrete terms that sudo cannot be used.
On other distributions it appears that the solution to my issue is quite straightforward - add the desired user to the gpio group. On OSMC it may not be this easy.
I start Home Assistant using systemd, as user osmc. The call that generates the permissions error is from somewhere deep within the running of Home Assistant.
Perhaps I need to run the Home Assistant service using sudo in order to have this work on OSMC? I’m not sure how I might go about that, or what other consequences it might have, but I’m happy to give it a go if it’s an option.
The most trouble-free route on OSMC seems to be either to use sudo or run as root.
I’ll try to install Home Assistant and see if I can come up with a sensible proposal.
Thanks, I really appreciate your help with this - it’s clearly not as straightforward as I had hoped/assumed!
I’m unable to do much today because of other commitments but I hope to take a better look tomorrow.
I’ve had a stab at installing Home Assistant using the script method but it’s heavy going.
Could you provide the URL from grab-logs -A to give me a better idea of what’s on your system?
OK, something strange has happened.
For some reason, I am now able to issue the commands from the command line without sudo, and Home Assistant is working as expected.
I didn’t do anything else, other than ignore this issue for a few days, and now it’s working. I reverted the 99-com.rules file change but left in the other changes you suggested - perhaps they worked after all?
I can only assume that for some reason it took longer than expected for the original changes you suggested to work? I have no idea how, I did several reboots in the process.
I’m happy to upload logs if you think there’s any merit in doing so.
If it’s working, let’s not provoke it. I’m happy to close the case if you are. If it goes wrong again, we’ll still be here.
1 Like
Thanks again for your help. One of your suggestions must have worked. Happy to close for now.