Problem beim Lesen eines GPIOs

[dsm]

Ich möchte am Raspberry PI einen Bewegungssensor (PIR) betreiben. Hierzu möchte ich einen GPIO nutzen. Ich habe WiringPI installiert und kann über die Konsole den Status des Eingangs abfragen. Die fhem.cfg habe ich wie folgt ergänzt:

define PIR RPI_GPIO 4
attr PIR direction input

Leider funktioniert der GPIO nicht und das Log-File zeigt folgende Meldung:

PIR: failed to export pin gpio4

[NewRasPi]

Hallo dsm
so funktioniert es bei mir mit den PIR Bewegungsmeldern:

Code Auswählen Erweitern

define <name> RPI_GPIO 4
attr <name> direction input
attr <name> interrupt both
attr <name> toggletostate yes
attr <name> room <Raumname>

Falls es dann noch nicht funktioniert habe ich hier im Forum mal diesen Befehl gefunden.
"Rechte für GPIO schalten:" (frag mich aber nicht was das genau macht - mit meinem copy & paste hat es geklappt)

Code Auswählen Erweitern

sudo chown -R fhem:root /sys/class/gpio/*

Viel Spass beim testen.

[Navigator]

Wenn oben genannte Antwort nicht funktioniert kannst du es auch so machen.

Wenn Ihnen das Gefrickel mit den Gruppen- und Zugriffrechten zu aufwendig erscheint, gibt es noch einen zweiten Weg über die systemweite Konfiguration im Verzeichnis /etc/udev/. Für den GPIO-Zugriff legen Sie im darunter befindlichen Regel-Verzeichnis rules.d eine neue Regeldatei namens

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

an. Wichtig ist eigentlich nur die Endung ".rules". Die Zahl am Anfang legt die Reihenfolge fest, in der die Regeldateien abgearbeitet werden. 80 ist da ein guter Kompromiss. Für das Beispiel verwende ich die oben schon erwähnte Gruppe "gpio", es wäre im Prinzip auch jede andere Gruppe möglich. In den Regeln wird nun festgelegt, dass für die beiden dem GPIO zugeordneten Verzeichnisse die Gruppe auf "gpio" gesetzt wird und die Zugriffsrechte auf Lesen und Schreiben. Zusätzlich wird auch noch das Sticky-Bit für die Gruppe gesetzt, was bedeutet, dass neue Dateien oder Unterverzeichnisse auch automatisch die Gruppe "gpio" erhalten:

# /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/class/gpio"
SUBSYSTEM=="gpio", RUN+="/bin/chown -R root.gpio /sys/devices/virtual/gpio"
# Sticky-Bit setzen
SUBSYSTEM=="gpio", RUN+="/bin/chmod g+s /sys/class/gpio"
SUBSYSTEM=="gpio", RUN+="/bin/chmod g+s /sys/devices/virtual/gpio"
# Zugriffsrechte setzen
SUBSYSTEM=="gpio", RUN+="/bin/chmod -R ug+rw /sys/class/gpio"
SUBSYSTEM=="gpio", RUN+="/bin/chmod -R ug+rw /sys/devices/virtual/gpio"

Jetzt müssen Sie nur noch den udev-Daemon von den Änderungen wissen lassen (beim nächsten Reboot passiert das dann automatisch):

sudo service udev restart
sudo udevadm trigger --subsystem-match=gpio

[klausw]

@Dittel: wo ist denn das Zitat her?
vielleicht kann ich das in die Commandref aufnehmen

[Navigator]

@klausw

...den Tipp hab ich von der "Mafia"... Netzmafia.de

http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_GPIO_Shell.html


...nur so hat es bei mir funktionieren wollen. 

[NewRasPi]

Hallo klausw

@Dittel: wo ist denn das Zitat her?
vielleicht kann ich das in die Commandref aufnehmen

Heißt das, dass wäre einer der "richtigsten Wege" (wenn auch nicht ganz leicht) um die immer wieder auftretenden Probleme bei den GPIO mal für die Zukunft zu regeln? (wenigstens bis wieder ein großes Update eingespielt wird, das schon funktionierendes wieder verhindert).

Für Anfänger ist es schwierig die Taktgeschwindigkeit der Veränderungen mit zu halten. Kaum glaubt man den Sinn eines Modul`s halbwegs einsetzen (ich schreibe bewusst nicht, zu verstehen) zu können wird schon wieder was verändert/ verbessert (was ja auch super ist!). 
Bitte denkt also bei den erweitern/ verbessern der Programme auch an die, die nicht Software Programmierer sind.
Vielen Dank

[klausw]

Hallo klausw
Heißt das, dass wäre einer der "richtigsten Wege" (wenn auch nicht ganz leicht) um die immer wieder auftretenden Probleme bei den GPIO mal für die Zukunft zu regeln? (wenigstens bis wieder ein großes Update eingespielt wird, das schon funktionierendes wieder verhindert).

Für Anfänger ist es schwierig die Taktgeschwindigkeit der Veränderungen mit zu halten. Kaum glaubt man den Sinn eines Modul`s halbwegs einsetzen (ich schreibe bewusst nicht, zu verstehen) zu können wird schon wieder was verändert/ verbessert (was ja auch super ist!). 
Bitte denkt also bei den erweitern/ verbessern der Programme auch an die, die nicht Software Programmierer sind.

Der beste Weg ist, kein Systemupgrade zu machen, wenn alles läuft 

Beim Raspberry Pi mit Raspbian funktioniert seit 3 Jahren:
aktuelles Raspbian auf Karte, FHEM installieren, User fhem in Gruppe GPIO -> Fertig

FHEM updates können natürlich problemlos gemacht werden (auch bei "apt-get update" habe ich noch keine Probleme gehabt).
Aber Kernelupgrades sind halt bisschen komplexer und gerade unbedarfte Personen sollten da die Finger von lassen.
Falls ich in den FHEM Modulen selbst ein Fehler einschleicht, ist das ein geringeres Problem, da er gewöhnlich Zeitnah behoben wird.

udev ist neben dem anlegen der GPIOs in der rc.local eine Alternative die eher für andere Linux Systeme wie BBB oder Cubie gedacht war.

[klausw]

...nur so hat es bei mir funktionieren wollen. 

Danke

Naja, bei Cubietruck habe ich keine Ahnung.
Die gruppe GPIO gibt es da nicht, oder?
Sind die GPIOs in der Gruppe Root?