Hallo,
seit dieser Version gehen meine Schlüssel nicht mehr ->HM-RC-KEY4-2, obwohl ich nur eine Taste drücke, Sprechen alle Channels gleichzeitig an, und mein Türschloss will öffnen, schliessen, verrigeln und Licht geht an im Flur. Das war vorher nicht so. Ich habe jetzt Version 24031 eingespielt, jetzt ist alles wieder io.
Log:
2021.04.07 15:36:05 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:17
2021.04.07 15:36:05 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:05 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:16
2021.04.07 15:36:05 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:05 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:05 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:05 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:06 4: wait:RegisterRead got:02 :
nAddr:0
forChn:01
forPeer:
Pending:RegisterRead
forList:01
mNo:3
reSent:1
cmd:As1003A00194561251889501040000000001
2021.04.07 15:36:06 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:16
2021.04.07 15:36:06 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:06 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:15
2021.04.07 15:36:06 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:06 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:06 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:06 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:06 4: wait:PeerList got:01 :
Pending:PeerList
cmd:As0B04A0019456125188950103
reSent:1
forChn:01
mNo:4
2021.04.07 15:36:06 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:15
2021.04.07 15:36:06 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:06 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:14
2021.04.07 15:36:06 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:06 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:06 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:06 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:08 4: wait:RegisterRead got:02 :
forList:01
mNo:5
reSent:1
cmd:As1005A00194561251889502040000000001
nAddr:0
forChn:02
forPeer:
Pending:RegisterRead
2021.04.07 15:36:08 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:14
2021.04.07 15:36:08 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:08 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:13
2021.04.07 15:36:08 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:08 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:08 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:08 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:09 4: wait:PeerList got:01 :
reSent:1
cmd:As0B06A0019456125188950203
Pending:PeerList
mNo:6
forChn:02
2021.04.07 15:36:09 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:13
2021.04.07 15:36:09 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:09 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:12
2021.04.07 15:36:09 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:09 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:09 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:09 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:09 4: wait:RegisterRead got:02 :
Pending:RegisterRead
forPeer:
nAddr:0
forChn:03
reSent:1
cmd:As1007A00194561251889503040000000001
forList:01
mNo:7
2021.04.07 15:36:09 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:12
2021.04.07 15:36:09 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:09 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:11
2021.04.07 15:36:09 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:09 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:09 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:09 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:11 4: wait:PeerList got:01 :
forChn:03
mNo:8
Pending:PeerList
reSent:1
cmd:As0B08A0019456125188950303
2021.04.07 15:36:11 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:11
2021.04.07 15:36:11 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:11 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:10
2021.04.07 15:36:11 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:11 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:11 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:11 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:12 4: wait:RegisterRead got:02 :
cmd:As1009A00194561251889504040000000001
reSent:1
mNo:9
forList:01
Pending:RegisterRead
forPeer:
nAddr:0
forChn:04
2021.04.07 15:36:12 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:10
2021.04.07 15:36:12 5: CUL_HM SchluesselSandro sent ACK:2
2021.04.07 15:36:12 5: CUL_HM SchluesselSandro protEvent:CMDs_processing... pending:9
2021.04.07 15:36:12 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:12 5: CUL_HM set SchluesselSandro ?
2021.04.07 15:36:12 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:12 4: CUL_HM SchluesselSandro dupe: dont process
2021.04.07 15:36:13 4: wait:PeerList got:01 :
mNo:10
forChn:04
cmd:As0B0AA0019456125188950403
reSent:1
Pending:PeerList
Ich habe ähnliche Probleme gesehen. GetConfig von zB. Heizkörperthermostaten blieb hängen bzw. es wurden definitiv falsche Registerwerte ausgelesen.
Ich bin mir nicht mehr sicher, ob folgendes der Problemlöser war.
Vermutung die VCCU wurde verändert. Ein Versuch mit
set <VCCU> assignHmKey
könnte helfen.
Gruß HJB
Ich hänge mich hier mal dran...
Ich habe zwei 6-fach-Taster, die mit DOIFs abgefragt werden. Seid dem Update auf o.g. Version werden bei Betätigen eines beliebeigen Tasters die Funktionen aller Taster ausgeführt.
Hier ist mal die Definition eines Tasters:
Internals:
CFGFN ./FHEM/18_Schalter.cfg
DEF ([BD_T6_Btn_01] =~ "Short" and [?BD_Li_Sw_02] eq "Ein")(set BD_Li_Sw_02 off)
DOELSEIF
([BD_T6_Btn_01] =~ "Short" and [?BD_Li_Sw_02] eq "Aus")(set BD_Li_Sw_02 on)
DOELSEIF
([BD_T6_Btn_02] =~ "Short" and [?BD_Li_Sw_01] eq "Ein")(set BD_Li_Sw_01 off)
DOELSEIF
([BD_T6_Btn_02] =~ "Short" and [?BD_Li_Sw_01] eq "Aus")(set BD_Li_Sw_01 on)
FUUID 5c443da9-f33f-b425-6347-85572b0cf8dfc5af
MODEL FHEM
NAME BD_Licht
NOTIFYDEV BD_T6_Btn_01,BD_T6_Btn_02,global
NR 444
NTFY_ORDER 50-BD_Licht
STATE Decke Ein
TYPE DOIF
VERSION 24195 2021-04-08 21:50:20
READINGS:
2021-04-09 11:30:15 Device BD_T6_Btn_02
2021-04-09 11:30:15 cmd 4
2021-04-09 11:30:15 cmd_event BD_T6_Btn_02
2021-04-09 11:30:15 cmd_nr 4
2021-04-09 11:30:15 e_BD_T6_Btn_01_STATE Short 1_72 (to VCCU)
2021-04-09 11:30:15 e_BD_T6_Btn_02_STATE Short 1_30 (to VCCU)
2021-04-09 11:30:15 state Decke Ein
Regex:
accu:
collect:
cond:
BD_T6_Btn_01:
0:
&STATE ^BD_T6_Btn_01$
1:
&STATE ^BD_T6_Btn_01$
BD_T6_Btn_02:
0:
1:
2:
&STATE ^BD_T6_Btn_02$
3:
&STATE ^BD_T6_Btn_02$
attr:
cmdState:
0:
Spiegel Aus
1:
Spiegel Ein
2:
Decke Aus
3:
Decke Ein
wait:
waitdel:
condition:
0 ::InternalDoIf($hash,'BD_T6_Btn_01','STATE') =~ "Short" and ::InternalDoIf($hash,'BD_Li_Sw_02','STATE') eq "Ein"
1 ::InternalDoIf($hash,'BD_T6_Btn_01','STATE') =~ "Short" and ::InternalDoIf($hash,'BD_Li_Sw_02','STATE') eq "Aus"
2 ::InternalDoIf($hash,'BD_T6_Btn_02','STATE') =~ "Short" and ::InternalDoIf($hash,'BD_Li_Sw_01','STATE') eq "Ein"
3 ::InternalDoIf($hash,'BD_T6_Btn_02','STATE') =~ "Short" and ::InternalDoIf($hash,'BD_Li_Sw_01','STATE') eq "Aus"
do:
0:
0 set BD_Li_Sw_02 off
1:
0 set BD_Li_Sw_02 on
2:
0 set BD_Li_Sw_01 off
3:
0 set BD_Li_Sw_01 on
4:
helper:
DEVFILTER ^global$|^BD_T6_Btn_02$|^BD_T6_Btn_01$
NOTIFYDEV global|BD_T6_Btn_02|BD_T6_Btn_01
event commState: CMDs_done
globalinit 1
last_timer 0
sleeptimer -1
timerdev BD_T6_Btn_02
timerevent commState: CMDs_done
triggerDev BD_T6_Btn_02
DOIF_eventa:
cmd_nr: 4
cmd: 4
cmd_event: BD_T6_Btn_02
Decke Ein
DOIF_eventas:
cmd_nr: 4
cmd: 4
cmd_event: BD_T6_Btn_02
state: Decke Ein
timerevents:
commState: CMDs_done
timereventsState:
commState: CMDs_done
triggerEvents:
commState: CMDs_done
triggerEventsState:
commState: CMDs_done
internals:
all BD_T6_Btn_01:STATE BD_Li_Sw_02:STATE BD_T6_Btn_02:STATE BD_Li_Sw_01:STATE
perlblock:
readings:
trigger:
uiState:
uiTable:
Attributes:
cmdState Spiegel Aus|Spiegel Ein|Decke Aus|Decke Ein
disable 0
do always
room 004Bad
Beim kurzen Betätigen von T1 soll nur das Spiegellicht angehen, stattdessen kommen die folgenden Events:
2021-04-09 11:30:15 CUL_HM BD_T6 BD_T6_Btn_01 Short
2021-04-09 11:30:15 CUL_HM BD_T6 CMDs_done
2021-04-09 11:30:15 CUL_HM BD_Li commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_01 commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_02 commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Li CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_02 set_on noArg
2021-04-09 11:30:15 CUL_HM BD_Li commState: CMDs_processing...
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_01 commState: CMDs_processing...
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_02 commState: CMDs_processing...
2021-04-09 11:30:15 DOIF BD_Licht cmd_nr: 2
2021-04-09 11:30:15 DOIF BD_Licht cmd: 2
2021-04-09 11:30:15 DOIF BD_Licht cmd_event: BD_T6_Btn_01
2021-04-09 11:30:15 DOIF BD_Licht Spiegel Ein
2021-04-09 11:30:15 CUL_HM BD_T6_Btn_01 commState: CMDs_done
2021-04-09 11:30:15 CUL_HM BD_T6_Btn_01 Short 1_72 (to VCCU)
2021-04-09 11:30:15 CUL_HM BD_T6_Btn_01 trigger: Short_72
2021-04-09 11:30:15 CUL_HM BD_T6_Btn_01 trigger_cnt: 72
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_01 set_on noArg
2021-04-09 11:30:15 DOIF BD_Licht cmd_nr: 4
2021-04-09 11:30:15 DOIF BD_Licht cmd: 4
2021-04-09 11:30:15 DOIF BD_Licht cmd_event: BD_T6_Btn_02
2021-04-09 11:30:15 DOIF BD_Licht Decke Ein
2021-04-09 11:30:15 CUL_HM BD_T6_Btn_02 commState: CMDs_done
2021-04-09 11:30:15 CUL_HM BD_Luefter commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Luefter_Sw_01 commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM GB_Luefter_Sw_02 commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Luefter CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Luefter_Sw_01 set_off noArg
2021-04-09 11:30:15 CUL_HM BD_Luefter commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Luefter CMDs_pending
2021-04-09 11:30:15 DOIF BD_Vent_run cmd_nr: 1
2021-04-09 11:30:15 DOIF BD_Vent_run cmd: 1
2021-04-09 11:30:15 DOIF BD_Vent_run cmd_event: BD_Vent_Man
2021-04-09 11:30:15 DOIF BD_Vent_run Aus
2021-04-09 11:30:15 dummy BD_Vent_Man Aus
2021-04-09 11:30:15 DOIF BD_Vent_switch cmd_nr: 1
2021-04-09 11:30:15 DOIF BD_Vent_switch cmd: 1
2021-04-09 11:30:15 DOIF BD_Vent_switch cmd_event: BD_T6_Btn_03
2021-04-09 11:30:15 DOIF BD_Vent_switch Manuell Aus
2021-04-09 11:30:15 CUL_HM BD_T6_Btn_03 commState: CMDs_done
2021-04-09 11:30:16 CUL_HM BD_Luefter commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Luefter CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Luefter_Sw_01 set_on noArg
2021-04-09 11:30:16 CUL_HM BD_Luefter commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Luefter CMDs_pending
2021-04-09 11:30:16 DOIF BD_Vent_run cmd_nr: 2
2021-04-09 11:30:16 DOIF BD_Vent_run cmd_seqnr: 1
2021-04-09 11:30:16 DOIF BD_Vent_run cmd: 2.1
2021-04-09 11:30:16 DOIF BD_Vent_run cmd_event: BD_Vent_Man
2021-04-09 11:30:16 DOIF BD_Vent_run Manuell
2021-04-09 11:30:16 DOIF BD_Vent_run wait_timer: 09.04.2021 12:30:16 cmd_2_2 BD_Vent_Man
2021-04-09 11:30:16 dummy BD_Vent_Man Ein
2021-04-09 11:30:16 DOIF BD_Vent_switch cmd_nr: 2
2021-04-09 11:30:16 DOIF BD_Vent_switch cmd: 2
2021-04-09 11:30:16 DOIF BD_Vent_switch cmd_event: BD_T6_Btn_04
2021-04-09 11:30:16 DOIF BD_Vent_switch Manuell Toggle
2021-04-09 11:30:16 CUL_HM BD_T6_Btn_04 commState: CMDs_done
2021-04-09 11:30:16 CUL_HM BD_Rola commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Rola set_off noArg
2021-04-09 11:30:16 CUL_HM BD_Rola commState: CMDs_pending
2021-04-09 11:30:16 DOIF BD_Rola_switch cmd_nr: 3
2021-04-09 11:30:16 DOIF BD_Rola_switch cmd: 3
2021-04-09 11:30:16 DOIF BD_Rola_switch cmd_event: BD_T6_Btn_05
2021-04-09 11:30:16 DOIF BD_Rola_switch Auf
2021-04-09 11:30:16 CUL_HM BD_T6_Btn_05 commState: CMDs_done
2021-04-09 11:30:16 CUL_HM BD_Rola commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Rola set_on noArg
2021-04-09 11:30:16 CUL_HM BD_Rola commState: CMDs_pending
2021-04-09 11:30:16 DOIF BD_Rola_switch cmd_nr: 4
2021-04-09 11:30:16 DOIF BD_Rola_switch cmd: 4
2021-04-09 11:30:16 DOIF BD_Rola_switch cmd_event: BD_T6_Btn_06
2021-04-09 11:30:16 DOIF BD_Rola_switch Stop
2021-04-09 11:30:16 CUL_HM BD_T6_Btn_06 commState: CMDs_done
2021-04-09 11:30:16 CUL_HM Melde_LED trigLast: BD_T6_Btn_01:short
2021-04-09 11:30:16 CUL_HM Melde_LED trig_BD_T6_Btn_01: Short_72
2021-04-09 11:30:16 CUL_HM BD_Li commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Li CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_01 commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_02 commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_02 deviceMsg: Ein (to VCCU)
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_02 level: 100
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_02 pct: 100
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_02 Ein
2021-04-09 11:30:16 HMLAN HMLAN1 loadLvl: low
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_01 commState: CMDs_processing...
2021-04-09 11:30:16 CUL_HM BD_Li commState: CMDs_done
2021-04-09 11:30:16 CUL_HM BD_Li CMDs_done
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_01 commState: CMDs_done
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_01 deviceMsg: Ein (to VCCU)
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_01 level: 100
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_01 pct: 100
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_01 Ein
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_02 commState: CMDs_processing...
2021-04-09 11:30:16 CUL_HM BD_Li_Sw_02 commState: CMDs_done
2021-04-09 11:30:16 CUL_HM BD_Luefter_Sw_01 commState: CMDs_processing...
2021-04-09 11:30:16 CUL_HM BD_Luefter commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Luefter CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Luefter_Sw_01 commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Luefter_Sw_01 Aus
2021-04-09 11:30:16 CUL_HM GB_Luefter_Sw_02 commState: CMDs_processing...
2021-04-09 11:30:16 CUL_HM GB_Luefter_Sw_02 commState: CMDs_pending
2021-04-09 11:30:16 CUL_HM BD_Luefter_Sw_01 commState: CMDs_processing...
2021-04-09 11:30:17 CUL_HM BD_Luefter commState: CMDs_pending
2021-04-09 11:30:17 CUL_HM BD_Luefter CMDs_pending
2021-04-09 11:30:17 CUL_HM BD_Luefter_Sw_01 commState: CMDs_pending
2021-04-09 11:30:17 CUL_HM BD_Luefter_Sw_01 deviceMsg: Ein (to VCCU)
2021-04-09 11:30:17 CUL_HM BD_Luefter_Sw_01 level: 100
2021-04-09 11:30:17 CUL_HM BD_Luefter_Sw_01 pct: 100
2021-04-09 11:30:17 CUL_HM BD_Luefter_Sw_01 Ein
2021-04-09 11:30:17 CUL_HM GB_Luefter_Sw_02 commState: CMDs_processing...
2021-04-09 11:30:17 CUL_HM GB_Luefter_Sw_02 commState: CMDs_pending
2021-04-09 11:30:17 CUL_HM BD_Luefter_Sw_01 commState: CMDs_processing...
2021-04-09 11:30:17 CUL_HM BD_Luefter commState: CMDs_done
2021-04-09 11:30:17 CUL_HM BD_Luefter CMDs_done
2021-04-09 11:30:17 CUL_HM BD_Luefter_Sw_01 commState: CMDs_done
2021-04-09 11:30:17 CUL_HM GB_Luefter_Sw_02 commState: CMDs_processing...
2021-04-09 11:30:17 CUL_HM GB_Luefter_Sw_02 commState: CMDs_done
2021-04-09 11:30:17 CUL_HM BD_Rola commState: CMDs_processing...
2021-04-09 11:30:17 CUL_HM BD_Rola trigLast: fhem:02
2021-04-09 11:30:17 CUL_HM BD_Rola trigLast: fhem:02
2021-04-09 11:30:17 CUL_HM BD_Rola commState: CMDs_pending
2021-04-09 11:30:17 CUL_HM BD_Rola deviceMsg: 99.5 (to VCCU)
2021-04-09 11:30:17 CUL_HM BD_Rola level: 99.5
2021-04-09 11:30:17 CUL_HM BD_Rola motor: down:99.5
2021-04-09 11:30:17 CUL_HM BD_Rola pct: 99.5
2021-04-09 11:30:17 CUL_HM BD_Rola 99.5
2021-04-09 11:30:17 CUL_HM BD_Rola timedOn: Zu
2021-04-09 11:30:17 CUL_HM BD_Rola commState: CMDs_processing...
2021-04-09 11:30:17 CUL_HM BD_Rola trigLast: fhem:02
2021-04-09 11:30:17 CUL_HM BD_Rola trigLast: fhem:02
2021-04-09 11:30:18 CUL_HM BD_Rola commState: CMDs_done
2021-04-09 11:30:18 CUL_HM BD_Rola deviceMsg: 97.5 (to VCCU)
2021-04-09 11:30:18 CUL_HM BD_Rola level: 97.5
2021-04-09 11:30:18 CUL_HM BD_Rola motor: up:97.5
2021-04-09 11:30:18 CUL_HM BD_Rola pct: 97.5
2021-04-09 11:30:18 CUL_HM BD_Rola 97.5
2021-04-09 11:30:18 CUL_HM BD_Rola timedOn: Zu
Im normalen log sieht das so aus (Achtung Reverse Log!):
2021.04.09 11:30:16 3: CUL_HM BD_Luefter_Sw_01 repeat, level 00 instead of C8
2021.04.09 11:30:16 3: CUL_HM set BD_Rola on noArg
2021.04.09 11:30:16 3: CUL_HM set BD_Rola off noArg
2021.04.09 11:30:16 1: Vent ist Aus
2021.04.09 11:30:16 3: CUL_HM set BD_Luefter_Sw_01 on noArg
2021.04.09 11:30:16 1: Vent ist manuell ein bei: 56 %
2021.04.09 11:30:15 1: Vent ist aus bei: 56 %
2021.04.09 11:30:15 3: CUL_HM set BD_Luefter_Sw_01 off noArg
2021.04.09 11:30:15 3: CUL_HM set BD_Li_Sw_01 on noArg
2021.04.09 11:30:15 3: CUL_HM set BD_Li_Sw_02 on noArg
Ich werde mal auf die vorherige Version zurückgehen und berichten...
Das Ergebnis ist wie bei sepultura30- mit der alten Version funzt es wieder.
@locodriver Gut gemeinter Rat zur Auswertung von HM Tastern:
Grundlegend: werte nicht den Zustand von state aus! Durch den state blubbert alles mögliche, das kann eigentlich nur schief gehen!
mMn gibt es diese Events die man bei den Tasten sinnvoll auswerten kann (ich habe es mal versucht in DOIF umzusetzen - garantiere nicht dafür, ich glaube als notify ist sowas einfacher):
1. entweder im Hauptdevice den Event mit Channel Name und Short -> 2021-04-09 11:30:15 CUL_HM BD_T6 BD_T6_Btn_01 Short -> ["^BD_T6$:^BD_T6_Btn_01 Short$"]
2. Oder im Channeldevice den Event mit Short -> 2021-04-09 11:30:15 CUL_HM BD_T6_Btn_01 Short 1_72 (to VCCU) ->["^BD_T6_Btn_01$:^Short"]
oder den Event mit dem trigger Reading -> 2021-04-09 11:30:15 CUL_HM BD_T6_Btn_01 trigger: Short_72 -> ["^BD_T6_Btn_01$:^trigger: Short"]
Doku https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events
Ist das BD_Li_Sw_01 auch Homematic? Wenn ja warum hast Du die nicht einfach gepeert?
@Otto123: danke für die Tipps - das werde ich mir mal ansehen.
Der Aktor ist ein HM-Doppelschalter. Peering geht nicht, weil der Aktor direkt hinter dem Taster sitzt und es damit zu Problemen bei der Funkübertragung kommt... außerdem ist jede Taste dopplt belegt - hier wird durch langen Tastendruck noch ein dummy geschaltet.
All das löst aber das Problem mit der HM-CUL-Version 24158 nicht...
Ich habe die gleichen Fehlererscheinungen, habe diesen Beitrag aber zu spät entdeckt und möchte nicht doppelt posten.
Meine Fehlerbeschreibung steht dort: [version nach 6.4.21] cul_hm bringt fhem zum absturz
https://forum.fhem.de/index.php/topic,120202.msg1147234.html#msg1147234 (https://forum.fhem.de/index.php/topic,120202.msg1147234.html#msg1147234)
Gruß aus Köln
Norbert
Zitat von: locodriver am 09 April 2021, 12:15:34
All das löst aber das Problem mit der HM-CUL-Version 24158 nicht...
Bei mir so gelöst
exclude_from_update 10_CUL_HM.pm 98_HMinfo.pm HMConfig.pm :D
Aber das Problem bei Dir
Zitatbei Betätigen eines beliebeigen Tasters die Funktionen aller Taster ausgeführt.
muss ja irgendwie an den Events liegen - die ändern sich im letzten Jahr gefühlt mit jeder Version -
BTW: ich habe den Doppelschalter in der Up Dose und den 6 fach Taster oben drauf. Beide sind gepeert, das ist offenbar wie mit der Hummel (die ist auch theoretisch zu schwer ;) )
Und "Doppelbelegung" mit Auswertung von Long geht auch nach dem peeren :)
"exclude" ist ja nicht die Lösung sondern eine "ad-hoc-Maßnahme", bis Martin hoffentlich das Problem lösen kann. Aber ich werde das erstmal auch so machen...
Mit dem Peeren hatte ich es auch vor (vielen) Jahren mal probiert - allerdings eben ohne Erfolg...
Bei dem andern Taster funzt es, da sind aber ca. 2 m Luftlinie zwischen Taster und Aktor.
2021-04-09 11:30:15 CUL_HM BD_Li commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_01 commState: CMDs_pending
2021-04-09 11:30:15 CUL_HM BD_Li_Sw_02 commState: CMDs_pending
das sieht mir auf alle fälle seltsam aus, da ich das reading commState nur im hauptdevice erwarten würde.
habe ich bei mir auch gerade in einem DIM1TPBU in allen 3 channeln entdeckt.
das sollte allerdings keine wirkung auf das doif haben, falls meine rudimentären doif kenntnisse dafür ausreichen.
ich verstehe schon nicht, warum der erste event vom taster-hauptdevice bereits das doif triggert:
2021-04-09 11:30:15 CUL_HM BD_T6 BD_T6_Btn_01 Short
hat hier nicht doif ein problem?
@otto123
du nutzt ja gerne alte cul_hm versionen.
findest du bei dir in multi-channel-aktoren auch in allen channels das reading commState?
erledigt, schon gefunden.
soweit ich DOIF verstehe:
Jeder Event im Device BD_T6_Btn_01 und BD_T6_Btn_02 triggert das DOIF und anschließend wird STATE gelesen und ausgewertet. Da dort immer Short irgendwas drinsteht, ist es immer mehr oder weniger ein Zufall welcher Zweig gerade trifft.
Wenn das bisher funktioniert hat (was mich wundert) muss das ein - für den DOIF Ersteller glücklicher - Umstand gewesen sein, quasi eine von Voodo erzeugte richtige Reihenfolge an Events.
Nach dem Update ist der Blubber im STATE nicht mehr dem Voodo Zauber erlegen und es geht schief. Meine pauschale Einschätzung, die muss nicht stimmen!
Das ist eigentlich auch genau in dem Fall das Ungute am DOIF mit STATE Auswertung: man weiß eigentlich nicht was passiert. Mit einem notify wäre man mMn gar nicht auf die Idee gekommen - man wertet dort als Erstes den Event aus. ;)
Und DOIF hat laut Readings ja auch genau zur gleichen Zeit zwei Events bekommen (was eigentlich auch verrückt ist?):
2021-04-09 11:30:15 e_BD_T6_Btn_01_STATE Short 1_72 (to VCCU)
2021-04-09 11:30:15 e_BD_T6_Btn_02_STATE Short 1_30 (to VCCU)
NB: dass man zwischen zwei Homematic Komponenten mindestens 50cm Abstand einhalten soll, steht in der Bedienungsanleitung von Homematic Geräten
@Otto123: die zwei Events kommen m.M.n. aus der fehlerhaften HM-CUL-Software. Denn wenn ich jetzt den Taster kurz drücke, dann kommt folgendes:
2021-04-09 15:28:13 CUL_HM BD_T6 BD_T6_Btn_01 Short
2021-04-09 15:28:13 CUL_HM BD_T6 CMDs_done
2021-04-09 15:28:13 CUL_HM BD_Li commState: CMDs_pending
2021-04-09 15:28:13 CUL_HM BD_Li CMDs_pending
2021-04-09 15:28:13 CUL_HM BD_Li_Sw_02 set_on noArg
2021-04-09 15:28:13 CUL_HM BD_Li commState: CMDs_processing...
2021-04-09 15:28:13 DOIF BD_Licht cmd_nr: 2
2021-04-09 15:28:13 DOIF BD_Licht cmd: 2
2021-04-09 15:28:13 DOIF BD_Licht cmd_event: BD_T6_Btn_01
2021-04-09 15:28:13 DOIF BD_Licht Spiegel Ein
2021-04-09 15:28:13 CUL_HM BD_T6_Btn_01 Short 1_80 (to VCCU)
2021-04-09 15:28:13 CUL_HM BD_T6_Btn_01 trigger: Short_80
2021-04-09 15:28:13 CUL_HM BD_T6_Btn_01 trigger_cnt: 80
2021-04-09 15:28:13 CUL_HM Melde_LED trigLast: BD_T6_Btn_01:short
2021-04-09 15:28:13 CUL_HM Melde_LED trig_BD_T6_Btn_01: Short_80
2021-04-09 15:28:13 CUL_HM BD_Li commState: CMDs_done
2021-04-09 15:28:13 CUL_HM BD_Li CMDs_done
2021-04-09 15:28:13 CUL_HM BD_Li_Sw_02 deviceMsg: Ein (to VCCU)
2021-04-09 15:28:13 CUL_HM BD_Li_Sw_02 level: 100
2021-04-09 15:28:13 CUL_HM BD_Li_Sw_02 pct: 100
2021-04-09 15:28:13 CUL_HM BD_Li_Sw_02 Ein
Es wird also - wie erwartet - nur Button1 ausgewertet...
@betateilechen: eben... Otto hat warscheinlich Glück, dass es bei ihm trotzdem funzt. Eventuell kann man ja versuchen, mit "Abstand" zu peeren und dann Taster und Aktor wieder näher zusammen zu bringen. Ob das dann aber später immer funzt...?
@Otto123
Ich habe das mit dem DOIF nicht ganz kappiert. Bisher habe ich "fast" alles mit DOIF erledigt und bei mir hat das tatsächlich bis zum Update der 10_CUL_HM funktioniert. Ich habe z.B. die Abfrage eines 8-fach HM Switch, der ebenfalls über eine FB mit DOIF short/long geschaltet wird, so angelegt:
define Anlage_Wohnzimmer_Text_di DOIF ([Television_Sw_01:"Ein"]) (set Television_Text on)DOELSEIF([Television_Sw_01:"Aus"]) (set Television_Text off)DOELSEIF([AV_Receiver_Sw_02] eq "Ein") (set AV_Receiver_Text on)DOELSEIF([AV_Receiver_Sw_02] eq "Aus") (set AV_Receiver_Text off)DOELSEIF([Blu_Ray_Player_Sw_03] eq "Ein") (set Blu_Ray_Player_Text on)DOELSEIF([Blu_Ray_Player_Sw_03] eq "Aus") (set Blu_Ray_Player_Text off)DOELSEIF([Kodi_Sw_04] eq "Ein" and [Kodi_Sw_04:timedOn] eq "off") (set Kodi_Text on)DOELSEIF([Kodi_Sw_04] eq "Aus" or [Kodi_Sw_04] eq "off") (set Kodi_Text off)DOELSEIF([Kodi_Sw_04:timedOn] eq "running") (set Kodi_Text dim25%)DOELSEIF([Ambilight_Sw_05] eq "Ein") (set Ambilight_Text on)DOELSEIF([Ambilight_Sw_05] eq "Aus") (set Ambilight_Text off)DOELSEIF([AV_Switch_Sw_06] eq "Ein") (set AV_Switch_Text on)DOELSEIF([AV_Switch_Sw_06] eq "Aus") (set AV_Switch_Text off)DOELSEIF([Phono_Sw_07] eq "Ein") (set Phono_Text on)DOELSEIF([Phono_Sw_07] eq "Aus") (set Phono_Text off)DOELSEIF([Dreambox_Sw_08] eq "Ein") (set Dreambox_Text on)DOELSEIF([Dreambox_Sw_08] eq "Aus") (set Dreambox_Text off)DOELSE
Ist das jetzt falsch oder richtig? oder muß ich daran was ändern?
Gruß
Norbert
Zitat von: Otto123 am 09 April 2021, 15:06:25
soweit ich DOIF verstehe:
Jeder Event im Device BD_T6_Btn_01 und BD_T6_Btn_02 triggert das DOIF und anschließend wird STATE gelesen und ausgewertet. Da dort immer Short irgendwas drinsteht, ist es immer mehr oder weniger ein Zufall welcher Zweig gerade trifft.
genau das würde ich auch denken.
aber der erste event, der das doif triggert, kommt vom hauptdevice
BD_T6Zitat2021-04-09 11:30:15 CUL_HM BD_T6 BD_T6_Btn_01 Short
der devicename vom button steht ja nur im "state".
oder die abfolge der gezeigten events ist falsch.
sind die events überhaupt aus dem eventmonitor?
aber doif ist mir eh zu kompliziert.
Naja fehlerhafte Software ist Ansichtssache, es kommen unnütze Events in der Art für alle Channel
2021-04-09 11:30:15 CUL_HM BD_T6_Btn_03 commState: CMDs_done
Der Fehler liegt eindeutig daran diese auszuwerten! Die Auswertung in deinem DOIF ist "ungünstig". ;D
@cocojambo [Television_Sw_01:"Ein"] regiert auf einen Event wo Ein bzw. Aus vorkommt. Musst Du mit eventMap gemacht haben? Klingt an sich gut.
@Otto123
Ja, jeden einzelnen Schaltkanal habe ich so gestaltet:
define Television_Sw_01 CUL_HM 70D3BA01
setuuid Television_Sw_01 5fe085f6-f33f-6f9b-88d2-17c56fd1fd02ecf4
attr Television_Sw_01 alias Fernsehgerät
attr Television_Sw_01 devStateIcon .*Ein:it_television@green .*Aus:it_television@red
attr Television_Sw_01 event-on-change-reading .*
attr Television_Sw_01 eventMap on:Ein off:Aus
attr Television_Sw_01 group Wohnzimmer
attr Television_Sw_01 model HM-MOD-RE-8
attr Television_Sw_01 onOffDevice true
attr Television_Sw_01 peerIDs peerUnread
attr Television_Sw_01 room Wohnzimmer
attr Television_Sw_01 webCmd Ein:Aus
und dann so den Switch geschaltet:
define FB_Anlage_Wohnzimmer_di DOIF ([FB_Anlage_Wohnzimmer_Btn_01] =~ "Short") (set Television_Sw_01 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_01] =~ "Long") (set Television_Sw_01 Aus)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_02] =~ "Short") (set AV_Receiver_Sw_02 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_02] =~ "Long") (set AV_Receiver_Sw_02 Aus)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_03] =~ "Short") (set Blu_Ray_Player_Sw_03 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_03] =~ "Long") (set Blu_Ray_Player_Sw_03 Aus)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_04] =~ "Short") (set Kodi_Sw_04 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_04] =~ "Long") (set Kodi_Sw_04 on-for-timer 30)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_05] =~ "Short") (set Ambilight_Sw_05 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_05] =~ "Long") (set Ambilight_Sw_05 Aus)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_06] =~ "Short") (set AV_Switch_Sw_06 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_06] =~ "Long") (set AV_Switch_Sw_06 Aus)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_07] =~ "Short") (set Phono_Sw_07 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_07] =~ "Long") (set Phono_Sw_07 Aus)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_08] =~ "Short") (set Dreambox_Sw_08_dummy Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_08] =~ "Long") (set Dreambox_Sw_08_dummy Stby)DOELSE
und die Auswertung habe ich ja schon vorher gepostet.
Aber wenn ich das Update gemacht habe, spinnt FHEM total und sendet dann ständig alle Text Befehle endlos zum FS20SIG und dann ist schnell das Funk Maximum erreicht und es geht nix mehr.
2021.04.09 10:38:40 3: CUL_HM set AV_Receiver_Sw_02 on noArg
2021.04.09 10:38:40 3: FS20 set AV_Receiver_Text off
2021.04.09 10:38:40 3: FS20 set AV_Switch_Text off
2021.04.09 10:38:40 3: FS20 set Ambilight_Text off
2021.04.09 10:38:40 3: FS20 set Blu_Ray_Player_Text off
2021.04.09 10:38:40 3: FS20 set Dreambox_Text on
2021.04.09 10:38:40 3: FS20 set Kodi_Text on
2021.04.09 10:38:40 3: FS20 set Phono_Text off
2021.04.09 10:38:40 3: FS20 set AV_Switch_Text off
2021.04.09 10:38:40 3: FS20 set Ambilight_Text off
2021.04.09 10:38:41 3: FS20 set Blu_Ray_Player_Text off
2021.04.09 10:38:41 3: FS20 set Dreambox_Text on
2021.04.09 10:38:41 3: FS20 set Kodi_Text on
2021.04.09 10:38:41 3: FS20 set Phono_Text off
2021.04.09 10:38:41 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:41 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:41 3: FS20 set AV_Receiver_Text on
2021.04.09 10:38:41 3: FS20 set AV_Switch_Text off
2021.04.09 10:38:41 3: FS20 set Ambilight_Text off
2021.04.09 10:38:41 3: FS20 set Blu_Ray_Player_Text off
2021.04.09 10:38:41 3: FS20 set Dreambox_Text on
2021.04.09 10:38:41 3: FS20 set Kodi_Text on
2021.04.09 10:38:41 3: FS20 set Phono_Text off
2021.04.09 10:38:41 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:41 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:42 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:42 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:42 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:43 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:43 3: CUL: Unknown code LOVF, help me!
2021.04.09 10:38:43 3: CUL: Unknown code LOVF, help me!
Installiere ich aber wieder das Modul "10_CUL_HM.pm 24031 2021-03-21 09", geht alles wieder.
Es kann doch dann nur mit dem Modul zusammenhängen oder?
Vor allen Dingen, was kann ich ändern, damit es wieder funktioniert?
Gruß aus Köln
Norbert
Moin Norbert,
hilft es wenn du dein DOIF etwas umbaust?
define FB_Anlage_Wohnzimmer_di DOIF ([FB_Anlage_Wohnzimmer_Btn_01:trigger] =~ "Short") (set Television_Sw_01 Ein)DOELSEIF([FB_Anlage_Wohnzimmer_Btn_01:trigger] =~ "Long")....
Gruss
Enno
Nein hilft leider nicht, denn wenn ich auch manuell in der Kommando Zeile
set Television_Sw_01 Ein
eingebe, passiert genau dasselbe.
Der Fehler tritt wahrscheinlich erst in der Auswertung des Switches auf, wenn die "Texte" zum FS20SIG gesendet werden sollen.
Gruß
Norbert
Das meine ich aber auch, das kann ja nur an der Auswertung liegen, die die FS20 Befehle absetzt!
Nochmal die gleiche Erklärung: Der hier [Kodi_Sw_04:timedOn] eq "off" wir von irgendeinem Event auf Kodi_Sw_04 getriggert und anschließend wird das Reading timedOn ausgewertet.
Alles klar: jetzt kommen diese SINNLOSEN neuen Events mit commState, die triggern und die Abfrage wird ausgelöst.
Also: wertet bitte keine Zustände sondern die Events aus, eventuell so - man müsste den Event genau sehen: [Kodi_Sw_04:"^timedOn: off$"]
OT
Zitat"exclude" ist ja nicht die Lösung sondern eine "ad-hoc-Maßnahme",
Mir kommt CUL_HM seit einem Jahr wie ein ewiges Tischtennisspiel vor:
martin gegen frank und die anderen spielen Chinesisch (rennen um die Platte)
- martin hat immer Angabe
- er spielt den Ball und frank spielt zurück.
- Nach eine paar Ballwechseln klappt martin seine Hälfte der Platte hoch und frank spielt ruhig weiter gegen die Wand.
- Irgendwann macht frank Pause, jetzt kommend die Anderen und spielen Chinesisch.
- In jeder Runde fliegt einer raus - ... mit exclude ;D
- Dann kommt wieder martin, klappt seine Hälfte runter und hat wieder Angabe
Ich bewundere frank und sein Durchhaltevermögen 👏
Zitat von: Otto123 am 09 April 2021, 18:31:33
OT Mir kommt CUL_HM seit einem Jahr wie ein ewiges Tischtennisspiel vor:
;D ich spiel auch nur an der Nachbarplatte. => exclude und Update erst wenn min 2 Wochen keine Einträge im Forum...
@Norbert: kannst du im Event Monitor erkennen mit welchen "state" der Zirkus los geht? Ich denke bei HM muss man inzwischen sehr genau auswerten, sonst gibt das mächtig viel Beifang.
Gruss
Enno
@Norbert schau mal ob es so wird (nur die DEF)
(["^Television_Sw_01$:^Ein"]) (set Television_Text on)DOELSEIF
(["^Television_Sw_01$:^Aus"]) (set Television_Text off)DOELSEIF
(["^AV_Receiver_Sw_02$:^Ein"]) (set AV_Receiver_Text on)DOELSEIF
(["^AV_Receiver_Sw_02$:^Aus"]) (set AV_Receiver_Text off)DOELSEIF
(["^Blu_Ray_Player_Sw_03$:^Ein"]) (set Blu_Ray_Player_Text on)DOELSEIF
(["^Blu_Ray_Player_Sw_03$:^Aus"]) (set Blu_Ray_Player_Text off)DOELSEIF
(["^Kodi_Sw_04$:^Ein" and [?Kodi_Sw_04:timedOn] eq "off"]) (set Kodi_Text on)DOELSEIF
(["^Kodi_Sw_04$:^Aus" or ["^Kodi_Sw_04$:^off"]) (set Kodi_Text off)DOELSEIF
(["^Kodi_Sw_04$:^timedOn: running"]) (set Kodi_Text dim25%)DOELSEIF
(["^Ambilight_Sw_05$:^Ein"]) (set Ambilight_Text on)DOELSEIF
(["^Ambilight_Sw_05$:^Aus"]) (set Ambilight_Text off)DOELSEIF
(["^AV_Switch_Sw_06$:^Ein"]) (set AV_Switch_Text on)DOELSEIF
(["^AV_Switch_Sw_06$:^Aus"]) (set AV_Switch_Text off)DOELSEIF
(["^Phono_Sw_07$:^Ein"]) (set Phono_Text on)DOELSEIF
(["^Phono_Sw_07$:^Aus"]) (set Phono_Text off)DOELSEIF
(["^Dreambox_Sw_08$:^Ein"]) (set Dreambox_Text on)DOELSEIF
(["^Dreambox_Sw_08$:^Aus"]) (set Dreambox_Text off)DOELSE
Edit: die ] ergänzt ;D danke fürs drauf schauen
nur ned die ganzen eckigen end-klammern vergessen, die da teilweise fehlen *g*
kann ich mich im club der doif-geschädigten hm-user anmelden?
hat schon wer ärztliche betreuung - wer meinen leidensweg braucht: https://forum.fhem.de/index.php/topic,120202.0.html
nachtrag: jaja, das copy&paste ... warum sollts nur mir so gehen? *bg*
übrigens - irgendwie hab ich grad das wichtigste vergessen:
kann man schon mal festlegen, auf was bei einem doif zu achten ist, dass der neue herr cul_hm keine probleme mehr bereitet?
und nö, die doif's zeigen tu ich euch nicht an ... ich rede hier von ca. 25 doif's, die sich teilweise gegenseitig beeinflussen. ist halt alles im laufe von jahren gewachsen und ich blick da selber nicht mehr wirklich durch.
Hallo zusammen,
ich habe auch wieder zurück rudern müssen, da meine Beleuchtung Disco spielt in Verbindung mit dem Bewegungsmelder. Geht eine halbe Sekunde an und wieder aus anstatt aus zu bleiben wenn es hell genug ist... Ich habe ein Notify dafür:
FlurEGBewegungsmelder_M:motion:.*
{
if ((Value("Treppenbeleuchtung") eq "off") &&
(ReadingsVal("FlurEGBewegungsmelder_M","state","0") eq "motion") &&
(ReadingsVal("FlurEGBewegungsmelder_M","brightness","80") < "100") &&
(
(ReadingsVal("rr_Chris","state","") eq "home") ||
(ReadingsVal("rr_Anja","state","") eq "home") )
)
{
fhem ("set Treppenbeleuchtung on-for-timer 240")
}
}
Das ging 5 Jahre so... seid gestern nicht mehr... :-O
@MegaData das verwundert mich jetzt. Kannst Du dazu bitte mal die Folge der Events posten Filter: FlurEGBewegungsmelder_M.* ?
@enno
Als erstes wird logischerweise der Befehl
CUL_HM set Television_Sw_01 off
ausgeführt. Dann müßte eigendlich der Befehl für die Textausführung "set Television_Text on" folgen, tut es aber nicht.
Stattdessen werden alle anderen "set....Text" Befehle in der gleichen Reihenfolge bis LOVF ausgeführt.
2021.04.10 11:16:58 3: CUL_HM set Television_Sw_01 off noArg
2021.04.10 11:16:58 3: FS20 set AV_Receiver_Text off
2021.04.10 11:16:58 3: FS20 set AV_Switch_Text off
2021.04.10 11:16:58 3: FS20 set Ambilight_Text off
2021.04.10 11:16:58 3: FS20 set Blu_Ray_Player_Text off
2021.04.10 11:16:58 3: FS20 set Dreambox_Text on
2021.04.10 11:16:58 3: FS20 set Kodi_Text off
2021.04.10 11:16:58 3: FS20 set Phono_Text off
2021.04.10 11:16:58 3: FS20 set AV_Receiver_Text off
2021.04.10 11:16:58 3: FS20 set AV_Switch_Text off
2021.04.10 11:16:58 3: FS20 set Ambilight_Text off
2021.04.10 11:16:58 3: FS20 set Blu_Ray_Player_Text off
2021.04.10 11:16:58 3: FS20 set Dreambox_Text on
2021.04.10 11:16:58 3: FS20 set Kodi_Text off
2021.04.10 11:16:58 3: FS20 set Phono_Text off
2021.04.10 11:16:59 3: CUL: Unknown code LOVF, help me!
Das mit exclude habe ich ja auch direkt gemacht, aber wenn sich das nicht ändert, kommt der Fehler später und man kann ja nicht alles was nicht richtig funktioniert mit exclude bearbeiten. Dann bekomme ich ja auch kein wichtiges Update mehr.
@Otto123
Ich habe beide Varianten ausprobiert. Keine funktioniert. Es wird kein Gerät geschaltet, es gibt keine Text ausgabe und auch keine Error Meldung.
Der Eventmonitor zeigt auch nichts.
Ich habe dann mal diese Variante ausprobiert:
([Television_Sw_01:state] eq "on") (set Television_Text on)DOELSEIF
([Television_Sw_01:state] eq "off") (set Television_Text off)DOELSEIF
([AV_Receiver_Sw_02:state] eq "on") (set AV_Receiver_Text on)DOELSEIF
([AV_Receiver_Sw_02:state] eq "off") (set AV_Receiver_Text off)DOELSEIF
([Blu_Ray_Player_Sw_03:state] eq "on") (set Blu_Ray_Player_Text on)DOELSEIF
([Blu_Ray_Player_Sw_03:state] eq "off") (set Blu_Ray_Player_Text off)DOELSEIF
([Kodi_Sw_04:state] eq "on" and [Kodi_Sw_04:timedOn] eq "off") (set Kodi_Text on)DOELSEIF
([Kodi_Sw_04:state] eq "off" or [Kodi_Sw_04:state] eq "off") (set Kodi_Text off)DOELSEIF
([Kodi_Sw_04:timedOn] eq "running") (set Kodi_Text dim25%)DOELSEIF
([Ambilight_Sw_05:state] eq "on") (set Ambilight_Text on)DOELSEIF
([Ambilight_Sw_05:state] eq "off") (set Ambilight_Text off)DOELSEIF
([AV_Switch_Sw_06:state] eq "on") (set AV_Switch_Text on)DOELSEIF
([AV_Switch_Sw_06:state] eq "off") (set AV_Switch_Text off)DOELSEIF
([Phono_Sw_07:state] eq "on") (set Phono_Text on)DOELSEIF
([Phono_Sw_07:state] eq "off") (set Phono_Text off)DOELSEIF
([Dreambox_Sw_08:state] eq "on") (set Dreambox_Text on)DOELSEIF
([Dreambox_Sw_08:state] eq "off") (set Dreambox_Text off)DOELSE
Damit scheint es tatsächlich zu funktionieren , ich werde das mal ausgiebig testen und dann mal sehen ob nach dem "Umbau" aller anderen DOIFs auch wieder alles funktioniert.
Gruß
Nobbi
sagts mal (habs eh in "meinem" fred auch schon gefragt, aber hier ist mehr los derzeit:
mir wurde gesagt, man könne das problem umgehen, indem man im doif nicht auf "state" abfragt, sondern auf andere readings.
hab heute früh aber festgestellt, dass mir das wenig nutzt, weil ich oft nur den state habe mit den entsprechenden infos.
jetzt frag ich mich: wenn ich im entsprechenden gerät ein userreading anlege - was weiß ich, z.b.: "stateX" und das einfach mit dem state füttere, bringt das in unserem problemfall was, oder hab ichs dann nur verkompliziert?
aja, und hier auch noch mal: wenn ich fhem mit -d anstarte, was muß ich wo weg machen, damits wieder normal rennt?
verbose 5 im global ist klar, aber wie komm ich wieder auf mein normales logfile?
und reicht dann ein restart, oder macht er mir dann automatisch wieder ein -d rein, weil er ja so beendet wurde?
fhem -d wird einfach mit ctrl + c beendet, dann startest Du den Dienst wieder und alle ist wie vorher.
Deine Idee mit stateX macht es nur komplizierter.
Du müsstest ein Beispiel geben, das state nur die Infos hat. Oft ist state ein Sammelbecken für alle Meldungen. Aber das hängt vom konkreten Device ab.
langsam komm ich durcheinander - hab frank im 2. fred eben die selben fragen beantwortet *g*, also hier nochmal ein list meines regensensors - der channel für die regenanzeige:Internals:
DEF 24E49C01
FUUID 5c62c6bf-f33f-0f9e-5aa7-f3e9ab214d73dfc6
NAME terrasse_regensensor_regenanzeige
NOTIFYDEV global
NR 49
NTFY_ORDER 50-terrasse_regensensor_regenanzeige
STATE rain
TYPE CUL_HM
chanNo 01
device terrasse_regensensor
CL:
Authenticated 0
BUF
FD 5
FW_ID 25196
LASTACCESS 1618052955
NAME handyWEB_192.168.178.51_2548
NR 25538
PEER 192.168.178.51
PORT 2548
SNAME handyWEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-04-10 13:08:54 state Connected
READINGS:
2020-06-16 19:10:06 R-sign off
2021-04-10 10:35:38 cfgState updating
2021-04-10 12:49:50 commState CMDs_done_Errors:1
2021-04-10 06:03:48 lastRain 2021-04-10 03:07:24
2021-04-10 06:21:13 recentStateType info
2021-04-10 06:21:13 state rain
2021-04-10 06:21:13 timedOn off
helper:
getCfgList all
getCfgListNo ,4
lastRain 2021-04-10 06:21:13
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:sensRain
regLst 1,4p
cmds:
TmplKey :no:1618043687.2761
TmplTs 1618043687.2761
cmdKey 1:0:0::terrasse_regensensor:00A7:01:
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
lst:
condition dry,dry,rain,rain
peer
peerOpt 4k12v_schalter1,4k12v_schalter2,4k12v_schalter3,4k12v_schalter4,schlafzimmer_rollo,solaranlage_kuehlung,vccu,wohnzimmer_buero_licht_Dim,wohnzimmer_buero_licht_Dim_V_01,wohnzimmer_buero_licht_Dim_V_02,wohnzimmer_gang_gz_licht_Dim,wohnzimmer_gang_gz_licht_Dim_V_01,wohnzimmer_gang_gz_licht_Dim_V_02,wohnzimmer_gang_sz_licht_Dim,wohnzimmer_gang_sz_licht_Dim_V_01,wohnzimmer_gang_sz_licht_Dim_V_02,wohnzimmer_rollo_strasse,wohnzimmer_rollo_terrasse,wohnzimmer_sofa_licht_Dim,wohnzimmer_sofa_licht_Dim_V_01,wohnzimmer_sofa_licht_Dim_V_02
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
00000000 broadcast
role:
chn 1
tmpl:
Attributes:
alias terrasse regenanzeige regensensor
devStateIcon dry:regenschirm_zu@gray rain:regenschirm_auf@blue .*:regenschirm_zu@orange
event-on-change-reading .*
fp_3d 721,1162,0,terrasse_regensensor_regenanzeige,
group sensoren
icon humidity
model HM-SEN-RD-O
peerIDs 00000000
room homematicnur zur info: der ist derzeit vom strom.
wie du siehst, siehst du nichts - dry/rain gibts nur im state, sonst hät ich das auch anders gelöst - mir war state in doif's immer schon ein bissi unsymphatisch, ohne zu wissen, warum.
wegen -d
lustig find ich dann aber, dass nach dem start ohne -d weiterhin globales verbose 5 ist und ich weiterhin das logfile nicht gefüllt/gelöscht kriege.
nachtrag: das wichtigste hab ich wieder vergessen. zumindest unter den derzeitigen umständen kriegte ich fhem 2 mal nicht mal wirklich hoch, wenn ichs "normal" starte ... oder es braucht so lange, dass ichs warten aufgebe - was weiß ich.
Also ich habe auch schon wieder zurück gerudert, aber von gestern aus dem Log:
2021.04.09 13:16:25.979 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:16:26.013 3: CUL_HM set Treppenbeleuchtung off noArg
2021.04.09 13:16:26.723 3: CUL_HM Treppenbeleuchtung repeat, level C8 instead of 00
2021.04.09 13:24:15.163 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:24:15.195 3: CUL_HM set Treppenbeleuchtung off noArg
2021.04.09 13:24:16.019 3: CUL_HM Treppenbeleuchtung repeat, level C8 instead of 00
2021.04.09 13:24:27.055 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:24:27.090 3: CUL_HM set Treppenbeleuchtung off noArg
2021.04.09 13:24:27.803 3: CUL_HM Treppenbeleuchtung repeat, level C8 instead of 00
2021.04.09 13:29:48.594 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:29:48.654 3: CUL_HM set Treppenbeleuchtung off noArg
2021.04.09 13:29:49.330 3: CUL_HM Treppenbeleuchtung repeat, level C8 instead of 00
2021.04.09 13:29:51.794 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:29:51.826 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:29:51.834 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:29:51.841 3: CUL_HM set Treppenbeleuchtung on noArg
2021.04.09 13:29:51.852 3: CUL_HM set Treppenbeleuchtung off noArg
2021.04.09 13:29:52.177 3: CUL_HM Treppenbeleuchtung repeat, level C8 instead of 00
2021.04.09 13:29:52.445 3: CUL_HM Treppenbeleuchtung repeat, level C8 instead of 00
Völlig unlogisch, als hätte er erst angeschalten und dann gemerkt dass es zu hell war - dann hat er wieder aus gemacht...
Gut das Log ist an der Stelle Wertlos. Aber ich glaube ich verstehe das Problem.
FlurEGBewegungsmelder_M:motion:.*
Auch Du triggerst auf alles was ins Reading motion gerät. Aber Du willst doch nur auf motion:.on reagieren!?
Ich habe keine Ahnung was da jetzt für Events kommen...
Aber ein set Treppenbeleuchtung off steht in deinem notify nicht drin, das Ende von on-for-timer kann es doch nicht sein?
Also generell steht bei motion immer nur "off" oder "on (to VCCU)".
Du hast Recht, ich triggere erstmal wenn eine Bewegung kommt und schaue dann ob der State vom Bewegungsmelder "motion" sendet. Falls das Licht aus ist, es dunkel genug ist, und wir beide daheim sind, schalte ich für 4 Minuten ein. Dadurch muss ich es durch FHEM nicht erneut ausschalten lassen.
Ich meine viele Wege führen nach Rom, was soll daran denn jetzt seid 3-4 Tagen falsch sein ? Klar - ich könnte auch auf motion:.on reagieren lassen... Da müsste ich aber alle meine Notifies für Bewegungsmelder umbauen... :-O
Ach ja, was mir noch eingefallen ist: wenn ich ein set Treppenbeleuchtung on abschicke, egal über die Kommandozeile oder über ein State-Icon... dann ging das Licht auch nur ne halbe Sekunde an und dann wieder aus - ganz unabhängig vom Bewegungsmelder. Ergo bekommt man das Licht überhaupt nicht mehr dauerhaft an...
ZitatAch ja, was mir noch eingefallen ist: wenn ich ein set Treppenbeleuchtung on abschicke, egal über die Kommandozeile oder über ein State-Icon... dann ging das Licht auch nur ne halbe Sekunde an und dann wieder aus - ganz unabhängig vom Bewegungsmelder. Ergo bekommt man das Licht überhaupt nicht mehr dauerhaft an...
dann ist dein aktor defekt, oder ein weiteres doif mischt sich ein.
Nein ist er nicht. Ich habe die HMConfig.pm und die 10_CUL... zurück gespielt und alles funktioniert wieder normal.
Und DOIF verwende ich generell nicht.
moin,
dann mischt sich ein anderes notify ein. Welches notify sendet den set Treppenbeleuchtung off Befehl?
Gruß Otto
Keins... ich setze einen on-for-timer - 4 Minuten... da brauchts doch keinen Off-Befehl ?
Zitat von: MegaData am 11 April 2021, 11:36:00
Keins... ich setze einen on-for-timer - 4 Minuten... da brauchts doch keinen Off-Befehl ?
Kannst Du mal alle notifys deaktivieren, das Log-File des Aktors aktivieren, falls nicht vorhanden, und mal ein on-for-timer abschicken? Das klingt ja bald so, als würde CUL-HM komplett falsche on-Zeiten an den Aktor abschicken. Bei mir sieht ein 5 s on so aus:
2021-04-11_12:02:35 hm.switch_KL.FlurLicht set_on-for-timer 5
2021-04-11_12:02:35 hm.switch_KL.FlurLicht commState: CMDs_processing...
2021-04-11_12:02:35 hm.switch_KL.FlurLicht trigLast: fhem:02
2021-04-11_12:02:35 hm.switch_KL.FlurLicht trigLast: fhem:02
2021-04-11_12:02:35 hm.switch_KL.FlurLicht commState: CMDs_done
2021-04-11_12:02:35 hm.switch_KL.FlurLicht deviceMsg: on (to vccu)
2021-04-11_12:02:35 hm.switch_KL.FlurLicht level: 100
2021-04-11_12:02:35 hm.switch_KL.FlurLicht pct: 100
2021-04-11_12:02:35 hm.switch_KL.FlurLicht on
2021-04-11_12:02:35 hm.switch_KL.FlurLicht timedOn: running
2021-04-11_12:02:42 hm.switch_KL.FlurLicht commState: CMDs_done
2021-04-11_12:02:42 hm.switch_KL.FlurLicht deviceMsg: off (to vccu)
2021-04-11_12:02:42 hm.switch_KL.FlurLicht level: 0
2021-04-11_12:02:42 hm.switch_KL.FlurLicht pct: 0
2021-04-11_12:02:42 hm.switch_KL.FlurLicht off
2021-04-11_12:02:42 hm.switch_KL.FlurLicht timedOn: offWarum trigLast 2x kommt, weiß ich auch nicht...CUL-HM ist 24031.
Zitat von: MegaData am 11 April 2021, 11:36:00
Keins... ich setze einen on-for-timer - 4 Minuten... da brauchts doch keinen Off-Befehl ?
es geht nicht darum, ob es einen off befehl braucht, sondern darum, dass scheinbar einer gesendet wird.
mach am besten einen eigenen thread auf und poste dort:
ein list vom aktor,
und die raw messages aus fhem.log vom on-for-timer befehl.
siehe wiki homematic sniffen.
also bei mir kommt langsam ein bissi handfesteres zusammen.
vielleicht kann man hier ja was mit anfangen:
https://forum.fhem.de/index.php/topic,120202.msg1148230.html#msg1148230
ich stell fest, ich krieg per state (dem ich wie im anderen fred beschrieben definitiv nicht überall ausweichen kann) nen haufen sinnloser meldungen mit - bis ich da mal von off zu on komme, hat der state schon x andere meldungen auch raus geworfen. das scheint den doif's dann übel aufzustoßen.
betrifft wohl: HM-SEN-RD-O, HM-SEC-SCO, HM-SEC-SC-2. teilweise HM-LC-SW1-BA-PCB und HM-LC-SW4-WM
was nun?
Zitatbis ich da mal von off zu on komme, hat der state schon x andere meldungen auch raus geworfen.
die sonne geht auf! 8)
Zitatdas scheint den doif's dann übel aufzustoßen.
nee, die machen dann einfach nur das, was in der DEF des doif für diese events definiert ist.
Zitatnee, die machen dann einfach nur das, was in der DEF des doif für diese events definiert ist.
in den doifs ist bei mir definiert: mache dieses oder jenes, wenn der state auf on wechselt und mache was anders, wenn der state auf off geht. ich hab in keinem doif mittlerweile was stehen, dass auf irgend einen undeffinierten status reagieren soll, nicht mal mehr sowas wie [xxx:state] ne "off"
was muß ich nun noch tun, damit ich das problem los werde?
ich sags gern nochmal: ich habe hier eindeutig geräte, die nur am state ihren status geben, ich kann auf kein anderes reading ausweichen.
btw - ists eigentlich üblich, dass ein händisches update des watchdogs bei 29 geräten gleich mal 5% load beim hmlan macht?
hab das ja nie wirklich beobachtet, aber irgendwie scheint mir das schon ein haufen zu sein.
und da hat kein doif was mit zu tun *g*
bei doif halte ich mich raus. das ist zu schwer für mich.
man muss grundsätzlich in jedem zweig nur die events zulassen, die man dort benötigt.
Zitatdass ein händisches update des watchdogs
was für ein update bei was für einem watchdog. ich verstehe nur bahnhof.
tschuldige, so nenn ich den - ist der "actiondetector".
das gute tool also, daß mir das leben meiner hm batteriegeräte anzeigt.
was doif angeht:
eine abfrage wie z.b. ([terrasse_regensensor_regenanzeige:state] eq "rain") kann für mein empfinden auch nur triggern, wenn im state "rain" steht. ob dort sonst "dry" oder "was anderes" steht, müßte doch egal sein. ob es das intern auch so tut, muß wer anderer sagen.
meines erachtens kann das nur probleme geben, wenn ich anstelle "eq" ein "ne" verwende, um div. andere zustände abzudecken. das hab ich jetzt so weit wie möglich raus, aber nicht überall.
als beispiel will ich eine rollo ganz zu fahren, wenn es regnet - soweit so gut.
da die aber ja nicht nur on und off können, sondern auch die pct-werte zw. 1 und 99 am state liefert, hab ich ein zusätzliche IF in div. doifs eingebaut. z.b.: ( IF ([schlafzimmer_rollo:state] ne "on" ) (set schlafzimmer_rollo on) )
mein wissen reicht da nicht aus, um z.b. zu sagen, wenn "off" oder "0-99", dann "on".
gut, bei vielen aktoren kann ich dann rein auf pct gehen, aber das geht eben nicht überall.
das es zu problemen führen kann, wenn der aktor die ganze zeit was rein schreit, kann ich mir vorstellen. nur, was tun?
Zitat([terrasse_regensensor_regenanzeige:state] eq "rain") kann für mein empfinden auch nur triggern, wenn im state "rain" steht
nein so ist DOIF nicht.
Es wird durch irgendein Event für das Gerät terrasse_regensensor_regenanzeige getriggert und anschließend wird das Reading state abgefragt.
Wenn also 27 einzelne Events für die Aktualisierung von 23 Readings und 4 Statusmeldungen erfolgen, wird das DOIF 27 mal triggern und jedes mal wird das Reading abgefragt, ausgewertet und wenn (sich das reading state auch gar nicht ändert) die Abfrage wahr ergibt - im blödesten Fall auch 27 mal der Ausführungsteil ausgeführt!
In state kann zwischenzeitlich alles mögliche stehen, wenn man also sichergehen will:
- nimmt man einen ganz spezifischen Event und triggert damit das DOIF
- wertet man ein spezifisches Reading und nicht state aus.
Allgemein also in etwa so:
(["^DEVICE$:^Event$"] and [?DEVICE:reading])
Zitattschuldige, so nenn ich den - ist der "actiondetector".
das gute tool also, daß mir das leben meiner hm batteriegeräte anzeigt.
der actiondetector von cul_hm erzeugt normaler weise
NULL load.
der sammelt nur "lebenszeichen" ein und merkt sie sich.
beim update berechnet er nur, ob nun devices dead sind.
nur wenn das attr autoActTry=1 gesetzt ist, wird bei einem möglicher weise als dead zu kennzeichnenden device einmalig noch ein statusrequest versucht.
bei 5% load hast du entweder einen anderen actiondetector, oder du hast hier auch irgendwelche doifs, die komische sachen machen.
ich kenne keinen aktor der nicht die readings level oder pct hat.
wir drehen uns im kreis ...
zuerst mal thx für die infos. nutzt halt nix, wenn es eben nur state gibt und kein anders reading. die entsprechenden sensoren hab ich aufgeführt.
als bspl. regensensor kanal für die anzeige des regens:
READINGS:
2021-04-11 21:30:52 R-sign off
2021-04-11 21:41:57 RegL_01. 00:00 08:00 22:64 23:00 30:06 87:0B 88:54 8B:0B 8C:22 8F:3C 91:82
2021-04-11 21:41:57 cfgState ok
2021-04-12 08:32:12 commState CMDs_done_Errors:1
2021-04-12 08:32:12 lastRain 2021-04-11 20:48:45
2021-04-12 08:32:12 recentStateType info
2021-04-12 08:32:12 state dry
2021-04-12 08:32:12 timedOn off
auf was, außer state, soll ich da triggern, wenn ich wissen will, obs regnet oder nicht?
die errors kommen jetzt, weil der sensor selber auf dummy 1 steht.
@frank
nö, is bei mir nicht ein, ich hab nur 3 mal auf update gedrückt. dann hatte ich einen load von 17%, vorher warens 2%. nick knatterton hat dann vermutet: passt super zu meinen aktionen.
in dem fall könnte ich nur eine readingsgroup anbieten für batterieanzeige:
<homematic>
TYPE=CUL_HM:batteryZitatich kenne keinen aktor der nicht die readings level oder pct hat.
ich schon, aber nehmen wir nur mal den regensensor! ich mag mich ja nicht wirklich mit euren modulen, perl oder irgendwelchen programmiertechniken auskennen, aber lesen kann ich schon noch.
na dann frag von mir aus den state ab aber triggere auf was anderes (kenne die Events vom Regensensor nicht)
state selbst liefert normal kein spezifisches Event
oder mach es in dem Fall so und frag alle anderen Bedingungen nur ab!
(["^DEVICE$:^state: rain$"])
attr DeinDoif addStateEvent
Aber sag jetzt nicht das gilt immer! ;D :'(
ich blicks grade nicht, was mit "gilt immer" (und dem meisten rest) gemeint ist.
und vor allem blick ich schon gar nicht, warum - was auch immer - jetzt nach jahren auf einmal ein problem ist. der ganze schrott ist doch problemlos gelaufen, warum jetzt nicht mehr?
könntet ihr bitte allgemein den level auf "dummy" senken für mich?
Zitatnö, is bei mir nicht ein, ich hab nur 3 mal auf update gedrückt. dann hatte ich einen load von 17%, vorher warens 2%. nick knatterton hat dann vermutet: passt super zu meinen aktionen.
mach mal ein neuen ratman-actiondetector-chaos-thread auf und poste dort ein list vom actiondetector.
erledigt.
und was heißt bitte chaos?
ich hab ein problem, man antwortet mir freundlicher weise mit div. fragen, ich versuche die fragen so umfangreich wie es mir möglich ist zu beantworten - gern auch mehrfach - um möglichst viele folgefragen raus zu nehmen.
mach ich was falsch?
Zitat von: the ratman am 12 April 2021, 12:44:29
könntet ihr bitte allgemein den level auf "dummy" senken für mich?
Ich dachte da bin ich schon die ganze Zeit :)
"gilt immer" meint: es gibt mit Sicherheit kein universal Lösung sondern das ist die ev. Lösung für deinen Regensensor. Ich weiß doch nicht was Deine 25 DOIFs machen. ::)
Das es bisher funktionierte lag daran, dass unvorsichtigerweise die bisherige Lösung unter der Annahme stand: Es gibt einen Event und damit ist es ganz einfach. Es war schon immer ein böses Erwachen wenn dann plötzlich mehrfache Übertragungen (Events) auftauchten oder so was. Das wird häufig mit dem Allheilmittel attr ... eocr .* behoben. Ja kann sein es hilft - aber besser ist schon immer nur darauf zu reagieren was relevant ist. Ich kann mich da nur wiederholen: Am besten so umbauen, dass genau eine Reaktion auf ein Ereignis erfolgt.
wie bei nem vortrag: interessierte ingenieure und darüber auf niveau 14 jährige und alles andere für unter 12 jährige erzählen. geh bei mir in sachen fhem bitte auf 5 bis 6 oder mal mir bilder mit lustigen tierchen ... das könnte dann vielleicht funktionieren *g*
ich weiß auch ned, was die doifs machen.
mittlerweile warscheinlich viel weniger als noch vor 2 tagen. hab ordentlich ausgemistet, und dann versucht, alles, was mit hm zu tun hat und ein "ne" in der abfrage hat ebenfalls zu ersetzen. was mir aber nicht vollständig gelingen mag.
ich kann dir die dinger aber gern mal alle auf einmal um die ohren hauen.
warscheinlich lachst du dann die ersten 5 minuten bist du gar bitterlich zu weinen beginnst ...
ZitatAm besten so umbauen, dass genau eine Reaktion auf ein Ereignis erfolgt.
und dazu würdest du im doif folgendes eintragen:
ich kann das addstateevent aber nur auf 0 oder 1 setzen - wo kommt dann (["^DEVICE$:^state: rain$"]) hin?
Zitatwas doif angeht:
eine abfrage wie z.b. ([terrasse_regensensor_regenanzeige:state] eq "rain") kann für mein empfinden auch nur triggern, wenn im state "rain" steht. ob dort sonst "dry" oder "was anderes" steht, müßte doch egal sein. ob es das intern auch so tut, muß wer anderer sagen.
Anstatt ([terrasse_regensensor_regenanzeige:state] eq "rain") schreibst Du (["^terrasse_regensensor_regenanzeige$:^state: rain$"])
Zitatich kann das addstateevent aber nur auf 0 oder 1 setzen
Ja, das ist das
lustige wenn Du nichts hinschreibst wird 1 gesetzt ;D
danke dir, wird probiert, sobald ich mal wieder 5 min. zeit hab.
Zitat von: locodriver am 09 April 2021, 11:38:59
Ich hänge mich hier mal dran...
Ich habe zwei 6-fach-Taster, die mit DOIFs abgefragt werden. Seid dem Update auf o.g. Version werden bei Betätigen eines beliebeigen Tasters die Funktionen aller Taster ausgeführt.
...
Hallo zusammen,
hat jemand mal probiert, ob dieses und die weiteren Probleme aus dem Thread in den nachfolgenden 10_CUL_HM-Versionen behoben sind ? (aktuell 24449 vom 16.05.2021)
Würde irgendwann mal gerne das "exclude_from_update" wieder rausmachen ....
Zitatwerden bei Betätigen eines beliebeigen Tasters die Funktionen aller Taster ausgeführt
da wird sich wenig ändern--> die notify-doif besser einschränken
Zitatnimmt man einen ganz spezifischen Event und triggert damit das DOIF
wertet man ein spezifisches Reading und nicht state aus.
Hallo sigma415,
Zitatob dieses
Dieses Problem hier ist kein grundsätzliches CUL_HM Problem, sondern zunächst nur eine Verhaltensänderung. Das Problem hier sind zu unspezifische Eventauswertungen und das ist ein Anwenderthema.
Und die Verhaltensänderung ist auch nicht in aktueller Version auf weniger Events zurück geändert, wenn ich es nicht übersehen habe. Die betreffende Zeile enthält nur seit dem letzten (?) einen Kommentar dazu. Für irgendwas scheint Martin die Events zu benötigen.
Gruß, Ansgar.
@ the ratman
Moin,
vielleicht kann ich Deine "Verwirrung" etwas "entwirren". Bin auch gerade dabei, meine DOIF's "triggerfest" umzustellen.
Es stimmt tatsächlich, dass der Regensensor außer
state kein anderes nutzbares Reading hat. Die anderen von Dir genannten HM-Komponenten allerdings schon.
Gib mal in fhem folgendes ein:
Zitatlist TYPE=CUL_HM model deviceMsg contact motion
Du bekommst eine (lange) Liste mit allen Deinen HM-Komponeneten. Wenn vorne in der Liste ein Zeilenabstand ist hat das Device eines der gesuchten Readings. Ist kein Zeilenabstand dann ist ausser model nichts angegeben. Das wird beim Regensensor so sein. Bei den anderen hast Du
contact (z.B. HM-SEC-SCO, HM-SEC-RHS), deviceMsg (z.B. HM-LC-SW1-BA-PCB, HM-LC-SW1-PL-DN-R1) oder motion (HM-SEN-MDIR-SM). Diese Readings liefern (offensichtlich) den eindeutigen Zustand.
Beispiel Fensterkontakt (ohne eocr.. Einschränkung)
Zitat
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor battery: ok
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor commState: CMDs_done
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor contact: open (to myVCCU)
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor open
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor trigger_cnt: 57
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor daysSinceLastBatt: 448
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor battery: ok
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor commState: CMDs_done
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor contact: closed (to myVCCU)
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor closed
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor trigger_cnt: 58
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor daysSinceLastBatt: 448
Beispiel Funksteckdose:
Zitat
2021-05-19 10:26:05.262 CUL_HM Steckdose_StehlampeTV commState: CMDs_pending
2021-05-19 10:26:05.984 CUL_HM Steckdose_StehlampeTV set_on noArg
2021-05-19 10:26:06.124 CUL_HM Steckdose_StehlampeTV commState: CMDs_processing...
2021-05-19 10:26:06.262 CUL_HM Steckdose_StehlampeTV trigLast: fhem:02
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV commState: CMDs_done
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV deviceMsg: on (to myVCCU)
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV level: 100
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV pct: 100
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV on
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV timedOn: off
2021-05-19 10:26:20.762 CUL_HM Steckdose_StehlampeTV commState: CMDs_pending
2021-05-19 10:26:21.533 CUL_HM Steckdose_StehlampeTV set_off noArg
2021-05-19 10:26:21.685 CUL_HM Steckdose_StehlampeTV commState: CMDs_processing...
2021-05-19 10:26:21.840 CUL_HM Steckdose_StehlampeTV trigLast: fhem:02
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV commState: CMDs_done
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV deviceMsg: off (to myVCCU)
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV level: 0
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV pct: 0
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV off
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV timedOn: off
Es kommen also jede Menge Events, die man vermutlich nie alle braucht. Also auf das nötigste Beschränken mittels event-on-change-reading xxx. Damit werden alle Events von nicht gewählten Readings unterdrückt, die gewählten Readings erzeugen nur bei Änderung einen Event. Bei den Fensterkontakten lasse ich z.B. nur noch contact, battery,sabotageError und Activity durch, mittels event-min-interval battery:3600 darf die Batterie stündlich ihren Zustand melden, auch wenn er sich nicht ändert.
Jetzt gehts nochmal um DOIF, wie das so tickt (hat Otto eigentlich schon erklärt):
Man sollte sich klar machen, ob man eine Zustand eines Readings "abfragen" möchte oder ob ein Event eines Readings etwas auslösen soll. Beispiel: Türkontakt und Regensensor:
Ich möchte eine Ansage "es regnet" wenn es regnet und ich die Tür öffne. Also ist der Trigger die Tür, der Zustand des Regensensors wird abgefragt:
DOIF (["^Tuer$:^contact:.open"] and [?Regensensor] eq "rain")(...Ansage)["^Tuer$:^contact:.open"] bedeutet: Es wird der Event genommen (Hochkomma), das Device beginnt ^ mit Tuer und endet $ mit Tuer, es heisst also GENAU Tuer, das Reading und der Wert contact:.open beginnt nur genau mit contact, weil hinter open/closed hier noch (to VCCU) oder so stehen kann. Das ist bei mir unterschiedlich und nicht wichtig. Der Trigger ist so eindeutig definiert. Du kannst Dir das so vorstellen, dass der Türkontakt diesen Event sendet und DOIF hat eine "Schablone", wo genau dieser Event reinpasst. Schickt ihn der Schalter, wird in und für diesen Moment diese Bedinung wahr. Dann kommt die Abfrage [?Regensensor:state] eq "rain", die durch das Fragezeichen nicht triggert. Kommt also der Tür-Event und es regnet wird die Bedingung wahr und der Ausführungsteil wird abgearbeitet (Ansage...)
Bei eine Definition wie [Regensensor:state] eq "rain" ist es so, dass das DOIF bei jedem Event von "Regensensor" angetriggert wird und dann die Bedinung überprüft wird. Die Bedingung wird also wahr, wenn sich der state von dry auf rain ändert, aber auch, wenn der Regensensor irgend etwas anders liefert und state auf rain steht. Bei FS20 Sendern ist das ziemlich egal, bei Homematic gibts aber mittlerweile so viele Events, dass man darauf genau achten muss.
Zurück zum Regensensor:
Mit ["^terrasse_regensensor_regenanzeige$:^rain$"] und ["^terrasse_regensensor_regenanzeige$:^dry$"] filterst Du exact nach den beiden relevanten Events. Das funktioniert bei mir jetzt zu 100% (gibt ja gerade reichlich Schauer....)
Ob das DOIF richtig funtioniert kannst Du auch mit
Zitattrigger terrasse_regensensor_regenanzeige rain
und
Zitattrigger terrasse_regensensor_regenanzeige dry
ausprobieren, wenn es gerade nicht schauert ;)
Ansonsten, auch wenn es schon etwas abgedroschen klingt: die Kapitel "Ereignissteuerung" und "Ereignissteuerung über Auswertung von Events" in der Commandref zu DOIF kann man gar nicht oft genug lesen....
Vor dem DOIF-schreiben würde ich immer das Device (Tükontakt/Regensensor etc) per EventMonitor beobachten und alle möglichen Zustände auslösen. Aus dem EventMonitor kannst Du dann die DOIF Definition fast immer 1:1 übernehmen.
Viel Erfolg!
Edit: das ist auch noch interessant zum Thema:
https://forum.fhem.de/index.php/topic,115785.msg1100628.html#msg1100628 (https://forum.fhem.de/index.php/topic,115785.msg1100628.html#msg1100628)
hallo Sany,
du solltest deine beispiele noch mehr eingrenzen, da es bei gepeerten devices sonst trotzdem mehrfache events gibt.
jeder peer erzeugt ein weiteres "...(to <peer>)" event.
und wenn die kommunikation gestört ist, kommen eventuell noch weitere events hinzu.
gruss frank
Hallo frank,
danke für den Hinweis. Mein hm_TestSensor ist natürlich der einzige im Haus, der nicht gepeert ist. Alle anderen sind mit einem Thermostaten gepeert und entsprechend kommen 2 Meldungen. Ein Kurzer Versuch hat gezeigt, dass zuerst der Thermostat und dann die VCCU dran ist, mit ca 1,5 sec Unterschied! Kannst Du sagen, dass die Reihenfolge immer gleich ist oder kann das auch beliebig sein?
Dann kann man natürlich im DOIF auf diese Events gezielt triggern, und wenn das bei der Reihenfolge tatsächlich so ist dann z.B. bei "open" auf den ersten contact Event und bei "closed" auf den 2ten. Wenn die Reihenfolge nicht immer gleich ist dann eben doch nur auf das open oder closed triggern und eine weitere Ausführung innerhalb weniger Sekunden im DOIF unterdrücken. Ich muss da mal meine HM-Komponenten eine Weile beobachten.
Aber allgemein gesagt scheint es keinen eindeutigen Event zu geben, um z.B. bei einem Türkontakt auf open/closed zu triggern. Also mit Reading. Finde ich schon etwas seltsam. Das state alles Mögliche erzählen kann, daran habe ich ich schon fast gewöhnt. Das contact auch verschiedene "open's" und "closed's" erzählen kann machts in der Anwendung nicht wirklich einfach. Mal sehen, was da sonst noch so raus kommt. Vielleicht sogar die Quelle für CPU-Last-Anstiege wenn Türen oder Fenster geöffnet werden....
OK, ist alles etwas OT, bezog sich hauptsächlich auf den Post von the ratman.
Sany
hallo sany,
der fk sendet nun mal an jeden peer und die centrale. warum sollte man die unterschiedlichen infos unter den tisch fallen lassen. es ist doch ein leichtes, auf nur ein event zu reagieren.
das einfachste ist doch immer, den ganzen string zu nehmen.
wenn ich deine erklärung für doif verstehe, dann wohl zb so:
["^Tuer$:^contact:.open.(to.vccu)$"]
ob die reihenfolge immer gleich ist, würde ich nicht drauf wetten. vielleicht fw abhängig?
oder mit einem userreading open/close aus contact holen, welches zusammen mit eocr nur noch 1x open/close im userreading zulässt.
ist aber eigentlich unnötige, zusätzliche belastung.
das userreading hätte bei gepeerten devices den vorteil, dass auch mal eine message "verloren" gehen kann.
Sorry dass ich den alten Thread noch mal hoch hole... Habe heute mal wieder ein Update probiert: bei mir klappt das immer noch nicht... Das kuriose ist tatsächlich: bei einigen Schaltern klappt es, bei anderen wird sofort wieder aus geschalten... :-O
Hier ein Beispiel wo es klappt:
Der physische Schalter:
Internals:
DEF 4AB38C
FUUID 5c66c323-f33f-7f95-fa09-1b04e99d9a280adf
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 1
NAME Kamin.LED
NOTIFYDEV global
NR 350
NTFY_ORDER 50-Kamin.LED
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:41 - t:10 s:4AB38C d:1C695F 0601000044
myHmUART_MSGCNT 1
myHmUART_RAWMSG 0501014141A4104AB38C1C695F0601000044
myHmUART_RSSI -65
myHmUART_TIME 2021-08-06 14:12:07
protLastRcv 2021-08-06 14:12:07
protRcv 1 last_at:2021-08-06 14:12:07
protSnd 2 last_at:2021-08-06 14:12:07
protState CMDs_done
rssi_at_myHmUART cnt:1 min:-65 max:-65 avg:-65 lst:-65
rssi_myHmUART cnt:1 min:-68 max:-68 avg:-68 lst:-68
CL:
Authenticated 1
AuthenticatedBy admin
AuthenticatedUser admin
BUF
FD 99
FW_ID 616
LASTACCESS 1628252938
NAME WEB_192.168.178.40_63369
NR 618
PEER 192.168.178.40
PORT 63369
SNAME WEB
SSL 1
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-08-06 14:28:58 state Connected
READINGS:
2021-08-06 14:03:45 CommandAccepted yes
2017-04-27 18:39:47 D-firmware 2.8
2017-04-27 18:39:47 D-serialNr NEQ0370403
2021-08-06 14:10:46 IODev myHmUART
2021-01-19 16:50:27 PairedTo 0x1C695F
2017-04-27 18:39:51 R-pairCentral 0x1C695F
2017-04-27 18:39:52 R-powerUpAction off
2017-04-27 18:39:52 R-sign off
2021-01-19 16:50:27 RegL_00. 00:00 02:01 0A:1C 0B:69 0C:5F 15:FF 18:00
2021-01-19 16:50:28 RegL_01. 00:00 08:00 30:06 56:00 57:24 93:11 94:3A
2021-04-12 16:34:17 cfgState ok
2021-08-06 14:12:07 commState CMDs_done
2021-08-06 14:12:07 deviceMsg off (to VCCU)
2021-08-06 14:12:07 level 0
2021-08-06 14:12:07 pct 0
2021-01-19 16:50:26 powerOn 2021-01-19 16:50:26
2021-08-06 14:12:07 recentStateType info
2021-08-06 14:12:07 state off
2021-08-06 14:12:07 timedOn off
2021-08-06 14:03:44 trigLast fhem:02
helper:
HM_CMDNR 65
cSnd ,011C695F4AB38C010E
mId 0002
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1628251852.04187
TmplTs 1628251852.04187
cmdKey 1:1:0::Kamin.LED:0002:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt BewegungsmelderSchuppen_M,BewegungsmelderSchuppen_T1,BewegungsmelderSchuppen_T2,Bewegungsmelder_Carport_vorn,Dachfenster,FB_Anja_Btn1,FB_Anja_Btn2,FB_Anja_Btn3,FB_Anja_Btn4,FB_Chris_Btn1,FB_Chris_Btn2,FB_Chris_Btn3,FB_Chris_Btn4,Fenster.BadNord,Fenster.BadWest,Fenster.Buero,Fenster.KinderzimmerSued,Fenster.KinderzimmerWest,Fenster.SchlafzimmerOst,Fenster.SchlafzimmerSued,FensterGast,FensterGastWC,FensterKuecheSpuele,FensterKuecheSued,FensterKuecheWest,FensterWZOst,FensterWZSued,FlurEGBewegungsmelder_M,FlurEGBewegungsmelder_T1,FlurEGBewegungsmelder_T2,FlurOGBewegungsmelder_M,FlurOGBewegungsmelder_T1,FlurOGBewegungsmelder_T2,HWRBewegungsmelder_M,HWRBewegungsmelder_T1,HWRBewegungsmelder_T2,Haustuer,Innentuer.HWR,Kueche_Taster_V1,Kueche_Taster_V2,Schuppentuer,Taster_Bad_Btn_01,Taster_Bad_Btn_02,Taster_Bad_Btn_03,Taster_Bad_Btn_04,Taster_Bad_Btn_05,Taster_Bad_Btn_06,Taster_Flur_Btn1,Taster_Flur_Btn2,Tuer.HWR,VCCU_Btn1,VCCU_Btn10,VCCU_Btn11,VCCU_Btn12,VCCU_Btn13,VCCU_Btn14,VCCU_Btn15,VCCU_Btn16,VCCU_Btn17,VCCU_Btn18,VCCU_Btn19,VCCU_Btn2,VCCU_Btn20,VCCU_Btn21,VCCU_Btn22,VCCU_Btn23,VCCU_Btn24,VCCU_Btn3,VCCU_Btn4,VCCU_Btn5,VCCU_Btn6,VCCU_Btn7,VCCU_Btn8,VCCU_Btn9,virtualswitch01_Btn1,virtualswitch01_Btn10,virtualswitch01_Btn11,virtualswitch01_Btn12,virtualswitch01_Btn13,virtualswitch01_Btn14,virtualswitch01_Btn2,virtualswitch01_Btn3,virtualswitch01_Btn4,virtualswitch01_Btn5,virtualswitch01_Btn6,virtualswitch01_Btn7,virtualswitch01_Btn8,virtualswitch01_Btn9
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +4AB38C,00,01,00
nextSend 1628251927.93891
rxt 0
vccu VCCU
p:
4AB38C
00
01
00
prefIO:
myHmUART
mRssi:
mNo 41
io:
myHmUART:
-61
-61
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO myHmUART
flg A
ts 1628251927.64391
ack:
HASH(0x438d7e8)
4180021C695F4AB38C00
rssi:
at_myHmUART:
avg -65
cnt 1
lst -65
max -65
min -65
myHmUART:
avg -68
cnt 1
lst -68
max -68
min -68
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 2.8
group Licht
model HM-LC-SW1-DR
peerIDs 00000000
room Wohnzimmer
serialNr NEQ0370403
subType switch
webCmd on:off
Das Notify dazu:
DEF
VCCU_Btn10 {if ((ReadingsVal("Kamin.LED","state","") eq "off")) {fhem "set Kamin.LED on"} elsif ((ReadingsVal("Kamin.LED","state","") eq "on")) { fhem ("set Kamin.LED off")}}
VCCU:
Internals:
DEF 1C695F0A
FUUID 5c66c325-f33f-7f95-325c-91f76381382db817
NAME VCCU_Btn10
NOTIFYDEV global
NR 395
NTFY_ORDER 50-VCCU_Btn10
STATE ???
TYPE CUL_HM
chanNo 0A
device VCCU
peerList Kueche_Taster_V2
CL:
Authenticated 1
AuthenticatedBy admin
AuthenticatedUser admin
BUF
FD 94
FW_ID 628
LASTACCESS 1628253134
NAME WEB_192.168.178.40_61536
NR 639
PEER 192.168.178.40
PORT 61536
SNAME WEB
SSL 1
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-08-06 14:32:10 state Connected
READINGS:
2021-04-12 16:34:19 cfgState ok
2021-08-06 14:03:44 commState CMDs_done
2021-08-06 14:10:54 peerList Kueche_Taster_V2
2021-08-06 13:36:11 trigLast Kueche_Taster_V2:short
2021-08-06 13:36:11 trig_Kueche_Taster_V2 Short_18
helper:
peerFriend peerSens,peerAct
peerIDsState incomplete
peerOpt -:virtual
regLst
cmds:
TmplKey Kueche_Taster_V2:no:1628251854.55597
TmplTs 1628251854.55597
cmdKey 1:0:1::VCCU:FFF0:0A:Kueche_Taster_V2
cmdLst:
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
tplSet_0 -tplChan-
tplSet_Kueche_Taster_V2 -tplPeer-
lst:
condition slider,0,1,255
peer Kueche_Taster_V2
peerOpt Aussen04,Aussensteckdose,Bad.Decke,Bad.LED,BewegungsmelderSchuppen_M,BewegungsmelderSchuppen_T1,BewegungsmelderSchuppen_T2,Bewegungsmelder_Carport_vorn,Boden_LEDs,Brunnenpumpe,Buero.Decke,Carportlicht,Dachfenster,FB_Anja_Btn1,FB_Anja_Btn2,FB_Anja_Btn3,FB_Anja_Btn4,FB_Chris_Btn1,FB_Chris_Btn2,FB_Chris_Btn3,FB_Chris_Btn4,Fenster.BadNord,Fenster.BadWest,Fenster.Buero,Fenster.KinderzimmerSued,Fenster.KinderzimmerWest,Fenster.SchlafzimmerOst,Fenster.SchlafzimmerSued,FensterGast,FensterGastWC,FensterKuecheSpuele,FensterKuecheSued,FensterKuecheWest,FensterWZOst,FensterWZSued,FlurEG.Decke,FlurEGBewegungsmelder_M,FlurEGBewegungsmelder_T1,FlurEGBewegungsmelder_T2,FlurOG.Wand,FlurOGBewegungsmelder_M,FlurOGBewegungsmelder_T1,FlurOGBewegungsmelder_T2,Garten_Haupt,Gast.Decke,GastWC.Decke,HM_5FF962_Sw_04,HWR.Decke,HWRBewegungsmelder_M,HWRBewegungsmelder_T1,HWRBewegungsmelder_T2,Hauptschalter_Bew,Hausnummernbeleuchtung,Haustuer,Innentuer.HWR,Kamin.LED,Kinderzimmer.Decke,Kreis_Hinterhaus,Kreis_TW,Kreis_Tropfen,Kreis_gross,Kreis_klein,Kueche.Decke,Kueche.Esstisch,Kueche.LED,Kueche_Taster_V1,Kueche_Taster_V2,Lichtschalter_Bad_V1,Lichtschalter_Bad_V2,Lichtschalter_Gast_V1,Lichtschalter_Gast_V2,Lichtschalter_Kinderzimmer_V1,Lichtschalter_Kinderzimmer_V2,Lichtschalter_Wohnzimmer_V1,Lichtschalter_Wohnzimmer_V2,Pflanzenlampe,RaffstoreKuecheSued,RaffstoreKuecheWest,RaffstoreWZost,RaffstoreWZsued,RolloKindSued,RolloKindWest,RolloSchlafOst,RolloSchlafSued,Scheinwerfer,Schlafzimmer.Decke,Schuppenlicht,Schuppentuer,SireneOG_Arm,SireneOG_Kanal1,SireneOG_Kanal2,SireneOG_Panik,SmartGrid1,SmartGrid2,Taster_Bad_Btn_01,Taster_Bad_Btn_02,Taster_Bad_Btn_03,Taster_Bad_Btn_04,Taster_Bad_Btn_05,Taster_Bad_Btn_06,Taster_Flur_Btn1,Taster_Flur_Btn2,Terrassenlicht,Toreinfahrt,Treppenbeleuchtung,Tuer.HWR,Warmwasser,Weihnachtsbeleuchtung,Wohnzimmer.Decke,XMASoutdoor
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
3B6DE802 Kueche_Taster_V2
role:
chn 1
vrt 1
tmpl:
Attributes:
model CCU-FHEM
peerIDs 3B6DE802
webCmd press short:press long
Und der physische Taster mit dem ich schalte:
Internals:
DEF 3B6DE802
FUUID 5c66c323-f33f-7f95-780a-cfc602823a689188
NAME Kueche_Taster_V2
NOTIFYDEV global
NR 323
NTFY_ORDER 50-Kueche_Taster_V2
STATE Short 1_18 (to VCCU)
TYPE CUL_HM
chanNo 02
device Kueche_Taster
peerList VCCU_Btn10
CL:
Authenticated 1
AuthenticatedBy admin
AuthenticatedUser admin
BUF
FD 92
FW_ID 639
LASTACCESS 1628253170
NAME WEB_192.168.178.40_57351
NR 643
PEER 192.168.178.40
PORT 57351
SNAME WEB
SSL 1
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-08-06 14:32:48 state Connected
READINGS:
2018-07-12 22:14:34 R-VCCU_Btn10-expectAES off
2018-07-12 22:14:34 R-VCCU_Btn10-peerNeedsBurst off
2017-04-18 13:27:18 R-sign off
2018-07-12 22:16:20 RegL_01. 04:10 08:00 09:00 00:00
2018-07-12 22:16:21 RegL_04.VCCU_Btn10 01:00 00:00
2021-04-12 16:34:17 cfgState ok
2021-08-06 13:36:13 commState CMDs_done
2021-08-06 14:10:52 peerList VCCU_Btn10
2021-08-06 13:36:11 state Short 1_18 (to VCCU)
2021-08-06 13:36:11 trigger Short_18
2018-07-12 22:14:51 triggerTo_Kueche_Taster_virt Short_172
2021-08-06 13:36:11 triggerTo_VCCU Short_18
2021-08-06 13:36:11 trigger_cnt 18
helper:
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:pushButton
regLst 1,4p
cmds:
TmplKey VCCU_Btn10:no:1628251852.34861
TmplTs 1628251852.34861
cmdKey 1:0:0::Kueche_Taster:006B:02:VCCU_Btn10
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_VCCU_Btn10 -tplPeer-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
lst:
condition slider,0,1,255
peer VCCU_Btn10
peerOpt Aussen04,Aussensteckdose,Bad.Decke,Bad.LED,Boden_LEDs,Brunnenpumpe,Buero.Decke,Carportlicht,FlurEG.Decke,FlurOG.Wand,Garten_Haupt,Gast.Decke,GastWC.Decke,HM_5FF962_Sw_04,HWR.Decke,Hauptschalter_Bew,Hausnummernbeleuchtung,Kamin.LED,Kinderzimmer.Decke,Kreis_Hinterhaus,Kreis_TW,Kreis_Tropfen,Kreis_gross,Kreis_klein,Kueche.Decke,Kueche.Esstisch,Kueche.LED,Lichtschalter_Bad_V1,Lichtschalter_Bad_V2,Lichtschalter_Gast_V1,Lichtschalter_Gast_V2,Lichtschalter_Kinderzimmer_V1,Lichtschalter_Kinderzimmer_V2,Lichtschalter_Wohnzimmer_V1,Lichtschalter_Wohnzimmer_V2,Pflanzenlampe,RaffstoreKuecheSued,RaffstoreKuecheWest,RaffstoreWZost,RaffstoreWZsued,RolloKindSued,RolloKindWest,RolloSchlafOst,RolloSchlafSued,Scheinwerfer,Schlafzimmer.Decke,Schuppenlicht,SireneOG_Arm,SireneOG_Kanal1,SireneOG_Kanal2,SireneOG_Panik,SmartGrid1,SmartGrid2,Terrassenlicht,Toreinfahrt,Treppenbeleuchtung,VCCU_Btn1,VCCU_Btn10,VCCU_Btn11,VCCU_Btn12,VCCU_Btn13,VCCU_Btn14,VCCU_Btn15,VCCU_Btn16,VCCU_Btn17,VCCU_Btn18,VCCU_Btn19,VCCU_Btn2,VCCU_Btn20,VCCU_Btn21,VCCU_Btn22,VCCU_Btn23,VCCU_Btn24,VCCU_Btn3,VCCU_Btn4,VCCU_Btn5,VCCU_Btn6,VCCU_Btn7,VCCU_Btn8,VCCU_Btn9,Warmwasser,Weihnachtsbeleuchtung,Wohnzimmer.Decke,XMASoutdoor,virtualswitch01_Btn1,virtualswitch01_Btn10,virtualswitch01_Btn11,virtualswitch01_Btn12,virtualswitch01_Btn13,virtualswitch01_Btn14,virtualswitch01_Btn2,virtualswitch01_Btn3,virtualswitch01_Btn4,virtualswitch01_Btn5,virtualswitch01_Btn6,virtualswitch01_Btn7,virtualswitch01_Btn8,virtualswitch01_Btn9
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
00000000 broadcast
1C695F0A VCCU_Btn10
role:
chn 1
tmpl:
Attributes:
model HM-PB-2-WM55
peerIDs 00000000,1C695F0A
Hier ein Beispiel wo ich zwar einschalten kann, aber nach 1-2 Sekunden schaltet er sofort wieder aus:
Der physische Schalter:
DeviceOverview
Treppenbeleuchtung
on
off
Treppenbeleuchtung
assignHmKey
Treppenbeleuchtung
list
normal
list (normal|hidden);
issue list command for the fiven entity normal or including the hidden parameterInternals
DEF
56D402
FUUID
5c66c324-f33f-7f95-de30-f6dfc335802b29f5
IODev
myHmUART
LASTInputDev
myHmUART
MSGCNT
12
NAME
Treppenbeleuchtung
NOTIFYDEV
global
NR
377
NTFY_ORDER
50-Treppenbeleuchtung
STATE
off
TYPE
CUL_HM
chanNo
01
lastMsg
No:34 - t:02 s:56D402 d:1C695F 0101000044
myHmUART_MSGCNT
12
myHmUART_RAWMSG
0403014034800256D4021C695F0101000044
myHmUART_RSSI
-64
myHmUART_TIME
2021-08-06 14:22:55
protLastRcv
2021-08-06 14:22:55
protRcv
12 last_at:2021-08-06 14:22:55
protResnd
1 last_at:2021-08-06 14:11:43
protSnd
11 last_at:2021-08-06 14:22:54
protState
CMDs_done
rssi_at_myHmUART
cnt:12 min:-64 max:-63 avg:-63.83 lst:-64
rssi_myHmUART
cnt:12 min:-70 max:-68 avg:-68.75 lst:-68
Readings
CommandAccepted
yes
2021-08-06 14:22:55
D-firmware
2.8
2017-11-11 17:25:36
D-serialNr
OEQ0251648
2017-11-11 17:25:36
IODev
myHmUART
2021-08-06 14:10:47
PairedTo
0x1C695F
2021-07-28 13:50:58
R-pairCentral
0x1C695F
2017-11-11 17:25:41
R-powerUpAction
off
2017-11-11 17:25:42
R-sign
off
2017-11-11 17:25:42
RegL_00.
00:00 02:01 0A:1C 0B:69 0C:5F 15:FF 18:00
2021-07-28 13:50:58
RegL_01.
00:00 08:00 30:06 56:00 57:24
2021-07-28 13:50:59
cfgState
ok
2021-07-28 13:51:29
commState
CMDs_done
2021-08-06 14:22:55
deviceMsg
off (to VCCU)
2021-08-06 14:22:55
level
0
2021-08-06 14:22:55
levelMissed
desired:0
2021-08-06 14:11:46
pct
0
2021-08-06 14:22:55
powerOn
2021-07-28 13:50:34
2021-07-28 13:50:34
recentStateType
ack
2021-08-06 14:22:55
state
off
2021-08-06 14:22:55
timedOn
off
2021-08-06 14:22:55
trigLast
fhem:02
2021-08-06 14:22:54
Treppenbeleuchtung
room
Flur EG,Flur OG
Attributes
IODev
myHmUART
deleteattr
IOgrp
VCCU:myHmUART
deleteattr
autoReadReg
4_reqStatus
deleteattr
expert
defReg,rawReg
deleteattr
firmware
2.8
deleteattr
group
Licht
deleteattr
model
HM-LC-SW1-FM
deleteattr
peerIDs
00000000
deleteattr
room
Flur EG,Flur OG
deleteattr
serialNr
OEQ0251648
deleteattr
subType
switch
deleteattr
webCmd
on:off
deleteattr
Probably associated with
FileLog_Treppenbeleuchtung
active
FileLog
FlurLichtOben
active
notify
FlurLichtUnten
2021-08-06 14:12:51
notify
TasterFlurEGNotify1
2021-08-06 14:11:28
notify
TasterFlurEGNotify2
2021-08-06 14:11:28
notify
TasterFlurOGNotify1
2021-08-06 14:11:28
notify
TasterFlurOGNotify2
2021-08-06 14:11:28
notify
Select icon Extend devStateIcon Raw definition Delete this device (Treppenbeleuchtung) Device specific help
Internals:
DEF 56D402
FUUID 5c66c324-f33f-7f95-de30-f6dfc335802b29f5
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 12
NAME Treppenbeleuchtung
NOTIFYDEV global
NR 377
NTFY_ORDER 50-Treppenbeleuchtung
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:34 - t:02 s:56D402 d:1C695F 0101000044
myHmUART_MSGCNT 12
myHmUART_RAWMSG 0403014034800256D4021C695F0101000044
myHmUART_RSSI -64
myHmUART_TIME 2021-08-06 14:22:55
protLastRcv 2021-08-06 14:22:55
protRcv 12 last_at:2021-08-06 14:22:55
protResnd 1 last_at:2021-08-06 14:11:43
protSnd 11 last_at:2021-08-06 14:22:54
protState CMDs_done
rssi_at_myHmUART cnt:12 min:-64 max:-63 avg:-63.83 lst:-64
rssi_myHmUART cnt:12 min:-70 max:-68 avg:-68.75 lst:-68
CL:
Authenticated 1
AuthenticatedBy admin
AuthenticatedUser admin
BUF
FD 92
FW_ID 650
LASTACCESS 1628253243
NAME WEB_192.168.178.40_51053
NR 651
PEER 192.168.178.40
PORT 51053
SNAME WEB
SSL 1
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-08-06 14:34:02 state Connected
READINGS:
2021-08-06 14:22:55 CommandAccepted yes
2017-11-11 17:25:36 D-firmware 2.8
2017-11-11 17:25:36 D-serialNr OEQ0251648
2021-08-06 14:10:47 IODev myHmUART
2021-07-28 13:50:58 PairedTo 0x1C695F
2017-11-11 17:25:41 R-pairCentral 0x1C695F
2017-11-11 17:25:42 R-powerUpAction off
2017-11-11 17:25:42 R-sign off
2021-07-28 13:50:58 RegL_00. 00:00 02:01 0A:1C 0B:69 0C:5F 15:FF 18:00
2021-07-28 13:50:59 RegL_01. 00:00 08:00 30:06 56:00 57:24
2021-07-28 13:51:29 cfgState ok
2021-08-06 14:22:55 commState CMDs_done
2021-08-06 14:22:55 deviceMsg off (to VCCU)
2021-08-06 14:22:55 level 0
2021-08-06 14:11:46 levelMissed desired:0
2021-08-06 14:22:55 pct 0
2021-07-28 13:50:34 powerOn 2021-07-28 13:50:34
2021-08-06 14:22:55 recentStateType ack
2021-08-06 14:22:55 state off
2021-08-06 14:22:55 timedOn off
2021-08-06 14:22:54 trigLast fhem:02
helper:
HM_CMDNR 52
cSnd 111C695F56D4020201C80000,111C695F56D4020201000000
dlvlCmd ++A0111C695F56D4020201000000
mId 0002
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1628252461.36916
TmplTs 1628252461.36916
cmdKey 1:1:0::Treppenbeleuchtung:0002:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt BewegungsmelderSchuppen_M,BewegungsmelderSchuppen_T1,BewegungsmelderSchuppen_T2,Bewegungsmelder_Carport_vorn,Dachfenster,FB_Anja_Btn1,FB_Anja_Btn2,FB_Anja_Btn3,FB_Anja_Btn4,FB_Chris_Btn1,FB_Chris_Btn2,FB_Chris_Btn3,FB_Chris_Btn4,Fenster.BadNord,Fenster.BadWest,Fenster.Buero,Fenster.KinderzimmerSued,Fenster.KinderzimmerWest,Fenster.SchlafzimmerOst,Fenster.SchlafzimmerSued,FensterGast,FensterGastWC,FensterKuecheSpuele,FensterKuecheSued,FensterKuecheWest,FensterWZOst,FensterWZSued,FlurEGBewegungsmelder_M,FlurEGBewegungsmelder_T1,FlurEGBewegungsmelder_T2,FlurOGBewegungsmelder_M,FlurOGBewegungsmelder_T1,FlurOGBewegungsmelder_T2,HWRBewegungsmelder_M,HWRBewegungsmelder_T1,HWRBewegungsmelder_T2,Haustuer,Innentuer.HWR,Kueche_Taster_V1,Kueche_Taster_V2,Schuppentuer,Taster_Bad_Btn_01,Taster_Bad_Btn_02,Taster_Bad_Btn_03,Taster_Bad_Btn_04,Taster_Bad_Btn_05,Taster_Bad_Btn_06,Taster_Flur_Btn1,Taster_Flur_Btn2,Tuer.HWR,VCCU_Btn1,VCCU_Btn10,VCCU_Btn11,VCCU_Btn12,VCCU_Btn13,VCCU_Btn14,VCCU_Btn15,VCCU_Btn16,VCCU_Btn17,VCCU_Btn18,VCCU_Btn19,VCCU_Btn2,VCCU_Btn20,VCCU_Btn21,VCCU_Btn22,VCCU_Btn23,VCCU_Btn24,VCCU_Btn3,VCCU_Btn4,VCCU_Btn5,VCCU_Btn6,VCCU_Btn7,VCCU_Btn8,VCCU_Btn9,virtualswitch01_Btn1,virtualswitch01_Btn10,virtualswitch01_Btn11,virtualswitch01_Btn12,virtualswitch01_Btn13,virtualswitch01_Btn14,virtualswitch01_Btn2,virtualswitch01_Btn3,virtualswitch01_Btn4,virtualswitch01_Btn5,virtualswitch01_Btn6,virtualswitch01_Btn7,virtualswitch01_Btn8,virtualswitch01_Btn9
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +56D402,00,01,00
nextSend 1628252575.1602
rxt 0
vccu VCCU
p:
56D402
00
01
00
prefIO:
myHmUART
mRssi:
mNo 34
io:
myHmUART:
-60
-60
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
at_myHmUART:
avg -63.8333333333333
cnt 12
lst -64
max -63
min -64
myHmUART:
avg -68.75
cnt 12
lst -68
max -68
min -70
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 2.8
group Licht
model HM-LC-SW1-FM
peerIDs 00000000
room Flur EG,Flur OG
serialNr OEQ0251648
subType switch
webCmd on:off
Notify fürs einschalten:
DEF
FlurEGBewegungsmelder_T1 set Treppenbeleuchtung on
FUUID
5c66c321-f33f-7f95-6aaf-1d90f30995909208
NAME
TasterFlurEGNotify1
NOTIFYDEV
FlurEGBewegungsmelder_T1
NR
191
NTFY_ORDER
50-TasterFlurEGNotify1
REGEXP
FlurEGBewegungsmelder_T1
STATE
2021-08-06 14:11:28
TRIGGERTIME
1628251888.49983
TYPE
notify
Notify fürs ausschalten:
DEF
FlurEGBewegungsmelder_T2 set Treppenbeleuchtung off
FUUID
5c66c321-f33f-7f95-e2d4-9973904f43ff677a
NAME
TasterFlurEGNotify2
NOTIFYDEV
FlurEGBewegungsmelder_T2
NR
192
NTFY_ORDER
50-TasterFlurEGNotify2
REGEXP
FlurEGBewegungsmelder_T2
STATE
2021-08-06 14:11:28
TRIGGERTIME
1628251888.52583
TYPE
notify
Taster vom Bewegungsmelder fürs ausschalten:
Internals:
DEF 361C3502
FUUID 5c66c320-f33f-7f95-7530-05c96886342f4454
NAME FlurEGBewegungsmelder_T2
NOTIFYDEV global
NR 90
NTFY_ORDER 50-FlurEGBewegungsmelder_T2
STATE Short 1_210 (to VCCU)
TYPE CUL_HM
chanNo 02
device FlurEGBewegungsmelder
peerList VCCU_Btn14
CL:
Authenticated 1
AuthenticatedBy admin
AuthenticatedUser admin
BUF
FD 92
FW_ID 683
LASTACCESS 1628253591
NAME WEB_192.168.178.40_58379
NR 690
PEER 192.168.178.40
PORT 58379
SNAME WEB
SSL 1
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-08-06 14:39:47 state Connected
READINGS:
2018-07-13 19:20:59 R-VCCU_Btn14-expectAES off
2018-07-13 19:20:59 R-VCCU_Btn14-peerNeedsBurst off
2017-01-11 23:12:29 R-sign off
2018-07-13 19:20:57 RegL_01. 04:10 09:00 08:00 22:C8 30:03 00:00
2018-07-13 19:20:59 RegL_04.VCCU_Btn14 01:00 00:00
2021-04-12 16:34:16 cfgState ok
2021-08-06 14:02:48 commState CMDs_done
2021-08-06 14:11:28 motion off
2021-08-06 14:10:51 peerList VCCU_Btn14
2021-08-06 14:37:38 state Short 1_210 (to VCCU)
2021-08-06 14:37:38 trigger Short_210
2021-08-06 13:59:29 triggerTo_VCCU Short_209
2021-08-06 14:37:38 trigger_cnt 210
helper:
BNO 210
BNOCNT 1
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:motionAndBtn
regLst 1,4p
cmds:
TmplKey VCCU_Btn14:no:1628251851.29506
TmplTs 1628251851.29506
cmdKey 1:0:0::FlurEGBewegungsmelder:00DB:02:VCCU_Btn14
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_VCCU_Btn14 -tplPeer-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
lst:
condition slider,0,1,255
peer VCCU_Btn14
peerOpt Aussen04,Aussensteckdose,Bad.Decke,Bad.LED,Boden_LEDs,Brunnenpumpe,Buero.Decke,Carportlicht,FlurEG.Decke,FlurOG.Wand,Garten_Haupt,Gast.Decke,GastWC.Decke,HM_5FF962_Sw_04,HWR.Decke,Hauptschalter_Bew,Hausnummernbeleuchtung,Kamin.LED,Kinderzimmer.Decke,Kreis_Hinterhaus,Kreis_TW,Kreis_Tropfen,Kreis_gross,Kreis_klein,Kueche.Decke,Kueche.Esstisch,Kueche.LED,Lichtschalter_Bad_V1,Lichtschalter_Bad_V2,Lichtschalter_Gast_V1,Lichtschalter_Gast_V2,Lichtschalter_Kinderzimmer_V1,Lichtschalter_Kinderzimmer_V2,Lichtschalter_Wohnzimmer_V1,Lichtschalter_Wohnzimmer_V2,Pflanzenlampe,RaffstoreKuecheSued,RaffstoreKuecheWest,RaffstoreWZost,RaffstoreWZsued,RolloKindSued,RolloKindWest,RolloSchlafOst,RolloSchlafSued,Scheinwerfer,Schlafzimmer.Decke,Schuppenlicht,SireneOG_Arm,SireneOG_Kanal1,SireneOG_Kanal2,SireneOG_Panik,SmartGrid1,SmartGrid2,Terrassenlicht,Toreinfahrt,Treppenbeleuchtung,VCCU_Btn1,VCCU_Btn10,VCCU_Btn11,VCCU_Btn12,VCCU_Btn13,VCCU_Btn14,VCCU_Btn15,VCCU_Btn16,VCCU_Btn17,VCCU_Btn18,VCCU_Btn19,VCCU_Btn2,VCCU_Btn20,VCCU_Btn21,VCCU_Btn22,VCCU_Btn23,VCCU_Btn24,VCCU_Btn3,VCCU_Btn4,VCCU_Btn5,VCCU_Btn6,VCCU_Btn7,VCCU_Btn8,VCCU_Btn9,Warmwasser,Weihnachtsbeleuchtung,Wohnzimmer.Decke,XMASoutdoor,virtualswitch01_Btn1,virtualswitch01_Btn10,virtualswitch01_Btn11,virtualswitch01_Btn12,virtualswitch01_Btn13,virtualswitch01_Btn14,virtualswitch01_Btn2,virtualswitch01_Btn3,virtualswitch01_Btn4,virtualswitch01_Btn5,virtualswitch01_Btn6,virtualswitch01_Btn7,virtualswitch01_Btn8,virtualswitch01_Btn9
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
00000000 broadcast
1C695F0E VCCU_Btn14
role:
chn 1
tmpl:
Attributes:
group Devices
model HM-SEN-MDIR-WM55
peerIDs 00000000,1C695F0E
room hidden
Taster vom Bewegungsmelder fürs einschalten:
DeviceOverview
FlurEGBewegungsmelder_T1
Short 1_85 (to VCCU)
FlurEGBewegungsmelder_T1
clear
msgErrors
FlurEGBewegungsmelder_T1
list
normal
list (normal|hidden);
issue list command for the fiven entity normal or including the hidden parameterInternals
DEF
361C3501
FUUID
5c66c320-f33f-7f95-f530-0fc81869b8b55cab
NAME
FlurEGBewegungsmelder_T1
NOTIFYDEV
global
NR
89
NTFY_ORDER
50-FlurEGBewegungsmelder_T1
STATE
Short 1_85 (to VCCU)
TYPE
CUL_HM
chanNo
01
device
FlurEGBewegungsmelder
peerList
VCCU_Btn13
Readings
R-VCCU_Btn13-expectAES
off
2018-07-13 19:20:58
R-VCCU_Btn13-peerNeedsBurst
off
2018-07-13 19:20:58
R-sign
off
2017-01-11 23:12:28
RegL_01.
04:10 09:00 08:00 22:C8 30:03 00:00
2018-07-13 19:20:56
RegL_04.VCCU_Btn13
01:00 00:00
2018-07-13 19:20:58
cfgState
ok
2021-04-12 16:34:16
commState
CMDs_done
2021-08-06 14:02:48
motion
off
2021-08-06 14:11:28
peerList
VCCU_Btn13
2021-08-06 14:10:51
state
Short 1_85 (to VCCU)
2021-08-06 14:37:35
trigger
Short_85
2021-08-06 14:37:35
triggerTo_VCCU
Short_84
2021-08-06 13:47:29
trigger_cnt
85
2021-08-06 14:37:35
FlurEGBewegungsmelder_T1
room
hidden
Attributes
group
Devices
deleteattr
model
HM-SEN-MDIR-WM55
deleteattr
peerIDs
00000000,1C695F0D
deleteattr
room
hidden
deleteattr
Probably associated with
FlurEGBewegungsmelder
CMDs_done
CUL_HM
FlurEGBewegungsmelder_M
motion
CUL_HM
FlurEGBewegungsmelder_T2
Short 1_210 (to VCCU)
CUL_HM
TasterFlurEGNotify1
2021-08-06 14:37:35
notify
VCCU_Btn13
set_press short all Burst 0 0.25
CUL_HM
virtualswitch01_Btn5
set_press short all Burst 0 0.25
CUL_HM
Select icon Extend devStateIcon Raw definition Delete this device (FlurEGBewegungsmelder_T1) Device specific help
Internals:
DEF 361C3501
FUUID 5c66c320-f33f-7f95-f530-0fc81869b8b55cab
NAME FlurEGBewegungsmelder_T1
NOTIFYDEV global
NR 89
NTFY_ORDER 50-FlurEGBewegungsmelder_T1
STATE Short 1_85 (to VCCU)
TYPE CUL_HM
chanNo 01
device FlurEGBewegungsmelder
peerList VCCU_Btn13
CL:
Authenticated 1
AuthenticatedBy admin
AuthenticatedUser admin
BUF
FD 94
FW_ID 690
LASTACCESS 1628253653
NAME WEB_192.168.178.40_62904
NR 695
PEER 192.168.178.40
PORT 62904
SNAME WEB
SSL 1
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-08-06 14:40:50 state Connected
READINGS:
2018-07-13 19:20:58 R-VCCU_Btn13-expectAES off
2018-07-13 19:20:58 R-VCCU_Btn13-peerNeedsBurst off
2017-01-11 23:12:28 R-sign off
2018-07-13 19:20:56 RegL_01. 04:10 09:00 08:00 22:C8 30:03 00:00
2018-07-13 19:20:58 RegL_04.VCCU_Btn13 01:00 00:00
2021-04-12 16:34:16 cfgState ok
2021-08-06 14:02:48 commState CMDs_done
2021-08-06 14:11:28 motion off
2021-08-06 14:10:51 peerList VCCU_Btn13
2021-08-06 14:37:35 state Short 1_85 (to VCCU)
2021-08-06 14:37:35 trigger Short_85
2021-08-06 13:47:29 triggerTo_VCCU Short_84
2021-08-06 14:37:35 trigger_cnt 85
helper:
BNO 85
BNOCNT 1
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:motionAndBtn
regLst 1,4p
cmds:
TmplKey VCCU_Btn13:no:1628251851.28999
TmplTs 1628251851.28999
cmdKey 1:0:0::FlurEGBewegungsmelder:00DB:01:VCCU_Btn13
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_VCCU_Btn13 -tplPeer-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
lst:
condition slider,0,1,255
peer VCCU_Btn13
peerOpt Aussen04,Aussensteckdose,Bad.Decke,Bad.LED,Boden_LEDs,Brunnenpumpe,Buero.Decke,Carportlicht,FlurEG.Decke,FlurOG.Wand,Garten_Haupt,Gast.Decke,GastWC.Decke,HM_5FF962_Sw_04,HWR.Decke,Hauptschalter_Bew,Hausnummernbeleuchtung,Kamin.LED,Kinderzimmer.Decke,Kreis_Hinterhaus,Kreis_TW,Kreis_Tropfen,Kreis_gross,Kreis_klein,Kueche.Decke,Kueche.Esstisch,Kueche.LED,Lichtschalter_Bad_V1,Lichtschalter_Bad_V2,Lichtschalter_Gast_V1,Lichtschalter_Gast_V2,Lichtschalter_Kinderzimmer_V1,Lichtschalter_Kinderzimmer_V2,Lichtschalter_Wohnzimmer_V1,Lichtschalter_Wohnzimmer_V2,Pflanzenlampe,RaffstoreKuecheSued,RaffstoreKuecheWest,RaffstoreWZost,RaffstoreWZsued,RolloKindSued,RolloKindWest,RolloSchlafOst,RolloSchlafSued,Scheinwerfer,Schlafzimmer.Decke,Schuppenlicht,SireneOG_Arm,SireneOG_Kanal1,SireneOG_Kanal2,SireneOG_Panik,SmartGrid1,SmartGrid2,Terrassenlicht,Toreinfahrt,Treppenbeleuchtung,VCCU_Btn1,VCCU_Btn10,VCCU_Btn11,VCCU_Btn12,VCCU_Btn13,VCCU_Btn14,VCCU_Btn15,VCCU_Btn16,VCCU_Btn17,VCCU_Btn18,VCCU_Btn19,VCCU_Btn2,VCCU_Btn20,VCCU_Btn21,VCCU_Btn22,VCCU_Btn23,VCCU_Btn24,VCCU_Btn3,VCCU_Btn4,VCCU_Btn5,VCCU_Btn6,VCCU_Btn7,VCCU_Btn8,VCCU_Btn9,Warmwasser,Weihnachtsbeleuchtung,Wohnzimmer.Decke,XMASoutdoor,virtualswitch01_Btn1,virtualswitch01_Btn10,virtualswitch01_Btn11,virtualswitch01_Btn12,virtualswitch01_Btn13,virtualswitch01_Btn14,virtualswitch01_Btn2,virtualswitch01_Btn3,virtualswitch01_Btn4,virtualswitch01_Btn5,virtualswitch01_Btn6,virtualswitch01_Btn7,virtualswitch01_Btn8,virtualswitch01_Btn9
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
00000000 broadcast
1C695F0D VCCU_Btn13
role:
chn 1
tmpl:
Attributes:
group Devices
model HM-SEN-MDIR-WM55
peerIDs 00000000,1C695F0D
room hidden
Hab ich da irgendwas mit Virtuals Switch und Button durcheinander gewürfelt damit ich grünes Licht am Taster bekomme ?!
Hi,
schau Dir mal bitte im Eventmonitor an was passiert wenn Du einen der Taster drückst:
Filter im Eventmonitor:
FlurEGBewegungsmelder.*
Damit sollte Dir klar werden, dass beide notify Mist sind.
Und hier steht warum es früher vielleicht mal funktionierte und jetzt nicht mehr:
https://forum.fhem.de/index.php/topic,120240.msg1147280.html#msg1147280
Warum peerst Du den Taster nicht einfach mit dem Aktor? Wozu den Umweg über Virtuellen Button und notify?
Gruß Otto
Okay, du hast mich überredet... ich habe jetzt alle Taster direkt gepeert. Schnellere Reaktion und unabhängig vom Raspi, das ist schon fein. Jetzt wirds aber kompliziert, denn für den Bewegungsmelder an sich brauche ich nun mal ein Notify. Was soll hier ran denn falsch sein, was genau geht da seit dem Update nicht mehr ?!
FlurOGBewegungsmelder_M:motion:.on.*
{
if ((Value("Treppenbeleuchtung") eq "off") &&
(ReadingsVal("FlurOGBewegungsmelder_M","brightness","") < "100") &&
(
(ReadingsVal("rr_A","state","") eq "home") ||
(ReadingsVal("rr_B","state","") eq "home") )
)
{
fhem ("set Treppenbeleuchtung on-for-timer 240")
}
}
Soll ich auf Level oder PCT triggern ?
Da sind auf jeden Fall einige Klammern zuviel.
Du kannst auch den Bewegungsmelder mit dem Aktor peeren. Ist bezüglich Zeitdauer und Helligkeit etwas komplizierter, aber dafür gab es ein Template.
An einem notify ist nichts verkehrt, man darf es bloß nicht (wie deinem ursprünglichen) auf alle Events reagieren lassen. Bei dem Update wurde geändert, das jetzt alle Homematic Channel eine Status Meldung schicken, wenn sich in einem Channel etwas tut. :'( :'( :'(
Den Bewegungsmeldet kann ich nicht direkt mit dem Aktor peeren, da ich ja nur zu bestimmten Situationen Licht brauche. Im Notify versuche ich quasi dass er nur schaltet, wenn es dunkel ist und jemand daheim ist - sonst gehts Licht nachts an wenn die Katze durchs Haus tigert ;-)
Bisher ging das Notify ja auch, aber das ist eines derer die halt nach dem Update nicht mehr gehen. Und das triggert doch nur auf motion ? Es ist der gleiche Effekt: Licht an und aus binnen 1 Sekunde auch wenn es hell ist - irgendwas bekommt der da nicht richtig übermittelt...
Zitater nur schaltet, wenn es dunkel ist und jemand daheim ist
set <aktor> inhibit [on|off]https://forum.fhem.de/index.php?topic=80618.0 (https://forum.fhem.de/index.php?topic=80618.0)
Zitat: Ich nutze zur "Winterblockade" der Terrassendachmarkise jetzt "inhibit" auf dem HM-Rolladenaktor (mit Wippe). Das Ein- und Ausschalten funktioniert, die Peers werden ignoriert (konkret: sie bekommen ein "Nack" und die LED leuchtet rot statt grün).
Wenn Du das schaltest, abhängig von der Anwesenheit, dann schaltet nur noch die Katze nachts wenn Du anwesend bist.
Das Registger für die Schwellhelligkeit hast Du gesetzt.
So habe ich es gemacht. Schwellwert, damit es nur bei Dunkelheit schaltet und inhibit weil bei Alarm das Licht blinkt und der Einbecher es nicht ausschalten soll. Die Katze darf sich Licht anmachen.
Zitat von: MegaData am 11 August 2021, 08:19:23
Bisher ging das Notify ja auch, aber das ist eines derer die halt nach dem Update nicht mehr gehen. Und das triggert doch nur auf motion ? Es ist der gleiche Effekt: Licht an und aus binnen 1 Sekunde auch wenn es hell ist - irgendwas bekommt der da nicht richtig übermittelt...
dieses notify schaltet aber nicht aus. Das dein Licht nach einer Sekunde wieder ausschaltet muss an einem anderen notify/device liegen? Hast Du alles geprüft?