GPIO über i2c interrupt triggern und Inputs in FHEM immer aktuell anzeigen

Begonnen von f.f, 03 September 2017, 12:01:04

Vorheriges Thema - Nächstes Thema

f.f

Hallo,

ich bin gerade dabei meine Hausautomatisation zu restaurieren und moechte das mit FHEM machen.
Dank einiger Tipps hier habe ich es schon geschafft ein py skript mit FHEM schalter zu triggern, dass mir einen Boardeigenen GPIO des RASPI schaltet.
Da ich ca. 50 Ausgänge (und Eingänge) brauche habe ich mir ein i2c 128i/o bestellt. Das Board kam gestern und ich hab schon einmal ein bischen experimentiert, so dass ich auch hier mit python die 128 einzelne PINS setzen/lesen kann.
Ich wäre also schon mal in der Lage meine 50 out pins via py.script und 50 Fhem Schaltern zu schalten.

Jetzt suche ich nach einer passenden Lösung die Inputs (möglichst in Realtime) in Fhem zu visualisieren. Nach einigem Stöbern hier, bin ich deshalb auch schon einige Male über das modul RPI_GPIO gestollpert. Das Modul könnte ja über interrupt genau das liefern was ich will, also eine Realtimevisualisierung eines GPIO Ereignisses.

Nun mein Problem: Das 128 io modul hat 8 23017er Chips mit je 16 /i/o verbaut und jeder Chip hat zwei Interrupt Ausgänge für je 8 seiner Kanäle. Mein Plan war nun folgender: Ich benötige 4 der chips für Eingänge, müsste also 8  Interrupt Ausgänge der Erweiterungsplatine auf 8 GPIO des PI Brücken. Damit könnte ich über python und callback/interunpt die 8 PI Eingänge überwachen, und im Falle eines Ereignisses die zugehörigen 8 Kanäle auf dem 23017 auslesen.
Damit hätte ich in Python eigentlich was ich wollte, nämlich einen Monitor der 64 Kanäle ohne pollen zu müssen. 

Die Frage ist getzt nur, wie bekomme ich das in Fhem gelöst ?? Für ideen wäre ich euch sehr dankbar.

Gruss
Frank

klausw

Zitat von: f.f am 03 September 2017, 12:01:04
Nun mein Problem: Das 128 io modul hat 8 23017er Chips mit je 16 /i/o verbaut und jeder Chip hat zwei Interrupt Ausgänge für je 8 seiner Kanäle. Mein Plan war nun folgender: Ich benötige 4 der chips für Eingänge, müsste also 8  Interrupt Ausgänge der Erweiterungsplatine auf 8 GPIO des PI Brücken. Damit könnte ich über python und callback/interunpt die 8 PI Eingänge überwachen, und im Falle eines Ereignisses die zugehörigen 8 Kanäle auf dem 23017 auslesen.
Damit hätte ich in Python eigentlich was ich wollte, nämlich einen Monitor der 64 Kanäle ohne pollen zu müssen. 

Die Frage ist getzt nur, wie bekomme ich das in Fhem gelöst ?? Für ideen wäre ich euch sehr dankbar.

- I2C_MCP23017 Devices in FHEM konfigurieren (8 Stück)
- Bei den Input Devices das Attribut InterruptOut auf "connected_..." setzen (dann benötigst du nur einen Interrupt Ausgang pro Chip)
  Wenn du "connected_open-drain" verwendest könntest du sogar alle Ausgänge zusammenschalten (in diesem Fall wird ein Pullup benötigt)
- Weiterhin natürlich die Input Ports über das Attribut "Interrupt" interruptfähig machen
- Den oder die Interrupt Ausgänge mit Raspberry GPIOs verbinden
- Für jeden GPIO ein RPI_GPIO Device anlegen, Attribut "interrupt" setzen (ich würde falling bei connected_open-drain verwenden, da in diesem Fall nur bei einer fallenden Flanke ein Interrupt ausgelöst wird)
- nun ein notify Device anlegen, das auf Events im RPI_GPIO reagiert und in diesem Fall die MCP23017 ausliest.

Wenn du hier im Forum nach MCP23017 suchst findest du auch fertige Codevorschläge
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

f.f

Danke für die schnelle Hilfe

Ich hab das mal so begonnen wie Du das Empfohle hast. Ich hab mir auch einmal das Perl Script zum Modul angeschaut (man will ja nicht ganz dumm nur kopieren und einfügen..)
Leider komme ich aus der Ecke C++/VB und somit sieht Perl noch etwas "kryptisch" aus, aber ich arbeite mich da wohl ein damit ich letztlich mit FHem, auch alles machen kann was ich mir vorstelle.

