Verstehe deviceMsg nicht

[Amenophis86]

Folgende Situation. Ich habe einen HM-PB-2-WM55 welcher über FHEM ein LED Controller an und ausschaltet, wenn ich den Button 02 short drücke. Hier ein List des Kanal 02:

Code Auswählen Erweitern

Internals:
   DEF        59824302
   NAME       KU.Schalter.LED_02
   NOTIFYDEV  global
   NR         251
   NTFY_ORDER 50-KU.Schalter.LED_02
   STATE      Short 4_0 (to VCCU)
   TYPE       CUL_HM
   chanNo     02
   device     KU.Schalter.LED
   peerList   VCCU_Btn1,KU.Decke.Licht,
   READINGS:
     2019-01-11 17:01:05   R-KU.Decke.Licht_chn-01-expectAES off
     2019-01-11 17:01:05   R-KU.Decke.Licht_chn-01-peerNeedsBurst off
     2019-01-11 17:01:05   R-VCCU_Btn1-expectAES off
     2019-01-11 17:01:05   R-VCCU_Btn1-peerNeedsBurst off
     2019-01-11 17:01:03   R-sign          off
     2019-01-11 17:01:03   RegL_01.        00:00 04:10 08:00 09:00
     2019-01-11 17:01:05   RegL_04.KU.Decke.Licht_chn-01 00:00 01:00
     2019-01-11 17:01:05   RegL_04.VCCU_Btn1 00:00 01:00
     2019-04-06 12:56:28   peerList        VCCU_Btn1,KU.Decke.Licht,
     2019-04-23 19:36:35   state           Short 4_0 (to VCCU)
     2019-04-23 19:36:35   trigger         Short_0
     2019-04-23 19:36:35   triggerTo_KU.Decke.Licht Short_0
     2019-04-23 19:36:35   trigger_cnt     0
   helper:
     BNO        0
     BNOCNT     4
     regLst     ,1,4p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   group      Schalter
   model      HM-PB-2-WM55
   peerIDs    00000000,12345601,53F3EF01,
   room       Z_System->Homematic,Z_Räume->Küche
Das ganze wird mittels eines DOIF ausgeführt und funktioniert auch. Wenn ich lange drücke dann wird ein HM-LC-Sw1PBU-FM geschaltet, welcher direkt mit dem Schalter verbunden ist ohne FHEM. Hier ein List des HM-LC-Sw1PBU-FM:

Code Auswählen Erweitern


