Hallo zusammen,
ich bin zur Zeit dabei, meinen RPi durch einen Banana Pi zu ersetzen.
FHEM läuft bereits ohne Probleme :) (FHT,IT,Wifilight,SOMFY,...) bis auf eine Ausnahme, RPI_GPIO :(.
Ich nutze GPIO´s direkt für einige LED´s und Taster um Aktionen zu signalisieren bzw zu starten. Auf dem RPi läuft das mit wiringPi super.
Auf BananaPi läuft Raspian 3.1 und wiringPi V2.14 (rev. 3 board). WiringPi läuft und zeigt mit gpio readall auf der Konsole auch alle GPIO an.
Wenn ich jetzt mit
define LED1 RPI_GPIO 17 versuche einen Pin zu definieren, erhalte ich
LED1: failed to export pin gpio17 (ebenso bei allen anderen Pins).
Im Log steht:
2014.11.16 22:30:53 4: LED1: write access to file /sys/class/gpio/export, use it to export GPIO
2014.11.16 22:30:58 1: LED1: failed to export pin gpio17
2014.11.16 22:30:58 1: define LED1 LED1 RPI_GPIO 17: LED1: failed to export pin gpio17
Hat jemand eine Idee, warum das unter BananaPi nicht funktioniert? Bei RPi läuft es so super.
Vielen Dank,
Viele Grüße,
santaclaus
Dazu fallen mir zwei Dinge ein:
1) Kannst Du auf der Konsole nicht nur Dir alle GPIOs anzeigen lassen sondern diese auch schalten?
2) Das könnte ein Rechte-Problem sein - wer darf GPIOs beeinflussen, unter welchem User läuft fhem, in welcher Gruppe?
zu 1): ja, auf der Konsole lassen sich die GPIO´s einzeln schalten (als Benutzer pi)
zu 2) GPIO´s sollten doch durch Mitglieder der Gruppe gpio geändert werden dürfen? FHEM läuft als User fhem (version $Id: fhem.pl 6913 2014-11-08 10:32:44Z rudolfkoenig $, os linux, user fhem, pid 9898)und ist in den Gruppen: gpio dialout audio tty.
Ein neu angelegter Benutzer,der nur zur Gruppe gpio gehört kann auf der Konsole auch GPIO´s schalten.
Zitat von: santaclaus am 16 November 2014, 22:41:14
Im Log steht:
2014.11.16 22:30:53 4: LED1: write access to file /sys/class/gpio/export, use it to export GPIO
2014.11.16 22:30:58 1: LED1: failed to export pin gpio17
2014.11.16 22:30:58 1: define LED1 LED1 RPI_GPIO 17: LED1: failed to export pin gpio17
In der ersten Zeile steht, das Schreibrechte vorhanden sind. Es sollte also kein Rechteproblem sein.
Funktioniert denn:
echo 17 > /sys/class/gpio/export ?
Oder besten gleich direkt über FHEM versuchen:
{`echo 17 > /sys/class/gpio/export`}
So, die Fehlersuche geht weiter:
mitecho 17 > /sys/class/gpio/export bekomme ich "Ressource / Gerät belegt". Da scheint es ein Problem zu geben... :(
Mit fuser /sys/class/gpio/export: 2533c
habe ich mir den Prozess gesucht, der die Datei blockiert. Dies ist 2533.
ps -axjf ergibt:
1 2392 2392 2392 ? -1 Ss 0 0:00 /usr/sbin/sshd
2392 2530 2530 2530 ? -1 Ss 0 0:00 \_ sshd: pi [priv]
2530 2532 2530 2530 ? -1 S 1000 0:00 \_ sshd: pi@pts/0
2532 2533 2533 2533 pts/0 2621 Ss 1000 0:00 \_ -bash
2533 2621 2621 2533 pts/0 2621 R+ 1000 0:00 \_ ps -axjf
Der gehört zu -bash (?) und ist mit kill auch nicht zu beenden... :P
Hat jemand eine Idee wie man noch rausbekommt, was die Datei blockiert?
super, dann bin ich schonmal raus :P
Ist GPIO 17 denn auch der Richtige? Nicht das du irgendeine Systemstatus LED nutzen willst.
Guter Einwand. Pin17 ist bei bananpi tatsächlich anders belegt. 8)
Nach Vergleich der Belegung erhalte ich zB nun nach echo 23 > /sys/class/gpio/export in der Konsole keine Ausgabe, nur wieder den Eingabeprompt.
In FHEM passiert mit {`echo 23 > /sys/class/gpio/export`}auch nichts, es wird nichtmal ein Fehler (bei verbose 5) geloggt. Hab auch alle anderen Pin´s durch...
Eins ist mir noch aufgefallen. Wenn ich gpio reset durchfüre und danach 2x echo 23 > /sys/class/gpio/export ausführe, ist beim ersten mal die Ausgabe leer, beim zweiten Mal wieder "Gerät/Ressource belegt"...
Zitat von: santaclaus am 17 November 2014, 18:22:23
Nach Vergleich der Belegung erhalte ich zB nun nach echo 23 > /sys/class/gpio/export in der Konsole keine Ausgabe, nur wieder den Eingabeprompt.
Das ist doch auch ok.
Wurde der GPIO denn angelegt?
Dann müsste unter
/sys/class/gpio/ ein Ordner namens gpio23 existieren.
Zitat von: santaclaus am 17 November 2014, 18:22:23
In FHEM passiert mit {`echo 23 > /sys/class/gpio/export`}auch nichts, es wird nichtmal ein Fehler (bei verbose 5) geloggt. Hab auch alle anderen Pin´s durch...
hier das Gleiche...es gibt keine Meldung...du kannst nur schauen, ob das Verzeichnis existiert
Zitat von: santaclaus am 17 November 2014, 18:22:23
Eins ist mir noch aufgefallen. Wenn ich gpio reset durchfüre und danach 2x echo 23 > /sys/class/gpio/export ausführe, ist beim ersten mal die Ausgabe leer, beim zweiten Mal wieder "Gerät/Ressource belegt"...
siehe oben
vermutlich funktioniert der GPIO23 schon, schließlich bekommst du keine Fehlermeldung
Ja, die GPIO´s werden angelegt und der Ordner ist unter 7sys/class/gpio sichtbar.
Bei FHEM das gleiche.
Nur der Befehl define LED1 RPI_GPIO 23 bringt nach wie vor den Fehler LED1: failed to export pin gpio23
Also einerseits funktionieren die GPIO´s, aber andererseits scheint FHEM noch ein Problem damit zu haben...
führe bitte
echo 23 > /sys/class/gpio/unexport
aus und überprüfe anschließend, ob das entsprechende GPIO Verzeichnis verschwunden ist.
Wenn es weg ist dann führe:
{`echo 23 > /sys/class/gpio/export`}
in FHEM aus.
Nun
ls -l /sys/class/gpio/gpio10/ ausführen und das Ergebnis hier posten.
Habe ich exakt so getan, hier das Ergebnis
pi@bananapi /sys/class/gpio $ ls -l /sys/class/gpio/gpio10/
ls: Zugriff auf /sys/class/gpio/gpio10/ nicht möglich: Datei oder Verzeichnis nicht gefunden
Ich vermute aber, du meinst in der letzten Zeile nicht 10 sondern 23? Dann erhalte ich:
pi@bananapi /sys/class/gpio $ ls -l /sys/class/gpio/gpio23/
insgesamt 0
-rw-r--r-- 1 root root 4096 Nov 18 18:03 active_low
lrwxrwxrwx 1 root root 0 Nov 18 18:03 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Nov 18 18:03 direction
-rw-r--r-- 1 root root 4096 Nov 18 18:03 edge
drwxr-xr-x 2 root root 0 Nov 18 18:03 power
-rw-r--r-- 1 root root 4096 Nov 18 18:03 pull
lrwxrwxrwx 1 root root 0 Nov 18 18:03 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Nov 18 18:03 uevent
-rw-r--r-- 1 root root 4096 Nov 18 18:03 value
ja, es sollte die 23 sein
seltsam, hast Du den Gpio aus FHEM heraus angelegt?
und war er davor sicher nicht vorhanden?
Der Gpio hab bei dir den besitzer root und ist auch in der Gruppe root. Eigentlich sollte er aber in der gruppe Gpio sein.
Aber wer weiss, was die Banane für Kernelmodule hat.
Was zeigt denn:
ls -l /sys/class/gpio/
was auf alle Fälle gehen sollte, ist in die rc.local filgendes einzuragen:
echo 23 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/virtual/gpio/*
chown -R fhem:root /sys/class/gpio/*
Zitatseltsam, hast Du den Gpio aus FHEM heraus angelegt?
ja
Zitatund war er davor sicher nicht vorhanden?
ja, war definitiv nicht da
ZitatWas zeigt denn:
Code: [Auswählen]
ls -l /sys/class/gpio/
pi@bananapi ~ $ ls -l /sys/class/gpio/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Nov 18 21:17 export
lrwxrwxrwx 1 root gpio 0 Nov 18 21:17 gpio10 -> ../../devices/platform/gpio-sunxi/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Nov 18 21:16 gpio22 -> ../../devices/platform/gpio-sunxi/gpio/gpio22
lrwxrwxrwx 1 root gpio 0 Nov 18 21:15 gpio23 -> ../../devices/platform/gpio-sunxi/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Nov 18 21:16 gpio27 -> ../../devices/platform/gpio-sunxi/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Nov 18 21:17 gpio9 -> ../../devices/platform/gpio-sunxi/gpio/gpio9
lrwxrwxrwx 1 root gpio 0 Jan 1 2010 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
-rwxrwx--- 1 root gpio 4096 Jan 1 2010 unexport
Zitatwas auf alle Fälle gehen sollte, ist in die rc.local filgendes einzuragen:
echo 23 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/virtual/gpio/*
chown -R fhem:root /sys/class/gpio/*
Dieser Eintrag ändert leider auch ncihts am Verhalten. In FHEM gibts wieder die selbe Fehlermeldung. Ehrlichgesagt habe ich auch nicht voll verstanden was das in rc.local bewirken soll?
Zitat von: santaclaus am 18 November 2014, 22:51:10
ja ja, war definitiv nicht da
pi@bananapi ~ $ ls -l /sys/class/gpio/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Nov 18 21:17 export
lrwxrwxrwx 1 root gpio 0 Nov 18 21:17 gpio10 -> ../../devices/platform/gpio-sunxi/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Nov 18 21:16 gpio22 -> ../../devices/platform/gpio-sunxi/gpio/gpio22
lrwxrwxrwx 1 root gpio 0 Nov 18 21:15 gpio23 -> ../../devices/platform/gpio-sunxi/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Nov 18 21:16 gpio27 -> ../../devices/platform/gpio-sunxi/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Nov 18 21:17 gpio9 -> ../../devices/platform/gpio-sunxi/gpio/gpio9
lrwxrwxrwx 1 root gpio 0 Jan 1 2010 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
-rwxrwx--- 1 root gpio 4096 Jan 1 2010 unexport
Hier sieht alles gut aus, die Ordner haben sind in der Gruppe Gpio und haben alle nötigen Rechte.
Zitat von: santaclaus am 18 November 2014, 18:08:04
pi@bananapi /sys/class/gpio $ ls -l /sys/class/gpio/gpio23/
insgesamt 0
-rw-r--r-- 1 root root 4096 Nov 18 18:03 active_low
lrwxrwxrwx 1 root root 0 Nov 18 18:03 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Nov 18 18:03 direction
-rw-r--r-- 1 root root 4096 Nov 18 18:03 edge
drwxr-xr-x 2 root root 0 Nov 18 18:03 power
-rw-r--r-- 1 root root 4096 Nov 18 18:03 pull
lrwxrwxrwx 1 root root 0 Nov 18 18:03 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Nov 18 18:03 uevent
-rw-r--r-- 1 root root 4096 Nov 18 18:03 value
Aber dann kann ich mir diese Rechte nicht erklären.
Zitat von: santaclaus am 18 November 2014, 22:51:10
Dieser Eintrag ändert leider auch ncihts am Verhalten. In FHEM gibts wieder die selbe Fehlermeldung. Ehrlichgesagt habe ich auch nicht voll verstanden was das in rc.local bewirken soll?
Durch diese Einträge exportierts du den GPIO23 und weist ihm die entsprechenden Zugriffsrechte zu... Ich sehe gerade, es sollte vermutlich:
chown -R fhem:gpioheissen.
Das RPI_GPIO Modul schaut im Define nach, ob der entsprechende GPIO bereits exportiert wurde und ob schreibzugriff besteht (exportieren und schreibrechte kannst du z.B. über die rc.local machen ).
Wenn dies nicht der Fall ist wird geprüft, ob schreibrecht auf
/sys/class/gpio/export besteht und wenn das der Fall ist, wird der Pin exportiert.
Wenn keine schreibrechte auf
/sys/class/gpio/export bestehen, wird geschaut, ob das wiringpi
/usr/local/bin/gpio existiert und der GPIO darüber angelegt.
In deinem ersten Post steht:
2014.11.16 22:30:53 4: LED1: write access to file /sys/class/gpio/export, use it to export GPIOwas heisst, das du schreibrechte auf die export Datei hast. Also müsste der GPIO exportiert worden sein.
Aber die rechte im GPIO Verzeichnis müssten danach etwas in der art sein:
-rwxrwx--- 1 root gpio 4096 Nov 17 16:26 value die Gruppe muss GPIO sein .. kannst du diese mit chmod ändern?
Ich habe chown -R fhem:gpio in der rc.local geändert.
Dann nochmal gpio reset gemacht. Das Verzeichnis /sys/class/gpio war daraufhin leer.
Nun habe ich über FHEM versucht einen GPIO anzulegen
define pin RPI_GPIO 23
Ergebnis im Verzeichnis, nun mit Gruppe gpio und vollen Rechten:
pi@bananapi /sys/class/gpio $ ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Nov 19 18:32 export
lrwxrwxrwx 1 root gpio 0 Nov 19 18:32 gpio23 -> ../../devices/platform/gpio-sunxi/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Nov 19 18:24 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
-rwxrwx--- 1 root gpio 4096 Nov 19 18:32 unexport
jedoch wieder die Fehlermeldung in FHEM
2014.11.19 18:34:54 5: Cmd: >define pin RPI_GPIO 23<
2014.11.19 18:34:54 4: pin: write access to file /sys/class/gpio/export, use it to export GPIO
2014.11.19 18:34:59 1: pin: failed to export pin gpio23
2014.11.19 18:34:59 1: define pin pin RPI_GPIO 23: pin: failed to export pin gpio23
in gpio23 sieht es so aus:
pi@bananapi /sys/class/gpio/gpio23 $ ls -l
insgesamt 0
-rw-r--r-- 1 root root 4096 Nov 19 18:38 active_low
lrwxrwxrwx 1 root root 0 Nov 19 18:38 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Nov 19 18:38 direction
-rw-r--r-- 1 root root 4096 Nov 19 18:38 edge
drwxr-xr-x 2 root root 0 Nov 19 18:38 power
-rw-r--r-- 1 root root 4096 Nov 19 18:38 pull
lrwxrwxrwx 1 root root 0 Nov 19 18:32 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Nov 19 18:32 uevent
-rw-r--r-- 1 root root 4096 Nov 19 18:32 value
probiere mal das hier:
EDIT: version ins SVN eingecheckt
Läuft, kann jetzt alle Pin´s wieder definieren ;D
Vielen Dank!
Ich weiß nicht ob ihr mir helfen könnt. Ich habe einen Banana Pi pro und will ihn mit einem COC betreiben. (der funktioniert auf einem RPi tadellos, Firmware ist also in Ordnung) Laut busware soll er über /dev/ttyS2 kommunizieren. Leider schlägt der Init fehl laut FHEM Log.
2014.12.20 23:56:23 3: Opening COC device /dev/ttyS2
2014.12.20 23:56:23 3: Setting COC baudrate to 38400
2014.12.20 23:56:23 3: COC device opened
2014.12.20 23:56:32 1: Cannot init /dev/ttyS2, ignoring it (COC)
Wenn ich die Pins 17/18 nacheinander an der Konsole schreibe gibt es keine Fehler, das COC blitzt nach dem letzten Komando kurz auf. Ich gehe davon aus, das COC entsprechend betriebsbereit ist. Der Fehler scheint also irgendwie am seriellen Port zu liegen. Habt ihr einen Tipp für mich, wie ich den Fehler finden kann? Ich habe Bananian getestet und auch Raspian
Nach dem Komandos auf Pin 17/18 sieht es so aus
root@bananapi ~/WiringBPi (git)-[bananapro] # gpio readall
+-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | ALT5 | 0 | 3 || 4 | | | 5V | | |
| 3 | 9 | SCL.1 | ALT5 | 0 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | OUT | 1 | 7 || 8 | 0 | IN | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | IN | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | OUT | 1 | 11 || 12 | 1 | IN | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | ALT4 | 0 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | ALT4 | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 0 | IN | GPIO. 5 | 5 | 24 |
| 10 | 12 | MOSI | IN | 0 | 19 || 20 | | | 0v | | |
| 9 | 13 | MISO | IN | 0 | 21 || 22 | 0 | ALT4 | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | IN | 0 | 23 || 24 | 0 | IN | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | IN | CE1 | 11 | 7 |
| 0 | 30 | SDA.0 | ALT4 | 0 | 27 || 28 | 0 | ALT4 | SCL.0 | 31 | 1 |
| 5 | 21 | GPIO.21 | IN | 0 | 29 || 30 | | | 0v | | |
| 6 | 22 | GPIO.22 | ALT4 | 0 | 31 || 32 | 0 | ALT4 | GPIO.26 | 26 | 12 |
| 13 | 23 | GPIO.23 | IN | 0 | 33 || 34 | | | 0v | | |
| 19 | 24 | GPIO.24 | IN | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 |
| 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | IN | GPIO.28 | 28 | 20 |
| | | 0v | | | 39 || 40 | 0 | IN | GPIO.29 | 29 | 21 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+
Ich möchte mich auch nochmal kurz dranhängen....
Ich habe leider das Problem dass bei mir das active_low nicht geschaltet wird. habe ein bananapi fhem 5.6 und ein update gemacht. dennoch bekomme ich die Fehlermeldung:
Can't open file: WzDose1, active_low
ls -l auf dem entsprechenden gpio14:
lrwxrwxrwx 1 root gpio 0 Aug 16 12:37 gpio14 -> ../../devices/platform/gpio-sunxi/gpio/gpio14
ls -l im gpio14 ordner:
/sys/class/gpio/gpio14# ls -l
insgesamt 0
-rw-r--r-- 1 root root 4096 Aug 16 12:37 active_low
lrwxrwxrwx 1 root root 0 Aug 16 12:49 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Aug 16 12:37 direction
-rw-r--r-- 1 fhem dialout 4096 Aug 16 12:37 edge
drwxr-xr-x 2 root root 0 Aug 16 12:49 power
-rw-r--r-- 1 root root 4096 Aug 16 12:49 pull
lrwxrwxrwx 1 root root 0 Aug 16 12:37 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Aug 16 12:37 uevent
-rw-r--r-- 1 fhem dialout 4096 Aug 16 12:38 value
jemand eine Idee?
PS. Alle GPIOs lassen sich über fhem schalten, nur das active_low nicht
Das ist ein Rechte-Problem. Mit der Banane klappt alles, was mit GPIO zu tun hat, leider nicht so ohne weiteres.
Du musst beim Start von der Banane die zu verwendenden GPIOs mit der Bin anlegen und danach die Rechte setzen. Steht in der commandref zum Modul.
Leider klappen bei mir aber nach wie vor die als Input definierten GPIOs nicht.
Das war es danke. Läuft jetzt wieder alles normal
Gesendet von meinem iPhone mit Tapatalk