Ich habe also zum Test einmal 2 MCP devices erstellt, und den einen Chip komplett als Output und den anderen Komplett als Eingang konfiguriert. Das Schalten funktionierte auf anhieb aber beim Input hab ich noch meine Probleme und zwar erstmal diirelkt am MCP (die Interupts habe ich zwar schon mit dem PI verkablet aber es geht hier erstmal nicht ums triggern sondern um ein Verständnisproblem)
Zum testen der Inputs auf dem MCP habe ich einen der Ausgänge des anderen auf einen INput gelegt. Schalte ich den Output ohne Verbindung, schaltzet der Chip einwandfrei und ich bekomme in den Readings auch ein stabiles ON angezeigt. Mit Verbindung schaltet der Ausgang kurz ein, geht aber gleich wieder auf OFF. Das versteh ich nicht so ganz....
Ich habe keine internen Pull Widerstände aktiviert, der Input "floated" also irgendwo herum aber das sollte doch völlig egal sein, oder? Soblad der OUt des erstem MCP auf high geht, zieht der den IN PIN doch mit hoch. Für mich sieht das so aus, als ob der IN den level vom OUT runterzieht (und der deshalb auf OFF geht??). Das würde doch aber keinen SInn machen, denn das würde ja nur gehen, wenn der IN zuviel Strom zieht, und das sollte ja wohl nicht sein?

Weiterhin ist es mir etwas rätselhaft, wieso die Ausgänge der MCP nur 3,3V an den Ausgängen liefern? Ist das bei euch auch so? (ISt eine Multi MCP Platine von Pridopia). Lt. Datenblatt sollte der 23017 doch 0.8*Vdd bringen und das wären 4V. Ich befürchte nämlich die 3,3V könnten evtl. grenzwertig für meine berstellten Relaisplatinen werden....

Dann hätte ich noch zwei grundsätzliche Frage zur Programmierung in Perl und Fhem-Einbindung:

- gibt es einen einfachen Trick, damit ein Drücken eines Schalters in FHEM als Taster auf den physikalischen Ausgang wirkt, also einen Konfigurierten Ausgang eins MCP nur kurz durchsteuert (und kann man die Impulsdauer irgendwie festlegen?)   

- Welche Möglichkeit habe ich eine Variable zwischen verschiedenen Modulen hin und her zu schieben?
Hintergrund: Ich steuere über meine Taster parallel meine SPSs (und das soll weiterhin parallel laufen). Die steuern dann z.B div. Dimmer und auch die Rolläden. Deshalb will ich ja mit den Outputs der SPS auf die Eingeänge der MCP. Wenn jemand per Taster (zeit...) die Rolläden und Dimmer betätigt, hätte ich gerne dass eine (mehrere) dauerhafte Variablen in FHEM die kummulierte Tastzeit der einzelnen Taster speichern. Ich denke, wenn die Zeitwerfassung schnell genug reagiert, sollte man so recht vernünftig immer die aktuellen Zustände der Aktoren/Rolläden/Dimmer kennen
Wie kann ich sowas am besten implementieren?         
 
Gruss

klausw

Zitat von: f.f am 06 September 2017, 08:54:00

