Modul für RPi GPIO Zugriff mit Interrupt Funktion für Input

Wernieman · 28 August 2015, 11:45:04

Eine passende UDEV-Regel, welche die Gruppierung passend setzt.

Kann nur momentan nicht zu hause nachsehen, wie die Regel lauten müsste,

Zenz · 28 August 2015, 13:43:07

Hallo Wernieman!

Wäre toll, wenn du mir mit eine passenden UDEV-Regel helfen könntest,
habe leider keine Ahnung davon, ist komplettes "Neuland".

Habe zwar versucht mich mit Google schnell ein wenig einzulesen, aber ist leider ziemlich verwirrend.

Vielen Dank
Zenz

Wernieman · 28 August 2015, 14:16:29

Mit "Glück" morgen .. habe vorhin aus der Ferne das System abgeschossen (Fehler saß vor dem Bildschirm

)

Zenz · 30 August 2015, 12:14:14

Hallo Wernieman,

wie geht's deinem System?

Wenn gut, darf ich dich nochmals bitten, ob du mir deine passenden UDEV-Regel
zur Verfügung stellen könntest.
Ich komme mit diesen "verzwickten" Berechtigungen einfach nicht zurecht.

mfG
Zenz

danieljo · 30 August 2015, 14:32:46

Ich muss hier leider auch nochmal fragen wegen dem GPIO am RPi2 mit Rasbpian 4.1.6-v7 und aktuellem FHEM frisch installiert.

Soweit funktioniert alles aber das attribut active-low kann nicht gesetzt werden. Erst wenn ich die Berechtigungen vom Ordner

Code Auswählen

/sys/devices/platform/soc/3f200000.gpio/gpio/ auf 0777 ändere schreibt FHEM das attr active low auch in die Datei. Jedoch nach jedem reboot sind die Berechtigungen wieder weg. Und im Log steht das FHEM keine Schreibrechte auf die Datei "active_low" hat.

Benutzer FHEM ist in Gruppe Root. Könnte mir da bitte jemand unter die arme greifen. Habe den Thread hier schon durchgelesen und einiges ausprobiert aber die Berechtigungen setzen sich immer wieder zurück. Ansonsten funktioniert alles super.

Wernieman · 31 August 2015, 09:25:45

1. Wenn der User FHEM in der gruppe root ist, dann ist er root!

Implementiere am besten ein sichere Rechtevergabe, So machst Du Dein System sehr offen ....

2. Setze Dir eine Udev-Regel:
z.B. für usb:

Code Auswählen

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664", GROUP="usb"
Dieses must Du "nur noch" für gpio adaptieren ...

z.B. siehe: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=9667

Zenz · 31 August 2015, 18:52:53

@Wernieman
Danke für den Tipp mit den Udev-Regel.

Nach langer Recherche habe ich folgende Lösung gefunden (weiss nicht ob ich den Link hier posten darf oder nicht),
die mir nach jedem Neustart des Raspberry bzw. Fhem erlaubt, diverse GPIO Befehle ohne Berechtigungsprobleme
auszuführen.
Auf meinem Raspberry läuft Linux 4.1.6-v7+ auf armv7l

Code Auswählen

sudo usermod -a -G gpio fhem

eine Datei erzeugen

Code Auswählen

sudo nano /etc/udev/rules.d/80-gpio-noroot.rules

folgenden Inhalt einfügen

Code Auswählen

# /etc/udev/rules.d/80-gpio-noroot.rules
# Zugriff auf GPIO ohne root-Rechte ermoeglichen
#
# Gruppe aendern
SUBSYSTEM=="gpio", RUN+="/bin/chown -R root.gpio /sys/devices/platform/soc/3f200000.gpio/gpio"
# Sticky-Bit setzen
SUBSYSTEM=="gpio", RUN+="/bin/chmod g+s /sys/devices/platform/soc/3f200000.gpio/gpio"
# Zugriffsrechte setzen
SUBSYSTEM=="gpio", RUN+="/bin/chmod -R ug+rw /sys/devices/platform/soc/3f200000.gpio/gpio/"

Code Auswählen

sudo service udev restart

Code Auswählen

sudo udevadm trigger --subsystem-match=gpio

Fragen bezüglich dieser Lösung kann ich leider nicht beantworten, da ich keine Ahnung von Linux habe
und diese Lösung nicht von mir stammt, sondern dieser Code nur auf die neue Stucktur von mir geändert worden ist.

Ich hoffe diese Lösung funktioniert auch bei anderen und bedanke mich für die Hilfe, die ich in diesem Forum
erfahren konnte.

mfG
Zenz

Wernieman · 31 August 2015, 21:13:36

Was Du pobieren könntest, kan selber malngels RasPi nicht testen:

Anstatt Deiner Zeile in die UDEV-Datei:

Code Auswählen

SUBSYSTEM=="gpio", MODE="0664", GROUP="gpio"

