Hallo, ich nutze an meinem RaspberryPi seit kurzem das Modul RPI_GPIO und
steuere damit eine Relaikarte an.
Wenn ich den Pi nun starte, ist das Relai auch aus, so wie es sein soll ... sobald Fhem
geladen ist schaltet das Relai an. Im Fhem ist der schalter dann auf "off" obwohl das Relai an ist!
Schalte ich nun im Fhem auf "on" so schaltet das Relai aus.
Wie kann ich den GPIO so konfigurieren, dass er beim starten des RaspberrPI und auch beim Laden
von Fhem aus bleibt?
Danke schonmal für eure Hilfe!
PS: auch beim Absetzen des Befehles "rereadcfg" schaltet das Relai kurz aus und dann wieder an.
define Pin11 RPI_GPIO 17
attr Pin11 direction output
attr Pin11 room Haus
Hallo,
da wohl kein direktes FHEM-Anfängerproblem sondern eher Modulbezogen hab ich das mal hier her verschoben (wo es lt. Maintainer.txt hin sollte) ;)
Grüße
Hallo,
so nun bin ich schon mal ein schritt weiter!
Mit...
attr Pin11 active_low yes
... mit "on" in Fhem schalte ich nun das Relai an und "off" wieder aus.
Der Befehl steht übrigends nicht in der Commandref !
Bei einem Neustart des PI's und bei einem "shutdown restart" schaltet das Relai aber
weiterhin für wennige Sekunden auf "on". Da scheint doch was beim Inizialisieren schief
zu gehen... Ich habs nun erstmal aufgegeben! Ich Hoffe also auf euch 8) ;)
Zitat von: Maergsche am 13 Juni 2014, 15:51:14
Hallo,
so nun bin ich schon mal ein schritt weiter!
Mit...
attr Pin11 active_low yes
... mit "on" in Fhem schalte ich nun das Relai an und "off" wieder aus.
Der Befehl steht übrigends nicht in der Commandref !
Bei einem Neustart des PI's und bei einem "shutdown restart" schaltet das Relai aber
weiterhin für wennige Sekunden auf "on". Da scheint doch was beim Inizialisieren schief
zu gehen... Ich habs nun erstmal aufgegeben! Ich Hoffe also auf euch 8) ;)
active_low im commandref wird nachgeliefert. Das es noch keinem aufgefallen ist 8)
Aber das passt schon, die Relaismodule die man käuflich erwerben kann haben meist invertierte Logik.
Was beim Booten passiert kann ich nicht beeinflussen. Aber wenn es während fhem Start passiert ist vielleicht abstellbar. Sind es wirklich mehrere Sekunden? Oder eher der Bruchteil einer Sekunde?
Ich hatte ein ähnliches Problem, allerdings in Verbindung mit Firmata. Da das RelayModul gegen Masse schaltete, kam es beim Start zu einem kurzen Einschalten. Das Problem habe ich durch das Vorschalten eines Transistors (zwecks Invertieren des Signals) gelöst.
(http://s6z.de/cms/images/content/arduino/Gong/Schema_Arduino_Klingel.png)
(s. die orangene Teilschaltung)
Zitat von: klausw am 13 Juni 2014, 18:32:51
active_low im commandref wird nachgeliefert. Das es noch keinem aufgefallen ist 8)
Aber das passt schon, die Relaismodule die man käuflich erwerben kann haben meist invertierte Logik.
Was beim Booten passiert kann ich nicht beeinflussen. Aber wenn es während fhem Start passiert ist vielleicht abstellbar. Sind es wirklich mehrere Sekunden? Oder eher der Bruchteil einer Sekunde?
Hallo Klausw,
so die letzen Tage waren bei mir etwas stressig, so dass ich mich nun erst jetzt wieder um das Thema kümmen konnte ... "Leider" bin ich auch dieses Wochenende nicht zu Hause, doch wollte ich nun endlich mal eine Rückmeldung geben.
Mein Relai hat auch eine Invertierte Logik, was erstmal ja kein Problem darstellen sollte.... Wenn ich den PI komplett ohne Definiton der GPIO's in der fhem.cfg neu starte, dann schaltet auch kein Relai. Mit der GPIO Definiton in der fhem.cfg schaltet das Relai beim Neustart.
Auch bei einem 'rereadcfg' schaltet das Relai. Somit muss es vom Modul '51_RPI_GPIO.pm' kommen.
Ich habe folgende Vermuttung:
Und zwar wird bei jedem 'rereadcfg' der GPIOxx neu in /sys/class/gpio/ angelegt (Egal, ob bereits vorhanden, oder nicht!). Dabei wird im default der Parameter auf 'active_low' auf 0 gesetzt. Im Späteren Verlauf wird dann der 'active_low' Parameter wieder auf 1 gesetzt. Ziehl ist es also, dass der GPIO nicht immer neu gesetzt wird.
Anbei noch ein Video mit der Schaltzeit.... Ich denke das erklärt das Timing am besten (bei Absetzen des 'rereadcfg' habe ich kräftig auf die Taste gehauen, damit du das Timing bis zum 1. Schalten des Relais auch hast :-) )
Gruß und Dank
Marc
Hi Marc,
stimmt, beim define wird der GPIO immer exportiert. Sicher ist sicher 8)
Ich hänge Dir mal eine neue Modulversion an.
Änderungen:
- gpio wird nur exportiert wenn er nicht vorher schon angelegt ist
- wenn der fhem user schreibrechte auf /sys/class/gpio/export hat wird der gpio darüber angelegt (sonst, falls vorhanden, über gpio utility)
- als erstes wird active_low gesetzt
- danach wird der gpio, wenn es ein output sein soll mit echo <high|low> /sys/class/gpio/gpioxx/direction din einem befehl auf output und level gesetzt
Das ganze klappt aber nur bei neueren raspbian Versionen (nicht älter als 6 Monate)
Bei diesen sind die gpios in der group gpio und können direkt von jedem, der auch Mitglied in dieser Gruppe ist genutzt werden.
Bei älteren Versionen läuft das über das gpio utility, da funktioniert das leider nicht.
Grüße
Klaus
Hallo Klaus,
danke für die schnelle Antwort. Ich habe das Modifizierte Modul getestet,
doch leider hat sich in Bezug auf das Relaischalten nix verändert, er schaltet
noch immer wie vorher einmal ein und dann wieder aus ...
Was ich bestätigen kann, ist dass der GPIO nicht mehr angelegt wird... hier mal ein 'list' meines Verzeichnisses:
(vor und nach dem 'rereadcfg'
pi@RasPiFhem /sys/class/gpio/gpio23 $ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 active_low
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 direction
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 edge
drwxrwx--- 2 root gpio 0 Jun 27 14:38 power
lrwxrwxrwx 1 root gpio 0 Jun 27 14:38 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 uevent
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 value
pi@RasPiFhem /sys/class/gpio/gpio23 $ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Jun 27 14:43 active_low
-rwxrwx--- 1 root gpio 4096 Jun 27 14:43 direction
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 edge
drwxrwx--- 2 root gpio 0 Jun 27 14:38 power
lrwxrwxrwx 1 root gpio 0 Jun 27 14:38 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 uevent
-rwxrwx--- 1 root gpio 4096 Jun 27 14:43 value
Man kann sehen, dass in activ_low, direction, und value bei einem 'rereadcfg' geschrieben wird.
Gruß Marc
Hallo nochmal,
nun verstehe ich das nicht mehr ... ich habe nochmal ein rereadcfg ausgeführt und
nun wurde der GPIO wieder exportiert.
pi@RasPiFhem /sys/class/gpio/gpio23 $ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Jun 27 14:43 active_low
-rwxrwx--- 1 root gpio 4096 Jun 27 14:43 direction
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 edge
drwxrwx--- 2 root gpio 0 Jun 27 14:38 power
lrwxrwxrwx 1 root gpio 0 Jun 27 14:38 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 27 14:38 uevent
-rwxrwx--- 1 root gpio 4096 Jun 27 14:43 value
pi@RasPiFhem /sys/class/gpio/gpio23 $ ls -l
total 0
pi@RasPiFhem /sys/class/gpio/gpio23 $ cd ..
pi@RasPiFhem /sys/class/gpio $ ls
export gpio23 gpio24 gpiochip0 unexport
pi@RasPiFhem /sys/class/gpio $ cd gpio23
pi@RasPiFhem /sys/class/gpio/gpio23 $ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Jun 27 14:52 active_low
-rwxrwx--- 1 root gpio 4096 Jun 27 14:52 direction
-rwxrwx--- 1 root gpio 4096 Jun 27 14:52 edge
drwxrwx--- 2 root gpio 0 Jun 27 14:52 power
lrwxrwxrwx 1 root gpio 0 Jun 27 14:52 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 27 14:52 uevent
-rwxrwx--- 1 root gpio 4096 Jun 27 14:52 value
Gruß Marc
schau mal ins log
da sollte drinstehen, was er gemacht hat
ich sehe gerade, das ich den value in der StateFn nochmal setze.
Es sollte sich aber eigentlich nicht negativ auswirken.
Das muss ich mir nochmal in ruhe anschauen.
Bei mir funktioniert es! Nach dem Neustart werden die GPIO's nicht mehr geschaltet.
Danke!!
Grüße
Zitat von: Maergsche am 27 Juni 2014, 14:54:00
danke für die schnelle Antwort. Ich habe das Modifizierte Modul getestet,
doch leider hat sich in Bezug auf das Relaischalten nix verändert, er schaltet
noch immer wie vorher einmal ein und dann wieder aus ...
wenn ich genauer hinschaue ist das logisch ... ich habe den code an der falschen stelle eingebaut :-/
Hallo Klaus,
ich bin gerade auf dem Weg nach Berlin, und komme auch nicht vor Sonntag zurück, sofern brauchst du keine panischen Codeänderungen machen ;)
An dieser Stelle schonmal danke, dass Du dich dem Themas widmest.
Schöne Grüße
Marc
so, neuer Versuch
gpio wird nur exportiert wenn noch nicht vorhanden
direction wird jetzt bei output pins erst gesetzt, wenn das erste mal ein value geschrieben werden soll (durch schreiben von high bzw. low in direktion wird der GPIO direkt gesetzt)
grüße
Klaus
Hallo Klaus,
leider keine guten Nachrichten ... Im Grunde hat sich nix verändert mit der neuen Version (Allerdings hatte ich auch nicht all zu lange Zeit zu testen)
Ich habe das neue Modul eingespielt, Rechte angepasst und ein "reload" des Modules sowie einen "sutdown restart" durchgeführt.
Bei einem "reread.cfg" schaltet das Relai wie gehabt einmal ein und wieder aus ...
Bei einem "rereadcfg" werden weiterhin Daten in activ_low,direction und value geschrieben...
pi@RasPiFhem /sys/class/gpio/gpio23 $ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Jun 30 15:53 active_low
-rwxrwx--- 1 root gpio 4096 Jun 30 15:53 direction
-rwxrwx--- 1 root gpio 4096 Jun 30 08:16 edge
drwxrwx--- 2 root gpio 0 Jun 30 08:16 power
lrwxrwxrwx 1 root gpio 0 Jun 30 08:16 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 30 08:16 uevent
-rwxrwx--- 1 root gpio 4096 Jun 30 15:53 value
pi@RasPiFhem /sys/class/gpio/gpio23 $
Wenn ich ein weiteres mal "rereadcfg" absende, dann wird der GPIO wieder neu angelegt...
pi@RasPiFhem /sys/class/gpio/gpio23 $ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Jun 30 15:58 active_low
-rwxrwx--- 1 root gpio 4096 Jun 30 15:58 direction
-rwxrwx--- 1 root gpio 4096 Jun 30 15:58 edge
drwxrwx--- 2 root gpio 0 Jun 30 15:58 power
lrwxrwxrwx 1 root gpio 0 Jun 30 15:58 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 30 15:58 uevent
-rwxrwx--- 1 root gpio 4096 Jun 30 15:58 value
pi@RasPiFhem /sys/class/gpio/gpio23 $
Hier mal ein paar Test's von mir:
16:05 rereadcfg ausgeführt > Neu angelegt
16:06 rereadcfg ausgeführt > Neu angelegt
16:07 rereadcfg ausgeführt > Neu angelegt
16:08 rereadcfg ausgeführt > Neu angelegt
16:09 rereadcfg ausgeführt > Neu angelegt
16:10 rereadcfg ausgeführt > Neu angelegt
16:12 rereadcfg ausgeführt > Neu angelegt
16:13 shutdown restart ausgeführt > nur activ_low,direction,value geschrieben
16:15 shutdown restart ausgeführt > nur activ_low,direction,value geschrieben
Nun habe ich mal die Inhalte der Dateien active_low, direction, value bei einem "shutdown restart" beobachtet.... und konnte feststellen, dass der Parameter "Value"
kurzzeitig auf 1 geht. Das kommt auch hin mit der Zeit wo das Relai schaltet
(bin momentan nicht zu Hause)
Dann habe ich gleichzeitig den Timestamp der Dateien und den Inhalt der Dateien beobachtet, indem ich bei einem "shutdown restart" folgenden Befehl mehrfach hintereinander ausgeführt habe... (Da gibt es sicher bessere Lösungen, aber es funktionierte ::) )
Das Ergebnis war sehr interessant! Denn ohne, dass sich der Timestamp vom Value verändert hat, hat sich der Inhalt geändert...
Hier mal zusammengefasst...
1. Activ_low und direction bekommen ein neuen Timestamp (Wert ändert sich nicht), parallel ändert sich der Value-Wert von 0 auf 1 (Timestamp ändert sich nicht)
2. Nach ein paar Sekunden ändert sich der Value-Wert von 1 auf 0, sowie der Timestamp von Value.
Ich habe mal das Output angehängt...
Gruß Marc
Hi Marc,
wenn das GPIO anlegen beim rereadcfg passiert und beim shutdown restart nicht liegt es vielleicht am rereadcfg.
Kann es sein das dabei die UndefFn ausgeführt wird?
activ_low, direction und value werden geschrieben, das ist richtig
Die Ursache, das Value sich ändert aber die timestamp gleichbleibt liegt sicher daran, das ich high/low in die Datei direction schreibe.
Aber ich habe noch 3 Fehler entdeckt.
zum einen hat restore_on_startup nicht funktioniert, wenn es benutzt wurde und auf yes gesetzt war
und bei schreiben von direction waren auch noch zwei fehler
Ich bin unterwegs und kann es leider nicht testen, aber es könnte daran gelegen haben.
Hier die korrigierte Version:
Hallo, nun hat sich was geändert...
un zwar blinkt die LED nur noch kurz auf und das Relai schaft es in der Zeit nichtmal voll anzuziehen...
Wie ist denn momentan die Programmierung?
Wird vor dem Setzen der 'direction' bzw. 'active_low' geprüft ob die Werte evtl. bereits korrekt sind, und nur dann
geschrieben, wenn diese von der Config im Fhem abweichen? Meine Annahme ist ja momentan, dass das setzen des
'direction' oder des 'aktive_low' Wertes das flackern nachwievor verursacht...
Anbei noch mal ein Video von "Flackern" des Ausganges!
Zitat von: Maergsche am 30 Juni 2014, 20:16:02
Hallo, nun hat sich was geändert...
un zwar blinkt die LED nur noch kurz auf und das Relai schaft es in der Zeit nichtmal voll anzuziehen...
Wie ist denn momentan die Programmierung?
Wird vor dem Setzen der 'direction' bzw. 'active_low' geprüft ob die Werte evtl. bereits korrekt sind, und nur dann
geschrieben, wenn diese von der Config im Fhem abweichen? Meine Annahme ist ja momentan, dass das setzen des
'direction' oder des 'aktive_low' Wertes das flackern nachwievor verursacht...
ein File im GPIO verzeichnis mit dem gleichen Wert zu überschreiben ändert am Pegel selbst nix
Das hatte ich vor einigen Monaten mal angeschaut (und hoffentlich keinen Mist gemessen ;)).
Derzeit ist es so:
- nach neustart
-ports exportiert (wenn nicht vorhanden)
- attribute werden in die files geschrieben (active_low, bei inputs auch direction)
- in der StateFn soll bei outputs der Value geschrieben werden
- bei dieser operation wird geprüft, ob bereits out in direction geschrieben wurde ...wenn ja wird value geschrieben
- wenn nein wird direction geschrieben, und zwar
high für on und
low für off
- danach wird value nochmal geschrieben (ist zwar unnötig, aber einfacher zu handhaben)
ich habe einen anderen verdacht:
wenn ich in direction ein high schreibe, dann geht der gpio auch auf high (unabhängig davon was in active_low steht)
das habe ich jetzt vorm Fussballspiel noch schnell geändert ;)
ich frage jetzt den status von active_low ab und vertausche high/low wenn active_low on ist
edit: wir inzwischen per update verteilt
Hallo, ich versuche grade verzweifelt die GPIOs meines Raspi anzusprechen bzw. on und off zu setzen. Dies funktioniert leider irgendwie nicht, könntet ihr mir da vlt. auf die Sprünge helfen? LG Spuckiii
Zitat von: Spuckiii am 13 Juli 2014, 18:43:50
Hallo, ich versuche grade verzweifelt die GPIOs meines Raspi anzusprechen bzw. on und off zu setzen. Dies funktioniert leider irgendwie nicht, könntet ihr mir da vlt. auf die Sprünge helfen? LG Spuckiii
Was wird denn im Logfile ausgegeben?
Cant Read pin 11. error... sowas in der Richtung (Bin grade auf Arbeit). Wenn ich den Raspi neustartet schaltet er aber beim Hochfahen den PIN auf Output. das funktioniert. Wenn ich zu Hause bin, poste ich mal das logfile.
LG Martin
Zitat von: Spuckiii am 14 Juli 2014, 10:46:13
Cant Read pin 11. error... sowas in der Richtung (Bin grade auf Arbeit). Wenn ich den Raspi neustartet schaltet er aber beim Hochfahen den PIN auf Output. das funktioniert. Wenn ich zu Hause bin, poste ich mal das logfile.
LG Martin
Poste auch gleich noch die Ausgabe von:
ls -l /sys/class/gpio/gpio17/...das kannst du auch direkt über die FHEM Eingabe machen:
{`ls -l /sys/class/gpio/gpio17/`}Grüße
Klaus
Hier der Auszug aus der LOG File
2014.07.13 19:24:28 1: Can't open file: Pin26, value
und hier die Antwort vom Raspi:
pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio17/total 0
-rwxrwx--- 1 root gpio 4096 Jul 13 19:09 active_low
-rwxrwx--- 1 root gpio 4096 Jul 13 19:09 direction
-rwxrwx--- 1 root gpio 4096 Jul 13 19:09 edge
drwxrwx--- 2 root gpio 0 Jul 13 19:09 power
lrwxrwxrwx 1 root gpio 0 Jul 13 19:09 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jul 13 19:09 uevent
-rwxrwx--- 1 root gpio 4096 Jul 13 19:09 value
Also irgendwas stimmt nicht, Du hast mir folgendes geschickt:
Zitat von: Spuckiii am 13 Juli 2014, 18:33:14
Nachtrag:
wiring PI hab ich installiert und in fhem schon das eingegeben
define Pin11 RPI_GPIO 17
attr Pin11 direction output
attr Pin11 room Haus
attr Pin11 active_low yes
aber die der PIN wird nicht on off geschaltet
und in deinem Logfile steht das:
Zitat von: Spuckiii am 14 Juli 2014, 17:33:17
2014.07.13 19:24:28 1: Can't open file: Pin26, value
Das würde zum Einen bedeuten, das
Pin11 funktionieren muss, da sonst Fehler zu
Pin11 im Logfile zu finden sein müssten. Zum Anderen gibt es ein Problem mit Pin26 ...kann ich nix zu sagen, da mir die config fehlt. Aber konzentrieren wir uns auf gpio17.
Ändert dich denn der Inhalt der value-Datei von gpio17 wenn du set Pin11 on|off ausführst?
Stimmt Deine Verdrahtung?
Hallo welche Config brauchst du?
Verdrahtung stimmt, ich kann das 8 Kanal Relay Pin 11 / 26 jeweils mit gprio write 0 / 11 1/0 in der Console ausschalten bzw. anschalten, nur halt nicht über fhem dann kommt dann immer die Fehlermeldung:
2014.07.14 18:56:08 1: Can't open file: Pin26, value
2014.07.14 18:56:10 1: Can't open file: Pin11, value
achso, mich hatte nur Pin26 irritiert :)
also die Dateirechte sind ok ...sehen bei mir nicht anders aus
der gpio wurde ja auch angelegt, was heisst, das die rechte stimmen sollten
an der definition kann ich auch nichts falsches erkennen
andere prozesse, welche auf die gpios zugreifen laufen nicht?
starte fhem bitte mal mit verbose 4 und poste das log (nach beenden und vor dem start die beiden gpios mit unexport entfernen)
ah... hm... ne also andere Prozesse laufen nicht. blöde Frage wie starte ich fhem mit verbose 4?
Zitat von: Spuckiii am 14 Juli 2014, 19:36:57
blöde Frage wie starte ich fhem mit verbose 4?
attr global verbose 4
danke ;-) hat geklappt hier der logg:
014.07.14 19:39:07 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem
2014.07.14 19:39:07 4: /fhem / RL:998 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.07.14 19:39:08 4: Closing connection FHEMWEB:192.168.0.228:45288
2014.07.14 19:39:08 4: Closing connection FHEMWEB:192.168.0.228:45287
2014.07.14 19:39:08 4: Closing connection FHEMWEB:192.168.0.228:45285
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem/pgm2/style.css
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45286 GET /fhem/pgm2/svg.js
2014.07.14 19:39:08 4: Connection accepted from FHEMWEB:192.168.0.228:45301
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.07.14 19:39:08 4: Connection accepted from FHEMWEB:192.168.0.228:45302
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45301 GET /fhem/pgm2/fhemweb.js
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45302 GET /fhem/pgm2/fhemweb_multiple.js
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45286 GET /fhem/pgm2/fhemweb_noArg.js
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem/pgm2/fhemweb_svg.js
2014.07.14 19:39:08 4: Connection accepted from FHEMWEB:192.168.0.228:45303
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45302 GET /fhem/pgm2/fhemweb_time.js
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45303 GET /fhem/pgm2/fhemweb_readingsHistory.js
2014.07.14 19:39:08 4: Connection accepted from FHEMWEB:192.168.0.228:45304
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45301 GET /fhem/pgm2/fhemweb_textField.js
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45304 GET /fhem/pgm2/fhemweb_slider.js
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem/pgm2/defaultCommon.css
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem/pgm2/dashboard_style.css
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem/images/default/icoEverything.png
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem/images/default/fhemicon.png
2014.07.14 19:39:08 4: HTTP FHEMWEB:192.168.0.228:45284 GET /fhem?XHR=1&inform=type=status;filter=×tamp=1405359538595
2014.07.14 19:39:32 4: ENIGMA2 Wz.TvReceiver: REQ powerstate
2014.07.14 19:39:32 4: HttpUtils url=http://192.168.0.37:80/web/powerstate
2014.07.14 19:39:33 4: http://192.168.0.37:80/web/powerstate: HTTP response code 200
2014.07.14 19:39:33 4: HttpUtils http://192.168.0.37:80/web/powerstate: Got data, length: 104
2014.07.14 19:39:33 4: ENIGMA2 Wz.TvReceiver: RCV powerstate
2014.07.14 19:39:33 4: ENIGMA2 Wz.TvReceiver: REQ getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.favourites.radio" ORDER BY bouquet&
2014.07.14 19:39:33 4: HttpUtils url=http://192.168.0.37:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2efavourites%2eradio%22%20ORDER%20BY%20bouquet&
2014.07.14 19:39:33 4: ENIGMA2 Wz.TvReceiver: REQ getcurrent
2014.07.14 19:39:33 4: HttpUtils url=http://192.168.0.37:80/web/getcurrent
2014.07.14 19:39:33 4: ENIGMA2 Wz.TvReceiver: REQ timerlist
2014.07.14 19:39:33 4: HttpUtils url=http://192.168.0.37:80/web/timerlist
2014.07.14 19:39:33 4: ENIGMA2 Wz.TvReceiver: REQ vol
2014.07.14 19:39:33 4: HttpUtils url=http://192.168.0.37:80/web/vol
2014.07.14 19:39:33 4: ENIGMA2 Wz.TvReceiver: REQ signal
2014.07.14 19:39:33 4: HttpUtils url=http://192.168.0.37:80/web/signal
2014.07.14 19:39:35 4: http://192.168.0.37:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2efavourites%2eradio%22%20ORDER%20BY%20bouquet&: HTTP response code 200
2014.07.14 19:39:35 4: HttpUtils http://192.168.0.37:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2efavourites%2eradio%22%20ORDER%20BY%20bouquet&: Got data, length: 73
2014.07.14 19:39:35 4: ENIGMA2 Wz.TvReceiver: RCV getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.favourites.radio" ORDER BY bouquet&
2014.07.14 19:39:35 4: ENIGMA2 Wz.TvReceiver: ERROR: Unable to read radio bouquet '1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.favourites.radio" ORDER BY bouquet' from device
2014.07.14 19:40:07 4: Connection accepted from telnet:127.0.0.1:48783
2014.07.14 19:40:07 0: Server shutdown
2014.07.14 19:40:28 1: Including fhem.cfg
2014.07.14 19:40:28 3: telnetPort: port 7072 opened
2014.07.14 19:40:29 3: WEB: port 8083 opened
2014.07.14 19:40:29 3: WEBphone: port 8084 opened
2014.07.14 19:40:29 3: WEBtablet: port 8085 opened
2014.07.14 19:40:29 2: eventTypes: loaded 124 events from ./log/eventTypes.txt
2014.07.14 19:40:32 1: Pin11: using gpio utility to export pin
2014.07.14 19:40:37 1: Pin11: failed to export pin gpio17
2014.07.14 19:40:37 1: Pin11: direction �ber gpio utility einstellen
2014.07.14 19:40:42 1: Pin11: failed to export pin gpio17
2014.07.14 19:40:42 1: Can't open file: Pin11, active_low
2014.07.14 19:40:42 1: Pin11: direction �ber gpio utility einstellen
2014.07.14 19:40:42 1: Pin26: using gpio utility to export pin
2014.07.14 19:40:47 1: Pin26: failed to export pin gpio7
2014.07.14 19:40:48 1: Pin26: direction �ber gpio utility einstellen
2014.07.14 19:40:53 1: Pin26: failed to export pin gpio7
2014.07.14 19:40:53 1: Pin26: direction �ber gpio utility einstellen
2014.07.14 19:40:53 1: Including ./log/fhem.save
2014.07.14 19:40:53 1: Can't open file: Pin11, value
2014.07.14 19:40:53 1: Can't open file: Pin26, value
2014.07.14 19:40:53 1: usb create starting
2014.07.14 19:40:54 3: Probing CUL device /dev/ttyAMA0
2014.07.14 19:40:55 3: Probing TCM310 device /dev/ttyAMA0
2014.07.14 19:40:55 3: Probing FRM device /dev/ttyAMA0
2014.07.14 19:41:00 1: usb create end
2014.07.14 19:41:00 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.07.14 19:41:00 0: Server started with 13 defined entities (version $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $, os linux, user pi, pid 2381)
Zitat von: Spuckiii am 14 Juli 2014, 19:42:32
2014.07.14 19:41:00 0: Server started with 13 defined entities (version $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $, os linux, user pi, pid 2381)
den Pinzugriff über das gpio utility muss ich mir nochmal anschauen ...vielleicht habe ich da mit gebaut
aber das ist bei dir vermutlich egal, Dein FHEM läuft unter dem user pi ...komisch es sollte eigentlich der user fhem sein.
das:
sudo adduser fhem pi
sudo reboot müsste demnach bei dir helfen
Hallo,
leider hat es nicht geholfen:
2014.07.14 20:02:18 0: Server shutdown
2014.07.14 20:02:34 1: Including fhem.cfg
2014.07.14 20:02:34 3: telnetPort: port 7072 opened
2014.07.14 20:02:36 3: WEB: port 8083 opened
2014.07.14 20:02:36 3: WEBphone: port 8084 opened
2014.07.14 20:02:36 3: WEBtablet: port 8085 opened
2014.07.14 20:02:37 2: eventTypes: loaded 124 events from ./log/eventTypes.txt
2014.07.14 20:02:41 1: Pin11: using gpio utility to export pin
2014.07.14 20:03:04 1: Pin11: failed to export pin gpio17
2014.07.14 20:03:04 1: Pin11: direction �ber gpio utility einstellen
2014.07.14 20:03:09 1: Pin11: failed to export pin gpio17
2014.07.14 20:03:09 1: Can't open file: Pin11, active_low
2014.07.14 20:03:09 1: Pin11: direction �ber gpio utility einstellen
2014.07.14 20:03:09 1: Pin26: using gpio utility to export pin
2014.07.14 20:03:14 1: Pin26: failed to export pin gpio7
2014.07.14 20:03:14 1: Pin26: direction �ber gpio utility einstellen
2014.07.14 20:03:19 1: Pin26: failed to export pin gpio7
2014.07.14 20:03:19 1: Pin26: direction �ber gpio utility einstellen
2014.07.14 20:03:19 1: Including ./log/fhem.save
2014.07.14 20:03:19 1: Can't open file: Pin11, value
2014.07.14 20:03:19 1: Can't open file: Pin26, value
2014.07.14 20:03:19 1: usb create starting
2014.07.14 20:03:21 3: Probing CUL device /dev/ttyAMA0
2014.07.14 20:03:21 3: Probing TCM310 device /dev/ttyAMA0
2014.07.14 20:03:22 3: Probing FRM device /dev/ttyAMA0
2014.07.14 20:03:27 1: usb create end
2014.07.14 20:03:27 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.07.14 20:03:27 0: Server started with 13 defined entities (version $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $, os linux, user fhem, pid 1946)
2014.07.14 20:03:50 1: Can't open file: Pin11, value
2014.07.14 20:03:52 1: Can't open file: Pin11, value
2014.07.14 20:03:53 1: Can't open file: Pin26, value
2014.07.14 20:03:54 1: Can't open file: Pin26, value
was zeigt das an:
cat /etc/group
was ich nicht verstehe ist, wie die pins angelegt werden können wenn die zugriffe fehlschlagen
pi@raspberrypi ~ $ cat /etc/group
root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:pi
tty:x:5:pi,fhem
disk:x:6:
lp:x:7:
mail:x:8:
news:x:9:
uucp:x:10:
man:x:12:
proxy:x:13:
kmem:x:15:
dialout:x:20:pi
fax:x:21:
voice:x:22:
cdrom:x:24:pi
floppy:x:25:
tape:x:26:
sudo:x:27:pi
audio:x:29:pi
dip:x:30:
www-data:x:33:
backup:x:34:
operator:x:37:
list:x:38:
irc:x:39:
src:x:40:
gnats:x:41:
shadow:x:42:
utmp:x:43:
video:x:44:pi
sasl:x:45:
plugdev:x:46:pi
staff:x:50:
games:x:60:pi
users:x:100:pi
nogroup:x:65534:
libuuid:x:101:
crontab:x:102:
pi:x:1000:fhem
ssh:x:103:
ntp:x:104:
netdev:x:105:pi
input:x:999:pi
messagebus:x:106:
lpadmin:x:107:
fuse:x:108:
lightdm:x:109:
indiecity:x:1001:root
spi:x:1002:pi
gpio:x:1003:pi
Zitat von: Spuckiii am 14 Juli 2014, 20:05:41
2014.07.14 20:03:27 0: Server started with 13 defined entities (version $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $, os linux, user fhem, pid 1946)
jetzt ist der user bei Dir wieder fhem
Zitat von: Spuckiii am 14 Juli 2014, 20:10:10
gpio:x:1003:pi
aber der fehlt in der gruppe gpio
gebe diese zeilen ein, dann muss es endlich gehen:
sudo adduser fhem gpio
sudo reboot mein code von eben war falsch, sollte eingentlich heissen:
sudo adduser pi gpio
sudo reboot aber das hattest Du ja sowieso schon eingetragen
Cool das war es wohl, jetzt klappt es... :-) Danke sehr..
jetzt muss ich nur noch n Schalter definieren und den homematic schalter ans laufen bringen... danke schön
Zitat von: Spuckiii am 14 Juli 2014, 20:27:53
Cool das war es wohl, jetzt klappt es... :-) Danke sehr..
jetzt muss ich nur noch n Schalter definieren und den homematic schalter ans laufen bringen... danke schön
sehr schön :)
Zitat von: Spuckiii am 14 Juli 2014, 20:05:41
2014.07.14 20:03:27 0: Server started with 13 defined entities (version $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $, os linux, user fhem, pid 1946)
Du solltest ein Update machen, Du hast noch eine ältere Version von RPI_GPIO drauf
Hallo nochmal,
(auf Grund eines Familiären Zwischenfalls, komme ich leider erst jetzt wieder dazu...)
leider funktioniert es nach wievor noch nicht korrekt ... Weiterhin flackert das Relay bei einem "shutdown restart"
Anbei mal ein Log:
2014.09.01 16:22:09 4: Pin16: gpio23 already exists
2014.09.01 16:22:09 4: Pin18: gpio24 already exists
2014.09.01 16:22:12 4: ENIGMA2 ET9000: REQ powerstate
2014.09.01 16:22:12 4: HttpUtils url=http://xxx:xxx@192.168.xxx.100:80/web/powerstate
2014.09.01 16:22:14 1: Including ./log/fhem.save
2014.09.01 16:22:15 4: Pin16: STATE kann auf off wiederhergestellt werden 2014-09-01 16:22:15
2014.09.01 16:22:15 4: Pin16: state kann auf off wiederhergestellt werden 2014-09-01 16:07:33
2014.09.01 16:22:15 4: OUTPUT Pin16: state wiederhergestellt auf off
2014.09.01 16:22:15 4: Pin16: direction gesetzt auf low
2014.09.01 16:22:15 4: OUTPUT Pin16: STATE wiederhergestellt auf off (restoreOnStartup=last)
2014.09.01 16:22:15 4: Pin18: STATE kann auf off wiederhergestellt werden 2014-09-01 16:22:15
2014.09.01 16:22:15 4: Pin18: state kann auf off wiederhergestellt werden 2014-09-01 16:07:33
2014.09.01 16:22:15 4: OUTPUT Pin18: state wiederhergestellt auf off
2014.09.01 16:22:15 4: Pin18: direction gesetzt auf low
2014.09.01 16:22:15 4: OUTPUT Pin18: STATE wiederhergestellt auf off (restoreOnStartup=last)
Hm, dann muss ich mal mit dem Oszi schauen. Aber ging es nicht schonmal ohne Relais klackern?
Hast du noch andere GPIO Scripte laufen? Bei mir flackert nix (allerdings habe ich auch nichtinvertierte logik verwendet).
Grüße
Klaus
Zitat von: klausw am 02 September 2014, 08:17:33
Aber ging es nicht schonmal ohne Relais klackern? Hast du noch andere GPIO Scripte laufen? Bei mir flackert nix (allerdings habe ich auch nichtinvertierte logik verwendet).
Hallo Klaus,
nein leider funktionierte es bis jetzt noch nicht... Andere GPIO Skripte habe ich nicht laufen.
Es wird ja sicher an der Invertierten Logik und auch mit großer Wahrscheinlichkeit an dem Wiederherstellen des letzten Schaltzustandes liegen. Leider komme ich mit der Programmiersprache noch nicht so klar, sonst hätte ich hier schon selbst mal Hand angelegt :-[ . (aktuell habe ich ja die Vermutung, dass beim auslesen, der Invertierte oder ein falscher Wert gelesen und dann überflüssig die Werte Initialisiert und / oder (nur) neu gesetzt werden, aber das ist gefährliches halbwissen :-\ )
Deinem Log nach zu urteilen passt alles. Das Modul schreibt low direkt in das File direction, was dazu führt das der Port auf Output gesetzt wird und gleichzeitig auf low. Neu angelegt wird er auch nicht mehr.
Hast du schon mal nichtinvertiertende Logik getestet?
Schau dir mal das an:
pi@RasPiFhem /sys/class/gpio $ cd gpio24
pi@RasPiFhem /sys/class/gpio/gpio24 $ cat direction
out
pi@RasPiFhem /sys/class/gpio/gpio24 $ cat value
0
pi@RasPiFhem /sys/class/gpio/gpio24 $ echo "low" > direction
pi@RasPiFhem /sys/class/gpio/gpio24 $ cat direction
out
pi@RasPiFhem /sys/class/gpio/gpio24 $ cat value
1
pi@RasPiFhem /sys/class/gpio/gpio24 $
Bei Dir im im Skript im sub RPI_GPIO_fileaccess wird nach einem "shutdown restart" immer in die Schleife "if ($hash->{dir_not_set} && $fname eq "value")" gegangen. Die driection wird auf "low" geschrieben. Dabei wird aber des Value von 0 auf 1 gesetzt.
Im Weiteren Verlauf des Aufrufs wird dann das Value wieder "0" gesetzt.
Das sollte das Flackern sein ! ;)
Zitat von: Maergsche am 02 September 2014, 11:24:18
Bei Dir im im Skript im sub RPI_GPIO_fileaccess wird nach einem "shutdown restart" immer in die Schleife "if ($hash->{dir_not_set} && $fname eq "value")" gegangen. Die driection wird auf "low" geschrieben. Dabei wird aber des Value von 0 auf 1 gesetzt.
Im Weiteren Verlauf des Aufrufs wird dann das Value wieder "0" gesetzt.
Das sollte das Flackern sein ! ;)
Komisch, es scheint so als würde sich das active_low doch auf die direction Datei auswirken. Ich dachte ich hätte es anders getestet.
Ändere Zeile 492 auf:
my $lev=1;
Dann sollte es gehen
Zitat von: klausw am 02 September 2014, 14:36:07
Ändere Zeile 492 auf:
my $lev=1;
Dann sollte es gehen
Ich denke das wird's nicht sein ... $lev war immer 1 ...
ich habe die Zeile 492 geändert auf:
my $lev = $al eq "yes" ? 0 : 1; # "on" in "yes" geändert
($al beinhaltete "yes" anstatt "on" und somit war $lev immer "1")
Wenn ich zu hause bin, dann werde ich das noch mal Testen.
Geht es dann noch wenn activ_low = "no" ist ?!?
Mmm ich sehe gerade, dass du active_low von no/yes auf off/on geändert hast ???
Allerdings nicht durchgehend im Code .... und laut Dokumentation soll da on/off rein
aber das würde so nicht funktionieren! Beim Deklarieren von "attr Pin16 active_low yes"
mit dem on / off anstatt yes würde Fhem schon eine Fehlermeldung ausgeben ...
Zitat von: Maergsche am 02 September 2014, 15:29:45
Mmm ich sehe gerade, dass du active_low von no/yes auf off/on geändert hast ???
Nein, da ist die Doku falsch (und auch Zeile 492...natürlich muss es "yes" anstelle von "on" heissen). War sicher wieder so eine nach Mitternacht Aktion. Da passiert viel Mist.
Dann sollte es auch gehen. Das mit dem statistischen Wert war nur ne Idee, da ich gerade nicht das verhalten der GPIO s testen kann
So, bei mir sieht es nun so aus:
if ($dir eq "out" && $fname eq "value" && defined($args[1])) {
my $al = AttrVal($hash->{NAME},"active_low","no");
my $lev = $al eq "yes" ? 0 : 1;
#Log3 $hash, 4, "$hash->{NAME}: arg=$args[1] al=$al lev=$lev";
$dir = ($args[1] == $lev ? "high" : "low")
}
Hab nun auch noch die Zeile da drüber angepasst, und das 'off' durch "no" ersetzt ...
Damit sollte es dann funktionieren!
ZitatNein, da ist die Doku falsch
Ich hatte erst schon ein P im Gesicht, konnte dann aber auch aus dem Code lesen,
dass das nicht sein konnte.
Bin nun gleich zu Hause und werde mal Testen und hier berichten!
Jetzt funktioniert es ohne Flackern.... Mit invert und ohne!
Schreibst du noch mal, sobald es über das Update verfügbar ist?
Gruß und Dank
Zitat von: Maergsche am 02 September 2014, 18:26:39
Schreibst du noch mal, sobald es über das Update verfügbar ist?
Habs eingecheckt
Hallo zusammen,
Das GPIO Modul läuft bei mir bisher ausgezeichnet.
Nur GPIO4 scheint zu spinnen.
Definiert habe ich ihn als Input inkl. Interrupt, wie die GPIO 2, 3 und 22 auch. Nachdem GPIO4 "irgendwie" nicht funktionierte, wollte ich ihn löschen, was FHEM zum Absturz bringt. Nur das Attr Interrupt löschen bringt das gleiche Ergebnis. Selbst löschen in der fhem.cfg lässt FHEM abstürzen.
Vielleicht macht das 1wire Modul Probleme? Steht ja auf GPIO4.
Konnte jemand ähnliches Verhalten nachstellen?
Die fhem.cfg und Logs kann ich leider erst am Mittwoch nachliefern.
Grüße
Matthias
Zitat von: Matzek83 am 13 Oktober 2014, 06:37:07
Definiert habe ich ihn als Input inkl. Interrupt, wie die GPIO 2, 3 und 22 auch. Nachdem GPIO4 "irgendwie" nicht funktionierte, wollte ich ihn löschen, was FHEM zum Absturz bringt. Nur das Attr Interrupt löschen bringt das gleiche Ergebnis. Selbst löschen in der fhem.cfg lässt FHEM abstürzen.
Vielleicht macht das 1wire Modul Probleme? Steht ja auf GPIO4.
Konnte jemand ähnliches Verhalten nachstellen?
Die fhem.cfg und Logs kann ich leider erst am Mittwoch nachliefern.
Nutzt du auch das 1wire modul?
Nein, nicht mehr. Wollte jetzt eben den GPIO nutzen. Theoretisch kann es weg. Interessant wärs vllt. trotzdem - für die allgemeine Stabilität.
Ich lösche das 1wire Modul und versuchs nochmal... Bericht folgt.
Zitat von: Matzek83 am 13 Oktober 2014, 12:43:21
Nein, nicht mehr. Wollte jetzt eben den GPIO nutzen. Theoretisch kann es weg. Interessant wärs vllt. trotzdem - für die allgemeine Stabilität.
Ich lösche das 1wire Modul und versuchs nochmal... Bericht folgt.
Du könntest mal posten, was im log und im stdout angezeigt wird.
Evtl. kann ich den Fehler abfangen und gleich das anlegen des Pin verhindern.
Stabil läuft es ja an sich, das nachdenken kann man natürlich niemandem abnehmen ;)
Joah... nachdenken wäre gut... :o
Stabil läuft es -- spitzenmäßig.
Meine Beschwerde galt der allgemeinen Verbesserung, wenn notwendig.
Ich komme erst Mittwoch dazu und poste den Log und teste alles ohne 1wire.
Anlegen abfangen klingt gut, am besten in beide Reihenfolgen. Also wenn GPIO4 angelegt ist auch das Anlegen von 1wire verhindern.
Grüße und danke für die schnellen Antworten
Zitat von: Matzek83 am 13 Oktober 2014, 16:12:16
Meine Beschwerde galt der allgemeinen Verbesserung, wenn notwendig.
Ich komme erst Mittwoch dazu und poste den Log und teste alles ohne 1wire.
Anlegen abfangen klingt gut, am besten in beide Reihenfolgen. Also wenn GPIO4 angelegt ist auch das Anlegen von 1wire verhindern.
passt schon
Ich schaue mir Deine Fehlermeldungen an und dann sehen wir, was sich anpassen lässt.
Ich weiss halt nicht genau, was der 1wire Kerneltreiber blockiert. also lösche nicht zuviel weg, Du musst das dann auch testen :)
Alles klar... 8)
Hi Klaus,
nun endlich meine Logs. Beinhaltet einmal hochfahren, GPIO4 löschen mit beschrieben FHEM-Absturz und neustarten vom Raspi.
Deinstallation der 1wire-Sensoren bringt übrigens keine Abhilfe. Fehler ist sauber reproduzierbar auch ohne 1wire. Logs sind noch inklusive der 1wire-Sensoren.
Also ist entweder bei meiner fhem.cfg was nicht OK oder das 1wire-Modul hat noch Einfluss und muss anders deinstalliert werden. Oder am RPI_GPIO-Modul stimmt was nicht -- kaum zu glauben. :-X
Grüße
Matthias
Bei mir funktioniert das Modul z.B. mit Garagentor über zwei Relais einwandrei.
Allerdings initialisiere ich die GPIOs beim RPi-Start:
#! /bin/bash
#! /etc/init.d/garage_init
case "$1" in
start)
echo "Garage: Initialisiere Relais ..."
# GPIOs einschalten, damit die Relais nach dem Init aus bleiben
gpio write 7 1
gpio write 8 1
# GPIOs initialisieren
gpio mode 7 out
gpio mode 8 out
;;
stop)
echo "Garage: auf Wiedersehen..."
;;
*)
echo "Usage: /etc/init.d/garage_init {start|stop}"
exit 1
;;
esac
exit 0
Und eine Beispieldefinition in fhem.cfg sieht so aus:
define GarageHoch RPI_GPIO 4
attr GarageHoch active_low yes
attr GarageHoch devStateIcon .*:control_centr_arrow_up
attr GarageHoch direction output
attr GarageHoch eventMap on:Auf
attr GarageHoch fm_type smarttogglebutton
attr GarageHoch group RPi-Relais
attr GarageHoch icon fts_garage
attr GarageHoch restoreOnStartup off
attr GarageHoch room Garage
attr GarageHoch webCmd Auf
define GarageRunter RPI_GPIO 2
attr GarageRunter active_low yes
attr GarageRunter devStateIcon .*:control_centr_arrow_down
attr GarageRunter direction output
attr GarageRunter eventMap on:Ab
attr GarageRunter fm_type smarttogglebutton
attr GarageRunter group RPi-Relais
attr GarageRunter icon fts_garage_door_100
attr GarageRunter restoreOnStartup off
attr GarageRunter room Garage
attr GarageRunter webCmd Ab
Dazu gibt es noch zwei notifys, die nach einer halben Sekunde jeweils wieder das Relais abschalten.
Zitat von: Matzek83 am 19 Oktober 2014, 09:17:26
Hi Klaus,
nun endlich meine Logs. Beinhaltet einmal hochfahren, GPIO4 löschen mit beschrieben FHEM-Absturz und neustarten vom Raspi.
Deinstallation der 1wire-Sensoren bringt übrigens keine Abhilfe. Fehler ist sauber reproduzierbar auch ohne 1wire. Logs sind noch inklusive der 1wire-Sensoren.
Also ist entweder bei meiner fhem.cfg was nicht OK oder das 1wire-Modul hat noch Einfluss und muss anders deinstalliert werden. Oder am RPI_GPIO-Modul stimmt was nicht -- kaum zu glauben. :-X
Hast du
modprobe w1-gpio
modprobe w1-thermin der
/etc/modules auskommentiert?
Ich vermute, das diese den GPIO blockieren.
Das natürlich noch abgefangen werden. Aber grundsätzlich sollte man sich für eine Funktion entscheiden ;)
füge in die 51_RPI_GPIO.pm
nach der Zeile 105
return "$name: failed to export pin gpio$hash->{RPI_pin}"; ein
das sollte dann so aussehen:
unless( $counter ) { #abbrechen wenn export fehlgeschlagen
Log3 $hash, 1, "$name: failed to export pin gpio$hash->{RPI_pin}";
return "$name: failed to export pin gpio$hash->{RPI_pin}";
}Dann sollte der define abgebrochen werden.
Hi Klaus,
die Lösung ist das Auskommentieren der w1-module in den /etc/modules.
VIELEN DANK dafür.
Soll ich so noch etwas testen?
Grüße
Matthias
Zitat von: Matzek83 am 20 Oktober 2014, 07:04:28
Hi Klaus,
die Lösung ist das Auskommentieren der w1-module in den /etc/modules.
VIELEN DANK dafür.
Soll ich so noch etwas testen?
Sehr schön
Ja, wenn du den Code aus meinem letzen Post mit aktiviertem 1-Wire mal testen könntest wäre das super.
Es dürfte dann einfach der GPIO4 nicht angelegt werden.
Grüße
Klaus
Hallo
ich bin absoluter Anfänger und will mir im Endefekt ein Thermostat mittels 1wire Temperatursensor und Relaiskarte zusammenbasteln mit meinen Raspberry.
Ich verwende die Module RPI_GPIO und Threshold. Grundsächlich funktioniert das soweit bei mir, aber die Schaltlogik ist invertiert d.h.
on ist off und off ist on.
define Relais RPI_GPIO 17
attr Relais active_low yes
attr Relais direction output
anscheinend funktioniert bei mir der Befehl active_low nicht.
WiringPi ist installiert aber unter der Shell habe ich das selbe Problem das an aus ist und umgekehrt
Ich bitte um Hilfe.
mfg
Zitat von: Maverick229 am 23 November 2014, 20:08:35
Hallo
ich bin absoluter Anfänger und will mir im Endefekt ein Thermostat mittels 1wire Temperatursensor und Relaiskarte zusammenbasteln mit meinen Raspberry.
Ich verwende die Module RPI_GPIO und Threshold. Grundsächlich funktioniert das soweit bei mir, aber die Schaltlogik ist invertiert d.h.
on ist off und off ist on.
define Relais RPI_GPIO 17
attr Relais active_low yes
attr Relais direction output
anscheinend funktioniert bei mir der Befehl active_low nicht.
WiringPi ist installiert aber unter der Shell habe ich das selbe Problem das an aus ist und umgekehrt
Ich bitte um Hilfe.
mfg
was zeigt denn:
cat /sys/class/gpio/gpio17/active_lowan?
Wenn du eine
1 zurückgeliefert bekommst. Dann sollte es funktionieren.
Vielleicht benötigst du keine invertierte logik. Lösche das Attribut active_low doch mal testweise
Hallo,
wenn ich den Befehl eingebe erhalte ich eine 0.
mfg
Zitat von: Maverick229 am 24 November 2014, 16:48:02
Hallo,
wenn ich den Befehl eingebe erhalte ich eine 0.
mfg
steht im Logfile was?
kann ich das Logfile auch in Fhem aufrufen? Wenn ja wie.
Das habe ich aus den Fhem Verzeichnis mittels Editor.
2014.11.23 19:41:06 4: Relais: using gpio utility to export pin
2014.11.23 19:41:06 1: Can't open file: Relais, active_low
2014.11.23 19:41:06 4: GPIO4: GPIO4_Define(Temp)
2014.11.23 19:41:06 4: GPIO4: GPIO4_Define(eg.vg.temp)
2014.11.23 19:41:07 4: Relais: direction ueber gpio utility einstellen
2014.11.23 19:41:07 4: Relais: direction gesetzt auf high
2014.11.23 19:41:07 1: Including ./log/fhem.save
2014.11.23 19:41:07 4: Relais: STATE kann auf off wiederhergestellt werden 2014$
2014.11.23 19:41:07 4: Relais: Pinlevel kann auf low wiederhergestellt werden 2$
2014.11.23 19:41:07 4: OUTPUT Relais: Pinlevel wiederhergestellt auf low
2014.11.23 19:41:07 4: Relais: state kann auf off wiederhergestellt werden 2014$
2014.11.23 19:41:07 4: OUTPUT Relais: state wiederhergestellt auf off
2014.11.23 19:41:07 4: OUTPUT Relais: STATE wiederhergestellt auf off (restoreO$
mfg
Zitat von: Maverick229 am 24 November 2014, 17:13:23
kann ich das Logfile auch in Fhem aufrufen? Wenn ja wie.
Das habe ich aus den Fhem Verzeichnis mittels Editor.
links unten: "Logflile" heist der Menüpunkt 8)
2014.11.23 19:41:06 1: Can't open file: Relais, active_lowzeigt schon das Problem.
Du hast keinen Schreibzugriff auf die Datei active_low.
Wie alt ist deine Raspbian installation?
Ist der user FHEM Mitglied der Gruppe gpio?
Den Menüpunkt habe ich nicht, sonst hätte ich das auch selber gefunden.
Muss ich wohl noch irgentwas aktivieren.
Die Installation müsste relativ aktuell sein, Sommer 2014 ein paar mal updates gemacht. Nur die Firmware könnte älter sein.
Ich habe Probleme die zu aktualisieren, jedes mal wenn ich das mache bootet der Raspi nicht mehr.
Ich vermute ja wie kann ich das testen, wie gesagt bin Anfänger.
mfg
Zitat von: Maverick229 am 24 November 2014, 18:05:42
Den Menüpunkt habe ich nicht, sonst hätte ich das auch selber gefunden.
Muss ich wohl noch irgentwas aktivieren.
Da muss nix aktiviert werden. Evtl kann man es deaktivieren.
Nutzt du ein stylesheetPrefix für FHEMWEB?
Hast du die anderen Menüpunkte wie
Commandref
Remote doc
Edit files
Select style
Event monitorZitat von: Maverick229 am 24 November 2014, 18:05:42
Die Installation müsste relativ aktuell sein, Sommer 2014 ein paar mal updates gemacht. Nur die Firmware könnte älter sein.
Ich habe Probleme die zu aktualisieren, jedes mal wenn ich das mache bootet der Raspi nicht mehr.
Wenn du ein Raspian Image von 2014 hast, sollte es funktionieren.
Ein "update" hast du in letzter Zeit auch in FHEM ausgeführt?
Zitat von: Maverick229 am 24 November 2014, 18:05:42
Ich vermute ja wie kann ich das testen, wie gesagt bin Anfänger.
was gibt denn
less /etc/groupaus?
Vermutlich nicht, denn ich weiss nicht was das ist.
Die aufgezählten Menüpunkte habe ich alle
Ein Update von FHem habe ich jeden Tag gemacht, gerade wieder.
der Befehl gibt aus
root@raspberrypi:~# less /etc/group
plugdev:x:46:pi
staff:x:50:
games:x:60:pi
users:x:100:pi
nogroup:x:65534:
libuuid:x:101:
crontab:x:102:
pi:x:1000:fhem
ssh:x:103:
ntp:x:104:
messagebus:x:105:
netdev:x:106:pi
input:x:999:pi
fuse:x:107:
lightdm:x:108:
bluetooth:x:109:
gpio:x:998:pi,fhem,Fhem
Fhem:x:1001:
(END)
mfg
hmm, ich würde eine Neuinstallation mit einem aktuellen Image wagen.
Ich habe mit Installationen von 2013, egal ob ich updates gemacht habe oder nicht, immer Probleme gehabt.
Auch der fehlende Logfile link ist seltsam.
Ich habe folgende Version
root@raspberrypi:~# cat /proc/version
Linux version 3.2.27+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #160 PREEMPT Mon Sep 17 23:18:42 BST 2012
die müsste ziemlich aktuell sein.
und die Grundinstallation erfolgte im August dieses Jahres.
Den originalen Logfilelink kann ich eventuell bei meinen Experimenten mit der fhem.cfg gelöscht haben, ohne das es mir aufgefallen ist.
mfg
Zitat von: Maverick229 am 24 November 2014, 21:44:31
Ich habe folgende Version
root@raspberrypi:~# cat /proc/version
Linux version 3.2.27+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #160 PREEMPT Mon Sep 17 23:18:42 BST 2012
die müsste ziemlich aktuell sein.
und die Grundinstallation erfolgte im August dieses Jahres.
die ist von 2012 (steht in der letzten Zeile)
wann bzw. wo hast Du die runtergeladen?
ich habe die:
Linux version 3.10.25+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014
und die ist von Anfang 2014
von der originalseite http://www.raspberrypi.org
was ist denn da schief gelaufen. Dann werde ich wohl wirklich alles Platt machen müssen.
Mist.
Jetzt weiss ich wieder was da schiefgelaufen ist. Mein Raspberry ist inkompatibel mit dem aktuellen Image bzw Update, wenn ich das installiere bootet der nicht mehr.
Ich verwende jetzt ein Image vom Juni 2014 damit funktioniert mein Relais korrekt
mfg
Zitat von: Maverick229 am 13 Dezember 2014, 09:41:34
Jetzt weiss ich wieder was da schiefgelaufen ist. Mein Raspberry ist inkompatibel mit dem aktuellen Image bzw Update, wenn ich das installiere bootet der nicht mehr.
Komisch, die Images sollten abwärtskompatibel sein.
Hallo,
bei mir lassen sie die GPIO´s von FHEM aus nicht schalten aber über einen Shell-Befehl lassen sie sich schalten, vllt. könnt ihr mir ja helfen.
wiringPi ist installiert, FHEM und Raspian sind aktuell.
Logfile:
Zitat2014.12.16 09:15:55 1: Can't open file: Pin3, value
2014.12.16 09:15:55 1: Pin3: readout of Pinvalue fail
config:
Zitatdefine Pin3 RPI_GPIO 2
attr Pin3 direction output
attr Pin3 poll_interval 5
attr Pin3 active_low yes
Ist fhem Mitglied der Gruppe gpio?
Anscheinend schon:
Zitatroot@raspberrypi:~# cat /etc/group
.
.
.
gpio:x:1003:pi,fhem
Zitat2014.12.16 08:14:27 0: Server started with 69 defined entities (version $Id: fhem.pl 7124 2014-12-05 07:10:20Z rudolfkoenig $, os linux, user fhem, pid 14625)
Zitatroot@raspberrypi:/sys/class/gpio/gpio2# ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Dez 16 09:45 active_low
-rwxrwx--- 1 root gpio 4096 Dez 17 00:24 direction
-rwxrwx--- 1 fhem dialout 4096 Dez 16 09:45 edge
drwxrwx--- 2 root gpio 0 Dez 16 09:45 power
lrwxrwxrwx 1 root gpio 0 Dez 16 09:45 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dez 16 09:45 uevent
-rwxrwx--- 1 fhem dialout 4096 Dez 16 09:45 value
was gibt denn
cat /proc/versionaus?
Zitat von: Bigsonic1 am 17 Dezember 2014, 08:35:39
root@raspberrypi:/sys/class/gpio/gpio2# ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Dez 16 09:45 active_low
-rwxrwx--- 1 root gpio 4096 Dez 17 00:24 direction
-rwxrwx--- 1 fhem dialout 4096 Dez 16 09:45 edge
drwxrwx--- 2 root gpio 0 Dez 16 09:45 power
lrwxrwxrwx 1 root gpio 0 Dez 16 09:45 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dez 16 09:45 uevent
-rwxrwx--- 1 fhem dialout 4096 Dez 16 09:45 value
die Gruppe dialout klingt nach einer alten Raspbian Version.
Du kannst auch fhem testweise zur Gruppe dialout hinzufügen.
Ich habe fhem zur Gruppe dialout hinzugefügt, aber keine besserung..
cat /proc/version
gibt raus:
Zitatroot@raspberrypi:~# cat /proc/version
Linux version 3.12.28+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #709 PREEMPT Mon Sep 8 15:28:00 BST 2014
versuche das ganze mal mit gpio22
auf gpio2 ist der I2C Bus, wenn die I2C module geladen sind dann blockieren die vielleicht den GPIO
Mit gpio22 das selbe spiel.
Wäre es besser wenn ich das ganze System neu aufsetze?
Zitat von: Bigsonic1 am 17 Dezember 2014, 12:14:15
Mit gpio22 das selbe spiel.
Wäre es besser wenn ich das ganze System neu aufsetze?
hast du nachdem du fhem in die gruppe dialout hinzugefügt hast mal das pi neu gestartet?
es ist seltsam, von den rechten her sollte es gehen
eine Neuinstallation kann natürlich helfen
ja ich habe immer <shutdown restart> in der fhem Konsole eingegeben.
Jetzt hab ich über Putty neugestartet und jetzt geht es, komisch??? ;D
Vielen vielen Dank!!!!
Zitat von: Bigsonic1 am 17 Dezember 2014, 12:43:36
ja ich habe immer <shutdown restart> in der fhem Konsole eingegeben.
Jetzt hab ich über Putty neugestartet und jetzt geht es, komisch??? ;D
Vielen vielen Dank!!!!
bitte bitte
das ist nicht komisch, shutdown restart ist nur für FHEM, aber die Rechteänderung erfordert einen kompletten Systemneustart.
...aber allemal besser als eine komplette Neuinstallation ;)
Hallo Klaus,
nachdem auf meinem RPi B+ fhem mit RPI_GPIO problemlos läuft, habe ich mich nun dran gegeben, das ganze mal auf einem nagelneuen Banana Pi Pro zum Laufen zu bringen. Die Pro-Banane hat das gleiche GPIO-Layout wie der RPi B+. Allerdings darf nicht das original wiringPi installiert werden sondern die Alternative von https://github.com/LeMaker/WiringBP .
Die Binary gpio klappt. Sie liegt in /usr/local/bin und hat root:root mit gesetztem Sticky-Bit - also wie bei der Standardinstallation auf einem RPi auch. fhem ist Mitglied der Gruppen gpio und dialout.
Allerdings sehen bei Anwendung die Rechte anders aus:
drwxrwx--- 2 root gpio 0 Dez 18 13:12 .
drwxr-xr-x 61 root root 0 Dez 18 13:12 ..
-rwxrwx--- 1 root gpio 4096 Dez 18 13:12 export
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpio17 -> ../../devices/platform/gpio-sunxi/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpio18 -> ../../devices/platform/gpio-sunxi/gpio/gpio18
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpio21 -> ../../devices/platform/gpio-sunxi/gpio/gpio21
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
-rwxrwx--- 1 root gpio 4096 Dez 18 13:12 unexport
Bis dahin alles gut. Aber dann:
bananapi@fhem /sys/class/gpio $ cd gpio17
bananapi@fhem /sys/class/gpio/gpio17 $ ls -la
insgesamt 0
drwxr-xr-x 3 root root 0 Dez 18 13:12 .
drwxr-xr-x 6 root root 0 Dez 18 13:12 ..
-rw-r--r-- 1 root root 4096 Dez 18 13:12 active_low
lrwxrwxrwx 1 root root 0 Dez 18 13:16 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Dez 18 13:12 direction
-rw-r--r-- 1 fhem dialout 4096 Dez 18 13:12 edge
drwxr-xr-x 2 root root 0 Dez 18 13:16 power
-rw-r--r-- 1 root root 4096 Dez 18 13:16 pull
lrwxrwxrwx 1 root root 0 Dez 18 13:12 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Dez 18 13:12 uevent
-rw-r--r-- 1 fhem dialout 4096 Dez 18 13:12 value
Die Folge ist, dass fhem bspw. u.a. die Datei active_low nicht beschreiben kann. Aber ich kann sie auch mit sudo nicht verändern - nach sudo su (also richtig als root) schon.
Da ist also noch irgendwo der Wurm drin und ich werde versuchen, dem auf den Grund zu gehen.
Hi Ralli,
Zitat von: Ralli am 18 Dezember 2014, 13:19:59
nachdem auf meinem RPi B+ fhem mit RPI_GPIO problemlos läuft, habe ich mich nun dran gegeben, das ganze mal auf einem nagelneuen Banana Pi Pro zum Laufen zu bringen.
Kannst du bitte mal bei folgenden Ports testen ob diese als Input beim B+ funktionieren?:
GPIO 4 - PIN 7
GPIO 5 - PIN 29
GPIO 6 - PIN 31
GPIO 7 - PIN 26
GPIO 8 - PIN 24Beim Kollegen IPPhoner2b bleibt der value immer 1 egal was er an den Pin anlegt. Mich würde interessieren ob es sich bei dir auch so verhält.
Zitat von: Ralli am 18 Dezember 2014, 13:19:59
Die Pro-Banane hat das gleiche GPIO-Layout wie der RPi B+. Allerdings darf nicht das original wiringPi installiert werden sondern die Alternative von https://github.com/LeMaker/WiringBP .
Die Binary gpio klappt. Sie liegt in /usr/local/bin und hat root:root mit gesetztem Sticky-Bit - also wie bei der Standardinstallation auf einem RPi auch. fhem ist Mitglied der Gruppen gpio und dialout.
Allerdings sehen bei Anwendung die Rechte anders aus:
drwxrwx--- 2 root gpio 0 Dez 18 13:12 .
drwxr-xr-x 61 root root 0 Dez 18 13:12 ..
-rwxrwx--- 1 root gpio 4096 Dez 18 13:12 export
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpio17 -> ../../devices/platform/gpio-sunxi/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpio18 -> ../../devices/platform/gpio-sunxi/gpio/gpio18
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpio21 -> ../../devices/platform/gpio-sunxi/gpio/gpio21
lrwxrwxrwx 1 root gpio 0 Dez 18 13:12 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
-rwxrwx--- 1 root gpio 4096 Dez 18 13:12 unexport
Bis dahin alles gut. Aber dann:
bananapi@fhem /sys/class/gpio $ cd gpio17
bananapi@fhem /sys/class/gpio/gpio17 $ ls -la
insgesamt 0
drwxr-xr-x 3 root root 0 Dez 18 13:12 .
drwxr-xr-x 6 root root 0 Dez 18 13:12 ..
-rw-r--r-- 1 root root 4096 Dez 18 13:12 active_low
lrwxrwxrwx 1 root root 0 Dez 18 13:16 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Dez 18 13:12 direction
-rw-r--r-- 1 fhem dialout 4096 Dez 18 13:12 edge
drwxr-xr-x 2 root root 0 Dez 18 13:16 power
-rw-r--r-- 1 root root 4096 Dez 18 13:16 pull
lrwxrwxrwx 1 root root 0 Dez 18 13:12 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Dez 18 13:12 uevent
-rw-r--r-- 1 fhem dialout 4096 Dez 18 13:12 value
Die Folge ist, dass fhem bspw. u.a. die Datei active_low nicht beschreiben kann. Aber ich kann sie auch mit sudo nicht verändern - nach sudo su (also richtig als root) schon.
Da ist also noch irgendwo der Wurm drin und ich werde versuchen, dem auf den Grund zu gehen.
Ja das scheint leider ein Manko des BananenKernels zu sein. Wurde hier (http://forum.fhem.de/index.php/topic,29245.0.html) etwas beleuchtet.
Der export eines GPIO über /sys/class/gpio/export legt den gpio ausschließlich mit rootrechten an.
Das gpio Tool passt wenigstens die Rechte von value und edge an.
Das Exportieren der GPIO und Rechteändern in der rc.local sollte aber gehen, oder?
Um sudo nutzen zu können muss dein aktueller user Mitglied der entsprechenden Guppe sein, evtl. liegt es daran das sudo nicht will.
Wie auch immer, super ist das ganze nicht. Dazu müssten die gpio Kernelmodule angepasst werden.
Grüße
Klaus
Hallo Klaus,
mit folgenden Einträgen in der rc.local klappt es zumindest mit den Output-Pins:
echo 17 > /sys/class/gpio/export
echo 21 > /sys/class/gpio/export
echo 18 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/platform/gpio-sunxi/gpio
chown -R fhem:root /sys/class/gpio
Bei den als Input definierten Pins keine Chance. Mit gpio readall sehe ich Statusänderungen, in fhem kommen sie aber nicht an.
Auf dem B+ kann ich erst später testen.
Zitat von: Ralli am 18 Dezember 2014, 15:15:43
Hallo Klaus,
mit folgenden Einträgen in der rc.local klappt es zumindest mit den Output-Pins:
echo 17 > /sys/class/gpio/export
echo 21 > /sys/class/gpio/export
echo 18 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/platform/gpio-sunxi/gpio
chown -R fhem:root /sys/class/gpio
Bei den als Input definierten Pins keine Chance. Mit gpio readall sehe ich Statusänderungen, in fhem kommen sie aber nicht an.
Um mal kurz zusammenzufassen:
- mit der wiringpi alternative geht es grundsätzlich (input/output interrupt) nur der active_low will nicht
- wenn du es über die rc.local machst dann funktionieren output pins aber input geht nicht
steht bei den inputs was im logfile?
wie sind die rechte der dateien?
Bei den Inputs:
Can't open file: GPIO21, edge
(Datei ist nicht vorhanden).
bananapi@fhem /sys/class/gpio/gpio21 $ ls -la
insgesamt 0
drwxr-xr-x 3 fhem gpio 0 Dez 18 15:29 .
drwxr-xr-x 6 fhem gpio 0 Dez 18 15:29 ..
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 active_low
lrwxrwxrwx 1 fhem gpio 0 Dez 18 15:29 device -> ../../../gpio-sunxi
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 direction
drwxr-xr-x 2 fhem gpio 0 Dez 18 15:29 power
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 pull
lrwxrwxrwx 1 fhem gpio 0 Dez 18 15:29 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 uevent
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 value
Zitat von: Ralli am 18 Dezember 2014, 16:05:25
Bei den Inputs:
Can't open file: GPIO21, edge
(Datei ist nicht vorhanden).
bananapi@fhem /sys/class/gpio/gpio21 $ ls -la
insgesamt 0
drwxr-xr-x 3 fhem gpio 0 Dez 18 15:29 .
drwxr-xr-x 6 fhem gpio 0 Dez 18 15:29 ..
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 active_low
lrwxrwxrwx 1 fhem gpio 0 Dez 18 15:29 device -> ../../../gpio-sunxi
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 direction
drwxr-xr-x 2 fhem gpio 0 Dez 18 15:29 power
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 pull
lrwxrwxrwx 1 fhem gpio 0 Dez 18 15:29 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 uevent
-rw-r--r-- 1 fhem gpio 4096 Dez 18 15:29 value
Vielleicht liegt es daran, das GPIO21 nicht interruptfähig ist.
Bei GPIO17 scheint es diese Datei ja zu geben.
Nichtsdestotrotz sollte der Input funktionieren. Müsstest halt pollen. Den Pinstatus lesen kannst du doch?
Mit der Binary ja - mit fhem nein, auch nicht manuell ausgelöst.
was passiert, wenn du das in FHEM eingibst?
{`cat /sys/class/gpio/gpio21/value`}
Er gibt eine 1 zurück. ... aber immer, egal, ob Spannung anliegt oder nicht.
Ich kann auch im Dateisystem keine Änderung irgendwo erkennen. Ich sehe den geänderten Pinlevel immer nur über die gpio-Binary.
Zitat von: Ralli am 19 Dezember 2014, 10:23:30
Er gibt eine 1 zurück. ... aber immer, egal, ob Spannung anliegt oder nicht.
Ich kann auch im Dateisystem keine Änderung irgendwo erkennen. Ich sehe den geänderten Pinlevel immer nur über die gpio-Binary.
:-\ seltsam
vielleicht funktionieren diese Pins generell nicht im userspace
Oder mom mal, als Output Modus funktionieren sie?
Korrekt - wenn sie vorher mit den Eintragungen in rc.local versehen wurden. Aber bei Inputs geht nix, auch nicht, wenn vorher in rc.local bearbeitet.
Zusammengefasst: mit der gpio-Binary geht alles (läuft ja schließlich mit SUID), ohne gpio-Utility nur Probleme. fhem in die root-Gruppe bringt auch nichts.
Ich habe mal https://github.com/WiringPi/WiringPi-Perl eingebunden, habe auch fhem so weit, dass mit use wiringpi in myUtils keine Fehlermeldungen erscheinen, wenn ich daraus Funktionen aufrufe, hatte bisher allerdings auch damit keinen Erfolg.
mit wiring pi werden aber die interrupts auch nicht funktionieren
das rpi_gpio Modul sollte aber wenigstens die Grundfunktionen abbilden
es nutzt doch, wenn es Probleme mit den Rechten gibt, das gpio utility