Ich habe also zum Test einmal 2 MCP devices erstellt, und den einen Chip komplett als Output und den anderen Komplett als Eingang konfiguriert.
Das würde ich auch grundsätzlich so machen. Mischst du beides dann müssen im Regelfall mehr INT Ausgänge verdrahtet werden.
Zitat von: f.f am 06 September 2017, 08:54:00
Das Schalten funktionierte auf anhieb aber beim Input hab ich noch meine Probleme und zwar erstmal diirelkt am MCP (die Interupts habe ich zwar schon mit dem PI verkablet aber es geht hier erstmal nicht ums triggern sondern um ein Verständnisproblem)
Zum testen der Inputs auf dem MCP habe ich einen der Ausgänge des anderen auf einen INput gelegt. Schalte ich den Output ohne Verbindung, schaltzet der Chip einwandfrei und ich bekomme in den Readings auch ein stabiles ON angezeigt. Mit Verbindung schaltet der Ausgang kurz ein, geht aber gleich wieder auf OFF. Das versteh ich nicht so ganz....
Ich habe keine internen Pull Widerstände aktiviert, der Input "floated" also irgendwo herum aber das sollte doch völlig egal sein, oder? Soblad der OUt des erstem MCP auf high geht, zieht der den IN PIN doch mit hoch. Für mich sieht das so aus, als ob der IN den level vom OUT runterzieht (und der deshalb auf OFF geht??). Das würde doch aber keinen SInn machen, denn das würde ja nur gehen, wenn der IN zuviel Strom zieht, und das sollte ja wohl nicht sein?
Du hast Recht, das Verhalten ist seltsam. Selbst die Ports eines unkonfigurierten MCP23017 ist nach dem einschalten als Inputs definiert.
Dein Code wäre hilfreicht zu verstehen, was Du machst  8)
Funktionieren die Ausgänge denn, wenn Du nichts angeschlossen hast?
Haben die beiden MCP23017 eine unterschiedliche I2C Adresse?
Zitat von: f.f am 06 September 2017, 08:54:00
Weiterhin ist es mir etwas rätselhaft, wieso die Ausgänge der MCP nur 3,3V an den Ausgängen liefern? Ist das bei euch auch so? (ISt eine Multi MCP Platine von Pridopia). Lt. Datenblatt sollte der 23017 doch 0.8*Vdd bringen und das wären 4V. Ich befürchte nämlich die 3,3V könnten evtl. grenzwertig für meine berstellten Relaisplatinen werden....
0.8*Vdd ist doch das Minimum, oder?
Hast du die Vdd am MCP direkt gemessen?
Worüber wird die Platine versorgt?
Achtung, bei ICs mit 5V Versorgung sollten keine weiteren Pullups als die auf dem Pi am I2C sein. Der Pi ist nur 3,3V tolerant.
Für gewöhnlich kann er bei kurzen Anschlüssen trotzdem 5V ICs ansteuern (ist halt nicht die elegenteste Lösung)
Zitat von: f.f am 06 September 2017, 08:54:00
Dann hätte ich noch zwei grundsätzliche Frage zur Programmierung in Perl und Fhem-Einbindung:

- gibt es einen einfachen Trick, damit ein Drücken eines Schalters in FHEM als Taster auf den physikalischen Ausgang wirkt, also einen Konfigurierten Ausgang eins MCP nur kurz durchsteuert (und kann man die Impulsdauer irgendwie festlegen?)   
Meinst du einen Schalter in der Weboberfläche?
Mit dem Modul readingsProxy kannst du für jeden einzelnen Port des MCP einen Schalter in der Oberfläche erstellen.
Dieser kann dann auch mit Aktionen wie on-for-timer den Ausgang kurz schalten und so als Taster agieren. Die Pulsdauer kannst du definieren. Aber eher im Sekundenbereich.
Das gleiche geht auch über einen physikalischen Schalter. In diesem Fall kannst du es über ein notiy lösen, welches den oben beschriebenen readingsProxy ansteuert.

Zitat von: f.f am 06 September 2017, 08:54:00
- Welche Möglichkeit habe ich eine Variable zwischen verschiedenen Modulen hin und her zu schieben?
Hintergrund: Ich steuere über meine Taster parallel meine SPSs (und das soll weiterhin parallel laufen). Die steuern dann z.B div. Dimmer und auch die Rolläden. Deshalb will ich ja mit den Outputs der SPS auf die Eingeänge der MCP. Wenn jemand per Taster (zeit...) die Rolläden und Dimmer betätigt, hätte ich gerne dass eine (mehrere) dauerhafte Variablen in FHEM die kummulierte Tastzeit der einzelnen Taster speichern. Ich denke, wenn die Zeitwerfassung schnell genug reagiert, sollte man so recht vernünftig immer die aktuellen Zustände der Aktoren/Rolläden/Dimmer kennen
Wie kann ich sowas am besten implementieren?         
Wenn ich es richtig verstanden habe, willst du FHEM nur für die Visualisierung nutzen?
Die "Variablen" lassen sich alse readings in dummy Devices speichern.
Für jeden Dimmer, Rolladen, etc. kannst du ein eigenes dummy Device anlegen und darin die Zustände ablegen.
Wenn ein Taster gedrückt wird reagierst du mit einem notify darauf und speicherst den Zeitpunkt im dummy.
Beim loslassen des Tasters ziehst du im notify die aktuelle Zeit von der gespeicherten ab und kannst sie weiterverarbeiten.
notify Devices lassen sich so einstellen, das sie auf definierte Änderungen von Readings eines beliebigen Devices reagieren und selbst definierten Perl Code ausführen.

