Hallo!
Ich habe eine Überwachung aller Fenster und Türen realisiert und will mich nur bei meiner Abwesenheit über das Öffnen jedes Gerätes bzw. das Geschlossensein aller Geräte informieren lassen.
Die Kontakte sind zwei HM-Tri-State Kontakte und IT-Kontakte aus China.
In den Übersichten über alle Kontakte werden die Zustandsänderungen und die Zustände zuverlässig richtig angezeigt. Im Überwachungs-DOIF funzt der erste Zweig, der zweite leider nicht.
Habt ihr eine Idee?
Hier das DOIF:
Internals:
DEF (["Fenster:offen"] or ["FL_Tuer:offen"] or ["WZ_Balkon:offen"])
()(IF ([androiduwe] ne "1.0") (set Nachrichten message $DEVICE ist geöffnet))
DOELSEIF
(["Fenster:geschlossen"] and ["FL_Tuer:geschlossen"] and ["WZ_Balkon:geschlossen"])
()(IF ([androiduwe] ne "1.0") (set Nachrichten message Tür und alle Fenster sind geschlossen))
NAME Fenster_check
NR 746
NTFY_ORDER 50-Fenster_check
STATE cmd_1
TYPE DOIF
READINGS:
2017-09-18 15:49:13 Device WZ_Balkon
2017-09-18 15:49:13 cmd 1.2
2017-09-18 15:49:13 cmd_event WZ_Balkon
2017-09-18 15:49:13 cmd_nr 1
2017-09-18 15:49:13 cmd_seqnr 2
2017-09-18 15:46:43 matched_event_c1_1 offen
2017-09-18 15:49:13 matched_event_c1_3 contact: offen (to VCCU)
2017-09-18 15:46:57 matched_event_c2_1 geschlossen
2017-09-18 15:48:25 matched_event_c2_3 contact: geschlossen (to VCCU)
2017-09-18 15:49:13 state cmd_1
condition:
0 EventDoIf('Fenster',$hash,'offen',0) or EventDoIf('FL_Tuer',$hash,'offen',0) or EventDoIf('WZ_Balkon',$hash,'offen',0)
1 EventDoIf('Fenster',$hash,'geschlossen',0) and EventDoIf('FL_Tuer',$hash,'geschlossen',0) and EventDoIf('WZ_Balkon',$hash,'geschlossen',0)
devices:
do:
0:
0
1 IF ([androiduwe] ne "1.0") (set Nachrichten message $DEVICE ist geöffnet)
1:
0
1 IF ([androiduwe] ne "1.0") (set Nachrichten message Tür und alle Fenster sind geschlossen)
2:
helper:
event contact: offen (to VCCU)
globalinit 1
last_timer 0
sleeptimer -1
timerdev WZ_Balkon
timerevent contact: offen (to VCCU)
triggerDev WZ_Balkon
timerevents:
battery: ok
contact: offen (to VCCU)
offen
trigger_cnt: 186
timereventsState:
battery: ok
contact: offen (to VCCU)
state: open
trigger_cnt: 186
triggerEvents:
battery: ok
contact: offen (to VCCU)
offen
trigger_cnt: 186
triggerEventsState:
battery: ok
contact: offen (to VCCU)
state: open
trigger_cnt: 186
internals:
itimer:
readings:
regexp:
0:
0 Fenster:offen
1 FL_Tuer:offen
2 WZ_Balkon:offen
1:
0 Fenster:geschlossen
1 FL_Tuer:geschlossen
2 WZ_Balkon:geschlossen
all:
0 Fenster:offen
1 FL_Tuer:offen
2 WZ_Balkon:offen
3 Fenster:geschlossen
4 FL_Tuer:geschlossen
5 WZ_Balkon:geschlossen
state:
STATE:
trigger:
Attributes:
devStateIcon cmd_1:LED.red cmd_2:LED.green
do always
room 010Wohnung
WZ_Balkon ist ein HM-Kontakt, der andere wird mit der jeweils ersten Abfrage mit abgefragt, FL_Tuer frage ich separat ab, da er nicht in die allg. Namenskonvention passt.
Der erste Ausführungsteil ist leer, da nichts weiter passieren soll, solange ich da bin.
Der zweite Teil, schickt mir bei Abwesenheit die Nachricht (hier habe ich gleich mal herausgefunden, dass IF auch im Ausführungsteil funzt :) ).
Der Türkontakt sieht so aus:
Internals:
CFGFN ./FHEM/067_FL.cfg
CUNO2_MSGCNT 40
CUNO2_RAWMSG i7a99a7
CUNO2_RSSI -48.5
CUNO2_TIME 2017-09-18 15:06:55
DEF 1527x7a99a 1110 0111 1011 0000
IODev CUNO2
LASTInputDev CUNO2
MSGCNT 40
NAME FL_Tuer
NR 271
STATE geschlossen
TYPE IT
XMIT f1dddfdfdd
XMITdimdown 0000
XMITdimup 1011
XMIToff 0111
XMITon 1110
CODE:
1 1527x7a99a
READINGS:
2017-09-18 15:06:55 Activity alive
2017-06-16 22:49:54 Batteriedauer_alt 0
2017-09-18 04:05:00 Batteriewechsel 154
2017-09-18 15:06:55 Last_closed 2017-09-18 15:06:55
2017-09-18 15:06:50 Last_open 2017-09-18 15:06:50
2017-09-18 15:06:55 dim 0
2017-06-16 20:58:03 lastDimValue
2017-06-16 19:25:34 protocol EV1527
2017-09-18 15:06:55 state off
Attributes:
IODev CUNO2
eventMap off:geschlossen on:offen dimup:Sabotage dimdown:Batt?
model itdimmer
room 007Flur
webCmd :
Ebenso sind die IT-Fensterkontakte definiert: AZ_Fenster, SZ_Fenster usw.
HM ist die Balkontür und das Badfenster:
Internals:
CFGFN ./FHEM/064_BD.cfg
DEF 149A4C
HMLAN1_MSGCNT 9
HMLAN1_RAWMSG E149A4C,0000,8DCDAA40,FF,FFA6,D6A441149A4CF1123401A700
HMLAN1_RSSI -90
HMLAN1_TIME 2017-09-17 20:09:31
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 11
NAME BD_Fenster
NOTIFYDEV global
NR 179
NTFY_ORDER 50-BD_Fenster
STATE geschlossen
TYPE CUL_HM
lastMsg No:D6 - t:41 s:149A4C d:F11234 01A700
myHmUART_MSGCNT 2
myHmUART_RAWMSG 05000059D4A441149A4CF1123401A5C8
myHmUART_RSSI -89
myHmUART_TIME 2017-09-17 19:59:25
protLastRcv 2017-09-17 20:09:31
protSnd 9 last_at:2017-09-17 20:09:31
protState CMDs_done
rssi_at_HMLAN1 avg:-89.77 max:-83 min:-98 cnt:9 lst:-90
rssi_at_myHmUART cnt:2 lst:-89 avg:-91 max:-89 min:-93
READINGS:
2017-09-16 13:47:12 Activity alive
2017-03-20 17:52:51 Batteriedauer_alt 0
2017-09-18 04:05:00 Batteriewechsel 864
2017-02-20 16:49:28 D-firmware 2.0
2017-02-20 16:49:28 D-serialNr IEQ0044944
2017-09-17 20:09:31 battery ok
2017-09-17 20:09:31 contact closed (to VCCU)
2017-09-17 20:09:31 state closed
2017-09-17 20:09:31 trigger_cnt 167
helper:
HM_CMDNR 214
mId 0030
rxType 4
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +149A4C,00,00,00
nextSend 1505671771.1208
rxt 0
vccu VCCU
p:
149A4C
00
00
00
mRssi:
mNo D6
io:
HMLAN1 -88
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rpt:
IO HMLAN1
flg A
ts 1505671771.03487
ack:
HASH(0x301f6e8)
D68002F11234149A4C00
rssi:
at_HMLAN1:
avg -89.7777777777778
cnt 9
lst -90
max -83
min -98
at_myHmUART:
avg -91
cnt 2
lst -89
max -89
min -93
shadowReg:
tmpl:
Attributes:
IODev HMLAN1
IOgrp VCCU
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
eventMap /tilted:gekippt/open:offen/closed:geschlossen/
expert 2_full
firmware 2.0
fp_ETW 26,596,0,
model HM-SEC-RHS
peerIDs 00000000,
room 004Bad
serialNr IEQ0044944
subType threeStateSensor
Danke, Uwe.
(["Fenster:geschlossen"] and ["FL_Tuer:geschlossen"] and ["WZ_Balkon:geschlossen"])
Logisch. Es werden niemals alle 3 Events zeitgleich kommen, daher kann das nie war sein. Schau dir Mal an wie das in der Commandref erklärt ist.
https://fhem.de/commandref_DE.html#DOIF_aggregation
Ich habe mich beim Erstellen des DOIFs an Folgendem orientiert:
https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events (https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events)
Ist das Bsp. aus deinem genannten Link der richtige Ansatz?
define di_Fenster DOIF (["^Window:open"])
(push "Fenster $DEVICE wurde geöffnet. Es sind folgende Fenster offen: [@"^Window":state:"open"]")
DOELSEIF ([#"^Window:closed":state:"open"] == 0)
(push "alle Fenster geschlossen")
attr di_Fenster do always
attr di_Fenster cmdState $DEVICE zuletzt geöffnet|alle geschlossen
D.h. für mein DOIF etwa so?
DOELSEIF
(([#"^Fenster:geschlossen":state:"offen"]==0) and ["FL_Tuer:geschlossen"] and ["WZ_Balkon:geschlossen"])
Du musst alle in die Zählung mit rein nehmen. Ob und wie das geht muss ich auch erst in Ruhe schauen. Geht erst heute Abend.
Noch mal zur Logik. Es kann nicht zur selben Zeit alle Events war sein weil sie nicht gleichzeitig auftreten können.
Deine Aussage mit der Logik verstehe ich nicht ganz:
Mit der zweiten Abfrage prüfe ich nur die Tür und mit der 3. nur die Balkontür. Alle anderen fasse ich (denke ich) in der ersten Abfrage zusammen.
Das sind: AZ_Fenster, SZ_Fenster, KU_Fenster, WZ_Fenster <- alles IT
und BD_Fenster <- HM.
Oder funzt die UND-Verknüpfung nicht?
Nachtrag: ich habe mal die 2. und 3. Abfrage entfernt, dann funzt meine originale Version.
Wie kann ich dann die beiden Türen erfassen, ohne die Namenskonvention zu ändern?
Nein Du prüfst nicht, du triggert auf ein Event
[?FL_Tuer:state] eq "geschlossen" and [?WZ_Balkon:state] eq "geschlossen"
Das wäre prüfen
Zitat von: locodriver am 18 September 2017, 18:38:27
Deine Aussage mit der Logik verstehe ich nicht ganz:
Mit der zweiten Abfrage prüfe ich nur die Tür und mit der 3. nur die Balkontür. Alle anderen fasse ich (denke ich) in der ersten Abfrage zusammen.
Das sind: AZ_Fenster, SZ_Fenster, KU_Fenster, WZ_Fenster <- alles IT
und BD_Fenster <- HM.
Oder funzt die UND-Verknüpfung nicht?
Nachtrag: ich habe mal die 2. und 3. Abfrage entfernt, dann funzt meine originale Version.
Wie kann ich dann die beiden Türen erfassen, ohne die Namenskonvention zu ändern?
Wenn Deine Fenster alle in der Mitte des Devicenamens Fenster drin hat, kann das
(([#"^Fenster:geschlossen":state:"offen"]==0)
Nicht gehen.
Da hast du natürlich Recht, ich habe mich nicht korrekt ausgedrückt...
Habe jetz mal testweise die Türen umbenannt:
WZ_Balkon -> WZ_BalkonFenster und
FL_Tuer -> FL_TuerFenster.
Damit werden alle Kontakte mit der ersten Abfrage erfasst, ich habe dann bei beiden noch einen Alias mit den "alten" Namen angelegt - aber der Weisheit letzter Schluss ist das noch nicht, auch wenn es wie gewünscht funzt ;) .
Zu früh gefreut, der Zustand wechselt jetzt auf cmd_2, sobald ein Kontakt geschlossen wird, egal ob andere noch geöffnet sind .
Es ist durchaus möglich das er bei der Aggregierung noch mal den state der anderen ab fragt. Dann kannst du WZ Balkon und FL Tür auch so machen wie Fenster und alle drei mit und verbinden. Ich teste das Mal auf meinem Testsystem
Danke, dass du dich der Sache mit annimmst.
Die - nicht so "elegante" - Alternative wäre sonst nur noch, alle Kontakte einzeln abzufragen. Dann müsste ich bei jeder Änderung auch das DOIF mit anpassen...
DEF (["Fenster:offen"] or ["FL_Tuer:offen"] or ["WZ_Balkon:offen"]) ( set dummyFensterInfo Fenster $DEVICE wurde geöffnet.) DOELSEIF ([#"Fenster:geschlossen":state:"offen"]==0 and [#"^WZ_Balkon:geschlossen":state:"offen"]==0 and [#"^FL_Tuer:geschlossen":state:"offen"]==0) (set dummyFensterInfo alle Fenster geschlossen)
Klappt perfekt. Einfach entsprechend erweitern wie du es bereis hattest. Mir ging es nur um Balkon und FL_Tuer mit der Aggregierung. Und das klappt genau so
@CoolTux: Danke, funktioniert :) . Mit der Aggregation habe ich mich bis jetzt noch nicht befasst, weil ich es noch nie benötigt habe. Aber jetzt ist das ein Anlass, sich "weiter zu bilden".
Reicht beim Zu-Fall :D nicht ein (bedingungsloses) DOELSE?