[gelöst] Klingelsensor HmIP-DSD-PCB notify wird doppelt getriggert

Begonnen von HansDampfHH, 27 September 2021, 16:59:56

Vorheriges Thema - Nächstes Thema

HansDampfHH

Seit heute werkelt der HmIP-DSD-PCB Sensor und tut was er soll, soweit fein.
Im Systemprotokoll der CCU wird jeweils nur ein Event protokolliert, im FHEM Event-Monitor taucht das Event leider 2x auf.
Daher wird natürlich auch das Notify 2x getriggert, aber wo kommt das 2. Event her?

Hier mal ein List meines neuen Sensors:

Internals:
   CFGFN     
   DEF        0026DBE998F7B4
   FUUID      6151a0b8-f33f-1920-4b2a-c549caee568775a6
   IODev      CCU2
   NAME       HM_HmIP_DSD_PCB_0026DBE998F7B4
   NR         616147
   STATE      true
   TYPE       HMCCUDEV
   ccuaddr    0026DBE998F7B4
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    HmIP-DSD-PCB 0026DBE998F7B4
   ccutype    HmIP-DSD-PCB
   channels   2
   firmware   1.0.6
   statevals  devstate
   READINGS:
     2021-09-27 16:44:32   0.CONFIG_PENDING 0
     2021-09-27 15:35:02   0.DUTY_CYCLE    false
     2021-09-27 15:35:02   0.INSTALL_TEST  true
     2021-09-27 15:35:02   0.OPERATING_VOLTAGE 2.500000
     2021-09-27 15:35:02   0.OPERATING_VOLTAGE_STATUS 0
     2021-09-27 16:44:32   0.RSSI_DEVICE   -44
     2021-09-27 15:35:02   0.RSSI_PEER     0
     2021-09-27 15:35:02   0.UPDATE_PENDING false
     2021-09-27 16:44:33   1.PRESS_SHORT   1
     2021-09-27 15:35:02   1.STATE         true
     2021-09-27 12:45:12   IODev           CCU2
     2021-09-27 16:44:32   activity        alive
     2021-09-27 16:44:32   battery         ok
     2021-09-27 15:35:02   control         true
     2021-09-27 16:44:33   hmstate         true
     2021-09-27 15:35:02   state           true
   hmccu:
     devspec    0026DBE998F7B4
     dp:
       0.CONFIG_PENDING:
         OSVAL      0
         OVAL       0
         SVAL       0
         VAL        0
       0.DUTY_CYCLE:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.INSTALL_TEST:
         OSVAL      true
         OVAL       true
         SVAL       true
         VAL        true
       0.LOW_BAT:
         OSVAL      ok
         OVAL       0
         SVAL       ok
         VAL        0
       0.OPERATING_VOLTAGE:
         OSVAL      2.500000
         OVAL       2.500000
         SVAL       2.500000
         VAL        2.500000
       0.OPERATING_VOLTAGE_STATUS:
         OSVAL      0
         OVAL       0
         SVAL       0
         VAL        0
       0.RSSI_DEVICE:
         OSVAL      -44
         OVAL       -44
         SVAL       -44
         VAL        -44
       0.RSSI_PEER:
         OSVAL      0
         OVAL       0
         SVAL       0
         VAL        0
       0.UNREACH:
         OSVAL      alive
         OVAL       0
         SVAL       alive
         VAL        0
       0.UPDATE_PENDING:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       1.PRESS_SHORT:
         OSVAL      1
         OVAL       1
         SVAL       1
         VAL        1
       1.STATE:
         OSVAL      true
         OVAL       true
         SVAL       true
         VAL        true
Attributes:
   DbLogExclude .*
   alias      Klingelsensor
   ccureadingfilter ERROR_CODE|LOW_BAT|STATE|PRESS_SHORT|.*
   event-on-update-reading .*
   statechannel 1
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

zap

Ich nehme an, Du meinst STATE. Versuche es mal mit event-on-change-reading
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

HansDampfHH

Als state kommt ja bei einem Sensor Event immer true, da würde ein on-change doch nicht getriggert, der Wert ändert sich ja nicht.
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

Adimarantis

Mein DOIF schaut so aus:
([HM_Sen_DB_PCB_XXXXX:state] eq 1) (set SignalBot send #Zuhause Es klingelt)(setreading HM_Sen_DB_PCB_XXXX state 0) DOELSE (setreading HM_Sen_DB_PCB_XXXXX state 0)
dazu ist "wait" auf "0,15" gesetzt und "do" auf "always".
Das sollte verhindern das bei ungeduldigem Klingeln mehrere Nachrichten versendet werden.

Ist schon so lange her, das ich gar nicht mehr weiss ob ich auch so ein Problem hatte - aber auf jeden Fall klappt das bei mir.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

TomLee

#4
Wenn du doch schon festgestellt hast dass das Event zweimal in Fhem ankommt warum setzt du dann ein  event-on-update-reading .* ? Dann ist doch klar das das notify zweimal auslöst ! edit: ohne event-on-change-reading bestätigst du mit event-on-update-reading .* doch nur noch zusätzlich daß das notify zweimal auslösen soll ?


HansDampfHH

In der CCU kann man einstellen welche Meldung bei offen/geschlossen gesendet wird.
Ich habe mal nur eingestellt, dass bei geschlossen eine Meldung kommt und seither gibt es auch nur noch ein Event.
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

zap

Danke für den Hinweis. Ich hatte mich schonmal mit dem Thema beschäftigt und festgestellt, dass die CCU tatsächlich 2x einen Event schickt. Der Tipp mit den Geräteeinstellungen ist sehr hilfreich.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB