Troubles with reading my GPIO device

I’ve bought a AM2302 temperature sensor so I can literally see how hot this summer is :sweat: but it looks like it doesn’t play nice on OSMC.

It uses some software compiled from Adafruit and python but I wasn’t able to get it working on my current installation of OSMC.
I grabbed another SD card and switched to Raspbian to check if the sensor itself was working and it was okay.
After this I did a reinstall of OSMC and am still having trouble getting readings. Feedback of the software is that there is a timeout. The success rate is about 30%. There is a sleep function in the script which is set to 2 seconds. I’ve increased that to 4 and later even to 20 seconds. This doesn’t seem to change much if anything.
On OSMC the scripts tels me it needs to run with sudo because there is no access to the GPIO. On Raspbian this is solved by adding the user to the group gpio. As far as I know there is no such group on OSMC. I changed ownership of /dev/gpio* to the osmc user and group. The script doesn’t complain about permissions anymore but I’m not sure if this is a proper solution. Advise appreciated on this part. (These rights are reset after a reboot but this could be a nice line in rc.local)

Do you have any tips what I could do to make it work better?

Thanks

We should have /dev/gpiomem which does not require root permissions

Sam

See OSMC run add-on as root - #6 by dillthedog

On my Pi. default permissions for /dev/gpiomem are:

crw------- 1 root root 244, 0 Jul 22 19:43 /dev/gpiomem

If you add the udev rule, it will become:

crw-r----- 1 root osmc 244, 0 Jul 12 12:15 /dev/gpiomem

Thnx for that link, I’ve come across that one but went for the rc.local variant. I’ve ended up with 0660 to run with without permission warnings.

crw-rw---- 1 root osmc 244, 0 Jul 22 21:50 /dev/gpiomem

osmc@Lightberry:~$ /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Failed to get reading. Try again!
osmc@Lightberry:~$ /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.3* Humidity=42.0%
osmc@Lightberry:~$ /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.3* Humidity=42.0%
osmc@Lightberry:~$ /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.2* Humidity=41.7%
osmc@Lightberry:~$ /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Failed to get reading. Try again!

It’s not 100% yet. Sometimes the readout is very fast and sometimes I have to wait a long time. I mixed it a few times with sudo to make sure.

osmc@Lightberry:~$ time /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.1* Humidity=41.2%

real 0m31.120s user 0m0.536s sys 0m0.061s
osmc@Lightberry:~$ time /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Failed to get reading. Try again!
real 0m38.187s user 0m0.631s sys 0m0.021s
osmc@Lightberry:~$ time /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Failed to get reading. Try again!
real 0m38.188s user 0m0.615s sys 0m0.040s
osmc@Lightberry:~$ time sudo /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Failed to get reading. Try again!
real 0m38.254s user 0m0.671s sys 0m0.052s
osmc@Lightberry:~$ time sudo /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.1* Humidity=41.0%
real 0m16.026s user 0m0.472s sys 0m0.038s
osmc@Lightberry:~$ time sudo /AM2302/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.1* Humidity=41.3%
real 0m8.431s user 0m0.372s sys 0m0.052s

We need to fix udev rules for that then.
Thanks for confirming.

Can you add:

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:osmc /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:osmc /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:osmc /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"

to a new file called /etc/udev/rules.d/996-fix-gpio-mem (chmod +x)

and let me know if it works

Sam

osmc@Lightberry:~$ ls -la /sys/class/gpio
total 0
drwxr-xr-x 2 root root 0 Jul 23 00:11 .
drwxr-xr-x 50 root root 0 Jul 23 00:11 …
–w------- 1 root root 4096 Jul 23 00:11 export
lrwxrwxrwx 1 root root 0 Jul 23 00:11 gpiochip0 → …/…/devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 Jul 23 00:11 gpiochip100 → …/…/devices/gpiochip2/gpio/gpiochip100
lrwxrwxrwx 1 root root 0 Jul 23 00:11 gpiochip128 → …/…/devices/gpiochip1/gpio/gpiochip128
–w------- 1 root root 4096 Jul 23 00:11 unexport
osmc@Lightberry:~$
osmc@Lightberry:~$ ls -la /sys/devices/virtual/gpio
ls: cannot access ‘/sys/devices/virtual/gpio’: No such file or directory
osmc@Lightberry:~$
osmc@Lightberry:~$ ls -la /sys/devices/platform/soc/*.gpio/gpio
total 0
drwxr-xr-x 3 root root 0 Jul 23 00:14 .
drwxr-xr-x 5 root root 0 Jul 23 00:14 …
drwxr-xr-x 3 root root 0 Jul 23 00:14 gpiochip0

Not sure if /sys/devices/virtual/gpio is expected not to exist. Reading github issue talk confused me more.

The first 4 readings look okay now. I need to hibernate now :wink:. The sensor will be polled every 5 minutes and I will report back tomorrow.

Just to confirm: are you saying that you tried the udev rule as suggested above?

Sam

Yes, that udev rules was applied.
Checked the stats this morning, 61% of the calls succeeded. I have a monitoring tool that executes the command every 5 minutes. The Pi had a hard time between 02:40 and 05:00, after that it was like pretty successful but still not perfect.

If I run:

osmc@osmc:~$ udevadm info -a -n /dev/gpiomem

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/bcm2835-gpiomem/gpiomem':
    KERNEL=="gpiomem"
    SUBSYSTEM=="bcm2835-gpiomem"
    DRIVER==""

so the KERNEL is gpiomem and the SUBSYSTEM is bcm2835-gpiomem. That’s what I used in the udev rule I linked to above.

Edit. Looking at your udev script, you refer to /sys/devices/virtual/gpio when it should be /sys/devices/virtual/bcm2835-gpiomem. That said, on Raspbian it’s still owned by root:root.

drwxr-xr-x  3 root root 0 Jul  3 09:17 bcm2835-gpiomem

Might just remove that.

I was thinking of a generic rule we could use for all platforms, but it can definitely be made Pi specific.

Well… Things got strange. I was reading a very good article about temperature sensors and the successor of my 2302 is able to communicate over I2C interface. Why not just try it. I enabled i2c_arm=on in the boot config and the last hour I had just 3 failures and more than 50 good ones.

So I switched back to Raspbian to verify things. I2c was not enabled in Raspbian. Using the pi config tool I even disabled it to be sure. I created a user osmc and this is the result:

osmc@Lightberry:~ $ groups
osmc gpio
osmc@Lightberry:~ $ time Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.7* Humidity=53.6%
real 0m1.058s user 0m0.272s sys 0m0.065s
osmc@Lightberry:~ $ time Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.7* Humidity=53.8%
real 0m0.778s user 0m0.238s sys 0m0.040s
osmc@Lightberry:~ $ time Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.7* Humidity=53.8%
real 0m0.776s user 0m0.257s sys 0m0.020s
osmc@Lightberry:~ $ time Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temp=25.7* Humidity=53.8%
real 0m0.782s user 0m0.252s sys 0m0.030s

osmc@Lightberry:~ $ cat /boot/config.txt | grep i2c
dtparam=i2c_arm=off

The only difference now is that it’s blazing fast on Raspbian where on OSMC it range is between 3 and 30 seconds (with the I2c on and off)

Default permissions on Raspbian:

Summary

osmc@Lightberry:~ $ ls -la /dev/gpio*
crw-rw---- 1 root gpio 254, 0 Jul 23 13:49 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Jul 23 13:49 /dev/gpiochip1
crw-rw---- 1 root gpio 254, 2 Jul 23 13:49 /dev/gpiochip2
crw-rw---- 1 root gpio 248, 0 Jul 23 13:49 /dev/gpiomem
osmc@Lightberry:~ $ ls -la /sys/class/gpio/*
-rwxrwx— 1 root gpio 4096 Jul 23 13:49 /sys/class/gpio/export
lrwxrwxrwx 1 root gpio 0 Jul 23 13:49 /sys/class/gpio/gpiochip0 -> …/…/devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio 0 Jul 23 13:49 /sys/class/gpio/gpiochip100 -> …/…/devices/gpiochip2/gpio/gpiochip100
lrwxrwxrwx 1 root gpio 0 Jul 23 13:49 /sys/class/gpio/gpiochip128 -> …/…/devices/gpiochip1/gpio/gpiochip128
-rwxrwx— 1 root gpio 4096 Jul 23 13:49 /sys/class/gpio/unexport
osmc@Lightberry:~ $ ls -la /sys/devices/gpiochip*
/sys/devices/gpiochip1:
total 0
drwxrwx— 4 root gpio 0 Jul 23 13:49 .
drwxr-xr-x 11 root root 0 Nov 3 2016 …
-rwxrwx— 1 root gpio 4096 Jul 23 13:49 dev
drwxrwx— 3 root gpio 0 Jul 23 13:49 gpio
lrwxrwxrwx 1 root gpio 0 Jul 23 13:49 of_node -> …/…/firmware/devicetree/base/soc/expgpio
drwxrwx— 2 root gpio 0 Jul 23 13:49 power
lrwxrwxrwx 1 root gpio 0 Jul 23 13:49 subsystem -> …/…/bus/gpio
-rwxrwx— 1 root gpio 4096 Jul 23 13:49 uevent

/sys/devices/gpiochip2:
total 0
drwxrwx— 4 root gpio 0 Jul 23 13:49 .
drwxr-xr-x 11 root root 0 Jul 23 14:12 …
-rwxrwx— 1 root gpio 4096 Jul 23 13:49 dev
drwxrwx— 3 root gpio 0 Jul 23 13:49 gpio
lrwxrwxrwx 1 root gpio 0 Jul 23 13:49 of_node -> …/…/firmware/devicetree/base/soc/virtgpio
drwxrwx— 2 root gpio 0 Jul 23 13:49 power
lrwxrwxrwx 1 root gpio 0 Jul 23 13:49 subsystem -> …/…/bus/gpio
-rwxrwx— 1 root gpio 4096 Jul 23 13:49 uevent
osmc@Lightberry:~ $ ls -la /sys/devices/virtual/bcm2835-gpiomem/*
total 0
drwxr-xr-x 3 root root 0 Jul 23 14:15 .
drwxr-xr-x 3 root root 0 Jul 23 14:15 …
-r–r--r-- 1 root root 4096 Jul 23 14:16 dev
drwxr-xr-x 2 root root 0 Jul 23 14:16 power
lrwxrwxrwx 1 root root 0 Jul 23 13:49 subsystem -> …/…/…/…/class/bcm2835-gpiomem

I recommend checking the package versions are the same.

Sam

Sorry for bringing up that old topic - but I encountered the same issue right now within the 2021-12 release from OSMC on my raspi 3.

Your proposed udev rule /etc/udev/rules.d/996-fix-gpiomem.rules did almost everything. But on my raspi there is no /sys/devices/virtual/gpio, instead ther exists /sys/devices/virtual/bcm2835-gpiomem. Thus I’ve adapted your udev to become

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:osmc /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:osmc /sys/devices/virtual/*gpio* && chmod -R 770 /sys/devices/virtual/*gpio*; chown -R root:osmc /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"

i.e. I simply inserted four stars to match my usecase.

Maybe that’s a generic solution?

Regards, Michael
PS: Didn’t test the new udev rule at all, but I executed the corresponding chown/chmod command manually.

Can you confirm which version of OSMC you’re on?

Thanks

Yes - as I wrote in my previous post it’s the most current OSMC version from december 2021. Or from uname -a

Linux .... 5.10.78-2-osmc #1 SMP PREEMPT Wed Nov 17 03:44:59 UTC 2021 armv7l GNU/Linux

Regards, Michael

Hi guys,
To solve my issue as described in the topic start I ended up with one line that i apply in the udev rules.
its:
/etc/udev/rules.d/01-gpio-permissions.rules

KERNEL==“gpiomem”, SUBSYSTEM==“bcm2835-gpiomem”, MODE=“0660”, GROUP=“osmc”

with this line added I can reach my temperature sensor without sudo permissions. I don’t change other rules in udev and this one seems redundant with the 996 rule but somehow it works.

Maybe I’ve discovered the solution:

There exists the standard debian package rpi.gpio-common to enable GPIO access for members of group dialout. On my installation the user osmc is a member of dialout (probabely by default). Thus the following commands did the trick:

apt update
apt install rpi.gpio-common

It mainly installs the new udev rule /lib/udev/rules.d/60-rpi.gpio-common.rules. To avoid problems I also removed /etc/udev/rules.d/996-fix-gpiomem.rules from OSMC installation.

Regards, Michael

Which device are you using? If it’s in upstream Debian I’ll check out what it brings in and adjust accordingly.

It’s a raspberry pi 3 running OSMC from december 2021 - your christmas release.

And I’m using 3 GPIO pins: one to receive IR signals using default OSMC setup for remote control of kodi. And two pins to detect the state of my beamer (utilizing 12V trigger signal) and my TV set (using its USB port). These two GPIOs are connected by optocouplers and monitored by the smarthome environment fhem.

Thus I can even confirm that the udev rule from rpi.gpio-common is compatible with OSMC’s default IR handling also using GPIO.

Regards, Michael

Hi

Hopefully the issue is now addressed with the following commit:

I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:

  1. Login via the command line
  2. Run the following command to add the staging repository:
    echo 'deb http://apt.osmc.tv buster-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
  3. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  4. Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.

I’d also recommend you deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.

Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.