Aber ich würde empfehlen das ganze Stück für Dtüch aufzubauen .. ist ja doch etwas komplexes was Du Dir wünschst.
Bemerkt sei nur, das Perl und damit FHEM nicht durch Echtzeitfähigkeit glänzt. Im ms Bereich kannst du nix gescheites messen.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

f.f

hi,

ja, da ich plane 4 chips rein für Output und 4 rein für Input zu nutzen habe ich die 32 (0x20) als ersten Chip auf der Platine zum reinen OUT gemacht und den 5  (also die 36) zum reinen INPUT.
Die OUT auf 0x20 funktionieren alle. (high=3,3V). Schalte ich über FHEM ein/aus, werden danach auch in den Readings des CHips die entsprechenden POrts als ON/OFF gelistet.
Brücke ich zum Testen einzelne Inputs auf 0x24 direkt mit 5V von der Versorung hoch, bekomme ich in FHEM auch die Readings Korrekt.
Wenn ich aber einen OUT von 0x20 auf eine in von 0x24 Brücke und den out auf ON schalte, geht der in den Readings kurz auf ON, aber dann gleich wieder auf OFF. Ob der INPUT in der Zeit überhaupt mal einen Status ON hatte weiss ich nicht (das geht zu schnell).

0.8*Vdd ist lt. Datenblatt für den h-pegel das Minimum, das er als Input braucht zum . Ich habe PI und Erweiterungsplatine über 5V Netzteil (das ist stabil auf 5V, habs gemessen) 
M.E. sollte es aber doch unproblematisch sein die INTA und INTB direkt mit den GPIO des RASPI zu koppeln, oder? Gemessen liefern die RASPI outs ca. 3,3V, der 23017 ja offenbar auch nur 3,3V, da sollte doch eigentlich nichts passieren.

über das wort "Readingsproxy" bin ich beim Stöbern schon hier und da gestollpert :-), allerdings hab ich noch keine Idee was ich damit wie in dem Zusammenhang machen kann.

Ich werde versuchen das Problem Stück für Stück zu lösen und deshalb erstmal versuchen die i2c inputs stabil hinzubekommen und zu verstehen.
Mein Gesamtsystem ist relativ komplex, aber ich denke wenn ich mir hier mal durchbeisse, wirds dann später mit den "exotischen" Sachen leichter.
Ich will nicht nur visualisieren, sondern auch schalten und regeln. Als ich mein Haus gebaut habe, hab ich die ganzen Brennstellen und Schalter in den Kasten geführt und an 4 erweiterete Mitsubishi AL2 SPS angeschlossen. Das ganze hängt an einem 4-fach seriell port server. Mein Plan war damals damit eine günstige und individuelle Lösung zu realisieren.  Eine Rolladensteuerung habe ich zum Einzug dann gerade noch auf die Schnelle damit gebacken bekommen aber für alles andere waren dann immer diverse andere Baustellen wichtigen. D.h. ich habe die SPS, außer für die Jalousien, nur als Stromstossschalter  durchkonfiguriert, bzw. für ein paar Hutschienendimmer die später hinzukamen den Eingang einfach durchgeschleift.
Jetzt hab ich endlich ein bischen Zeit aber die Lösung mit dem serialport server scheitert im wesentlichen an vernünftigen (virtuellen) Treibern für den serial portserver.
Deshalb mein Plan: ich lass alles so wie es ist (denn es funktioniert ja) und bastele mir eine Visualisierung und Steuerung die parallel läuft. Ich gehe also mit den 64 out der 4 MCP auf 4 billige China Relaisplatinen und hänge die parallel zu den Tastern in die Eingänge der 4 SPS. Damit könnte ich ja dann über FHEM alles Schalten - allerdings ohne jegliche Rückmeldung. Um die zu bekommen werde ich die Ausgänge der SPS (24V) über Spannungsteiler in die 4 MCP schleifen, die ich als Input laufen lasse. so mein Plan.......             

klausw

Zitat von: f.f am 06 September 2017, 13:45:36
ja, da ich plane 4 chips rein für Output und 4 rein für Input zu nutzen habe ich die 32 (0x20) als ersten Chip auf der Platine zum reinen OUT gemacht und den 5  (also die 36) zum reinen INPUT.
Die OUT auf 0x20 funktionieren alle. (high=3,3V). Schalte ich über FHEM ein/aus, werden danach auch in den Readings des CHips die entsprechenden POrts als ON/OFF gelistet.
Brücke ich zum Testen einzelne Inputs auf 0x24 direkt mit 5V von der Versorung hoch, bekomme ich in FHEM auch die Readings Korrekt.
Wenn ich aber einen OUT von 0x20 auf eine in von 0x24 Brücke und den out auf ON schalte, geht der in den Readings kurz auf ON, aber dann gleich wieder auf OFF. Ob der INPUT in der Zeit überhaupt mal einen Status ON hatte weiss ich nicht (das geht zu schnell).
Das ist ein recht seltsames Verhalten. Evtl. steht im Log was drin (mit Verbose 5).
- Hast Du am 0x20 Baustein auch die entsprechenden elektrischen Pegel anliegen? Oder schaust Du nur auf die Weboberfläche?
- Du verwendest noch keinen Interrupt. Liest du Baustein 0x24 per Seitenrefresh aus?
- Ändert sich an den Pegeln an 0x20 etwas, wenn Du Baustein 0x24 ausliest?
- Ändert sich an den Pegeln an 0x20 etwas, wenn Du an Baustein 0x24 einige Ports auf 5V legst und dann ausliest?

Zitat von: f.f am 06 September 2017, 13:45:36

M.E. sollte es aber doch unproblematisch sein die INTA und INTB direkt mit den GPIO des RASPI zu koppeln, oder? Gemessen liefern die RASPI outs ca. 3,3V, der 23017 ja offenbar auch nur 3,3V, da sollte doch eigentlich nichts passieren.
Wie gesagt:

InterruptOut -> connected_open-drain (INTA/INTB outputs are internally connected and open drain)
Dann muss nur INTA mit dem Raspi verbunden werden (+ Pullup auf 3,3V)

Zitat von: f.f am 06 September 2017, 13:45:36

über das wort "Readingsproxy" bin ich beim Stöbern schon hier und da gestollpert :-), allerdings hab ich noch keine Idee was ich damit wie in dem Zusammenhang machen kann.
Der MCP23017 hat 16 Ports welche alle in einem Device dargestellt werden.
Mit readingsProxy kannst du jeden Port als separates Device erstellen (Das ist für die Weboberfläche z.B. sehr praktisch).

defmod Bild readingsProxy MCP32:PortA3
attr Bild setFn {$READING . " " .$CMD}
attr Bild setList on off
attr Bild webCmd :


Dieses Beispiel legt ein Device an, das den Zustand von Reading PortA3 des Devices MCP32 widerspiegelt.
Schaltest du "Bild" auf "on" so wird nach der setFn im Beispiel "set MCP32 PortA3 on" ausgelöst.
In der Wiki müssten auch paar Beispiele sein.

Zitat von: f.f am 06 September 2017, 13:45:36


Ich werde versuchen das Problem Stück für Stück zu lösen und deshalb erstmal versuchen die i2c inputs stabil hinzubekommen und zu verstehen.
Mein Gesamtsystem ist relativ komplex, aber ich denke wenn ich mir hier mal durchbeisse, wirds dann später mit den "exotischen" Sachen leichter.
Das wird mit Sicherheit so sein, ist alles kein Hexenwerk ;)
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

f.f

vielen Dank für deine Mühe.
Ich bin gestern Abend noch etwas verzweifelt und habe dann die Sache nochmal von vorne aufgerollt. Der Fehler lag offenbar in einem Kabel mit zeitweisem Kontaktproblem b zw. Übergangswiderstand. Kleine Ursache große wirkung....jedenfalls hatte ich gestern auch schon getriggerte Inputs angezeigt, danke für deine perfekt auf den Punkt gebarachte Hilfe.

Das mit der Tastzeitregistrierung ist mir aber noch etwas unklar.
Habe ich dich richtig vertsanden: Wenn ich einen interupt auf dem 23017 mit dem GPIO abfange rufe ich via notfiy einen Dummy auf und speichere den Zeitstempel (im Dummy??, wo?) und den aufrufenden Taster/Input (wo?)
Wird ein weiterer interupt ausgelöst, prüfe ich, ob es der entsprechende Schalter war bzw.ob dieser nun wieder OFF ist und rechne mir daraus die Laufzeit aus?
Ist das so in etwa der plan?

Gibt es keine Möglichkeit mir eine globale Variable direkt im Hauptmodul deklarieren zu lassen, auf die ich dann von allen Sub Routinen referenzieren kann?.
Ich muss ja schon ein paar zeilen Code schreiben, die die relativ komplexe Rolladensteuerung auch richtig auf das "Laufzeitkonto" hinzurechnet oder abzieht. Dann ist das ganze, ja nur ein "Schätzeisen", d.h. man müsste bei erkennen einer völligen Auf- und Zufahrt der Jalousie auch noch die zeitlich errechnete Position resetten um das ganze auf dauer praktikabel zu machen.
Dazu wäre es natürlich perfekt, wenn ich einfach anstatt eines Dummy eine eigene Subroutine aufrufen könnte, die das alles übernimmt and letztlich an die device Rolladen eine Ist-Position übergibt. Leider fehlt mir hier noch das Gespür für die Möglichkeiten in und mit Perl und wie ich das ganze in Fhem integriere.

Gruss     

Beta-User

Schau dir zu dem Rolladen-Thema mal das ROLLO-Modul an.
https://wiki.fhem.de/wiki/ROLLO
Könnte sein, dass du dir damit einiges an Arbeit ersparen kannst.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

klausw

Zitat von: f.f am 07 September 2017, 07:37:11
....jedenfalls hatte ich gestern auch schon getriggerte Inputs angezeigt, danke für deine perfekt auf den Punkt gebarachte Hilfe.
Gern, ich bin eher froh, das du keinen Bug gefunden hast  8)

Zitat von: f.f am 07 September 2017, 07:37:11
Das mit der Tastzeitregistrierung ist mir aber noch etwas unklar.
Habe ich dich richtig vertsanden: Wenn ich einen interupt auf dem 23017 mit dem GPIO abfange rufe ich via notfiy einen Dummy auf und speichere den Zeitstempel (im Dummy??, wo?) und den aufrufenden Taster/Input (wo?)
Der dummy ist nur ein Vorschlag zur besseren Übersicht (du kannst es auch als neues Reading im MCP23017 Device oder im readingsProxy mit speichern).
Du kannst neben den existierenden Readins in den Modulen beliebig viele weitere anlegen.
Einen Zeitstempel bekommst du mit:
my $ts = ReadingsTimestamp("$NAME","state",0);
Diesen kannst du speichern wo du magst.
mit "set NAME $ts" in den STATE eines Devices
mit "setreading NAME READINGNAME $ts" in ein beliebiges Reading

Zitat von: f.f am 07 September 2017, 07:37:11
Wird ein weiterer interupt ausgelöst, prüfe ich, ob es der entsprechende Schalter war bzw.ob dieser nun wieder OFF ist und rechne mir daraus die Laufzeit aus?
Ist das so in etwa der plan?
genau
alten Zeitstempel mit
my $ts = ReadingsVal("NAME","READINGNAME",0); holen und rechnen.

Zitat von: f.f am 07 September 2017, 07:37:11
Gibt es keine Möglichkeit mir eine globale Variable direkt im Hauptmodul deklarieren zu lassen, auf die ich dann von allen Sub Routinen referenzieren kann?.
Ich muss ja schon ein paar zeilen Code schreiben, die die relativ komplexe Rolladensteuerung auch richtig auf das "Laufzeitkonto" hinzurechnet oder abzieht. Dann ist das ganze, ja nur ein "Schätzeisen", d.h. man müsste bei erkennen einer völligen Auf- und Zufahrt der Jalousie auch noch die zeitlich errechnete Position resetten um das ganze auf dauer praktikabel zu machen.
Mit Hauptmodul meinst du FHEM? Das würde ich lassen da sich die Auswirkungen schlecht abschätzen lassen.
Falls du dein MCP Modul meinst so ist das möglich.. siehe oben.
Code der mehrfach verwendet werden soll kann in einer 99_myUtils.pm abgelegt werden. Beispiel ist die myUtilsTemplate.pm

Zitat von: f.f am 07 September 2017, 07:37:11
Dazu wäre es natürlich perfekt, wenn ich einfach anstatt eines Dummy eine eigene Subroutine aufrufen könnte, die das alles übernimmt and letztlich an die device Rolladen eine Ist-Position übergibt. Leider fehlt mir hier noch das Gespür für die Möglichkeiten in und mit Perl und wie ich das ganze in Fhem integriere.
da ist der Tip von Beta-User sicherlich Gold wert. Ich persönlich kenne das Modul nicht.

RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Beta-User

