Problem mit Auslesen eines GPIO-Pins in 99_myUtils

Begonnen von ChHerrm, 13 August 2015, 19:11:12

Vorheriges Thema - Nächstes Thema

ChHerrm

Hallo!
Ich habe momentan das Problem, dass ich einen GPIO-Pin über FHEM nicht ausgelesen bekomme. Das Ziel ist, dass ich dauerhaft nebenbei den True-Zustand des Pins feststelle und daraufhin ein Python-Skript ausführe. Bisher habe ich es weder in der Config-Datei geschafft noch über 99_myUtils.

Aktuell sieht es folgendermaßen in der 99_myUtils-Datei aus: sub
Alarmpin_auslesen()
{
  my ($ALARM) = {system('sudo gpio read 29')};
  if (($ALARM) == 1)
  {
    system('sudo python2 /opt/fhem/log/SerielleBefehle/Alarm.py&');;
  }
}

Hierfür bekomme ich auch keine Fehlermeldung, es wird aber auch nicht ausgeführt. Wie genau muss ich diese Funktion in der cfg-Datei aufrufen damit es ständig durchlaufen wird?

Kann mir jemand dabei helfen? :-\ Was ich an Material in anderen Forumsbeiträgen gefunden habe, lief in meinem Fall nicht so richtig, daher habe ich inzwischen keine Idee dafür mehr :(

ChHerrm

Okay vielleicht nochmal besser formuliert und inzwischen etwas anders versucht:

In der 99_myUtils.pm:

sub
Alarmpin_auslesen($)
{
  my ($ALARM) = @_;
  $ALARM = system('sudo gpio read 29');;
  if (($ALARM) == 1)
  {
    system('sudo python2 /opt/fhem/log/SerielleBefehle/Alarm.py&');;
  }

}



In der fhem.cfg dann eingesetzt:

define Alarmmeldung dummy
define TEST notify Alarmmeldung:* { Alarmpin_auslesen($ALARM);; }


In welcher der Dateien die Anweisung umgesetzt wird ist mir eigentlich egal, hauptsache der Pinzustand wird abgefragt und bei Bedarf dann das Pythonskript ausgeführt. Hat niemand eine Idee dazu?

Wzut

und wie soll der dummy denn dein notify triggern ?
Ich würde :
a. den dummy und die sub Alarmpin_auslesen in der 99_myUtils rauswerfen
b. mit dem Modul RPI_GPIO den Pin überwachen, das notify auf den high/low state dieses device hetzen und das externe Skript auch direkt darin aufrufen
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bergadler

aktuelles FHEM auf Raspberry B+, FHEM von fhem.de V.5.7, CUL868 V1.57, (6x FHT80B+ FHTTK, div. IT,div. FS20,Harmony Hub)

ChHerrm

Okay ich habe das jetzt versucht anders umzusetzen mit Hilfe des Threads, RPI_GPIO und ohne 99_myUtils. Die Schritte:
Auf dem Raspberry Pi 2:
echo "21" > sys/class/gpio/export
echo "in" > /sys/class/gpio/export



FHEM in der fhem.cfg-Datei:
define Alarmpin RPI_GPIO 21
attr Alarmpin direction input
attr Alarmpin restoreOnStartup yes
get Alarmpin
define Alarmmerker notify Alarmpin:high {system('sudo python2 /opt/fhem/log/SerielleBefehle/Alarm.py&');;}


Dann bekomme ich aber die Fehlermeldung "Current Value for Alarmpin". Wie muss ich das verbessern? Funktioniert das überhaupt per get?

Wzut

wozu das get ?
Du hast doch das wunderschöne Attribut interrupt , das weckt schon dein notify wenn es Zeit ist :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Puschel74

Ausserdem hat ein get in der Konfig nichts zu suchen.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

ChHerrm

Okay danke für die Hinweise. Leider läuft es aber immer noch nicht. Wenn ich das Folgende eingebe, ist danach nicht mal mehr FHEM erreichbar (seit ich "interrupt both" ergänzt habe). Erst muss ich FHEM in der Shell stoppen und nochmal starten. Die Pinbezeichnung des GPIO21 bezieht sich auf die Darstellung dieser Seite, durchgezählt also Pin 40: http://www.element14.com/community/docs/DOC-73950/l/raspberry-pi-2-model-b-gpio-40-pin-block-pinout
Sollte also denke ich auch stimmen von der Bezeichnung her. Also was stimmt am folgenden Code noch immer nicht?

define Alarmpin RPI_GPIO 21
attr Alarmpin direction input
attr Alarmpin interrupt both
attr Alarmpin restoreOnStartup yes
define Alarmmerker notify Alarmpin:high {system('sudo python2 /opt/fhem/log/SerielleBefehle/Alarm.py&');;}

Wzut

Dann fang doch ersteinmal klein an und lasse interrupt und restoreOnStartup weg , nutze statt dessen ein kurzes Intervall wie z.B. 5
Für das Modul gibt es auch einen eigenen Fred : http://forum.fhem.de/index.php/topic,16519.0.html
Ob dein GPIO21 eine Sonderrolle hat kann ich nicht sagen, habe keinen Pi2 auf dem Basteltisch, d.h. ich muss mich an die Pin Nr. in der commandref des RPI_GPIO Moduls halten.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ChHerrm

Hm bisher gibt's noch immer keinen Erfolg zu verzeichnen, obwohl das doch eigentlich keine soo große Hürde sein kann :-\ Habe jetzt wie in dem anderen Thread und der Referenz erwähnt mit:

echo 29 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/virtual/gpio/*
chown -R fhem:root /sys/class/gpio/*


in die Datei /etc/rc.local zu schreiben, da es ja eigentlich fast nur noch an den Rechten hängen kann. Aber auch danach nichts.

In der fhem.cfg siehts folgendermaßen aus (sicherheitshalber sowohl mit GPIO Nr. 21 als auch 29 darin enthalten):

define Alarmpin RPI_GPIO 29
attr Alarmpin direction input
attr Alarmpin poll_interval 1
define Alarmmerker notify Alarmpin:low {system('sudo python2 /opt/fhem/log/SerielleBefehle/Alarm.py&');;}


Egal ob ich den Pegel high oder low erkennen möchte, tut sich nichts. Im Terminal wird der Pegelwechsel aber erkannt.
Das Logfile gibt mir folgenden Fehler:

2015.08.18 10:52:59 5: Alarmpin, in fileaccess: value
2015.08.18 10:52:59 1: Can't open file: Alarmpin, value
2015.08.18 10:52:59 1: Alarmpin: readout of Pinvalue fail

Was gibt es sonst noch zu verbessern oder mal auf anderem Weg zu versuchen? Liegt es noch immer an Rechten? FHEM hat bei mir eigentlich alle Rechte, kann ja auch die Skripte etc ausführen.

Wzut

Zitat von: ChHerrm am 18 August 2015, 10:55:22
chown -R fhem:root /sys/devices/virtual/gpio/*

---snipp ---
2015.08.18 10:52:59 5: Alarmpin, in fileaccess: value

gibt es bei mir unter /sys/devices/virtual/ nichts, schau doch bitte mal mit "ls -l /sys/class/gpio" nach wie die Dateien wirklich heissen und welche Rechte vorhanden sind.
Ich kann bei mir z.B. den owner root.gpio gar nicht ändern, statdessen ist der User fhem  in der Gruppe gpio (falls dein fhem unter dem User fhem User läuft)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ChHerrm

Also unter "ls -l /sys/class/gpio" bekomme ich:

lrwxrwxrwx 1 root gpio 0 Aug 18 10:51 gpio29 -> ../../devices/soc/3f200000.gpio/gpio/gpio29

Aber wie es mit der Information jetzt weitergeht, weiß ich nicht so recht :-\

Wzut

Zitat von: Wzut am 18 August 2015, 11:57:54
statdessen ist der User fhem  in der Gruppe gpio (falls dein fhem unter dem User fhem User läuft)

wie packt man unter Linux einen User in eine Gruppe ?
Tante Goggle kennt bestimmt ne Antwort ...
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ChHerrm

Hm auch danach habe ich es nicht zum Laufen bekommen, aber nun einen anderen Weg für die Umsetzung genutzt und das Ganze ohne IO-Pins gebastelt. Funktioniert jetzt auch, das Thema hat sich somit erledigt. Trotzdem danke für die Hilfe! :)

kurtklaiber

Ich hatte ein ähnliches Problem. Da sieht mir ganz nach einem Problem der Berechtigung aus. Ich konnte das Problme wie folgt lösen:

Achtung: Auch wenn das Kommando chmod 660 ... durch chmod 666 ... (Zugriffsrecht fuer alle) wird kein Zugriffsrecht für others zugelassen. Wenn andere Benutzeraccounts als der Standarduser "pi" auf die GPIO-Pins zugreifen sollen, müssen Sie zusätzlich in die Gruppe gpio eingetragen werden:

sudo usermod -a -G gpio <Username>

Nähere Informationen dazu findest du hier:

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

Viel Glück