HM-LC-Sw1PBU-FM und HM-PB-2-WM55 Problem

Begonnen von Amenophis86, 20 November 2017, 18:12:39

Vorheriges Thema - Nächstes Thema

Amenophis86

Folgende Situation: Ich habe einen HM-LC-Sw1PBU-FM als Deckenlicht für unsere Küche. Hier ein List des Device:

Internals:
   CFGFN
   DEF        53F3EF
   HMLAN1_MSGCNT 1106
   HMLAN1_RAWMSG E53F3EF,0000,31173034,FF,FFC8,F2A41053F3EF1234560601C800
   HMLAN1_RSSI -56
   HMLAN1_TIME 2017-11-20 18:02:13
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     1106
   NAME       KU.Decke.Licht
   NOTIFYDEV  global
   NR         229
   NTFY_ORDER 50-KU.Decke.Licht
   STATE      on
   TYPE       CUL_HM
   lastMsg    No:F2 - t:10 s:53F3EF d:123456 0601C800
   peerList   KU.Schalter.LED_01,
   protLastRcv 2017-11-20 18:02:13
   protResnd  2 last_at:2017-11-12 17:00:49
   protSnd    1009 last_at:2017-11-20 18:02:13
   protState  CMDs_done
   rssi_HMLAN1 avg:-57.93 min:-66 max:-52 cnt:15 lst:-55
   rssi_KU.Schalter.LED avg:-52.23 min:-68 max:-34 cnt:96 lst:-56
   rssi_at_HMLAN1 cnt:1106 lst:-56 avg:-60.01 min:-80 max:-53
   READINGS:
     2017-11-20 17:57:42   CommandAccepted yes
     2017-06-11 10:51:17   D-firmware      2.8
     2017-06-11 10:51:17   D-serialNr      NEQ1736369
     2017-11-12 17:14:19   PairedTo        0x123456
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgActionType jmpToTarget
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgCtDlyOff geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgCtDlyOn geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgCtOff geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgCtOn geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgCtValHi 100
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgCtValLo 50
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgMultiExec on
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgOffDly 0 s
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgOffTime unused
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgOffTimeMode absolut
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgOnDly 0 s
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgOnTime unused
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgOnTimeMode absolut
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgSwJtDlyOff off
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgSwJtDlyOn on
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgSwJtOff dlyOn
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-lgSwJtOn dlyOff
     2017-11-12 17:14:21   R-KU.Schalter.LED_01-shActionType off
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shCtDlyOff geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shCtDlyOn geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shCtOff geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shCtOn geLo
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shCtValHi 100
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shCtValLo 50
     2017-11-12 17:14:21   R-KU.Schalter.LED_01-shMultiExec off
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shOffDly 0 s
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shOffTime unused
     2017-11-12 17:14:21   R-KU.Schalter.LED_01-shOffTimeMode absolut
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shOnDly 0 s
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shOnTime unused
     2017-11-12 17:14:21   R-KU.Schalter.LED_01-shOnTimeMode absolut
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shSwJtDlyOff off
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shSwJtDlyOn on
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shSwJtOff dlyOn
     2017-11-12 17:00:49   R-KU.Schalter.LED_01-shSwJtOn dlyOff
     2017-06-11 10:51:22   R-intKeyVisib   invisib
     2017-06-11 10:51:22   R-localResDis   off
     2017-06-11 10:51:22   R-pairCentral   0x123456
     2017-06-11 10:51:22   R-powerUpAction off
     2017-06-11 10:51:22   R-sign          off
     2017-06-11 10:51:22   R-statusInfoMinDly 2 s
     2017-06-11 10:51:22   R-statusInfoRandom 1 s
     2017-06-11 10:51:22   R-transmitTryMax 6
     2017-11-12 17:14:19   RegL_00.          02:01 0A:12 0B:34 0C:56 15:FF 18:00 00:00
     2017-11-12 17:14:20   RegL_01.         08:00  30:06 57:24 56:00 00:00
     2017-11-12 17:14:21   RegL_03.KU.Schalter.LED_01  02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:00 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
     2017-11-20 18:02:13   deviceMsg       on (to VCCU)
     2017-11-20 18:02:13   level           100
     2017-08-23 14:03:38   levelMissed     desired:0
     2017-11-20 18:02:13   pct             100
     2017-11-12 17:14:20   peerList        KU.Schalter.LED_01,
     2017-08-03 18:06:29   powerOn         2017-08-03 18:06:29
     2017-11-20 18:02:13   recentStateType info
     2017-11-20 18:02:13   state           on
     2017-11-20 18:02:13   timedOn         off
     2017-11-20 17:57:42   trigLast        KU.Schalter.LED_01:short
     2017-11-20 17:57:42   trig_KU.Schalter.LED_01 Short_211
   helper:
     HM_CMDNR   242
     cSnd       1112345653F3EF0201C80000,1112345653F3EF0201000000
     dlvlCmd    ++A01112345653F3EF0201000000
     mId        0069
     peerIDsRaw ,59824301,00000000
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +53F3EF,00,00,00
       nextSend   1511197334.05391
       rxt        0
       vccu       VCCU
       p:
         53F3EF
         00
         00
         00
       prefIO:
         HMLAN1
     mRssi:
       mNo        F2
       io:
         HMLAN1     -54
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMLAN1
       flg        A
       ts         1511197333.96813
       ack:
         HASH(0x36d89f8)
         F2800212345653F3EF00
     rssi:
       HMLAN1:
         avg        -57.9333333333333
         cnt        15
         lst        -55
         max        -52
         min        -66
       KU.Schalter.LED:
         avg        -52.2395833333333
         cnt        96
         lst        -56
         max        -34
         min        -68
       at_HMLAN1:
         avg        -60.0144665461121
         cnt        1106
         lst        -56
         max        -53
         min        -80
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU:HMLAN1
   alexaName  Küchenlicht
   alexaRoom  Küche
   autoReadReg 4_reqStatus
   devStateIcon on:Licht.on off:Licht.off
   event-on-change-reading .*
   expert     251_anything
   firmware   2.8
   genericDeviceType switch
   group      Licht
   model      HM-LC-Sw1PBU-FM
   peerIDs    00000000,59824301,
   room       Räume--Kueche,Z_System--Homematic,Z_Räume--Kueche,Z_System--alexa
   serialNr   NEQ1736369
   subType    switch
   userattr   room_map structexclude wohnung wohnung_map
   verbose    2
   webCmd     on:off
   wohnung    WG.Licht.Alle