Allerdings gibt Du damit das komplette GPIO an die Gruppe gpio frei (teoretisch, praktisch s.o.)

Was Du bei Deiner Lösung machst, ist das Setzen der Zugriffsregel hart per externen Programm. besser ist eigentlich, das interne zu verwenden.

Andererseits ... "newer change a running system"

Wenn Du experimentierfreudig bist ... könntest Du eventuell testen?

lullebammel · 02 September 2015, 17:45:56

Hi ich hab mir auch zwei Abende um die Ohren geschlagen.

Macht einfach ein Downgrade auf 3.12.35 vom 19.12.2014 und gut ist.

sudo rpi-update ba43047bec24d5f0a4150f09a37884240f8926d2

SmartFan · 04 September 2015, 17:31:45

Hallo Allerseits,

bei mir geht nun nach der Sommerpause auch nix mehr und ich haben den ganzen Thread durchgearbeitet und die Vorschläge alle gemacht.

Bin nun auch wie Du schreibst auf alte Version zurück gegangen. Leider geht immer noch nix.

Gruß Michael

Ellert · 07 September 2015, 19:44:25

Leider habe auch ich das hier beschriebene Problem der nicht funktionierenden GPIOs nach dem Upgrade des RasPi B+ auf den Kernel 4.16. Ich bin jetzt zurück auf mein vorher gezogenes Backup nach dem folgendes nicht funktioniert hat:

Zitat von: Wernieman am 31 August 2015, 21:13:36
Was Du pobieren könntest, kan selber malngels RasPi nicht testen:

Anstatt Deiner Zeile in die UDEV-Datei:
Code Auswählen Erweitern
SUBSYSTEM=="gpio", MODE="0664", GROUP="gpio"

Allerdings gibt Du damit das komplette GPIO an die Gruppe gpio frei (teoretisch, praktisch s.o.)

Was Du bei Deiner Lösung machst, ist das Setzen der Zugriffsregel hart per externen Programm. besser ist eigentlich, das interne zu verwenden.

Andererseits ... "newer change a running system"

Wenn Du experimentierfreudig bist ... könntest Du eventuell testen?

Folgendes habe ich beobachtet:
Die Gruppe gpio ist vorhanden, pi und fhem sind Mitglieder der Gruppe gpio.
Die in FHEM definierten GPIOs (bei mir 24 und 25) werden in /sys/class/gpio auch richtig angelegt, nach dem Start von FHEM.
Nur das Device in FHEM-wird nicht angelegt. Und im Log steht, dass auf das Verzeichnis /sys/class... und das Verzeichnis /usr/local/gpio... nicht zugegriffen werden kann, bzw., dass es nicht existiert. Das Verzeichniss /usr/local/gpio... existiert bei mir nicht.

Eine Lösung kenne ich nicht.

klausw · 07 September 2015, 19:49:45

Seltsam, wenn FHEM die gpios anlegt muss es doch zugriff haben.
Was bringt:
ls -l /sys/class/gpio

SmartFan · 08 September 2015, 07:17:34

so siehts aus.

Code Auswählen

pi@raspberrypi ~ $ ls -l /sys/class/gpio
total 0
-rwxrwx--- 1 root gpio 4096 Sep  6 19:58 export
lrwxrwxrwx 1 root gpio    0 Sep  6 19:58 gpio21 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio21
lrwxrwxrwx 1 root gpio    0 Jan  1  1970 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan  1  1970 unexport
pi@raspberrypi ~ $

Gruss Michael

Ellert · 08 September 2015, 08:00:32

Ich habe gerade auf meinem Testsystem einen GPIO definiert mit:

Code Auswählen

define gpio24 RPI_GPIO 24

Es erscheint die Fehlermeldung:

Code Auswählen

 gpio24: failed to export pin gpio24

Im Log steht:

Code Auswählen

2015.09.08 07:49:49 1: gpio24: can't export gpio24, no write access to /sys/class/gpio/export and file /usr/local/bin/gpio doesnt exist
2015.09.08 07:49:49 1: gpio24: failed to export pin gpio24
2015.09.08 07:49:49 1: define gpio24 RPI_GPIO 24: gpio24: failed to export pin gpio24

Die Datei /usr/local/bin/gpio existiert nicht. Weder auf dem funktionierenden Sytem, noch auf dem nicht funktionierenden.
Der GPIO wird allerdings angelegt, wie SmartFan schon geschrieben hat:

Code Auswählen

pi@raspberrypi ~ $ ls -l /sys/class/gpio
total 0
-rwxrwx--- 1 root gpio 4096 Sep  8 07:49 export
lrwxrwxrwx 1 root gpio    0 Sep  8 07:49 gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24
lrwxrwxrwx 1 root gpio    0 Jan  1  1970 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan  1  1970 unexport

Wernieman · 08 September 2015, 08:17:55

Und was ist mit dem 2. teil der Fehlermeldung?

Existiert "/usr/local/bin/gpio"?