Modul für die Ansteuerung des MCP23017 I2C Portextender

[klausw]

...so - WiringCB (WiringPi) funktioniert leider auch nicht.

wie lautet der komplette Pfad zum gpio utility von WiringCB?
ist es von den Befehlen her kompatibel zu WiringPi?
funktioniert es von der Shell aus?

[Punkt]

Hallo Klaus,

WiringCB ist soweit ich weis gleich zu WiringPi - ging meines Wissens daraus hervor.
Was aber ja merkwürdig ist: nach dem Reboot des Cubie funktioniert ja alles.

Die ls-Ausgaben hab ich mal zusammengestellt und häng sie unten an...

...aber mir ist nochwas aufgefallen:

Ich habe jetzt mal zusätzlich noch einen weiteren GPIO aktiviert und getestet (GPIO239).

Der funktioniert genauso (wenig).
Was vielleicht noch ein Hinweis sein könnte:

Nach einem Reboot gehe ich in FHEM auf die Detailseite des GPIO.
Wenn ich nun auf LOW / HIGH schalte (einfach per Draht auf 3.3V / GND) dann aktualisiert sich die Detailseite direkt von alleine und der Pinlevel wird sofort aktualisiert rot dargestellt.

Nach einem shutdown restart funktioniert das nicht mehr.
Der aktuelle Pinlevel wird dann nur wieder korrekt angezeigt wenn ich mit F5 aktualisiere - reproduzierbar immer wieder..


Ich exportiere mittlerweile die GPIO auch nicht mehr im Startscript - mit WiringCB geht das jetzt auch ohne...


so - hier mal jetzt noch die Ausgaben - bitte nicht von den Uhrzeiten irritieren lassen - die Ausgaben nach dem Neustart des Cubie hab ich nach dem ersten shutdown restart gemacht - und die zweite Ausgabe des GPIO239 nach dem 2. shutdown restart...:

nach Neustart

Code Auswählen Erweitern

michael@homie:~$ ls -l /sys/class/gpio/
total 0
--w------- 1 root root 4096 Mar 16 23:55 export
lrwxrwxrwx 1 root root    0 Mar 16 23:55 gpio231 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio231
lrwxrwxrwx 1 root root    0 Mar 16 23:55 gpio239 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio239
lrwxrwxrwx 1 root root    0 Mar 16 23:55 gpiochip0 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpiochip0
--w------- 1 root root 4096 Mar 16 23:55 unexport
michael@homie:~$ ls -l /sys/class/gpio/gpio231/
total 0
-rw-r--r-- 1 root root    4096 Mar 16 23:55 active_low
lrwxrwxrwx 1 root root       0 Mar 16 23:55 device -> ../../../1c20800.pinctrl
-rw-r--r-- 1 root root    4096 Mar 16 23:55 direction
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:55 edge
drwxr-xr-x 2 root root       0 Mar 16 23:55 power
lrwxrwxrwx 1 root root       0 Mar 16 23:55 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root    4096 Mar 16 23:55 uevent
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:55 value
michael@homie:~$ ls -l /sys/class/gpio/gpio239/
total 0
-rw-r--r-- 1 root root    4096 Mar 16 23:55 active_low
lrwxrwxrwx 1 root root       0 Mar 16 23:56 device -> ../../../1c20800.pinctrl
-rw-r--r-- 1 root root    4096 Mar 16 23:55 direction
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:55 edge
drwxr-xr-x 2 root root       0 Mar 16 23:56 power
lrwxrwxrwx 1 root root       0 Mar 16 23:56 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root    4096 Mar 16 23:55 uevent
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:55 value



nach shutdown restart

Code Auswählen Erweitern