Dann habe ich in der Küche noch einen HM-PB-2-WM55, welcher zwei LED Streifen bei kurzem Tastendruck und das Küchenlicht bei langem Tastendruck auslösen soll. Hier ein List des Device (aktuell nur die Linke Seite [Schalter um 90 Grad gedreht] in Funktion fürs Deckenlicht, da ich noch am Testen bin):

Internals:
   CFGFN
   DEF        59824301
   NAME       KU.Schalter.LED_01
   NOTIFYDEV  global
   NR         279
   NTFY_ORDER 50-KU.Schalter.LED_01
   STATE      Short 2_211 (to VCCU)
   TYPE       CUL_HM
   chanNo     01
   device     KU.Schalter.LED
   peerList   VCCU_Btn1,KU.Decke.Licht,
   READINGS:
     2017-11-12 17:00:55   R-KU.Decke.Licht_chn-01-expectAES off
     2017-11-12 17:00:55   R-KU.Decke.Licht_chn-01-peerNeedsBurst off
     2017-08-23 13:52:12   R-VCCU_Btn1-expectAES off
     2017-08-23 13:52:12   R-VCCU_Btn1-peerNeedsBurst off
     2017-08-23 13:47:39   R-dblPress      0 s
     2017-08-23 13:47:39   R-longPress     0.4 s
     2017-08-23 13:47:39   R-sign          off
     2017-11-12 17:00:53   RegL_01.          04:10 08:00 09:00 00:00
     2017-11-12 17:00:55   RegL_04.KU.Decke.Licht_chn-01   01:00 00:00
     2017-11-12 17:00:54   RegL_04.VCCU_Btn1   01:00 00:00
     2017-11-12 17:00:54   peerList        VCCU_Btn1,KU.Decke.Licht,
     2017-11-20 17:57:42   state           Short 2_211 (to VCCU)
     2017-11-20 17:57:42   trigger         Short_211
     2017-11-20 17:57:42   triggerTo_KU.Decke.Licht Short_211_ack
     2017-11-20 17:57:42   trigger_cnt     211
   helper:
     BNO        211
     BNOCNT     2
     peerIDsRaw ,12345601,53F3EF01,00000000
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   event-on-change-reading .*
   expert     251_anything
   group      Schalter
   model      HM-PB-2-WM55
   peerIDs    00000000,12345601,53F3EF01,
   room       Z_System--Homematic,Z_Räume--Kueche


Wie gesagt soll ein langer Tastendruck das Deckenlicht toggeln und ein kurzer Tastendruck die LED Leiste toggeln. Das klappt auch soweit. Allerdings möchte ich, dass bei einem kurzen Tastendruck beim HM-LC-Sw1PBU-FM kein Event ausgelöst wird. Ich dachte das passiert, wenn ich R-KU.Schalter.LED_01-shActionType off setze. Stimmt aber nicht, es wird trotzdem immer wieder ein Event ausgelöst, auch, wenn das Licht selbst nicht geschaltet wird. Problem ist, ich reagiere auf das Event des HM-LC-Sw1PBU-FM mit einem DOIF, weil dieser beim ausschalten des Deckenlichts mittels des HM-LC-Sw1PBU-FM auch die LED Licht ausschalten soll.

Nun die Frage, wie muss ich die Reg setzen, dass bei einem kurzen Druck des HM-PB-2-WM55  beim HM-LC-Sw1PBU-FM kein Event ausgelöst wird? Ein event-on-change-reading klappt nicht, weil ich ja auf das Ausschalten drücken des HM-LC-Sw1PBU-FM auch reagieren will, wenn nur die LED Leisten an sind.

