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:
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:
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: deviceMsg off (to KU.Schalter.LED) nach kurzer Zeit wechselt er dann nochmal 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?
deviceMsg ist nicht meine erste Wahl. Es wird angezeigt, an welche Entities der Kanal seinen Status sendet. Deine Darstellung ist also falsch:
ZitatKU.Decke.Licht: reading deviceMsg off (to VCCU)
das Licht hat "off"
to - also in Richtung - VCCU gesendet.
Zitatnach 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.
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.
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
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?
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
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.