michael@homie:/sys/class/gpio$ ls -l /sys/class/gpio/
total 0
--w------- 1 root root 4096 Mar 16 23:49 export
lrwxrwxrwx 1 root root    0 Mar 16 23:48 gpio231 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio231
lrwxrwxrwx 1 root root    0 Mar 16 23:48 gpio239 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio239
lrwxrwxrwx 1 root root    0 Mar 16 23:48 gpiochip0 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpiochip0
--w------- 1 root root 4096 Mar 16 23:48 unexport
michael@homie:/sys/class/gpio$ ls -l /sys/class/gpio/gpio231/
total 0
-rw-r--r-- 1 root root    4096 Mar 16 23:48 active_low
lrwxrwxrwx 1 root root       0 Mar 16 23:52 device -> ../../../1c20800.pinctrl
-rw-r--r-- 1 root root    4096 Mar 16 23:49 direction
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:49 edge
drwxr-xr-x 2 root root       0 Mar 16 23:52 power
lrwxrwxrwx 1 root root       0 Mar 16 23:52 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root    4096 Mar 16 23:48 uevent
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:48 value
michael@homie:~$ ls -l /sys/class/gpio/gpio239/
total 0
-rw-r--r-- 1 root root    4096 Mar 16 23:56 active_low
lrwxrwxrwx 1 root root       0 Mar 16 23:56 device -> ../../../1c20800.pinctrl
-rw-r--r-- 1 root root    4096 Mar 16 23:57 direction
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:57 edge
drwxr-xr-x 2 root root       0 Mar 16 23:56 power
lrwxrwxrwx 1 root root       0 Mar 16 23:56 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root    4096 Mar 16 23:56 uevent
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:55 value

nach shutdown - FHEM ist beendet

Code Auswählen Erweitern

michael@homie:~$ sudo service fhem status
[sudo] password for michael:
fhem is not running
michael@homie:~$ ls -l /sys/class/gpio/
total 0
--w------- 1 root root 4096 Mar 16 23:57 export
lrwxrwxrwx 1 root root    0 Mar 16 23:55 gpio231 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio231
lrwxrwxrwx 1 root root    0 Mar 16 23:55 gpio239 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio239
lrwxrwxrwx 1 root root    0 Mar 16 23:55 gpiochip0 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpiochip0
--w------- 1 root root 4096 Mar 16 23:55 unexport
michael@homie:~$ ls -l /sys/class/gpio/gpio231/
total 0
-rw-r--r-- 1 root root    4096 Mar 16 23:55 active_low
lrwxrwxrwx 1 root root       0 Mar 16 23:55 device -> ../../../1c20800.pinctrl
-rw-r--r-- 1 root root    4096 Mar 16 23:57 direction
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:57 edge
drwxr-xr-x 2 root root       0 Mar 16 23:55 power
lrwxrwxrwx 1 root root       0 Mar 16 23:55 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root    4096 Mar 16 23:55 uevent
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:55 value
michael@homie:~$ ls -l /sys/class/gpio/gpio239/
total 0
-rw-r--r-- 1 root root    4096 Mar 16 23:56 active_low
lrwxrwxrwx 1 root root       0 Mar 16 23:56 device -> ../../../1c20800.pinctrl
-rw-r--r-- 1 root root    4096 Mar 16 23:57 direction
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:57 edge
drwxr-xr-x 2 root root       0 Mar 16 23:56 power
lrwxrwxrwx 1 root root       0 Mar 16 23:56 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root    4096 Mar 16 23:56 uevent
-rw-r--r-- 1 fhem dialout 4096 Mar 16 23:55 value


....ich kann eigentlich keinen Unterschied erkennen...


Viele Grüße

Michael

[klausw]

Die Dateien edge und value sind durch fhem schreibbar.
Somit sollte RPI_GPIO auch darauf zugreifen können.
Ich kann keinen Fehler erkennen.
Nach dem shutdown restart haben edge und direction den korrekten Wert? direction sollte ja passen, da du mit F5 den wert korrekt aktualisieren kannst.
Evtl. bringt ein Verbose 5 (global) licht ins Dunkel.

Wird beim shutdown auch fhem komplett beendet? Nicht das noch irgendwelche Perl Fragmente die Except Funktion blockieren.

Wenn du WiringCB nutzt dann sollte es grundsätzlich auch ohne export der Pins im Startscript laufen.