Historie löschen
Internals:
   CUL1_MSGCNT 272
   CUL1_RAWMSG A0E36A41053F3EF1234560601000032::-51:CUL1
   CUL1_RSSI  -51
   CUL1_TIME  2019-04-23 19:36:46
   DEF        53F3EF
   HMLAN1_MSGCNT 295
   HMLAN1_RAWMSG R4B457F3E,0001,5914C37D,FF,FFCD,36A41053F3EF1234560601000032
   HMLAN1_RSSI -51
   HMLAN1_TIME 2019-04-23 19:36:46
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     567
   NAME       KU.Decke.Licht
   NOTIFYDEV  global
   NR         215
   NTFY_ORDER 50-KU.Decke.Licht
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:36 - t:10 s:53F3EF d:123456 0601000032
   peerList   KU.Schalter.LED_01,KU.Schalter.LED_02,
   protLastRcv 2019-04-23 19:36:46
   protRcv    272 last_at:2019-04-23 19:36:46
   protSnd    232 last_at:2019-04-23 19:36:46
   protState  CMDs_done
   rssi_HMLAN1 cnt:27 min:-57 max:-50 avg:-52.07 lst:-50
   rssi_KU.Schalter.LED cnt:64 min:-75 max:-46 avg:-55.15 lst:-59
   rssi_at_CUL1 cnt:272 min:-74.5 max:-43 avg:-54.03 lst:-51
   rssi_at_HMLAN1 cnt:295 min:-64 max:-48 avg:-53.58 lst:-51
   READINGS:
     2019-04-23 19:36:35   CommandAccepted yes
     2019-01-11 00:10:23   D-firmware      2.8
     2019-01-11 00:10:23   D-serialNr      NEQ1736369
     2019-01-11 22:36:43   PairedTo        0x123456
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgActionType jmpToTarget
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgCtDlyOff geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgCtDlyOn geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgCtOff geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgCtOn geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgCtValHi 100
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgCtValLo 50
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgMultiExec on
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgOffDly 0 s
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgOffTime unused
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgOffTimeMode absolut
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgOnDly 0 s
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgOnTime unused
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgOnTimeMode absolut
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgSwJtDlyOff off
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgSwJtDlyOn on
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgSwJtOff dlyOn
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-lgSwJtOn dlyOff
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shActionType off
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shCtDlyOff geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shCtDlyOn geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shCtOff geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shCtOn geLo
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shCtValHi 100
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shCtValLo 50
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shMultiExec off
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shOffDly 0 s
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shOffTime unused
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shOffTimeMode absolut
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shOnDly 0 s
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shOnTime unused
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shOnTimeMode absolut
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shSwJtDlyOff off
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shSwJtDlyOn on
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shSwJtOff dlyOn
     2019-01-11 00:11:45   R-KU.Schalter.LED_01-shSwJtOn dlyOff
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgActionType jmpToTarget
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgCtDlyOff geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgCtDlyOn geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgCtOff geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgCtOn geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgCtValHi 100
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgCtValLo 50
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgMultiExec on
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgOffDly 0 s
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgOffTime unused
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgOffTimeMode absolut
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgOnDly 0 s
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgOnTime unused
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgOnTimeMode absolut
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgSwJtDlyOff off
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgSwJtDlyOn on
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgSwJtOff dlyOn
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-lgSwJtOn dlyOff
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shActionType off
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shCtDlyOff geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shCtDlyOn geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shCtOff geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shCtOn geLo
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shCtValHi 100
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shCtValLo 50
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shMultiExec off
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shOffDly 0 s
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shOffTime unused
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shOffTimeMode absolut
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shOnDly 0 s
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shOnTime unused
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shOnTimeMode absolut
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shSwJtDlyOff off
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shSwJtDlyOn on
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shSwJtOff dlyOn
     2019-01-11 00:11:52   R-KU.Schalter.LED_02-shSwJtOn dlyOff
     2019-01-11 00:11:39   R-intKeyVisib   invisib
     2019-01-11 00:11:39   R-localResDis   off
     2019-01-11 00:11:39   R-pairCentral   0x123456
     2019-01-11 22:36:44   R-powerUpAction off
     2019-01-11 22:36:44   R-sign          off
     2019-01-11 22:36:44   R-statusInfoMinDly 2 s
     2019-01-11 22:36:44   R-statusInfoRandom 1 s
     2019-01-11 22:36:44   R-transmitTryMax 6
     2019-01-11 22:36:42   RegL_00.        00:00 02:01 0A:12 0B:34 0C:56 15:FF 18:00
     2019-01-11 22:36:44   RegL_01.        00:00 08:00 30:06 56:00 57:24
     2019-01-11 22:36:45   RegL_03.KU.Schalter.LED_01 00:00 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
     2019-01-11 22:36:46   RegL_03.KU.Schalter.LED_02 00:00 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
     2019-04-23 19:36:46   deviceMsg       off (to VCCU)
     2019-04-23 19:36:46   level           0
     2019-04-23 19:36:46   pct             0
     2019-04-06 12:56:28   peerList        KU.Schalter.LED_01,KU.Schalter.LED_02,
     2019-01-11 22:36:41   powerOn         2019-01-11 22:36:41
     2019-04-23 19:36:46   recentStateType info
     2019-04-23 19:36:46   state           off
     2019-04-23 19:36:46   timedOn         off
     2019-04-23 19:36:35   trigLast        KU.Schalter.LED_02:short
     2019-04-23 19:30:16   trig_KU.Schalter.LED_01 Short_203
     2019-04-23 19:36:35   trig_KU.Schalter.LED_02 Short_0
   helper:
     HM_CMDNR   54
     cSnd       0112345653F3EF010E,0112345653F3EF010E
     dlvlCmd    ++A01112345653F3EF0201000000
     mId        0069
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +53F3EF,00,00,00
       nextSend   1556041006.8084
       rxt        0
       vccu       VCCU
       p:
         53F3EF
         00
         00
         00
       prefIO:
         HMLAN1
     mRssi:
       mNo        36
       io:
         CUL1:
           -51
           -51
         HMLAN1:
           -45
           -45
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL1
       flg        A
       ts         1556041006.70942
       ack:
         HASH(0x5844838)
         36800212345653F3EF00
     rssi:
       HMLAN1:
         avg        -52.0740740740741
         cnt        27
         lst        -50
         max        -50
         min        -57
       KU.Schalter.LED:
         avg        -55.15625
         cnt        64
         lst        -59
         max        -46
         min        -75
       at_CUL1:
         avg        -54.03125
         cnt        272
         lst        -51
         max        -43
         min        -74.5
       at_HMLAN1:
         avg        -53.5898305084745
         cnt        295
         lst        -51
         max        -48
         min        -64
     tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU:HMLAN1
   alexaName  Küchedeckenlicht
   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,59824302,
   room       Räume->Küche,Z_System->Homematic,Z_Räume->Küche,Z_System->alexa
   serialNr   NEQ1736369
   structexclude KU.Licht.Alle:.*
   subType    switch
   userattr   raum raum_map structexclude wohnung wohnung_map
   verbose    2
   webCmd     on:off

