Problem ESP8266, RFID Reader PN532 - Karten-ID wird mehrfach gesendet

Begonnen von niels330, 11 April 2018, 14:48:24

Vorheriges Thema - Nächstes Thema

Joejoe

Hallo zusammen,

[edit]  Auf Wunsch wurde ein neues Thema gestartet siehe: https://forum.fhem.de/index.php/topic,95552.0.html [/edit]

Grüße Joe

parabacus

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
Stiebel Eltron LWZ 504 / FHEM auf Rasperry Pi 3 / THZ / Weather / TABLETUI / SB_SERVER / SB_PLAYER  / OBIS / Verkehrsinfo / speedtest / Presence / FRITZ / ZWDongle / ZWAVE / Calendar / CALVIEW/ IPCAM/ ABFALL / ESPEasy