[Punkt]

so....hab mal ein bissl rumprobiert...

kurz Vorweg: die GPIO exportiere ich seit ich WiringCB installiert habe nicht mehr im Start-Script..



zu edge und direction:

nach reboot

Code Auswählen Erweitern

michael@homie:/sys/class/gpio/gpio239$ cat edge
both
michael@homie:/sys/class/gpio/gpio239$ cat direction
in

nach shutdown restart

Code Auswählen Erweitern

michael@homie:/sys/class/gpio/gpio239$ cat edge
both
michael@homie:/sys/class/gpio/gpio239$ cat direction
in


nach shutdown ist auch kein Perl-Prozess mehr vorhanden...


Wenn ich folgenden Prozess einhalte dann funktioniert es:

- FHEM stoppen
- GPIO manuell unexportieren
- FHEM starten

Code Auswählen Erweitern

michael@homie:/sys/class/gpio$ sudo service fhem stop
Stopping fhem...
michael@homie:/sys/class/gpio$ sudo su
root@homie:/sys/class/gpio# echo "239" > unexport
root@homie:/sys/class/gpio# echo "231" > unexport
root@homie:/sys/class/gpio# ll
total 0
drwxr-xr-x  2 root root    0 Mar 17 20:41 .
drwxr-xr-x 53 root root    0 Mar 17 20:41 ..
--w-------  1 root root 4096 Mar 17 20:34 export
lrwxrwxrwx  1 root root    0 Mar 17 20:41 gpiochip0 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpiochip0
--w-------  1 root root 4096 Mar 17 20:41 unexport
root@homie:/sys/class/gpio# service fhem start


Was mich auch etwas verwundert hatte:
nach einem shutdown sind trotz "unexportpin = yes" alle GPIO vorhanden

Code Auswählen Erweitern

root@homie:/sys/class/gpio# ll
total 0
drwxr-xr-x  2 root root    0 Mar 17 20:46 .
drwxr-xr-x 53 root root    0 Mar 17 20:41 ..
--w-------  1 root root 4096 Mar 17 20:47 export
lrwxrwxrwx  1 root root    0 Mar 17 20:50 gpio231 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio231
lrwxrwxrwx  1 root root    0 Mar 17 20:50 gpio239 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpio239
lrwxrwxrwx  1 root root    0 Mar 17 20:41 gpiochip0 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpiochip0
--w-------  1 root root 4096 Mar 17 20:46 unexport


Ich versteh einfach noch nicht was beim shutdown restart anders läuft, was nötig macht daß ich die GPIO manuell unexportieren muss...


Verbose 5 bringt vermutlich auch nicht viel mehr erkenntnis denke ich.
Ich hab das mal laufen lassen - das Logfile sprengt danach alles....riesengroß...


Ich hab aber zum Test einfach mal alle Log-Befehle in der 51_RPI_GPIO.pm auf Verbose 1 umgeschrieben - das kann ich gerne mal hier anhängen - aber ich weis nicht ob da was zu finden ist...
Oder meinst du es könnte noch durch ein anderes Modul etwas zerschossen werden?

...Wenn gar nix hilft sichere ich meine Konfiguration einmal und lasse das ganze einfach mal mit einer absoluten Minimal-Konfiguration laufen....vielleicht bringt uns das weiter...?
Dann wäre das Log auch nicht so voll...


Viele Grüße

Michael

[Punkt]

Hallo Klaus,

...ich hab das jetzt mal mit ner Minimalkonfiguration probiert.

Beim reboot und beim shutdown restart gibts da keine Unterschiede im log... :-/

Was ich aber festgestellt habe:

WENN es funktioniert (also nach dem reboot) hab ich folgendes im Log (wenn ich den Interrupt auslöse):

Code Auswählen Erweitern