Nun habe ich noch ein DOIF, welches die LED ausschaltet, wenn ich das Deckenlicht direkt am HM-LC-Sw1PBU-FM ausschalte, selbst, wenn der HM-LC-Sw1PBU-FM bereits aus ist. Das funktioniert auch soweit.

Was ist das Problem. Der HM-LC-Sw1PBU-FM empfängt im Reading deviceMsg immer die Nachrichten des HM-PB-2-WM55, was zum Beispiel so aussieht:

Code Auswählen Erweitern

deviceMsg off (to KU.Schalter.LED) nach kurzer Zeit wechselt er dann nochmal

Code Auswählen Erweitern

deviceMsg off (to VCCU) ohne, dass irgendwas gedrückt wurde. Ich habe aber keine Ahnung wieso. Kann mir jemand erklären was das Problem ist und wie das Reading deviceMsg überhaupt arbeitet?

[martinp876]

deviceMsg ist nicht meine erste Wahl. Es wird angezeigt, an welche Entities der Kanal seinen Status sendet. Deine Darstellung ist also falsch:

KU.Decke.Licht: reading deviceMsg       off (to VCCU)

das Licht  hat "off" to - also in Richtung  - VCCU gesendet.

nach kurzer Zeit wechselt er dann nochmal

da wechselt nichts. Das Device muss die Peers und die Zentrale informieren. Die Zentrale immer. Den Peer von dem der Trigger kam.
Ein Peer sendet a) nie "on" oder "Off" sondern nur "trigger" und b) es steht nicht (from VCCU)  im Reading.

[Amenophis86]

ok jetzt verstehe ich für was es ist. Ich brauche allerdings deviceMsg für folgenden Funktion. Status HM-LC-Sw1PBU-FM = off, LEDs = on. Jetzt drücke ich den HM-LC-Sw1PBU-FM auf aus um die LEDs auszuschalten, weil der HM-LC-Sw1PBU-FM an einer anderen Stelle als der HM-PB-2-WM55 ist. Daher muss ich auf deviceMsg lauschen. Mal sehen, wie ich das umsetzen kann. Danke für die Info.

[martinp876]

Da du nur den status on\off sehen willst - es ist egal wem der aktor dies mitteilt- solltest du besser state oder level auswerten.
Devicemessage ist nur eine info für wenige user welche prüfen wollen, wem der aktor infos sendet.das lässt Rückschlüsse auf peerings und trigger zu. Für dich hier ungeeignet

[Amenophis86]

nicht ganz, weil wie will ich wissen, dass off gedrückt wurde, wenn er bereits auf off steht? Dies bekomme ich doch nur über devicemsg, oder? Und warum sendet er off obwohl er gar nicht gedrückt wurde und der 55 ihm auch kein Signal sendet?

[martinp876]

Grundsätzlich falsch verstanden.
Ein peer sendet nie nie nie off. Auch nie nie nie on. Wo hast du so etwas eingestellt? Es ist immer immer immer der aktor, der wissen muss was zu tun ist. ( Einzige Ausnahme ist das kommando aus der zentrale, das aber kein peer ist).

Also: der peer sensor sender einen trigger " ich bin gedrückt". Ein 3 state sensor könnte noch sagen "mein Zustand hat sich von 0 auf 50 geändert". Ein bewegungsmelder konnte sagen "bewegung erkannt, es ist 70 hell".
Mehr kommt nicht.

Die aktoren müssen entscheiden, was zu tun ist. Der aktor erkennt den trigger und weiss
Bei peer 1 trigger schalte ich an
Bei peer 2 aus
Bei peer 3 schalte ich um (toggle)
Bei peer 4 schaue ich erst einmal nach der helligkeit und entscheide dann, ob ich es auswerte. Wenn ja schalte ich für 10s an.

Die devicemesaage geht an die zentrale und den peer und sagt den neuen Zustand.
Der zustand selbst interessiert den peer nicht. Er kann damit nichts anfangen.er ist hat einfach dabei und die Zentrale kann es lesen.

Nenne mir einen einzigen fall, in dem die auswertung des state nicht das macht, was du willt, oder sich von devicemessage unterscheidet

[Amenophis86]

dann machen wir es so ich beschreibe dir was ich haben will und du sagst mir, wie es anders gehen kann.

Ich habe einen HM-PB-2-WM55, ein HM-LC-Sw1PBU-FM und einen LED Controller über WiFi verbunden. Wenn ich LED über den 55 anschalte will ich ihn, unabhängig vom Schaltstatus vom Sw1PBU mit diesem ausschalten können. Wenn der Sw1PBU von on auf off wechselt kein Problem, wenn der Sw1PBU schon aus ist, wird es allerdings zum Problem. Warum? Weil er nicht nochmal off sender bzw. ein Event auslöst. Deswegen kann ich nicht auf STATE bzw status lauschen und muss auf deviceMsg schauen.