Was die Visualisierung in FHEM angeht:
So wie ich das verstanden habe, sollen - neben den Rolläden, die noch komplexer zu sein scheinen - auch immer z.B. ein Lichttaster und der Status eines Lichts miteinander gekoppelt werden, also beim Drücken der Anzeige des Status von Gerät_1 (Lichtsensoreingang) das Gerät_2 (Toggle-impuls oder 24V on/off) geschaltet werden soll. Das geht - jedenfalls nach meiner Erfahrung - nicht so gut mit readingsProxy, da ist eine readingsGroup besser (auch für ein solches logisches Gesamtgerät, das nur aus einem Status und einem Schalter/Taster besteht).

Vielleicht ein hilfreiches Beispiel dazu: https://forum.fhem.de/index.php/topic,75020.msg668780.html#msg668780

(Ich hoffe, mich einigermaßen verständlich ausgedrückt zu haben).

Gruß und viel Erfolg damit,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jorge

Ich möchte den Interrupt vom MCP23008 für A0,A1 und A2 mit GPIO 18 abfangen und habe in fhem Folgendes eingerichtet:

Internals:
   DEF        0x20
   I2C_Address 32
   IODev      RPII2C
   NAME       MCP23008
   NR         26
   RPII2C_SENDSTAT Ok
   STATE      Ok
   TYPE       I2C_MCP23008
   Readings:
     2018-06-22 12:18:08   PortA0          off
     2018-06-22 12:18:08   PortA1          off
     2018-06-22 12:18:08   PortA2          off
     2018-06-18 18:17:30   PortA3          off
     2018-06-22 13:34:31   PortA4          on
     2018-06-22 11:50:14   PortA5          off
     2018-06-17 21:25:46   PortA6          off
     2018-06-17 21:25:46   PortA7          off
     2018-06-22 13:34:32   state           Ok
Attributes:
   IODev      RPII2C
   Interrupt  A0,A1,A2
   InterruptOut separate_open-drain
   OutputPorts A4,A5,A6
   room       I2C

Internals:
   DEF        18
   EXCEPT_FD  15
   GPIO_Basedir /sys/class/gpio
   NAME       GPIO18
   NR         28
   RPI_pin    18
   STATE      off
   TYPE       RPI_GPIO
   WiringPi_gpio /usr/local/bin/gpio
   lasttrg    1529666987.83224
   Readings:
     2018-06-22 13:29:47   Counter         2909
     2018-06-22 12:51:41   Dblclick        off
     2018-06-22 13:38:15   Pinlevel        low
     2018-06-22 13:29:47   Toggle          on
     2018-06-22 13:29:47   state           off
   Fhem:
     interfaces switch
Attributes:
   comment    Interup MCP23008
   direction  input
   interrupt  falling
   pud_resistor up
   room       GPIO,I2C




Wenn ich jetzt z.B. einen taster an A0 drücke, geht GPIO18 auf 'low' und es wird ein Reading erzeugt. Soweit o.k. Aber leider bleibt dieser Status auch nach Loslassen der Taste so erhalten und ein wiederholter Tastendruck löst kein Reading mehr aus, erst nachdem fhem neu gestartet wird. Gibts dafür ein Lösung oder ist meine Hardware defekt?

LG
Jorge
FHEM.RaspberryPi 2 (HM, 1Wire, Callmonitor.FB 7490, GPIO, I2C, MQTT-Server, MCP23018)
FHEM.RaspberryPi  (FHEM2FHEM, CUL, FS20)
FHEM.RPiZeroW (I2C, 1Wire, python.api, XiaomiBTLESens.MQTT)
FHEM.Win7 (FHEM2FHEM,DBLOG.MySql)
ESPEasy (WEMOSD1, I2C, Analog, 1Wire), Sonoff_T1_3ch, Mobotix QM25, robonect

klausw



Zitat von: jorge am 22 Juni 2018, 13:49:27
Wenn ich jetzt z.B. einen taster an A0 drücke, geht GPIO18 auf 'low' und es wird ein Reading erzeugt. Soweit o.k. Aber leider bleibt dieser Status auch nach Loslassen der Taste so erhalten und ein wiederholter Tastendruck löst kein Reading mehr aus, erst nachdem fhem neu gestartet wird. Gibts dafür ein Lösung oder ist meine Hardware defekt?

Klingt so, als funktioniert es wie es soll.
Interrupt auf falling bedeutet, das nur bei fallender Flanke getriggert wird.
Demzufolge wird sich das Reading nicht ändern.
Aber es wird ein Event ausgelöst. Bei jedem erzeugen Interrupt müsste sich der Zeitstempel ändern.
Darauf kannst du mit einem notify reagieren.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

