I’ve bought a AM2302 temperature sensor so I can literally see how hot this summer is 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?
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
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.
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.
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
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
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
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.
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.
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.
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
Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
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.
but it looks like it doesn’t play nice on OSMC.
. The sensor will be polled every 5 minutes and I will report back tomorrow.