Hier, nun endlich mein erstes Modul (das ohne die Hilfe von Rudi nicht zustande gekommen wäre) :)
Ist mittlerweile im SVN trunk committed und per update installierbarWenn Interesse besteht würde ich das Modul gern zum FHEM Paket hinzufügen. Was sind die Voraussetzungen dafür?
Es bietet Zugriff auf die GPIOs der Raspberrys. Sie können als Ein- und Ausgang konfiguriert werden. Wenn als Eingang genutzt, lässt sich der Pegel per poll interval abfragen oder auch bei Pegeländerung ein Interrupt auslösen, der die Readings sofort ändert.
Der Eingang lässt sich weiterhin als Toggleinput verwenden. Dabei kann ein Taster angeschlossen werden und bei jedem Tastendruck ändert sich der Pegel.
Vorbereitung: (ich habe bei mir HiPi installiert, aber die Datei "hipi-expin" sollte ausreichend sein, bitte um Rückmeldung ob es geht)
Auf GPIO Pins wird im Modul über sysfs zugegriffen. Die Dateien befinden sich unter /system/class/gpio und können nur mit root erreicht werden. Eine Möglichkeit, das zu umgehen, ist mit udev die Rechte von /system/class/gpio zu ändern:
Wenn sich bereits die HiPi Perl Bibliothek auf dem System befindet, kann auf den download von hipi-expin verzichtet werden.
herunterladen von http://code.google.com/p/hipi-perl-raspberrypi/source/browse/tags/RELEASE_0.33/userbin/hipi-expin (http://code.google.com/p/hipi-perl-raspberrypi/source/browse/tags/RELEASE_0.33/userbin/hipi-expin) und ablegen unter /usr/local/bin/Rechte dieser Datei anpassen: sudo chmod rwxr-xr-x /usr/local/bin/hipi-expinden Nutzer fhem zur Gruppe gpio hinzufügen: sudo adduser fhem gpioNeue udev Datei anlegen: sudo nano/etc/udev/rules.d/97_gpio.rulesdiese Zeile einfügen: KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/usr/local/bin/hipi-expin gpio /sys%p"reboot
jetzt sollte es möglich sein, mit normalem Nutzer auf die GPIO's zuzugreifen (um folgende Zeilen zu testen muss sich der user mit dem man testet auch in der Gruppe gpio befinden)
echo "17" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio17/direction
echo "1" > /sys/class/gpio/gpio17/valueWenn es keine Zugriffsfehler gibt dann ist alles Ok.
Befehlsreferenz:
Define
define <name> RPI_GPIO <GPIO number>
Beispiele:
define Pin12 RPI_GPIO 18
attr Pin12
attr Pin12 poll_interval 5
Set
set <name> <value>
value ist dabei einer der folgenden Werte:
Für GPIO der als output konfiguriert ist
off
on
toggle
Die set extensions werden auch unterstützt.
Für GPIO der als input konfiguriert ist
readval
Beispiele:
set Pin12 off
set Pin11,Pin12 on
Get
get <name>
Gibt "high" oder "low" entsprechend dem aktuellen Pinstatus zurück und schreibt den Wert auch in das reading Pinlevel
Attributes
direction
Setzt den GPIO auf Ein- oder Ausgang.
Standard: input, gültige Werte: input, output
interrupt
kann nur gewählt werden, wenn der GPIO als Eingang konfiguriert ist
Aktiviert Flankenerkennung für den GPIO
bei jedem interrupt Ereignis werden die readings "Pinlevel" und "state" aktualisiert
Zusätzlich wird bei falling und rising ein Reading "Toggle" angelegt und bei jedem dieser Ereignisse invertiert (dieses Reading wird mit dem Attribut toggletostate auf das reading "state" kopiert)
Standard: none, gültige Werte: none, falling, rising, both
poll_interval
Fragt den Zustand des GPIO regelmäßig ensprechend des eingestellten Wertes in Minuten ab
Standard: -, gültige Werte: decimal number
toggletostate
Funktioniert nur bei auf falling oder rising gesetztem Attribut interrupt
Wenn auf "yes" gestellt wird bei jedem Triggerereignis das state reading invertiert
Standard: no, gültige Werte: yes, no
pud_resistor
ohne FunktionNun testet mal schön und teilt mir eure Meinung mit 8)
Die nächste Woche bin ich im Urlaub, also nicht wundern wenn bis zum 26.11 keine Antwort kommt.
edit: Anhang gelöscht
ZitatEine Möglichkeit, das zu umgehen, ist mit udev die Rechte von /system/class/gpio zu ändern
udev heißt udev, weil es Änderungen in /dev/... vornimmt und nicht in /system/...
Was Du da vorschlägst, widerspricht nach meiner (selbstverständlich unmassgeblichen) Meinung sämtlichen allgemeingültigen Standards zum Thema "Zugriff auf Systemverzeichnisse unter Linux"
Wenn du eine Idee hast wie man es anders machen könnte, immer her damit :D
Ich habe keine Ahnung von der Rechteverwaltung in Linux. Die udev Geschichte habe ich mir von der HiPi Bibliothek abgeschaut.
Ist es denn ein Sicherheitsproblem es so zu machen? Ich hatte es so verstanden, das bei Zugriffsversuch auf das Gpio Verzeichnis einfach nur die Rechte dieses Verzeichnisses und der Unterpfade angepasst werden.
Ist es nicht das selbe Verfahren, das du auch beim I2C Drucksensor nutzt?
Hallo zusammen,
ich habe das Problem mit der Berechtigung direkt mit Udev gelöst (fhem läuft bei mir auf dem RPi):
Neue Datei anlegen (/etc/udev/rules.d/51-gpio.rules) und folgendes eintragen:
SUBSYSTEM=="subsystem", KERNEL=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R fhem:dialout /sys%p'"
Update:
SUBSYSTEM=="subsystem", KERNEL=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R fhem:dialout /sys/class/gpio/*'"
SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R fhem:dialout /sys/class/gpio/*'"
Udev neu starten:
service udev restart
Schauen ob die änderungen funktioniert haben:
ls -la /sys/class/gpio/
Allerdings werden, durch dein Modul neu angelegte Ordner, noch nicht in ihrer Berechtigung geändert: (Manueller workaround):
sudo udevadm test --action=add /class/gpio
Und jetzt zu deinem Modul:
Erstens:
Ich würde es gerne dazu benutzen um den Status eines GPIO Ports zu überwachen (high/low). Das Modul zeigt zwar den PIN Status (high/low) korrekt an, allerdings ändert sich der State nicht und es wird leider auch kein Event generiert. Daher kann ich auch nicht mit einem notify darauf reagieren.
Funktioniert doch :)
Zweitens:
Im Log wird beim DEFINE und beim Ändern eines Attributes immer die Meldung "2013.11.30 10:38:53 1: Can't open file: test, direction" angezeigt. Wahrscheinlich nicht normal oder?
Ansonsten schonmal ein großes Danke für deine Arbeit!
MfG
Matthias
Hi Matthias,
zu1(wenn auch schon erledigt :)):
Wenn du attr <name> interrupt both nutzt dann wird der state Wert sofort geändert.
zu2:
Deine Fehlermeldung kann ich bei mir nicht nachvollziehen.
Sie bedeutet, das die Datei /sys/class/gpio/gpioN/direction nicht geschrieben werden konnte.
Bei dir funktioniert es trotzdem, da diese Datei beim anlgen des GPIO standardmäßig den Inhalt "in" hat, also auf Input eingestellt ist.
Aber in diese Datei schreibe ich beim define erstmal zur Sicherheit ein "in" für Input.
Bei attr lese ich sie auch fast immer mit aus, da ich die Attribute gegenchecken muss. (z.B. kann Interrupt nur im zusammenhang mit Input funktionieren)
Kannst du bitte die Rechte der Datei prüfen? Vermutlich klappt mit dem udev nochwas nicht.
Grüße
Klaus
Hi Klaus,
stimmt. Die Dateien und Unterverzeichnisse gehören immer noch dem ROOT. Da muss ich am udev noch was ändern.
MfG
Matthias
man könnte auch einfach die Dateizugriffe mit sudo machen, ich bin nicht sicher, was die beste Lösung ist
Hi,
man könnte auch wiringPi nutzen: http://wiringpi.com/download-and-install/
Das dazugehörige cmd line tool "gpio" kann auch ohne root genutzt werden.
Zitat von: Dennis B. am 10 Dezember 2013, 22:52:17man könnte auch wiringPi nutzen:
Das dazugehörige cmd line tool "gpio" kann auch ohne root genutzt werden.
Genau deshalb habe ich diesen Weg bei der Umsetzung meines PiFace Moduls gewählt, das ja auch nix anderes macht, als GPIO zu lesen/setzen
Zitat von: Dennis B. am 10 Dezember 2013, 22:52:17
man könnte auch wiringPi nutzen: http://wiringpi.com/download-and-install/
Das dazugehörige cmd line tool "gpio" kann auch ohne root genutzt werden.
Wieso eigentlich nicht. Ich habe das mal implementiert.
Also zuerst http://wiringpi.com/download-and-install/ (http://wiringpi.com/download-and-install/) installieren:
sudo apt-get update
sudo apt-get upgrade
http://wiringpi.com/download-and-install/
git clone git://git.drogon.net/wiringPi
cd wiringPi
./build
Das Attribut
pud_resistor funktioniert jetzt und ich habe noch die Attribute
debounce_in_ms zum entprellen von Schaltern, sowie
restoreOnStartup zum wiederherstellen des Pinzustandes nach restart.
So, ich habe auf die schnelle noch eine Zählfunktion hinzugefügt.
Wenn das Attribut interrupt auf rising oder falling steht, dann wird ein Reading namens Conter angelegt, welches bei jedem Interruptereignis eins hochzählt.
Ich werde das ganze noch konfigurierbar machen, das man den Zählwert auch im State haben kann. Und ein Multiplikator ist sicher auch nicht verkehrt.
Ideen/Wünsche sind erbeten ;)
Grüße
Klaus
Die letzen Versionen hatten noch einen Fehler: Pins funktionierten generell nicht als Output wenn die HiPi Bibliothek incl. udev nicht eingerichtet sind.
Mir ist es erst jetzt aufgefallen, als ich udev entfernt habe.
Diese Version sollte jetzt ausschließlich mit WiringPi funktionieren.
kleine Fehlerkorrektur für die SetExtension (konnte vorher bei der Nutzung als Output zum Absturz von FHEM kommen)
Hi,
danke für deine Mühe und Zeit die du opferst !!
Ich würde das ganze mit einem PIFACE verwenden wollen, das krieg ich aber nich hin. Das PiFace selbst funktioniert schon (mit gpio Commands via Console)
Das FHEM hab ich auch soweit hinbekommen, nur schalten will es nicht. ich habe foldende defines gmacht :
define Pin12 RPI_GPIO 18
attr Pin12 direction output
attr Pin12 loglevel 5
define Pin11 RPI_GPIO 17
attr Pin11 direction output
define Pin13 RPI_GPIO 27
attr Pin13 direction output
define Pin15 RPI_GPIO 22
attr Pin15 direction output
define Pin16 RPI_GPIO 23
attr Pin16 direction output
define Pin18 RPI_GPIO 24
attr Pin18 direction output
define Pin22 RPI_GPIO 25
attr Pin22 direction output
define Pin7 RPI_GPIO 4
attr Pin7 direction output
aber nicht eine einzige LED brennt wenn ich einschalte....mit gpio readall sehe ich auch keine änderung des Zustandes
Mir ist aber auch das Mapping der physikalischen Anschlüsse des Piface zu den GPIO Ports ein Rätsel, vielleicht kann wer was dazu sagen.
Danke vorab !!!
mfg
bb10
Die Config sieht ok aus.
Hast du die neuste Modulversion installiert?
Steht im Logfile entsprechendes drin?
Du kannst auch einmal schauen wie im GPIO Verzeichnis die Rechte vergeben sind.
Das sollte so aussehen:
-rw-r--r-- 1 fhem dialout 4096 Dez 18 21:47 edge
-rw-r--r-- 1 fhem dialout 4096 Dez 18 21:47 value
Hi,
schnelle Antwort :), danke!!!
ad 1 : es ist das neueste Modul
ad 2: im FHEM Logfile steht nichts was nur annnähernd mit gpio oder ports zu tun hat. ich glaub FHEM sprchicht nicht zu dem Modul :)
ad 3: die Berechtigungen scheinen ok
root@raspberrypi:/sys/devices/virtual/gpio/gpio4# ls -la
insgesamt 0
drwxr-xr-x 3 root root 0 Dez 18 22:29 .
drwxr-xr-x 11 root root 0 Dez 18 20:56 ..
-rw-r--r-- 1 root root 4096 Dez 18 22:55 active_low
-rw-r--r-- 1 root root 4096 Dez 18 22:29 direction
-rw-r--r-- 1 fhem dialout 4096 Dez 18 22:29 edge
drwxr-xr-x 2 root root 0 Dez 18 22:53 power
lrwxrwxrwx 1 root root 0 Dez 18 22:29 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Dez 18 22:29 uevent
-rw-r--r-- 1 fhem dialout 4096 Dez 18 22:29 value
mfg
bb10
Ja, das zeigt auch, das Modul exportiert die Pins richtig.
Und wenn nix im Log steht dann musses eigentlich auch Funktionieren. 8)
Schalte mal in FHEM den GPIO4 (also Pin 7 auf dem P1 Connector) auf on und führe danach in der Konsole:
cat /sys/class/gpio/gpio4/value
aus.
Danach auf off und das gleiche machen.
hi,
bei "ON" kommt als value 1, bei "OFF" 0, trotzdem brennt die LED nicht (anders als beim PIFACE Emulator).
schaut also gut aus ...
mfg
bb10
Also das Modul funktioniert erstmal bei Dir, Glückwunsch ;D
Was ist denn ein PIFACE Emulator?
Ich vermute, das du die falschen Pins verwendest.
GPIO4 z.B. ist auf Pin7 am P1 Pfostenstecker (da du es genauso beschriftet hast, vermute ich das ich dir nix neues erzähle)
Aber kann es sein, das das Piface nicht die GPIO's des Raspberry verwendet, sondern einen I2C Portexpander nutzt?
Dann würde mein Modul nicht funktionieren. Das ist ausschließlich für die Raspberry GPIO's gedacht.
Hi,
ja, ich sehe das auch so, dass es funktioniert. Vielen Dank jedenfalls !!
Ich hab von hier http://wiringpi.com/dev-lib/piface/ rausgelesen, dass es einen Portexpander benutzt, da hast du recht. Trotzdem glaube ich, dass man das zum Laufen kriegt (ich vielleicht nicht :() wenn man die Adressierung anpasst. Wenn man die SPI Treiber ladet, lässt es sich mit gpio commands ansprechen.
Ist so beschrieben und funktioniert auch so :
gpio -p ...
The optional -p flag causes the gpio program to assume there is a PiFace board fitted to the Rasberry Pi and subsequent commands are interpreted as pins on the PiFace. Note: Pins on the PiFace are 200 through 207 for both reading and writing, with pins 208 through 215 reading the state of the output latch register (ie. you can read the state of the output pins)
Da das auf anhieb funktioniert hat ( gpio -p write 200 1 # first relais "on", gpio -p write 201 0 # second relais "off", glaube ich dass man das hinbekommt, wenn man die Tabelle im Modul erweitert, aber ich bin leider ein blutiger Anfänger.....
Für mich schwer zu verstehen ist, dass die physikalisch getrennten Input und Output Connectors dieselbe Adresse haben, nur die Richtung (In oder Out) gibt vor, welche Anschlüsse zu verwenden sind. Vielleicht hilft das jemandem weiter...
mfg
bb10
Hast du mal das Modul PIFACE ausprobiert?
Grundsätzlich lässt es sich integrieren. Einfach erweitern ist nicht, denn... das Modul arbeitet anders als du denkst.
Das Programm gpio von WiringPi wird nur verwendet, um die GPIO Pins des Pi zu exportieren, sprich die Verzeichnisse .../gpiox/ und die darin vorhandenen Dateien anzulegen. Das direkte exportieren der GPIOs funktioniert nur mit root Rechten. Daher der Umweg über das gpio Programm.
Der eigentliche Portzugriff erfolgt über die Perl Bibliothek IO::File. Da ich nur so Interruptsteuerung machen kann.
Interruptsteuerung mit dem Piface funktioniert nicht, da der auf dem Piface genutzte Portextender im I2C Bus als Slave funktioniert und per polling abgefragt wird.
Zitat von: backbone10 am 19 Dezember 2013, 11:05:09
Für mich schwer zu verstehen ist, dass die physikalisch getrennten Input und Output Connectors dieselbe Adresse haben, nur die Richtung (In oder Out) gibt vor, welche Anschlüsse zu verwenden sind. Vielleicht hilft das jemandem weiter...
Das verstehe ich nicht, was hat die selbe Adresse?
Hast du hier schon geschaut?
http://forum.fhem.de/index.php/topic,13236.0.html (http://forum.fhem.de/index.php/topic,13236.0.html)
Hi,
danke für deine rasche Antwort. Jetzt hast du mir leider meine Illusion genommen :o , da hab ich scheinbar das falsche Board gekauft.
Der Satz mit den Connectors hat sich nur auf das PIFACE bezogen ich meinte damit, dass man mit
gpio -p read 200 den Wert des linken Taster auslest aber mit
gpio - p write 200 x das erste Relais steuert.
Taster und Relais haben natürlich andere physikalische connectoren.....
Den Link hab ich mir angesehen, da hab ich noch nicht alles verstanden...
danke jedenfalls..
mfg
bb10
Hallo,
ich versuche mich auch daran die gpio's zum laufen zu bekommen. Leider habe ich folgende Fehlermeldungen im Log:
2013.12.22 00:26:19 1: Can't open file: Mischer_auf, value
2013.12.22 00:26:20 1: Can't open file: Mischerzu, value
in der Config steht:
define Mischer_auf RPI_GPIO 27
attr Mischer_auf direction output
define Mischerzu RPI_GPIO 22
attr Mischerzu direction output
Die Zugriffsrechte scheinen zu stimmen, auf der Konsole kann ich ohne sudo schalten.
cat /sys/class/gpio/gpio4/value
bringt keine Änderung
Ich habe HiPi und wiringpi installiert. Außerdem habe ich Udev eingestellt wie matzefisi es beschrieben hat.
Ich hoffe Ihr könnt mir helfen.
Hallo Fireflyer,
Hipi wird nicht mehr gebraucht.
Das udev auch nicht mehr. Vermutlich liegt es am udev. Mazefisi hat selbst geschrieben, das es nicht geht....immer bis zuende lesen ;)
Lösche die udev Regeln und versuche nochmal.
Can't open file: Mischer_auf, value
bedeutet in Deinem Fall, das auf:
/sys/class/gpio/gpio27/value
nicht geschrieben werden kann.
Mit ls -l /sys/class/gpio/gpio27 kannst Du die Rechte überprüfen. Ddie Datei value sollte fhem gehören.
Was willst Du eigentlich mit cat /sys/class/gpio/gpio4/value bezwecken? Du nutzt doch GPIO27 und 22, richtig?
Moin,
gpio4 ist ein copy & past Fehler ;-) Hab schon die richtigen gpio benutzt.
Werde mich nachher um die Rechte kümmern. Außer mit udev hab ich aber noch nichts gemacht. Werden dann wohl noch root gehören. Wie ändere ich das ggf? Die entsprechenden gpio-Verzeichnise werden automatisch angelegt, das hat sofort funktioniert.
Gruß FireFlyer
P.S. Mit dem Handy geschrieben...
So folgendes kam heraus:
$ ls -l /sys/class/gpio/gpio22/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Dez 22 02:17 active_low
-rwxrwx--- 1 root gpio 4096 Dez 22 02:17 direction
-rwxrwx--- 1 root gpio 4096 Dez 22 02:17 edge
drwxrwx--- 2 root gpio 0 Dez 22 02:17 power
lrwxrwxrwx 1 root gpio 0 Dez 22 02:17 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dez 22 02:17 uevent
-rwxrwx--- 1 root gpio 4096 Dez 22 02:17 value
und ohne udef
$ ls -l /sys/class/gpio/gpio22/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Dez 22 10:58 active_low
-rwxrwx--- 1 root gpio 4096 Dez 22 10:58 direction
-rwxrwx--- 1 root gpio 4096 Dez 22 10:58 edge
drwxrwx--- 2 root gpio 0 Dez 22 10:58 power
lrwxrwxrwx 1 root gpio 0 Dez 22 10:58 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dez 22 10:58 uevent
-rwxrwx--- 1 root gpio 4096 Dez 22 10:58 value
erst sudo adduser fhem gpio
hat die Lösung gebracht. Werde jetzt mal HiPi wieder entfernen. Danke für die schnelle Hilfe!
Hast du nach dem entfernen von udev neu gestartet?
Es sieht, nach Deinen zugriffsrechten, so aus, als ob udev noch aktiv ist.
Value sollte diese Rechte haben:
-rw-r--r-- 1 fhem dialout 4096 Dez 18 22:29 value
Die Rechte werden im Modul vom Programm gpio, das bei wiringpi dabei ist, angelegt.
Es kann sein, das udev diese überschreibt.
Hallo,
ich hatte zwischen beiden Listings rebootet. Aber es funktioniert jetzt. Das HiPi bin ich zwar nicht wieder los geworden, weil ich kein uninstall-skript gefunden habe, oder reicht es die Programmordner zu löschen?
Frohe Weihnachten!
Modul ist jetzt ins SVN eingecheckt. Sollte beim nächsten update verfügbar sein.
Da fehlt ein l 8)
- feature: new module 51_RPI_GPIO.pm added (kausw)
Ich fühle mich überwacht ;)
habs korrigiert
Zitat von: betateilchen am 05 Januar 2014, 11:40:38
Da fehlt ein l 8)
Ich hab grade RPI_GPIO in mein fhem eingebaut und funktioniert super. Danke erstmal für die Mühe.
Ich hätte noch eine Idee / Wunsch:
Ich würd gern einen oder mehrere Taster an die GPIO-Ports hängen und damit verschiedene Lichter an und aus schalten.
Möchte dabei eine Logik einbauen, die bei einem kurzen Tastendruck ein Licht einschaltet, das nach ca. 30 Sekunden wieder ausgeht und bei einem langen Tastendruck (größer 2 sec) das Licht dauerhaft einschaltet.
Ist sowas mit RPI_GPIO denkbar? Oder evtl. so etwas wie "Doppelklick" und "Einfachklick" auf nen Taster?
Zitat von: uwe.bart am 08 Januar 2014, 18:22:46
Ich hätte noch eine Idee / Wunsch:
Ich würd gern einen oder mehrere Taster an die GPIO-Ports hängen und damit verschiedene Lichter an und aus schalten.
Möchte dabei eine Logik einbauen, die bei einem kurzen Tastendruck ein Licht einschaltet, das nach ca. 30 Sekunden wieder ausgeht und bei einem langen Tastendruck (größer 2 sec) das Licht dauerhaft einschaltet.
Ist sowas mit RPI_GPIO denkbar? Oder evtl. so etwas wie "Doppelklick" und "Einfachklick" auf nen Taster?
Über den langen Tastendruck habe ich auch schon nachgedacht, das müsste sich machen lassen. Ich schaue mir das am Wochenende mal an.
Da würde dann aber mithilfe eines Timers laufen. D.h. ich könnte ein weiteres Reading einbauen, das, sobald eine Taste länger als eine Sekunde gedrückt ist, auf on geht.
Doppelklick geht vielleicht auch auf diese Weise, aber dann müsste man zwischen zwei einfachklicks mind. 1s warten.
Der Timer kann minimal nur 1s.
So, habe eine neue Version eingecheckt. Morgen kann sie über update geholt werden.
Wenn das Attribut interrupt auf both gestellt ist, dann wird beim ersten setzten des GPIO auf high (für länger als 1s) das reading Longpress angelegt und auf on gesetzt. Beim loslassen wird es wieder auf off gesetzt.
Wenns benötigt wird kann man die Erkennungszeit noch einstellbar machen und auch das reading Longpress auf State ausgeben.
Für Doppelklick habe ich noch keine Idee wie ich ihn sinnvoll umsetze (soll ein reading bei doppelklick toggeln, oder kurz auf on gehen oder...).
Da brauche ich noch konkrete Beispiele.
Danke, hast du toll gemacht.
Ich hab damit mal ein Treppenhauslicht realisiert.
- normaler Tastendruck = Licht einschalten und nach 30 sek. geht es von selbst aus
- langer Tastendruck = Licht geht an und bleibt an, bis man es wieder ausschaltet
Hier mal der Ausschnitt aus der fhem.cfg:
Zitat
# GPIO14
# Dummy-Schalter definieren
define gpio14 dummy
attr gpio14 room GPIO
# den Dummy überwachen
define n_gpio14 notify gpio14:toggle {\
if(OldValue('gpio14') eq 'off'){\
fhem("set gpio14 on");;\
fhem("define a_tmp_gpio14 at +00:00:30 set gpio14 off");;\
}elsif(OldValue('gpio14') eq 'on'){\
fhem("set gpio14 off");;\
}\
}
attr n_gpio14 room GPIO
# RPI_GPIO für pin 14 definieren
define pin0014 RPI_GPIO 14
attr pin0014 debounce_in_ms 50
attr pin0014 direction input
attr pin0014 interrupt both
attr pin0014 pud_resistor down
attr pin0014 room GPIO
# das on-Event von pin 14 überwachen
define n_pin0014 notify pin0014:on {Log 1,$EVENT;;\
fhem("set gpio14 toggle");;\
}
attr n_pin0014 room GPIO
# das Longpress-Event von pin 14 überwachen und den Timer damit löschen
define n_pin0014_longpress notify pin0014:Longpress.*on {\
Log 1,$EVENT;;\
fhem("delete a_tmp_gpio14");;\
}
attr n_pin0014_longpress room GPIO
Der Dummy steht in Vertretung für dein Treppenlicht?
Wenn du vorhast es über einen GPIO Output schaltest kannst du auch die setextensions verwenden:
set myoutputpin on-for-timer 30
Dieser Timer lässt sich jederzeit mit "set myoutputpin on/off" abbrechen.
Hab ich tatsächlich vor, bin aber noch nicht dazu gekommen mich mit RPI_GPIO als output zu beschäftigen. Danke für den Tip.
Hallo,
kann mir jemand verraten, woher die Gruppe "gpio" kommt? Das "sudo adduser fhem gpio" bringt die Meldung, dass die Gruppe gpio
nicht existiert.
Mit manuellem Setzen der Rechte scheint alles zu funktionieren.
Gruß Wolfgang
Gute Frage, wenn ich mich recht erinnere sollte die Gruppe gpio beim Raspbian von Anfang an mit dabei sein.
Zitat von: klausw am 20 Januar 2014, 16:39:29
Gute Frage, wenn ich mich recht erinnere sollte die Gruppe gpio beim Raspbian von Anfang an mit dabei sein.
Achso, und ich habe die ganze Zeit die Installation von wiringPi als Erzeuger in Verdacht gehabt. Ich habe meinen Pi mit wheezy aufgesetzt, da ist (oder war) die Gruppe nicht vorhanden.
Ist aber nicht schlimm, läuft ja jetzt nach manueller Anpassung der Dateien auch so.
Vielen Dank auf jeden Fall für das tolle Engagement. Ich hatte mir bisher mit eigenem c-Code geholfen, das war etwas holprig.
Noch ein Wunsch: Es wäre super, wenn das Modul die event-on-change-reading bzw. event-on-update-reading Attribute unterstützen könnte. das würde für die entstehenden Events beim Pollen sinnvoll sein.
Bisher hatte ich mit meiner eigenen Konstruktion das Problem, das irgendwann keine Interrupts mehr durchkamen. Dann rettet das Pollen den korrekten Zustand.
Gruß Wolfgang
Hallo,
also bei mir gibt's die Gruppe nicht.
Ich habe die Platine von Locutus auf dem RPI laufen und da wird auch WiringPi benutzt:
http://forum.fhem.de/index.php/topic,14156.msg118637.html#msg118637 (http://forum.fhem.de/index.php/topic,14156.msg118637.html#msg118637)
pi@fhemraspi ~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users netdev input
Gruß StefanP
Hallo zusammen,
ich habe gerade nochmal einen SD Karte mit der Raspbian Version 2013-12-20-wheezy-raspbian.img bespielt.
pi@raspberrypi ~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users netdev input spi gpio
Die Gruppe gpio ist bei mir vorhanden.
@Wolfgang: wie hast du die Anpassung manuell vorgenommen?
Zitat von: fruemmel am 20 Januar 2014, 17:13:50
Noch ein Wunsch: Es wäre super, wenn das Modul die event-on-change-reading bzw. event-on-update-reading Attribute unterstützen könnte. das würde für die entstehenden Events beim Pollen sinnvoll sein.
Ist eingebaut und sollte beim nächsten Update dabei sein.
Zitat von: klausw am 20 Januar 2014, 23:10:41
Hallo zusammen,
ich habe gerade nochmal einen SD Karte mit der Raspbian Version 2013-12-20-wheezy-raspbian.img bespielt.
pi@raspberrypi ~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users netdev input spi gpio
Die Gruppe gpio ist bei mir vorhanden.
Hallo Klaus,
mein wheezy ist deutlich älter (ca. Q2 2013), vielleicht liegt es daran.
Zitat von: klausw am 20 Januar 2014, 23:10:41
@Wolfgang: wie hast du die Anpassung manuell vorgenommen?
Ist eingebaut und sollte beim nächsten Update dabei sein.
Ich habe in allen Verzeichnissen unter /sys/devices/virtual/gpio/ bei den Dateien edge und value den owner auf fhem gesetzt. Damit funktioniert es bei mir.
Zum Thema event-on-change-reading etc:
Zitat von: klausw am 20 Januar 2014, 23:10:41
Ist eingebaut und sollte beim nächsten Update dabei sein.
Super, vielen Dank!!
Gruß Wolfgang
Zitat von: fruemmel am 21 Januar 2014, 09:32:59
Ich habe in allen Verzeichnissen unter /sys/devices/virtual/gpio/ bei den Dateien edge und value den owner auf fhem gesetzt. Damit funktioniert es bei mir.
Das machst du mit einem Script nach jedem reboot?
Hallo Klaus,
habe gerade dein Modul ausprobiert. SPITZE ;D
Jetzt brauche ich nicht mehr umständlich mit sripten und notifys rumzuwerkeln.
Wenn ich das richtig verstehe setzt du WiringPi auf?
Wäre es dann auch möglich die PWM Funktion zu integrieren? ::)
Dann wären alle Funktionen der GPIO's unterstützt.
Vielen Dank
Olaf
Zitat von: klausw am 21 Januar 2014, 10:01:48
Das machst du mit einem Script nach jedem reboot?
Ich habe gerade einen reboot gemacht (vom Pi), bei mir "überlebt" fhem als owner der Dateien.
Ok, das ist interessant. Verstehen kann ich's aber nicht. Die Dateien existieren ja praktisch nicht. Sie werden beim booten erzeugt.
Aber Hauptsache es geht ;D
Hallo Klaus,
neben meiner Frage, ob es möglich die PWM-Funktion mit einzubauen habe ich noch eine weitere:
Wäre es möglich bei der Interrupt-Funktion (both) die Impulsdauer in den Readings anzuzeigen?
Mein Ziel wäre es die Dauer eines Impulses zu messen um HC-SR04 Ultraschall Sensoren einzubinden.
hier ein Beispiel: http://www.gtkdb.de/index_36_2272.html
Man könnte dann über einen GPI-Out einen Impuls auf den Triggereingang geben und bekommt über Echo auf einen Interrupteingang einen Impuls mit der Dauer in Abhängigkeit von der Entfernung zurück.
Vielen Dank
Olaf
EDIT: Mangels Perl kann ich leider noch nicht viel programmieren. Habe hier jedoch weitere Infos gefunden:
http://www.tinkerforge.com/de/doc/Software/Bricklets/DistanceUS_Bricklet_Perl.html#distance-us-bricklet-perl-examples
Hallo Olaf
Dein Beitrag war mir durch die Lappen gegangen ...so als letzer auf einer Seite ;)
Zitat von: ollir am 21 Januar 2014, 11:01:57
Wenn ich das richtig verstehe setzt du WiringPi auf?
jein, ich nutze nur das gpio Tool von wiringpi um die GPIO's als Normaluser exportieren zu können.
Danach greife ich über das Dateisystem auf die Ports zu. Auf diesem Weg funktioniert das mit der Software PWM nicht. Auch das gpio Tool kann keine PWM Werte setzen. Ich habe noch ein weiteres Programm gefunden, welches angeblich Software PWM auf allen Ports ermöglicht. Dazu brauche ich aber eine ruhige Minute.
Das mit der Impulsdauer kann ich versuchen, am We habe ich denke ich etwas Zeit.
Hast du so ein Modul? Ich bin nicht sicher, ob das in FHEM schnell genug geht. Da kommt es schließlich auf ein paar ms an.
Grüße
Klaus
Hallo Klaus,
leider habe ich noch kein HC-SR04 Modul.
Werde gleich mal ein paar bestellen.
Ich dachte mir man könnte mit der steigenden Flanke einen Timer starten und diesen mit der fallenden Flanke stoppen. Die abgelaufene Timerzeit dann als Rückgabewert.
Die Berechnung der Distanz könnte im UserReading geschehen.
Wann und wie oft der HC-SR04 messen soll, wird über den Trigger Eingang gesteuert.
Für seltene Messungen (z.B. Zizterne) einen GPI_Out über FHEM kurz Schalten.
Für stetige und schnelle Messungen (z.B. Abstandsmessung Haustüre) müsste man ca. 20ms Impulse auf den Trigger Eingang erzeugen.
Vielen Dank
Olaf
Für 1cm musst du auf 3ms auflösen können ... ich weiss nicht wie die Looptime vom FHEM ist, aber das erscheint mir sportlich.
Organisiere lieber erstmal nur eins ;)
Die Tür kannst du doch mit einem Kontakt machen, oder nimm ein PIR Modul ... gibts für 5V und kostet keine 5€
Hi,
ich habe zwei Fragen, für die ich trotz SUFU und Wiki nicht lösen konnte :)
1.Hat schon jemand das Attribut "active_low" erfolgreich eingesetzt ? ich habs probiert, bei den Readings in FHEM ändert sich aber nichts bei mir. Oder ich verstehe das ganze falsch, ich hab eine kleine Schaltung angeschlossen, die Level High liefert, wenn der Zustand off ist - vielleicht ist es nicht für das gemacht.....
2. Die Zeilen im Modul selbst sind mir nicht klar
Bei interrupt both wird ein reading Longpress angelegt, welches auf on gesetzt wird solange der Pin länger als 1s gedrueckt wird<br>
Bei "falling" und "rising" wird ein reading Toggle angelegt, das bei jedem Interruptereignis toggelt und das Reading Counter, das bei jedem Ereignis um 1 hochzählt..
Ist das so richtig verstanden, dass bei "both" keine Counter mitgezählt werden?? - wenn ja wie heisst der Counter genau ??
danke
bb10
Zitat von: backbone10 am 26 Januar 2014, 21:16:22
1.Hat schon jemand das Attribut "active_low" erfolgreich eingesetzt ? ich habs probiert, bei den Readings in FHEM ändert sich aber nichts bei mir. Oder ich verstehe das ganze falsch, ich hab eine kleine Schaltung angeschlossen, die Level High liefert, wenn der Zustand off ist - vielleicht ist es nicht für das gemacht.....
Doch, dafür isses gemacht. Allerdings funktioniert es wirklich nicht mehr. Das Attribut hatte ich bei der Umstellung auf WiringPi übersehen. Werde ich beim nächsten Update mit reinbringen.
Zitat von: backbone10 am 26 Januar 2014, 21:16:22
Bei interrupt both wird ein reading Longpress angelegt, welches auf on gesetzt wird solange der Pin länger als 1s gedrueckt wird<br>
Bei "falling" und "rising" wird ein reading Toggle angelegt, das bei jedem Interruptereignis toggelt und das Reading Counter, das bei jedem Ereignis um 1 hochzählt..
Ist das so richtig verstanden, dass bei "both" keine Counter mitgezählt werden?? - wenn ja wie heisst der Counter genau ??
Die Frage verstehe ich nicht. Der Counter heisst Counter :).
Der Counter zählt nur bei "falling" und "rising" bei entsprechendem Ereignis um eins hoch. Bei "both" würde jeder Tastendruck doppelt zählen...macht meiner Meinung nach keinen Sinn
Toggle funktioniert auch nur bei "falling" und "rising". Bei "both" macht es auch keinen Sinn, sonst müsste man noch ein weiteres Attribut einfügen, um festzulegen bei welchem Flankenwechsel der Toggel umgeändert werden soll.
Der Interrupt ist nur Mittel zum Zweck.
Hi klausw,
danke für die prompte Antwort.
Punkt 1 ist damit klar.
Punkt 2 habe ich aufgrund meiner bescheidenen Erfahrung schlecht dargestellt. Ich hab mir überlegt, den Counter als Zähler für die Einschaltereignisse zu verwenden, auch wenn ich ihn durch2 dividiere. Muß noch ein wenig spielen damit, sorry..
mfg
bb10
gern geschehen
wenn bei dir Einschalten = wechsel von 0 auf 1 am GPIO bedeutet, kannst du interrupt auf "rising" stellen und schon wird jedes Einschaltereignis gezählt. Du musst nix durch 2 dividieren.
Hallo ollir,
so ein HC-SR04 wäre absolut gut um einen Wassertank oder Oeltank zu überwachen .... Hast Du vor das Thema noch zu verfolgen?
Zitat von: Maergsche am 27 Januar 2014, 16:45:30
Hallo ollir,
so ein HC-SR04 wäre absolut gut um einen Wassertank oder Oeltank zu überwachen .... Hast Du vor das Thema noch zu verfolgen?
Ich habe Klaus's Modul mit einem Rückgabewert (gettimeofday welcher bis mircosekunden zurück gibt) bei der Interrupterkennung (Rising/Falling) ergänzt.
Ob es funktioniert werde ich sehen, wenn die Sensoren da sind.
Ich weis nur nicht in welchem Zeitfenter die Interrupterkennung reagiert.
Werde dran bleiben und berichten.
VG
Olaf
Zitat von: ollir am 27 Januar 2014, 19:29:25
Ich weis nur nicht in welchem Zeitfenter die Interrupterkennung reagiert.
Werde dran bleiben und berichten.
Ich habe auch mal testweise ein Reading eingefügt, welches die on Zeit darstellt.
Jetzt fehlt nur noch ein kurzer Impuls zum testen. Wenn Du es vor mir schaffst gib Bescheid und ich baue es ein.
Vermute aber das man nicht unter 100ms kommt.
Hallo Klaus,
mangels externen Generator kann ich die Funktion auch nicht genau testen. Zur Zeit gebe ich über einen GPI-Out einen Impuls aus.
Mit diesem komme ich auch nicht kleiner als ca. 100ms.
Ich denke es liegt aber an dem Ausgabe-Impuls der über FHEM ausgegeben wird.
Ich hoffe das mit einen Externen Impuls die Zeitangabe über Interrupt wesentlich kürzer und genauer funktioniert.
Würdest die Zeitangabe über HiPi::Interupt::Message ($msg->timestamp Returns an epoch timestamp in milliseconds for the message.) machen?
Evtl. ist dies noch genauer/schneller als im Modul selber über (gettimeofday)?
VG
Olaf
Hi Olli,
Zitat von: ollir am 28 Januar 2014, 11:35:29
Würdest die Zeitangabe über HiPi::Interupt::Message ($msg->timestamp Returns an epoch timestamp in milliseconds for the message.) machen?
Evtl. ist dies noch genauer/schneller als im Modul selber über (gettimeofday)?
HiPi nutze ich für das Modul nicht mehr. Es macht keinen Sinn, da für die Interruptfunktionen der Prozess geforkt werden muss und das hat im Zusammenhang mit FHEM nicht funktioniert. Ausserdem war die Vorarbeit für diese Bibliothek recht umständlich.
Ich werde versuchen die Interruptverarbeitung noch ein bisschen zu optimieren. Zum testen leihe ich mit einen Funktionsgenerator von Arbeit aus. Evtl. komme ich am We dazu.
Wenn das alles nichts hilft könntest Du ein zusätzliches Script schreiben, auf das Du von FHEM aus zugreifst. Ich hatte mal ein python script dafür getestet. Das lieferte einigermaßen brauchbare Werte.
Hallo Klaus,
die China-Lieferung ist schneller angekommen als gedacht.
Meine Änderungen an deinem Modul sind noch nicht zufrieden stellend.
Das im Internet zu findende Python script funktioniert jedoch sehr gut.
Kannst du mir evtl. deine Version zukommen lassen?
Ich habe noch ein HC-SR04 Modul übrig. Schicke mir einfach eine Mail mit Deiner Anschrift.
VG
Olaf
Hallo Olaf,
das minimum, welches ich hinbekomme sind um die 17ms, das entspricht fast 6m (müssten 3m Abstand sein)
Also zum Abstandsmessen ist das nicht brauchbar. Mehr lässt sich nicht rausholen, da der Interrupt von FHEM zurückgemeldet wird.
Man könnte es noch mit einer blockierenden Funktion probieren, aber alles andere als elegant.
Danke fürs Angebot, aber ich hatte mich auch schonmal so nen Modul bestellt.
Zitat von: backbone10 am 26 Januar 2014, 21:16:22
1.Hat schon jemand das Attribut "active_low" erfolgreich eingesetzt ? ich habs probiert, bei den Readings in FHEM ändert sich aber nichts bei mir. Oder ich verstehe das ganze falsch, ich hab eine kleine Schaltung angeschlossen, die Level High liefert, wenn der Zustand off ist - vielleicht ist es nicht für das gemacht.....
Ich wollte gerade das "active_low" Attribut reparieren. Allerdings funktioniert es bei mir.
In der Datei
/sys/class/gpio/gpio<Pinnummer>/active_low steht bei mit eine "1" wenn
active_low auf "yes" gesetzt ist
Wenn nicht, müsste ausserdem im Logfile:
Can't open file: <NAME>, active_low stehen
Könnt ihr das mal überprüfen, ob es bei euch geht?
Grüße
Klaus
Hallo Klaus,
vielen Dank für deine Mühe. Ich hatte es schon fast befürchtet.
Zur Zeit mache ich die Abstandsmessung über ein Pythonscripit, welches über einen AT-Job gestartet wird und über Telnet sein Ergebnis zurück im ein Dummy schreibt.
Vielen Dank
Olaf
Hi Olaf
Zitat von: ollir am 04 Februar 2014, 20:21:28
Zur Zeit mache ich die Abstandsmessung über ein Pythonscripit, welches über einen AT-Job gestartet wird und über Telnet sein Ergebnis zurück im ein Dummy schreibt.
Das ist sicher die beste Lösung.
FHEM ist dafür nicht gedacht.
Du kannst das Script hier gerne posten. Es gibt sicher noch einige Interessenten.
Mittelst du im Script eigentlich über mehrere Messungen und schmeißt die Abweicher raus?
Ich kann mich erinnern das, insbesondere bei höherer Prozessorlast, einige Messungen vollkommen daneben lagen.
Grüße
Klaus
Hallo Klaus,
ich mittlere von drei Messungen und gebe sie zurück.
Ab und zu habe ich Ausreißer nach oben.
Diese Messungen verwerfe ich, wenn sie größer als 400cm sind.
Werde die Tage mal alles zusammenschreiben und in's Forum schreiben.
Viele Grüße
Olaf
EDIT: Anleitung mit Externem Script: http://forum.fhem.de/index.php/topic,19812.0.html (http://forum.fhem.de/index.php/topic,19812.0.html)
ZitatIch wollte gerade das "active_low" Attribut reparieren. Allerdings funktioniert es bei mir.
In der Datei /sys/class/gpio/gpio<Pinnummer>/active_low steht bei mit eine "1" wenn active_low auf "yes" gesetzt ist
Wenn nicht, müsste ausserdem im Logfile:
Code: [Auswählen]
Can't open file: <NAME>, active_low
stehen
Könnt ihr das mal überprüfen, ob es bei euch geht?
Hi klausw,
bitte um Nachsicht, ich habs grad wieder probiert und nachdem ich die Rechte von "active_low" auf owner fhem - gruppe dialout gesetzt (644) habe funktioniert es auch bei mir. Bin noch beim Aufbau der Grundkenntnisse - geht leider alles sehr viel schwieriger als erwartet..
Update : jetzt hat aufeinmal wieder root/root die rechte und es zeigt wieder verkehrt an, weil in active_low eine 0 stand.
keine Ahnung warum das passiert ist, vielleicht bei einem reboot ?? Wie sollten die Berechtigungen sein ??
nochmal Update : das passiert bei mir leider dauernd, auch die Fehlermeldung im Log...
danke
bb10
danke nochmal
bb10
Zitat von: backbone10 am 09 Februar 2014, 20:22:09
Update : jetzt hat aufeinmal wieder root/root die rechte und es zeigt wieder verkehrt an, weil in active_low eine 0 stand.
keine Ahnung warum das passiert ist, vielleicht bei einem reboot ?? Wie sollten die Berechtigungen sein ??
nochmal Update : das passiert bei mir leider dauernd, auch die Fehlermeldung im Log...
Wenn Du die Rechte manuell änderst, dann sind sie nach einem Reboot wieder weg. Es sind ja keine wirklichen Dateien. Sie werden beim starten angelegt und geben Dir nur einfachen Zugriff auf die GPIO's über das Dateisystem.
Wenn es generell nicht geht (k.A. wieso das bei mit funktioniert) dann muss ich es anders implementieren. Das wird aber eine Weile dauern, da ich das Modul komplett umändern muss. Es ist nicht einfach mit einer Invertierung der Werte getan. Auch die Interrupts müssen angepasst werden.
Grüße
Klaus
vorerst könntest Du readingsProxy verwenden um einfach die Ports zu invertieren.
Zitat von: backbone10 am 09 Februar 2014, 20:22:09
bitte um Nachsicht, ich habs grad wieder probiert und nachdem ich die Rechte von "active_low" auf owner fhem - gruppe dialout gesetzt (644) habe funktioniert es auch bei mir. Bin noch beim Aufbau der Grundkenntnisse - geht leider alles sehr viel schwieriger als erwartet..
fängt ja jeder mal an :)
komisch ist es aber trotzdem
logge dich mal über ssh ein und gib folgendes ein:
id fhemdann solltest du sowas bekommen:
uid=999(fhem) gid=20(dialout) Gruppen=20(dialout),1003(gpio)
Nun gehe bitte nochmal in ein GPIO Verzeichnis, von einem GPIO den Du in FHEM definiert hast:
cd /sys/class/gpio/gpioN/und führe folgenden Befehl aus:
ls -lnun müsste es etwa so aussehen:
-rwxrwx--- 1 root gpio 4096 Feb 20 00:36 active_low
-rwxrwx--- 1 root gpio 4096 Feb 20 00:36 direction
-rwxrwx--- 1 root gpio 4096 Feb 20 00:36 edge
drwxrwx--- 2 root gpio 0 Feb 20 00:36 power
lrwxrwxrwx 1 root gpio 0 Feb 20 00:36 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Feb 20 00:36 uevent
-rwxrwx--- 1 root gpio 4096 Feb 20 00:36 value
Der User ist zwar root, aber die Gruppe ist gpio und alle Dateien haben Schreibrechte für die Gruppe. Somit sollte es funktionieren.
Teste das bitte mal und poste die Ergebnisse hier.
Grüße
Klaus
Hi,
danke dass du dir da ansiehst..
pi@raspberrypi:~$ id fhem
uid=999(fhem) gid=20(dialout) Gruppen=20(dialout)
pi@raspberrypi:/sys/class/gpio/gpio24$ ls -l
insgesamt 0
-rw-r--r-- 1 fhem dialout 4096 Feb 20 07:57 active_low
-rw-r--r-- 1 fhem dialout 4096 Feb 20 07:57 direction
-rw-r--r-- 1 fhem dialout 4096 Feb 20 07:57 edge
drwxr-xr-x 2 fhem dialout 0 Feb 20 07:48 power
lrwxrwxrwx 1 fhem dialout 0 Feb 20 07:48 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 fhem dialout 4096 Feb 20 07:48 uevent
-rw-r--r-- 1 fhem dialout 4096 Feb 20 07:41 value
pi@raspberrypi:/sys/class/gpio/gpio24$
das war aber nachdem ich die Berechtigungen manuell gesetzt habe.
Nach einem Neustart habe ich immer 0 in dem File und Root als Besitzer und Gruppe Root drin (und wie schon gesagt RW, Gruppe und andere RW)
Danke
bb10
der user fhem sollte auch in der Gruppe gpio sein
mit
sudo adduser fhem gpio
und neu starten
der Besitzer der Files ist root, das ist normal. Allerdings sollte die Gruppe auch bei Dir schon gpio sein.
nach dem Neustart bitte nochmal ls -l machen und hier posten, ich möchte wissen, ob alle Dateien die gleichen Rechte haben.
wenn dann wieder Nutzer und Gruppe root sind bitte folgendes als user pi versuchen:
/usr/local/bin/gpio export 8 in
wobei Pin und Richtung keine Rolle spielen
und dann von diesem Pin nochmals:
ls -l
Hi,
danke..
User hab ich hinzugefügt, dann reboot und
pi@raspberrypi /sys/class/gpio/gpio24 $ ls -l
insgesamt 0
-rw-r--r-- 1 root root 4096 Feb 20 18:15 active_low
-rw-r--r-- 1 root root 4096 Feb 20 18:15 direction
-rw-r--r-- 1 fhem dialout 4096 Feb 20 18:15 edge
drwxr-xr-x 2 root root 0 Feb 20 18:17 power
lrwxrwxrwx 1 root root 0 Feb 20 18:15 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Feb 20 18:15 uevent
-rw-r--r-- 1 fhem dialout 4096 Feb 20 18:15 value
pi@raspberrypi /sys/class/gpio/gpio24 $
dann das zweite
pi@raspberrypi /sys $ cd /sys/class/gpio/gpio24
pi@raspberrypi /sys/class/gpio/gpio24 $ ls
active_low direction edge power subsystem uevent value
pi@raspberrypi /sys/class/gpio/gpio24 $ ls -l
insgesamt 0
-rw-r--r-- 1 root root 4096 Feb 20 18:15 active_low
-rw-r--r-- 1 root root 4096 Feb 20 18:15 direction
-rw-r--r-- 1 fhem dialout 4096 Feb 20 18:15 edge
drwxr-xr-x 2 root root 0 Feb 20 18:17 power
lrwxrwxrwx 1 root root 0 Feb 20 18:15 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Feb 20 18:15 uevent
-rw-r--r-- 1 fhem dialout 4096 Feb 20 18:15 value
pi@raspberrypi /sys/class/gpio/gpio24 $ ^C
pi@raspberrypi /sys/class/gpio/gpio24 $ cd /sys/class/gpio/gpio8
pi@raspberrypi /sys/class/gpio/gpio8 $ /usr/local/bin/gpio export 8 in
pi@raspberrypi /sys/class/gpio/gpio8 $ ls -l
insgesamt 0
-rw-r--r-- 1 root root 4096 Feb 20 18:21 active_low
-rw-r--r-- 1 root root 4096 Feb 20 18:24 direction
-rw-r--r-- 1 pi pi 4096 Feb 20 18:20 edge
drwxr-xr-x 2 root root 0 Feb 20 18:21 power
lrwxrwxrwx 1 root root 0 Feb 20 18:20 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Feb 20 18:20 uevent
-rw-r--r-- 1 pi pi 4096 Feb 20 18:20 value
pi@raspberrypi /sys/class/gpio/gpio8 $
Jetzt ist Besitzer und Gruppe wieder root und in active_low steht wieder die 0..... :'(
mfg
bb10
Value und EDGE haben aber User und Gruppe übernommen. An so ein Verhalten kann ich mich noch erinnern. Nachdem Ende letzten Jahre meine Sdkarte abgeraucht ist, habe ich das Pi neu aufgesetzt. Seitdem scheint die Rechtevergabe etwas anders zu sein. Von wann ist Deine Pi Installation? Und wann hast du wiringpi installiert?
Hi,
den PI habe ich ca. im August aufgesetzt, wiringpi dann später, wird so ca. anfang dezember gewesen sein
Ich habe den PI öfters mit sudo apt-get update / upgrade aktualisiert.
Versionsnummern habe ich keine gefunden, soll ich wieder mal updaten und das nochmal probieren ? FHEM ist ganz uptodate..
danke
bb10
wenn ich das wüsste...
ich hätte als erstes wiringpi in Verdacht. Da ja bei Dir und mir die Gpio Dateien mit unterschiedlichen Rechten angelegt werden.
gpio -v
sagt bei mir:
gpio version: 2.13
und bei Dir?
Aber vielleicht liegt es auch an den Kerneltreibern.
cat /proc/version
bringt bei mir:
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
Hi,
genau das gleiche :(
soll ich mal was neu installieren ? wen ja, was und mit welchem user ?
mfg
bb10
puh, gute frage
hast Du eine 2. SD Karte?
Dann würde ich es komplett neu aufsetzten mit der aktuellen raspbian Version.
Ich habe letzte Wochen mein 2. Raspi neu aufgesetzt. Da hat es auch auf Anhieb funktioniert.
PS: ich habe alle installationen mit dem user pi gemacht
Hi,
kann ich hiermit bestaetigen. Funktioniert ;)
Danke
bb10
Ich komme mit dem Interrupt nicht weiter, was muß ich da noch konfigurieren?
Ich habe jetzt folgendes:
define Pin12 RPI_GPIO 18
attr Pin12 direction input
attr Pin12 interrupt falling
Egal was ich weiteres einstelle, der Zustand des PIN12 ändert sich in FHEM nicht.
Außerdem habe ich beobachtet, dass die CPU auf 100% geht, sobald ich den Interrupt einschalte.
Dabei gehen knapp 50% an perl und ebenfalls knapp 50% an startpar.
Letztendlich möchte ich mit dem Interrupt das lesen des MCP23017 per i2c auslösen.
Danke
Zitat von: Apollo am 27 März 2014, 14:36:44
Ich komme mit dem Interrupt nicht weiter, was muß ich da noch konfigurieren?
Ich habe jetzt folgendes:
define Pin12 RPI_GPIO 18
attr Pin12 direction input
attr Pin12 interrupt falling
Egal was ich weiteres einstelle, der Zustand des PIN12 ändert sich in FHEM nicht.
Außerdem habe ich beobachtet, dass die CPU auf 100% geht, sobald ich den Interrupt einschalte.
Dabei gehen knapp 50% an perl und ebenfalls knapp 50% an startpar.
Letztendlich möchte ich mit dem Interrupt das lesen des MCP23017 per i2c auslösen.
Danke
interrupt falling bedeutet, das bei fallender Flanke die werte aktualisiert werden
Da kannst natürlich du keine Veränderung von state sehen (da immer nur der low Pegel aktualisiert wird). Allerdings sollte sich die Zeit bei jedem Interrupt ändern. Pinlevel wird in diesem Fall nur bei einem reload aktualisiert.
Aber um ein notify zum auslesen des MCP... zu erzeugen reicht das.
Mit
interrupt both ändert sich state bei jedem Pegelwechsel.
Mit
interrupt both ändert sich
Wie lang bleibt die CPU denn auf 100%? Das habe ich mir noch nciht angeschaut
danke für deine schnelle Antwort.
Leider geht das auch mit both auch nicht. Der Pinlevel wird nur beim Reload der Detailseite aktualisiert, aber das macht es ja auch ohne den Interrupt-Eintrag.
Die 100% CPU bleiben so lange, bis ich den Interrupt-Eintrag wieder kösche, dann ist sofort 98% Idle.
Revision 1 oder 2 des RPI dürfe ja keinen unterschied machen, oder? (Ich hab die 1)
Zitat von: Apollo am 27 März 2014, 18:49:08
Leider geht das auch mit both auch nicht. Der Pinlevel wird nur beim Reload der Detailseite aktualisiert, aber das macht es ja auch ohne den Interrupt-Eintrag.
Genau, das beteutet aber schonmal das es grundsätzlich funktioniert
Zitat von: Apollo am 27 März 2014, 18:49:08
Die 100% CPU bleiben so lange, bis ich den Interrupt-Eintrag wieder kösche, dann ist sofort 98% Idle.
Was bedeutet löschen? Den Pin zurücksetzen? Oder ein Undefine?
Geht FHEM noch wenn du bei 100% bist?
Zitat von: Apollo am 27 März 2014, 18:49:08
Revision 1 oder 2 des RPI dürfe ja keinen unterschied machen, oder? (Ich hab die 1)
Das sollte egal sein ... bis auf die Tatsachem das einige GPIOs auf anderen Pins sitzen.
Wie alt ist Deine Raspbian Installation?
Ja eben, es geht ja grundsätzlich. Ich kann den Zustand des Pins auslesen oder ihn als Ausgang benutzen, nur das mit dem Interrupt will nicht.
Mit löschen meinte ich das Attribut "interrupt", entweder direkt auf der Detailseite mit "deleteattr", oder direkt in der fhem.cfg und save (das braucht nicht mal ein rereadcfg).
Erstaunlicherweise geht FHEM trotz der 100% CPU noch recht gut.
Raspbian ist das letzte (2014-01-07)
edit: das Log sagt auch nichts weiter
2014.03.27 20:52:56 5: Cmd: >define Pin12 RPI_GPIO 18<
2014.03.27 20:52:56 5: Loading ./FHEM/51_RPI_GPIO.pm
2014.03.27 20:52:56 5: Pin12: direction: input
2014.03.27 20:52:57 5: Cmd: >attr Pin12 direction input<
2014.03.27 20:52:57 5: Pin12: direction: input
2014.03.27 20:52:57 5: Cmd: >attr Pin12 interrupt both<
2014.03.27 20:52:57 5: Datei: /sys/class/gpio/gpio18/value, FH: IO::File=GLOB(0x1ebfc08), EXCEPT_FD: 8, akt. Wert: 1
2014.03.27 20:52:57 5: Pin12: interrupt: both
Ja, das Log sieht normal aus.
Die Perl Version ist auch aktuell?
Ich habe noch mal update/upgrade von Raspbian gemacht, somit sollte perl aktuell sein.
Komischer weise ist jetzt die hohe CPU-Last weg. Geändert hat sich beim Interrupt aber nichts.
welches Modul ist eigentlich das aktuellere?
das im trunk
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/
oder das im Board
http://forum.fhem.de/index.php/topic,16519.msg115933.html#msg115933
Ich werde mal die Tage Raspbian noch mal komplett neu aufzusetzen, eventuell ist ja doch irgendwo etwas quer.
per update im FHEM solltest Du die aktuelle Version bekommen
das ist dann das im trunk
Ich habe gerade in einem anderen Beitrag gelesen, dass die pins mit 3,3V arbeiten. ich hab für mein Steckboard die 5V vom RPI abgegriffen, kann das mein Interrupt-Problem sein?
Beim I2C-Bus müsste das ja egal sein, da die ICs ja mit low-Pegel arbeiten und die Pullups auf dem RPI sind.
Zitat von: Apollo am 28 März 2014, 02:02:33
Ich habe gerade in einem anderen Beitrag gelesen, dass die pins mit 3,3V arbeiten. ich hab für mein Steckboard die 5V vom RPI abgegriffen, kann das mein Interrupt-Problem sein?
Beim I2C-Bus müsste das ja egal sein, da die ICs ja mit low-Pegel arbeiten und die Pullups auf dem RPI sind.
Das steht auch in der connmandref drin.
Mit 5V kannst du Dir die Pins zerschießen, vielleicht ist das auch schon passiert.
Wie der Controller dann reagiert ist schwer zu sagen.
Hast Du noch einen Pin, der keine 5V gesehen hat? Dann solltest Du es an diesem noch einmal probieren.
Manche I2C Module haben aber auch Pullups drauf. Da würde ich aufpassen.
Ja, erst lesen wäre besser. Meistens mach ich das leider anders herum.
Ich hatte einen 4,7k Widerstand gegen 5V, das hat der Pin denke ich überlebt.
Ich hab jetzt auch noch Pin7 (GPIO4) dran, aber ist das selbe.
Wenn ich das pollen lasse (Attr:poll_interval) dann geht es ( in Minutenabständen :( ), nur nicht per Interrupt.
Momentan hab ich ja nur ein Steckboard dran und da hab ich die Pullups komplett weg gelassen.
Wenn es dann so funktioniert, wie es soll, dann baue ich mir die Module auch selber.
Das die hohe CPU-Last weg ist, stimmt übrigens nicht. Hatte gestern wahrscheinlich auf die falsche SSH Konsole geschaut, war schon spät.
Wenn ich Zeit habe, werde ich noch mal mit einem frischen Raspbian anfangen.
Bin zwar noch beim Einrichten des I2C, aber den Interrupt auf den GPIOs konnte ich mit einem frischen System schon mal erfolgreich testen.
Super, es wäre zwar interessant, woran es gelegen hat. Aber so weisst du schonmal, das die Hardware Ok ist
Hallo zusammen,
Ich hoffe, ich verhalte mich nicht falsch, weil ich ein Neuling im Forum bin.
Ich habe einen Raspberry Pi mit Fhem aufgesetzt, und möchte damit über den I2C-Bus 4 MCP23017 Chips ansprechen.
Konkret möchte ich damit die Rollos kabelgebunden steuern. Von der Hardware Seite funktioniert schonmal alles. Jetzt geht es um die Software.
Ich habe mal testweise ein Python Script zum ansteuern der Ausgänge getestet, und in dem Script mit WiringPi2 gearbeitet. Die Bedienung finde ich als Einsteiger sehr einfach.
Gibt es eine Möglichkeit mit dem GPIO Modul von euch, auch die MCP Bausteine komfortabel anzusteuern?
Also ich würde gerne von den insgesamt 64 zur Verfügung stehenden Ports, 16 als Eingänge von Schaltern überwachen, und 48 als Ausgänge.
Wobei ich zum testen auch mit 4 Eingängen und 16 Ausgängen klar komme.
Könnt ihr mir da helfen? Ein Riesen Schritt wäre ja, wenn ich mit GPIO die MCP's ansprechen könnte, und wenn mir kurz ne Hilfe bzgl der Eingänge gegeben werden könnte, ob dass bei den Porterweiterungen auch über "Verzeichnisse" klappt.
Falls ich falsch sein sollte, oder es unpassend ist, bitte ich vielmals um Entschuldigung.
Ansonsten schon mal vielen Dank im Voraus.
Gruß
Christian
Zitat von: IPPhoner2b am 07 April 2014, 22:09:51
Gibt es eine Möglichkeit mit dem GPIO Modul von euch, auch die MCP Bausteine komfortabel anzusteuern?
kurz gesagt nein
Das Modul ist ausschließlich für die GPIO's des Raspberry gedacht.
Es gibt noch ein weiteres Modul um I2C Bausteine am Raspberry anzusteuern.
Hier (http://forum.fhem.de/index.php/topic,20452.0.html) und hier (http://forum.fhem.de/index.php/topic,19797.0.html)
Allerdings gibt es da noch kein fertiges Modul für den MCP....das muss erst noch geschrieben werden.
so ähnlich versuche ich das auch gerade, nur dass ich für die Schaltausgänge den PCF8574 verwende, die Eingänge realisiere ich auch über den MCP23017.
Das Auslesen und Auswerten des MCP23017 ist recht einfach.
Auf dem Pin7 (GPIO4) habe ich den Interrupt des MCP23017. Der Port wird vom GPIO Interrupt überwacht.
Eine Änderung lößt ein Notify aus, dass dann die Auswertung übernimmt.
Pin7.off {
my $wa = fhem("get bus read 21 12") + 0;
my $wb = fhem("get bus read 21 13") + 0;
if ($wa & 1) {fhem ("set IC1_A0 on")} else {fhem ("set IC1_A0 off")}
if ($wa & 2) {fhem ("set IC1_A1 on")} else {fhem ("set IC1_A1 off")}
if ($wa & 4) {fhem ("set IC1_A2 on")} else {fhem ("set IC1_A2 off")}
if ($wa & 8) {fhem ("set IC1_A3 on")} else {fhem ("set IC1_A3 off")}
if ($wa & 16) {fhem ("set IC1_A4 on")} else {fhem ("set IC1_A4 off")}
if ($wa & 32) {fhem ("set IC1_A5 on")} else {fhem ("set IC1_A5 off")}
if ($wa & 64) {fhem ("set IC1_A6 on")} else {fhem ("set IC1_A6 off")}
if ($wa & 128) {fhem ("set IC1_A7 on")} else {fhem ("set IC1_A7 off")}
if ($wb & 1) {fhem ("set IC1_B0 on")} else {fhem ("set IC1_B0 off")}
if ($wb & 2) {fhem ("set IC1_B1 on")} else {fhem ("set IC1_B1 off")}
if ($wb & 4) {fhem ("set IC1_B2 on")} else {fhem ("set IC1_B2 off")}
if ($wb & 8) {fhem ("set IC1_B3 on")} else {fhem ("set IC1_B3 off")}
if ($wb & 16) {fhem ("set IC1_B4 on")} else {fhem ("set IC1_B4 off")}
if ($wb & 32) {fhem ("set IC1_B5 on")} else {fhem ("set IC1_B5 off")}
if ($wb & 64) {fhem ("set IC1_B6 on")} else {fhem ("set IC1_B6 off")}
if ($wb & 128) {fhem ("set IC1_B7 on")} else {fhem ("set IC1_B7 off")}}
"bus" ist das RPII2C Modul, die Adresse des ICs ist in meinem Fall 21, IC1_A0 bis IC1_B7 sind Dummys
Wieso nicht einfach ein Modul schreiben. Ich bin grade bisschen beschäftigt und habe auch nix mit nem Mcp. Aber wenn jemand das Modul für den Mcp... weiterschreiben will bitte Pn an mich.
Wow, das ging ja schnell mit antworten.
Danke schon mal dafür.
Wenn du sagst, "ein Modul für den mcp weiterschreiben"
Ich habe gestern mal nen flüchtigen Blick auf das GPIO Script geworfen. Das ist zwar nicht wirklich meine Welt, aber wenn ich nur die Ein- und Ausgänge des MCP auswerten und setzen möchte, und dies (weil zum verstehen einfacher) mit WiringPi2 realisieren möchte, was muss ich da konkret machen?
HHabe vor 3 Jahren für dieses Avr-Net-Io Bord von Pollin ein paar Programme geschrieben, deswegen ist das nicht so ganz fremd, und mir geht es ja nur um diese "einfachen" Sachen und nix kompliziertes.
Also wenn mir nur ne gaaaaanz kurze Crash Einweisung gegeben würde, würde ich mich gerne dran versuchen.
Kann man die Python Befehle da fast übernehmen, oder in welcher Sprache muss das geschrieben werden? (Perl)
Jedenfalls Respekt vor der Arbeit.
:EDIT:
@Apollo,
das sieht auch schonmal sehr interessant aus.
Kannst du mir bei den Bezeichnungen in deinem Script helfen, welche Bezeichnungen was bedeuten?
Da ich echt noch Neuling bin, was heißt, dass du den Interupt des MCP auf den GPIO 4 gelegt hast?
Und könntest du mir bitte noch erklären, wie du die Dummys angelegt hast, oder wo ich das alles nachlesen kann?
Vielen Dank im voraus
Gruß Christian
Zitat von: IPPhoner2b am 08 April 2014, 06:01:15
Das ist zwar nicht wirklich meine Welt, aber wenn ich nur die Ein- und Ausgänge des MCP auswerten und setzen möchte, und dies (weil zum verstehen einfacher) mit WiringPi2 realisieren möchte, was muss ich da konkret machen?
Mit WiringPi kann ich Dir nicht helfen, da ich es nicht nutze (mit Ausnahme des gpio tools zur Rechteanpassung). Ehrlich gesagt will ich es auch nicht nutzen, weil es keine Standardlösung für FHEM bringt und sich jeder selbst was zurecht basteln muss. Ein eigenes Modul für den MCP könnte jeder nutzen (sogar auf anderen Systemen).
Das RPI_GPIO Modul ist auch das falsche. Du müsstest Dir das I2C_PCF8574 anschauen. So ähnlich muss auch das Modul für den MCP aussehen. Es ist, wie FHEM auch, in Perl geschrieben. Wenn man es sich mal in Ruhe anschaut ist es eigentlich auch recht logisch aufgebaut ;) (ich bin auch auf diese Weise in die Modulprogrammierung rein gekommen). Ich suche mal nach meiner ersten Version für den I2C_MCP23017 und stelle sie hier ein.
Ja ok,
Das macht Sinn, dass man nicht das Rad neu erfinden muss, und wenn das mit dem GPIO auch soweit funktioniert, und ich es verstehe, wäre es mir auch egal, wie ich es ansprechen muss.
Dann werde ich mir mal die Datei für den PCF... ansehen, und so wenigstens die Ausgänge komfortabel setzen zu können. Das ist super nett von dir, wenn ich mir deine Datei anschauen kann, und noch besser wäre es, wenn ich dann auch hier und da mal Tipps bekommen kann.
Was meinst du denn, sollte ich die Eingänge wie Apollo das gemacht hat abfragen, oder geht dass dann auch mit dem "Modul"?
Wie geht das denn mit der Eingangsabfrage über den GPIO 4, habe schonmal nach gesucht, aber noch nicht viel zufriedenstellendes gefunden.
Zitat von: IPPhoner2b am 08 April 2014, 21:21:04
Dann werde ich mir mal die Datei für den PCF... ansehen, und so wenigstens die Ausgänge komfortabel setzen zu können. Das ist super nett von dir, wenn ich mir deine Datei anschauen kann, und noch besser wäre es, wenn ich dann auch hier und da mal Tipps bekommen kann.
Was meinst du denn, sollte ich die Eingänge wie Apollo das gemacht hat abfragen, oder geht dass dann auch mit dem "Modul"?
Wie geht das denn mit der Eingangsabfrage über den GPIO 4, habe schonmal nach gesucht, aber noch nicht viel zufriedenstellendes gefunden.
Ok, lass mich das Modul noch an die neue Schnittstelle zu den I2C Modulen anpassen.
Du kannst dann mit dem MCP.... Modul sämtliche GPIO des IC direkt als Ein oder Ausgänge nutzen. In diesem Modul sollte auch der Interrupt konfiguriert werden.
Den Interrupt Ausgang kannst Du dann an jeden beliebigen GPIO der Raspberry anschließen und über die Interrupt Funktion des Moduls Rpi_GPIO das auslesen der Portpins vom MCP starten.
So kannst Du ohne den Prozessor zu belasten die Portpins als Input nutzen.
So hier (http://forum.fhem.de/index.php/topic,23164.0.html) das Modul für den MCP23017
In Ermangelung eines Testsamples kann ich es nicht selbst testen.
Über die Attribute:
OutputPorts
Pullup
active_low
Interrupt
Können einige Konfigurationen ausgeführt werden.
Die Werte für die Attribute müssen Kommagetrennte Portbezeichnungen sein.
z.B A1,B4,B7
Wenn es funktioniert werde ich es einchecken.
Hallo Klaus,
Vielen Dank schonmal für deine Unterstützung, heute und morgen werde ich wohl noch keine Zeit dafür haben, aber ich hoffe, nächste Tage dann mal die Ruhe dafür zu haben.
Also mit den Interrupt d.h. Also den Pin IntA oder IntB auf den GPIO z.b. pin4 des RPI zu legen, richtig?
Über den Befehl Pullup kann ich also für die Eingänge die internen Pullup Widerstände aktivieren?!
Herrje, ich habe wirklich noch viel vor mir, und ich glaube zur Sicherheit könnte ich dem Klaus noch nen Satz MCP23017 zukommen lassen. Wenn du dann mal in ferner Zukunft die Lust verspürst eine "richtige funktionierende" Version zu erstellen, dann wäre anderen Usern auch direkt geholfen.
Ich bin ja immer dankbar, dass es so Leute gibt, die sich so selbstlos einsetzen *Alle Daumen hoch* :) :)
Gruß Christian
gern geschehen 8), alleine hätte ich es aber auch nicht hinbekommen
Selbstlos isses ja nicht. Den MCP hatte ich auch schonmal ins Auge gefasst.
Zitat von: IPPhoner2b am 10 April 2014, 20:33:38
Also mit den Interrupt d.h. Also den Pin IntA oder IntB auf den GPIO z.b. pin4 des RPI zu legen, richtig?
Genau, im Moment müssen die beide auf getrennte GPIO's. Sobald ich weitere Konfigurationsregister eingebaut habe lassen die sich auch zusammenschließen bzw. intern verbinden.
Zitat von: IPPhoner2b am 10 April 2014, 20:33:38
Über den Befehl Pullup kann ich also für die Eingänge die internen Pullup Widerstände aktivieren?!
yepp... 100k Pullup Pinselektiv
Zitat von: IPPhoner2b am 10 April 2014, 20:33:38
Herrje, ich habe wirklich noch viel vor mir, und ich glaube zur Sicherheit könnte ich dem Klaus noch nen Satz MCP23017 zukommen lassen. Wenn du dann mal in ferner Zukunft die Lust verspürst eine "richtige funktionierende" Version zu erstellen, dann wäre anderen Usern auch direkt geholfen.
Na ich hoffe doch, das die Version schon richtig funkioniert :D
Was würde ich nur ohne dich machen ;D ::)
Du bist so gut zu mir ;)
Dann werde ich mich morgen mal dran setzen, und schauen wie ich das alles gestemmt bekomme, meine weiteren Fragen werde ich wohl hier wieder kund tun :o
Gruß Christian
S, ich werde den RPi zur Sicherheit doch nochmal komplett neu aufsetzen, hatte ja doch hier und da sachen drin, die dort nicht hingehören.
Nur ne kurze Frage bzgl der ganzen Dinge, die installiert werden müssen.
Basis: Raspian Wheezy vom 07.01.2014 und updaten
dann im groben und ganzen Fhem installieren und updaten
- den I2C Bus aktivieren und die I2C-Tools und WiringPi installieren
Gibt es da einen Unterschied, ob ich WiringPi oder WiringPi2 installiere? Habe momentan die ...2 drauf, weiß aber nicht, ob das kompatibel ist.
Und dann könnte es doch in groben schritten schon fast losgehen, um die "Defines" einzurichten, oder?
Gruß
Christian
Zitat von: IPPhoner2b am 15 April 2014, 09:05:31
Nur ne kurze Frage bzgl der ganzen Dinge, die installiert werden müssen.
Basis: Raspian Wheezy vom 07.01.2014 und updaten
dann im groben und ganzen Fhem installieren und updaten
- den I2C Bus aktivieren und die I2C-Tools und WiringPi installieren
Gibt es da einen Unterschied, ob ich WiringPi oder WiringPi2 installiere? Habe momentan die ...2 drauf, weiß aber nicht, ob das kompatibel ist.
Und dann könnte es doch in groben schritten schon fast losgehen, um die "Defines" einzurichten, oder?
Du benötigst auch die Moose und SMBus Perl library (steht in der commandref drin wie Du es installiert).
Sonst passt es soweit.
Von WiringPi wird nur das gpio tool benötigt. Das sollte bei beiden Versionen dabei sein.
Apollo hat ein Script (http://forum.fhem.de/index.php/topic,20452.msg154861.html#msg154861) geschrieben, welches alles automatisch installiert.
Hallo Klaus,
na schau mal, die Libmoose hatte ich nicht drin, danke für den Hinweis mit dem Installscript von Apollo, dann werde ich es jetzt damit nochmal zur Sicherheit neu machen, damit auch wirklich alles drauf ist, was da sein muss. :o
Achso, eine Frage noch, habe mir das Script mal grob angesehen, eine Sache konnte ich jedoch nicht entziffern, wird der Speicherplatz der SD Karte auf das maximum erweitert? Wenn ja, welcher Befehl in dem Script ist das dann?
:EDIT:
Hmm, komisch, bekomme das Script nicht gestartet, muss ich da in einem besonderen Verzeichnis sein?
ich glaube ich muss es doch wieder auf die altmodische Weise machen, und kopiere mir die Befehle aus dem Script heraus :o ::)
pi@raspberrypi ~ $ wget -q http://binichschondrin.info/install && chmod 755 install && ./install
-bash: ./install: /bin/bash^M: bad interpreter: No such file or directory
das musst Du vermutlich mit sudo machen
aber immer alles neu machen muss auch nicht sein ;)
Habe es auch direkt danach mit sudo versucht, kam aber die gleiche Fehlermeldung :'(
Ich bin wirklich nicht sehr routiniert was Linux und son Zeugs angeht, und da ich ja eh noch am Anfang bin, wollte ich es halt einmal so aufsetzen, das nur das nötigste installiert ist.
:EDIT:
Hi Klaus,
eine kleine Anmerkung in eigener Sache, wenn du die Scripte erstellst, kannst du nicht evtl oben ein Datum der Überarbeitung mit reinschreiben? Das würde es einfacher machen, gleich die aktuellste Datei zu finden.
Zitat von: IPPhoner2b am 16 April 2014, 11:44:41
wenn du die Scripte erstellst, kannst du nicht evtl oben ein Datum der Überarbeitung mit reinschreiben? Das würde es einfacher machen, gleich die aktuellste Datei zu finden.
welche Scripte meinst Du?
Meinte die RPI_I2C, oder MCP_23017 oder so.
Weil doch oben dein Name drin steht, dachte ich, die wären von dir.
Jedenfalls wäre es dann einfacher herauszufinden, welche Datei jetzt die aktuellste Version immer ist (beim MCP ja noch sehr einfach ;D )
Sagmal, bin jetzt mal ein bisschen angefangen rum zu experimentieren.
Die Sachen werden doch alle in die Fhem.cfg geschrieben, oder?
Ich komme nur noch nicht so richtig zurecht mit der Sprache, muss mich da doch noch stark durch Wiki lesen oder so.
Was muss dort alles rein, dass ich z.B. mit
set <name> <port> <value> den Ausgang A0 schalten kann?
Wenn ich
set mcp_20 A0 1
eingebe, kommt
no IODev assigned to 'mcp_20
in der Fhem.cfg habe ich folgendes:
define chip RPII2C 1
define mcp_20 I2C_MCP23017 0x20
auch mit
attr mcp_20 OutputPorts A0
kommt die gleiche Meldung, aber ich weiß nicht, was ich mit IODev machen muss
Über
attr mcp_20 IODev 1
kommt auch nichts fruchtbares
Oh mann, ich scheitere schon an so Basics, wo soll das noch hinführen :-[
:EDIT:
Kann das evtl. damit zusammenhängen, dass folgender Befehl bei mir noch nicht ausgeführt wurde? Läuft jetzt grade, aber das dauert ja recht lange
sudo cpan -i Device::SMBus
Zitat von: IPPhoner2b am 16 April 2014, 14:23:43
Meinte die RPI_I2C, oder MCP_23017 oder so.
Weil doch oben dein Name drin steht, dachte ich, die wären von dir.
Jedenfalls wäre es dann einfacher herauszufinden, welche Datei jetzt die aktuellste Version immer ist (beim MCP ja noch sehr einfach ;D )
Mit ausnahme des I2C_MCP23017 werden bei einem update von FHEM die aktuellsten Modulversionen heruntergeladen. Da muss man nix herausfinden :)
Zitat von: IPPhoner2b am 16 April 2014, 14:23:43
Sagmal, bin jetzt mal ein bisschen angefangen rum zu experimentieren.
Die Sachen werden doch alle in die Fhem.cfg geschrieben, oder?
jein
Du kannst sie in die fhem.cfg schreiben.
Du kannst sie aber auch nacheinander oben in FHEM in die Eingabezeile eingeben. Die Module bleiben dann bis zum Neustart erhalten ("safe config" schreibt es in die fhem.cfg und Du hast die Einstellungen auch nach dem Neustart noch)
Zitat von: IPPhoner2b am 16 April 2014, 14:23:43
Ich komme nur noch nicht so richtig zurecht mit der Sprache, muss mich da doch noch stark durch Wiki lesen oder so.
links unten in FHEM auf commanref drücken...da hast Du eine Übersicht über die Befehle für alle in FHEM enthaltenen Module.
Zitat von: IPPhoner2b am 16 April 2014, 14:23:43
Was muss dort alles rein, dass ich z.B. mit
set <name> <port> <value> den Ausgang A0 schalten kann?
Wenn ich
set mcp_20 A0 1
eingebe, kommt
no IODev assigned to 'mcp_20
in der Fhem.cfg habe ich folgendes:
define chip RPII2C 1
define mcp_20 I2C_MCP23017 0x20
auch mit
attr mcp_20 OutputPorts A0
kommt die gleiche Meldung, aber ich weiß nicht, was ich mit IODev machen muss
Über
attr mcp_20 IODev 1
kommt auch nichts fruchtbares
bei IODev muss natürlich das IODev rein B) in Deinem Fall chip
define chip RPII2C 1 #IODev für I2C definieren
define mcp_20 I2C_MCP23017 0x20 #MCP23017 definieren
attr mcp_20 IODev chip #IODev dem MCP23017 zuweisen
attr mcp_20 OutputPorts A0,A1,A2 #Ports A0 bis A2 als Output definieren
Zitat von: IPPhoner2b am 16 April 2014, 14:23:43
Kann das evtl. damit zusammenhängen, dass folgender Befehl bei mir noch nicht ausgeführt wurde? Läuft jetzt grade, aber das dauert ja recht lange
sudo cpan -i Device::SMBus
Ohne Device::SMBus funktioniert die Kommunikation über RPII2C nicht.
Die Installation muss vorher abgeschlossen werden.
Wenn du Moose nicht vorher installiert hat dauert die Installation über 8h.
Hallo Klaus,
vielen Dank für deine Hilfe, hatte mir eigentlich vorgenommen in meinem Urlaub richtig was zu schaffen, aber naja, wie das eben so ist, Urlaub ist vorbei, und ich habe es grade mal zu den Basics geschafft :o ;)
Aber dank deiner Hilfe wird es jetzt voran gehen *Du tust mir jetzt schon Leid, dich mit so einem Noob herumschlagen zu dürfen* ::) ;D
Das "Libmoose" Zeugs hatte ich schon vorher installiert, und habe mich so extrem gewundert, dass er dann bei dem cpan Befehl innerhalb extremst kurzer Zeit fertig war.
Ich werde Testen und berichten :P
:EDITH sagt
Du bist einfach nur genial, was so eine kleine vergessene Zuordnung doch anstellen kann ::) ;D
:Da ist noch eine EDITH im Spiel,
irgendwas ist total komisch, ich konnte meine Eingänge abfragen, und meine Ausgänge schonmal per Webinterface steuern,
dann habe ich die Sachen vom Steckbrett auf meine Platine umgeändert, also eigentlich nur den Interrupt Pin mit angeschlossen, und jetzt klappt irgendwie nix mehr.
Habe zwar 4 MCPs auf der Platine, und habe die auch passend adressiert, wie den ersten davon, aber seitdem klappt nix mehr, beim aktualisieren der Übersichtsseite springen auf einmal die Eingänge oder die Ausgänge auf on oder off usw, ohne dass sich aber an der Platine eine LED "erleuchtet". Ich konnte auch keine Ausgänge setzen, oder Eingänge abfragen. Habe dann die anderen 3 Chips auskommentiert und aus dem Sockel entnommen, klappte aber trotzdem nicht.
Zurück aufs Steckbrett, und tja, was soll ich sagen, es klappt auch nicht mehr. :-[
Der Ausgang wird gesetzt, aber sofort wieder auf 0 gesetzt, und Eingänge ignoriert er gekonterweise >:(
2014.04.18 15:14:22 1: mcp_20 set regaddr: 12 inhalt: 01
2014.04.18 15:14:22 1: mcp_20 UpdReadings Register: 18, Inhalt: 1; RegA: 18, RegB: 19
2014.04.18 15:14:22 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.04.18 15:14:22 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
Das hier ist der Bereich für die Fhem.cfg
define chip RPII2C 1
define mcp_20 I2C_MCP23017 0x20
attr mcp_20 IODev chip
attr mcp_20 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
attr mcp_20 Pullup B0,B1,B2,B3,B4,B5,B6,B7
attr mcp_20 active_low B0,B1,B2,B3,B4,B5,B6,B7
#define mcp_21 I2C_MCP23017 0x21
#attr mcp_21 IODev chip
#attr mcp_21 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
#define mcp_22 I2C_MCP23017 0x22
#attr mcp_22 IODev chip
#attr mcp_22 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
#define mcp_24 I2C_MCP23017 0x24
#attr mcp_24 IODev chip
#attr mcp_24 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
#attr mcp_24 Pullup B0,B1,B2,B3,B4,B5,B6,B7
#attr mcp_24 active_low B0,B1,B2,B3,B4,B5,B6,B7
define Eingang_mcp_20 RPI_GPIO 8
attr Eingang_mcp_20 direction input
attr Eingang_mcp_20 interrupt rising
#define Eingang_mcp_24 RPI_GPIO 10
#attr Eingang_mcp_24 direction input
#attr Eingang_mcp_24 interrupt rising
Hallo zusammen,
Heute wurde bei uns (endlich) ein Wasserzähler mit Impulsausgang montiert.
Diesen Impulsausgang (1 Imp. = 1 Liter) möchte ich nun gerne an meinen RasPi klemmen und (logischerweise) abfragen.
Aber - ich habe an diesem RasPi bereits den I2C-Port belegt.
Darüber frage ich zur Zeit 3 LM75-Temperatursensoren ab.
Nun erstmal natürlich die Frage:
Geht mein Vorhaben oder kommt sich I2C(GPIO1/2) und z.B. GPIO 17 in die Quere?
Nicht das sich das Modul resp. die WiringPi erstmal alle GPIO krallt und der I2C dann nichtmehr zur Verfügung steht.
Sollte das so klappen dann würde es ja genügen von Pin1 (3.3V) über den Kontakt auf Pin11 (GPIO17) zu verdrahten und mit dem Modul dann diesen Pin auf Eingang zu setzen und das Attribut interrupt zu aktivieren.
Oder habe ich hier einen Denkfehler?
Danke schonmal für Eure Antworten bzw. Hilfestellungen.
Grüße
P.S.: Ein kurzes und knappes "Nein" würde mir schon reichen wenn ich gedanklich ganz daneben liege ;D
Zitat von: Puschel74 am 22 April 2014, 10:49:43
Heute wurde bei uns (endlich) ein Wasserzähler mit Impulsausgang montiert.
Diesen Impulsausgang (1 Imp. = 1 Liter) möchte ich nun gerne an meinen RasPi klemmen und (logischerweise) abfragen.
...
P.S.: Ein kurzes und knappes "Nein" würde mir schon reichen wenn ich gedanklich ganz daneben liege ;D
Das Modul ist sehr genügsam ;D
Es werden nur die Pins exportiert, die auch definiert werden. Ich nutze auch I2C parallel dazu.
Es ist also eher ein kurzes ja.
Wie stark der interne Pullup ist, kann ich Dir nicht sagen. Evtl musst Du extern noch einen dazu setzen.
Ich würde noch einen 1k Angstwiderstand in Reihe zur 3.3V setzen.
Grüße
Klaus
PS: im Modul werden aber nur die Pulse gezählt. Mehr habe ich noch ich implementiert.
Hallo,
ZitatEs ist also eher ein kurzes ja.
Wunderbar.
Vielen Dank für die Antwort.
Und danke auch für die Hinweise mit den Widerständen.
Werd ich auf alle Fälle machen.
ZitatPS: im Modul werden aber nur die Pulse gezählt.
Mehr hätte ich auch garnicht erwartet ;D
Das ist eigentlich genau das was mir ja schon genügt.
ZitatFür GPIO der als input konfiguriert ist
readval
readval aktualisiert das reading Pinlevel und, wenn attr toggletostate nicht gesetzt ist, auch state
Wenn ich das richtig lese kann ich ja den Pinlevel bzw. state auslesen und wenn der brav mit jedem Kontakt hochzählt hab ich ja schonmal die Liter.
Alles weitere sollte ja dann das "kleinere" Problem sein (hoffe ich mal).
Nu geh ich erst mal ans löten 8)
Grüße
Zitat von: Puschel74 am 22 April 2014, 11:50:45
Für GPIO der als input konfiguriert ist
readval
readval aktualisiert das reading Pinlevel und, wenn attr toggletostate nicht gesetzt ist, auch state
Wenn ich das richtig lese kann ich ja den Pinlevel bzw. state auslesen und wenn der brav mit jedem Kontakt hochzählt hab ich ja schonmal die Liter.
Der Pinlevel nützt Dir doch nix. Du möchtest die Impulse (Flanken) zählen.
Natürlich kannst Du den Pinlevel pollen, das muss aber nicht sein.
Sobald Du das Attribut
interrupt auf falling oder rising gesetzt hast, wird bei entsprechender Flanke ein Interrupt ausgelöst und das Reading
Counter um 1 hochgezählt.
Dieses Reading kannst du dann zyklisch auslesen und für Deine Verbrauchsdarstellung nutzen.
Du kannst auch bei jedem Zyklus mit
setreading den Counter wieder zurücksetzen.
Zitat von: IPPhoner2b am 18 April 2014, 11:05:59
:Da ist noch eine EDITH im Spiel,
irgendwas ist total komisch, ich konnte meine Eingänge abfragen, und meine Ausgänge schonmal per Webinterface steuern,
dann habe ich die Sachen vom Steckbrett auf meine Platine umgeändert, also eigentlich nur den Interrupt Pin mit angeschlossen, und jetzt klappt irgendwie nix mehr.
Habe zwar 4 MCPs auf der Platine, und habe die auch passend adressiert, wie den ersten davon, aber seitdem klappt nix mehr, beim aktualisieren der Übersichtsseite springen auf einmal die Eingänge oder die Ausgänge auf on oder off usw, ohne dass sich aber an der Platine eine LED "erleuchtet". Ich konnte auch keine Ausgänge setzen, oder Eingänge abfragen. Habe dann die anderen 3 Chips auskommentiert und aus dem Sockel entnommen, klappte aber trotzdem nicht.
Zurück aufs Steckbrett, und tja, was soll ich sagen, es klappt auch nicht mehr. :-[
Der Ausgang wird gesetzt, aber sofort wieder auf 0 gesetzt, und Eingänge ignoriert er gekonterweise >:(
2014.04.18 15:14:22 1: mcp_20 set regaddr: 12 inhalt: 01
2014.04.18 15:14:22 1: mcp_20 UpdReadings Register: 18, Inhalt: 1; RegA: 18, RegB: 19
2014.04.18 15:14:22 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.04.18 15:14:22 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
Das hier ist der Bereich für die Fhem.cfg
define chip RPII2C 1
define mcp_20 I2C_MCP23017 0x20
attr mcp_20 IODev chip
attr mcp_20 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
attr mcp_20 Pullup B0,B1,B2,B3,B4,B5,B6,B7
attr mcp_20 active_low B0,B1,B2,B3,B4,B5,B6,B7
#define mcp_21 I2C_MCP23017 0x21
#attr mcp_21 IODev chip
#attr mcp_21 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
#define mcp_22 I2C_MCP23017 0x22
#attr mcp_22 IODev chip
#attr mcp_22 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
#define mcp_24 I2C_MCP23017 0x24
#attr mcp_24 IODev chip
#attr mcp_24 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
#attr mcp_24 Pullup B0,B1,B2,B3,B4,B5,B6,B7
#attr mcp_24 active_low B0,B1,B2,B3,B4,B5,B6,B7
define Eingang_mcp_20 RPI_GPIO 8
attr Eingang_mcp_20 direction input
attr Eingang_mcp_20 interrupt rising
#define Eingang_mcp_24 RPI_GPIO 10
#attr Eingang_mcp_24 direction input
#attr Eingang_mcp_24 interrupt rising
Soo, ich war Ostern offline ... sehr erholsam :D
zu aller erst: wenn es zuerst funktioniert hat dann sollte es nach dem Rückbau in gleicher Konfiguration auch wieder gehen.
Wird der Ausgang auch messbar am Pin gesetzt, oder nur im Frontend?
Bevor ich mit den Kopf zerbreche:
geht es ohne
define Eingang_mcp_20 RPI_GPIO 8 wieder?
Geht es ohne die Attribute Pullup und activelow?
Es währe gut zu wissen, bei welcher Änderung es nicht mehr geht.
Hallo,
Zitatund das Reading Counter um 1 hochgezählt.
Äh, ja klar.
Da gibt es schon eine deutsche commandref dazu und dann les ich nur die Hälfte ::)
Stimmt ja.
Da gibt es ja dann den Counter <-- noch besser.
Danke für den Schupps.
Grüße
Hallo Klaus,
zunächst mal ein großes Lob für das Modul!
Für jemanden wie mich, der erst dabei ist sich in die Untiefen der IC's zu begeben, spart dieses Modul zunächst viel Zeit für die (test)Inbetriebnahme. :D
Dennoch ist es natürlich hilfreich und sinnvoll zu verstehen mit was und wie man damit arbeitet.
Neben dem Datenblatt ist mir folgende Seite zwar bisher sehr hilfreich gewesen, aber ich bin eben noch am Anfang.::)
http://www.elektronx.de/tutorials/porterweiterung-mit-mcp23017-und-i2c/ (http://www.elektronx.de/tutorials/porterweiterung-mit-mcp23017-und-i2c/)
Mein Problem ist nur, dass der Interrupt leider nicht reagiert.
Meine Testkonfiguration:
- REED-Kontakt auf GPA7
- INTA auf GPIO4 gelegt (bleibt immer auf High!?!)
define chip RPII2C 1
define testMCP23017 I2C_MCP23017 0x20
attr testMCP23017 IODev chip
attr testMCP23017 Interrupt A7
define dummyMCP23017 dummy
define notifyMCP23017 notify testMCP23017 {my $MCP23017state=ReadingsVal("testMCP23017","PortA7",0);; fhem ("set dummyMCP23017 $MCP23017state")}
attr notifyMCP23017 showTriggerTime 1
Die Ports (die Readings) werden nur ausgelesen wenn ich das <testMCP23017> geöffnet habe und F5 drücke. ??? :-[
Muss ich evtl. den INTA noch konfigurieren und wenn ja wie?
Vielen Dank schonmal bis hierhin und im Voraus!
(P.S: Ich freue mich natürlich über jede Hilfe!)
Gruß
Christian
Hallo Christian,
Zitat von: linusd am 27 April 2014, 16:37:23
Mein Problem ist nur, dass der Interrupt leider nicht reagiert.
Meine Testkonfiguration:
- REED-Kontakt auf GPA7
- INTA auf GPIO4 gelegt (bleibt immer auf High!?!)
define chip RPII2C 1
define testMCP23017 I2C_MCP23017 0x20
attr testMCP23017 IODev chip
attr testMCP23017 Interrupt A7
define dummyMCP23017 dummy
define notifyMCP23017 notify testMCP23017 {my $MCP23017state=ReadingsVal("testMCP23017","PortA7",0);; fhem ("set dummyMCP23017 $MCP23017state")}
attr notifyMCP23017 showTriggerTime 1
Die Ports (die Readings) werden nur ausgelesen wenn ich das <testMCP23017> geöffnet habe und F5 drücke. ??? :-[
Muss ich evtl. den INTA noch konfigurieren und wenn ja wie?
Deine Konfiguration scheint schonmal zu funktionieren.
Der Interrupt kann noch nicht laufen, da die Konfiguration noch unvollständig ist.
Der Gpio vom Raspberry muss noch eingestellt werden.
z.B. so:
define meinIntport RPI_GPIO 4
attr meinIntport direction input
attr meinIntport interrupt risingDieser sollte dann bei jedem Interruptereignis auslösen.
Wenn das geht, kannst Du über den GPIO ein
notify auslösen, welches eine get für den MCP23017 auslöst.
Grüße
Klaus
Zitat von: klausw am 22 April 2014, 15:03:56
Soo, ich war Ostern offline ... sehr erholsam :D
zu aller erst: wenn es zuerst funktioniert hat dann sollte es nach dem Rückbau in gleicher Konfiguration auch wieder gehen.
Wird der Ausgang auch messbar am Pin gesetzt, oder nur im Frontend?
Bevor ich mit den Kopf zerbreche:
geht es ohne define Eingang_mcp_20 RPI_GPIO 8 wieder?
Geht es ohne die Attribute Pullup und activelow?
Es währe gut zu wissen, bei welcher Änderung es nicht mehr geht.
Hallo Klaus,
hoffe du hast die Tage gut überstanden, ich bin auch in letzter Zeit überhaupt nicht mehr zu gekommen.
Bin jetzt mal in die Fhem.cfg, und habe unten alles rausgelöscht, jetzt steht nur noch folgendes drin:
define chip RPII2C 1
define mcp_20 I2C_MCP23017 0x20
attr mcp_20 IODev chip
attr mcp_20 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
#define Eingang_mcp_20 RPI_GPIO 12
#attr Eingang_mcp_20 direction input
#attr Eingang_mcp_20 interrupt risingAber selbst so wird der gesetzte Ausgang sofort zurückgenommen
2014.05.01 12:22:55 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.01 12:22:55 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
2014.05.01 12:23:01 1: mcp_20 set regaddr: 12 inhalt: 20
2014.05.01 12:23:01 1: mcp_20 UpdReadings Register: 18, Inhalt: 32; RegA: 18, RegB: 19
2014.05.01 12:23:01 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.01 12:23:01 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
2014.05.01 12:23:07 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.01 12:23:07 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
2014.05.01 12:23:12 1: mcp_20 set regaddr: 12 inhalt: 02
2014.05.01 12:23:12 1: mcp_20 UpdReadings Register: 18, Inhalt: 2; RegA: 18, RegB: 19
2014.05.01 12:23:12 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.01 12:23:12 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19Als Anhang nochmal ein Screenshot, von der Übersichtsseite des MCP, warum steht dort bei I2C-Address eine 32? Das ist aber richtig so, oder?
Also egal, welchen Ausgang ich setze, es wird sofort gekillt.
Wird noch in eine andere Datei außer der Fhem.cfg was geschrieben, weil ich habe keine Ahnung, wo der Fehler sonst liegen kann.
Ich wechsel mal kurz den MCP Chip, ob das klappt, und sonst danach noch den RPI, und wenns dann auch nicht ist, muss ja eingetlich irgendwo an der Software ein Fehler liegen. :-[
Vielen Dank schonmal für die Unterstützung, und einen schönen ersten Mai noch.
:EDIT:
also den Chip habe ich getauscht, bringt jedenfalls keine Änderung, dann habe ich den Chip bzw. die Verbindungen alle getrennt, um zu sehen, ob er den Chip überhaupt erkennt bzw. anspricht, dann kommt beim Start auch sofort eine Fehlermeldung im Log
2014.05.01 12:59:03 3: mcp_20: failure in message from chip
2014.05.01 12:59:03 3: Direction: i2cread I2Caddress: 32 Register: 18 Data: undef received: undef So, und jetzt noch eben den RPI getauscht, ist das selbe Spiel, der Ausgang wird ohne Verzögerung sofort deaktiviert. Bin jetzt kurz davor alles nochmal neu zu machen, weil irgendwann habe ich mal diese attribute oder define oder so übers WebInterface oben in die Zeile eingegeben. Vielleicht hat der irgendwo was hingeschrieben, dass es deshalb nicht mehr klappt....
Jetzt bin ich irgendwie noch Ratloser, als vorher
Gruß
Christian
Hallo Christian,
in Deiner config kann ich keinen Fehler erkennen.
Verändere erstmal nix, ich vermute, das der Fehler im Modul liegt. Es gibt keine andere Config, es sei denn Du hast die in der fhem.cfg eingebunden.
Zitat von: IPPhoner2b am 01 Mai 2014, 12:34:21
Als Anhang nochmal ein Screenshot, von der Übersichtsseite des MCP, warum steht dort bei I2C-Address eine 32? Das ist aber richtig so, oder?
32 ist eine Dezimalzahl und entspricht Hexadezimal 0x20
Wenn bei SENDSTAT ok stehe, dann antwortet der MCP auch...also die Kommunikation ist in Ordnung.
Versuche mal folgendes:
- Attribut verbose in chip auf 5 setzen
- attr mcp_20 OutputPorts nochmal neu setzen
- einen pin auf 1 setzen
- log hier posen
ausserdem kannst Du mal mit i2cread auf der Konsole schauen, was in den ersten 2 Registern vom MCP steht.
Ich vermute, die Ports werden nicht auf Output gesetzt....warum auch immer.
Grüße
Klaus
Hallo,
ich beschäftige mich seit Kurzem auch mit dem Modul für den MCP23017 von Klaus. Ich habe aber das Problem, dass der Chip nicht korrekt initialisiert wird.
"attr mcp_20 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7" wird beim Start vermutlich nicht übertragen. Wenn ich das Attribut nochmals über die Eingabezeile schiebe, dann läuft alles.
Nach dem Start steht Folgendes im log:
2014.05.02 00:24:19 5: chip: vom client empfangen|direction: i2cwrite|reg: 0|data: 0|i2caddress:
2014.05.02 00:24:19 5: chip: vom client empfangen|direction: i2cwrite|reg: 1|data: 0|i2caddress:
Grüße,
Hajo
Zitat von: hajo23 am 02 Mai 2014, 00:57:52
ich beschäftige mich seit Kurzem auch mit dem Modul für den MCP23017 von Klaus. Ich habe aber das Problem, dass der Chip nicht korrekt initialisiert wird.
.....
Nach dem Start steht Folgendes im log:
2014.05.02 00:24:19 5: chip: vom client empfangen|direction: i2cwrite|reg: 0|data: 0|i2caddress:
2014.05.02 00:24:19 5: chip: vom client empfangen|direction: i2cwrite|reg: 1|data: 0|i2caddress:
Das ist ein Fehler im Modul. Irgendwie werden die Attribute gesendet, bevor die I2C Adresse im Hash abgelegt wird.
Wesshalb was so ist weiss ich nicht, im define wird die Adresse schließlich angegeben. Ich bin an dem Thema dran...
Hallo Klaus,
also habe grade deine Anleitung befolgt *g*, und es hat auf Anhieb funktioniert, hier das Log:
2014.05.02 14:05:42 0: Server started with 11 defined entities (version $Id: fhem.pl 5705 2014-04-30 10:26:25Z rudolfkoenig $, os linux, user fhem, pid 1963)
2014.05.02 14:06:01 5: chip: vom client empfangen|direction: i2cwrite|reg: 0|data: 0|i2caddress: 32
2014.05.02 14:06:01 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:06:01 5: chip; Register 00 schreiben - Inhalt: 00 Returnvar.: 0
2014.05.02 14:06:01 5: chip ->Client gefunden: mcp_20, I2Caddress: 32
2014.05.02 14:06:01 3: mcp_20: failure in message from chip
2014.05.02 14:06:01 3: Direction: i2cwrite I2Caddress: 32 Register: 0 Data: 0 received: undef
2014.05.02 14:06:01 5: chip: vom client empfangen|direction: i2cwrite|reg: 1|data: 255|i2caddress: 32
2014.05.02 14:06:01 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:06:01 5: chip; Register 01 schreiben - Inhalt: FF Returnvar.: 0
2014.05.02 14:06:01 5: chip ->Client gefunden: mcp_20, I2Caddress: 32 Data: 255
2014.05.02 14:06:01 1: mcp_20 UpdReadings Register: 1, Inhalt: 255; RegA: 18, RegB: 19
2014.05.02 14:06:13 5: chip: vom client empfangen|direction: i2cread|nbyte: 2|reg: 18|i2caddress: 32
2014.05.02 14:06:13 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:06:13 5: chip; Register 12 lesen - Inhalt: 00
2014.05.02 14:06:13 5: chip; Register 13 lesen - Inhalt: 00
2014.05.02 14:06:13 5: chip ->Client gefunden: mcp_20, I2Caddress: 32
2014.05.02 14:06:13 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.02 14:06:13 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
2014.05.02 14:06:19 1: mcp_20 set regaddr: 12 inhalt: 08
2014.05.02 14:06:19 5: chip: vom client empfangen|direction: i2cwrite|reg: 18|data: 8|i2caddress: 32
2014.05.02 14:06:19 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:06:19 5: chip; Register 12 schreiben - Inhalt: 08 Returnvar.: 0
2014.05.02 14:06:19 5: chip ->Client gefunden: mcp_20, I2Caddress: 32 Data: 8
2014.05.02 14:06:19 1: mcp_20 UpdReadings Register: 18, Inhalt: 8; RegA: 18, RegB: 19
2014.05.02 14:06:19 5: chip: vom client empfangen|direction: i2cread|nbyte: 2|reg: 18|i2caddress: 32
2014.05.02 14:06:19 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:06:19 5: chip; Register 12 lesen - Inhalt: 08
2014.05.02 14:06:19 5: chip; Register 13 lesen - Inhalt: 00
2014.05.02 14:06:19 5: chip ->Client gefunden: mcp_20, I2Caddress: 32
2014.05.02 14:06:19 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.02 14:06:19 1: mcp_20 UpdReadings Register: 18, Inhalt: 8; RegA: 18, RegB: 19
Mit der Console, meintest du da I2Cget, oder I2Cread? Weil Read kenne ich und das System nicht ::)
:EDIT ist wieder da:
Habe danach die Config gespeichert, also dass das mit Verbose 5 da drin steht, und habe neu gestartet, ohne die Ausgänge extra neu zu definieren. Dann klappt es wieder nicht, hier davon das log
2014.05.02 14:10:06 0: Server started with 11 defined entities (version $Id: fhem.pl 5705 2014-04-30 10:26:25Z rudolfkoenig $, os linux, user fhem, pid 1949)
2014.05.02 14:10:12 5: chip: vom client empfangen|direction: i2cread|nbyte: 2|reg: 18|i2caddress: 32
2014.05.02 14:10:12 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:10:12 5: chip; Register 12 lesen - Inhalt: 00
2014.05.02 14:10:12 5: chip; Register 13 lesen - Inhalt: 00
2014.05.02 14:10:12 5: chip ->Client gefunden: mcp_20, I2Caddress: 32
2014.05.02 14:10:12 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.02 14:10:12 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
2014.05.02 14:10:21 1: mcp_20 set regaddr: 12 inhalt: 04
2014.05.02 14:10:21 5: chip: vom client empfangen|direction: i2cwrite|reg: 18|data: 4|i2caddress: 32
2014.05.02 14:10:21 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:10:21 5: chip; Register 12 schreiben - Inhalt: 04 Returnvar.: 0
2014.05.02 14:10:21 5: chip ->Client gefunden: mcp_20, I2Caddress: 32 Data: 4
2014.05.02 14:10:21 1: mcp_20 UpdReadings Register: 18, Inhalt: 4; RegA: 18, RegB: 19
2014.05.02 14:10:21 5: chip: vom client empfangen|direction: i2cread|nbyte: 2|reg: 18|i2caddress: 32
2014.05.02 14:10:21 5: chip: HWaccess I2CAddr: 20
2014.05.02 14:10:21 5: chip; Register 12 lesen - Inhalt: 00
2014.05.02 14:10:21 5: chip; Register 13 lesen - Inhalt: 00
2014.05.02 14:10:21 5: chip ->Client gefunden: mcp_20, I2Caddress: 32
2014.05.02 14:10:21 1: mcp_20 UpdReadings Register: 19, Inhalt: 0; RegA: 18, RegB: 19
2014.05.02 14:10:21 1: mcp_20 UpdReadings Register: 18, Inhalt: 0; RegA: 18, RegB: 19
:Nochmals:
So, habe auf der Console I2Cget 1 0x20 eingegeben, und habe als Antwort 0x04 erhalten, als ich dann in Fhem die Ausgänge nochmals definiert habe, so wie "Hajo23" auch schrieb, ging sofort die LED an, und auf der Webseite stand sofort dass der Ausgang gesetzt wurde
Habe nochmal nach einem Neustart die Register 0x00 und 0x01 ausgelesen, diese waren beide wieder bei 0xff, nachdem die Ports wieder in Fhem zugeordnet wurden, stand 0x00 auf 0x00 ;D
Gruß
Christian
hier (http://forum.fhem.de/index.php/topic,23164.0.html) ist eine Neue Version des MCP23017 Moduls
Bitte dort weiterdiskutieren.
Dieser Thread sollte dem Modul für die Pi GPIOs vorbehalten sein.
Mein Fehler ist mit der neuen Version des Moduls behoben.
Ich habe meine funktionieren Beispielkonfiguration hier (http://forum.fhem.de/index.php/topic,23164.msg164846.html#msg164846) bereitgestellt.
Hallo,
Ich benutze das GPIO Moul bereits zum einlesen von Tastern. Das funktioniert auch super.
Jetzt bin ich auf der Suche nach einer Lösung für das Erkennen eines Longpress eines Tasters.
Die Suchfunktion hat mich da nicht wirklich weiter gebracht.
Kann mir da jemand weiterhelfen. Link zu einer Beschreibung bzw. Code-Bsps wären top.
Danke
Zitat von: Hoeness am 10 Juli 2014, 10:38:56
Hallo,
Ich benutze das GPIO Moul bereits zum einlesen von Tastern. Das funktioniert auch super.
Jetzt bin ich auf der Suche nach einer Lösung für das Erkennen eines Longpress eines Tasters.
Die Suchfunktion hat mich da nicht wirklich weiter gebracht.
Kann mir da jemand weiterhelfen. Link zu einer Beschreibung bzw. Code-Bsps wären top.
Danke
Schau dir mal readingsproxy an.
Das könnte was für dich sein.
Wenn interrupt auf both gesetzt ist dann wird bei langem Tastendruck bereits das reading longpress gesetzt.
Hallo,
ich moechte gerne ueber mein FHEM auf dem Raspberry PI den Brennersuastnd meiner Heizung ueberwachen. Um nicht auf Loesungen wie der modifizierten MAX Sensoren auszuweichen, habe ich es mit einer pragmatischen Loesung versucht und einfach ein altes Steckernetzteil (Handyladegeraet) parallel zum Betriebsstundenzaehlerausgang der Heizung gelegt. Der bekommt - wenn der Brenner laeuft - 230 V und erzeugt ein 5V Gleicspannungssignal, und liefert nchts wenn der Brenner aus ist. MIt einer Widerstandskaskade wurden die 5V auf die fuer GPIO ports erlaubten 3.3V gebracht und an GPIO 23 angegeschlossen. Und parallel zur Widerstandskaskade wurde noch ein 1,5k Widerstand gelegt, damit das Netzteil nach ausschalten in weniger als einer Sekunde keine Signifikante Spannung liefert.
Hier die Settings
Dann habe ich erst mit GPIO24 einen Test gemacht
define Heizung RPI_GPIO 23
attr Heizung direction input
attr Heizung interrupt both
attr Heizung pud_resistor down
attr Heizung restoreOnStartup yes
attr Heizung room GPIO
define Heizung_FileLog FileLog ./log/Heizung-%Y.log Heizung
attr Heizung_FileLog logtype text
attr Heizung_FileLog room GPIO
Der auf output gestellte GPIO Port24 wurde mit 6k Widerstand direkt an GPIO 23 angeschlossen und je nach Zustand folgt der Heizungsstatus dem Port 24.
Nachdem ich aber das mit der Heizung verkoppelte Netzteil an Port angeschlossen habe, bekomme ich ich aber nicht nur Wechsel ein / aus, sondern eine Kaskade von off:
2014-07-21_12:30:28 Heizung Pinlevel: low
2014-07-21_12:30:28 Heizung off
2014-07-21_12:30:46 Heizung Pinlevel: high
2014-07-21_12:30:46 Heizung on
2014-07-21_12:30:57 Heizung Pinlevel: low
2014-07-21_12:30:57 Heizung off
2014-07-21_12:31:34 Heizung Pinlevel: low
2014-07-21_12:31:34 Heizung off
2014-07-21_12:31:58 Heizung Pinlevel: low
2014-07-21_12:31:58 Heizung off
2014-07-21_12:32:03 Heizung Pinlevel: low
2014-07-21_12:32:03 Heizung off
2014-07-21_12:32:03 Heizung Pinlevel: low
2014-07-21_12:32:03 Heizung off
2014-07-21_12:32:03 Heizung Pinlevel: low
2014-07-21_12:32:03 Heizung off
2014-07-21_12:32:03 Heizung Pinlevel: low
2014-07-21_12:32:03 Heizung off
2014-07-21_12:32:03 Heizung Pinlevel: low
2014-07-21_12:32:03 Heizung off
2014-07-21_12:32:03 Heizung Pinlevel: low
2014-07-21_12:32:03 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:04 Heizung Pinlevel: low
2014-07-21_12:32:04 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:05 Heizung Pinlevel: low
2014-07-21_12:32:05 Heizung off
2014-07-21_12:32:06 Heizung Pinlevel: low
2014-07-21_12:32:06 Heizung off
2014-07-21_12:32:06 Heizung Pinlevel: low
2014-07-21_12:32:06 Heizung off
2014-07-21_12:32:07 Heizung Pinlevel: low
2014-07-21_12:32:07 Heizung off
2014-07-21_12:32:07 Heizung Pinlevel: low
2014-07-21_12:32:07 Heizung off
2014-07-21_12:32:09 Heizung Pinlevel: low
2014-07-21_12:32:09 Heizung off
2014-07-21_12:32:09 Heizung Pinlevel: low
2014-07-21_12:32:09 Heizung off
2014-07-21_12:32:10 Heizung Pinlevel: low
2014-07-21_12:32:10 Heizung off
2014-07-21_12:32:10 Heizung Pinlevel: low
2014-07-21_12:32:10 Heizung off
2014-07-21_12:32:10 Heizung Pinlevel: low
2014-07-21_12:32:10 Heizung off
2014-07-21_12:32:11 Heizung Pinlevel: low
2014-07-21_12:32:11 Heizung off
2014-07-21_12:32:11 Heizung Pinlevel: low
2014-07-21_12:32:11 Heizung off
2014-07-21_12:32:12 Heizung Pinlevel: low
2014-07-21_12:32:12 Heizung off
2014-07-21_12:32:12 Heizung Pinlevel: low
2014-07-21_12:32:12 Heizung off
2014-07-21_12:32:12 Heizung Pinlevel: low
2014-07-21_12:32:12 Heizung off
2014-07-21_12:32:12 Heizung Pinlevel: high
2014-07-21_12:32:12 Heizung on
2014-07-21_12:34:17 Heizung Pinlevel: high
2014-07-21_12:34:17 Heizung on
2014-07-21_12:34:17 Heizung Pinlevel: low
2014-07-21_12:34:17 Heizung off
2014-07-21_12:48:47 Heizung Pinlevel: low
Zur Erlauterung: die ersten 3 Schaltungen (12:30) waren der Test mit GPIO24. Die weiteren Eintraege entstanden, als die Heizung ansprang und die 3.3V am GPIO23 anlagen. Erst nach 40 Sekunden war zwei "on" MEsswerte zu sehen. Erst dachte ich, dass auf dem Eingang viele Unterbrechungen liegen, aber dann haetten doch auch immer high/low bzw. on/off im Wechsel erfolgen muessen, oder? Auch mit gpiscope gemessen zeigt GPIO23 nur high values und keine Einbrueche (die ggf. theoretisch schneller erfolgen koennen als gpiscope aufloesen kann.
Was kann es noch sein, dass diese vielen low messwerte erzeugt?
Gruss vom Nordlich aus Koelle
Zitat von: einnordlicht am 21 Juli 2014, 13:46:30
Zur Erlauterung: die ersten 3 Schaltungen (12:30) waren der Test mit GPIO24. Die weiteren Eintraege entstanden, als die Heizung ansprang und die 3.3V am GPIO23 anlagen. Erst nach 40 Sekunden war zwei "on" MEsswerte zu sehen. Erst dachte ich, dass auf dem Eingang viele Unterbrechungen liegen, aber dann haetten doch auch immer high/low bzw. on/off im Wechsel erfolgen muessen, oder? Auch mit gpiscope gemessen zeigt GPIO23 nur high values und keine Einbrueche (die ggf. theoretisch schneller erfolgen koennen als gpiscope aufloesen kann.
Was kann es noch sein, dass diese vielen low messwerte erzeugt?
Gruss vom Nordlich aus Koelle
Zusammengefasst funktioniert es, wenn Du den GPIO24 als Quelle nutzt, aber nicht mit dem Netzteil als Quelle. Richtig?
Deine Konfiguration ist soweit richtig (restoreOnStartup sollte last sein, aber yes funktioniert im mom auch noch)
Ich teile Deine Vermutung, das gpioscope (ist das eine SW Lösung, die direkt auf dem Pin misst?) wird zu langsam sein.
Kannst Du mit einem richtigen Oszi nachmessen?
Die Tatsache, das Du immer nur low misst legt nahe, das auf der Leitung Glitches drauf sind. Ist die Leitung zum Brenner lang?
Ein Glitch kann Problemlos einen Interrupt auslösen. Beim Messen am GPIO ist die Spannung dann aber schon wieder normal
Ein Tiefpass könnte da helfen (oder auch das Attribut event_on_change_reading .... aber das ist in diesem Fall sehr unsauber, da die permanenten Interrups das System auslasten).
Das mit den ersten High Werten nach 40s verstehe ich nicht. Kommen die 40s zu spät?
Mit Widerstandskaskade meinst Du sicher Spannungsteiler...allerdings wir Dir ein dazu parallesgeschalteter Widerstand das Teilungsverhältnis verbiegen. Es ist besser, den Spannungsteiler einfach niederohmiger zu machen.
ZitatZusammengefasst funktioniert es, wenn Du den GPIO24 als Quelle nutzt, aber nicht mit dem Netzteil als Quelle. Richtig?
Korrekt. Alles sauber, jeder Schaltvorgang fuehrt zu einem Interrupt und einem korrektem Status.
ZitatIch teile Deine Vermutung, das gpioscope (ist das eine SW Lösung, die direkt auf dem Pin misst?) wird zu langsam sein.
Kannst Du mit einem richtigen Oszi nachmessen?
Habe ich leider nicht. piscope ist von der http://abyz.co.uk/rpi/pigpio (http://abyz.co.uk/rpi/pigpio) Seite und ist eigentlich ganz gut, aber wahrscheinlich nicht gut genug...
Mal sehen, vielleicht setze ich sicherheits/probehalber einen kleinen Glaettungskondensator daneben.
Die Leitung zum Brenner ist 30cm zum Netzgeraet und dann 80cm zum Raspberry. Sollte eigentlich ok sein.Wenn ich es testweise direkt einschalte, ist die Spannung instantan da, beim Abschalten verschwindet die Restspannung innerhalb von 0,5sec (alledings am Digitalvoltmeter, denen sieht man das ja nicht so doll an). Aber 40 sec und so 50 ueberfluessige Flanken halte ich beim Einschalten fuerkein gutes Signal, zumal ich dann dann noch das Betriebsstundenzaehler Plugin damit betreiben moechte.
Ach ja, tschuldigung, ich meinte in der Tat Spannungsteiler. Ich hatte aber nur 5 Stueck zu 1,5k zur Hand und wollte 5:3 Teilen, also 5 in Reihe und bei 3 abgegriffen. Danke fuer den Hinweis, aber so wie ich die Ohmschen Gesetze erinnere, verbiegt ein dazu (also zu allen 5 in Reihe geschalteter Widerstaend) parallelgeschalteter Widerstand nicht den Spannungsteiler, sondern senkt nur den Gesamtwiderstand:
Ein Zweig mit 5 in Serie 1.5 hat 5 * 1,5 =7.5k. Parallel dazu einen 1.5k macht Gesamt 1.25k (1/Rges = 1/R1 + 1/R2)... ;) (ich hoffe, da habe ich mich jetzt nicht voellig blamiert, aber ich war so erstaunt, dass ich fast 30 Jahre spaeter es noch wusste)
Vielen Dank fuer die schnelle Antwort und noch mehr fuer die Erstellung des Plugin!
Zitat von: einnordlicht am 21 Juli 2014, 21:53:37
Korrekt. Alles sauber, jeder Schaltvorgang fuehrt zu einem Interrupt und einem korrektem Status.
Habe ich leider nicht. piscope ist von der http://abyz.co.uk/rpi/pigpio (http://abyz.co.uk/rpi/pigpio) Seite und ist eigentlich ganz gut, aber wahrscheinlich nicht gut genug...
Gut für mich...dann liegt es schonmal nicht am Modul ;)
Zitat von: einnordlicht am 21 Juli 2014, 21:53:37
Mal sehen, vielleicht setze ich sicherheits/probehalber einen kleinen Glaettungskondensator daneben.
Die Leitung zum Brenner ist 30cm zum Netzgeraet und dann 80cm zum Raspberry. Sollte eigentlich ok sein.Wenn ich es testweise direkt einschalte, ist die Spannung instantan da, beim Abschalten verschwindet die Restspannung innerhalb von 0,5sec (alledings am Digitalvoltmeter, denen sieht man das ja nicht so doll an). Aber 40 sec und so 50 ueberfluessige Flanken halte ich beim Einschalten fuerkein gutes Signal, zumal ich dann dann noch das Betriebsstundenzaehler Plugin damit betreiben moechte.
Ich habe keine Ahnung, wie der Brenner aufgebaut ist. Aber vielleicht gibt es so eine Art Testpulse, die überprüfen, ob ein Brenner angeschlossen ist. Die könnten dann natürlich überkoppeln. Schließlich ist der Anschluss ausschließlich für einen Brenner gedacht. Das Netzteil an sich sollte ja bereits eine Glättung besitzen.
Alternativ könntest Du einen Optokoppler verwenden. Der Aufwand ist nur geringfügig größer.
Zitat von: einnordlicht am 21 Juli 2014, 21:53:37
Ach ja, tschuldigung, ich meinte in der Tat Spannungsteiler. Ich hatte aber nur 5 Stueck zu 1,5k zur Hand und wollte 5:3 Teilen, also 5 in Reihe und bei 3 abgegriffen. Danke fuer den Hinweis, aber so wie ich die Ohmschen Gesetze erinnere, verbiegt ein dazu (also zu allen 5 in Reihe geschalteter Widerstaend) parallelgeschalteter Widerstand nicht den Spannungsteiler, sondern senkt nur den Gesamtwiderstand:
Ein Zweig mit 5 in Serie 1.5 hat 5 * 1,5 =7.5k. Parallel dazu einen 1.5k macht Gesamt 1.25k (1/Rges = 1/R1 + 1/R2)... ;) (ich hoffe, da habe ich mich jetzt nicht voellig blamiert, aber ich war so erstaunt, dass ich fast 30 Jahre spaeter es noch wusste)
Das hast Du Dir gut gemerkt :D. Ich hatte es so verstanden, das die zusätzlichen 1,5k direkt am GPIO angebracht sind.
Ach ja, was so 50 oder 100 microF doch die Wogen glaetten koennen. Nach dem ich eine alte IDE Bus Ethernetkarte geschlacht und um einen Kondensator beraubt habe (Ich muss mich echt mal wieder eine Restekiste zulegen), der dann parallel zum 5V Ausgang gelegt wurde, funzt der Geber genauso wie er sollte: pro Ein / Ausschaltvorgang ein Signal.
Also alles super, nix mecker am Modul! Ein rauf mit Mappes. Und ein zufriedener Nutzer mehr.
Ich muss mir mal die Struktur dieser Module anschauen, vielleicht kann ich ja auch mal etwas der Gemeinschaft zurueckliefern.
Und wie gesagt: nach dem die Daten sauber reinkommen, kann ich mich mit dem Betriebstundenzaehler Plugin an die Statistik und die Graphen machen.
Gruss aus Koelle vom Nordlicht (bei dem Wetter mit Heimweh)
Hi,
kann mir hier bitte jemand weiterhelfen ? Ich verwende das GPIO Modul Interruptgesteuert um die Ereignisse mit dem Hourcounter auszuwerten. Geht auch sehr gut, allerdings sind die Plots nie aktuell , weil oft zu lange keine Ereignisse stattgefunden haben. Der Hourcounter reagiert nur auf on off..Wie kann ich es anstellen, dass das letzte "on" oder "off" regelmässig wiederholt wird z.b. alle 15 minuten und um 23:59....Mit dem Attribut poll intervall gehts leider nicht...Mit dem addlog habe ich es auch nicht hinbekommen
Für den Fall dass ich mich undeutlich ausgedrückt habe, kopiere ich die relevanten Teile der fhem.cfg hinein...
mit bestem Dank
Tom
define Pin18 RPI_GPIO 24
attr Pin18 active_low yes
attr Pin18 alias BRENNER
attr Pin18 debounce_in_ms 250
attr Pin18 devStateIcon on.*:icoHEIZUNG off.*:icoHeizungAn
attr Pin18 direction input
attr Pin18 interrupt both
attr Pin18 pud_resistor off
attr Pin18 restoreOnStartup yes
define CN.BRENNER HourCounter Pin18:on Pin18:off
define SHUTTER.BRENNER.event notify SHUTTER.BRENNER:onoff.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}
define SVG_FileLog_SHUTTER.BRENNER SVG FileLog_SHUTTER.BRENNER:SVG_FileLog_SHUTTER.BRENNER:CURRENT
define SVG_CN.BRENNER.FileDay SVG CN.BRENNER.FileDay:SVG_CN.BRENNER.FileDay:CURRENT
Hallo Tom,
Zitat von: backbone10 am 29 Oktober 2014, 18:12:20
Wie kann ich es anstellen, dass das letzte "on" oder "off" regelmässig wiederholt wird z.b. alle 15 minuten und um 23:59....Mit dem Attribut poll intervall gehts leider nicht...Mit dem addlog habe ich es auch nicht hinbekommen
Was wird in dem Plot angezeigt? Die kummulierten Betriebsstunden, oder einfach die An-Aus-Zeiten?
Das Attribut poll_intervall erzeugt im angegebenen Intervall ein Ereignis, aber wenn der HourCounter dies filtert, müsstest Du auch bei diesem Modul ansetzen.
Wenn Du nur die An-Aus-Zeiten visualisieren möchtest dann kannst Du das auch direkt von Deinem Pin18 machen. Dann funktioniert auch poll_intervall
Grüße
Klaus
Hallo,
nun bräuchte ich hier auch bitte mal kurz Hilfe. Ich überwache einen schnurgebundenen Kontakt wie folgt:
define PIN18 RPI_GPIO 18
attr PIN18 active_low no
attr PIN18 direction input
attr PIN18 eventMap low:open high:closed
attr PIN18 interrupt both
attr PIN18 restoreOnStartup yes
attr PIN18 stateFormat Pinlevel
Funktioniert einwandfrei. Jedes Öffnen und Schließen löst einen Event aus, ausgewertet wird der Pinlevel, der auf open/closed gemapt wird.
Mein Problem: das restoreOnStartup. Ich möchte, dass beim Startup eben nicht einfach was zurückgeschrieben wird sondern anhand des tatsächlichen Pinlevels neu gesetzt wird. Es könnte ja sein, dass während der Down-Zeit von fhem eine Zustandsänderung eingetreten ist. Um diese festzustellen, müsste beim Start von fhem bzw. besser beim Initialisieren des Devices ein set <dev> readValue Pinlevel ausgeführt werden.
Je nachdem, was ich bei restoreOnStartup einstelle, in der jetzigen Modul-Version (bzw. bei meiner o.a. Konfiguration) werden nach einem fhem-Neustart bei einer Zustandsänderung zwar die Readings aktualisiert, nicht jedoch das Internal STATE.
Was kann ich tun?
Hallo Klaus,
danke dass du mir auch diesmal weiterhilfst. Im Plot zeigt er ab dem letzten off Ereignis gar nichts mehr an, der Plot wir erst beim nächsten ON Ereignis wieder aktualisiert und die Daten für die Zeit dazwischen "nachgezeichnet". Daher hat auch das poll intervall nicht geholfen, er hat ja nur wieder "OFF" reported, und das motiviert den Hour Counter nicht zum weiterarbeiten. Ich denke das kann man - so wie du es gesagt hast - nur im Hour Counter lösen...
Danke jedenfalls nochmals
Grüße
Tom
Zitat von: klausw am 03 November 2014, 12:35:48
Hallo Tom,
Was wird in dem Plot angezeigt? Die kummulierten Betriebsstunden, oder einfach die An-Aus-Zeiten?
Das Attribut poll_intervall erzeugt im angegebenen Intervall ein Ereignis, aber wenn der HourCounter dies filtert, müsstest Du auch bei diesem Modul ansetzen.
Wenn Du nur die An-Aus-Zeiten visualisieren möchtest dann kannst Du das auch direkt von Deinem Pin18 machen. Dann funktioniert auch poll_intervall
Grüße
Klaus
Zitat von: Ralli am 03 November 2014, 15:12:30
Je nachdem, was ich bei restoreOnStartup einstelle, in der jetzigen Modul-Version (bzw. bei meiner o.a. Konfiguration) werden nach einem fhem-Neustart bei einer Zustandsänderung zwar die Readings aktualisiert, nicht jedoch das Internal STATE.
Was kann ich tun?
Pobiere mal angehängte Version aus.
restoreOnStartup ist für normale Eingänge meiner Meinung nach nicht notwendig
Ich habe das Modul erweitert, das für Inputs (die toggletostate nicht nutzen) beim starten automatisch der aktuelle Wert vom Pin übernommen wird.
Wenn es funktioniert werde ich es einchecken.
Grüße
Klaus
Herzlichen Dank, dass Du Dich der Sache annimmst!
Habe die 51_RPI_GPIO ersetzt, dann fhem gestoppt, nach dem Stoppen eine Alarmschleife unterbrochen und dann fhem neu gestartet.
Die Readings sind aktualisiert, leider aber nicht das Internal STATE. Anbei ein Bildschirmfoto, auf dem man sieht, dass STATE und state nicht zusammen passen - dazu muss man allerdings noch wissen, dass ich den STATE wie folgt definiere:
attr GPIO21 stateFormat {ReadingsVal("GPIO21","Pinlevel",0) eq "low" ? "open" : "closed"}
... also wenn Strom anliegt, Pinlevel high, dann ist die Schleife geschlossen und STATE closed. Wenn kein Strom anliegt, Pinlevel low, dann ist Schleife unterbrochen und STATE open.
Edit:
Das tritt umgekehrt auch auf, wenn ich fhem stoppe, eine zuvor unterbrochene Alarmschleife wieder schließe und dann fhem starte.
Edit2:
Führe ich dann manuell ein "set GPIO21 readValue Pinlevel" aus, liest er brav den tatsächlichen Pinlevel ein und setzt state/STATE.
Edit3:
Das steht im Logfile, wenn vor dem Beenden von fhem Pinlevel low, wenn fhem beendet Eingang beschalten, dann fhem starten:
2014.11.06 12:49:15 5: Cmd: >setstate GPIO21 closed<
2014.11.06 12:49:15 4: GPIO21: STATE kann auf closed wiederhergestellt werden 2014-11-06 12:49:15
2014.11.06 12:49:15 5: Cmd: >setstate GPIO21 2014-11-06 12:46:55 Longpress on<
2014.11.06 12:49:15 4: GPIO21: Longpress kann auf on wiederhergestellt werden 2014-11-06 12:46:55
2014.11.06 12:49:15 4: INPUT GPIO21: STATE von Pin lesen
2014.11.06 12:49:15 5: GPIO21, in fileaccess: value
2014.11.06 12:49:15 4: INPUT GPIO21: Pinwert ist: on
2014.11.06 12:49:15 5: Cmd: >setstate GPIO21 2014-11-06 12:48:20 Pinlevel low<
2014.11.06 12:49:15 4: GPIO21: Pinlevel kann auf low wiederhergestellt werden 2014-11-06 12:48:20
2014.11.06 12:49:15 4: INPUT GPIO21: STATE von Pin lesen
2014.11.06 12:49:15 5: GPIO21, in fileaccess: value
2014.11.06 12:49:15 4: INPUT GPIO21: Pinwert ist: on
2014.11.06 12:49:15 5: Cmd: >setstate GPIO21 2014-11-06 12:47:46 state off<
2014.11.06 12:49:15 4: GPIO21: state kann auf off wiederhergestellt werden 2014-11-06 12:47:46
2014.11.06 12:49:15 4: INPUT GPIO21: STATE von Pin lesen
2014.11.06 12:49:15 5: GPIO21, in fileaccess: value
2014.11.06 12:49:15 4: INPUT GPIO21: Pinwert ist: on
Zitat von: Ralli am 06 November 2014, 13:30:25
Herzlichen Dank, dass Du Dich der Sache annimmst!
Habe die 51_RPI_GPIO ersetzt, dann fhem gestoppt, nach dem Stoppen eine Alarmschleife unterbrochen und dann fhem neu gestartet.
Die Readings sind aktualisiert, leider aber nicht das Internal STATE. Anbei ein Bildschirmfoto, auf dem man sieht, dass STATE und state nicht zusammen passen - dazu muss man allerdings noch wissen, dass ich den STATE wie folgt definiere:
attr GPIO21 stateFormat {ReadingsVal("GPIO21","Pinlevel",0) eq "low" ? "open" : "closed"}
geht es denn, wenn Du das Attribut stateFormat löschst?
Ja, dann funktioniert es!
Allerdings generiert er keinen Event bzw. triggert nichts an.
Dann sollte es auch so gehen:
attr GPIO21 stateFormat {state eq "off" ? "open" : "closed"}
Den Pinvalue könnte ich allerdings auch noch mit beim starten schreiben...
Nein, das gibt einen Fehler.
... leider wird bei der jetzigen Lösung beim initialen Setzen des Pinlevels auch kein Event getriggert.
Problem:
Wie gesagt, Alarmschleife. Wenn fhem läuft und auf einmal wird ein Pinlevel low bedeutet das, dass irgendwo ein Fenster aufgegangen ist. Kann ich wunderbar mit einem Notify oder DOIF abfangen. Wenn nun alles ordnungsgemäß geschlossen, dann ist fhem warum auch immer kurz offline und in der Zeit wird ein Fenster geöffnet, fhem startet wieder, dann wird jetzt der Status zwar aktuell ausgelesen und übernommen, jedoch wird kein Event generiert. Die Aktion auf ein plötzlich geöffnetes Fenster bleibt dann aus.
Ich kenne mich mit der Systematik von den Modulen und der fhem-Internas nicht aus. Aber ich würde es (laienhaft) so machen:
Beim Zurückschreiben der Werte in die Readings prüfen, ob der aktuelle Pinlevel (und damit ja auch state) von dem zurückzuschreibenden Wert abweicht. Wenn ja, nicht nur den aktuellen Wert schreiben sondern auch den Event triggern (gemäß dem interrupt-Attribut).
Zitat von: Ralli am 06 November 2014, 14:58:42
Nein, das gibt einen Fehler.
... leider wird bei der jetzigen Lösung beim initialen Setzen des Pinlevels auch kein Event getriggert.
Mit an Sicherheit grenzender Wahrscheinlichkeit geht das so auch nicht. Im Grunde liegt kein Triggervent vor. Es wird einfach ein Zustand beim laden übernommen. Ich übergebe im Modul beim Starten die Werte an State genauso, wie auch im Interruptfall.
Beim hochfahren von FHEM werden vermutlich noch keine Events ausgelöst ...wie auch, es wird schließlich alles erst geladen.
Das triggern machst Du sicher über notify, oder?
Darauf habe ich keinen Einfluss, das läuft über die Mainloop.
Aber:
ich habe jetzt einen einmaligen Timer eingefügt, der macht 60s nach dem booten eine Leseaktion
schau mal, ob dir das hilft
Danke.
Ich glaube, das ist der richtige Ansatz, kann es aber nun erst morgen probieren. Sollte es so noch nicht funktionieren, werde ich mal experimentieren, ob es mit dem einmaligen Timer klappt, OHNE das vorher der Pinlevel gemäß aktueller Überprüfung gesetzt wird (denn wenn Du gemäß aktuellem Auslesen die Readings setzt und danach nochmal einen Poll machst, ändern sich ja die Readings nicht mehr und damit würde u.U. dann ja auch kein Event ausgelöst. Aber, wie gesagt, dafür bin ich nicht tief genug im Code und der Systematik drin.
Ich gebe Rückmeldung!
Der einmalige Timer ist schon im Modul selbst eingebaut. Das notify wird trotzdem ausgelöst, auch wenn sich der Wert nicht ändert. Das kannst Du auf der Detailseite vom GPIO sehen, wenn Du sie vor Ablauf der ersten Minute aufrufst.
Evtl.musst du dein Notify anpassen
Hallo Klaus,
ich habe das Modul wie beigefügt modifiziert.
Grundlegende Überlegung: Das Zurückschreiben von Readings nach fhem-Restart anhand des Statefiles ist m.E. bei einem als Input definierten GPIO unsinnig - ein Input wird halt nicht durch fhem beeinflusst sondern von extern.
Ich habe daher nun definiert, dass wenn restoreOnStartup auf no (oder off) steht (oder gar nicht definiert ist), ein Poll unmittelbar getimert wird. Bei einem direkten Funktionsaufruf werden keine Events generiert, bei einem getimerten Aufruf schon ??? . Wenn restoreOnStartup auf yes (oder on) steht, werden die Readings anhand des aktuellen tatsächlich anliegenden Wertes aktualisiert und es werden KEINE Events ausgelöst. Ein klassisches Zurückschreiben durch das Statefile wird nicht vernichtet, wenn restoreOnStartup auf last steht.
Zitat von: Ralli am 07 November 2014, 10:00:08
ich habe das Modul wie beigefügt modifiziert.
schaue gleich mal rein...
funktionierte denn meine Version nicht?
Zitat von: Ralli am 07 November 2014, 10:00:08
Grundlegende Überlegung: Das Zurückschreiben von Readings nach fhem-Restart anhand des Statefiles ist m.E. bei einem als Input definierten GPIO unsinnig - ein Input wird halt nicht durch fhem beeinflusst sondern von extern.
Jein, der Counter und der Toggle sollten wiederhergestellt werden.
Und wenn toggletostate gesetzt ist, dann natürlich auch state (soll schließlich eine Tasterfunktion nachbilden)
Zitat von: Ralli am 07 November 2014, 10:00:08
Ich habe daher nun definiert, dass wenn restoreOnStartup auf no (oder off) steht (oder gar nicht definiert ist), ein Poll unmittelbar getimert wird. Wenn restoreOnStartup auf yes (oder on) steht, werden die Readings anhand des aktuellen tatsächlich anliegenden Wertes aktualisiert und es werden KEINE Events ausgelöst. Ein klassisches Zurückschreiben durch das Statefile wird nicht vernichtet, wenn restoreOnStartup auf last steht.
restoreOnStartup hat du, vermute ich, falsch verstanden:
- no -> kein wiederherstellen
- off -> auf off wiederherstellen
- on -> auf on wiederherstellen
- last -> auf letzten wert
- yes ist ein Überbleibsel aus Kompatibilitätsgründen (werde ich jetzt entfernen)
Ich werde die commandref dazu noch verfeinern.
Für Input sollte generell der Status am Pin hergezogen werden (ausser bei toggletostate)
Zitat von: Ralli am 07 November 2014, 10:00:08
Bei einem direkten Funktionsaufruf werden keine Events generiert, bei einem getimerten Aufruf schon ??? .
die Events können beim FHEM sStart nicht geladen werden, da zur Ladzeit des Pins das dazugehörige notify noch nicht geladen ist. Daher läuft es ins leere. Der Timer verschiebt es einfach.
Das auslesen über state ist sowieso mist -> wenn es kein statefile vorhanden ist dann wird es auch nciht ausgelöst
Zitat von: klausw am 07 November 2014, 12:16:12
schaue gleich mal rein...
funktionierte denn meine Version nicht?
Jein - nicht so, wie gewünscht bzw. nicht mit den jetzt eingebauten Möglichkeiten.
Zitat
Jein, der Counter und der Toggle sollten wiederhergestellt werden.
Und wenn toggletostate gesetzt ist, dann natürlich auch state (soll schließlich eine Tasterfunktion nachbilden)
Das habe ich auch so gelassen.
Zitat
restoreOnStartup hat du, vermute ich, falsch verstanden:
- no -> kein wiederherstellen
- off -> auf off wiederherstellen
- on -> auf on wiederherstellen
- last -> auf letzten wert
- yes ist ein Überbleibsel aus Kompatibilitätsgründen (werde ich jetzt entfernen)
Nein, hab ich schon richtig verstanden, kann man aber m.M. nicht so auf GPIOs anwenden, die auf Input konfiguriert sind, da das einfach nicht "passt". Für einen Input bekommen die Einstellmöglichkeiten einfach andere Bedeutungen.
Zitat
Für Input sollte generell der Status am Pin hergezogen werden (ausser bei toggletostate)
Genau.
Zitat
die Events können beim FHEM sStart nicht geladen werden, da zur Ladzeit des Pins das dazugehörige notify noch nicht geladen ist. Daher läuft es ins leere. Der Timer verschiebt es einfach.
Ok!
Zitat
Das auslesen über state ist sowieso mist -> wenn es kein statefile vorhanden ist dann wird es auch nciht ausgelöst
Richtig! Das ist noch ein Manko.
Edit:
Ich habe aber noch eine andere Idee.
Die Funktion RPI_GPIO_State wird ja nach meinem Verständnis nur aufgerufen, wenn mittels Statefile die gespeicherten Readings/Stati zurückgeschrieben werden müssen.
Dann müsste eigentlich bei einem Input nur der zu setzende Wert mit dem tatsächlichen Pinlevel verglichen werden. Und nur wenn der abweicht, wird ein RPI_GPIO_Poll getimert.
So wie angehangen - ist aber noch nicht getestet!
Das ist aber immer noch das gleiche Problem.
Wenn im Statefile keine state Variable für den Input existiert, dann wird die Stateroutine auch nicht aufgerufen.
Obwohl dann ist es halt so.
Ich könnte den Timer auch ins define verlegen. Allerdings trifft der Timer dann auch für Outputs zu. Das wiederum hat den NAchteil, das die Timestamp geändert wird. Diese sollte aber den letzten Schaltzeitpunkt zeigen.
Fazit, ich werde es in der Stateroutine lassen.
Was die restoreOnStartup Attribute betrifft, werde ich sie bei inputs ausschießlich für toggle verwenden.
Was ich noch nicht verstanden habe, wieso Du bei den Inputs einmal ein event auslösen möchtest und einmal nicht.
Es nur auszulösen, wenn gespeicherter Wert und reeller Wert unterschiedlich sind finde ich da sinnvoller.
(was das Dein Problem? Also das immer getriggert wurde, auch wenn sich der Wert nicht geändert hat?)
Ganz einfach:
Für mich ist es am sinnvollsten, wenn ein Event nur ausgelöst wird, wenn auch tatsächlich (in der Downzeit) eine Statusänderung stattgefunden hat.
Ich habe ein notify oder doif auf xy:open bzw. xy:off sitzen. Wenn das zur Laufzeit von fhem ausgelöst wurde, braucht es nicht neu ausgelöst werden, wenn dann fhem weg war und wieder kommt.
Ansonsten waren die in meiner ersten Version eingebauten Möglichkeiten eben nur Möglichkeiten für diejenigen, die warum auch immer so etwas brauchen. Denkbar: Normalerweise werden zur Laufzeit von fhem diverse Dinge über die Inputs getriggert. Wenn fhem nun down geht und wieder kommt und in der Zwischenzeit sich an den Inputs was getan hat, kann es ja sein, dass nicht jeder auf jeden Fall dann auch noch eine Aktion auslösen lassen möchte - während der Laufzeit von fhem aber sehr wohl.
Soo, folgende Version übernimmt die Pinwerte. Wenn Pinwerte mit denen aus dem Statefile nicht übereinstimmen dann wird ein Timer gestartet um ein notify auslösen zu können. Sonst werden nur die Werte übernommen.
Das ganze funktioniert immer, wenn restoreOnStartup nicht "no" ist.
Schau mal obs so passt für dich
Lösche bitte Deine alten Modulvorschläge, die irritieren nur :)
Hallo Klaus,
das wird langsam ;) . Aber ich glaube, er hat im letzten elsif vor dem Vergleich und im letzten else den alten Wert nicht in $sval?
Zitat von: Ralli am 07 November 2014, 18:11:53
Hallo Klaus,
das wird langsam ;) . Aber ich glaube, er hat im letzten elsif vor dem Vergleich und im letzten else den alten Wert nicht in $sval?
sollte schon, $sval wird vorher nicht neu geschrieben
Hi zusammen,
ich betreibe FHEM auf einem BBB mit Debian und habe mir dafür das Relay Cape (http://www.logicsupply.de/beaglebone-black/boards-cases-capes/cbb-relay/) von Logic Supply geholt. Das steuere ich mit RPI_GPIO (und Wiring Pi) an, was für die Eingänge auch gut klappt. Die beiden Relais reagieren aber nicht - das geht nur, wenn ich nach dem FHEM-Start die Direction manuell setze:
echo out > /sys/class/gpio/gpio65/direction
Beim Start geschieht nämlich merkwürdiges (das Device heißt GPIO_Relay1):
2014.11.06 22:00:07 5: GPIO_Relay1, in fileaccess: value 1
2014.11.06 22:00:07 5: GPIO_Relay1, in fileaccess: direction high
2014.11.06 22:00:07 4: GPIO_Relay1: direction ueber gpio utility einstellen
2014.11.06 22:00:07 4: GPIO_Relay1: direction gesetzt auf low
2014.11.06 22:00:07 4: OUTPUT GPIO_Relay1: STATE wiederhergestellt auf off
Und auf der Konsole lese ich derweil:
export: Invalid mode: low. Should be in or out
Soweit ich den Code verstanden habe, wird tatsächlich versucht, als Direction "low" bzw. zu setzen, wo IMHO "out" korrekt wäre (Funktion RPI_GPIO_fileaccess, Zeile 493):
$dir = ($args[1] == $lev ? "high" : "low")
Wenn ich das entsprechend ändere, läuft die Relais-Ansteuerung wunderbar - und ja: die Eingänge funktionieren dann auch noch ;)
$dir = ($args[1] == $lev ? "in" : "out")
Ich frage mich also, ob die genannte Zeile nicht einen Fehler enthält, den ich in diesem Fall gern korrigiert hätte. Falls ich das Modul irgendwie falsch benutze, dann sorry. Bis auf direction=output hatte ich allerdings keine besonderen Einstellungen vorgenommen.
Und bevor ich es vergesse: Das ist ein für mich sehr nützliches und (ansonsten ;)) toll funktionierendes Modul, vielen Dank dafür!
Gruß
fnord
Zitat von: fnord am 07 November 2014, 23:27:08
...
Und auf der Konsole lese ich derweil:
export: Invalid mode: low. Should be in or out
Soweit ich den Code verstanden habe, wird tatsächlich versucht, als Direction "low" bzw. zu setzen, wo IMHO "out" korrekt wäre (Funktion RPI_GPIO_fileaccess, Zeile 493):
Du hast es richtig verstanden. Es wird als direction "low" gesetzt. Ein schreiben von low in direction führt dazu, das der Pin als Output gesetzt wird und gleichzeitig auf Low (das soll kurzzeitiges schalten beim booten unterbinden ... für die Details musst Du mal diesen Tread ein Stück zurückverfolgen)
Jetzt scheint Dein Kernel dies nicht zu unterstützen.
Die Frage ist nun, ob Du eine exotische Distribution verwendest, oder ob es beim BBB generell nicht unterstützt wird. Versuche das doch mal herauszufinden :)
Da ich nur ein paar Pi's habe kann ich dazu nix sagen.
Notfalls müsste ich da noch ein attribut einbauen...wenn das überhaupt so einfach geht.
Danke für die prompte Rückmeldung! Also soetwas wie
echo high > /sys/class/gpio/gpio65/direction
funktioniert hier (Debian wie gesagt) durchaus. Wenn ich es (wiederum) richtig verstehe, wird doch aber an der Stelle das gpio-Tool (https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/) von Wiring Pi verwendet. Ich rate mal:
gpio export 65 low
...denn das liefert genau die zitierte Fehlermeldung auf der Konsole. Könnte es so sein?
Gruß
fnord
Zitat von: fnord am 08 November 2014, 00:57:56
Danke für die prompte Rückmeldung! Also soetwas wie
echo high > /sys/class/gpio/gpio65/direction
funktioniert hier (Debian wie gesagt) durchaus. Wenn ich es (wiederum) richtig verstehe, wird doch aber an der Stelle das gpio-Tool (https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/) von Wiring Pi verwendet. Ich rate mal:
gpio export 65 low
...denn das liefert genau die zitierte Fehlermeldung auf der Konsole. Könnte es so sein?
Ah, das Debain habe ich überlesen.
Wenn ich mit den Quellcode anschaue, kann das durchaus passieren. Das muss ich noch anpassen.
Aber es sollte trotzdem gehen. Das passiert nur, wenn der fhem user keine Schreibrechte auf die GPIOs hat.
Gibt es bei Dir eine gruppe namens gpio? und ist fhem Mitglied der selben?
Was zeigt "ls -l" im gpio65 Verzeichnis an?
Die Dateien für die Pins sind bei mir für den FHEM-Benutzer nicht schreibbar. Ich fand es wenig elegant, in die /etc/rc.local noch diverse Initialisierungen zu stopfen. Wiring Pi kann das ja sehr fein selbst erledigen. Wenn ich FHEM die Schreibrechte gebe, dann funktioniert es auch - in diesem Fall wird wohl der else-Zweig der Bedingung ab Zeile 511 genommen:
if ($fname eq "direction" && (not -w $file)) { #wenn direction und diese nicht schreibbar mit gpio utility versuchen
...
} else {
my $fh = IO::File->new("> $file");
...
Ich glaube, ich verstehe jetzt auch das Problem besser: In Zeile 496 wird ja RPI_GPIO_fileaccess rekursiv aufgerufen, um vor dem eigentlichen Setting zunächst die Direction zu setzen:
RPI_GPIO_fileaccess($hash, "direction", $dir);
$dir ist dabei "high" oder "low". Dieser Aufruf läuft bis zur o.g. Zeile 511, um dann entweder das gpio-Tool aufzurufen (if) oder den Pin direkt zu setzen (else, Zeilen 520ff). Das direkte Setzen mit high/low funktioniert (wie oben beschrieben), der gpio-Aufruf mit high/low aber eben nicht, wie in meinem letzten Posting geschildert! Mein Vorschlag: Zeile 513
RPI_GPIO_exuexpin($hash, $value);
ändern in
RPI_GPIO_exuexpin($hash, $value eq "high" ? "in" : "out");
Damit klappt es (bei mir) auch wenn die Pin-Rechte fehlen.
Gruß
fnord
Zitat von: fnord am 08 November 2014, 22:44:48
RPI_GPIO_exuexpin($hash, $value eq "high" ? "in" : "out");
Damit klappt es (bei mir) auch wenn die Pin-Rechte fehlen.
was ist dann, wenn der Pin auf low gesetzt werden soll?
ich schlage vor:
$dir = "out" if ( $dir eq ("high" || "low") );in Zeile 540 einfügen.
Teste das bitte mal.
Zitat$dir = "out" if ( $dir eq ("high" || "low") );
Das klappt leider nicht. Meine Perl-Kenntnisse sind ziemlich rudimentär, aber die Zeile bedeutet doch: "Wenn $dir 'high' oder 'low' enthält, dann setze es auf 'out'", korrekt? Was ich aber erreichen wollte war: "Wenn $dir 'high' enthält, dann setze es auf 'in', wenn es ansonsten "low" enthält, dann setze es auf 'out'". Ich denke, wir sind uns schon einig, und an Deinem Vorschlag erkenne ich, dass Du die Lösung gern in RPI_GPIO_exuexpin hättest. Mein Gegenvorschlag:
sub RPI_GPIO_exuexpin($$) { #export, unexport and direction Pin via GPIO utility
my ($hash, $dir) = @_;
my $sw;
if ($dir eq "unexport") {
$sw = $dir;
$dir = "";
} else {
$sw = "export";
if ($dir eq "high") {
$dir = "in";
} elsif ($dir eq "low") {
$dir = "out";
}
$dir = " ".$dir;
}
if ( defined(my $ret = RPI_GPIO_CHECK_GPIO_UTIL($gpioprg)) ) {
Log3 $hash, 1, "$hash->{NAME}: " . $ret;
} else {
my $exp = $gpioprg.' '.$sw.' '.$hash->{RPI_pin}.$dir;
$exp = `$exp`;
}
}
Das if-elsif habe ich eingefügt, Anfänger-style ;). Funktioniert hier sowohl für Ein- wie Ausgänge. Was hältst Du davon?
Gruß
fnord
was ich will, ist eventuelle Fehler ausbügeln 8)
Was Du vorschlägst macht für mich keinen Sinn.
Die Routine RPI_GPIO_exuexpin wird entweder für einen Input mit "in" und für einen Output mit "out" aufgerufen.
Zusätzlich halt noch über die State Funktion beim booten (was bei wiringpi nicht funktioniert) mit "high" oder "low" für einen Output.
Mit $dir = "out" if ( $dir eq ("high" || "low") ); sollte das glattgezogen sein.
Jedenfalls bedeutet sowohl "high" als auch "low" einen output
Hallo Klaus,
ich war Dir noch eine Rückmeldung schuldig.
Es klappt! Wenn restoreOnStartup nicht auf no steht, wird bei einem Start von fhem nur bei einem anderen Status des aktuellen Pinlevel gegenüber dem gespeicherten Status ein Event generiert, sonst nicht. So soll es sein.
Zitatwas ich will, ist eventuelle Fehler ausbügeln 8)
Gut, darin sind wir uns einig! Aber nochmal sorry - ich hatte diese high/low-Semantik missverstanden. Beides impliziert ja direction out und setzt nur zusätzlich den value. Dein Code
$dir = "out" if ( $dir eq ("high" || "low") );funktioniert allerdings nur für $dir="high". Nach etwas ausprobieren bin ich auf
$dir = "out" if ( $dir eq "high" || $dir eq "low" );gekommen. Ok?
Gruß
fnord
Zitat von: fnord am 10 November 2014, 12:32:52
Gut, darin sind wir uns einig! Aber nochmal sorry - ich hatte diese high/low-Semantik missverstanden. Beides impliziert ja direction out und setzt nur zusätzlich den value. Dein Code
$dir = "out" if ( $dir eq ("high" || "low") );
funktioniert allerdings nur für $dir="high". Nach etwas ausprobieren bin ich auf
$dir = "out" if ( $dir eq "high" || $dir eq "low" );
gekommen. Ok?
Gruß
fnord
oh, das kann gut sein, ich war nicht sicher, das mein Code ok ist, aber da es keine Fehlermeldungen gab dachte ich es funktioniert.
Macht ja nix, wie du siehst macht jeder Fehler 8)
Dein Vorschlag funktioniert bei Dir vollstandig?
Dann baue ich ihn einfach ein.
Ja, die Relais knacken wie gewünscht. Freut mich, dass ich etwas beitragen konnte, womit wir beide zufrieden sind! ;D
Gruß
fnord
Änderungen in restoreOnStartup und für gpio utility sind eingecheckt
Daumen hoch! Danke.
ZitatÄnderungen in restoreOnStartup und für gpio utility sind eingecheckt
Update, restart, läuft. 8)
Gruß
fnord
Habe da mal eine kurze Frage bzgl des "neuen" Raspi B+:
Der hat auf seiner 40pol Leiste die GPIOs 5 + 6 sitzen, wenn ich an diese einen Schalter mache, und ihn dementsprechend definiere, klappt es leider nicht, auf den anderen von mir getesteten Port (9-11-13-19-20-26) klappt es hingegen problemlos. Kann es sein, dass es da einen Konflikt zwischen Version B und B+ gibt?
Bei den beiden Pins gibt er mir bei den Readings nur "Pinlevel" und "State" aus, bei den anderen Pins steht noch Longpress und Counter.
Könnt ihr mir da nen Tip geben :o ;D
Wie gesagt, alle gleich definiert, nach folgendem Schema:
# RPI_GPIO 19 ist der Eingangspin am Raspberry, um den Schalter einzulesen
define sklih RPI_GPIO 19
attr sklih active_low no
attr sklih alias 20 B0 Schalter Küchenrollo Links Hoch
attr sklih debounce_in_ms 10
attr sklih direction input
attr sklih event-on-change-reading state
attr sklih group InputPorts
attr sklih interrupt both
# RPI_GPIO 5 ist der Eingangspin am Raspberry, um den Schalter einzulesen
define skreh RPI_GPIO 5
attr skreh active_low no
attr skreh alias 20 B2 Schalter Küchenrollo Rechts Hoch
attr skreh debounce_in_ms 10
attr skreh direction input
attr skreh event-on-change-reading state
attr skreh group InputPorts
attr skreh interrupt both
Achja, der State ist immer auf ON gesetzt, als ob der Eingang betätigt wäre, siehe Bild
steht was im Logfile drin?
wurde der GPIO angelegt?
was gibt folgender Befehl aus?
ls -l /sys/class/gpio/gpio5
Longpress und Counter werden erst angelegt wenn diese Ereignisse auftreten
Hallo Klaus,
Das einzige ist, dass er bei GPIO5 nen "Zeilenumbruch" oder so mit drin hat
also für den GPIO 5 bekomme ich als Meldung
ls -l /sys/class/gpio/gpio5
lrwxrwxrwx 1 root gpio 0 Dec 16 22:17 /sys/class/gpio/gpio5 -> ../../devices/vir tual/gpio/gpio5
und für GPIO 13 eigenltich die gleiche (der funktioniert aber)
ls -l /sys/class/gpio/gpio13
lrwxrwxrwx 1 root gpio 0 Dec 16 22:17 /sys/class/gpio/gpio13 -> ../../devices/virtual/gpio/gpio13
WiringPi habe ich installiert, und auf die anderen Pins habe ich auch im WebIF zugriff, nur bei Port 5+6 nicht, zumindest, sind das die, die ich bis jetzt ausprobiert habe.
Das hier ist der Mittschnitt aus dem Log mit Global Verbose 5, und da sieht man eben, dass der Pin 5 gleich auf 1 gesetzt wird, aber warum ?
2014.12.17 12:06:52 5: Cmd: >define sklir RPI_GPIO 13<
2014.12.17 12:06:52 4: sklir: write access to file /sys/class/gpio/export, use it to export GPIO
2014.12.17 12:06:52 5: Cmd: >attr sklir active_low no<
2014.12.17 12:06:52 5: sklir, in fileaccess: active_low 0
2014.12.17 12:06:52 5: sklir: set attr active_low: no
2014.12.17 12:06:52 5: Cmd: >attr sklir alias 20 B1 Schalter Küchenrollo Links Runter<
2014.12.17 12:06:52 5: Cmd: >attr sklir debounce_in_ms 10<
2014.12.17 12:06:52 5: Cmd: >attr sklir direction input<
2014.12.17 12:06:52 5: sklir, in fileaccess: direction in
2014.12.17 12:06:52 5: sklir: set attr direction: input
2014.12.17 12:06:52 5: Cmd: >attr sklir event-on-change-reading state<
2014.12.17 12:06:52 5: Cmd: >attr sklir group InputPorts<
2014.12.17 12:06:52 5: Cmd: >attr sklir interrupt both<
2014.12.17 12:06:52 5: sklir, in fileaccess: edge both
2014.12.17 12:06:52 5: Datei: /sys/class/gpio/gpio13/value, FH: IO::File=GLOB(0x22ad140), EXCEPT_FD: 9, akt. Wert: 0
2014.12.17 12:06:52 5: sklir: set attr interrupt: both
2014.12.17 12:06:52 5: Cmd: >define skreh RPI_GPIO 5<
2014.12.17 12:06:52 4: skreh: write access to file /sys/class/gpio/export, use it to export GPIO
2014.12.17 12:06:52 5: Cmd: >attr skreh active_low no<
2014.12.17 12:06:52 5: skreh, in fileaccess: active_low 0
2014.12.17 12:06:52 5: skreh: set attr active_low: no
2014.12.17 12:06:52 5: Cmd: >attr skreh alias 20 B1 Schalter Küchenrollo Rechts Hoch<
2014.12.17 12:06:52 5: Cmd: >attr skreh debounce_in_ms 10<
2014.12.17 12:06:52 5: Cmd: >attr skreh direction input<
2014.12.17 12:06:52 5: skreh, in fileaccess: direction in
2014.12.17 12:06:52 5: skreh: set attr direction: input
2014.12.17 12:06:52 5: Cmd: >attr skreh event-on-change-reading state<
2014.12.17 12:06:52 5: Cmd: >attr skreh group InputPorts<
2014.12.17 12:06:52 5: Cmd: >attr skreh interrupt both<
2014.12.17 12:06:52 5: skreh, in fileaccess: edge both
2014.12.17 12:06:52 5: Datei: /sys/class/gpio/gpio5/value, FH: IO::File=GLOB(0x2187e78), EXCEPT_FD: 10, akt. Wert: 1
2014.12.17 12:06:52 5: skreh: set attr interrupt: both
Falsch, ich meine natürlich:
ls -l /sys/class/gpio/gpio5/
ohne den Schrägstrich am Ende werde die Dateien nicht angezeigt.
Was ich deinem Log entnehmen kann sieht soweit normal aus.
Mit cat /sys/class/gpio/gpio5/direction solltest du "in" erhalten
Dann ist die Richtung schonmal richtig eingestellt.
Mit cat /sys/class/gpio/gpio5/value kannst du schauen, welchen Wert der Pin hat.
Mache das mit beiden Schaltzuständen und schaue ob sich was ändert.
Vielleicht ist auch der Pin kaputt
So, ich erhalte folgende Meldungen:
ls -l /sys/class/gpio/gpio5/
total 0
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 active_low
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 direction
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 edge
drwxrwx--- 2 root gpio 0 Dec 17 16:01 power
lrwxrwxrwx 1 root gpio 0 Dec 17 16:01 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 uevent
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 value
ls -l /sys/class/gpio/gpio13/
total 0
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 active_low
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 direction
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 edge
drwxrwx--- 2 root gpio 0 Dec 17 16:01 power
lrwxrwxrwx 1 root gpio 0 Dec 17 16:01 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 uevent
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 value
Richtung steht auf "IN", und wechseln tut sich leider nix, anders sieht es aus, wenn ich GPIO 13 nehme, da wechselt er immer.
Ich habe ja noch nen zweiten B+ hier liegen, werde da die Micro SD Karte mal einwerfen, und diesen testen.
So, habe es eben umgesteckt, und es ist genau das gleiche Phänomen.
Es ist auch egal, ob überhaupt etwas angeschlossen ist, oder nicht, diese beiden Pins sind immer aktiv gesetzt.
Zitat von: IPPhoner2b am 17 Dezember 2014, 16:16:21
So, ich erhalte folgende Meldungen:
ls -l /sys/class/gpio/gpio5/
total 0
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 active_low
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 direction
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 edge
drwxrwx--- 2 root gpio 0 Dec 17 16:01 power
lrwxrwxrwx 1 root gpio 0 Dec 17 16:01 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 uevent
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 value
ls -l /sys/class/gpio/gpio13/
total 0
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 active_low
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 direction
-rwxrwx--- 1 root gpio 4096 Dec 17 16:02 edge
drwxrwx--- 2 root gpio 0 Dec 17 16:01 power
lrwxrwxrwx 1 root gpio 0 Dec 17 16:01 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 uevent
-rwxrwx--- 1 root gpio 4096 Dec 17 16:01 value
Richtung steht auf "IN", und wechseln tut sich leider nix, anders sieht es aus, wenn ich GPIO 13 nehme, da wechselt er immer.
Ich habe ja noch nen zweiten B+ hier liegen, werde da die Micro SD Karte mal einwerfen, und diesen testen.
So, habe es eben umgesteckt, und es ist genau das gleiche Phänomen.
Es ist auch egal, ob überhaupt etwas angeschlossen ist, oder nicht, diese beiden Pins sind immer aktiv gesetzt.
Ok, vielleicht ist da noch nen Bug im Kernel. RPI_GPIO macht nix anderes als diese Dateien auszulesen. Wenn es mit cat nicht funktioniert dann geht es natürlich auch in FHEM nicht.
Du hast aber keine 5V auf die Pins gejagt?
Die einzige Möglichkeit, die ich sehe ist, im Internet nach den besagen GPIOs zu suchen. Das Problem haben sicher noch andere, vielleicht gibt es schon einen Workaround
Hi Klaus,
evtl. hilft es ja, habe grade mal alle GPIO Pins die eine GPIO Nummer hatten als Inputs definiert, und jeweils NUR die gewünschten3,3V beaufschlagt ;D
Folgende GPIOs kann ich nicht als Eingang nutzen, weil diese nicht aktualisiert werden:
GPIO 4 - PIN 7
GPIO 5 - PIN 29
GPIO 6 - PIN 31
GPIO 7 - PIN 26
GPIO 8 - PIN 24
Zitat von: IPPhoner2b am 17 Dezember 2014, 16:52:46
Hi Klaus,
evtl. hilft es ja, habe grade mal alle GPIO Pins die eine GPIO Nummer hatten als Inputs definiert, und jeweils NUR die gewünschten3,3V beaufschlagt ;D
Folgende GPIOs kann ich nicht als Eingang nutzen, weil diese nicht aktualisiert werden:
GPIO 4 - PIN 7
GPIO 5 - PIN 29
GPIO 6 - PIN 31
GPIO 7 - PIN 26
GPIO 8 - PIN 24
Hmm, es wäre interessant herauszufinden, wieso diese GPIOs nicht funktionieren.
Vielleicht werden sie alternativ von anderen Prozessen blockiert.
z.B. GPIO14 und 15 sind nicht verwendbar, wenn dir serielle Schnittstelle aktiviert ist.
evtl. gibt es da was
Die 1wire Kernelmodule hast du nicht geladen, oder?
1wire wäre mir nicht bekannt, also wenn das nicht von vorneherein geladen ist, würde ich jetzt mal nein sagen.
Zitat von: IPPhoner2b am 17 Dezember 2014, 17:41:36
1wire wäre mir nicht bekannt, also wenn das nicht von vorneherein geladen ist, würde ich jetzt mal nein sagen.
Den musst du erst eintragen. Standardmäßig wird der Treiber nicht geladen.
Kann ja auch sein, das es ein B+ Fehler ist, der noch noch nicht behoben wurde.
So, habe grade nochmal nen Test gemacht, und ich weiß nicht, ob es daran lag, dass vorher das WiringPi nicht installiert war, aber ich vermute es mal, weil ich nichts mehr an meiner Config geändert habe.
Jedenfalls funktionieren ALLE GPIOs an den RPIs B und B+ mit der gleichen SD Karte so wie gewünscht, also habe ich die Pferde etwas zu unrecht aufgescheucht, tut mir Leid, und ich versuche mich zu bessern :o 8) ::) ;D
Hauptsache es läuft jetzt ::)
Hi,
Is it possible to add an extra option for the counter . I'm will use the counter for my watermeter this send a pulse every 0.5L water.
It should be nice to say something like every pulse is 0.5 liter, so that the log is also in the correct format.
I used rfxmeter and there is also something that rfxmeter 0.5 ltr
example output rfxmeter with scale factor 0.5 2014-12-18_19:38:03 RFXWater meter: 645630.5 ltr
regards Richard
Hi Richard,
Zitat von: kroonen am 26 Dezember 2014, 21:32:42
Is it possible to add an extra option for the counter . I'm will use the counter for my watermeter this send a pulse every 0.5L water.
It should be nice to say something like every pulse is 0.5 liter, so that the log is also in the correct format.
I used rfxmeter and there is also something that rfxmeter 0.5 ltr
example output rfxmeter with scale factor 0.5 2014-12-18_19:38:03 RFXWater meter: 645630.5 ltr
of course its possible to implement it.
I'll check it in the next days
But you should be able to solve this problem with readings proxy.
Hi,
I solved this, bij adding a 1-wire counter, and the use an factor for it already.
I have another question. I uses an input (gpio) to check if the garage is open or close. I Want to know when it was that the last time it was open op closed. So to should be nice to have a statechange timestamp, so when that I know when it was last time.
Is this possible ?
regards Richard
Hallo,
hatte mich gerade mit dem Modul rumgeschlagen und da hat mir eine Fehler im Logging das Leben unnötig schwer gemacht.
Beim definieren von einem neuen RPI_GPIO kam folgernder LOG Eintrag:
Zitattest: can't export gpio7, no write access to /sys/class/gpio/export and file /usr/local/bin/gpio doesnt exist
gpio existiert wirklich nicht, nur das Problem lag nicht an den fehlenden Schreibrechten. Das ganze läuft bei mir auf einem Cubietruck und da sind noch die Pin Definition am gpio-Verzeichnis angehängt.
Zitat/sys/class/gpio/gpio6_pg3
Mit
define test RPI_GPIO 6_pg3 hat es dann gleich geklappt, wenn der gpio schon angelegt war.
In der LOG müsste eher auf das nicht gefundene gpio Verzeichnis hingewiesen werden.
Das Modul legt den gpio zwar an aber findet logischerweise das Verzeichnis mit dem Zusatz _pg3 nicht.
Glücklicherweise klappt es ja mit dem Umweg wenn ich den Pin komplett eintrage.
Gruß
Zitat von: kroonen am 01 Januar 2015, 18:41:39
I have another question. I uses an input (gpio) to check if the garage is open or close. I Want to know when it was that the last time it was open op closed. So to should be nice to have a statechange timestamp, so when that I know when it was last time.
Is this possible ?
yes:
1. create two dummys (e.g. gate_opened and gate_closed)
2. create an notify for input gpio:
define act_on_Pin23 notify Pin23 {\
my $ts = ReadingsTimestamp("%NAME","state",0);;\
if ("%EVENT" eq "on") {\
fhem "set gate_opened $ts";;\
} elsif ("%EVENT" eq "off") {\
fhem "set gate_closed $ts";;\
}\
}
Zitat von: Phill am 02 Januar 2015, 01:45:45
Hallo,
hatte mich gerade mit dem Modul rumgeschlagen und da hat mir eine Fehler im Logging das Leben unnötig schwer gemacht.
Beim definieren von einem neuen RPI_GPIO kam folgernder LOG Eintrag:gpio existiert wirklich nicht, nur das Problem lag nicht an den fehlenden Schreibrechten. Das ganze läuft bei mir auf einem Cubietruck und da sind noch die Pin Definition am gpio-Verzeichnis angehängt.Mit define test RPI_GPIO 6_pg3 hat es dann gleich geklappt, wenn der gpio schon angelegt war.
In der LOG müsste eher auf das nicht gefundene gpio Verzeichnis hingewiesen werden.
Das Modul legt den gpio zwar an aber findet logischerweise das Verzeichnis mit dem Zusatz _pg3 nicht.
Glücklicherweise klappt es ja mit dem Umweg wenn ich den Pin komplett eintrage.
über logausgaben kann man sich immer streiten...ich denke mal über eine sinnvollere Meldung nach.
immerhin hast du es rausgefunden ;)
nutzt du ein neues image auf dem cubie?
wenn ich mich richtig erinnere dann nutzen das schon einige ohne probleme.
Der export funktioniert aber weiterhin über die reine gpio nummer? oder kannst du dort auch z.B. das pg_3 anhängen?
Dann müsste ja nur die Commandreg angepasst werden
Ich nutze cubieez 2.0 auf meinem Cubietruck. Weiß ich nicht ob es bei anderen Images den Zusatz am Verzeichnis gibt.
Der export funktioniert nur über die reine Nummer, gibt man den Zusatz mit an klappt es nicht. Auch auf Konsolenebene mit echo > export klappt es nur mit der Nummer.
Ich erzeuge die gpios jetzt in rc.local und setze den benutzer fhem als Besitzer.
Dann kann ich in fhem die RPI_GPIO's mit dem Zusatz definieren.
Evtl. könnte man auch innerhalb des Moduls RPI_GPIO mit regexp arbeiten.
Also so irgendwie, /sys/class/gpio/gpio\d*.*/Wobei ich denke das es so einfach nicht klappt, da er ja nicht ein-ziffrige gpio's mit mehr-ziffrigen gpio's verwechseln darf.
Vielleicht ist das bei mir auch zu exotisch um den Code extra anzupassen. Es funktioniert ja einigermaßen Zufriedenstellend.
Hallo Klaus,
von mir noch mal eine Rückmeldung in Sachen Banana Pi (Pro) und Input:
Aktuelles Raspbian (mit nun vorinstalliertem wiringPi) mit aktuellen fhem. Grundsätzlich funktioniert der GPIO-Zugriff nur, wenn in rc.local entsprechend die zu nutzenden GPIOs vorher geimpft wurden. Dies funktioniert sowohl für Output als auch für Input.
Für Input gibt es allerdings eine wirklich ätzende Einschränkung: Es läuft nicht mittels Interrupt, nur Poll klappt.
Was ist denn in Bezug auf Interrupt zu beachten? Kann ich noch irgendwo dran schrauben?
Zitat von: Phill am 03 Januar 2015, 16:52:06
Evtl. könnte man auch innerhalb des Moduls RPI_GPIO mit regexp arbeiten.
Also so irgendwie, /sys/class/gpio/gpio\d*.*/Wobei ich denke das es so einfach nicht klappt, da er ja nicht ein-ziffrige gpio's mit mehr-ziffrigen gpio's verwechseln darf.
Vielleicht ist das bei mir auch zu exotisch um den Code extra anzupassen. Es funktioniert ja einigermaßen Zufriedenstellend.
Exotisch ist deine Hardware sicher nicht.
Ich habe ein bisschen probiert, konnte aber kein befriedigendes Ergebnis erzielen.
Wenn du zwischenzeitlich eine funktionierende Codeanpassung hast, kann ich diese gern einbauen.
Zitat von: Ralli am 08 Januar 2015, 18:14:02
Aktuelles Raspbian (mit nun vorinstalliertem wiringPi) mit aktuellen fhem. Grundsätzlich funktioniert der GPIO-Zugriff nur, wenn in rc.local entsprechend die zu nutzenden GPIOs vorher geimpft wurden. Dies funktioniert sowohl für Output als auch für Input.
Für Input gibt es allerdings eine wirklich ätzende Einschränkung: Es läuft nicht mittels Interrupt, nur Poll klappt.
Was ist denn in Bezug auf Interrupt zu beachten? Kann ich noch irgendwo dran schrauben?
schicke mir bitte PM von "ls -l" von einem input gpio verzeichnis und vom gpio verzeichnis und vom logfile
bananapi@fhem /sys/class/gpio $ ls -la
insgesamt 0
drwxrwxrwx 2 root gpio 0 Jan 8 16:26 .
drwxr-xr-x 62 root root 0 Jan 8 16:26 ..
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 export
lrwxrwxrwx 1 root gpio 0 Jan 8 16:26 gpio21 -> ../../devices/platform/gpio-sunxi/gpio/gpio21
lrwxrwxrwx 1 root gpio 0 Jan 8 16:26 gpio27 -> ../../devices/platform/gpio-sunxi/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Jan 8 16:26 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 unexport
Ein Input-GPIO:
bananapi@fhem /sys/class/gpio/gpio21 $ ls -la
insgesamt 0
drwxrwxrwx 3 root gpio 0 Jan 8 16:26 .
drwxrwxrwx 5 root gpio 0 Jan 8 16:26 ..
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 active_low
lrwxrwxrwx 1 root gpio 0 Jan 8 16:26 device -> ../../../gpio-sunxi
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 direction
drwxrwxrwx 2 root gpio 0 Jan 8 16:26 power
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 pull
lrwxrwxrwx 1 root gpio 0 Jan 8 16:26 subsystem -> ../../../../../class/gpio
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 uevent
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 value
Ein Output-GPIO:
bananapi@fhem /sys/class/gpio/gpio27 $ ls -la
insgesamt 0
drwxrwxrwx 3 root gpio 0 Jan 8 16:26 .
drwxrwxrwx 5 root gpio 0 Jan 8 16:26 ..
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 active_low
lrwxrwxrwx 1 root gpio 0 Jan 8 16:26 device -> ../../../gpio-sunxi
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 direction
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 edge
drwxrwxrwx 2 root gpio 0 Jan 8 16:26 power
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 pull
lrwxrwxrwx 1 root gpio 0 Jan 8 16:26 subsystem -> ../../../../../class/gpio
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:26 uevent
-rwxrwxrwx 1 root gpio 4096 Jan 8 16:30 value
Im Logfile steht nix.
2015.01.09 08:53:07 0: Server shutdown
2015.01.09 08:53:09 1: Including fhem.cfg
2015.01.09 08:53:09 3: telnetPort: port 7072 opened
2015.01.09 08:53:10 3: WEB: port 8083 opened
2015.01.09 08:53:10 3: WEBphone: port 8084 opened
2015.01.09 08:53:10 3: WEBtablet: port 8085 opened
2015.01.09 08:53:10 2: eventTypes: loaded 10 events from ./log/eventTypes.txt
2015.01.09 08:53:10 1: Including ./log/fhem.save
2015.01.09 08:53:10 1: usb create starting
2015.01.09 08:53:11 1: usb create end
2015.01.09 08:53:11 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.
2015.01.09 08:53:11 0: Server started with 11 defined entities (version $Id: fhem.pl 7358 2014-12-29 16:03:31Z rudolfkoenig $, os linux, user fhem, pid 2672)
List von GPIO21
Internals:
DEF 21
NAME GPIO21
NR 20
RPI_pin 21
STATE on
TYPE RPI_GPIO
Readings:
2015-01-09 08:54:17 Pinlevel high
2015-01-09 08:54:17 state on
Fhem:
interfaces switch
Attributes:
direction input
poll_interval 0.01
List vom GPIO27:
Internals:
DEF 27
NAME GPIO27
NR 21
RPI_pin 27
STATE off
TYPE RPI_GPIO
Readings:
2015-01-08 16:12:35 Pinlevel high
2015-01-09 08:53:10 state off
Fhem:
interfaces switch
Attributes:
active_low yes
direction output
Die Pins hattest du schon in der rc.local exportiert?
Wie sieht das ganze aus, wenn du die Zeilen aus der rc.local entfernst?
Wenn wiring pi installiert ist sollte das trotzdem gehen.
Im Log steht nix, da du kein Attribut interrupt für den Input vergeben hast 8)
Bei Deinem GPIO21 fehlt die Datei edge. Über diese läuft die Interruptauswertung.
Vermutlich unterstützt dieser GPIO einfach keinen Interrupt.
Nutze GPIO27 bitte Testweise als Input mit Interrupt.
Ja, bereits in der rc.local exportiert. Wenn ich das nicht tue, klappt so gut wie gar nichts. Das einzige, was dann funktioniert, ist das Beschalten eines Outputs - allerdings kommt er bspw. an active_low schon nicht mehr dran, so dass das auch nicht wirklich richtig klappt.
Mit dem Interrupt hole ich nochmal nach bzw. probiere das aus.
Zitat von: Ralli am 10 Januar 2015, 06:50:10
Ja, bereits in der rc.local exportiert. Wenn ich das nicht tue, klappt so gut wie gar nichts. Das einzige, was dann funktioniert, ist das Beschalten eines Outputs - allerdings kommt er bspw. an active_low schon nicht mehr dran, so dass das auch nicht wirklich richtig klappt.
stimmt, wiring pi ermöglicht nur zugriff auf value und edge
aber ein input sollte auch gehen, wenigstens im polling
Input klappt ja im Polling auch - aber eben nicht per Interrupt.
Wenn ich manuell mit GPIO versuche, einen Pin auf Interrupt zu bringen, klappt es auch nicht. Ich bekomme die Fehlermeldung
Unable to open GPIO edge interface for pin 21: No such file or directory
Laut einem Post auf Drogons/Gordons Seite https://projects.drogon.net/raspberry-pi/wiringpi/functions/ könnte das auf eine fehlende Unterstützung im Kernel hinweisen. Und damit ist dann leider Schluss für mich :(.
Frage:
Bedeutet denn das ständige Polling hier im konkreten Fall einen wesentlichen Ressourcen-Mehraufwand gegenüber der Interrupt-Lösung oder ist das zu vernachlässigen - ich kenne die Art und Weise der Abhandlung innerhalb von Perl bzw. fhem nicht? (generell ist Polling ja eher deutlich schlechter als Interrupt...)
Zitat von: Ralli am 12 Januar 2015, 13:26:02
Frage:
Bedeutet denn das ständige Polling hier im konkreten Fall einen wesentlichen Ressourcen-Mehraufwand gegenüber der Interrupt-Lösung oder ist das zu vernachlässigen - ich kenne die Art und Weise der Abhandlung innerhalb von Perl bzw. fhem nicht? (generell ist Polling ja eher deutlich schlechter als Interrupt...)
Es kommt immer auf die Anwendung an.
Wenn du minütlich pollst ist das sicher zu vernachlässigen (Zustand Fenster z.B). Aber zum Abfragen von Tasten ist es ungeeignet, du kannst versuchen alle 100ms abzufragen, aber das erzeugt Prozessorlast und ist an sich auch noch zu langsam. Die Interrupt Lösung erzeugt, nachdem sie aktiviert wurde, überhaupt keine Last, solange kein Interrupt ausgelöst wird.
Probiere es aus, vielleicht reicht es für deine Anwendung
Aber ... schön isses natürlich nciht.
Wenn es im Kernel nicht drin ist, kann ich leider auch nicht viel machen.
Was ist denn mit den Pins, wo die edge Datei im Verzeichnis liegt? Das war doch bei dem einen Output Pin bei die der Fall.
Kannst du auf die Datei zugreifen, wenn sie da ist?
Das Polling kannst du auch über wiringpi machen, das brauchst du nix in die rc.local zu schreiben...richtig?
Hallo Klaus,
habe noch was gefunden: http://forum.lemaker.org/thread-11177-1-1-.html
Es ist wohl nicht jeder GPIO auch mit Interrupt nutzbar.
Und siehe da - wenn man einen GPIO für Input nimmt, der auch Interrupt beherrscht, klappt's auch :). Aber auch hier gilt: er muss genau wie die anderen in der rc.local geimpft werden.
Meine rc.local habe ich um Folgendes ergänzt:
# in /etc/init.d/rc.local den Pfad ergänzen um :/usr/local/sbin:/usr/local/bin
gpio reset
# Input-Ports (BCM)
for Port in 4 21
do
echo "$Port" > /sys/class/gpio/export
echo "in" >/sys/class/gpio/gpio${Port}/direction
done
# Output-Ports (BCM)
for Port in 27
do
echo "$Port" > /sys/class/gpio/export
echo "out" >/sys/class/gpio/gpio${Port}/direction
echo "1" > /sys/class/gpio/gpio${Port}/active_low
echo "0" >/sys/class/gpio/gpio${Port}/value
done
chmod 775 -R /sys/class/gpio
chown -R root:gpio /sys/class/gpio
chmod 775 -R /sys/devices/platform/gpio-sunxi
chown -R root:gpio /sys/devices/platform/gpio-sunxi
Hi,
ich verwende ein paar Raspi-Pins für Alarmsignale wie z.B. von einem Rauchmelder. Da die Signale zum Teil kürzer als eine Minute sind verwende ich den Interrupt-Modus:
define Rauchmelder RPI_GPIO 11
attr Rauchmelder active_low yes
attr Rauchmelder direction input
attr Rauchmelder interrupt falling
Den Pin habe ich mit einem Notify verknüpft, der im Alarmfall eine SMS sendet. Bei einem Test wurde jedoch alle paar Sekunden eine neue SMS gesendet.
Sollte der Notify denn nicht nur bei dem Flankenwechsel ausgelöst werden?
Die Alarmeingänge habe ich auch mit einem Log verknüpft und dort sieht man, dass die Pins sehr oft täglich toggeln und den Counter hochzählen, obwohl der Pinlevel immer Low ist:
2015-01-29_15:44:57 Rauchmelder Pinlevel: low
2015-01-29_15:44:57 Rauchmelder off
2015-01-29_15:44:57 Rauchmelder Toggle: on
2015-01-29_15:44:57 Rauchmelder Counter: 26386
2015-01-29_17:50:39 Rauchmelder Pinlevel: low
2015-01-29_17:50:39 Rauchmelder off
2015-01-29_17:50:39 Rauchmelder Toggle: off
2015-01-29_17:50:39 Rauchmelder Counter: 26387
Ist das bei euren Interrupt-Pins auch so oder mach ich hier etwas falsch?
Zitat von: hobbynaut am 29 Januar 2015, 21:05:26
Hi,
ich verwende ein paar Raspi-Pins für Alarmsignale wie z.B. von einem Rauchmelder. Da die Signale zum Teil kürzer als eine Minute sind verwende ich den Interrupt-Modus:
define Rauchmelder RPI_GPIO 11
attr Rauchmelder active_low yes
attr Rauchmelder direction input
attr Rauchmelder interrupt falling
Den Pin habe ich mit einem Notify verknüpft, der im Alarmfall eine SMS sendet. Bei einem Test wurde jedoch alle paar Sekunden eine neue SMS gesendet.
Sollte der Notify denn nicht nur bei dem Flankenwechsel ausgelöst werden?
Die Alarmeingänge habe ich auch mit einem Log verknüpft und dort sieht man, dass die Pins sehr oft täglich toggeln und den Counter hochzählen, obwohl der Pinlevel immer Low ist:
2015-01-29_15:44:57 Rauchmelder Pinlevel: low
2015-01-29_15:44:57 Rauchmelder off
2015-01-29_15:44:57 Rauchmelder Toggle: on
2015-01-29_15:44:57 Rauchmelder Counter: 26386
2015-01-29_17:50:39 Rauchmelder Pinlevel: low
2015-01-29_17:50:39 Rauchmelder off
2015-01-29_17:50:39 Rauchmelder Toggle: off
2015-01-29_17:50:39 Rauchmelder Counter: 26387
Ist das bei euren Interrupt-Pins auch so oder mach ich hier etwas falsch?
Der Pinlevel ist nicht immer Low. Das attribut Interrupt auf falling sorgt allerdings dafür, das nur bei einem high->low Wechsel am GPIO der Status aktualisiert wird. Das heisst, es wird immer nur low reingeschrieben. Trotzdem muss der Pin vorher high gewesen sein. Das wird aber nur registriert, wenn du interrupt auf both stellst. Zum zählen ist es irrelevant.
Ich vermute, das du am GPIO kein stabiles Eingangssignal hast.
Bei einem Alarmeingang verwende ich Interrupt = both. Dann müsste ich in dem zugehörigen Log ja auch mal pinlevel = high sehen. In dem Log steht aber immer nur pinlevel = low.
Hallo Klaus,
nachdem ich heute einen B+ mit rpi-update und software-seitig auf aktuellen Stand gebracht habe, ist mir aufgefallen, dass der in der commandref aufgeführte Pfad bei chown -R fhem:root /sys/devices/virtual/gpio/* zumindest unter Raspbian nicht (mehr) existiert.
Der Pfad lautet /sys/devices/soc/20200000.gpio/gpio/*
Zitat von: Ralli am 06 Februar 2015, 09:30:07
Hallo Klaus,
nachdem ich heute einen B+ mit rpi-update und software-seitig auf aktuellen Stand gebracht habe, ist mir aufgefallen, dass der in der commandref aufgeführte Pfad bei chown -R fhem:root /sys/devices/virtual/gpio/* zumindest unter Raspbian nicht (mehr) existiert.
Der Pfad lautet /sys/devices/soc/20200000.gpio/gpio/*
Ich frage mich sowieso gerade, was ich da geschrieben habe....
Gibt es denn:
/sys/class/gpio/export?
und damit auch die
/sys/class/gpio/gpio[zahl]?
nach eingabe von:
Zitatsudo adduser fhem gpio
sudo reboot
und reboot sollte beim raspbian sowieso alles direkt ohne weitere Änderungen laufen.
Zitat von: klausw am 09 Februar 2015, 10:19:38
Ich frage mich sowieso gerade, was ich da geschrieben habe....
8)
Zitat
Gibt es denn: /sys/class/gpio/export?
und damit auch die /sys/class/gpio/gpio[zahl]?
Ja - beides. Ersteres als ausführbare Datei, letztes jeweils als Verzeichnis.
Und nein, nach dem
Zitat
sudo adduser fhem gpio
sudo reboot
war nach der Update-Prozedur nicht alles gut.
Zitat von: Ralli am 09 Februar 2015, 12:55:09
Ja - beides. Ersteres als ausführbare Datei, letztes jeweils als Verzeichnis.
dann sollte doch auch
chown -R fhem:root /sys/class/gpio/*funktionieren. Oder?
Zitat von: Ralli am 09 Februar 2015, 12:55:09
Und nein, nach dem
war nach der Update-Prozedur nicht alles gut.
was ist denn nicht gut?
geht es nur eingeschränkt oder gar nicht?
wie sind den die Rechte ohne die Anpassung in der rc.local?
Zitat von: klausw am 09 Februar 2015, 13:04:57
dann sollte doch auch
chown -R fhem:root /sys/class/gpio/*
funktionieren. Oder?
Nein, das alleine funktioniert nicht. Da werden die Berechtigungen nicht richtig durchgereicht (virtuelle Dateien).
Zitat
was ist denn nicht gut?
geht es nur eingeschränkt oder gar nicht?
wie sind den die Rechte ohne die Anpassung in der rc.local?
Das gleiche Problem wie bei der Banane. Ohne Bearbeitung in der rc.local nur rudimentäre Funktionen. Genaueres kann ich Dir leider jetzt nicht mehr schreiben, da ich gestern auf die Banane migriert habe und der PI nun platt ist.
Zitat von: Ralli am 09 Februar 2015, 13:19:36
Nein, das alleine funktioniert nicht. Da werden die Berechtigungen nicht richtig durchgereicht (virtuelle Dateien).
Wieder was gelernt :)
Dann sollte ich die Pfade der verschiedenen Distros sammeln und in die commandref einbauen.
Zitat von: Ralli am 09 Februar 2015, 13:19:36
Das gleiche Problem wie bei der Banane. Ohne Bearbeitung in der rc.local nur rudimentäre Funktionen. Genaueres kann ich Dir leider jetzt nicht mehr schreiben, da ich gestern auf die Banane migriert habe und der PI nun platt ist.
Mach nix, wenn jemand Probleme hat wird er sich sicher melden.
Hallo, kann mir jemand auf die Sprünge helfen, welche Debian Pakete ich alles benötigt, um WiringPi zu compilen?
Make und gcc habe ich installiert, funktioniert aber leider nicht.
root@pibz:/tmp/wiringPi-72b2af2# ./build
wiringPi Build script
=====================
WiringPi Library
[UnInstall]
[Compile] wiringSerial.c
[Compile] piHiPri.c
[Compile] wiringShift.c
[Compile] wiringPi.c
[Compile] piThread.c
piThread.c:26:21: fatal error: pthread.h: No such file or directory
wiringPi.c:55:19: fatal error: stdio.h: No such file or directory
compilation terminated.
compilation terminated.
wiringSerial.c:23:19: fatal error: stdio.h: No such file or directory
compilation terminated.
piHiPri.c:27:19: fatal error: sched.h: No such file or directory
compilation terminated.
In file included from wiringShift.c:25:0:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/include/stdint.h:3:26: fatal error: stdint.h: No such file or directory
compilation terminated.
Makefile:89: recipe for target 'wiringSerial.o' failed
make: *** [wiringSerial.o] Error 1
make: *** Waiting for unfinished jobs....
Makefile:89: recipe for target 'wiringPi.o' failed
make: *** [wiringPi.o] Error 1
Makefile:89: recipe for target 'piThread.o' failed
make: *** [piThread.o] Error 1
Makefile:89: recipe for target 'piHiPri.o' failed
make: *** [piHiPri.o] Error 1
Makefile:89: recipe for target 'wiringShift.o' failed
make: *** [wiringShift.o] Error 1
Make Failed...
Zitat von: TeeVau am 13 Februar 2015, 15:28:27
Hallo, kann mir jemand auf die Sprünge helfen, welche Debian Pakete ich alles benötigt, um WiringPi zu compilen?
keine Ahnung, läuft das unterschiedlich zum Raspbian? dort geht es so:
sudo apt-get install git-core
git clone git://git.drogon.net/wiringPi
cd wiringPi ./build
Ja, es ist ein respian. Benutze das Image Musikbox Pi. Git kopiert ja nur den sourceforge, das Build compiliert das ganze ja. Das macht bei mir Probleme. Sonst schreib ich den Entwickler die Tage mal an
Hab darauf hier noch keine Anwort gefunden:
Läuft der Counter irgnedwann über? Fängt er wieder bei 0 an? (z.B. bei 65535?)
Gute Frage, vermutlich ja. Aber da sollte jede Menge Luft sein. Evtl. findest du in der Perldoku was.
Zitat von: klausw am 07 Mai 2015, 16:39:25
Gute Frage, vermutlich ja. Aber da sollte jede Menge Luft sein. Evtl. findest du in der Perldoku was.
Bei mir ist nicht viel Luft, es hängt ein Windmesser am GPIO und mit dem Counter wird die Windgeschwindigkeit berechnet :)
Na dann lass es mal laufen und berichte :)
Das ist aber eher interesse.
Ich würde in die Routine zur Geschwindigkeitsberechnung einfach das zurücksetzen des Zählers einbauen.
Zitat von: klausw am 07 Mai 2015, 17:44:08
Na dann lass es mal laufen und berichte :)
Das ist aber eher interesse.
Ich würde in die Routine zur Geschwindigkeitsberechnung einfach das zurücksetzen des Zählers einbauen.
Kann man den Counter zurücksetzen?
Zitat von: Nemo0815 am 07 Mai 2015, 17:49:18
Kann man den Counter zurücksetzen?
Mit setreading, Syntax habe ich nicht im Kopf, steht aber in der commandref
Ich vermute aber, das du auch ohne zurücksetzen keinen Überlauf hinbekommst.
Wie genau ist dieser Counter eigneltich? Bzw. bis zu welcher Frequenz lassen sich die GPIOs "abtasten"?
Irgendwie bekomme ich mit meinem Windmesser nur max. 20 km/h hin, was mir doch etwas wenig erscheint :)
Zitat von: Nemo0815 am 11 Mai 2015, 13:30:13
Wie genau ist dieser Counter eigneltich? Bzw. bis zu welcher Frequenz lassen sich die GPIOs "abtasten"?
Irgendwie bekomme ich mit meinem Windmesser nur max. 20 km/h hin, was mir doch etwas wenig erscheint :)
Naja, das Counter ist wie das ganze Modul in Perl programmiert und greift auf den GPIO über das Dateisystem zu.
Bei jedem Interrupt werden Dateioperationen ausgeführt, die eine Weile dauern.
Triggerst du auf beide Flanken? Dann könnte es mit einer besser gehen.
Der Counter ist genau, solange die CPU genug Reserven hat. Werden beispielsweise gerade Plots berechnet dann kann es Probleme geben.
Das mit dem Counter hatte ich damals auf Wunsch eingebaut und mir nicht weiter Gedanken drüber gemacht.
Für eine Lösung die schneller zählen kann müsstest du was in C schreiben. Oder besser noch einen Mikrocontroller nehmen der die Geschw. direkt berechnet.
Zitat von: klausw am 11 Mai 2015, 14:37:00
Naja, das Counter ist wie das ganze Modul in Perl programmiert und greift auf den GPIO über das Dateisystem zu.
Bei jedem Interrupt werden Dateioperationen ausgeführt, die eine Weile dauern.
Triggerst du auf beide Flanken? Dann könnte es mit einer besser gehen.
Der Counter ist genau, solange die CPU genug Reserven hat. Werden beispielsweise gerade Plots berechnet dann kann es Probleme geben.
Das mit dem Counter hatte ich damals auf Wunsch eingebaut und mir nicht weiter Gedanken drüber gemacht.
Für eine Lösung die schneller zählen kann müsstest du was in C schreiben. Oder besser noch einen Mikrocontroller nehmen der die Geschw. direkt berechnet.
Danke für die Info.
Ich habe mittlerweile versucht mir mittels eines Python scripts über RPI.GPIO Lib zu behelfen.
(und mich da in die ISR callback zu hängen). Leider funktioniert das nur wenn FHEM nicht läuft, auch wenn ich den entsprechenden Pin nicht benutze.
Wenn FHEM läuft wird kein interrupt ausgelöst, es sei denn ich definiere den Pin zusätzlich in fhem als RPI_GPIO. Gibts da irgendeinen Rechte/Resourcen Konflikt mit der Art wir RPI_GPIO die Ports benutzt?
Hier ist der Code, wens interessiert (noch nicht perfekt):
#!/usr/bin/python3
# Windmesser
import RPi.GPIO as GPIO
import time, sys, os
# SoC als Pinreferenz waehlen
GPIO.setmode(GPIO.BCM)
GPIO.setup(27, GPIO.IN)
# Variable Counter definieren
sample_each_ms = 10000
counter = 0
t1 = time.time()
def Interrupt(channel):
global counter
counter = counter + 1
print "Counter " + str(counter)
# Interrupt Event hinzufuegen. Pin 27, auf steigende Flanke reagieren und ISR "Interrupt" deklarieren
GPIO.add_event_detect(27, GPIO.RISING, callback = Interrupt, bouncetime = 10)
# Endlosschleife
while True:
t2 = time.time()
delta = t2-t1
if delta >= sample_each_ms/1000:
if counter > 0:
speed = ((((counter/delta) + 2) / 3) * 3.6)
os.system('perl /opt/fhem/fhem.pl 7072 "setreading WindgeschwindigkeitExt state '+str(speed)+'"')
sys.stdout.write('counter = {} \n'.format(counter))
counter=0
else:
os.system('perl /opt/fhem/fhem.pl 7072 "setreading WindgeschwindigkeitExt state 0"')
sys.stdout.write('counter = 0 \n')
t1=t2
Zitat von: Nemo0815 am 13 Mai 2015, 13:10:03
Danke für die Info.
Ich habe mittlerweile versucht mir mittels eines Python scripts über RPI.GPIO Lib zu behelfen.
(und mich da in die ISR callback zu hängen). Leider funktioniert das nur wenn FHEM nicht läuft, auch wenn ich den entsprechenden Pin nicht benutze.
Wenn FHEM läuft wird kein interrupt ausgelöst, es sei denn ich definiere den Pin zusätzlich in fhem als RPI_GPIO. Gibts da irgendeinen Rechte/Resourcen Konflikt mit der Art wir RPI_GPIO die Ports benutzt?
Sollte es nicht geben. Vom rpi_gpio Modul werden nur die Pins exortiert, die per define angelegt wurden. Eigentlich ist es auch so, das ein anderweitig verwendeter GPIO, für die Verwendung mit dem rpi_gpio Modul blockiert ist.
Zitat von: klausw am 16 Mai 2015, 22:51:14
Sollte es nicht geben. Vom rpi_gpio Modul werden nur die Pins exortiert, die per define angelegt wurden. Eigentlich ist es auch so, das ein anderweitig verwendeter GPIO, für die Verwendung mit dem rpi_gpio Modul blockiert ist.
Danke,
Ich das Modul war auch nicht schuld, sorry für die Verwirrung. Anscheinend hat die RPI.GPIO Lib ein Problem sobald man os.system im Script benutzt (dann wird der Interrupt wieder disabled), mit subprocess.call dagegen funktioniert alles wie erwartet.
Hallo zusammen,
nachdem ich nun einige Stunden damit verbracht habe, die Dateiberechtigungen zum GPIO Zugriff auf einem Raspi hinzubekommen, möchte ich euch gerne meine Erfahrungen hier mitteilen :)
Installiert ist auf dem RPi das relativ aktuelle Raspbian 3.18.11+ von Ende April 2015 und die WiringPi Bibliothek. Nach dem Anlegen eines Outputs über define Relais RPI_GPIO 17 konnte ich das angeschlossene Relais auch schalten. Allerdings benötigt meine Relaisplatine eine invertierte Logik, schaltet also bei LOW ein. Mit dem Attribut active_low = yes sollte diese Invertierung greifen, hat es bei mir aber ersteinmal nicht getan. Ein Blick ins Log zeigt dann: Can't open file: Relais, active_low, also ein Berechtigungsproblem :(
Nach Lesen der commandref ist der erste Ansatz, per sudo adduser fhem gpio den User fhem der Gruppe gpio zuzuorden - Leider gibt es scheinbar im aktuellen Raspbian keine solche Gruppe mehr.
Zweiter Ansatz aus der commandref: in der Datei rc.local die Berechtigungen setzen, bevor Fhem startet. Die Einträge von dort übernommen und angepasst - leider immer noch kein Zugriff auf die Dateien, diese werden nach Reboot immer wieder mit root:root neu angelegt und sind von fhem aus nicht beschreibbar.
Nach Recherche im Web habe ich dann herausgefunden, das es in neueren Raspian Versionen eine Veränderung im Device Tree gegeben hat und das beschriebene Verzeichnis /sys/devices/virtual nicht mehr existiert. Nun findet man die Datein hier /sys/devices/soc/....
Folgender Eintrag in der rc.local funktioniert nun endlich auch mit dem aktuellen Raspian:
echo 17 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/soc/*.gpio/*
chown -R fhem:root /sys/class/gpio/*
Gruß Micha
Zitat von: MichaS am 16 Juni 2015, 13:10:40
Folgender Eintrag in der rc.local funktioniert nun endlich auch mit dem aktuellen Raspian:
echo 17 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/soc/*.gpio/*
chown -R fhem:root /sys/class/gpio/*
Danke für den Hinweis. So langsam wir es unübersichtlich in der commandref ;)
Zitat von: MichaS am 16 Juni 2015, 13:10:40
Hallo zusammen,
nachdem ich nun einige Stunden damit verbracht habe, die Dateiberechtigungen zum GPIO Zugriff auf einem Raspi hinzubekommen, möchte ich euch gerne meine Erfahrungen hier mitteilen :)
Installiert ist auf dem RPi das relativ aktuelle Raspbian 3.18.11+ von Ende April 2015 und die WiringPi Bibliothek. Nach dem Anlegen eines Outputs über define Relais RPI_GPIO 17 konnte ich das angeschlossene Relais auch schalten. Allerdings benötigt meine Relaisplatine eine invertierte Logik, schaltet also bei LOW ein. Mit dem Attribut active_low = yes sollte diese Invertierung greifen, hat es bei mir aber ersteinmal nicht getan. Ein Blick ins Log zeigt dann: Can't open file: Relais, active_low, also ein Berechtigungsproblem :(
Nach Lesen der commandref ist der erste Ansatz, per sudo adduser fhem gpio den User fhem der Gruppe gpio zuzuorden - Leider gibt es scheinbar im aktuellen Raspbian keine solche Gruppe mehr.
Zweiter Ansatz aus der commandref: in der Datei rc.local die Berechtigungen setzen, bevor Fhem startet. Die Einträge von dort übernommen und angepasst - leider immer noch kein Zugriff auf die Dateien, diese werden nach Reboot immer wieder mit root:root neu angelegt und sind von fhem aus nicht beschreibbar.
Nach Recherche im Web habe ich dann herausgefunden, das es in neueren Raspian Versionen eine Veränderung im Device Tree gegeben hat und das beschriebene Verzeichnis /sys/devices/virtual nicht mehr existiert. Nun findet man die Datein hier /sys/devices/soc/....
Folgender Eintrag in der rc.local funktioniert nun endlich auch mit dem aktuellen Raspian:
echo 17 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/soc/*.gpio/*
chown -R fhem:root /sys/class/gpio/*
Ich habe gerade auf meinem Raspberry Pi B 512 die Version
2015-05-05-raspbian-wheezy installiert.
Die Gruppe gpio ist vorhanden.
Alles geht auf Anhieb OHNE wiringpi (ausser pud_resistor natürlich):
pi@raspberrypi512 /sys/class/gpio $ ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jan 1 1970 export
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan 1 1970 unexport
pi@raspberrypi512 /sys/class/gpio $ echo 27 > export
pi@raspberrypi512 /sys/class/gpio $ ls -l gpio27/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 active_low
lrwxrwxrwx 1 root gpio 0 Jun 23 21:31 device -> ../../../20200000.gpio
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 direction
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 edge
lrwxrwxrwx 1 root gpio 0 Jun 23 21:31 subsystem -> ../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 uevent
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 value
Bist du sicher das du die aktuelle Version installiert hast?
Ich habe gerade auf meinem Raspberry Pi2 B die Version 2015-05-05-raspbian-wheezy installiert.
Die Gruppe gpio ist vorhanden.
Alles geht auf Anhieb OHNE wiringpi (ausser pud_resistor natürlich):
pi@raspberrypib2 /sys/class/gpio $ ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jan 1 1970 export
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan 1 1970 unexport
pi@raspberrypib2 /sys/class/gpio $ echo 27 > export
pi@raspberrypib2 /sys/class/gpio $ ls -l gpio27/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 active_low
lrwxrwxrwx 1 root gpio 0 Jun 23 21:31 device -> ../../../20200000.gpio
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 direction
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 edge
lrwxrwxrwx 1 root gpio 0 Jun 23 21:31 subsystem -> ../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 uevent
-rwxrwx--- 1 root gpio 4096 Jun 23 21:31 value
[/quote]
Hallo,
nur zur Info. Mit aktuellen Raspbian von letzter Woche habe ich exakt das gleiche Problem, wie MichaS.
Die Rechte nach einem Naustart sind root:root.
Gruß,
Yogi
Hallo nochmal,
ich habe das jetzt nochmal nachgestellt.
Folgendes Problem:
attribut active_low für GPIO wird wegen Berechtigungsproblem nicht geschrieben
Folgende Ausgangslage:
- aktuelles Rasbian, frisch installiert auf Raspi2
- Fhem 5.6 mit allen updates
- wiringPi installiert (ohne das geht gar nichts!)
- der User fhem ist Mitglied in Gruppe gpio
Folgende Berechtigungen werden angezeigt:
root@server01:~# ls -l /sys/class/gpio/gpio13/
insgesamt 0
-rw-r--r-- 1 root root 4096 Jun 27 10:54 active_low
lrwxrwxrwx 1 root root 0 Jun 27 10:54 device -> ../../../3f200000.gpio
-rw-r--r-- 1 root root 4096 Jun 27 10:53 direction
-rw-r--r-- 1 fhem dialout 4096 Jun 27 10:53 edge
lrwxrwxrwx 1 root root 0 Jun 27 10:54 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jun 27 10:54 uevent
-rw-r--r-- 1 fhem dialout 4096 Jun 27 10:53 value
Einträge in der rc.local jeglicher Art bringen gar keine Änderung.
Wenn ich die Rechte für die Datei active_low manuell anpasse funktioniert alles, jedoch nach einem Neustart ist alles wieder weg. Das RPI_GPIO-Modul benutzt bei manchen Attributen (z.B. Direction) scheinbar das WiringPi-Tool, um sich die Rechte zu besorgen. Bei dem Attribute "Active_low" jedoch nicht. Könnte man das anpassen?
gruß,
Yogi
Zitat von: cocktailyogi am 27 Juni 2015, 10:52:02
nur zur Info. Mit aktuellen Raspbian von letzter Wiche habe ich exakt dad gleiche Problem, wie MichaS.
Die Rechte nach einem Naustart sind root:root.
das verstehe ich nicht, habe es ja getestet und es funktionierte bei mir.
Der vermutlich einzige unterschied ist, das ich die frisch geflashte SD Karte vorher in einem B getestet habe.
Was zeigt bei dir
cat /proc/version an?
Zitat von: cocktailyogi am 27 Juni 2015, 11:05:18
Folgendes Problem:
attribut active_low für GPIO wird wegen Berechtigungsproblem nicht geschrieben
Folgende Ausgangslage:
- aktuelles Rasbian, frisch installiert auf Raspi2
- Fhem 5.6 mit allen updates
- wiringPi installiert (ohne das geht gar nichts!)
- der User fhem ist Mitglied in Gruppe gpio
Folgende Berechtigungen werden angezeigt:
root@server01:~# ls -l /sys/class/gpio/gpio13/
insgesamt 0
-rw-r--r-- 1 root root 4096 Jun 27 10:54 active_low
lrwxrwxrwx 1 root root 0 Jun 27 10:54 device -> ../../../3f200000.gpio
-rw-r--r-- 1 root root 4096 Jun 27 10:53 direction
-rw-r--r-- 1 fhem dialout 4096 Jun 27 10:53 edge
lrwxrwxrwx 1 root root 0 Jun 27 10:54 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jun 27 10:54 uevent
-rw-r--r-- 1 fhem dialout 4096 Jun 27 10:53 value
Einträge in der rc.local jeglicher Art bringen gar keine Änderung.
Wenn ich die Reche für dei Datei active_low manuell anpasse funktioniert alles, jedoch nach einem Neustart ist alles wieder weg. Das RPI_GPIO-Modul benutzt bei manchen Attributen (z.B. Direction) scheinbar das WiringPi-Tool, um sich die Rechte zu besorgen. Bei dem Attribute "Active_low" jedoch nicht. Könnte man das anpassen?
Wenn du WiringPi installiert hast dann werden die GPIOs durch das gpio Utility von WiringPi exportiert. Dieses setzt die Rechte wie du es hier angibst. Darauf habe ich aber keinen Einfluss. Die WiringPi Implementierung ist eher eine Altlast.
Kurz gesagt: Wenn WiringPi genutzt wird dann sind nur edge und value beschreibbar.
Aber zurück zum eigentlichen Problem.
sudo adduser fhem gpio hat ohne Fehlermeldung funktioniert?
Das würde heissen, es gint die Gruppe GPIO auch und damit sollten auch die GPIO Rechte passen.
Was zeigt denn:
ls -l /sys/class/gpio/ an?
Hi, sorry für die späte Meldung..... Ich habe keine Benachrichtigung erhalten....
Also zum Thema:
Ohne WiringPi geht bei mir gar nichts.
root@server01:~# cat /proc/version
Linux version 4.0.7-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #801 SMP PREEMPT Tue Jun 30 18:38:23 BST 2015
root@server01:~# sudo adduser fhem gpio
Der Benutzer ▒fhem▒ ist bereits ein Mitglied der Gruppe ▒gpio▒.
root@server01:~# ls -l /sys/class/gpio/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jul 1 16:51 export
lrwxrwxrwx 1 root gpio 0 Jul 1 16:51 gpio13 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio13
lrwxrwxrwx 1 root gpio 0 Jul 1 16:51 gpio17 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jul 1 16:51 unexport
Soweit so gut, aber nun schau dir die Rechte in den Unterordnern an....
root@server01:~# ls -l /sys/class/gpio/gpio13/*
-rw-r--r-- 1 root root 4096 Jul 1 16:51 /sys/class/gpio/gpio13/active_low
lrwxrwxrwx 1 root root 0 Jul 1 17:00 /sys/class/gpio/gpio13/device -> ../../../3f200000.gpio
-rw-r--r-- 1 root root 4096 Jul 1 16:51 /sys/class/gpio/gpio13/direction
-rw-r--r-- 1 fhem dialout 4096 Jul 1 16:51 /sys/class/gpio/gpio13/edge
lrwxrwxrwx 1 root root 0 Jul 1 16:51 /sys/class/gpio/gpio13/subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jul 1 16:51 /sys/class/gpio/gpio13/uevent
-rw-r--r-- 1 fhem dialout 4096 Jul 1 16:52 /sys/class/gpio/gpio13/value
Dort hat die Gruppe GPIO irgenwie nichts mehr zu melden.... Keine Ahnung, woher das kommt-
Gruß,
Yogi
Zitat von: cocktailyogi am 01 Juli 2015, 17:06:50
root@server01:~# cat /proc/version
Linux version 4.0.7-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #801 SMP PREEMPT Tue Jun 30 18:38:23 BST 2015
Du hast natürlich auch gleich nen Kernelupdate auf den 4er gemacht 8)
Nicht das es daran liegt.
Zitat von: cocktailyogi am 01 Juli 2015, 17:06:50
root@server01:~# ls -l /sys/class/gpio/
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jul 1 16:51 export
lrwxrwxrwx 1 root gpio 0 Jul 1 16:51 gpio13 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio13
lrwxrwxrwx 1 root gpio 0 Jul 1 16:51 gpio17 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jul 1 16:51 unexport
Das sieht normal aus. Mitglieder der Gruppe gpio dürfen auf export und unexport voll zugreifen.
Hast du die Rechte manipuliert? Also über die rc.local oder so?
Versuche einmal als Nutzer "pi" (der sollte natürlich auch in der Gruppe GPIO sein):
echo 10 > /sys/class/gpio/exportund schaue dir wenn es funktioniert hat mit
ls -l /sys/class/gpio/gpio10/die Rechte an.
Zitat von: cocktailyogi am 01 Juli 2015, 17:06:50
Soweit so gut, aber nun schau dir die Rechte in den Unterordnern an....
root@server01:~# ls -l /sys/class/gpio/gpio13/*
-rw-r--r-- 1 root root 4096 Jul 1 16:51 /sys/class/gpio/gpio13/active_low
lrwxrwxrwx 1 root root 0 Jul 1 17:00 /sys/class/gpio/gpio13/device -> ../../../3f200000.gpio
-rw-r--r-- 1 root root 4096 Jul 1 16:51 /sys/class/gpio/gpio13/direction
-rw-r--r-- 1 fhem dialout 4096 Jul 1 16:51 /sys/class/gpio/gpio13/edge
lrwxrwxrwx 1 root root 0 Jul 1 16:51 /sys/class/gpio/gpio13/subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jul 1 16:51 /sys/class/gpio/gpio13/uevent
-rw-r--r-- 1 fhem dialout 4096 Jul 1 16:52 /sys/class/gpio/gpio13/value
Dort hat die Gruppe GPIO irgenwie nichts mehr zu melden.... Keine Ahnung, woher das kommt-
Naja, das ist normal, wenn die Pins über wiringpi angelegt werden.
Der lässt einen nur auf edge und value.
Hallo zusammen,
ich würde mich gerne auch mal hier anschließen.
Und zwar habe ich folgendes Problem, dass ich per WiringPi ein Relais schalte, welches ich über FHEM triggere per Schreibtischlampe {system("sudo /wiringPi/relais1.sh")}.
Also fhem installiert, dummy und notify einprogrammiert und das ganze funktioniert. Jedoch NUR bis zum ersten reboot der Raspberry, danach tut sich nichts mehr.
sudo chmod 777 /sys/class/gpio/export habe ich auch schon ausprobiert, löst aber leider mein Problem nicht.
chown -R fhem:root /sys/devices/soc/*.gpio/*
chown -R fhem:root /sys/class/gpio/*
habe ich auch schon probiert, aber bringt auch nichts.
Mit root und pi, kann ich die gpios mit wiringpi wunderbar schalten.
Aber bekomme es einfach nicht ans laufen, hat jemand ne Idee?
Grüße
Zitat von: JimKnopf182 am 04 Juli 2015, 18:03:36
Und zwar habe ich folgendes Problem, dass ich per WiringPi ein Relais schalte, welches ich über FHEM triggere per Schreibtischlampe {system("sudo /wiringPi/relais1.sh")}.
Also fhem installiert, dummy und notify einprogrammiert und das ganze funktioniert. Jedoch NUR bis zum ersten reboot der Raspberry, danach tut sich nichts mehr
....
Mit root und pi, kann ich die gpios mit wiringpi wunderbar schalten.
Läuft dein Shellscript nur als superuser?
Dann kann es daran liegen, das der fhem User nicht in der sudoers Gruppe ist.
Wieso nutzt du eigentlich nicht das rpi_gpio Modul von Fhem?
Nachdem bei mir ja die Gruppe GPIO fehlte, hatte ich einige Posts vorher mit der Kernelversion 3.18 und dem dort geänderten Devicetree mit folgenden Einträgen in der rc.local Erfolg (Beispiel GPIO17)
echo 17 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/soc/*.gpio/*
chown -R fhem:root /sys/class/gpio/*
Nun nach einem Update auf die neueste Kernelversion 4.0 (über Hexxeh rpi-update Script) gibt es schon wieder eine Änderung des Devicetree - es kommt ein Unterverzeichnis "platform" hinzu >:( Nun funkionieren folgende Einträge für GPIO17:
echo 17 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/platform/soc/*.gpio/*
chown -R fhem:root /sys/class/gpio/*
Also vorher immer mit ls -l /sys/class/gpio/ prüfen wie die Verzeichnisse bei euch wirklich liegen - dann sollte es funktionieren, wenn der von klausw beschriebene Ansatz mit frischer Installation und GPIO Gruppe nicht funktionieren will 8)
Grüße
Micha
Zitat von: MichaS am 08 Juli 2015, 21:31:18
Nun nach einem Update auf die neueste Kernelversion 4.0 (über Hexxeh rpi-update Script) gibt es schon wieder eine Änderung des Devicetree - es kommt ein Unterverzeichnis "platform" hinzu >:( Nun funkionieren folgende Einträge für GPIO17:
Es lebe die Kontinuität ;)
Vielleicht liegt es an wiringpi ... also das Problem mit der gpio Gruppe
Ich habe immer ohne getestet.
Das Werde ich bei Gelegenheit nachholen
Entweder ich hab's in einem vorhergegangenen Post überlesen oder es hilft vielleicht noch jemandem (oder ich bin der einzige Trottel der drauf reinfällt.)
Ich habe schon einiges vorher mit WiringPi gemacht, daher bin ich von der GPIO-Nummerierung von WiringPi ausgegangen. Die verwendet die Spalte 'Name' während man in FHEM und rc.local die Spalte 'BCM' für die Definitionen verwenden muss. Kernel-Update, FHEM-Update, 5 Knoten im Hirn, aber kaum macht man's richtig funktioniert's ;)
pi@raspfhemsat1 ~ $ gpio readall
+-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | IN | 1 | 3 || 4 | | | 5V | | |
| 3 | 9 | SCL.1 | IN | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | OUT | 0 | 7 || 8 | 1 | ALT0 | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | ALT0 | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 1 | IN | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | IN | 1 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | IN | 1 | 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 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | IN | 0 | 23 || 24 | 1 | IN | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | IN | CE1 | 11 | 7 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| 28 | 17 | GPIO.17 | IN | 0 | 51 || 52 | 0 | IN | GPIO.18 | 18 | 29 |
| 30 | 19 | GPIO.19 | IN | 0 | 53 || 54 | 0 | IN | GPIO.20 | 20 | 31 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
Zitat von: Markus9 am 29 Juli 2015, 18:35:42
Entweder ich hab's in einem vorhergegangenen Post überlesen oder es hilft vielleicht noch jemandem (oder ich bin der einzige Trottel der drauf reinfällt.)
Ich habe schon einiges vorher mit WiringPi gemacht, daher bin ich von der GPIO-Nummerierung von WiringPi ausgegangen. Die verwendet die Spalte 'Name' während man in FHEM und rc.local die Spalte 'BCM' für die Definitionen verwenden muss. Kernel-Update, FHEM-Update, 5 Knoten im Hirn, aber kaum macht man's richtig funktioniert's ;)
pi@raspfhemsat1 ~ $ gpio readall
+-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | IN | 1 | 3 || 4 | | | 5V | | |
| 3 | 9 | SCL.1 | IN | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | OUT | 0 | 7 || 8 | 1 | ALT0 | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | ALT0 | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 1 | IN | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | IN | 1 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | IN | 1 | 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 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | IN | 0 | 23 || 24 | 1 | IN | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | IN | CE1 | 11 | 7 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| 28 | 17 | GPIO.17 | IN | 0 | 51 || 52 | 0 | IN | GPIO.18 | 18 | 29 |
| 30 | 19 | GPIO.19 | IN | 0 | 53 || 54 | 0 | IN | GPIO.20 | 20 | 31 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
In der Commandref gibt's eine Tabelle dafür. Da wiringpi nicht notwendig ist macht auch dessen Nummerierung keinen Sinn 8)
@klausw
Zuerst einmal recht herzlichen Dank für die Bereitstellung deines tollen Moduls, welches
in den vergangenen Monaten nach einem zusätzlichem "sudo adduser fhem gpio"
hervorragend funktioniert hat.
@all
Nun habe ich in meinem Übereifer leider ein Update auf meinem "Raspberry Pi 2" durchgeführt => nun Linux 4.1.6-v7+ auf armv7l
Das Ergebnis ist, dass Fhem keine Rechte mehr besitzt z.B "active_low" zu schalten.
Im Fhem-Log erhalte ich den Eintrag "Can't open file: Relaise_1, active_low"
Nun habe ich mit einem "sudo chmod –R 777 /sys/devices/platform/soc/3f200000.gpio/gpio/*" leider nur eine unbefriedigende Lösung gefunden,
denn das funktioniert nur bis zum nächsten Neustart des Raspberry's.
Dann hat wieder nur mehr die Gruppe: root mit dem Eigentümer: root zugriff auf den "gpio-Ordner" (0755).
Hat da vielleicht jemand das gleiche Problem bzw. eine Lösung dafür?
Vielen Dank
Zenz
Eine passende UDEV-Regel, welche die Gruppierung passend setzt.
Kann nur momentan nicht zu hause nachsehen, wie die Regel lauten müsste,
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
Mit "Glück" morgen .. habe vorhin aus der Ferne das System abgeschossen (Fehler saß vor dem Bildschirm :-[ )
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
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 /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.
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:
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 (https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=9667)
@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
sudo usermod -a -G gpio fhem
eine Datei erzeugen
sudo nano /etc/udev/rules.d/80-gpio-noroot.rules
folgenden Inhalt einfügen
# /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/"
sudo service udev restart
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
Was Du pobieren könntest, kan selber malngels RasPi nicht testen:
Anstatt Deiner Zeile in die UDEV-Datei:
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" ;D
Wenn Du experimentierfreudig bist ... könntest Du eventuell testen?
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
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
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:
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" ;D
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.
Seltsam, wenn FHEM die gpios anlegt muss es doch zugriff haben.
Was bringt:
ls -l /sys/class/gpio
so siehts aus.
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
Ich habe gerade auf meinem Testsystem einen GPIO definiert mit: define gpio24 RPI_GPIO 24
Es erscheint die Fehlermeldung: gpio24: failed to export pin gpio24
Im Log steht:
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:
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
Und was ist mit dem 2. teil der Fehlermeldung?
Existiert "/usr/local/bin/gpio"?
Zitat von: SmartFan am 08 September 2015, 07:17:34
so siehts aus.
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 ~ $
die Rechte passen.
Hast du:
sudo adduser fhem gpio
sudo reboot ausgeführt?
Edit:
den gpio21 hast du per FHEM angelegt?
@ Werniemann: Die Datei /usr/local/bin/gpio existiert nicht. Weder auf dem funktionierenden Sytem, noch auf dem nicht funktionierenden.
@klausw: Ja, das Testsystem ist eine Kopie des Wirksystems mit einer auf den Test reduzierten fhem.cfg. Insofern lief der GPIO vor dem Upgrade mit fhem in gpio..
pi@raspberrypi /usr/local/bin $ sudo adduser fhem gpio
The user `fhem' is already a member of `gpio'.
Ich habe gerade ins Modul geschaut, /usr/local/bin/gpio ist für WiringPi. WiringPi habe ich nicht installiert, da ich die "pud_resistor" nicht nutze.
Zitat von: Ellert am 08 September 2015, 09:50:19
@klausw: Ja, das Testsystem ist eine Kopie des Wirksystems mit einer auf den Test reduzierten fhem.cfg. Insofern lief der GPIO vor dem Upgrade mit fhem in gpio..
pi@raspberrypi /usr/local/bin $ sudo adduser fhem gpio
The user `fhem' is already a member of `gpio'.
Ich habe gerade ins Modul geschaut, /usr/local/bin/gpio ist für WiringPi. WiringPi habe ich nicht installiert, da ich die "pud_resistor" nicht nutze.
Ah, jetzt bist du mir zuvorgekommen, das wollte ich gerade schreiben. Außerdem ist es eher eine Altlast aus der Zeit, wo es dir Gruppe gpio noch nicht gab.
1. Kannst du bitte das Ergebnis von:
ls -l /sys/class/gpio/gpio24posten.
2. Was passiert wenn du
define gpio24 RPI_GPIO 24erneut ausführst?
pi@raspberrypi /usr/local/bin $ ls -l /sys/class/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Sep 8 07:49 /sys/class/gpio/gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24
define gpio24 RPI_GPIO 24 liefert wieder: gpio24: failed to export pin gpio24
Das Device wird nicht angelegt.
und im Log steht mit verbose 5:
2015.09.08 10:36:54 5: Cmd: >define gpio24 RPI_GPIO 24<
2015.09.08 10:36:54 4: gpio24: write access to file /sys/class/gpio/export, use it to export GPIO
2015.09.08 10:36:59 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 10:36:59 1: gpio24: failed to export pin gpio24
2015.09.08 10:36:59 1: define gpio24 RPI_GPIO 24: gpio24: failed to export pin gpio24
Im Frontend ergeben die Abfragen:
{(-e "/sys/class/gpio/gpio24")} liefert 1
{(-w "/sys/class/gpio/gpio24/value")} liefert "nichts"
{(-w "/sys/class/gpio/gpio24/direction")} liefert "nichts"
{(-w "/sys/class/gpio/export")} liefert 1
Und wenn ich mir die Rechte anzeigen lasse ist gpio nicht dabei:
pi@raspberrypi /usr/local/bin $ ls -l /sys/class/gpio/gpio24/*
-rw-r--r-- 1 root root 4096 Sep 8 11:21 /sys/class/gpio/gpio24/active_low
lrwxrwxrwx 1 root root 0 Sep 8 11:21 /sys/class/gpio/gpio24/device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Sep 8 11:05 /sys/class/gpio/gpio24/direction
-rw-r--r-- 1 root root 4096 Sep 8 11:21 /sys/class/gpio/gpio24/edge
lrwxrwxrwx 1 root root 0 Sep 8 07:49 /sys/class/gpio/gpio24/subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Sep 8 07:49 /sys/class/gpio/gpio24/uevent
-rw-r--r-- 1 root root 4096 Sep 8 07:49 /sys/class/gpio/gpio24/value
Im funktionierenden System sieht es so aus:
pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio24/*
-rwxrwx--- 1 root gpio 4096 Sep 7 20:36 /sys/class/gpio/gpio24/active_low
lrwxrwxrwx 1 root gpio 0 Sep 7 20:36 /sys/class/gpio/gpio24/device -> ../../../20200000.gpio
-rwxrwx--- 1 root gpio 4096 Sep 7 20:36 /sys/class/gpio/gpio24/direction
-rwxrwx--- 1 root gpio 4096 Sep 7 20:36 /sys/class/gpio/gpio24/edge
lrwxrwxrwx 1 root gpio 0 Sep 7 20:36 /sys/class/gpio/gpio24/subsystem -> ../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Sep 7 20:36 /sys/class/gpio/gpio24/uevent
-rwxrwx--- 1 root gpio 4096 Sep 7 20:36 /sys/class/gpio/gpio24/value
Zitat von: Ellert am 08 September 2015, 10:44:52
pi@raspberrypi /usr/local/bin $ ls -l /sys/class/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Sep 8 07:49 /sys/class/gpio/gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24
define gpio24 RPI_GPIO 24 liefert wieder: gpio24: failed to export pin gpio24
Das Device wird nicht angelegt.
Oha, das ist bisschen wenig.
Das sollte etwas mehr bringen:
ls -l /sys/class/gpio/gpio24/
Zitat von: Ellert am 08 September 2015, 10:44:52
und im Log steht mit verbose 5:
2015.09.08 10:36:54 5: Cmd: >define gpio24 RPI_GPIO 24<
2015.09.08 10:36:54 4: gpio24: write access to file /sys/class/gpio/export, use it to export GPIO
2015.09.08 10:36:59 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 10:36:59 1: gpio24: failed to export pin gpio24
2015.09.08 10:36:59 1: define gpio24 RPI_GPIO 24: gpio24: failed to export pin gpio24
Die zweite Zeile ist falsch, da muss ich die Fehlermeldungen mal anpassen. Schreibzugriff ist schließlich vorhanden :/
Irgend wie hängt die Rechtevergabe mit dem DeviceTree zusammen, denn wenn ich in der config.txt den DeviceTree abschalte, kann ich mit define gpio24 RPI_GPIO 24 den Port definieren. Siehe https://www.raspberrypi.org/documentation/configuration/device-tree.md#part4.3 (https://www.raspberrypi.org/documentation/configuration/device-tree.md#part4.3)
Das wird aber keine Lösung auf Dauer sein.
Ich hatte letzten meinen Beitrag schon ergänzt, das ist ein bisschen unübersichtlich, tut mir Leid. Hier nochmal die Rechte:
pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio24/
total 0
-rw-r--r-- 1 root root 4096 Sep 8 12:34 active_low
lrwxrwxrwx 1 root root 0 Sep 8 12:34 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Sep 8 12:34 direction
-rw-r--r-- 1 root root 4096 Sep 8 12:34 edge
lrwxrwxrwx 1 root root 0 Sep 8 12:34 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Sep 8 12:34 uevent
-rw-r--r-- 1 root root 4096 Sep 8 12:34 value
p
Zitat von: Ellert am 08 September 2015, 12:41:34
Irgend wie hängt die Rechtevergabe mit dem DeviceTree zusammen, denn wenn ich in der config.txt den DeviceTree abschalte, kann ich mit define gpio24 RPI_GPIO 24 den Port definieren. Siehe https://www.raspberrypi.org/documentation/configuration/device-tree.md#part4.3 (https://www.raspberrypi.org/documentation/configuration/device-tree.md#part4.3)
Das wird aber keine Lösung auf Dauer sein.
Ich hatte letzten meinen Beitrag schon ergänzt, das ist ein bisschen unübersichtlich, tut mir Leid. Hier nochmal die Rechte:
Alles gut, ich fands durchaus Übersichtlich ;)
Wo es nicht geht ist die Gruppe root anstelle von gpio. Mich wundert es nur, das es bei manchen funktioniert und bei anderen nicht.
Seltsamerweise läuft bei mir alles normal mit aktuellem Image und Kernel. Ich habe I2C in der config.txt aktiviert:
dtparam=i2c_arm=on aber daran sollte es eigentlich nicht liegen.
Immerhin ist es erstmal eine Lösung.
Du hast
device_tree= in die config.txt eingefügt?
Ich habe es vermulich überlesen...welches Pi hast du?
Als Wirksystem habe ich einen Pi B+, der meldet sich mit: Linux raspberrypi 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l. Damit funktionieren die GPIOs, wie in der Comandref zu RPI_GPIO beschrieben einwandfrei.
Mein Testsystem läuf auch auf einem Pi B+ und basiert auf dem Wirksystem. Darauf habe ich ein Upgrade durchgeführt, mit:
sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get autoremove -y
sudo reboot
Dann meldet sich das System mit: Linux raspberrypi 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l.
Hier gibt es die Rechteprobleme mit den GPIOs. Die Probleme verschwinden, wenn ich versuchsweise "device_tree=" am Ende der config.txt eintrage und neu starte. Das wird wahrscheinlich Geräte beeinflussen, die jetzt über DeviceTree angesprochen werden. Ich habe das nicht getestet, da an dem Testsystem nichts weiter angeschlossen ist. Ich denke jedoch, der Versuch deutet darauf hin, dass das Rechteproblem mit dem DeviceTree zusammen hängt. Ich denke am Modul liegt es nicht, denn wenn ich einen GPIO manuell exportiere, besteht das gleiche Problem:
pi@raspberrypi ~ $ echo "24" > /sys/class/gpio/export
pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio24/
total 0
-rw-r--r-- 1 root root 4096 Sep 8 16:13 active_low
lrwxrwxrwx 1 root root 0 Sep 8 16:13 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Sep 8 16:13 direction
-rw-r--r-- 1 root root 4096 Sep 8 16:13 edge
lrwxrwxrwx 1 root root 0 Sep 8 16:13 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Sep 8 16:13 uevent
-rw-r--r-- 1 root root 4096 Sep 8 16:13 value
Es besteht für mich keine Notwendigkeit zum Upgrade, daher bleibt mein Wirksystem unverändert.
Hatte auch massiv das Problem mit den GPio Berechtigungen. fhem hat die immer mit root:root angelegt und ich musste die Rechte manuell ändern, was nur bis zum nächsten Reboot funktionierte.
Hilfe hat nur ein komplett neu aufgesetzter raspi mit raspbian jessie gebracht.
- Sytem neu aufgespielt
- fhem installiert
- wiringPi installiert
jetzt gehts und die GPIOS werden sauber mit root:gpio angelegt
Gruß
Mario
Zitat von: cremofix am 29 Oktober 2015, 17:05:00
Hilfe hat nur ein komplett neu aufgesetzter raspi mit raspbian jessie gebracht.
Kann ich bestätigen. Nach dem Upgrade von Wheezy ist die Rechtevergabe für die GPIOs im A...
Nach Neuinstallation funktioniert es wieder mit der gruppe GPIO wie in der commandref beschrieben.
Zitat von: klausw am 02 Dezember 2015, 00:42:25
Kann ich bestätigen. Nach dem Upgrade von Wheezy ist die Rechtevergabe für die GPIOs im A...
Nach Neuinstallation funktioniert es wieder mit der gruppe GPIO wie in der commandref beschrieben.
Bei mir ist es immernoch so.... Vor einigen Wochen kam es mir so vor, als sei ich der Einzige mit dem Problem, aber so langsam zeichnet sich das Schema ab. ;D Nur dass ich keine Neuinstalltion machen kann, da mein RPI2 noch viel mehr Aufgaben erledigt. Wie kann ich helfen, die Ursache einzugrenzen? Könnten wir irgendwie eine Neuinstalltion mit mit meiner "Upgradeversion" vergleichen?
Gruß,
Yogi
Hallo,
leider habe ich auch ein Problem:
Ich habe 5 Pins in Fhem definiert, 3 funktionieren, bei 2 bekomme ich einen Logeintrag "/usr/local/bin/gpio: Unable to open GPIO direction interface for pin 27: No such file or directory" das gleiche für Pin 17.
Unter /sys/class/gpio sind die zwei auch nicht angelegt.
Mit "echo 17 > ...../export" kommt die Meldung "Gerät oder Ressource ist beleg.
Dann wollte ich mit "echo 17 > ...../unexport" den Pin freigeben geben, kommt die Meldung "Schreibfehler, Argument ist ungültig"
Nachtrag:
Die Meldungen kommen so unter pi, sudo und su root.
Fhem und pi ist in der Gruppe gpio eingetragen.
Hat jemand eine Idee?
Zitat von: frober am 06 Dezember 2015, 16:11:39
Ich habe 5 Pins in Fhem definiert, 3 funktionieren, bei 2 bekomme ich einen Logeintrag "/usr/local/bin/gpio: Unable to open GPIO direction interface for pin 27: No such file or directory" das gleiche für Pin 17.
Unter /sys/class/gpio sind die zwei auch nicht angelegt.
Mit "echo 17 > ...../export" kommt die Meldung "Gerät oder Ressource ist beleg.
Dann wollte ich mit "echo 17 > ...../unexport" den Pin freigeben geben, kommt die Meldung "Schreibfehler, Argument ist ungültig"
Nachtrag:
Die Meldungen kommen so unter pi, sudo und su root.
Fhem und pi ist in der Gruppe gpio eingetragen.
wenn ein GPIO geht dann gehen grundsätzlich alle
Gerät oder Ressource ist beleg sagt eigentlich alles ;)
17 und 27 haben auch alternative Funktionen vermutlich hat du die SPI in der config.txt (z.B. über raspi-config) oder anderswo aktiviert
Zitat von: klausw am 06 Dezember 2015, 22:34:40
17 und 27 haben auch alternative Funktionen vermutlich hat du die SPI in der config.txt (z.B. über raspi-config) oder anderswo aktiviert
Erstmal danke für den Tip.
Hatte noch keine Zeit zum testen, aber wo sind die alternativen Funktionen von GPIO 17 + 27 dokumentiert?
Ich bin nach der Tabelle aus der Commandref gegangen und habe nur Pin's gewählt die keine andere Funktion haben.
Kann ich irgend wo sehen, was meine Pin's belegt?
Zitat von: frober am 07 Dezember 2015, 12:41:50
Erstmal danke für den Tip.
Hatte noch keine Zeit zum testen, aber wo sind die alternativen Funktionen von GPIO 17 + 27 dokumentiert?
Ich bin nach der Tabelle aus der Commandref gegangen und habe nur Pin's gewählt die keine andere Funktion haben.
Kann ich irgend wo sehen, was meine Pin's belegt?
mit dem gpio utility von wiringPi kannst du das anschauen
Bei einem halben Dutzend verschiedener Raspberrys ist die Tabelle in der Commandref nicht vollständig.
Google hilft da 8) Zugegebenermaßen ist es nicht einfach eine vollständige Pinbelegung zu finden. Diese (http://pinout.xyz/) ist ganz gut.
Aber wenn das GPIO Verzeichnis nicht existiert und bei Exportversucht die Meldung kommt das die Ressource belegt ist kann es eigentlich nix anderes sein.
Aber von allein aktivieren sich die alternativen Funktionen nicht (ausgenommen die serielle Schnittstelle GPIO14,15).
Wo hast du dein SD-Image her?
Hast du über raspi-config z.B. die SPI aktiviert? (das könntest du auch in der /boot/config.txt als Paramter "dtparam=spi=on" finden)
Erstmal danke für die Hilfe.
SPI ist nicht aktiv, die Pins lassen sich trotzdem nicht schalten.
Was meinst du genau mit dem gpio utility?
Mit gpio readall kann ich die Belegung (Reservierung) nicht erkennen.
Meinen Raspi habe ich anfangs mit einen 4"-Display betrieben, daher habe ich, als Anfänger, ein Image mit den integrierten Treibern installiert.
Ich glaube, ich habe das über den Verkäufer des Displays bezogen.
Bei Gelegenheit werde ich den Raspi neu aufsetzen und testen, habe einen zweiten zum testen bestellt, damit wird alles einfacher.
Zitat von: frober am 08 Dezember 2015, 15:32:42
SPI ist nicht aktiv, die Pins lassen sich trotzdem nicht schalten.
Wie hast du das Überprüft?
Zitat von: frober am 08 Dezember 2015, 15:32:42
Was meinst du genau mit dem gpio utility?
Mit gpio readall kann ich die Belegung (Reservierung) nicht erkennen.
gpio readall gibt eine Liste aus
In der Spalte Mode steht die Konfiguration.
ALTx bedeutet, das der Pin alternativ belegt ist
Im Link in meinem letzten Post stehen die alternativen Belegungen drin
Zitat von: frober am 08 Dezember 2015, 15:32:42
Meinen Raspi habe ich anfangs mit einen 4"-Display betrieben, daher habe ich, als Anfänger, ein Image mit den integrierten Treibern installiert.
Ich glaube, ich habe das über den Verkäufer des Displays bezogen.
Die Aufsteckdisplays werden meines Wissens über die SPI angeschlossen.
Je nachdem wie alt das Modul ist können die SPI Kernelmodule beispielsweise auch auch in die /etc/modules eingetragen worden sein
Zitat von: frober am 08 Dezember 2015, 15:32:42
Bei Gelegenheit werde ich den Raspi neu aufsetzen und testen, habe einen zweiten zum testen bestellt, damit wird alles einfacher.
Das ist hilfreich 8)
SPI habe ich mit raspi-config und config.txt überprüft, wie du es beschrieben hast.
In Modules steht was vom Display: "...fbtft...gpios=DC:22, Reset:27........gpio_pendown=17...."
Laut gpio readall ist PIN 22 und 27 als Ausgang und high definiert, PIN 17 als Eingang.
Ich denke das wars, danke.
Wie kann ich die PINs freigeben, bzw. die Displaytreiber entfernen?
Oder ist eine Neuinstallation und -Konfiguration einfacher?
Zitat von: frober am 08 Dezember 2015, 17:43:01
SPI habe ich mit raspi-config und config.txt überprüft, wie du es beschrieben hast.
In Modules steht was vom Display: "...fbtft...gpios=DC:22, Reset:27........gpio_pendown=17...."
Laut gpio readall ist PIN 22 und 27 als Ausgang und high definiert, PIN 17 als Eingang.
Ich denke das wars, danke.
Wie kann ich die PINs freigeben, bzw. die Displaytreiber entfernen?
Oder ist eine Neuinstallation und -Konfiguration einfacher?
versuche mal die entsprechenden Zeilen rauszulöschen, dann sollten die Module nicht geladen werden und die Pins entsprechend verfügbar sein
Hallöchen, ich habe ein paar Fragen zum Thema GPIO des RaspberryPi2.
Ich besitze einen RaspberryPi2 mit FHEM und eineigen HM Geräten.
Nun möchte ich meine alte Alarmanalge ablösen und ins FHEM einbinden.
Ich habe 6 normale Reedkontake an den Türen die ich ins FHEM einbinden möchte.
Nun habe ich gelesen das ich diese evtl. direkt an den RaspberryPi2 an eine GPIO Schnittstelle hängen kann!?
Die normalen Litzekabel vom jeweiligen Reedkontakt zum RaspberryPi2 sind ca. 10-30m lang. Würde der Schaltkontakt direkt an den RaspberryPi2 damit funktionieren? Falls ja, ist dies für eine Alarmanlage Störungssicher genug zwecks Zuverlässigkeit!?
Falls ja, könnte mir jemand erklären wie ich dies verwirklichen kann?
Also welche Pins am Rasp. belegen, welche Dateien(und wie) auf dem Rasp. installieren und welche Befehle ich in die fhem.config eintragen muss!?
Ich bin dabei noch eher ein Neuling.
Würde mich echt freuen wenn mir jemand Licht ins dunkle bringen könnte
Vielen Dank
Gruß Thomas
Ich hab mal für Dich gegoogelt.
ZitatWürde der Schaltkontakt direkt an den RaspberryPi2 damit funktionieren?
http://www.forum-raspberrypi.de/Thread-gpio-taster-max-kabellaenge (http://www.forum-raspberrypi.de/Thread-gpio-taster-max-kabellaenge)
ZitatStörungssicher genug zwecks Zuverlässigkeit!?
Was heisst genug? Für die Versicherung, für Dich?
http://www.kriminalberatung.de/alarmanlagen/ (http://www.kriminalberatung.de/alarmanlagen/)
http://anti-scam.de/cgi-bin/yabb2/YaBB.pl?num=1384862385/9#9 (http://anti-scam.de/cgi-bin/yabb2/YaBB.pl?num=1384862385/9#9)
ZitatFalls ja, könnte mir jemand erklären wie ich dies verwirklichen kann?
https://klenzel.de/1839 (https://klenzel.de/1839)
ZitatAlso welche Pins am Rasp. belegen
http://forum.fhem.de/index.php/topic,16519.msg370939.html#msg370939 (http://forum.fhem.de/index.php/topic,16519.msg370939.html#msg370939)
Zitatwelche Dateien(und wie) auf dem Rasp. installieren
http://fhem.de/commandref_DE.html#RPI_GPIO (http://fhem.de/commandref_DE.html#RPI_GPIO)
Zitatwelche Befehle ich in die fhem.config eintragen muss!?
http://www.fhemwiki.de/wiki/Konfiguration#Bearbeitung_der_Konfiguration (http://www.fhemwiki.de/wiki/Konfiguration#Bearbeitung_der_Konfiguration)
Zitat von: Depechem am 15 Dezember 2015, 22:50:57
Ich habe 6 normale Reedkontake an den Türen die ich ins FHEM einbinden möchte.
Nun habe ich gelesen das ich diese evtl. direkt an den RaspberryPi2 an eine GPIO Schnittstelle hängen kann!?
Die normalen Litzekabel vom jeweiligen Reedkontakt zum RaspberryPi2 sind ca. 10-30m lang. Würde der Schaltkontakt direkt an den RaspberryPi2 damit funktionieren? Falls ja, ist dies für eine Alarmanlage Störungssicher genug zwecks Zuverlässigkeit!?
Falls ja, könnte mir jemand erklären wie ich dies verwirklichen kann?
Sollte eigentlich funktionieren.
Pullup (10k) an den GPIO. Über den Reedkontakt dann die Masse auf den GPIO anschließen.
Also wenn Reedkontakt offen -> GPIO high
Reedkontakt geschlossen -> GPIO low
Zitat von: Depechem am 15 Dezember 2015, 22:50:57
Also welche Pins am Rasp. belegen, welche Dateien(und wie) auf dem Rasp. installieren und welche Befehle ich in die fhem.config eintragen muss!?
Wenn du ein relativ frisch aufgesetztes System hast sollte es problemlos gehen.
Hier (http://fhem.de/commandref_DE.html#RPI_GPIO) wird dir geholfen.
Anbei mal eine neue Version, die auch den Pfad vom neuerdings beim Jessie mitgelieferten WiringPi berücksichtigt.
Außerdem wird /sys/class/aml_gpio als Basispfad für das ODROID-C1 erkannt.
Für den Fall das Basispfad oder gpio Utility von WiringPi irgendwo anders sind, lassen sich jetzt beide Werte beim define mit übergeben.
Werde es nächste Woche einchecken wenn keine Probleme auftauchen.
Danke klausw
Nun klappt es mit dem Inputs ;D
Zitat von: klausw am 17 März 2016, 00:00:26
Anbei mal eine neue Version, die auch den Pfad vom neuerdings beim Jessie mitgelieferten WiringPi berücksichtigt.
Außerdem wird /sys/class/aml_gpio als Basispfad für das ODROID-C1 erkannt.
....
Hallo Klaus,
bin jetzt erst zum testen gekommen. In Zeile 26 habe ich die Reihenfolge getauscht, da der ODROID-C1 auch ein "/sys/class/gpio" hat.
Jetzt werden Impulse erkannt. Auf meinem RasPi habe ich es noch nicht getest. Mache ich aber noch.
my @gpiodirs = ("/sys/class/aml_gpio", "/sys/class/gpio" );
Jörg
PS: Hab es auf meine RasPi getestet und es funktioniert. Vielen Dank.
Zitat von: pejonp am 20 März 2016, 18:34:01
bin jetzt erst zum testen gekommen. In Zeile 26 habe ich die Reihenfolge getauscht, da der ODROID-C1 auch ein "/sys/class/gpio" hat.
Jetzt werden Impulse erkannt.
PS: Hab es auf meine RasPi getestet und es funktioniert. Vielen Dank.
Ok, dann tausche ich das noch, notfalls lässt es sich ja auch im define angeben.
Sehr witzig was ist beim ODROID-C1 denn im /sys/class/gpio vorhanden?
zur Vollständigkeit noch etwas aus einem anderen Thread (https://forum.fhem.de/index.php/topic,23164.msg423513.html#msg423513). Das Problem bezog sich das auf den Interrupt.
Dieser funktionierte nach shutdown/restart nicht mehr.
Bugfix folgt im nächsten update.
Zitat von: klausw am 21 März 2016, 12:50:54
Ok, dann tausche ich das noch, notfalls lässt es sich ja auch im define angeben.
Sehr witzig was ist beim ODROID-C1 denn im /sys/class/gpio vorhanden?
Hallo Klaus,
soweit ich das verstanden habe, kann diese Verzeichnis genommen werden, wenn nur Ausgänge benötigt werden. Das andere Verzeichnis( /sys/class/aml_gpio) ist für Eingänge(Interupt/Flanken) und auch Ausgänge. So hat es jedenfalls bei mir funktioniert.
Jörg
Hallo Klaus!
Ich hoffe, Du kannst mir helfen - ich komme gerade nicht weiter!
Ich habe zunächst die 51_RPI_GPIO.pm aus dem ersten Beitrag hier kopiert - die ist aber schon recht alt (angeblich vom 15.11.13). Ein Update von FHEM funktioniert aber nicht, weil immer die Fehlermeldung kommt:
Events (global only):
2016-04-13 01:04:18 Global global http://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: Bad hostname 'fhem.de:80'
Ich habe drei GPIO Pins angelegt, einen als Input (da ist ein Bewegungssensor angeschlossen), die anderen beiden als Output (mit LEDs zum Testen). Per Python-Skript kann ich (wenn auch als sudo) alles steuern oder abfragen.
Hier meine FHEM Defs:
define RPIPin37 RPI_GPIO 26
attr RPIPin37 direction output
define RPIPin11 RPI_GPIO 17
attr RPIPin11 direction output
define RPIPin8 RPI_GPIO 14
attr RPIPin8 direction input
attr RPIPin8 interrupt both
Der Bewegungssensor reagiert gar nicht (ändert den state nicht von ??? auf etwas anderes). Im log habe ich auch einige Fehlermeldungen, z.B.:
2016.04.13 01:03:26 1: Can't open file: RPIPin37, value
2016.04.13 01:03:32 1: Can't open file: RPIPin11, value
2016.04.13 01:03:46 1: Can't open file: RPIPin11, value
2016.04.13 01:03:47 1: Can't open file: RPIPin8, value
2016.04.13 01:14:31 1: RPIPin37: failed to export pin gpio26
2016.04.13 01:14:36 1: RPIPin11: failed to export pin gpio17
2016.04.13 01:14:41 1: RPIPin8: failed to export pin gpio14
2016.04.13 01:14:41 1: Can't open file: RPIPin8, edge
Trotzdem liess sich vorhin die LED anschalten ("set RPIPin11 on") - dann aber nicht mehr aus: Sie wird zwar aus angezeigt in FHEM, leuchtet aber weiter. Jetzt reagiert sie gerade gar nicht mehr...
Ich habe den User fhem der Gruppe gpio zugefügt mit:
sudo adduser fhem gpio
Vielen Dank!
Ich würde mir eher Gedanken machen, warum Du nicht updaten kannst:
Bad hostname 'fhem.de:80'
Funktioniert bei Deinem Rechner die Namensauflösung?
host fhem.de
ping fhem.dehost
Bitte gib uns den Output.
Heute morgen sieht der Update-Fehler etwas anders aus:
2016-04-13 09:03:57 Global global MKDIR restoreDir/2016-04-13
2016-04-13 09:04:00 Global global UPD ./CHANGED
2016-04-13 09:04:05 Global global http://fhem.de/fhemupdate/./CHANGED: Select timeout/error:
Der Output von "host fhem.de" ist:
pi@raspberrypi ~ $ host fhem.de
fhem.de has address 82.165.184.33
fhem.de mail is handled by 10 mx01.kundenserver.de.
fhem.de mail is handled by 10 mx00.kundenserver.de.
Und "ping fhem.de" geht auch:
pi@raspberrypi ~ $ ping fhem.de
PING fhem.de (82.165.184.33) 56(84) bytes of data.
64 bytes from kundenserver.de (82.165.184.33): icmp_req=1 ttl=56 time=28.6 ms
64 bytes from kundenserver.de (82.165.184.33): icmp_req=2 ttl=56 time=328 ms
64 bytes from kundenserver.de (82.165.184.33): icmp_req=3 ttl=56 time=390 ms
[code]
(alles per SSH von dem Rechner, der das Update nicht machen will...)
Zitat von: nicor2k am 13 April 2016, 09:07:45
Heute morgen sieht der Update-Fehler etwas anders aus:
Ich nehm's zurück, beim 3. Versuch jetzt geht's plötzlich mit dem Update - aber nur bis hier:
2016-04-13 09:09:04 Global global http://fhem.de/fhemupdate/FHEM/10_EnOcean.pm: Select timeout/error:
Irgendwann nach dem gefühlten 10. Mal ging das Update dann komplett - jetzt lassen sich die LEDs auch an- und ausschalten! :)
Nur das Auslesen des Bewegungssensors geht noch nicht, zumindest wird er nicht live (ohne Neuladen der Seite) angezeigt: ich dachte mit "attr RPIPin8 interrupt both" würde man das umgehen?
Vielen Dank schon mal für die Hilfe! :)
Könntest Du bitte dafür ein "Neues Ticket" eröffnen? Ich glaube, wir sollten diesen Thread nicht "Misbruchen" ;o)
Zitat von: nicor2k am 13 April 2016, 09:09:36
Nur das Auslesen des Bewegungssensors geht noch nicht, zumindest wird er nicht live (ohne Neuladen der Seite) angezeigt: ich dachte mit "attr RPIPin8 interrupt both" würde man das umgehen?
Ja, Attribut interrupt auf both sollte die Readings bei jedem Pinwechsel aktualisieren.
Steht was im Log?
Wobei ich eher den Verdacht habe, das evtl. doch nicht das komplette FHEM aktualisiert wurde.
Zur Sicherheit habe ich das Modul aus dem ersten Post gelöscht :)
Hallo Klaus,
ich habe, wie es mir scheint, das merkwürdige Problem mit nichtreagierenden interrupt Eingängen das laut letzten commit aber gefixt sein soll. Ich habe vor dem testen ein update gemacht, habe also die letzte Vers. von 11120 2016-03-23 23:49:16Z.
Ich habe u.a. 2 Eingänge mit interrupt definiert.
Wenn ich meinen Raspi reboote und dann drücke ich die Tasten dann reagiert der FHEM entsprechend.
2016-04-14 22:58:40 RPI_GPIO pin16 Dblclick: off
2016-04-14 22:58:40 RPI_GPIO pin16 Pinlevel: low
2016-04-14 22:58:40 RPI_GPIO pin16 off
2016-04-14 22:58:40 RPI_GPIO pin16 Longpress: off
2016-04-14 22:58:40 RPI_GPIO pin16 Dblclick: off
2016-04-14 22:58:40 RPI_GPIO pin16 Pinlevel: low
2016-04-14 22:58:40 RPI_GPIO pin16 off
2016-04-14 22:58:40 RPI_GPIO pin16 Longpress: off
2016-04-14 22:58:40 RPI_GPIO pin16 Pinlevel: high
2016-04-14 22:58:40 RPI_GPIO pin16 on
2016-04-14 22:58:41 RPI_GPIO pin16 Longpress: on
Nach einem shutdown restart gehen die 2 Eingänge nicht mehr, Ausgänge sind ok. Im Event Monitor als auch im log gibts bei Tastendrücken auch nichts zu sehen.
Nach restart sehe ich folgendes im log während der fhem hochfährt:
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 130.
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 131.
2016.04.14 22:45:24 1: Can't open file: pin16, edge
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 136.
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 137.
2016.04.14 22:45:29 1: Can't open file: pin18, edge
Meine config sieht so aus:
#LED
define pin19 RPI_GPIO 10
attr pin19 direction output
attr pin19 verbose 5
#LED
define pin21 RPI_GPIO 9
attr pin21 direction output
attr pin21 verbose 5
#LED
define pin23 RPI_GPIO 11
attr pin23 direction output
attr pin23 verbose 5
#Relais
define pin11 RPI_GPIO 17
attr pin11 direction output
attr pin11 verbose 5
#Relais
define pin13 RPI_GPIO 27
attr pin13 direction output
attr pin13 verbose 5
#Relais
define pin15 RPI_GPIO 22
attr pin15 direction output
attr pin15 verbose 5
#Relais
define pin12 RPI_GPIO 18
attr pin12 direction output
attr pin12 verbose 5
#Taste
define pin16 RPI_GPIO 23
attr pin16 direction input
attr pin16 interrupt both
attr pin16 verbose 5
#Taste
define pin18 RPI_GPIO 24
attr pin18 direction input
attr pin18 interrupt both
Das ist mein init script:
root@raspia:/opt/fhem# cat /root/gpioinit.sh
#!/bin/bash
chmod 222 /sys/class/gpio/export /sys/class/gpio/unexport
echo "9" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio9
echo "10" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio10
echo "11" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio11
echo "17" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio17
echo "18" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio18
echo "22" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio22
echo "27" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio27
#echo "out" > /sys/class/gpio/gpio10/direction
echo "23" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio23
echo "24" > /sys/class/gpio/export
chmod 777 -R /sys/class/gpio/gpio24
Mit der udev rule die ganz am Anfang dieses Threads steht habe ich experimentiert (raus/rein), die scheint mir hier aber keinen Unterschied zu machen. Ist das ein Überbleibsel von den Anfängen und mittlerweile überflüssig oder braucht man die doch für irgendwas ?
Manuelle Abfrage der Eingänge von console mit cat /sys/..../value funktioniert immer.
Hm.
Könntest du dir das bitte mal ansehen?
lg
knxhm
Hi knxhm,
setze das Attribut unexportpin mal auf no. Dann sollten wenigstens die Pins beim shutdown nicht gelöscht werden.
Das nur die Interrupts gehen finde ich sehr seltsam.
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 131.
Deutet auf das fehlen des Internals WiringPi_gpio hin.
Ein shutdown restart mit globalem verbose 5 gibt sicher mehr Auskunft (das verbose für die einzelnen Pins greift leider zu spät)
Und wenn du dabei bist bitte auch:
ls -l /sys/class/gpio/
ls -l /sys/class/gpio/gpio23/
jeweils vor und nach shutdown/restart
und ein "list pin16"
Nutzt du ein Raspberry? Da würde ich das aktuelle Raspbian empfehlen. Da kannst du auf das gpioinit.sh verzichten ;).
Es muss halt neu installiert werden, ein upgrade von wheezy auf jessie beschädigt die Rechteverwaltung der GPIOs.
Das udev sollte alternativ zu deinem gpioinit.sh verwendet werden können.
Hallo Klaus,
hier ist alles was du dir gewünscht hast. ;)
direkt nach reboot raspi
root@raspia:/home/pi# ls -l /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 Apr 15 18:11 export
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio10 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio11 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio11
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio17 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio18 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio18
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio22 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio22
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio23 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio27 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Apr 15 18:11 gpio9 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio9
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
root@raspia:/home/pi# ls -l /sys/class/gpio/gpio23/
total 0
-rwxrwxrwx 1 root root 4096 Apr 15 18:11 active_low
lrwxrwxrwx 1 root root 0 Apr 15 18:11 device -> ../../../20200000.gpio
-rwxrwxrwx 1 root root 4096 Apr 15 18:11 direction
-rwxrwxrwx 1 root root 4096 Apr 15 18:11 edge
lrwxrwxrwx 1 root root 0 Apr 15 18:11 subsystem -> ../../../../../../class/gpio
-rwxrwxrwx 1 root root 4096 Apr 15 18:11 uevent
-rwxrwxrwx 1 root root 4096 Apr 15 18:11 value
Internals:
DEF 23
EXCEPT_FD 18
GPIO_Basedir /sys/class/gpio
NAME pin16
NR 67
RPI_pin 23
STATE on
TYPE RPI_GPIO
WiringPi_gpio
lasttrg 1460736110.98839
Readings:
2016-01-03 01:51:06 Counter 25
2016-04-15 18:01:50 Dblclick on
2016-04-15 18:01:51 Longpress on
2016-04-15 18:01:51 Pinlevel high
2016-04-15 18:01:51 state on
Fhem:
interfaces switch
Attributes:
direction input
interrupt both
verbose 5
Tastendruck
root@raspia:/opt/fhem# tail -f log/fhem-2016-04.log
2016.04.15 18:02:16 4: Connection accepted from WEB_172.22.22.21_40461
2016.04.15 18:02:16 4: WEB_172.22.22.21_40461 POST /fhem&fw_id=83&room=all&cmd=list+pin16; BUFLEN:0
2016.04.15 18:02:16 5: Cmd: >list pin16<
2016.04.15 18:02:16 4: name: /fhem&fw_id=83&room=all&cmd=list+pin16 / RL:1349 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.04.15 18:02:16 4: WEB_172.22.22.21_40461 GET /fhem?XHR=1&inform=type=status;filter=;since=1460736135;fmt=JSON&fw_id=83×tamp=1460736136422; BUFLEN:0
2016.04.15 18:02:29 5: Triggering Temp2 (1 changes)
2016.04.15 18:02:29 5: Starting notify loop for Temp2, first event tmpint: 17
2016.04.15 18:02:29 5: Notify from Device: Temp2 recieved
2016.04.15 18:02:29 5: DbLog: logging of Device: Temp2 , Type: GPIO4 , Event: tmpint: 17 , Reading: tmpint , Value: 17 , Unit:
2016.04.15 18:03:29 5: pin16, in fileaccess: edge
2016.04.15 18:03:29 5: Triggering pin16 (1 changes)
2016.04.15 18:03:29 5: Starting notify loop for pin16, first event Dblclick: off
2016.04.15 18:03:29 5: Notify from Device: pin16 recieved
2016.04.15 18:03:29 5: Triggering pin16 (3 changes)
2016.04.15 18:03:29 5: Starting notify loop for pin16, first event Pinlevel: low
2016.04.15 18:03:29 5: Notify from Device: pin16 recieved
2016.04.15 18:03:30 5: Triggering Temp2 (1 changes)
2016.04.15 18:03:30 5: Starting notify loop for Temp2, first event tmpint: 17
2016.04.15 18:03:30 5: Notify from Device: Temp2 recieved
2016.04.15 18:03:30 5: DbLog: logging of Device: Temp2 , Type: GPIO4 , Event: tmpint: 17 , Reading: tmpint , Value: 17 , Unit:
2016.04.15 18:03:30 5: pin16, in fileaccess: edge
2016.04.15 18:03:30 5: Triggering pin16 (2 changes)
2016.04.15 18:03:30 5: Starting notify loop for pin16, first event Pinlevel: high
2016.04.15 18:03:30 5: Notify from Device: pin16 recieved
2016.04.15 18:03:32 5: pin18, in fileaccess: edge
2016.04.15 18:03:32 5: Triggering pin18 (2 changes)
2016.04.15 18:03:32 5: Starting notify loop for pin18, first event Pinlevel: high
2016.04.15 18:03:32 5: Notify from Device: pin18 recieved
2016.04.15 18:03:32 5: pin16, in fileaccess: value
2016.04.15 18:03:32 5: Triggering pin16 (1 changes)
2016.04.15 18:03:32 5: Starting notify loop for pin16, first event Longpress: on
2016.04.15 18:03:32 5: Notify from Device: pin16 recieved
2016.04.15 18:03:33 5: pin18, in fileaccess: value
2016.04.15 18:03:33 5: Triggering pin18 (1 changes)
2016.04.15 18:03:33 5: Starting notify loop for pin18, first event Longpress: on
2016.04.15 18:03:33 5: Notify from Device: pin18 recieve
shutdown restart
root@raspia:/opt/fhem# ls -l /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 Apr 15 18:05 export
lrwxrwxrwx 1 root gpio 0 Apr 14 23:12 gpio10 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Apr 14 23:12 gpio11 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio11
lrwxrwxrwx 1 root gpio 0 Apr 14 23:12 gpio17 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Apr 14 23:12 gpio18 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio18
lrwxrwxrwx 1 root gpio 0 Apr 14 23:12 gpio22 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio22
lrwxrwxrwx 1 root gpio 0 Apr 15 18:05 gpio23 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Apr 15 18:05 gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Apr 14 23:12 gpio27 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Apr 14 23:12 gpio9 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio9
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Apr 15 18:05 unexport
root@raspia:/opt/fhem# ls -l /sys/class/gpio/gpio23/
total 0
-rw-r--r-- 1 root root 4096 Apr 15 18:09 active_low
lrwxrwxrwx 1 root root 0 Apr 15 18:09 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Apr 15 18:05 direction
-rw-r--r-- 1 root root 4096 Apr 15 18:05 edge
lrwxrwxrwx 1 root root 0 Apr 15 18:05 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Apr 15 18:05 uevent
-rw-r--r-- 1 root root 4096 Apr 15 18:05 value
Internals:
DEF 23
EXCEPT_FD 17
GPIO_Basedir /sys/class/gpio
NAME pin16
NR 67
RPI_pin 23
STATE on
TYPE RPI_GPIO
WiringPi_gpio
Readings:
2016-01-03 01:51:06 Counter 25
2016-04-15 18:03:29 Dblclick off
2016-04-15 18:03:32 Longpress on
2016-04-15 18:03:30 Pinlevel high
2016-04-15 18:03:30 state on
Fhem:
interfaces switch
Attributes:
direction input
interrupt both
verbose 5
und hier noch das komplette log eines shutdown restart
root@raspia:/opt/fhem# tail -f log/fhem-2016-04.log
2016.04.15 18:03:32 5: Starting notify loop for pin16, first event Longpress: on
2016.04.15 18:03:32 5: Notify from Device: pin16 recieved
2016.04.15 18:03:33 5: pin18, in fileaccess: value
2016.04.15 18:03:33 5: Triggering pin18 (1 changes)
2016.04.15 18:03:33 5: Starting notify loop for pin18, first event Longpress: on
2016.04.15 18:03:33 5: Notify from Device: pin18 recieved
2016.04.15 18:04:31 5: Triggering Temp2 (1 changes)
2016.04.15 18:04:31 5: Starting notify loop for Temp2, first event tmpint: 17
2016.04.15 18:04:31 5: Notify from Device: Temp2 recieved
2016.04.15 18:04:31 5: DbLog: logging of Device: Temp2 , Type: GPIO4 , Event: tmpint: 17 , Reading: tmpint , Value: 17 , Unit:
2016.04.15 18:05:27 4: Connection accepted from WEB_172.22.22.21_40462
2016.04.15 18:05:27 4: WEB_172.22.22.21_40462 POST /fhem?XHR=1&cmd=shutdown%20restart&fw_id=83; BUFLEN:0
2016.04.15 18:05:27 5: Cmd: >shutdown restart<
2016.04.15 18:05:27 5: Triggering global (1 changes)
2016.04.15 18:05:27 5: Starting notify loop for global, first event SHUTDOWN
2016.04.15 18:05:27 5: Notify from Device: global recieved
2016.04.15 18:05:27 0: Server shutdown
2016.04.15 18:05:27 5: pin16: interrupt detached
2016.04.15 18:05:27 5: pin16: gpio23 removed
2016.04.15 18:05:27 5: pin18: interrupt detached
2016.04.15 18:05:27 5: pin18: gpio24 removed
2016.04.15 18:05:31 5: Initializing Type Library:
2016.04.15 18:05:31 1: Including fhem.cfg
2016.04.15 18:05:31 5: Cmd: >attr global userattr DbLogExclude DbLogInclude cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride<
2016.04.15 18:05:31 5: Cmd: >attr global autoload_undefined_devices 1<
2016.04.15 18:05:31 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2016.04.15 18:05:32 5: Cmd: >attr global modpath .<
2016.04.15 18:05:32 5: Cmd: >attr global motd SecurityCheck:
WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth.
telnetPort has no associated allowed device with password/globalpassword.
Restart FHEM for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.
<
2016.04.15 18:05:32 5: Cmd: >attr global statefile ./log/fhem.save<
2016.04.15 18:05:32 5: Cmd: >attr global updateInBackground 1<
2016.04.15 18:05:32 5: Cmd: >attr global verbose 5<
2016.04.15 18:05:32 5: Cmd: >define telnetPort telnet 7072 global<
2016.04.15 18:05:32 5: Loading ./FHEM/98_telnet.pm
2016.04.15 18:05:32 3: telnetPort: port 7072 opened
2016.04.15 18:05:32 5: Cmd: >define WEB FHEMWEB 8083 global<
2016.04.15 18:05:32 5: Loading ./FHEM/01_FHEMWEB.pm
2016.04.15 18:05:33 3: WEB: port 8083 opened
2016.04.15 18:05:33 5: Cmd: >define WEBphone FHEMWEB 8084 global<
2016.04.15 18:05:33 3: WEBphone: port 8084 opened
2016.04.15 18:05:33 5: Cmd: >attr WEBphone stylesheetPrefix smallscreen<
2016.04.15 18:05:33 5: Cmd: >define WEBtablet FHEMWEB 8085 global<
2016.04.15 18:05:33 3: WEBtablet: port 8085 opened
2016.04.15 18:05:33 5: Cmd: >attr WEBtablet stylesheetPrefix touchpad<
2016.04.15 18:05:33 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m.log fakelog<
2016.04.15 18:05:33 5: Loading ./FHEM/92_FileLog.pm
2016.04.15 18:05:33 5: Cmd: >define autocreate autocreate<
2016.04.15 18:05:33 5: Loading ./FHEM/98_autocreate.pm
2016.04.15 18:05:33 5: Cmd: >attr autocreate filelog ./log/%NAME-%Y.log<
2016.04.15 18:05:33 5: Cmd: >define eventTypes eventTypes ./log/eventTypes.txt<
2016.04.15 18:05:33 5: Loading ./FHEM/91_eventTypes.pm
2016.04.15 18:05:33 2: eventTypes: loaded 68 events from ./log/eventTypes.txt
2016.04.15 18:05:33 5: Cmd: >define initialUsbCheck notify global:INITIALIZED usb create<
2016.04.15 18:05:33 5: Loading ./FHEM/91_notify.pm
2016.04.15 18:05:33 5: Cmd: >define Temp2 GPIO4 28-00000656f9a8<
2016.04.15 18:05:33 5: Loading ./FHEM/58_GPIO4.pm
2016.04.15 18:05:33 4: GPIO4: GPIO4_Define(Temp2)
2016.04.15 18:05:34 5: Cmd: >attr Temp2 DbLogExclude failures,T,85<
2016.04.15 18:05:34 5: Cmd: >attr Temp2 event-min-interval tmpint:30<
2016.04.15 18:05:34 5: Cmd: >attr Temp2 event-on-change-reading tmpint<
2016.04.15 18:05:34 5: Cmd: >attr Temp2 model DS18B20<
2016.04.15 18:05:34 5: Cmd: >attr Temp2 room GPIO4<
2016.04.15 18:05:34 5: Cmd: >attr Temp2 userReadings tmpint {int ReadingsVal("Temp2","temperature",0)}<
2016.04.15 18:05:34 5: Cmd: >define FileLog_Temp2 FileLog ./log/Temp2-%Y.log Temp2<
2016.04.15 18:05:34 5: Cmd: >attr FileLog_Temp2 logtype text<
2016.04.15 18:05:34 5: Cmd: >attr FileLog_Temp2 room GPIO4<
2016.04.15 18:05:34 5: Cmd: >define Temp3 GPIO4 28-000006573235<
2016.04.15 18:05:34 4: GPIO4: GPIO4_Define(Temp3)
2016.04.15 18:05:36 5: Cmd: >attr Temp3 DbLogExclude failures,T,85<
2016.04.15 18:05:36 5: Cmd: >attr Temp3 event-min-interval tmpint:900<
2016.04.15 18:05:36 5: Cmd: >attr Temp3 event-on-change-reading tmpint<
2016.04.15 18:05:36 5: Cmd: >attr Temp3 model DS18B20<
2016.04.15 18:05:36 5: Cmd: >attr Temp3 room GPIO4<
2016.04.15 18:05:36 5: Cmd: >attr Temp3 userReadings tmpint {int ReadingsVal("Temp3","temperature",0)}<
2016.04.15 18:05:36 5: Cmd: >define FileLog_Temp3 FileLog ./log/Temp3-%Y.log Temp3<
2016.04.15 18:05:36 5: Cmd: >attr FileLog_Temp3 logtype text<
2016.04.15 18:05:36 5: Cmd: >attr FileLog_Temp3 room GPIO4<
2016.04.15 18:05:36 5: Cmd: >define Temp4 GPIO4 28-0000065cefd7<
2016.04.15 18:05:36 4: GPIO4: GPIO4_Define(Temp4)
2016.04.15 18:05:37 5: Cmd: >attr Temp4 DbLogExclude failures,T,85<
2016.04.15 18:05:37 5: Cmd: >attr Temp4 event-min-interval tmpint:900<
2016.04.15 18:05:37 5: Cmd: >attr Temp4 event-on-change-reading tmpint<
2016.04.15 18:05:37 5: Cmd: >attr Temp4 model DS18B20<
2016.04.15 18:05:37 5: Cmd: >attr Temp4 room GPIO4<
2016.04.15 18:05:37 5: Cmd: >attr Temp4 userReadings tmpint {int ReadingsVal("Temp4","temperature",0)}<
2016.04.15 18:05:37 5: Cmd: >define FileLog_Temp4 FileLog ./log/Temp4-%Y.log Temp4<
2016.04.15 18:05:37 5: Cmd: >attr FileLog_Temp4 logtype text<
2016.04.15 18:05:37 5: Cmd: >attr FileLog_Temp4 room GPIO4<
2016.04.15 18:05:37 5: Cmd: >define Temp1 GPIO4 28-00000655aa4f<
2016.04.15 18:05:37 4: GPIO4: GPIO4_Define(Temp1)
2016.04.15 18:05:38 5: Cmd: >attr Temp1 DbLogExclude failures,T,85<
2016.04.15 18:05:38 5: Cmd: >attr Temp1 event-min-interval tmpint:900<
2016.04.15 18:05:38 5: Cmd: >attr Temp1 event-on-change-reading tmpint<
2016.04.15 18:05:38 5: Cmd: >attr Temp1 model DS18B20<
2016.04.15 18:05:38 5: Cmd: >attr Temp1 room GPIO4<
2016.04.15 18:05:38 5: Cmd: >attr Temp1 userReadings tmpint {int ReadingsVal("Temp1","temperature",0)}<
2016.04.15 18:05:38 5: Cmd: >define FileLog_Temp1 FileLog ./log/Temp1-%Y.log Temp1<
2016.04.15 18:05:38 5: Cmd: >attr FileLog_Temp1 logtype text<
2016.04.15 18:05:38 5: Cmd: >attr FileLog_Temp1 room GPIO4<
2016.04.15 18:05:38 5: Cmd: >define logdb DbLog ./db.conf .*:tmpint.*<
2016.04.15 18:05:38 5: Loading ./FHEM/93_DbLog.pm
2016.04.15 18:05:39 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2016.04.15 18:05:39 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 2472
2016.04.15 18:05:39 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established
2016.04.15 18:05:39 5: Cmd: >define RPi GPIO4 BUSMASTER<
2016.04.15 18:05:39 4: GPIO4: GPIO4_Define(RPi)
2016.04.15 18:05:39 5: Cmd: >define pin19 RPI_GPIO 10<
2016.04.15 18:05:39 5: Loading ./FHEM/51_RPI_GPIO.pm
2016.04.15 18:05:39 4: RPI_GPIO: gpio directory exists: /sys/class/gpio
2016.04.15 18:05:39 4: pin19: gpio10 already exists
2016.04.15 18:05:39 5: Cmd: >attr pin19 direction output<
2016.04.15 18:05:39 5: pin19: set attr direction: output vorerst NICHT
2016.04.15 18:05:39 5: Cmd: >attr pin19 verbose 5<
2016.04.15 18:05:39 5: Cmd: >define pin21 RPI_GPIO 9<
2016.04.15 18:05:39 4: pin21: gpio9 already exists
2016.04.15 18:05:39 5: Cmd: >attr pin21 direction output<
2016.04.15 18:05:39 5: pin21: set attr direction: output vorerst NICHT
2016.04.15 18:05:39 5: Cmd: >attr pin21 verbose 5<
2016.04.15 18:05:39 5: Cmd: >define pin23 RPI_GPIO 11<
2016.04.15 18:05:39 4: pin23: gpio11 already exists
2016.04.15 18:05:39 5: Cmd: >attr pin23 direction output<
2016.04.15 18:05:39 5: pin23: set attr direction: output vorerst NICHT
2016.04.15 18:05:39 5: Cmd: >attr pin23 verbose 5<
2016.04.15 18:05:39 5: Cmd: >define pin11 RPI_GPIO 17<
2016.04.15 18:05:39 4: pin11: gpio17 already exists
2016.04.15 18:05:39 5: Cmd: >attr pin11 direction output<
2016.04.15 18:05:39 5: pin11: set attr direction: output vorerst NICHT
2016.04.15 18:05:39 5: Cmd: >attr pin11 verbose 5<
2016.04.15 18:05:39 5: Cmd: >define pin13 RPI_GPIO 27<
2016.04.15 18:05:39 4: pin13: gpio27 already exists
2016.04.15 18:05:39 5: Cmd: >attr pin13 direction output<
2016.04.15 18:05:39 5: pin13: set attr direction: output vorerst NICHT
2016.04.15 18:05:39 5: Cmd: >attr pin13 verbose 5<
2016.04.15 18:05:39 5: Cmd: >define pin15 RPI_GPIO 22<
2016.04.15 18:05:39 4: pin15: gpio22 already exists
2016.04.15 18:05:39 5: Cmd: >attr pin15 direction output<
2016.04.15 18:05:39 5: pin15: set attr direction: output vorerst NICHT
2016.04.15 18:05:39 5: Cmd: >attr pin15 verbose 5<
2016.04.15 18:05:39 5: Cmd: >define pin12 RPI_GPIO 18<
2016.04.15 18:05:39 4: pin12: gpio18 already exists
2016.04.15 18:05:39 5: Cmd: >attr pin12 direction output<
2016.04.15 18:05:39 5: pin12: set attr direction: output vorerst NICHT
2016.04.15 18:05:39 5: Cmd: >attr pin12 verbose 5<
2016.04.15 18:05:39 5: Cmd: >define pin16 RPI_GPIO 23<
2016.04.15 18:05:39 4: pin16: write access to file /sys/class/gpio/export, use it to export GPIO
2016.04.15 18:05:44 4: pin16: using gpio utility to export pin (first export via /sys/class/gpio/export failed)
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 130.
2016.04.15 18:05:44 5: Cmd: >attr pin16 direction input<
2016.04.15 18:05:44 5: pin16, in fileaccess: direction in
2016.04.15 18:05:44 4: pin16: direction ueber gpio utility einstellen
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 131.
2016.04.15 18:05:44 5: pin16: set attr direction: input
2016.04.15 18:05:44 5: Cmd: >attr pin16 interrupt both<
2016.04.15 18:05:44 5: pin16, in fileaccess: edge both
2016.04.15 18:05:44 1: Can't open file: pin16, edge
2016.04.15 18:05:44 5: Datei: /sys/class/gpio/gpio23/value, FH: IO::File=GLOB(0xa11f50), EXCEPT_FD: 17, akt. Wert: 1
2016.04.15 18:05:44 5: pin16: set attr interrupt: both
2016.04.15 18:05:44 5: Cmd: >attr pin16 verbose 5<
2016.04.15 18:05:44 5: Cmd: >define pin18 RPI_GPIO 24<
2016.04.15 18:05:44 4: pin18: write access to file /sys/class/gpio/export, use it to export GPIO
2016.04.15 18:05:49 4: pin18: using gpio utility to export pin (first export via /sys/class/gpio/export failed)
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 136.
2016.04.15 18:05:49 5: Cmd: >attr pin18 direction input<
2016.04.15 18:05:49 5: pin18, in fileaccess: direction in
2016.04.15 18:05:49 4: pin18: direction ueber gpio utility einstellen
Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 640, <$fh> line 137.
2016.04.15 18:05:49 5: pin18: set attr direction: input
2016.04.15 18:05:49 5: Cmd: >attr pin18 interrupt both<
2016.04.15 18:05:49 5: pin18, in fileaccess: edge both
2016.04.15 18:05:49 1: Can't open file: pin18, edge
2016.04.15 18:05:49 5: Datei: /sys/class/gpio/gpio24/value, FH: IO::File=GLOB(0xa98968), EXCEPT_FD: 18, akt. Wert: 1
2016.04.15 18:05:49 5: pin18: set attr interrupt: both
2016.04.15 18:05:49 1: Including ./log/fhem.save
2016.04.15 18:05:49 5: Cmd: >setstate FileLog_Temp1 active<
2016.04.15 18:05:49 5: Cmd: >setstate FileLog_Temp2 active<
2016.04.15 18:05:49 5: Cmd: >setstate FileLog_Temp3 active<
2016.04.15 18:05:49 5: Cmd: >setstate FileLog_Temp4 active<
2016.04.15 18:05:49 5: Cmd: >setstate Logfile active<
2016.04.15 18:05:49 5: Cmd: >setstate RPi 2016-04-14 21:14:11 failures 7<
2016.04.15 18:05:49 5: Cmd: >setstate Temp1 T: 17.687<
2016.04.15 18:05:49 5: Cmd: >setstate Temp1 2016-04-14 23:12:53 failures 0<
2016.04.15 18:05:49 5: Cmd: >setstate Temp1 2016-04-15 18:04:33 state T: 17.687<
2016.04.15 18:05:49 5: Cmd: >setstate Temp1 2016-04-15 18:04:33 temperature 17.687<
2016.04.15 18:05:49 5: Cmd: >setstate Temp1 2016-04-15 18:04:33 tmpint 17<
2016.04.15 18:05:49 5: Cmd: >setstate Temp2 T: 17.562<
2016.04.15 18:05:49 5: Cmd: >setstate Temp2 2016-04-14 23:12:50 failures 0<
2016.04.15 18:05:49 5: Cmd: >setstate Temp2 2016-04-15 18:04:31 state T: 17.562<
2016.04.15 18:05:49 5: Cmd: >setstate Temp2 2016-04-15 18:04:31 temperature 17.562<
2016.04.15 18:05:49 5: Cmd: >setstate Temp2 2016-04-15 18:04:31 tmpint 17<
2016.04.15 18:05:49 5: Cmd: >setstate Temp3 T: 17.562<
2016.04.15 18:05:49 5: Cmd: >setstate Temp3 2016-04-14 23:12:51 failures 0<
2016.04.15 18:05:49 5: Cmd: >setstate Temp3 2016-04-15 18:04:32 state T: 17.562<
2016.04.15 18:05:49 5: Cmd: >setstate Temp3 2016-04-15 18:04:32 temperature 17.562<
2016.04.15 18:05:50 5: Cmd: >setstate Temp3 2016-04-15 18:04:32 tmpint 17<
2016.04.15 18:05:50 5: Cmd: >setstate Temp4 T: 17.812<
2016.04.15 18:05:50 5: Cmd: >setstate Temp4 2016-04-14 23:12:52 failures 0<
2016.04.15 18:05:50 5: Cmd: >setstate Temp4 2016-04-15 18:04:32 state T: 17.812<
2016.04.15 18:05:50 5: Cmd: >setstate Temp4 2016-04-15 18:04:32 temperature 17.812<
2016.04.15 18:05:50 5: Cmd: >setstate Temp4 2016-04-15 18:04:32 tmpint 17<
2016.04.15 18:05:50 5: Cmd: >setstate autocreate active<
2016.04.15 18:05:50 5: Cmd: >setstate eventTypes active<
2016.04.15 18:05:50 5: Cmd: >setstate global <no definition><
2016.04.15 18:05:50 5: Cmd: >setstate initialUsbCheck 2016-04-15 17:58:17<
2016.04.15 18:05:50 5: Cmd: >setstate initialUsbCheck 2016-04-14 23:12:50 state active<
2016.04.15 18:05:50 5: Cmd: >setstate logdb connected<
2016.04.15 18:05:50 5: Cmd: >setstate logdb 2016-04-15 17:58:16 state connected<
2016.04.15 18:05:50 5: Cmd: >setstate pin11 off<
2016.04.15 18:05:50 4: pin11: STATE kann auf off wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin11 2016-04-15 17:58:17 state off<
2016.04.15 18:05:50 4: pin11: state kann auf off wiederhergestellt werden 2016-04-15 17:58:17
2016.04.15 18:05:50 4: OUTPUT pin11: state wiederhergestellt auf off
2016.04.15 18:05:50 5: pin11, in fileaccess: value 0
2016.04.15 18:05:50 5: pin11, in fileaccess: direction low
2016.04.15 18:05:50 4: pin11: direction gesetzt auf low
2016.04.15 18:05:50 4: OUTPUT pin11: STATE wiederhergestellt auf off (restoreOnStartup=last)
2016.04.15 18:05:50 5: Cmd: >setstate pin12 off<
2016.04.15 18:05:50 4: pin12: STATE kann auf off wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin12 2016-04-15 17:58:17 state off<
2016.04.15 18:05:50 4: pin12: state kann auf off wiederhergestellt werden 2016-04-15 17:58:17
2016.04.15 18:05:50 4: OUTPUT pin12: state wiederhergestellt auf off
2016.04.15 18:05:50 5: pin12, in fileaccess: value 0
2016.04.15 18:05:50 5: pin12, in fileaccess: direction low
2016.04.15 18:05:50 4: pin12: direction gesetzt auf low
2016.04.15 18:05:50 4: OUTPUT pin12: STATE wiederhergestellt auf off (restoreOnStartup=last)
2016.04.15 18:05:50 5: Cmd: >setstate pin13 off<
2016.04.15 18:05:50 4: pin13: STATE kann auf off wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin13 2016-04-15 17:58:17 state off<
2016.04.15 18:05:50 4: pin13: state kann auf off wiederhergestellt werden 2016-04-15 17:58:17
2016.04.15 18:05:50 4: OUTPUT pin13: state wiederhergestellt auf off
2016.04.15 18:05:50 5: pin13, in fileaccess: value 0
2016.04.15 18:05:50 5: pin13, in fileaccess: direction low
2016.04.15 18:05:50 4: pin13: direction gesetzt auf low
2016.04.15 18:05:50 4: OUTPUT pin13: STATE wiederhergestellt auf off (restoreOnStartup=last)
2016.04.15 18:05:50 5: Cmd: >setstate pin15 off<
2016.04.15 18:05:50 4: pin15: STATE kann auf off wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin15 2016-04-15 17:58:17 state off<
2016.04.15 18:05:50 4: pin15: state kann auf off wiederhergestellt werden 2016-04-15 17:58:17
2016.04.15 18:05:50 4: OUTPUT pin15: state wiederhergestellt auf off
2016.04.15 18:05:50 5: pin15, in fileaccess: value 0
2016.04.15 18:05:50 5: pin15, in fileaccess: direction low
2016.04.15 18:05:50 4: pin15: direction gesetzt auf low
2016.04.15 18:05:50 4: OUTPUT pin15: STATE wiederhergestellt auf off (restoreOnStartup=last)
2016.04.15 18:05:50 5: Cmd: >setstate pin16 on<
2016.04.15 18:05:50 4: pin16: STATE kann auf on wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin16 2016-01-03 01:51:06 Counter 25<
2016.04.15 18:05:50 4: pin16: Counter kann auf 25 wiederhergestellt werden 2016-01-03 01:51:06
2016.04.15 18:05:50 4: INPUT pin16: Counter wiederhergestellt auf 25
2016.04.15 18:05:50 5: Cmd: >setstate pin16 2016-04-15 18:03:29 Dblclick off<
2016.04.15 18:05:50 4: pin16: Dblclick kann auf off wiederhergestellt werden 2016-04-15 18:03:29
2016.04.15 18:05:50 5: Cmd: >setstate pin16 2016-04-15 18:03:32 Longpress on<
2016.04.15 18:05:50 4: pin16: Longpress kann auf on wiederhergestellt werden 2016-04-15 18:03:32
2016.04.15 18:05:50 5: Cmd: >setstate pin16 2016-04-15 18:03:30 Pinlevel high<
2016.04.15 18:05:50 4: pin16: Pinlevel kann auf high wiederhergestellt werden 2016-04-15 18:03:30
2016.04.15 18:05:50 5: Cmd: >setstate pin16 2016-04-15 18:03:30 state on<
2016.04.15 18:05:50 4: pin16: state kann auf on wiederhergestellt werden 2016-04-15 18:03:30
2016.04.15 18:05:50 4: INPUT pin16: alter Pinwert war: on
2016.04.15 18:05:50 5: pin16, in fileaccess: value
2016.04.15 18:05:50 4: INPUT pin16: aktueller Pinwert ist: on
2016.04.15 18:05:50 5: Cmd: >setstate pin18 on<
2016.04.15 18:05:50 4: pin18: STATE kann auf on wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin18 2016-01-03 02:04:28 Counter 13<
2016.04.15 18:05:50 4: pin18: Counter kann auf 13 wiederhergestellt werden 2016-01-03 02:04:28
2016.04.15 18:05:50 4: INPUT pin18: Counter wiederhergestellt auf 13
2016.04.15 18:05:50 5: Cmd: >setstate pin18 2016-04-15 18:01:51 Dblclick off<
2016.04.15 18:05:50 4: pin18: Dblclick kann auf off wiederhergestellt werden 2016-04-15 18:01:51
2016.04.15 18:05:50 5: Cmd: >setstate pin18 2016-04-15 18:03:33 Longpress on<
2016.04.15 18:05:50 4: pin18: Longpress kann auf on wiederhergestellt werden 2016-04-15 18:03:33
2016.04.15 18:05:50 5: Cmd: >setstate pin18 2016-04-15 18:03:32 Pinlevel high<
2016.04.15 18:05:50 4: pin18: Pinlevel kann auf high wiederhergestellt werden 2016-04-15 18:03:32
2016.04.15 18:05:50 5: Cmd: >setstate pin18 2016-04-15 18:03:32 state on<
2016.04.15 18:05:50 4: pin18: state kann auf on wiederhergestellt werden 2016-04-15 18:03:32
2016.04.15 18:05:50 4: INPUT pin18: alter Pinwert war: on
2016.04.15 18:05:50 5: pin18, in fileaccess: value
2016.04.15 18:05:50 4: INPUT pin18: aktueller Pinwert ist: on
2016.04.15 18:05:50 5: Cmd: >setstate pin19 off<
2016.04.15 18:05:50 4: pin19: STATE kann auf off wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin19 2016-04-14 20:23:28 Pinlevel low<
2016.04.15 18:05:50 4: pin19: Pinlevel kann auf low wiederhergestellt werden 2016-04-14 20:23:28
2016.04.15 18:05:50 4: OUTPUT pin19: Pinlevel wiederhergestellt auf low
2016.04.15 18:05:50 5: Cmd: >setstate pin19 2016-04-15 17:58:17 state off<
2016.04.15 18:05:50 4: pin19: state kann auf off wiederhergestellt werden 2016-04-15 17:58:17
2016.04.15 18:05:50 4: OUTPUT pin19: state wiederhergestellt auf off
2016.04.15 18:05:50 5: pin19, in fileaccess: value 0
2016.04.15 18:05:50 5: pin19, in fileaccess: direction low
2016.04.15 18:05:50 4: pin19: direction gesetzt auf low
2016.04.15 18:05:50 4: OUTPUT pin19: STATE wiederhergestellt auf off (restoreOnStartup=last)
2016.04.15 18:05:50 5: Cmd: >setstate pin21 off<
2016.04.15 18:05:50 4: pin21: STATE kann auf off wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin21 2016-04-15 17:58:17 state off<
2016.04.15 18:05:50 4: pin21: state kann auf off wiederhergestellt werden 2016-04-15 17:58:17
2016.04.15 18:05:50 4: OUTPUT pin21: state wiederhergestellt auf off
2016.04.15 18:05:50 5: pin21, in fileaccess: value 0
2016.04.15 18:05:50 5: pin21, in fileaccess: direction low
2016.04.15 18:05:50 4: pin21: direction gesetzt auf low
2016.04.15 18:05:50 4: OUTPUT pin21: STATE wiederhergestellt auf off (restoreOnStartup=last)
2016.04.15 18:05:50 5: Cmd: >setstate pin23 off<
2016.04.15 18:05:50 4: pin23: STATE kann auf off wiederhergestellt werden 2016-04-15 18:05:50
2016.04.15 18:05:50 5: Cmd: >setstate pin23 2016-04-15 17:58:17 state off<
2016.04.15 18:05:50 4: pin23: state kann auf off wiederhergestellt werden 2016-04-15 17:58:17
2016.04.15 18:05:50 4: OUTPUT pin23: state wiederhergestellt auf off
2016.04.15 18:05:50 5: pin23, in fileaccess: value 0
2016.04.15 18:05:50 5: pin23, in fileaccess: direction low
2016.04.15 18:05:50 4: pin23: direction gesetzt auf low
2016.04.15 18:05:50 4: OUTPUT pin23: STATE wiederhergestellt auf off (restoreOnStartup=last)
2016.04.15 18:05:50 5: Triggering global (1 changes)
2016.04.15 18:05:50 5: Starting notify loop for global, first event INITIALIZED
2016.04.15 18:05:50 4: GPIO4: GPIO4_GetSlaves()
2016.04.15 18:05:50 4: GPIO4: GPIO4_GetSlave(28-00000656f9a8)
2016.04.15 18:05:50 4: GPIO4: GPIO4_GetSlave(28-000006573235)
2016.04.15 18:05:50 4: GPIO4: GPIO4_GetSlave(28-0000065cefd7)
2016.04.15 18:05:50 4: GPIO4: GPIO4_GetSlave(28-00000655aa4f)
2016.04.15 18:05:50 5: Triggering initialUsbCheck
2016.04.15 18:05:50 4: initialUsbCheck exec usb create
2016.04.15 18:05:50 5: Cmd: >usb create<
2016.04.15 18:05:50 1: usb create starting
2016.04.15 18:05:52 4: ### ttyAMA0: checking if it is a CUL
2016.04.15 18:05:52 3: Probing CUL device /dev/ttyAMA0
2016.04.15 18:05:52 5: SW: 0a
2016.04.15 18:05:52 5: SW: 560a
2016.04.15 18:05:52 4: got wrong answer for a CUL
2016.04.15 18:05:52 4: ### ttyAMA0: checking if it is a TCM_ESP3
2016.04.15 18:05:52 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.04.15 18:05:52 5: SW: 5500010005700838
2016.04.15 18:05:52 4: got wrong answer for a TCM_ESP3
2016.04.15 18:05:52 4: ### ttyAMA0: checking if it is a FRM
2016.04.15 18:05:52 3: Probing FRM device /dev/ttyAMA0
2016.04.15 18:05:52 5: SW: f9
2016.04.15 18:05:58 5: SW: f079f7
2016.04.15 18:05:58 4: got wrong answer for a FRM
2016.04.15 18:05:58 1: usb create end
2016.04.15 18:05:58 5: Notify from Device: global recieved
2016.04.15 18:05:58 2: SecurityCheck: WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.15 18:05:58 0: Featurelevel: 5.7
2016.04.15 18:05:58 0: Server started with 28 defined entities (fhem.pl:11237/2016-04-13 perl:5.014002 os:linux user:fhem pid:2472)
2016.04.15 18:05:58 4: Connection accepted from WEB_172.22.22.21_40465
2016.04.15 18:05:58 4: Connection accepted from telnetPort_172.22.22.9_45467
2016.04.15 18:05:58 5: Cmd: >admin<
2016.04.15 18:05:58 5: Cmd: >inform on .*<
2016.04.15 18:05:58 4: Setting inform to on .*
2016.04.15 18:05:59 4: WEB_172.22.22.21_40465 GET /fhem?XHR=1&inform=type=status;filter=;since=1460736135.1460001;fmt=JSON&fw_id=83×tamp=1460736337755; BUFLEN:0
tasten druck
nichts
edit:
Das attribut unexport habe ich nachher auch gesetzt und nochmal probiert. Damit tritt das Problem nicht mehr auf.
Danke, jetzt erinnere ich mich auch wieder...
beim Shutdown/Restart werden die Output GPIOs generell nicht mehr per unexport gelöscht.
Bei den Inputs aber schon, da Probleme mit dem Interrupt gemeldet wurden, wenn die Pins bestehen bleiben.
...wie auch immer, wenns jetzt läuft ist gut 8)
Hallo zusammen,
ich habe auch Probleme mit den Rechten der GPIOs.
Und zwar habe ich mir ein neues System mit einem Minibian Jessie aufgesetzt und wiringpi installiert.
FHEM habe ich übers Debian Repository installiert.
User fhem ist angelegt und gehört zur Gruppe gpio.
Ich kann GPIOs exportieren und die Rechte ändern. Dies hält aber nur bis zu einem Reboot.
Außerdem bekomme ich beim Anlegen eines GPIO in FHEM immer folgende Fehlermeldung:
second attempt to export gpio17 failed: file /usr/local/bin/gpio doesnt exist
Habe schon ziemlich viel gelesen, aber noch keine Plan woran es liegt.
root@minibian:/sys/class/gpio# ls -l
total 0
--w------- 1 root root 4096 Apr 22 21:08 export
lrwxrwxrwx 1 root root 0 Apr 22 21:09 gpio17 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root root 0 Apr 22 21:00 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
--w------- 1 root root 4096 Apr 22 21:00 unexport
Du hast nicht gesagt ob die GPIO grundsätzlich gehen oder nicht ?
Hast du nach der Installation von FHEM ein "update" gemacht?
Habe selber kein Jessie, aber warum macht du nicht ein init script das die Rechte nach jedem Reboot so setzt wie du es willst ? Das habe ich bei mir so mit Wheezy (siehe oben), wiringpi habe/brauche ich auch nicht.
Ob die GPIOs unter Jessie grundsätzlich funktionieren, habe ich ehrlich gesagt nicht ausprobiert.
Unter Wheezy haben sie aber funktioniert. Da hatte ich Schalter und DS18B20 dran.
Ich könnte auch einfach mein Backup zurückspielen aber mich interessiert auch was da mit den Berechtigungen passiert.
So ein Startskript kann doch nicht die optimale Lösung sein. Unter Wheezy ging es ja auch ohne.
Ja, ein Update habe ich vor der Installation von FHEM gemacht.
WirinPi brauchst du nicht? Ich dachte immer das seit nötig um mit FHEM auf die GPIOs zugreifen zu können.
Habe ich da wohl etwas falsch verstanden?
Hm, ich hatte gefragt ob du ein "update" NACH der Installation von FHEM gemacht hast, ich meine ein FHEM update. Die letzte Vers. von RPI_GPIO ist vom 2016-03-23 und ohne update hast du möglicherweise ein veraltetes Modul, vielleicht gibts deswegen die Fehlermeldung wenn du einen GPIO anlegst?
Nein, WiringPi hab ich nicht installiert und alles geht wie ich will, Eingänge und Ausgänge und Temperaturmessung. Sowohl von Kommandozeile als auch mit FHEM. Ich habe allerdings ein init script installiert das die GPIO konfiguriert und die Rechte setzt.
Es gibt wohl mehrere Möglichkeiten wie man das alles zum laufen bringen kann, ich habe halt diese gewählt.
Zitat von: knxhm am 24 April 2016, 16:54:08
Hm, ich hatte gefragt ob du ein "update" NACH der Installation von FHEM gemacht hast,....
Sorry, das hatte ich falsch verstanden. Bin auch davon ausgegangen, dass FHEM aktuell wäre, wenn ich es über das Repository installiere.
Besten Dank jedenfalls für den Hinweis.
Habe nun ein Update gemacht, wiringpi deinstalliert und die Rechte des GPIOs auf 777 gesetzt und siehe da, es funktioniert.
Was mich allerdings berennend interessiert, warum die GPIOs beim reboot immer unexported werden.
Das muss man doch abstellen können.
Zitat von: r_knipp am 24 April 2016, 21:30:03
Sorry, das hatte ich falsch verstanden. Bin auch davon ausgegangen, dass FHEM aktuell wäre, wenn ich es über das Repository installiere.
Besten Dank jedenfalls für den Hinweis.
Nein, bei der Installation wird immer der letzte Milestone (im mom 5.7) installiert. Ein update von FHEM ist daher nach der Neuinstallation eine gute Idee.
Zitat von: r_knipp am 24 April 2016, 21:30:03
Habe nun ein Update gemacht, wiringpi deinstalliert und die Rechte des GPIOs auf 777 gesetzt und siehe da, es funktioniert.
Was mich allerdings berennend interessiert, warum die GPIOs beim reboot immer unexported werden.
Das muss man doch abstellen können.
Wiringpi ist seit Jessie von Haus aus bei raspbian mit dabei. Allerdings wird es nicht grundsätzlich benötigt. Es ist vielmehr eine Alternative beim anlegen der GPIOs.
meinst du mit reboot den raspberry Neustart?
unter /sys/ gibt es nur virtuelle Dateien. Die sind nicht auf der SD Karte abgelegt und werden folglich bei jedem Neustart neu erzeugt. Daher lassen sich die Rechte auch nicht permanent speichern.
Wenn du Jessie als Neuinstallation hast sollte aber das hinzufügen von fhem zur Gruppe gpio vollkommen ausreichen.
Das minibian scheint die gpios ander zu behandeln
Zitat von: r_knipp am 22 April 2016, 22:57:25
root@minibian:/sys/class/gpio# ls -l
total 0
--w------- 1 root root 4096 Apr 22 21:08 export
lrwxrwxrwx 1 root root 0 Apr 22 21:09 gpio17 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root root 0 Apr 22 21:00 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
--w------- 1 root root 4096 Apr 22 21:00 unexport
[/code]
Export sollte nämlich so aussehen:
-rwxrwx--- 1 root gpio 4096 Apr 22 22:56 export
Btw:
Unix (Linux) hat ein Rechtekonzept, warum werden dann immer für Produktivsysteme erstmal alle rechte auf alles gesetzt?
chmod 777
bedeutet, das ALLE dort ALLES dürfen, im positiven wie im negativen Falle.
Besser ist es immer, es über eine Gruppe zu lösen, wie die hier schon erwähnte Gruppe gpio. Alternativ kann man sich mit Bordmitteln (z.B. udev) auch eine Gruppe "basteln", welch man fhem hinzufügt.
@wernieman, über die 777 hier kann man natûrlich trefflich streiten, ich sehe das jedenfalls im context. Wenn das Ding zuhause in einer privaten Umgebung werkelt und es auch nur einen User gibt dann ist das wohl egal. In einer Multiuserumgebung gebe ich dir natürlich recht.
Zitat von: knxhm am 26 April 2016, 07:35:53
@wernieman, über die 777 hier kann man natûrlich trefflich steiten,ich sehe das jedenfalls im context. Wenn das Ding zuhause in einer privaten Umgebung werkelt und es auch nur einen User gibt dann ist das wohl egal. In einer Multiuserumgebung gebe ich dir natürlich recht.
Genauso sehe ich das auch. Das über Gruppen, bzw. User zu lösen ist sicher besser. Die Lösung über die 777 ist aber etwas einfacher.
Bei mir soll das Teil das Aquarium überwachen und Signale an mein Haupt-FHEM senden. Ist also nur von mir selber per LAN zu erreichen. Also alles gut denke ich ;-)
Zitat von: klausw am 25 April 2016, 18:29:51
meinst du mit reboot den raspberry Neustart?
unter /sys/ gibt es nur virtuelle Dateien. Die sind nicht auf der SD Karte abgelegt und werden folglich bei jedem Neustart neu erzeugt. Daher lassen sich die Rechte auch nicht permanent speichern.
Wenn du Jessie als Neuinstallation hast sollte aber das hinzufügen von fhem zur Gruppe gpio vollkommen ausreichen.
Das minibian scheint die gpios ander zu behandeln
Export sollte nämlich so aussehen:
-rwxrwx--- 1 root gpio 4096 Apr 22 22:56 export
Ja, mit reboot meinte ich den Neustart des Raspis.
OK, wenn die GPIO Dateien nicht auf der SD-Karte abgelegt werden ist es klar dass sie bei Neustart weg sind. Dann ist das Skript wohl erstmal die beste Lösung.
Den Sinn dahinter muss man aber nicht verstehen, oder?
Das Minibian behandelt die GPIO glaube ich auch nicht anders. Aber die Gruppe GPIO gibt's nicht (User fhem sowieso nicht). Die musste ich selber anlegen.
Das Minibian ist halt maximal abgespeckt. Dafür ist es aber keine 500MB groß und braucht gerade mal knapp über 30MB RAM und bootet sauschnell.
Gefühlte 80%-90% des Raspbian braucht man für FHEM doch nicht. Außer FHEM und nano habe ich mir bisher nur Raspi-Config nachinstalliert weil damit das Resizen des Dateisystems etwas einfacher von der Hand geht.
ZitatWenn das Ding zuhause in einer privaten Umgebung werkelt
Da der Rechner über Deinen Router im INet hängt, sehe ich es leider anders. Mann sollte auch bei solchen "Kleingeräten" sich Gedanken über die Sicherheit machen. Deine Momentane Sicherheit ist, das es wenig fhem-Installationen gibt. Aber dieses kann sich durchaus Ändern ;o)
Also 1-2 Gedanken über die Sicherheit, dazugehört hier das 777, ist eventuell nicht verkehrt.
Wie man es anders löst, findet man pr google auch schnell ;o)
Wollte es nur mal erwähnt haben ;o)
Zitat von: r_knipp am 26 April 2016, 08:28:41
Ja, mit reboot meinte ich den Neustart des Raspis.
OK, wenn die GPIO Dateien nicht auf der SD-Karte abgelegt werden ist es klar dass sie bei Neustart weg sind. Dann ist das Skript wohl erstmal die beste Lösung.
Den Sinn dahinter muss man aber nicht verstehen, oder?
Der Sinn ist einfach der, daß du eine GPIO über das Dateisystem ansprechen kannst.
Es ist eine Virtuelle Datei, die auf den GPIO gemappt ist.
Eine Datei auf der SD Karte macht da doch keinen Sinn.
Zitat von: r_knipp am 26 April 2016, 08:28:41
Das Minibian behandelt die GPIO glaube ich auch nicht anders. Aber die Gruppe GPIO gibt's nicht (User fhem sowieso nicht). Die musste ich selber anlegen.
Das Minibian ist halt maximal abgespeckt. Dafür ist es aber keine 500MB groß und braucht gerade mal knapp über 30MB RAM und bootet sauschnell.
Gefühlte 80%-90% des Raspbian braucht man für FHEM doch nicht. Außer FHEM und nano habe ich mir bisher nur Raspi-Config nachinstalliert weil damit das Resizen des Dateisystems etwas einfacher von der Hand geht.
Bisschen schon wie mir scheint, die Gruppe gpio ist beim Raspbian vorhanden und die GPIOs sind per default von dieser Gruppe aus verwendbar.
Aber schnell booten ist auch ein Vorteil, da musst du halt abwägen.
Zitat von: klausw am 26 April 2016, 15:26:34
Der Sinn ist einfach der, daß du eine GPIO über das Dateisystem ansprechen kannst.
Es ist eine Virtuelle Datei, die auf den GPIO gemappt ist.
Das ist ist mir klar.
Zitat von: klausw am 26 April 2016, 15:26:34
Eine Datei auf der SD Karte macht da doch keinen Sinn.
Sorry, aber das verstehe ich nicht. Das sollte doch genauso auch funktionieren wenn die Dateien auf der SD-Karte liegen würden.
Oder etwa nicht?
Zitat von: klausw am 26 April 2016, 15:26:34
Aber schnell booten ist auch ein Vorteil, da musst du halt abwägen.
Naja, die Bootzeit finde ich primär nicht so wichtig. Wenns einmal läuft braucht mans ja nicht oft rebooten.
Eine kurze Bootzeit bedeutet doch aber auch, dass viel weniger Programme und Services beim Start geladen werden, die man eigentlich gar nicht braucht und die nur die Performance negativ beeinflussen würden.
Unix hat die Philosophie: Alles liegt im Dateisystem.
Es gibt mehr als ein "Pseudo-Dateisystem" unter Linux. Das ist z.B. /sys oder /proc. Wenn Du in diese absteigst (z.B. cd /proc) landest Du nicht auf Deiner Platte, sondern in einem eigenen "Treiber", der dieses Dateisystem abbildet.
Im Gegensatz zu Windows ist ein Device nicht ein Laufwerk, sondern liegt "nur" unter einem Ordner im Dateisystem. Dies kann irgendwo im Dateisystem liegen .... ist eigentlich relativ simple.
Ich glaube, ich sollte den Leipzig-Stammtisch mal voranbringen und dort einen Linux-Kurs "halten" ....
Zitat von: Wernieman am 26 April 2016, 18:43:57
Ich glaube, ich sollte den Leipzig-Stammtisch mal voranbringen und dort einen Linux-Kurs "halten" ....
...wenn der in der MB stattfindet könnte ich schwach werden 8)
Zitat von: r_knipp am 26 April 2016, 17:33:04
Naja, die Bootzeit finde ich primär nicht so wichtig. Wenns einmal läuft braucht mans ja nicht oft rebooten.
Eine kurze Bootzeit bedeutet doch aber auch, dass viel weniger Programme und Services beim Start geladen werden, die man eigentlich gar nicht braucht und die nur die Performance negativ beeinflussen würden.
Die kannst du auch im Raspbian deaktivieren und da gibt es inzwischen auch eine abgespeckte Version.
Wie erwähnt dort musst du kein script für die GPIOs schreiben...die funktionieren einfach.
Zitat von: Wernieman am 26 April 2016, 18:43:57
Unix hat die Philosophie: Alles liegt im Dateisystem.
Ich weiß, das hat uns unser Prof in den Vorlesungen für Netzwerke und Betriebssysteme schon immer eingetrichtert.
Trotzdem verstehe ich immer noch nicht warum die Dateien für die GPIOs nicht permanent auf der SD-Karte erzeugt werden können.
Sorry, vielleicht bin ich da ja etwas begriffsstutzig.
Aber ich nehme das erstmal so hin. Will den Thread ja nicht für eine Linux Schulung missbrauchen. Komme ja erstmal klar.
Zitat von: Wernieman am 26 April 2016, 18:43:57
Ich glaube, ich sollte den Leipzig-Stammtisch mal voranbringen und dort einen Linux-Kurs "halten" ....
Wär ich auch sofort dabei, wenn die Anfahrt nur nicht so weit wäre...
Webinar?
Zitat von: klausw am 26 April 2016, 21:41:18
Die kannst du auch im Raspbian deaktivieren und da gibt es inzwischen auch eine abgespeckte Version.
Wie erwähnt dort musst du kein script für die GPIOs schreiben...die funktionieren einfach.
Dazu fehlt mir leider das Know How :(
Webinar? ;)
OT:
@klausw
Was meinst Du mit MB
@r_knipp
Die Dateien können nicht angelegt werden, da es eben kein Dateisystem ist!
Kein Problem .... sollten wir nur im passenden Thread diskutieren
Habe mal einen neuen aufgemacht: https://forum.fhem.de/index.php/topic,52727.0.html (https://forum.fhem.de/index.php/topic,52727.0.html)
@Klaus:
Habe Dir dort eine Frage gestellt ;o)
Zitat von: Puschel74 am 22 April 2014, 10:49:43
Heute wurde bei uns (endlich) ein Wasserzähler mit Impulsausgang montiert.
Diesen Impulsausgang (1 Imp. = 1 Liter) möchte ich nun gerne an meinen RasPi klemmen und (logischerweise) abfragen.
Geht mein Vorhaben oder kommt sich I2C(GPIO1/2) und z.B. GPIO 17 in die Quere?
Nicht das sich das Modul resp. die WiringPi erstmal alle GPIO krallt und der I2C dann nichtmehr zur Verfügung steht.
Die Frage ist zwar schon eine Weile her, aber ich habe auch vor kurzem einen Wasserzähler mit Impulsausgang bekommen. Vorlage für die Realisierung war http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/
Ich habe den Impulsausgang auf den Stecker P5 (http://elinux.org/RPi_Low-level_peripherals) geklemmt, P5-06 und P5-08. Der Pullup kommt vom RaspberryPi GPIO.
Die Definition für RPIO_GPIO lautet wie folgt:
# water counter over RaspberryPi GPIO 31 (P5-6) and GND (P5-8)
define WZpin RPI_GPIO 31
attr WZpin active_low yes
attr WZpin devStateIcon on:ios-on-blue.png off:ios-off
attr WZpin direction input
attr WZpin interrupt both
attr WZpin pud_resistor up
attr WZpin room 3.1_Wasser
attr WZpin toggletostate yesFür das zählen selber nutze ich HourCounter:
define Wasser HourCounter WZpin:on WZpin:offHier habe ich mir zwei zusätzliche Readings gebaut, die mir am Tagesende den Tagesgesamtverbrauch schreibt:
# prepare reading total water volume in every night)
define WasserDay_at at *23:59:30 {my $new=ReadingsVal("Wasser","countsPerDay","0");;fhem "setreading Wasser countsPerDay_tot $new";;}
attr WasserDay_at room 3.1_Wasser
bzw. alle 15 min. die Differenz berechnet:
# prepare reading for every 15 minutes difference to before
define Wasser15min_at at +*00:15:00 {\
my $last=ReadingsVal("Wasser", "counts15min_last", "0");;;; \
my $act=ReadingsVal("Wasser","countsOverall","0");;;; \
my $val15min=$act-$last;;;; \
fhem "setreading Wasser counts15min $val15min";;;; \
fhem "setreading Wasser counts15min_last $act";;;; \
}
attr Wasser15min_at room 3.1_Wasser(ok, ich gebe zu, dass ich die fhem.cfg bearbeite, aber mit den Semikola weiß ich nicht, was ich tue >:().
Da ich nicht alles loggen will, hier der Rest vom Code (10 min. countsOverall, nur bei Änderung countsPerDay bzw. jedes Reading counts15min):
attr Wasser event-min-interval countsOverall:600
attr Wasser event-on-change-reading countsPerDay
attr Wasser event-on-update-reading counts15min,countsPerDay_tot
attr Wasser room 3.1_Wasser
# log values
define Wasser_log FileLog ./log/wasser-%Y-%m.log Wasser:countsOverall:.*|Wasser:countsPerDay:.*|Wasser:counts15min:.*
define 1_Wasser_svg SVG Wasser_log:PM_wasser:CURRENT
attr 1_Wasser_svg label "Wasserverbrauch: Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr 1_Wasser_svg room 3.1_Wasser
define Wasser_day_log FileLog ./log/wasser_d-%Y-%m.log Wasser:countsPerDay_tot:.*
define 2_Wasser_day_svg SVG Wasser_day_log:PM_wasser_d:CURRENT
attr 2_Wasser_day_svg label "Wasserverbrauch pro Tag: Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr 2_Wasser_day_svg fixedrange month
attr 2_Wasser_day_svg room 3.1_Wasser
Zum Schluß habe ich mir noch eine Übersicht gebaut:
# summary of readings
define 0_Wasser readingsGroup <Wasser>,<Gesamt>,<gestern>,<aktuell>,<15 min.> <hr> Wasser:countsOverall,countsPerDay_tot,countsPerDay,counts15min
attr 0_Wasser valueFormat {countsOverall => "%.0f l", countsPerDay_tot => "%.0f l", countsPerDay => "%.0f l", counts15min => "%.0f l"}
attr 0_Wasser room 3.1_WasserMan sieht sehr schön, wann ich mit event-on-xxx gekämpft habe ;)
Die gplots hänge ich auch mal ran, vielleicht kann es jemand brauchen.
Gruß PeMue
Edit: Eine Variable nachgetragen, damit auch der tägliche Verbrauch geloggt wird ;)
Hallo,
weiß jemand warum ich den user fhem nicht in die Gruppe gpio hinzufügen kann? Die Gruppe existiert bei mir nicht.. aber warum?
sudo adduser fhem gpio ->
adduser: The Group "gpio" does not exist.
Verwende das letzte raspian ::)
Zitat von: huhu am 03 August 2016, 10:37:38
Verwende das letzte raspian ::)
Hast du eine Neuinstallation gemacht, oder aktualisiert?
Die Gruppe sollte eigentlich vorhanden sein.
Hallo ich nutze SED heute dein Modul.
Erstmal muss ich sagen klasse das auslesen zweier GPIO funktionierte auf anhieb.
Aber beim schalten meiner 4 Relais habe ich das Problem das diese Invertiert sind. In FHEM steht On und die relais sind OFF.
Auch das attr aktive_low bringt keine Abhilfe egal ob es auf yes oder no steht.
Meine Relais brauchen GND zum schalten.
Kann es an WiringPI liegen das ich für Pilight und meine 433mhz Sender und Empfänger installiert habe?
Gibt es sonst noch ne Möglichkeit das Signal zu invertieren?
Hallo Tueftler1983,
gleiche Fragen an die selbe Person in unterschiedlichen Threads zu stellen beschleunigt die Antwort nicht. 8)
Ach sorry hatte garnicht auf den Namen geachtet dachte nur frag mal beim Ersteller des Moduls nach... lol und sorry
Hallo, ich habe ebenfalls das Problem, dass bei mir die Gruppe GPIO nicht existiert:
adduser: The Group "gpio" does not exist.
Ein chmod hilft leider immer nur bis zum nächsten reboot. Das System komplett neu aufzusetzen möchte ich vermeiden. Habt Ihr noch eine Idee, das zu fixen?
VG
F.
Hi, wem gehören denn die GPIO Files?
Bitte mal dies probieren:
ll /sys/class/gpio/
-rwxrwx--- 1 root gpio 4096 May 21 08:10 export
lrwxrwxrwx 1 root gpio 0 May 21 08:04 gpio17 -> ../../devices/virtual/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan 1 1970 unexport
Hier sieht man schön das user root und der Gruppe gpio der Zugriff gehört.
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Hallo also der Befehl
ll /sys/class/gpio/
Führt bei mir zu folgendem Ergebnis
root@fhemserver:~# ll /sys/class/gpio/
-bash: ll: Kommando nicht gefunden.
ll ist ein alias, den sich viele anlegen.
mach einfach ein:
ls -lha /sys/class/gpio/
Das ergibt bei mir dann
root@fhemserver:~# ls -lha /sys/class/gpio/
insgesamt 0
drwxrwx--- 2 root gpio 0 Okt 11 09:47 .
drwxr-xr-x 48 root root 0 Okt 10 11:18 ..
-rwxrwx--- 1 root gpio 4,0K Okt 11 09:48 export
lrwxrwxrwx 1 root gpio 0 Okt 11 09:47 gpio10 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Okt 10 11:19 gpio18 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio18
lrwxrwxrwx 1 root gpio 0 Okt 10 11:20 gpio22 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio22
lrwxrwxrwx 1 root gpio 0 Okt 10 11:20 gpio23 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Okt 10 11:20 gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Okt 10 11:20 gpio27 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Okt 11 09:47 gpio9 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio9
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4,0K Okt 11 09:45 unexport
root@fhemserver:~#
Bei mir sieht es anders aus, beides root:
drwxr-xr-x 2 root root 0 Oct 16 19:40 .
drwxr-xr-x 47 root root 0 Oct 16 16:43 ..
--w------- 1 root root 4.0K Oct 16 18:57 export
lrwxrwxrwx 1 root root 0 Oct 16 16:43 gpio17 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root root 0 Oct 16 16:43 gpio18 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio18
lrwxrwxrwx 1 root root 0 Oct 16 16:43 gpio2 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio2
lrwxrwxrwx 1 root root 0 Oct 16 19:40 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
--w------- 1 root root 4.0K Oct 16 19:40 unexport
Was mich wundert ist das bei mir GPIO 17 nicht aufgeführt ist da bei mir 17 und 18 für Pilight 433mhz Sender und Empfänger in Gebrauch sind an 22,23,24,27 hängen Relais und 9,10 Sind Eingänge von der Klingel
Zitat von: Fistandantilus am 16 Oktober 2016, 19:42:34
Bei mir sieht es anders aus, beides root:
drwxr-xr-x 2 root root 0 Oct 16 19:40 .
drwxr-xr-x 47 root root 0 Oct 16 16:43 ..
--w------- 1 root root 4.0K Oct 16 18:57 export
lrwxrwxrwx 1 root root 0 Oct 16 16:43 gpio17 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root root 0 Oct 16 16:43 gpio18 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio18
lrwxrwxrwx 1 root root 0 Oct 16 16:43 gpio2 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio2
lrwxrwxrwx 1 root root 0 Oct 16 19:40 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
--w------- 1 root root 4.0K Oct 16 19:40 unexport
vermutlich hast du ein update von wheezy auf jessie gemacht.
Dieses hat bei mir auch die Rechte zerschossen.
Folgende Lösungen existieren:
1. Neuinstallation
2. in der rc.locals die Rechte anpassen. So werde sie bei jedem Reboot neu gesetzt. Beispiel ist in der commandref
3. wiringpi installieren, darüber kann RPI_GPIO auch die GPIOs exportieren. Allerdings lassen sich in diesem Fall die GPIOs nicht invertieren
Zitat von: Tueftler1983 am 16 Oktober 2016, 20:23:30
Was mich wundert ist das bei mir GPIO 17 nicht aufgeführt ist da bei mir 17 und 18 für Pilight 433mhz Sender und Empfänger in Gebrauch sind an 22,23,24,27 hängen Relais und 9,10 Sind Eingänge von der Klingel
Es sind nur die GPIOs aufgeführt, die du auch als input/output angelegt hast (sprich per hand über /sys/class/gpio/export, über RPI_GPIO oder wiringpi).
GPIOs die für alternative Funktionen konfiguriert sind erscheinen nicht im sysfs.
Hmm okay aber GPIO 17 habe ich ja auch nicht von Hand angelegt.... Aber egal.
Übermorgen kommt mein RPI3 dann muss ich eh komplett neu aufsetzen gibt es vielleicht Tipps oder so welche Raspbian Version ich installieren soll?
Hallo ich bin noch auf dem RPI 2+ ich habe jetzt in der rc.locals das eingetragen
echo 9 > /sys/class/gpio/export
echo 10 > /sys/class/gpio/export
echo 22 > /sys/class/gpio/export
echo 23 > /sys/class/gpio/export
echo 24 > /sys/class/gpio/export
echo 27 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/virtual/gpio/*
chown -R fhem:root /sys/class/gpio/*
Jedoch kann ich das attr active low nicht nutzen die rechte sehen jetzt so aus
root@fhemserver:~# ls -l /sys/class/gpio/gpio22/
insgesamt 0
-rw-r--r-- 1 root root 4096 Okt 25 22:38 active_low
lrwxrwxrwx 1 root root 0 Okt 25 22:48 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Okt 25 22:38 direction
-rw-r--r-- 1 fhem fhem 4096 Okt 25 22:38 edge
lrwxrwxrwx 1 root root 0 Okt 25 22:36 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Okt 25 22:36 uevent
-rw-r--r-- 1 fhem fhem 4096 Okt 25 22:38 value
root@fhemserver:~# ls -la /sys/class/gpio/
insgesamt 0
drwxrwx--- 2 root gpio 0 Okt 25 22:36 .
drwxr-xr-x 48 root root 0 Okt 25 22:38 ..
-rwxrwx--- 1 fhem dialout 4096 Okt 25 22:38 export
lrwxrwxrwx 1 fhem dialout 0 Okt 25 22:36 gpio10 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio10
lrwxrwxrwx 1 fhem dialout 0 Okt 25 22:36 gpio18 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio18
lrwxrwxrwx 1 fhem dialout 0 Okt 25 22:36 gpio22 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio22
lrwxrwxrwx 1 fhem dialout 0 Okt 25 22:36 gpio23 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio23
lrwxrwxrwx 1 fhem dialout 0 Okt 25 22:36 gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24
lrwxrwxrwx 1 fhem dialout 0 Okt 25 22:36 gpio27 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio27
lrwxrwxrwx 1 fhem dialout 0 Okt 25 22:36 gpio9 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio9
lrwxrwxrwx 1 fhem dialout 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 fhem dialout 4096 Jan 1 1970 unexport
root@fhemserver:~#
Wo mache ich noch den fehler?
wie sehen die Rechte der GPIOs nach dem reboot aus, OHNE das FHEM gestartet wurde?
edge und value mit den Rechten fhem:fhem (und der Rest mit root:root) macht den Eindruck, das diese über wiringpi angelegt wurden.
Hallo,
ich habe gerade ein Problem mit "get", das ich mir nicht erklären kann: In einer Funktion (getWDx_I2C() in 99_myUtils.pm), die zuverlässig zu bestimmten Zeiten aufgerufen wird, werden die verdrahteten Fensterkontakte geprüft, die über Arduino nano abgefragt und als Word über I2C an FHEM übertragen und bitweise dort verarbeitet werden, also jedes Bit steht für einen Kontakt. Funktioniert seit geraumer Zeit tadellos.
Nun wollte ich mal kurz auch noch das Gartentor integrieren, das über ein Bit des BPI, auf dem FHEM läuft, abgefragt in fhem.cfg wird:
define pin13 RPI_GPIO 27
attr pin13 direction input
attr pin13 interrupt both
attr pin13 room Garten
define di_pin13 DOIF ([pin13:Pinlevel] eq "high") (setreading OpenWinDoorDummy Door.Garten open) DOELSE (setreading OpenWinDoorDummy Door.Garten closed)
Das funktioniert zwar, aber nicht immer so ganz zuverlässig. Grund unbekannt.
Nun wollte ich noch eine zusätzliche Abfrage in die zyklische Funktion getWDx_I2C() einbauen um zuverlässig zu ermitteln. ob das Tor nun wirklich zu ist:
my $pin13 = fhem(get pin13);
Dort bleibt die Funktion stehen, bzw. wird nicht weiter ausgeführt, was ich an den Log-Einträgen vorher und nachher sehen kann. Weshalb?
Warum bleibt die Abarbeitung der Funktion dort an dieser Stelle stehen und wird nicht weiter durchgeführt?
Wenn mir da mal einer einen Tipp geben kann, wäre ist dankbar.
Gruß
Manne
versuche es in dieser Weise:
my $val = ReadingsVal(<name>,<reading>,<default value>)
my $val = ReadingsVal("pin13","Pinlevel","low")
Vielen Dank, aber da lese ich doch nur das was in der Variablen pin13 steht, was aber offenbar nicht immer richtig ist. Ich wollte mal den Pin direkt abfragen und das geht offenbar nicht. Hängt das etwa vom Attribut "attr interrupt both" ab, d.h. das get wartet auf den nächsten Interrupt?
Bei get liest das Modul den aktuellen Pinstatus aus da sollte nix hängen.
Ws sei denn der Pin wird anderweitig blockiert.
Mit attr interrupt both sorgst du nur dafür, das die Readings im Falle eines Pegelwechsels sofort aktualisiert werden und du damit immer aktuelle Readings hast (das wäre natürlich Voraussetzung für ReadingsVal).
Ich habe bei get einen Fehler gemacht und anstatt
my $pin13 = fhem("get pin13");
das ohne Anführungszeichen geschrieben. Aber warum da keine Fehlermeldung kommt, sondern die Verarbeitung abbricht, das ist mir unklar. Ich sehe es nämlich an den folgenden Log-Einträgen, die ausbleiben wenn der Befehl ohne Anführungszeichen geschrieben wird.
Ausgabe ist nicht nur der Wert, sondern ein String:
pin13:Current Value for pin13: low
Was mir nicht klar ist, ist das nun der direkte Zugriff auf den Pin oder nur das Reading, das man auch mit ReadingsVal(..) bekommen könnte?
Hallo
Ich bin mittlerweile auf dem RPI3 was auch soweit gut klappt aber ich bekomme auf meinem Klingel Eingang Störungen drauf. sprich wenn ich meinen Türschnapper schalte (12V DC) bekomme ich die meldung TuerKlingel
Das heißt ich habe Störungen die ich mir einfange.
Habe das attr pud resistor auf down da ich die 3,3v auf den gpio schalte.
Kann es sein das der Pull_Down doch nicht gesetzt ist? GIBT es ne Möglichkeit das zu überprüfen?
Zitat von: manne44 am 29 Oktober 2016, 02:36:16
Was mir nicht klar ist, ist das nun der direkte Zugriff auf den Pin oder nur das Reading, das man auch mit ReadingsVal(..) bekommen könnte?
Mit get wird der aktuelle Pinwert gelesen.
Zitat von: Tueftler1983 am 29 Oktober 2016, 15:24:14
Ich bin mittlerweile auf dem RPI3 was auch soweit gut klappt aber ich bekomme auf meinem Klingel Eingang Störungen drauf. sprich wenn ich meinen Türschnapper schalte (12V DC) bekomme ich die meldung TuerKlingel
Das heißt ich habe Störungen die ich mir einfange.
Habe das attr pud resistor auf down da ich die 3,3v auf den gpio schalte.
Kann es sein das der Pull_Down doch nicht gesetzt ist? GIBT es ne Möglichkeit das zu überprüfen?
Ich empfehle dir, einen externen Pullup zu verwenden. Der interne ist recht schwach.
Wenn du Störungen hast dann würde ich nen Tiefpass an den Pin ran bauen.
Was ich komisch finde ist mit dem RPI2+ hatte ich die selbe Verkabelung (nur von den einem RPI auf den anderen umgestecht. Auch die fhem config war gleich aber da hatte ich die Probleme nicht.
Dann habe ich mal den pud resistor auf up gestellt, eigentlich hätte der Pin Status sich ja auf high ändern sollen dem war aber nicht so
Vielen Dank für die Antworten und auch für das ganze Modul, was das digitale IO über die Pins sehr einfach macht.
Zitat von: Tueftler1983 am 29 Oktober 2016, 23:44:59
Was ich komisch finde ist mit dem RPI2+ hatte ich die selbe Verkabelung (nur von den einem RPI auf den anderen umgestecht. Auch die fhem config war gleich aber da hatte ich die Probleme nicht.
Dann habe ich mal den pud resistor auf up gestellt, eigentlich hätte der Pin Status sich ja auf high ändern sollen dem war aber nicht so
Naja, den Pullup stellt WiringPi ein. Es kann sein, das der Prozessor im Pi3 von WiringPi nicht unterstützt wird. Oder dieser Pin hat beim Pi3 keinen PullUp.
Diesbezüglich bin ich überfragt.
Aber wenn es mit dem internen Pullup beim Pi2 funktionierte geht es sicher mit einem Externen und dem Pi3
Hmm okay sieht dann zwar nicht mehr so hübsch aus aber egal wenn nicht anders geht
Zitat von: Tueftler1983 am 30 Oktober 2016, 23:00:52
Hmm okay sieht dann zwar nicht mehr so hübsch aus aber egal wenn nicht anders geht
Hübsch? Na wenns im Wohnzimmer an der Wand hängt kann ich dir nicht helfen ;D
Nein das nicht hängt in einer abkastung im Flur wo auch der Sicherungskasten ist.
Habe den fehler mit den Pull-Down gefunden.... WiringPI war nicht installiert.
Problem besteht weiterhin. Werde jetzt noch versuchen auf Pull-UP zu stellen und GND zu schalten.
Wenn das auch nicht hilft kommen Externe Widerstände dran.
Also jetzt funktioniert es!
Pud_resistor auf Pull-UP gestellt und mit GND schalten. Jetzt habe ich keine Störungen mehr!
Danke für die hilfe
Zitat von: Tueftler1983 am 31 Oktober 2016, 17:52:45
Also jetzt funktioniert es!
Pud_resistor auf Pull-UP gestellt und mit GND schalten. Jetzt habe ich keine Störungen mehr!
Ok, also up geht, aber down nicht?
Hmm, dann kann vermutlich der Portpin nix anderes
Hi,
bei mir funktioniert der Interrupt-Modus nicht, d.h. ich kann einen Input per ReadValue erfolgreich einlesen mit wechselndem state.
Aber bei Zustandswechsel wird der State nicht automatisch geändert durch Interrupt.
Raspy B, neuestes Wheezy, WiringPi installiert
DEF 18
EXCEPT_FD 12
GPIO_Basedir /sys/class/gpio
NAME TuerKlingel
NR 974
RPI_pin 18
STATE off
TYPE RPI_GPIO
WiringPi_gpio
Readings:
2016-11-12 11:27:19 Pinlevel low
2016-11-12 11:27:19 state off
Fhem:
interfaces switch
Attributes:
direction input
interrupt rising
pud_resistor down
restoreOnStartup off
room Interfaces
ls -l /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 Nov 11 21:40 export
lrwxrwxrwx 1 root gpio 0 Nov 11 21:40 gpio18 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio18
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
Was mache ich falsch ?
Gruss
Joe
Also wenn es sich um das zuferlässige melden der Türklingel geht bin ich bei Counter hängen geblieben das funktioniert bei mir zu 100%. Mit einem DOIF frage ich die Änderung des Counter ab
Nein es geht darum, dass sich mein State bzw. Pinlevel in FHEM nicht automatisch aendert, wenn ich an den PIN GND oder 3.3 V anlege.
Nur wenn ich manuell ReadValue ausführe, dann wird der Zustand erkannt ...
Einen Counter hab ich auch nicht ...
Zitat von: cotecmania am 12 November 2016, 15:33:42
Nein es geht darum, dass sich mein State bzw. Pinlevel in FHEM nicht automatisch aendert, wenn ich an den PIN GND oder 3.3 V anlege.
Nur wenn ich manuell ReadValue ausführe, dann wird der Zustand erkannt ...
Einen Counter hab ich auch nicht ...
attribut interrupt auf both stellen um Pegeländerungen zu sehen
Wenn das Attribut auf rising steht wird natürlich auch nur ein Interrupt und damit eine Aktualisierung bei steigender Flanke ausgelöst.
Es wird dabei auch ein Ereignis ausgelöst (erkennbar daran, das sich die Readingzeit ändert wenn jemand klingelt), welches du für ein notify oder DOIF verwenden könntest.
Du solltest überlegen, was du überhaupt benötigst und dann entscheiden, welche Art von Interrupt dafür die beste ist.
Wenn du die Klingeldauer haben möchtest dann ist "both" notwendig
Wenn nur das Ereignis, das jemand gedrückt hat wichtig ist dann rising oder falling.
Zitat von: klausw am 13 November 2016, 00:34:16
Wenn das Attribut auf rising steht wird natürlich auch nur ein Interrupt und damit eine Aktualisierung bei steigender Flanke ausgelöst.
Es wird dabei auch ein Ereignis ausgelöst (erkennbar daran, das sich die Readingzeit ändert wenn jemand klingelt), welches du für ein notify oder DOIF verwenden könntest.
Das ist mir klar, aber es wird eben
gar kein Zustandswechsel automatisch erkannt, auch nicht wenn ich "both" einstelle.
Das ist mein Problem ...
Muss man die Interrupt-Funktionalität erst irgendwie aktivieren ?
Nur wenn ich dann in FHEM auf ReadValue klicke, werden die Readings incl. Zeitangabe aktualisiert ...
Gruss
Joe
Ist fhem den Mitglied in der Gruppe gpio?
Also wenn der impuls am Eingang nicht zu kurz ist sollte fhem es mitbekommen.
Bei mir klappt es am besten wenn ich die interne pullups aktiviere und den gpio beim schalten auf gnd ziehe
Zitat von: cotecmania am 13 November 2016, 11:03:00
Das ist mir klar, aber es wird eben gar kein Zustandswechsel automatisch erkannt, auch nicht wenn ich "both" einstelle.
Das ist mein Problem ...
Muss man die Interrupt-Funktionalität erst irgendwie aktivieren ?
Nur wenn ich dann in FHEM auf ReadValue klicke, werden die Readings incl. Zeitangabe aktualisiert ...
Das ist ein seltsames Verhalten.
Der Interrupt muss nicht aktiviert werden.
Es könnte ein Rechteproblem sein, aber dann sollte gar nix gehen. Steht was im Log?
was bringt:
ls -l /sys/class/gpio/gpio18/
Die Zustände "high/low" bzw. "on/off" werden grundsätzlich erkannt, wenn ich auf ReadValue klicke ...
Nur die automatische Interrupt-Funktion bzw. das automatische setzen der Readings gehen nicht ...
Im Log habe ich nichts gefunden. Muss ich verbose hochsetzen ?
pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio18/
total 0
-rw-r--r-- 1 root root 4096 Nov 13 17:47 active_low
lrwxrwxrwx 1 root root 0 Nov 13 17:47 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Nov 13 13:24 direction
-rw-r--r-- 1 fhem dialout 4096 Nov 13 13:24 edge
lrwxrwxrwx 1 root root 0 Nov 13 13:24 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Nov 13 13:24 uevent
-rw-r--r-- 1 fhem dialout 4096 Nov 13 13:24 value
Gruss
Joe
Erste Problem was ich sehe das die rechte zerschossen sind. Eigentlich sollte da immer root gpio stehen nicht root root
Hast du mal ein Upgrade weelzy auf jessie gemacht?
Dadurch kannst du die Funktionen active_low und pud_resistor nicht so einfach nutzen
Also wie gesagt wenn es nur darum geht auf das Klingeln zu reagieren geht es bei mir am besten über den counter.
Die Screenshots zeigen wie ich das Klingeln auswerte und reagiere
Fehlerhafte Dateizugriffe sollten eigentlich im Log auftauchen.
Aber wer weiß, vielleicht habe ich was übersehen. Verbose 5 kann nicht schaden.
Kann es sein, das du ein Update von wheezy auf jessie gemacht hast?
Die Dateien in /sys/class/gpio/ (export und unexport) haben die korrekten Rechte (-rwxrwx--- 1 root gpio)
Diese Rechte müssten auch die Dateien des GPIO nach Anlegen haben.
Nach einem Upgrade von wheezy auf jessie funktioniert das nicht mehr
Ist WiringPi installiert? Die Rechte von Edge und Value deuten darauf hin, aber die Pfadangabe ist leer, was wiederum auf das fehlen hindeutet.
Ist fhem in der Gruppe dialout?
mit
cat /sys/class/gpio/gpio18/edge
kannst du überprüfen ob die Datei korrekt geschrieben wurde
Hi,
WiringPi habe ich installiert.
Arbeite immer noch mit Wheezy, kein Jessy.
pi@raspberrypi /sys/class/gpio $ cat /sys/class/gpio/gpio18/edge
both
Ist fhem in der Gruppe dialout? - Wie finde ich das raus ?
Ich komme aus der Windows-Welt und bin in Linux nicht sehr firm.
Kann man nicht dem ganzen Pfad auf einmal die notwendigen Berechtigungen geben ?
Eine Anleitung der Linux-Befehle in der richtigen Reihenfolge, damit alles läuft, wäre sehr hilfreich.
Gruss Joe
Zitat von: cotecmania am 13 November 2016, 19:09:36
WiringPi habe ich installiert.
Arbeite immer noch mit Wheezy, kein Jessy.
pi@raspberrypi /sys/class/gpio $ cat /sys/class/gpio/gpio18/edge
both
Hm, das passt doch an den Rechten kann es also nicht liegen.
An sich müsste es funktionieren. Jetzt wird es langsam schwierig.
Ist das Modul aktuell? Mache mal ein "update force"
Und dann mal mit verbose 5 starten (global und im Modul)
Zitat von: cotecmania am 13 November 2016, 19:09:36
Ist fhem in der Gruppe dialout? - Wie finde ich das raus ?
Ich komme aus der Windows-Welt und bin in Linux nicht sehr firm.
Kurzer Abriss (https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/) über Linux User und Gruppen
Zitat von: cotecmania am 13 November 2016, 19:09:36
Kann man nicht dem ganzen Pfad auf einmal die notwendigen Berechtigungen geben ?
Jein, du kannst nach anlegen des GPIO die Rechte setzen. Das musst du aber nach jedem Reboot machen, da es nur virtuelle Dateien sind, die jedesmal beim booten neu erzeugt werden.
Zitat von: cotecmania am 13 November 2016, 19:09:36
Eine Anleitung der Linux-Befehle in der richtigen Reihenfolge, damit alles läuft, wäre sehr hilfreich.
Stehen in der commandref. So wie dort beschrieben funktioniert es üblicherweise.
Hi,
gestern bin ich "gezwungenermassen" von wheezy auf Jessie umgestiegen (knapp 7h update ;-)) , da ich sonst meinen Bluetooth-Thermostat von EQ-3 nicht zum laufen bekam.
Nun habe ich mal unter Jessie den GPIO18 wieder auf 3.3V gelegt und siehe da, der Interrupt wurde ausgelöst.
Gruss
Joe
Ja unter Jessie bin ich auch zufriedener mit der Ansteuerung und dem auslesen der GPIO'S
Hallo Zusammen,
habe seit kurzem meinen RPi3 mit Stretch Lite am Laufen.
FHEM läuft problemlos, wollte nun GPIO einbinden und bekomme permanent.
Zitat
2018.01.02 14:11:26 1: Can't open file: RasPi_Pin38, value
2018.01.02 14:13:29 1: Can't open file: RasPi_Pin38, value
2018.01.02 14:15:48 1: Can't open file: RasPi_Pin38, value
2018.01.02 14:17:16 5: wird an setextensions gesendet: RasPi_Pin38 ?
2018.01.02 14:17:16 5: wird an setextensions gesendet: RasPi_Pin38 ?
2018.01.02 14:17:16 5: wird an setextensions gesendet: RasPi_Pin38 ?
2018.01.02 14:17:16 5: RasPi_Pin38, in fileaccess: value
2018.01.02 14:17:16 1: Can't open file: RasPi_Pin38, value
2018.01.02 14:17:16 1: RasPi_Pin38 GetFn: readout of Pinvalue fail
2018.01.02 14:17:21 5: RasPi_Pin38, in fileaccess: value 0
2018.01.02 14:17:21 1: Can't open file: RasPi_Pin38, value
2018.01.02 14:17:21 5: wird an setextensions gesendet: RasPi_Pin38 ?
Hatte zuvor FHEM auf RasPi2 mit Wheezy am Laufen.
Wesentlicher Unterschied Stretch zu Wheezy ist, dass ich jetzt den Benutzer fhem mit definierten Rechten, kein root, angelegt habe.
Zitat
fhem@RasPi3:~ $ id
uid=1001(fhem) gid=1001(fhem) groups=1001(fhem),20(dialout),997(gpio)
fhem@RasPi3:~ $ groups
fhem dialout gpio
fhem@RasPi3:~ $
Zitat
fhem@RasPi3:~ $ ls -l /sys/class/gpio/gpio20/
total 0
-rwxrwx--- 1 root gpio 4096 Jan 2 14:10 active_low
lrwxrwxrwx 1 root gpio 0 Jan 2 14:10 device -> ../../../gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan 2 14:15 direction
-rwxrwx--- 1 fhem fhem 4096 Jan 2 14:10 edge
drwxrwx--- 2 root gpio 0 Jan 2 14:10 power
lrwxrwxrwx 1 root gpio 0 Jan 2 14:10 subsystem -> ../../../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Jan 2 14:10 uevent
-rwxrwx--- 1 fhem fhem 4096 Jan 2 14:20 value
fhem@RasPi3:~ $
Wenn ich Value manuell ändere, dann bekomme ich LED an GPIO auch zum Leuchten.
Ich vermute ein Rechteproblem, obwohl value Gruppe und Benutzer fhem volle Rechte haben.
Hat jemand einen Tipp?
Danke im Voraus
Knut
Komisch, die Rechte passen.
Hast du nach setzen der Rechte neu gestartet? Der Befehl reboot scheint da nicht immer zu funktionieren.
Bringt "{`id`}" in Fhem eingegeben die gleiche Zeile wie in deinem vorangegangenen Post?
Hallo Klaus,
"{`id`}" in Fhem eingegeben bringt
uid=1001(fhem) gid=1001(fhem) groups=1001(fhem),20(dialout)irgendwie nicht ganz das gleiche zu
Zitatuid=1001(fhem) gid=1001(fhem) groups=1001(fhem),20(dialout),997(gpio)
da fehlt gpio!
Muss man da in fhem was anpassen?
Grüße
ich hatte eher erwartet, das die uid nicht fhem ist
gleiche uid heisst für mich, gleiche gruppen
Das Ergebnis verstehe ich nicht.
hast du zwischenzeitlich neu gestartet? evtl. übernimmt ein Prozess die Rechte/Gruppen, etc. beim laden.
Das war der richtige Hinweis!
Ich hatte fhem schon mehrfach neu gestartet,
aber nie den Pi gebootet.
Nach Reboot funktioniert es. :)
Danke
Hallo klausw,
ich habe einen kleinen Abstellraum, in dem sich mein FHEM RPI3 befindet und der 2 Türen hat. Ich würde gerne per FHEM das Licht (HUE Lampe) im Raum einschalten, sobald eine der beiden Türen geöffnet wird. Sind beide Türen geschlossen, soll das Licht im Raum ausgehen.
Natürlich könnte ich das über Türkontakte lösen, würde aber ungern 2 Mal 30,- Euro für die HomeMatic Türkontakte ausgeben und bin deshalb auf die Idee gekommen, das Problem mit den GPIOs des RPI3 zu lösen.
Leider fehlt mir das technische Know-How, um entscheiden zu können, was für Sensoren ich an den Türen anbringen muss, um sie direkt mit dem RPI3 abfragen zu können.
Für Hilfe wäre ich sehr dankbar.
Vielen Dank.
Grüße Mave
Einfache kabelgebundene Reed Kontakte
Hallo Forum,
ich hole dieses Thema nochmal hoch da ich grade vor den Problem stehe meine Gpio´s nicht ansteuern zu können. Als Hintergrund möchte ich gern ein Relaismodul ansteuern um damit Rollos zu steuern. Hierzu habe ich das GPIO Modul wie folgt eingebunden:
define Kopfup RPI_GPIO 12
attr Kopfup direction output
define Kopfdown RPI_GPIO 13
attr Kopfdown direction output
define Fussup RPI_GPIO 4
attr Fussup direction output
attr Fussup verbose 5
define Fussdown RPI_GPIO 5
attr Fussdown direction output
attr Fussdown verbose 5
define Schereup RPI_GPIO 2
attr Schereup direction output
define Scheredown RPI_GPIO 3
attr Scheredown direction Output
Wenn ich nun neu starte bekomme ich unter /sys/class/gpio/ das angezeigt:
drwxrwx--- 2 fhem dialout 0 Dez 18 15:29 .
drwxr-xr-x 50 root root 0 Dez 18 15:43 ..
-rwxrwx--- 1 root gpio 4096 Dez 18 15:29 export
lrwxrwxrwx 1 root gpio 0 Dez 18 15:29 gpio12 -> ../../devices/platform/soc/20200000.gpio/gpiochip0/gpio/gpio12
lrwxrwxrwx 1 root gpio 0 Dez 18 15:29 gpio13 -> ../../devices/platform/soc/20200000.gpio/gpiochip0/gpio/gpio13
lrwxrwxrwx 1 root gpio 0 Dez 18 15:29 gpio2 -> ../../devices/platform/soc/20200000.gpio/gpiochip0/gpio/gpio2
lrwxrwxrwx 1 root gpio 0 Dez 18 15:29 gpio3 -> ../../devices/platform/soc/20200000.gpio/gpiochip0/gpio/gpio3
lrwxrwxrwx 1 root gpio 0 Dez 18 15:29 gpio4 -> ../../devices/platform/soc/20200000.gpio/gpiochip0/gpio/gpio4
lrwxrwxrwx 1 root gpio 0 Dez 18 15:29 gpio5 -> ../../devices/platform/soc/20200000.gpio/gpiochip0/gpio/gpio5
lrwxrwxrwx 1 root gpio 0 Dez 18 15:26 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Dez 18 15:26 unexport
Ich habe wiringpi installiert und die Pinbezeichung habe ich wiringpi genutzt also nicht GPIO, ist das richtig so? Also ein zB gpio write 13 1 geht. Nur wenn ich in Fhem schalte bekomme ich in Log:
2018.12.18 16:11:06 5: Fussdown, in fileaccess: value 0
2018.12.18 16:11:06 5: wird an setextensions gesendet: Fussdown ?
2018.12.18 16:11:06 5: wird an setextensions gesendet: Fussdown ?
2018.12.18 16:11:08 5: Fussup, in fileaccess: value 0
2018.12.18 16:11:08 5: wird an setextensions gesendet: Fussup ?
2018.12.18 16:11:08 5: wird an setextensions gesendet: Fussup ?
Wenn ich in Fhem schalte bekomme ich mit zB cat /sys/class/gpio/gpio5/value eine 0 oder 1 aber der Gpio schaltet nicht.
Was mache ich falsch ?
Gruß
Frank
in
define <name> RPI_GPIO <GPIO number> ist die <GPIO number> halt GPIO number 8)
Die wiringpi Bezeichnung wird nicht verwendet.
Ist die commandref in diesem Punkt unverständlich?
In diesem Fall hätte ich gern einen Tip wie ich es besser verständlich schreiben kann.
Sorry habe ich total überlesen. Bin nach Anfänger im Bereich Fhem von daher danke für den Hinweis. Nun kann ich die Gpio´s ansteuern. Ich hätte aber noch eine Frage.
Meine Gpio´s steuern Relais, die dann wieder Rollos ansteuern. Nun schließen die Relais beim Booten heißt je nach dem wie ich die Relais anschließe, öffnen bzw schließen meine Rollos beim booten des Pi´s. Wie könnte ich das lösen ?
https://raspberrypi.stackexchange.com/questions/51479/gpio-pin-states-on-powerup
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Danke für den Hinweis, wäre es nicht einfacher nach setzten des Gpio auf Output ein zb echo 0 > /sys/class/gpio/gpio4/value zu senden ?
Wenn du das Attribut restoreOnStartup auf last setzt dann sollte der Output direkt nach dem Reboot korrekt gesetzt werden.
Es lässt sich aber nicht vermeiden, das beim Booten der rezessivzustand der Relais gesetzt wird.
Das sollte aber kein Problem sein, die Rolladenmotoren sollten ja nur beim fahren bestromt sein.
Hallo,
ich versuche gerade die Türklingel über einen GPIO Port auszuwerten.
Wird Taster gedrückt ( Kontakt geschlossen ) soll der PI das erkennen und weitere Funktionen werden per Script gestartet.
Ich kann über GPIO Relais ein und ausschalten. Das klappt.
Habe GPIO25 ist als Input definiert. Der zeigt keine Veränderung ob ich ihn auf GND oder 3.3V setzte.
Hat jemand eine Idee. Stehe derzeit im Wald und sehe die Bäume nicht.
Danke
Zitat von: Beetle2003 am 04 März 2019, 23:38:57
Hallo,
ich versuche gerade die Türklingel über einen GPIO Port auszuwerten.
Wird Taster gedrückt ( Kontakt geschlossen ) soll der PI das erkennen und weitere Funktionen werden per Script gestartet.
Ich kann über GPIO Relais ein und ausschalten. Das klappt.
Habe GPIO25 ist als Input definiert. Der zeigt keine Veränderung ob ich ihn auf GND oder 3.3V setzte.
Hat jemand eine Idee. Stehe derzeit im Wald und sehe die Bäume nicht.
Danke
Zeig mal bitte ei List von GPIO.
Gesendet von meinem Doogee S60 mit Tapatalk
Klinke mich hier mal ein....
Ich habe gestern auch einen GPIO als INPUT definiert.
Nachdem ich den Pegel am Eingang verändere muss ich erst den Button set GPIOxx readValue betätigen damit das Device den state sowie Pinlevel aktualisiert.
- Sollte dies nicht automatisch gehen oder muss ich sowas wie event-on-change-reading .* setzen ?
Danke.
Zitat von: Steffen@Home am 21 März 2019, 06:49:24
Klinke mich hier mal ein....
Ich habe gestern auch einen GPIO als INPUT definiert.
Nachdem ich den Pegel am Eingang verändere muss ich erst den Button set GPIOxx readValue betätigen damit das Device den state sowie Pinlevel aktualisiert.
- Sollte dies nicht automatisch gehen oder muss ich sowas wie event-on-change-reading .* setzen ?
Danke.
Da wir hier nicht hellsehen können für dich das gleiche:
Zeig mal ein list vom GPIO.
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 21 März 2019, 07:06:57
Da wir hier nicht hellsehen können für dich das gleiche:
Zeig mal ein list vom GPIO.
Gesendet von meinem Doogee S60 mit Tapatalk
Internals:
DEF 27
FUUID 5c92addb-f33f-1cf4-8787-815384e2da5b6ad0
GPIO_Basedir /sys/class/gpio
GPIO_Nr 27
NAME GPIO27
NR 36
STATE off
TYPE RPI_GPIO
WiringPi_gpio /usr/bin/gpio
READINGS:
2019-03-21 07:11:42 Pinlevel low
2019-03-20 19:17:15 state off
fhem:
interfaces switch
Attributes:
alias Gartentor- ist AUF!
comment Draht:gelb
devStateIcon off:fts_garage_door_100@grey on:fts_garage_door_20@F76205
direction input
group Tor_Garten_Zustand
room GPIOs
sortby 10
Hi,
Ist es das Problem?
Known issues mit WiringPi
active_low wird nicht korrekt exportiert, und damit sieht es so aus als wurde das setting ignoriert. Das ist ein Fehler im WiringPi.
https://github.com/blecher-at/WiringPi
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: Steffen@Home am 21 März 2019, 07:28:32
Internals:
DEF 27
FUUID 5c92addb-f33f-1cf4-8787-815384e2da5b6ad0
GPIO_Basedir /sys/class/gpio
GPIO_Nr 27
NAME GPIO27
NR 36
STATE off
TYPE RPI_GPIO
WiringPi_gpio /usr/bin/gpio
READINGS:
2019-03-21 07:11:42 Pinlevel low
2019-03-20 19:17:15 state off
fhem:
interfaces switch
Attributes:
alias Gartentor- ist AUF!
comment Draht:gelb
devStateIcon off:fts_garage_door_100@grey on:fts_garage_door_20@F76205
direction input
group Tor_Garten_Zustand
room GPIOs
sortby 10
Danke!
In erster Linie fehlt dir das interrupt Attribut. das erklärt das Verhalten deines GPIO.
Dann, Du schaltest 3,3V drauf zum aktivieren? oder schaltest Du mit 0V aktiv?
3,3V,
attr GPIO27 interrupt both
attr GPIO27 pud_resistor down
0V,
attr GPIO27 active_low yes
attr GPIO27 interrupt both
attr GPIO27 pud_resistor up
Zitat von: Frank_Huber am 21 März 2019, 08:59:02
Danke!
In erster Linie fehlt dir das interrupt Attribut. das erklärt das Verhalten deines GPIO.
Dann, Du schaltest 3,3V drauf zum aktivieren? oder schaltest Du mit 0V aktiv?
3,3V,
attr GPIO27 interrupt both
attr GPIO27 pud_resistor down
0V,
attr GPIO27 active_low yes
attr GPIO27 interrupt both
attr GPIO27 pud_resistor up
Hallo Frank,
ich setze 0V zum schalten. Der GPIO wird extern mit 4k7 Ohm auf high gezogen.
also setze ich:
attr GPIO27 active_low yes
attr GPIO27 interrupt bothda attr pud_resistor kann ich weglassen weil pullup extern gesetzt?
Danke.
Ja, dann kannst ihn weglassen.
Aber denke daran, nur auf 3v3 hochziehen, nie auf 5V.
Zitat von: Steffen@Home am 21 März 2019, 06:49:24
Klinke mich hier mal ein....
Ich habe gestern auch einen GPIO als INPUT definiert.
Nachdem ich den Pegel am Eingang verändere muss ich erst den Button set GPIOxx readValue betätigen damit das Device den state sowie Pinlevel aktualisiert.
- Sollte dies nicht automatisch gehen oder muss ich sowas wie event-on-change-reading .* setzen ?
Danke.
Ist das Attribut interrupt gesetzt?
Nur dann wird ein Gpio automatisch aktualisiert.
Wenn ja, steht was im Log? Notfalls das Loglevel (verbose) hochsetzen.
Zitat von: klausw am 21 März 2019, 12:44:47
Ist das Attribut interrupt gesetzt?
Nur dann wird ein Gpio automatisch aktualisiert.
Wenn ja, steht was im Log? Notfalls das Loglevel (verbose) hochsetzen.
Hi Klaus,
er hat mit seinem List schon bestätigt dass kein interrupt gesetzt war.
Das war auch meine erste Vermutung gewesen. :-)
Grüße
Frank
Ich werde das vermutlich heute Abend testen können! Danke.
Zitat von: Frank_Huber am 21 März 2019, 12:45:51
Hi Klaus,
er hat mit seinem List schon bestätigt dass kein interrupt gesetzt war.
Das war auch meine erste Vermutung gewesen. :-)
Grüße
Frank
Witzig, der Post auf den ich antwortete war zum Zeitpunkt meiner Antwort der letzte im Thread. Tapatalk ist scheinbar etwas lahm mit dem update [emoji3]
Mit Interrupt und active_low funktioniert alles wunderbar!
Kann mir jemand erklären wie ich mit diesem Modul auf eine RPI im Netzwerk zugreifen kann?
Zitat von: uwirt am 28 Juni 2020, 10:53:21
Kann mir jemand erklären wie ich mit diesem Modul auf eine RPI im Netzwerk zugreifen kann?
das ist nicht vorgesehen
Dieses Modul kann GPIOs nur auf dem Pi ansteuern auf dem auch die FHEM Instanz läuft.
Du könntest allerdings zwei FHEM Instanzen mit dem mqtt Bridge Modul verbinden.
Hallo,
das Modul basiert auf WiringPi, welches nicht mehr unterstützt wird und auch mit den in demWiki beschriebenen Aktionen nicht mehr installiert werden kann.
Kann das Modul RPI_GPIO ggf. auf eine andere Art des Zugriffs umgestellt werden ?
Es gibt einen Fork
https://github.com/WiringPi/WiringPi (https://github.com/WiringPi/WiringPi)
Das sollte helfen...
DANKE!
WiringPi wird nicht unbedingt benötigt und macht nur bei Sonderfunktionen Sinn.
Das Modul greift direkt auf die GPIOs zu.