Modul für RPi GPIO Zugriff mit Interrupt Funktion für Input

[backbone10]

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

Code Auswählen Erweitern



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




[klausw]

Hallo Tom,

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

[Ralli]

Hallo,

nun bräuchte ich hier auch bitte mal kurz Hilfe. Ich überwache einen schnurgebundenen Kontakt wie folgt:

Code Auswählen Erweitern


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?

[backbone10]

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

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

[klausw]

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

[Ralli]

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[klausw]

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:

Code Auswählen Erweitern


attr GPIO21 stateFormat {ReadingsVal("GPIO21","Pinlevel",0) eq "low" ? "open" : "closed"}


geht es denn, wenn Du das Attribut stateFormat löschst?

[Ralli]

Ja, dann funktioniert es!

Allerdings generiert er keinen Event bzw. triggert nichts an.

[klausw]

Dann sollte es auch so gehen:

Code Auswählen Erweitern

attr GPIO21 stateFormat {state eq "off" ? "open" : "closed"}

Den Pinvalue könnte ich allerdings auch noch mit beim starten schreiben...

[Ralli]

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).

[klausw]

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

[Ralli]

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!

[klausw]

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

[Ralli]

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.

[klausw]

ich habe das Modul wie beigefügt modifiziert.

schaue gleich mal rein...
funktionierte denn meine Version nicht?

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)

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)

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.