2016.03.17 21:10:56 4: WEB_192.168.0.80_53339 GET /fhem/icons/favicon; BUFLEN:0
2016.03.17 21:10:56 4: WEB_192.168.0.80_53337 GET /fhem?XHR=1&inform=type=status;filter=InterruptPI10;since=1458245455;fmt=JSON&fw_id=26×tamp=1458245457267; BUFLEN:0
2016.03.17 21:11:10 5: InterruptPI10, in fileaccess: edge
2016.03.17 21:11:10 5: Triggering InterruptPI10 (3 changes)
2016.03.17 21:11:10 5: Notify loop for InterruptPI10 Pinlevel: low
2016.03.17 21:11:10 5: InterruptPI10, in fileaccess: edge
2016.03.17 21:11:10 5: Triggering InterruptPI10 (3 changes)
2016.03.17 21:11:10 5: Notify loop for InterruptPI10 Pinlevel: low
2016.03.17 21:11:13 5: InterruptPI10, in fileaccess: edge
2016.03.17 21:11:13 5: Triggering InterruptPI10 (2 changes)
2016.03.17 21:11:13 5: Notify loop for InterruptPI10 Pinlevel: high
2016.03.17 21:11:14 5: InterruptPI10, in fileaccess: value
2016.03.17 21:11:14 5: Triggering InterruptPI10 (1 changes)
2016.03.17 21:11:14 5: Notify loop for InterruptPI10 Longpress: on
2016.03.17 21:11:27 4: Connection closed for WEB_192.168.0.68_60994: EOF
2016.03.17 21:11:27 4: Connection accepted from WEB_192.168.0.68_32770
2016.03.17 21:11:27 4: WEB_192.168.0.68_32770 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-03.log; BUFLEN:0
2016.03.17 21:11:28 4: Connection accepted from WEB_192.168.0.68_32771
2016.03.17 21:11:28 4: Connection accepted from WEB_192.168.0.68_32772


....wenn ich den Interrupt nach dem shutdown restart auslöse ist das nicht mehr im Log zu finden...


Viele Grüße

Michael

[klausw]

zu edge und direction:

nach reboot

Code Auswählen Erweitern

michael@homie:/sys/class/gpio/gpio239$ cat edge
both
michael@homie:/sys/class/gpio/gpio239$ cat direction
in

nach shutdown restart

Code Auswählen Erweitern

michael@homie:/sys/class/gpio/gpio239$ cat edge
both
michael@homie:/sys/class/gpio/gpio239$ cat direction
in


nach shutdown ist auch kein Perl-Prozess mehr vorhanden...

gut, alles wie es sein soll

Wenn ich folgenden Prozess einhalte dann funktioniert es:

- FHEM stoppen
- GPIO manuell unexportieren
- FHEM starten

Das ist ja auch der normale Prozess (GPIOs werden beim stoppen abgemeldet).
Im undefine sollte folgende Schleife ausgeführt werden:

Code Auswählen Erweitern

if ( ( AttrVal($hash->{NAME}, "interrupt", "none") ) ne ( "none" ) ) {
delete $selectlist{$hash->{NAME}};
close($hash->{filehandle});
}

Für die Interruptbehandlung wird für die value Datei ein filehandle angelegt über welches das die ExceptFN ausgelöst wird, wenn ein Interrupt auslöst. Dieses muss, wenn ich mich richtig erinnere gelöscht werden.
Du kannst Testweise in die Schleife ein Log reinbauen um zu sehen, ob sie ausgeführt wird.
Wenn das filehandle nicht gelöscht wird, kann es sein, das der Interrupt blockiert wird (beim unexport des GPIO verschwindet vermutlich auch ein noch bestehendes Filehandle).

Code Auswählen Erweitern

michael@homie:/sys/class/gpio$ sudo service fhem stop
Stopping fhem...
michael@homie:/sys/class/gpio$ sudo su
root@homie:/sys/class/gpio# echo "239" > unexport
root@homie:/sys/class/gpio# echo "231" > unexport
root@homie:/sys/class/gpio# ll
total 0
drwxr-xr-x  2 root root    0 Mar 17 20:41 .
drwxr-xr-x 53 root root    0 Mar 17 20:41 ..
--w-------  1 root root 4096 Mar 17 20:34 export
lrwxrwxrwx  1 root root    0 Mar 17 20:41 gpiochip0 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpiochip0
--w-------  1 root root 4096 Mar 17 20:41 unexport
root@homie:/sys/class/gpio# service fhem start