Ich weiß, liest sich sehr kompliziert, aber ich hoffe man kann es grob nachvollziehen. Wenn nicht sagt bescheid, dann versuche ich es nochmal anders zu erklären.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Beta-User

M.E. ist das "works as designed".

Das peering hat ja nichts damit zu tun, dass die Tastendrücke des Tasteres weiter von FHEM registriert werden.
Von daher ist "Short 2_211 (to VCCU)" völlig richtig. Ggf. mußt du die Regex anpassen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Amenophis86

Mir geht es darum, dass beim HM-LC-Sw1PBU-FM das Event state off ausgelöst wird. Das möchte ich unterbinden. Das die Taste gedrückt wird und daher short ... ausgelöst wird ist klar.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

frank

events werden in fhem erzeugt und dort kannst du sie auch unterdrücken.
nimm für dein doif ein besseres reading des aktors, zb percent und setze event-on-change-reading. dann kann es auch kein event geben, wenn sich der status nicht ändert.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Amenophis86

Zitat von: frank am 20 November 2017, 19:11:48
events werden in fhem erzeugt und dort kannst du sie auch unterdrücken.
nimm für dein doif ein besseres reading des aktors, zb percent und setze event-on-change-reading. dann kann es auch kein event geben, wenn sich der status nicht ändert.

Dann erklär mir doch bitte für was dann R-KU.Schalter.LED_01-shActionType off ist?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Pfriemler

#5
Die Einstellung
R-KU.Schalter.LED_01-shActionType off
im Aktor bewirkt, dass der Aktor beim Empfang eines Short-Triggers nichts ausführt. Gleich wohl sendet er seinen Status, quasi als Quittung ("ich hab's gehört aber ich mache nichts"). Diese Kommunikation hört FHEM nur mit, dort werden sowohl die Events des Tastendrucks als auch der Statusmeldung des Aktors ankommen, das kann auch nicht unterdrückt werden. Aber die Reaktion darauf kann man unterbinden: Beispielsweise reagieren notifys/DOIFs eben wie frank vorschlägt nur bei Änderung des "state", wenn das event-on-change-reading zumindest für state gesetzt ist.

Eben wegen der regelmäßigen Aktualisierung der readings bei Homematic-Geräten hat sich das event-on-change-reading .* quasi als Standardempfehlung durchgesetzt. Dann wird auch Dein DOIF nicht getriggert werden.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Amenophis86

Die Erklärung macht Sinn.

Ich muss aber auf das Reading State hören ohne event-on-change-reading, damit ich auch beim drücken der Aus Taste des HM-LC-Sw1PBU-FM die LED ausschalten kann, wenn die Lampe schon aus ist. Das würde dann nicht klappen. Muss mir also einen Workaround suchen.

Danke für die Info.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Pfriemler

Ach ich verstehe endlich. Du willst erreichen, dass die LED-Streifen ausgehen, wenn man entweder am Wandtaster oder aber auch am Wand-Aktor ausschaltet.
Die Jumptabelle zu verbiegen wird vermutlich auch nichts bringen.

Andererseits wird das Problem bestehenbleiben: angestoßene oder selbsttätige Aktualisierungen des Status werden regelmäßig ein Event "off" erzeugen. Der Workaround könnte vielleicht darin bestehen, beim Short am Wandaktor zusätzlich eine andere Aktion auszulösen, die FHEM mitbekommen kann. Beim Einschalten ginge das ja: Einschalten auf 30 Stunden und "timedOn" auswerten. Nur timedOff gibt es ja nicht...


"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Amenophis86

Genau das will ich. Sry, wohl nicht gut genug ausgedrückt. Habe aber jetzt meinen Workaround gefunden:

([KU.Decke.Licht:state] eq "off" and [KU.Decke.Licht:deviceMsg] eq "off (to VCCU)")
(set KU.LED.L off, set KU.LED.R off)


Ich muss zusätzlich auf das Reading deviceMsg achten. Dieses teilt mir mit, wo der Befehl herkommt. Damit schaltet das DOIF die LED aus, wenn Off direkt am Taster des HM-LC-Sw1PBU-FM gedrückt wurde und nicht auch, wenn lange die Taste des HM-PB-2-WM55 gedrückt wird was die Deckenlampe ausschalten würde (und ja das Event off erzeugt). Danke euch trotzdem für die Hilfe :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Pfriemler

Guter Ansatz, hat mich interessiert und habs nachgestellt. Interessanterweise erzeugt ein Tastendruck einer gepeerten Fernbedienung nach Aktion bei mir zunächst ein "on/off (to FB)", dann aber unmittelbar folgend auch "(to vccu)". Klappt das wirklich bei Dir?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Amenophis86

Hab gerade den PC runter gefahren um zu schauen. Kann aber morgen Abend nochmal schauen, ob vorher noch ein anderes Event kommt. Aber es klappt auf jeden Fall. Kommt der Befehl nämlich vom HM-PB-2-WM55 Stand dort (to KU.Schalter.LED_01) meine ich und nichts mit (to VCCU)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...