Moinmoin,
aufbauend auf diesem (leider schon ein Jahr alten Thread) https://forum.fhem.de/index.php?topic=70447.0 (https://forum.fhem.de/index.php?topic=70447.0) stellt sich auch mein Problem wie folgt dar:
Ich habe ein ESP8266 mit ESPEasy geflasht und einen PN532 RFID Reader daran angeschlossen. Das ganze kommuniziert über Wlan mit meiner auf einem Pi3 laufenden FHEM Instanz und schaltet bei erfolgreichem Auslesen eines bestimmten RFID-Tags (bzw dessen UID) einen Türklicker. Soweit so gut, funktioniert an sich ganz gut, aber hat einen entscheidenden Haken.
Das notify sieht so aus:
define ESPEasy_notify_Tag1 notify ESPEasy_ESP_Easy_RFIDScanner:Tag:.XXXXXXXXXX {fhem "set Zimmertur off"}
attr ESPEasy_notify_Tag1 room ESPEasy
Nun zum Haken: Nach erfolgreichem Schalten des Relais, welches den Türklicker öffnet passiert etwas seltsames: ca 2-4 Minuten später (leider unregelmäßig, aber meist in diesem Zeitraum) wird erneut das Reading "Tag:.XXXXXXXXXX" in FHEM empfangen und entsprechend noch mal der Türklicker betätigt. Das passiert sogar, wenn ich das ESP nach erstmaligem Öffnen vom Strom nehme oder reboote. Scheint also ein Problem auf FHEM-Seite zu sein. In oben genanntem Thread wird das Problem sehr ähnlich geschildert, jedoch bleiben sämtliche Lösungsansätze aus selbigem ohne Erfolg.
Jemand hier ne Idee, wie man das "entsprellen" könnte? Bei Bedarf poste ich gerne die entsprechenden Stellen aus dem Eventmonitor.
Gruß
Niels
Ich wieder,
alternativ hätte ich noch die Idee, statt des "state"-Readings das "Tag"-Reading in einem Notify weiterzuverarbeiten. Ich habe nämlich eben festgestellt, dass nach den 2-4 Minuten lediglich das State-Reading mit "Tag: XXXXX" erneuert wird. Das "Tag"-Reading liest sauber die UID aus und gibt diese nur einmal weiter. da gibt es kein "refresh" nach ein paar Minuten.
Allerdings bin ich noch ziemlich unerfahren mit FHEM und deshalb schon froh überhaupt ein notify zum laufen zu bekommen. Kann mir jemand verraten, wie ich es in dem o.g. notify schaffe anstatt des State Readings das Tag reading weiterzuverwerten?
Gruß Niels
Poste mal ein list vom RFID Reader bzw dem ESP damit man die genauen Reading namen hat dann kann man dir bestimmt Helfen
Hier mal screenshots von allem, was das device so hergibt... Danke!
Hallo Niels,
dank Eventmonitor ist das eigentlich ganz einfach.
https://wiki.fhem.de/wiki/Event_monitor
Einfach beim Event zuschauen was passiert, die richtige Zeile markieren und notify erzeugen.
Eventuell hilft auch das attribut event-on-change-reading.
Gruß Otto
P.S. Ein list ist kein Screenshot!
Zitat von: Otto123 am 11 April 2018, 17:36:31
Hallo Niels,
dank Eventmonitor ist das eigentlich ganz einfach.
https://wiki.fhem.de/wiki/Event_monitor
Einfach beim Event zuschauen was passiert, die richtige Zeile markieren und notify erzeugen.
Eventuell hilft auch das attribut event-on-change-reading.
Gruß Otto
P.S. Ein list ist kein Screenshot!
Moin,
Danke, ich dachte es mir schon, allerdings konnte ich so auf die Schnelle nichts mit List anfangen, deshalb habe ich Screenshots hochgeladen, sollte ja auch seinen Zweck erfüllen :)
Den Eventmonitor habe ich beobachtet, allerdings finde ich dort den Grund für das doppelt auslösen nicht. es erscheint nach 2-4 Minuten einfach erneut die Zeile mit dem State-Reading "Tag: xxxxxx". Deshalb der Ansatz, wie man denn das notify entsprechend anpasst um eben nicht "state" auszulesen, sondern das "Tag" Reading direkt verwertet. Event-on-change-reading hatte ich schon ausprobiert. Ändert nichts an dem Problem, leider.
Poste nachher nochmal auszüge vom Eventmonitor.
Beste Grüße
Niels
Zitat von: niels330 am 11 April 2018, 17:46:35
deshalb habe ich Screenshots hochgeladen, sollte ja auch seinen Zweck erfüllen :)
Nein, ein list ist etwas völlig anderes. Zum einen stehen mehr Informationen drin, zum anderen sind Screenshots viel schlechter lesbar als ein list.
Du brauchst die Events nicht zu posten, wenn es keinen Event mit dem Tag Reading gibt wird es nichts mit dem notify. Wenn es einen Event gibt lässt Du Dir dein notify vom Eventmonitor einfach modifizieren.
Zitatallerdings finde ich dort den Grund für das doppelt auslösen nicht. es erscheint nach 2-4 Minuten einfach erneut die Zeile mit dem State-Reading
Naja das ist der Grund warum das notify zweimal auslöst.
Und dein Versuch mit
event-on-change-reading 0 ist großer Käse. Wie kommst Du auf die Idee? Was soll die 0 dort?
.* wäre für alle Readings
state wäre für state
Tag wäre für Tag
usw.
Der Syntax steht immer in der Doku und wird nicht frei erfunden! :-X
Zitatevent-on-change-reading
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings". Wenn gesetzt, erzeugen nur Veränderungen der gelisteten "readings" ein Ereignis. Wenn die aktualiserten Werte der gelisteten "readings" identisch sind, wird kein Ereignis generiert.
Wenn hinter dem Namen eines "readings" eine :Schwelle angegeben ist, wird das Event nur getriggert wenn die Änderung grösser als diese Schwelle ist.
Die unterschiedlichen Bedeutungen von event-on-update-reading und event-on-change-reading sind folgende:
Wenn beide Attribute nicht gesetzt sind erzeugt jede Aktualisierung eines jeden "readings" eines Gerätes ein Ereignis.
Wenn eines der Attribute gesetzt ist, erzeugen nur Updates oder änderungen von "readings" die in einem der Attribute gesetzt sind ein Ereignis.
Wenn ein "reading" in event-on-update-reading aufgeführt ist, erzeugt eine Aktualisierung ein Ereignis unabhängig ob das "reading" auch in event-on-change-reading aufgelistet ist.
Gruß Otto
Hallo
Wenn ich das richig sehe fragst du mit deinem Notify aber auch das Reading Tag ab, bin zwar nicht der notify experte aber
ESPEasy_ESP_Easy_RFIDScanner:Tag:.XXXXXXXXXX bezieht sich auf das Reading nur der . vor dem code also das .XXXXX erretiert mich, heißt der punkt nicht das es bei jedem Code reagieren soll?
Nein, ein notify fragt erstmal kein Reading ab, es reagiert auf einen Event!
Der Punkt steht für "match auf jedes Zeichen" aber erstmal genau auf ein Zeichen.
Also max reagiert genau auf max, m.x reagiert auch auf max, mex, mix oder m x - oder was auch immer vorn mit m und hinten mit x ;D
Ein * würde sagen: reagiere auf beliebig viele Zeichen die vor dem Stern stehen, also
a* würde auf a oder aa oder aaa usw reagieren - .* reagiert dann sozusagen auf alles.
Gruß Otto
mit event-on-change-reading=0 hätte es eigentlich keine events geben dürfen. ausser für das reading "0".
vielleicht ist auch das modul hier nicht "sauber" programmiert.
also sollte sein notify wenn es nur auf den einen Tag mit der id 1234567 reagieren soll doch so aussehen:
define ESPEasy_notify_Tag1 notify ESPEasy_ESP_Easy_RFIDScanner:Tag:1234567 {fhem "set Zimmertur off"}
attr ESPEasy_notify_Tag1 room ESPEasy
attr ESPEasy_notify_Tag1 event-on-update-reading Tag
dann sollte es nur Reagieren wenn das Reading neu erzeugt wird oder
im prinzip ja, aber in der regex noch ein punkt vor die id. denn da gibt es ein leerzeichen. und die perl klammern inklusive fhem befehl sind unnötig.
define ESPEasy_notify_Tag1 notify ESPEasy_ESP_Easy_RFIDScanner:Tag:.1234567 set Zimmertur off
Zitat von: Tueftler1983 am 11 April 2018, 19:36:19
also sollte sein notify wenn es nur auf den einen Tag mit der id 1234567 reagieren soll doch so aussehen:
define ESPEasy_notify_Tag1 notify ESPEasy_ESP_Easy_RFIDScanner:Tag:1234567 {fhem "set Zimmertur off"}
attr ESPEasy_notify_Tag1 room ESPEasy
attr ESPEasy_notify_Tag1 event-on-update-reading Tag
dann sollte es nur Reagieren wenn das Reading neu erzeugt wird oder
Das mit dem event-on-update-reading funktioniert aber nicht als attribut des notifys oder hab ich grad nen denkfehler? Das muss ich dann als Attribut des Scanners definieren:
attr ESPEasy_ESP_Easy_RFIDScanner event-on-update-reading Tagso?
Internals:
DEF 192.168.0.241 80 espBridge ESP_Easy_RFIDScanner
ESP_BUILD 20100
ESP_SLEEP 0
ESP_UNIT 0
HOST 192.168.0.241
IDENT ESP_Easy_RFIDScanner
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MSGCNT 1
NAME ESPEasy_ESP_Easy_RFIDScanner
NOTIFYDEV global
NR 499
NTFY_ORDER 50-ESPEasy_ESP_Easy_RFIDScanner
PORT 80
STATE Tag: 226093XXXX
SUBTYPE device
TYPE ESPEasy
VERSION 0.82
espBridge_MSGCNT 1
espBridge_TIME 2018-04-11 19:59:06
Readings:
2018-04-11 19:59:06 Tag 226093XXXX
2018-04-04 03:38:40 presence present
2018-04-11 19:59:06 state Tag: 226093XXXX
Helper:
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 303
TRIGGERTIME 11.04.2018 20:03:54
Received:
Tag 1523469546.22412
Attributes:
IODev espBridge
Interval 300
event-on-change-reading .*
group ESPEasy Device
presenceCheck 0
readingSwitchText 1
room ESPEasy
setState 3
hier mal die list vom Device ESPEasy_ESP_Easy_RFIDScanner
Zitat von: Otto123 am 11 April 2018, 17:36:31
Hallo Niels,
dank Eventmonitor ist das eigentlich ganz einfach.
https://wiki.fhem.de/wiki/Event_monitor
Einfach beim Event zuschauen was passiert, die richtige Zeile markieren und notify erzeugen.
Eventuell hilft auch das attribut event-on-change-reading.
Gruß Otto
P.S. Ein list ist kein Screenshot!
ich habe dem Device nun ein
attr Event-on-change-reading .* gesetzt. Zweites mal Klicken bleibt aus - gut. Problem dann allerdings, dass er auch bei zukünftigen Scans der selben RFID-Karte nichts mehr macht, da ja immer wieder die selbe UID im Reading auftaucht und er erst wieder schaltet, wenn eine andere definierte UID einer anderen Schlüsselkarte eingelesen wird. Das kanns ja auch eher nicht sein ;D
deswegen mein vorschlag mit dem event-on-update-reading
Eventmonitor zu rate gezogen, ohne das Event-on-change-reading wird ca 2 Minuten nach dem eigentlichen einlesen der Karte nochmal ein Event generiert und der "state" geupdatet.
2018-04-11 20:12:01 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:12:01 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:12:01 dummy Zimmertur off
...
2018-04-11 20:13:59 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:13:59 dummy Zimmertur off
Sprich ein Event-on-update-reading hilft nicht weiter, doppeltes Event = doppeltes klicken. Ein Event-on-change-reading unterdrückt zwar das zweite event und somit ein erneutes klicken, aber dann ist wie gesagt das Problem, dass er bei zukünftigem Einlesen der selben RFID Karte gar nichts mehr macht.
Was mir die ganze Zeit noch nicht klar ist, warum wird das state-Reading (state "Tag: xxxxxx") nach 2-4 Minuten nochmal geupdatet, das Tag-Reading aber liest wirklich nur das einscannen der Karte aus (Tag "xxxxx")und updatet nicht random... Das heißt doch eigentlich, dass ich im Endeffekt nur mit dem Tag-Reading wirklich weiterkomme und dieses irgendwie verarbeiten muss, oder?
Entchuldigt bitte die vielleicht total dämlichen Fragen, aber daran hänge ich momentan extrem... :) Ist einfach nicht hübsch, wenn die Tür zwei Minuten nach dem öffnen nochmal klickert, auch wenn es in dem Fall nicht sicherheitsrelevant ist.
Besten Gruß,
Niels
Hallo Niels,
probiere doch bitte mal folgendes DOIF (statt deines Notify). Notify bitte für den Test deaktivieren!
define RFID_Tag_DOIF DOIF ([ESPEasy_ESP_Easy_RFIDScanner:Tag] eq "1234567") (set Zimmertur off)
DOELSE
Eventuell musst du in diesem DOIF das Attribut "do" - "always" setzen.
Also in die FHEM Befehlszeile folgendes eingeben:
attr RFID_Tag_DOIF do always
Das do always aber erst setzen, wenn es irgendeine Fehlfunktion ohne dieses Attribut gibt.
Mit der Bitte um Feedback, wie die Tests verliefen.
Gruß,
Mike
Zitat von: tik-tak-tok am 11 April 2018, 20:26:01
Hallo Niels,
probiere doch bitte mal folgendes DOIF (statt deines Notify). Notify bitte für den Test deaktivieren!
define RFID_Tag_DOIF DOIF ([ESPEasy_ESP_Easy_RFIDScanner:Tag] eq "1234567") (set Zimmertur off)
DOELSE
Eventuell musst du in diesem DOIF das Attribut "do" - "always" setzen.
Also in die FHEM Befehlszeile folgendes eingeben:
attr RFID_Tag_DOIF do always
Das do always aber erst setzen, wenn es irgendeine Fehlfunktion ohne dieses Attribut gibt.
Mit der Bitte um Feedback, wie die Tests verliefen.
Gruß,
Mike
Servus,
erstmal danke für den neuen Ansatz, soeben getestet, leider auch nicht wirklich erfolgreich. Ohne das do always atrribut passiert gar nichts, also im Eventmonitor taucht zwar das Reading auf
2018-04-11 20:31:54 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:31:55 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
Aber es klickt gar nicht.
Setze ich dann das do always Attribut passiert folgendes:
2018-04-11 20:40:38 DOIF RFID_Tag_DOIF cmd_nr: 1
2018-04-11 20:40:38 DOIF RFID_Tag_DOIF cmd: 1
2018-04-11 20:40:38 DOIF RFID_Tag_DOIF cmd_event: ESPEasy_ESP_Easy_RFIDScanner
2018-04-11 20:40:38 DOIF RFID_Tag_DOIF cmd_1
2018-04-11 20:40:38 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:40:38 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:40:38 dummy Zimmertur off
....
2018-04-11 20:43:43 DOIF RFID_Tag_DOIF cmd_nr: 1
2018-04-11 20:43:43 DOIF RFID_Tag_DOIF cmd: 1
2018-04-11 20:43:43 DOIF RFID_Tag_DOIF cmd_event: ESPEasy_ESP_Easy_RFIDScanner
2018-04-11 20:43:43 DOIF RFID_Tag_DOIF cmd_1
2018-04-11 20:43:43 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:43:43 dummy Zimmertur off
....
2018-04-11 20:48:44 DOIF RFID_Tag_DOIF cmd_nr: 1
2018-04-11 20:48:44 DOIF RFID_Tag_DOIF cmd: 1
2018-04-11 20:48:44 DOIF RFID_Tag_DOIF cmd_event: ESPEasy_ESP_Easy_RFIDScanner
2018-04-11 20:48:44 DOIF RFID_Tag_DOIF cmd_1
2018-04-11 20:48:44 ESPEasy ESPEasy_ESP_Easy_RFIDScanner present
2018-04-11 20:48:44 dummy Zimmertur off
Sprich diesmal klickt er sogar dreimal... mit ca 3 Minuten verzögerung kommt das Reading mit der UID erneut rein und nach weiteren 5 Minuten wechselt er auf das reading "present" und schaltet nochmal. Einfach zum Mäuse melken.
Im List von ESPEasy_ESP_Easy_RFIDScanner ist aber auch hier zu erkennen, dass nur das state-reading randomly geupdatet wird. Wenn man es irgendwie schaffen würde mit dem Tag-Reading weiterzuarbeiten, dann wäre alles super, da steht nälich auch jetzt noch die Uhrzeit vom letzten einlesen der RFID Karte...
Internals:
DEF 192.168.0.241 80 espBridge ESP_Easy_RFIDScanner
ESP_BUILD 20100
ESP_SLEEP 0
ESP_UNIT 0
HOST 192.168.0.241
IDENT ESP_Easy_RFIDScanner
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MSGCNT 9
NAME ESPEasy_ESP_Easy_RFIDScanner
NOTIFYDEV global
NR 499
NTFY_ORDER 50-ESPEasy_ESP_Easy_RFIDScanner
PORT 80
STATE present
SUBTYPE device
TYPE ESPEasy
VERSION 0.82
espBridge_MSGCNT 9
espBridge_TIME 2018-04-11 20:40:38
Readings:
2018-04-11 20:40:38 Tag 2260931259
2018-04-04 03:38:40 presence present
2018-04-11 20:48:43 state present
Helper:
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 11.04.2018 20:53:47
Received:
Tag 1523472038.5515
Attributes:
IODev espBridge
Interval 300
event-on-update-reading .*
group ESPEasy Device
presenceCheck 0
readingSwitchText 1
room ESPEasy
setState 3
Seltsaaaam....
Beste Grüße,
Niels
PS: Wollte mich mal bedanken, toll wieviele sich hier einfach einschalten um mit mir nach der Lösung suchen, find ich super! Danke!
Hi,
Und ich mich beschweren ;-)
1.) Nutze Code Tags um die Listen von Logs oder Befehlen:
[code]blabla[/code]
2.) Gehe dich mal dem root cause auf die Spur! Hast Du mal in deinem ESP Easy Device geschaut, was da eingetragen ist? Unter Rules oder Hardware (z.B. Delays?)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 11 April 2018, 21:08:31
2.) Gehe dich mal dem root cause auf die Spur! Hast Du mal in deinem ESP Easy Device geschaut, was da eingetragen ist? Unter Rules oder Hardware (z.B. Delays?).
Einen Rules Reiter habe ich in ESPEasy gar nicht. Und unter Hardware sind bei mir folgende Items aufgeführt: Wifi Status LED, I2C Interface, SPI Interface, GPIO boot states... nix mit Delays oder ähnliches. Verwirrend. Aber wie ursprünglich gesagt, das zeitverzögerte Event tritt auch auf, wenn ich den ESP nach erstmaligem schalten komplett vom Strom nehme (und lasse), daher gehe ich davon aus, dass der Fehler auf FHEM seite liegt. kann mich natürlich täuschen...
Was hast du den auf der ESP Config seite hier bei delay stehen?? siehe screenshot?
Zitat von: Tueftler1983 am 11 April 2018, 21:37:43
Was hast du den auf der ESP Config seite hier bei delay stehen?? siehe screenshot?
Mein Menü schaut etwa anders aus. Evtl ist da was falsch eingestellt? Habe dort aber nicht rumgespielt, sondern einfach die Original-Einstellungen so gelassen...
Gruß
Hi,
Aber in jeder Hardware gibt es doch wieder ein Delay. 0 gleich sofort übermitteln und Wert in s für Zwitverzögert. Die Rules muss man erst unter Advanced aktivieren, wenn Du die nicht hast, ist das nicht schlimm und kann auch nicht den Fehler machen ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: niels330 am 11 April 2018, 20:21:43
Eventmonitor zu rate gezogen, ohne das Event-on-change-reading wird ca 2 Minuten nach dem eigentlichen einlesen der Karte nochmal ein Event generiert und der "state" geupdatet.
2018-04-11 20:12:01 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:12:01 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:12:01 dummy Zimmertur off
...
2018-04-11 20:13:59 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Tag: 226093xxxx
2018-04-11 20:13:59 dummy Zimmertur off
Hallo Niels,
wenn das alles ist im Eventmonitor (da gibt es übrigens Filter, Du solltest Dir wirklich mal das Wiki durchlesen) dann kommen ja nicht zwei Events wie Du immer erzählst, sondern drei. Zwei sofort und einer verzögert.
Edit:
Die ersten beiden Events sind übrigens einmal das setzen des Readings Tag und zum zweiten das setzen des STATE durch attr setstate 3. Ändere das attr mal auf setstate 2, dann kann man die Events unterscheiden.
Edit2:
Kannst Du mal das attr <> Interval 300 auf 0 setzen! Das brauchst Du aus meiner Sicht nicht. Aber ob es das ist?
ZitatInterval
Used to set polling interval for presence check and GPIOs polling in seconds. 0 will disable this feature.
Possible values: secs > 10.
Default: 300
Gruß Otto
Anhang: Nur falls Du die Codetags nicht findest, die Arnd erwähnt hat.
probieren kann er es ja indem er den interval auf 0 setzt aber 300 sind ja 5 min und das passt ja auch nicht
Moin,
ja ich weiß. War nur eine Idee.
Das Hauptproblem in dem Fall ist sicher, dass Tag 3 Zeichen hat und mit dem Standard attr <> setState 3 ist dann der Event für das setzen des state und des Readings nicht mehr unterscheidbar ist.
ZitatsetState
Summarize received values in state reading.
A positive number determines the number of characters used for abbreviated reading names. Only readings with an age less than interval will be considered. If your are not satisfied with format or behavior of setState then disable this attribute (set to 0) and use global attributes userReadings and/or stateFormat to get what you want.
Possible values: integer >=0
Default: 3 (enabled with 3 characters abbreviation)
Warum der state nach ein paar Minuten nochmal aktualisiert wird erschliesst sich mir nicht.
Fakt ist, so wie es jetzt ist, ist der eigentliche Event nicht auswertbar!
Könnte man eventuell damit beheben
ZitataddStateEvent
Das mit dem state Reading verknüpfte Event ist speziell, da das dazugehörige Prefix "state: " entfernt wird, d.h. $EVENT ist nicht "state: on", sondern nur "on". In manchen Fällen ist es aber erwünscht das unmodifizierte Event zu bekommen, d.h. wo "state: " nicht entfernt ist. Für diese Fälle sollte addStateEvent auf 1 gesetzt werden, die Voreinstellung ist 0 (deaktiviert).
Achtung:
dieses Attribut muss beim Empfänger (notify, FileLog, etc) gesetzt werden.
dieses Attribut zeigt nur für solche Geräte-Events eine Wirkung, die readingFnAttributes unterstützen.
Gruß Otto
@niels330:
Die einzelnen Readings der einzelnen FHEM ESPEasy Devices werden dann aktualisiert (incl. event), wenn Daten dafür empfangen werden.
Das Reading state wird aktualisiert, wenn irgendein anderes Reading aktualisiert wird, auch das presence Reading. Wenn Dein notify, wie im ersten Beitrag gezeigt, auf das Reading Tag triggert, dann, weil es aktualisiert wurde oder Otto123s Vermutung trifft zu (habe ich nicht geprüft), dann sollte Dir das notify Attribut addStateEvent helfen.
Wenn das Update (incl. events) des Readings state Dich stört, dann kannst Du das mit dem Attribut setState abstellen und Dich selbst um den Inhalt von state kümmern.
Die event-on-[change|update]-reading Attribute funktionieren bei allen Readings der FHEM ESPEasy Devices so wie sie in der command reference (https://fhem.de/commandref.html#readingFnAttributes) beschrieben sind.
Zitat von: Otto123 am 11 April 2018, 22:18:40
Edit:
Die ersten beiden Events sind übrigens einmal das setzen des Readings Tag und zum zweiten das setzen des STATE durch attr setstate 3. Ändere das attr mal auf setstate 2, dann kann man die Events unterscheiden.
Edit2:
Kannst Du mal das attr <> Interval 300 auf 0 setzen! Das brauchst Du aus meiner Sicht nicht. Aber ob es das ist?
Otto... Danke! Ganz genau erschließt es sich mir nicht, warum wieso weshalb, aber durch diese beiden Modifikationen ist das Problem behoben worden!
define ESPEasy_notify_Checkkarte notify ESPEasy_ESP_Easy_RFIDScanner:Tag:.226093xxxx {fhem "set Zimmertur off"}
attr ESPEasy_notify_Checkkarte room ESPEasydefine ESPEasy_ESP_Easy_RFIDScanner ESPEasy 192.168.0.241 80 espBridge ESP_Easy_RFIDScanner
attr ESPEasy_ESP_Easy_RFIDScanner IODev espBridge
attr ESPEasy_ESP_Easy_RFIDScanner Interval 0
attr ESPEasy_ESP_Easy_RFIDScanner event-on-update-reading .*
attr ESPEasy_ESP_Easy_RFIDScanner group ESPEasy Device
attr ESPEasy_ESP_Easy_RFIDScanner presenceCheck 0
attr ESPEasy_ESP_Easy_RFIDScanner readingSwitchText 1
attr ESPEasy_ESP_Easy_RFIDScanner room ESPEasy
attr ESPEasy_ESP_Easy_RFIDScanner setState 2Su tut es genau wie gewünscht!
Vielen danke an alle für die hervorragenden Lösungsansätze, super!
Gruß,
Niels
Hallo Niels,
noch zwei Tipps
{fhem "set Zimmertur off"} -> set Zimmertur off
An der Stelle brauchst Du den Sprung von FHEm nach Perl und zurück nach FHEM nicht. Aber ich weiß manche mögen das so "Einheitlich" ;D
Jetzt ist ja unklar was zum Erfolg geführt hat?
Auf alle Fälle ist der Event für das setzen des state nur noch zweistellig, der sollte also jetzt so aussehen - oder?:
2018-04-11 20:31:55 ESPEasy ESPEasy_ESP_Easy_RFIDScanner Ta: 226093xxxx
Ist der zweite Event nach ein paar Minuten weggefallen?
Gruß Otto
Hallo zusammen,
[edit] Auf Wunsch wurde ein neues Thema gestartet siehe: https://forum.fhem.de/index.php/topic,95552.0.html (https://forum.fhem.de/index.php/topic,95552.0.html) [/edit]
Grüße Joe
Da's zum neu verlinkten Thema nicht wirklich passt und ich heute genau das selbe Problem hatte, hinterlasse ich hier meine Problemlösung der Nachwelt. ;D
Hier meine Lists:
Internals:
DEF <meine IP> 80 espBridge AlarmOnOff_DeActAlam
ESP_BUILD 20103
ESP_BUILD_GIT mega-20190116
ESP_BUILD_NOTES - Mega
ESP_NODE_TYPE_ID ESP Easy Mega
ESP_SLEEP 0
ESP_UNIT 2
ESP_VERSION 2
FUUID 5c5d9daa-f33f-869f-4040-3c7ebd3897ee1ac3
HOST 192.168.1.49
IDENT AlarmOnOff_DeActAlam
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MAX_CMD_DURATION 1
MSGCNT 17
NAME AlarmOnOff
NOTIFYDEV global
NR 870
NTFY_ORDER 50-AlarmOnOff
PORT 80
STATE absent
SUBTYPE device
TYPE ESPEasy
VERSION 2.16
espBridge_MSGCNT 17
espBridge_TIME 2019-02-09 20:05:32
READINGS:
2019-02-09 20:05:44 Tag 0
2019-02-09 22:38:45 presence absent
2019-02-09 22:38:45 state absent
helper:
fpc 1549727141.61564
pm:
Encode 1
JSON 1
received:
sec:
admpwd
Attributes:
IODev espBridge
group ESPEasy Device
readingSwitchText 1
room Alarmanlage,ESPEasy
setState 3
Wie ich herausgefunden habe, ist das Problem, dass auch bei deaktivierter Presence-Detektion dennoch ein Event generiert wird. Ist dann die Tag-Info vom vorausgegangenen Event noch gefüllt, triggert der das DOIF oder NOTIFY nochmal (..was ja quasi korrekt ist, aber unerwünscht).
Daher hab ich in meinem DOIF als erstes mal die Tag-Info als erste Aktion gelöscht, dann meine gewünschten Aktionen durchgeführt und am Ende die Tag-Info sicherheitshalber nochmal gelöscht, da ich hin und wieder auch einen spätern retrigger festgestellt habe. Um das zeitlich zu steuern, hab ich mit Attribut wait gearbeitet - erstes Löschen und erste Aktion (ein Piepton) unverzüglich, dann mit 2 Sec. Verzögerung die Wertänderung einer Steuervariable und dann nach 10 Sec. nochmal Löschen der Tag-Info.
Internals:
DEF ([AlarmOnOff:"^Tag:.<meinTAG>$"] and [AlarmForcedOff] eq "off") (setreading AlarmOnOff Tag 0) (set ZWSirene alarmDisarmOn) (set AlarmForcedOff on) (setreading AlarmOnOff Tag 0)
FUUID 5c5ea944-f33f-869f-0907-42760b56445650be
MODEL FHEM
NAME AlarmOnOff_DOIF_0
NR 880
NTFY_ORDER 50-AlarmOnOff_DOIF_0
STATE initialized
TYPE DOIF
READINGS:
2019-02-09 22:48:52 Device AlarmOnOff
2019-02-09 13:49:15 cmd 0
2019-02-09 20:05:34 e_AlarmForcedOff_STATE on
2019-02-09 22:48:52 e_AlarmOnOff_events absent
2019-02-09 13:49:15 mode enabled
2019-02-09 13:49:15 state initialized
Regex:
attr:
cmdpause:
10
wait:
0:
0
0
2
10
condition:
0 ::EventDoIf('AlarmOnOff',$hash,'^Tag:.<meinTAG>$',1) and ::InternalDoIf($hash,'AlarmForcedOff','STATE') eq "off"
devices:
0 AlarmOnOff AlarmForcedOff
all AlarmOnOff AlarmForcedOff
do:
0:
0 setreading AlarmOnOff Tag 0
1 set ZWSirene alarmDisarmOn
2 set AlarmForcedOff on
3 setreading AlarmOnOff Tag 0
1:
helper:
event absent
globalinit 1
last_timer 0
sleeptimer -1
triggerDev AlarmOnOff
triggerEvents:
absent
triggerEventsState:
state: absent
internals:
0 AlarmForcedOff:STATE
all AlarmForcedOff:STATE
itimer:
perlblock:
readings:
trigger:
all AlarmOnOff
uiState:
uiTable:
Attributes:
cmdpause 10
do always
room ESPEasy
wait 0,0,2,10
So läuft es nun schon den ganzen Tag vollkommen stabil! ;D