jorge

Zitat von: klausw am 22 Juni 2018, 15:22:10

Klingt so, als funktioniert es wie es soll.
Interrupt auf falling bedeutet, das nur bei fallender Flanke getriggert wird.
Demzufolge wird sich das Reading nicht ändern.
Aber es wird ein Event ausgelöst. Bei jedem erzeugen Interrupt müsste sich der Zeitstempel ändern.
Darauf kannst du mit einem notify reagieren.

Hallo Klaus,
leider wird lt Eventmonitor kein Event ausgelöst. Dementsprechend reagiert das notify
Internals:
   CFGFN
   DEF        GPIO18:.* IF ([MCP23008:PortA5] eq "off")(set MCP23008 PortA5 on) ELSE (set MCP23008 PortA5 off)
   NAME       MCP23008.Input.Interrupt
   NOTIFYDEV  GPIO18
   NR         622
   NTFY_ORDER 50-MCP23008.Input.Interrupt
   REGEXP     GPIO18:Toggle:.*
   STATE      active
   TYPE       notify
   Readings:
     2018-06-24 11:49:08   state           active
Attributes:
   room       I2C


(was ich Testweise angelegt habe, um ein Event an GPIO18 zu signalisieren) nicht bzw. nur das erste mal nach Neustart.

Hab es auch schon mit event-on-change-update versucht: keine Änderung.

Ich hätte auch erwartet, dass der Interupt von MCP23008 GPIO18 nur kurz auf auf low schaltet und dann sofort wieder auf high geht. 

Hast Du noch eine Idee?
FHEM.RaspberryPi 2 (HM, 1Wire, Callmonitor.FB 7490, GPIO, I2C, MQTT-Server, MCP23018)
FHEM.RaspberryPi  (FHEM2FHEM, CUL, FS20)
FHEM.RPiZeroW (I2C, 1Wire, python.api, XiaomiBTLESens.MQTT)
FHEM.Win7 (FHEM2FHEM,DBLOG.MySql)
ESPEasy (WEMOSD1, I2C, Analog, 1Wire), Sonoff_T1_3ch, Mobotix QM25, robonect

klausw

Der Interrupt vom MCP steht so lang an wie die Änderungen nicht abgeholt worden sind und wird beim auslesen zurück gesetzt.
Der Gpio sollte keine event-on... haben. Poste bitte mal ein list vom Gpio.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

jorge

Zitat von: klausw am 24 Juni 2018, 12:37:14
Der Interrupt vom MCP steht so lang an wie die Änderungen nicht abgeholt worden sind und wird beim auslesen zurück gesetzt.
Der Gpio sollte keine event-on... haben. Poste bitte mal ein list vom Gpio.

o.k. event_on_update habe ich nur versucht, und inzwischen wieder gelöscht.

Aber wie stelle ich den GPIO nach Abholen des Interrupts wieder zurück?

Hier mein List vom GPIO

Zitat
Internals:
   DEF        18
   EXCEPT_FD  20
   GPIO_Basedir /sys/class/gpio
   NAME       GPIO18
   NR         28
   RPI_pin    18
   STATE      off
   TYPE       RPI_GPIO
   WiringPi_gpio /usr/local/bin/gpio
   lasttrg    1529839188.93045
   Readings:
     2018-06-24 13:19:48   Counter         2914
     2018-06-22 12:51:41   Dblclick        off
     2018-06-25 11:41:25   Pinlevel        high
     2018-06-24 13:19:48   Toggle          off
     2018-06-24 13:19:48   state           off
   Fhem:
     interfaces switch
Attributes:
   comment    Interup MCP23008
   direction  input
   interrupt  falling
   pud_resistor up
   room       GPIO,I2C


Danke für´s Bemühen
Jorge
FHEM.RaspberryPi 2 (HM, 1Wire, Callmonitor.FB 7490, GPIO, I2C, MQTT-Server, MCP23018)
FHEM.RaspberryPi  (FHEM2FHEM, CUL, FS20)
FHEM.RPiZeroW (I2C, 1Wire, python.api, XiaomiBTLESens.MQTT)
FHEM.Win7 (FHEM2FHEM,DBLOG.MySql)
ESPEasy (WEMOSD1, I2C, Analog, 1Wire), Sonoff_T1_3ch, Mobotix QM25, robonect