Was mich auch etwas verwundert hatte:
nach einem shutdown sind trotz "unexportpin = yes" alle GPIO vorhanden

das ist wirklich seltsam
ohne Attribut "unexportpin" oder mit "unexportpin = yes" sollten die GPIOs bei auch verschwinden.
WiringCB ist ja bei dir installiert und legt die GPIOs auch an wenn ich das richtig verstanden habe.
Ohne WiringCB gehts bei dir natürlich nicht, da export/unexport nur über root gehen.
Machst du den manuellen unexport über WiringCB?


Vielleicht komme ich am We mal zum testen. Es muss aber was mit dem Filehandle zu tun haben. Perl nutzt da irgendeinen Benachrichtigungsprozess vom System ... das ist leider schon bisschen her und ich habe einiges vergessen :-/


Das Log aus deinem letzten Post sagt einfach nur aus, das der Interrupt läuft, wenn diese Meldungen fehlen dann halt nicht

[Punkt]

Im undefine sollte folgende Schleife ausgeführt werden:

Code Auswählen Erweitern

if ( ( AttrVal($hash->{NAME}, "interrupt", "none") ) ne ( "none" ) ) {
delete $selectlist{$hash->{NAME}};
close($hash->{filehandle});
}

äh.....dazu kurze Frage:

im sub RPI_GPIO_Undef ist ja schon ein Log-Eintrag drin:

Code Auswählen Erweitern

Log3 $hash, 1, "$hash->{NAME}: entfernt";

...der sollte ja immer geschrieben werden wenn ich das richtig verstehe.


...wenn ich aber mein gesamtes Logfile durchsuche finde ich den String "entfernt" überhaupt nicht. 

Heist das das Undefine wird gar nicht durchlaufen???
Standardmäßig hab ich verbose 3 eingestellt....die Zeile sollte ja sogar bei verbos 1 geschrieben werden, oder?


Viele Grüße

Michael

[klausw]

äh.....dazu kurze Frage:

im sub RPI_GPIO_Undef ist ja schon ein Log-Eintrag drin:

Code Auswählen Erweitern

Log3 $hash, 1, "$hash->{NAME}: entfernt";

...der sollte ja immer geschrieben werden wenn ich das richtig verstehe.


...wenn ich aber mein gesamtes Logfile durchsuche finde ich den String "entfernt" überhaupt nicht. 

Heist das das Undefine wird gar nicht durchlaufen???
Standardmäßig hab ich verbose 3 eingestellt....die Zeile sollte ja sogar bei verbos 1 geschrieben werden, oder?

Äh ja, was weich ich, ich ... muss gehen 

Wenn ich mich richtig erinnere kam das unexportpin Attribut genau aus diesem Grund rein: beim shutdown werden die GPIOs unexportiert und wenn man die vorher über ein script angelegt und Schreibrechte für alle vergeben hat dann sägte man sich den Ast ab.

und ja

Code Auswählen Erweitern

Log3 $hash, 1, "$hash->{NAME}: entfernt";
sollte IMMER ausgeführt werden, wenn unexport aufgerufen wird.

Ich weiss gerade nicht weiter
Bei mir (RPI mit Jessie) werden die GPIOs beim Shutdown auch nicht unexportiert. Aber die Interrupts laufen nach einem Start trotzdem wieder

[Punkt]

...hab mir grade mal als Beispiel das DBLog-Modul angeschaut....

...da gibts ne Funktion "DbLog_Shutdown"...

Kann es sein daß es da an dem Framework irgendwie eine Änderung gegeben hat und man dafür jetzt eine Shutdown-Routine einbauen muss? 


Viele Grüße

Michael

[Punkt]

so...noch ein paar Log-Einträge in DBLog beim Undef und beim Shutdown gemacht - aber die stehen auch nicht im Log...
Bin nicht sicher ob das korrekt geloggt wird....ich steh momentan ein bissl aufm Schlauch...


VG
Michael

[Punkt]

stop....Kommando zurück...

Die Shutdown-Methode wird doch durchlaufen - nur die Undef nicht...

[Punkt]

das wars....! 

zum Test folgendes eingefügt im Definitions-Teil des Moduls:

Code Auswählen Erweitern

       $hash->{ShutdownFn} = "RPI_GPIO_Undef";


....und Tadaaaa....es funktioniert! 

...da soll mal einer drauf kommen... 

[klausw]

das wars....! 

zum Test folgendes eingefügt im Definitions-Teil des Moduls:

Code Auswählen Erweitern

       $hash->{ShutdownFn} = "RPI_GPIO_Undef";


....und Tadaaaa....es funktioniert! 

...da soll mal einer drauf kommen... 

Super, warum nicht gleich so 

Ich habe ne weile die developer threads nur mäßig verfolgt, kann sein, das sich an dieser Stelle was geändert hat.
Die eine Zeile kann ich durchaus noch einbauen
Oder ich baue eine neue Funktion, damit Outputs bei shutdown/restart nicht angefasst werden und somit nix flackert.
Es ist trotzdem komisch, das beim Pi der Interrupt nach FHEM Neustart noch läuft und beim Cubie nicht mehr.

[wthiess]

Hallo!

Leider schaffe ich nicht den "Input"
Ich habe auf A0 einen Taster gegen GND. Leider keine Reaktion.
Die Ausgänge funktionieren. Kann alle Relais schalten.
Hier mein Fhem.cfg

#I2C
define i2c RPII2C 1
attr i2c alias Onboard I2C Controller 1
attr i2c room ops

define i2c20 I2C_MCP23017 0x20
attr i2c20 IODev i2c
attr i2c20 Interrupt A0,A1,A2,A3,A4,A5,A6,A7
attr i2c20 InterruptOut separate_active-low
attr i2c20 OutputPorts B0,B1,B2,B3,B4,B5,B6,B7
attr i2c20 Pullup A0,A1,A2,A3,A4,A5,A6,A7
attr i2c20 invert_input A0,A1,A2,A3,A4,A5,A6,A7
attr i2c20 room ops

define int RPI_GPIO 20
attr int active_low yes
attr int direction input
attr int interrupt both
attr int pud_resistor up
attr int userReadings get_i2c20 {fhem ("get i2c20")}

#relais1
define relais1 readingsProxy i2c20:PortB1
attr relais1 alias Relais 1 (In1)
attr relais1 devStateIcon on:on:off off:off:on
attr relais1 room ops
attr relais1 setFn {($CMD eq "on")?"PortB1 off":"PortB1 on"}
attr relais1 setList on off
attr relais1 valueFn {($VALUE eq "on")?"off":"on"}

#Relais0 über Taster schalten
define relais0 readingsProxy i2c20:PortB0
attr relais0 alias Relais 0 (In1)
attr relais0 devStateIcon on:on:off off:off:on
attr relais0 room ops
attr relais0 setFn {($CMD eq "on")?"PortB0 off":"PortB0 on"}
attr relais0 setList on off
attr relais0 valueFn {($VALUE eq "on")?"off":"on"}

define i2c20pA0 readingsProxy i2c20:PortA0
attr i2c20pA0 alias Taster A0
attr i2c20pA0 room ops
attr i2c20pA0 valueFn { if ($VALUE eq "on") { fhem "set relais0 toggle" } }

Bitte um Hilfe

lg
Wolfgang

[klausw]

Hallo Wolfgang,

die Konfiguration macht einen guten Eindruck.
Ändert sich der Status von A0 denn, wenn du bei gedrücktem Taster den i2c20 mit get aktualisierst?
Gibt es Meldungen zum genutzten GPIO im Log?

Grüße
Klaus