Heizthermostat reagiert nicht auf Fensterkontakt

teichtaucher · 03 Dezember 2019, 14:20:23

Hallo,
ich habe im Wohnzimmer mehrere Fenster und mehrere Heizkörper. Bisher hatte ich alle Heizkörper mit zwei Fenstersensoren gepeered. Das hat auch einwandfrei funktioniert.
Jetzt habe ich zwei neue Fensterkontakte dazubestellt und diese montiert. Bei einem hat das peeren mit den Heizthermostaten einwandfrei funktioniert der andere macht Probleme. Komischerweise sehe ich bei allen Heizthermostaten beide neuen Fensterkontakte (5E0CB8,5DA3C6) in den PeerIDs, z.B. dieser hier:

Code Auswählen


Internals:
   DEF        2E75D103
   FUUID      5cb63bfd-f33f-d318-3201-891c48ab2304b668
   NAME       wz.ht.Couch_WindowRec
   NOTIFYDEV  global
   NR         101
   NTFY_ORDER 50-wz.ht.Couch_WindowRec
   STATE      last:trigLast
   TYPE       CUL_HM
   chanNo     03
   device     wz.Ht.Couch
   peerList   ku.fk.Schiebetuer,wz.fk.Garten,wz.fk.FensterSpiel,wz.fk.FensterCouch,
   READINGS:
     2017-10-01 20:50:14   R-sign          off
     2019-12-03 14:07:23   RegL_01.         00:00 08:00
     2019-12-03 14:07:23   RegL_03.ku.fk.Schiebetuer_chn-01  00:00 04:32
     2019-12-03 14:07:24   RegL_03.wz.fk.FensterCouch_chn-01  00:00 04:32
     2019-12-03 14:07:24   RegL_03.wz.fk.FensterSpiel_chn-01  00:00 04:32
     2019-12-03 14:07:23   RegL_03.wz.fk.Garten_chn-01  00:00 04:32
     2019-12-03 14:07:25   RegL_07.ku.fk.Schiebetuer_chn-01  00:00 05:0A
     2019-12-03 14:07:26   RegL_07.wz.fk.FensterCouch_chn-01  00:00 05:18
     2019-12-03 14:07:26   RegL_07.wz.fk.FensterSpiel_chn-01  00:00 05:18
     2019-12-03 14:07:25   RegL_07.wz.fk.Garten_chn-01  00:00 05:0A
     2019-12-03 14:07:22   peerList        ku.fk.Schiebetuer,wz.fk.Garten,wz.fk.FensterSpiel,wz.fk.FensterCouch,
     2019-12-03 14:07:22   state           unknown
   helper:
     peerFriend peerSens,peerVirt
     peerIDsRaw ,44257C01,58BBFC01,5E0CB801,5DA3C601,00000000
     peerOpt    3:thermostat,7p:thermostat
     regLst     1,3p,7p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
Attributes:
   model      HM-CC-RT-DN
   peerIDs    00000000,44257C01,58BBFC01,5DA3C601,5E0CB801,
   room       Wohnzimmer
   stateFormat last:trigLast

Und hier ist das Problemkind. Ich habe beim Peeren alles genauso gemacht wie bei dem andren Fensterkontakt (z.B. set wz.fk.FensterCouch peerChan 0 wz.ht.Essecke_WindowRec single set) und danach die Anlerntaste gedrückt. Das einzige was mir aufgefallen ist ist dass der funktionierende FK schnell geblinkt hat und das Problemkind nur langsam.

Code Auswählen


Internals:
   CFGFN      
   DEF        5E0CB8
   FUUID      5de5695b-f33f-d318-adfd-6e3baee14125e3e4
   HMLAN1_MSGCNT 95
   HMLAN1_RAWMSG E5E0CB8,0000,4CD6358F,FF,FFBD,A586415E0CB8000000012E00
   HMLAN1_RSSI -67
   HMLAN1_TIME 2019-12-03 14:05:45
   IODev      gl.gw.Wemos
   LASTInputDev HMLAN1
   MSGCNT     181
   NAME       wz.fk.FensterCouch
   NOTIFYDEV  global
   NR         4285
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   gl.gw.Wemos_MSGCNT 86
   gl.gw.Wemos_RAWMSG 05000041A586415E0CB8000000012E00
   gl.gw.Wemos_RSSI -65
   gl.gw.Wemos_TIME 2019-12-03 14:05:45
   lastMsg    No:A5 - t:41 s:5E0CB8 d:000000 012E00
   protCmdDel 91
   protCmdPend 3 CMDs pending
   protLastRcv 2019-12-03 14:05:45
   protNack   23 last_at:2019-12-03 14:04:50
   protRcv    97 last_at:2019-12-03 14:05:45
   protResnd  2 last_at:2019-12-03 14:05:47
   protSnd    17 last_at:2019-12-03 14:05:45
   protState  CMDs_pending
   rssi_at_HMLAN1 cnt:95 min:-69 max:-52 avg:-62.51 lst:-67 
   rssi_at_gl.gw.Wemos cnt:87 min:-93 max:-55 avg:-66.51 lst:-65 
   READINGS:
     2019-12-03 14:04:55   Activity        alive
     2019-12-03 14:04:50   CommandAccepted no
     2019-12-03 14:04:55   D-firmware      1.0
     2019-12-03 14:04:55   D-serialNr      OEQ1198546
     2019-12-02 21:03:21   R-ku.ht.Heizung_WindowRec-expectAES set_off
     2019-12-02 21:03:21   R-ku.ht.Heizung_WindowRec-peerNeedsBurst set_on
     2019-12-02 20:43:24   R-pairCentral   set_0x301235
     2019-12-02 21:09:03   R-wz.ht.Couch_WindowRec-expectAES set_off
     2019-12-02 21:09:03   R-wz.ht.Couch_WindowRec-peerNeedsBurst set_on
     2019-12-02 20:52:32   R-wz.ht.Essecke_WindowRec-expectAES set_off
     2019-12-02 20:52:32   R-wz.ht.Essecke_WindowRec-peerNeedsBurst set_on
     2019-12-02 20:55:16   R-wz.ht.Spielecke_WindowRec-expectAES set_off
     2019-12-02 20:55:16   R-wz.ht.Spielecke_WindowRec-peerNeedsBurst set_on
     2019-12-03 13:15:27   alive           yes
     2019-12-03 14:05:45   battery         ok
     2019-12-03 14:05:45   contact         closed (to broadcast)
     2019-12-02 20:44:42   powerOn         2019-12-02 20:44:41
     2019-12-03 13:15:27   recentStateType info
     2019-12-03 13:15:27   sabotageError   off
     2019-12-03 14:05:45   state           closed
     2019-12-03 14:05:45   trigDst_broadcast noConfig
     2019-12-03 14:05:45   trigger_cnt     46
   cmdStack:
     ++A0013012355E0CB800040000000000
     ++A0013012355E0CB801040000000001
     ++A0013012355E0CB80103
   helper:
     HM_CMDNR   166
     PONtest    0
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5E0CB8,02,00,00
       nextSend   1575378345.10017
       prefIO     
       rxt        2
       vccu       
       p:
         5E0CB8
         00
         00
         00
     mRssi:
       mNo        A5
       io:
         HMLAN1:
           -67
           -67
         gl.gw.Wemos:
           -61
           -61
     prt:
       bErr       0
       sProc      2
       wuReSent   2
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HMLAN1:
         avg        -62.5157894736842
         cnt        95
         lst        -67
         max        -52
         min        -69
       at_gl.gw.Wemos:
         avg        -66.5172413793103
         cnt        87
         lst        -65
         max        -55
         min        -93
     shadowReg:
       RegL_00.    02:01 0A:30 0B:12 0C:35
       RegL_04.ku.ht.Heizung_WindowRec  01:01
       RegL_04.wz.ht.Couch_WindowRec  01:01
       RegL_04.wz.ht.Essecke_WindowRec  01:01
       RegL_04.wz.ht.Spielecke_WindowRec  01:01
Attributes:
   IODev      gl.gw.Wemos
   IOgrp      VCCU:gl.gw.Wemos
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCO
   room       CUL_HM,Wohnzimmer
   serialNr   OEQ1198546
   subType    threeStateSensor

Habt ihr eine Idee was ich machen kann? Oder soll ich das Peering aufheben (mit unset), das Device zurücksetzen und dann wieder von vorne anfangen?

Beta-User · 03 Dezember 2019, 14:32:25

Es sollte (wenn keine cmd mehr pending sind) ggf. kein Problem sein, das peering einfach nochmal drüber zu wiederholen (sonst: Knopf drücken, bis die Befehle abgearbeitet sind oder clearMsg).

In so einer Konstellation bietet es sich mMn. aber an, indirekt zu peeren, also alle FK's in einen virtuellen zu packen und dann die RT's mit diesem zu peeren. Dann kann man besser verzögern (kurze Öffnungen ignorieren) und spart eine ganze Anzahl burst-Bessages...

(code kann ich ggf. liefern).

frank · 03 Dezember 2019, 15:24:35

ZitatHabt ihr eine Idee was ich machen kann? Oder soll ich das Peering aufheben (mit unset), das Device zurücksetzen und dann wieder von vorne anfangen?

ich würde die frage immer erst an hminfo stellen:

hey hminfo, siehst du eventuell irgendwo ein problem?

Code Auswählen

get hminfo configCheck

teichtaucher · 03 Dezember 2019, 21:16:46

Habe mir gerade ein HMinfo definiert. Mein System lief vorher auch ohne

HMinfo listet mir alle möglichen Fehler, aber bis auf den oben beschriebenen Fehler läuft alles:

Code Auswählen


configCheck done:

 missing register list
    ki.fk.FensterRechts:	RegL_00.,RegL_01.
    sz.fk.Fenster:	RegL_00.,RegL_01.
    wz.fk.FensterCouch:	RegL_00.,RegL_01.
    wz.fk.FensterSpiel:	RegL_00.,RegL_01.,RegL_04.wz.ht.Essecke_WindowRec,RegL_04.wz.ht.Spielecke_WindowRec

 Register changes pending
    wz.fk.FensterCouch
    wz.fk.FensterSpiel
    wz.ht.Essecke

 peer list incomplete. Use getConfig to read it.
    incomplete: ki.fk.FensterRechts:
    incomplete: ku.fk.Schiebetuer:
    incomplete: sz.fk.Fenster:
    incomplete: wz.fk.FensterCouch:

 peer not verified. Check that peer is set on both sides
    az.ht.Heizung_WindowRec p:ku.fk.Schiebetuer
    ki.ht.Heizung_WindowRec p:ki.fk.FensterRechts
    ku.ht.Heizung_WindowRec p:ku.fk.Schiebetuer
    ku.ht.Heizung_WindowRec p:wz.fk.FensterCouch
    wz.ht.Couch_WindowRec p:ku.fk.Schiebetuer
    wz.ht.Couch_WindowRec p:wz.fk.FensterCouch
    wz.ht.Couch_WindowRec p:wz.fk.FensterSpiel
    wz.ht.Couch_WindowRec p:wz.fk.Garten
    wz.ht.Essecke_WindowRec p:ku.fk.Schiebetuer
    wz.ht.Essecke_WindowRec p:wz.fk.FensterCouch
    wz.ht.Essecke_WindowRec p:wz.fk.Garten
    wz.ht.Spielecke_WindowRec p:ku.fk.Schiebetuer
    wz.ht.Spielecke_WindowRec p:wz.fk.FensterCouch
    wz.ht.Spielecke_WindowRec p:wz.fk.Garten
    wz.wt.Heizung_WindowRec p:ku.fk.Schiebetuer

 trigger sent to unpeered device
    triggerUnpeered: ki.fk.FensterLinks:000000
    triggerUnpeered: wz.fk.FensterSpiel:000000

 PairedTo mismatch to IODev
    ki.fk.FensterLinks paired:0x000000 IO attr: 301235.
    wz.fk.FensterSpiel paired:0x000000 IO attr: 301235.

 templist mismatch 
    az.ht.Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    ba.ht.Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    ki.ht.Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    ki.wt.Heizung_Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    ku.ht.Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    wz.ht.Couch_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    wz.ht.Essecke_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    wz.ht.Spielecke_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    wz.wt.Heizung_Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory

Zitat
Es sollte (wenn keine cmd mehr pending sind) ggf. kein Problem sein, das peering einfach nochmal drüber zu wiederholen (sonst: Knopf drücken, bis die Befehle abgearbeitet sind oder clearMsg).

Das habe ich schon versucht. Also nochmal den gleichen Peer-Befehl abgesetzt und die Anlerntaste vom FK gedrückt. Verhalten ist immer noch das gleiche.
Wenn keiner mehr eine Idee hat würde ich "unpeeren", Device in FHEM löschen und den FK zurücksetzen und dann noch mal von vorn Starten.

MadMax-FHEM · 03 Dezember 2019, 21:37:13

Warum machst du nicht was hminfo rät: getConfig

Einfach mal überall clear messages und dann dort wo noch Register fehlen ein getConfig...

Wenn Batteriegeräte: "Konfig-Taster" drücken (bei optischen FK eine Auslösung, also Fenster auf/zu vermeiden)...

EDIT: evtl. nach getConfig (wenn noch nicht passt) peering wiederholen. Zurücksetzen und Löschen macht es selten besser...

Gruß, Joachim

frank · 04 Dezember 2019, 01:04:19

versuch mal mit deinem hmlan als prefered io am fk. wlan kann problematisch beim timing sein.

auffällig sind 23 nack im list und komischerweise nur probleme mit fk.
eventuell gibt es auch ein problem mit der anzahl der gepeerten fk? du hast ja schon einige.

und nichts löschen, resetten, etc...

teichtaucher · 07 Dezember 2019, 11:13:05

Hi, danke für Eure Antworten. Ich habe jetzt komischerweise ein Problem mit einem anderen FK. Dieser hat immer einwandfrei funktioniert. Aber seit ein paar Tagen will er nicht mehr bei Events nicht mehr senden. Ich dachte erst die Batterien sind leer aber ne neue Batterie hilft nicht.
Beim Einlegen der Batterie blinkt er erst orange, dann kurz rot. Auch wenn ich die Taste drücke leuchtet die LED für eine Sekunde rot, dann aus und leuchtet dann noch kurz rot auf. Laut Anleitung deutet das auf DutyCycle hin, aber es kann ja nicht sein dass er jetzt gar nicht mehr sendet.
Das einzige was ich am FK gemacht habe war die eventDlyTime auf 1 gesetzt.
Hier mal ein List:

Code Auswählen


Internals:
   DEF        44257C
   FUUID      5cb63bfb-f33f-d318-6683-f8d5e56a3dd28e23
   HMLAN1_MSGCNT 963
   HMLAN1_RAWMSG E44257C,0000,60C8D18B,FF,FFC0,00A61044257C3012350601C80E
   HMLAN1_RSSI -64
   HMLAN1_TIME 2019-12-07 11:02:46
   IODev      gl.gw.Wemos
   LASTInputDev HMLAN1
   MSGCNT     1930
   NAME       ku.fk.Schiebetuer
   NOTIFYDEV  global
   NR         59
   NTFY_ORDER 50-ku.fk.Schiebetuer
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   gl.gw.Wemos_MSGCNT 967
   gl.gw.Wemos_RAWMSG 0511002400A61044257C3012350601C80E
   gl.gw.Wemos_RSSI -36
   gl.gw.Wemos_TIME 2019-12-07 11:02:45
   lastMsg    No:00 - t:10 s:44257C d:301235 0601C80E
   protCmdPend 4 CMDs_pending
   protLastRcv 2019-12-07 11:02:45
   protRcv    4 last_at:2019-12-07 11:02:45
   protResnd  2 last_at:2019-12-07 11:02:50
   protSnd    8 last_at:2019-12-07 11:02:45
   protState  CMDs_pending
   rssi_at_HMLAN1 cnt:963 min:-92 max:-54 avg:-68.49 lst:-64 
   rssi_at_gl.gw.Wemos cnt:967 min:-50 max:-36 avg:-40.14 lst:-36 
   READINGS:
     2019-12-07 10:52:45   PairedTo        0x301235
     2019-12-07 10:52:45   R-cyclicInfoMsg on
     2019-12-07 10:52:45   R-eventDlyTime  0 s
     2019-12-07 10:52:45   R-pairCentral   0x301235
     2019-12-07 10:52:45   R-sabotageMsg   on
     2019-12-07 10:52:45   R-sign          on
     2019-12-07 11:02:45   alive           yes
     2019-12-07 11:02:45   battery         ok
     2019-12-07 11:02:45   contact         open (to VCCU)
     2019-12-07 10:46:50   powerOn         2019-12-07 10:46:50
     2019-12-07 11:02:45   recentStateType info
     2019-12-07 11:02:45   sabotageError   on
     2019-12-07 11:02:45   state           open
   cmdStack:
     ++A00130123544257C0103
     ++A00130123544257C00040000000000
     ++A00130123544257C01040000000001
     ++A00130123544257C0103
   helper:
     HM_CMDNR   1
     PONtest    0
     cSnd       0130123544257C0103,0130123544257C0103
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +44257C,02,00,00
       nextSend   1575712965.58056
       prefIO     
       rxt        2
       vccu       VCCU
       p:
         44257C
         00
         00
         00
     mRssi:
       mNo        00
       io:
         HMLAN1:
           -64
           -64
         gl.gw.Wemos:
           -28
           -28
     prt:
       bErr       0
       sProc      2
       sleeping   0
       wuReSent   3
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rpt:
       IO         gl.gw.Wemos
       flg        A
       ts         1575712965.34994
       ack:
         HASH(0x24f3a90)
         00800230123544257C00
     rssi:
       at_HMLAN1:
         avg        -68.4922118380062
         cnt        963
         lst        -64
         max        -54
         min        -92
       at_gl.gw.Wemos:
         avg        -40.147880041365
         cnt        967
         lst        -36
         max        -36
         min        -50
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU
   actCycle   002:50
   actStatus  alive
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCO
   peerIDs    
   room       Kueche
   serialNr   MEQ1723075
   subType    threeStateSensor

Ich habe versucht, vorher ein getConfig zu machen und die Taste zu drücken aber die LED leuchtet trotzdem rot. Keine Ahnung ob also was übertragen wurde. Vorher habe ich auch schon ein clear msgEvents gemacht.
Wie kann ich den FK wieder in Gang setzen wenn er beim Drücken der LED immer mit rot quittiert?

teichtaucher · 07 Dezember 2019, 11:20:02

Noch eine Sache: Ich habe autoReadReg auf 5_readMissing gesetzt. Und jetzt sehe ich im Log dass bei dem FK öfters ein getConfig ausgelöst wurde:

Code Auswählen


2019.12.05 00:11:07 3: CUL_HM set ku.fk.Schiebetuer getConfig

...davon stehen einige im Log.

frank · 07 Dezember 2019, 11:36:55

ist hminfo jetzt sauber?
rotes aufleuchten gibt es auch, wenn ein peer nicht antwortet.

teichtaucher · 07 Dezember 2019, 11:46:50

Nein, hmInfo ist noch nicht sauber. Das bekomme ich aber zeitnah auch nicht weg weil meine Kinder die Fenster voll mit Weihnachtsdeko gehängt haben und ich die Fenster nicht aufmachen kann (habe die FKs im Fensterrahmen verbaut)

Das mit dem rot blinkenden FK macht mir zur Zeit mehr Sorgen. Der FK meldet seinen Status noch nicht mal an FHEM. Laut FHEM ist das Fenster noch offen. Soll ich jetzt erstmal abwarten? Laut Anleitung soll der DutyCycle Fehler nach maximal einer Stunde weggehen. Aber beim Drücken der Taste blinkt er immer noch rot.

teichtaucher · 11 Dezember 2019, 21:28:30

So, ich antworte mir mal selbst falls einer ein ähnliches Problem hat. Habe es schon in einen anderen Threat geschrieben.

Die Homematic FKs haben ein Problem wenn sie mit zu vielen RTs gepeered sind. Ich vermute die Funklast ist zu hoch weil zu viele RTs einzeln angesprochen werden müssen. Im schlimmsten Fall werden ein paar RTs gar nicht erreicht was der FK mit rot quittiert. Zum Teil gehen die FKs dann auf DutyCycle Error und senden gar nichts mehr.
Ich habe jetzt bei allen FKs das Peering mit den RTs aufgehoben. Und siehe da, auf einmal haben die FKs auch auf ein GetConfig (mit grün) geantwortet. Außerdem reagieren alle FKs total schnell und antworten auf jedes Kommando.
Ich habe mir statt direktem Peering einen virtuellen FK angelegt und den mit allen fünf RTs gepeered. Ein DoIf (mit 30s wait delay) löst jetzt den virtuellen FK aus sobald ein Fenster offen ist. Neben dem jetzt fehlerfreien Betrieb hat man noch andere Vorteile:
-Durch das wait löst nicht jede kurze Fensteröffnung ein Runterregeln aus.
-Ein nicht erkanntes geschlossenes Fenster führt trotzdem dazu dass die Heizung wieder hoch regelt.
-Es ist viel übersichtlicher da jedes offene Fenster in nur einem virtuellen FK gehändelt wird statt dass jeder FK mit jedem RT gepeered ist.
Und jetzt ist auch HmInfo sauber

FHEM-User22 · 12 Dezember 2019, 07:16:13

Guten Morgen,

Zitat von: Beta-User am 03 Dezember 2019, 14:32:25
Es sollte (wenn keine cmd mehr pending sind) ggf. kein Problem sein, das peering einfach nochmal drüber zu wiederholen (sonst: Knopf drücken, bis die Befehle abgearbeitet sind oder clearMsg).

In so einer Konstellation bietet es sich mMn. aber an, indirekt zu peeren, also alle FK's in einen virtuellen zu packen und dann die RT's mit diesem zu peeren. Dann kann man besser verzögern (kurze Öffnungen ignorieren) und spart eine ganze Anzahl burst-Bessages...

(code kann ich ggf. liefern).

Ich wäre an dem Code interessiert.

Dankeschön

Beta-User · 12 Dezember 2019, 07:44:28

Moin,

der Code ist hier zu finden. Wenn du eine Anleitung zum "Installieren" brauchst, bitte melden.

Du kannst die myUtils ganz verwenden, brauchst aber mindestens myWinContactNotify() und myTimeoutWinContact().

Benötigt wird weiterhin für jede Gruppe von Thermostaten ein virtueller Fensterkontakt (wie im Wiki beschrieben, also je ein Hauptgerät mit eigender HmID und ein Kanal für den virt. FK, der ist dann erfolgreich mit den Thermostaten zu peeren)
Diesem weist du via userAttr die echten Tür- und Fensterkontakte zu und legst du ein notify an, das auf alle zu überwachenden Kontakte reagiert (kann ein notify für das ganze Haus sein).

Code Auswählen

defmod n_FK_TK_event ((Dachf|F)enster|.*tuer)_.*:contact:.(open|tilted|closed)..to.VCCU. {myWinContactNotify($NAME,$EVENT,30)}

Das letzte Argument ist optional, man kann auch ein weiteres userAttr myTimeout am virtuellen FK setzen, sonst werden 90 Sekunden verwendet. Für 1,5 Min. reicht daher:

Code Auswählen

defmod n_FK_TK_event ((Dachf|F)enster|.*tuer)_.*:contact:.(open|tilted|closed)..to.VCCU. {myWinContactNotify($NAME,$EVENT)}

Beispiel für einen passenden virtuellen FK (Auszug):

Code Auswählen


defmod Virtueller_FK_SZ CUL_HM 33221101
attr Virtueller_FK_SZ userattr myRealFK myTimeout
attr Virtueller_FK_SZ myRealFK FensterSchlafzimmer1,FensterSchlafzimmer2

Bei Fragen einfach melden.

Gruß, Beta-User

FHEM-User22 · 12 Dezember 2019, 10:55:40

Zitat von: Beta-User am 12 Dezember 2019, 07:44:28
Du kannst die myUtils ganz verwenden, brauchst aber mindestens myWinContactNotify() und myTimeoutWinContact().

??

Zitat von: Beta-User am 12 Dezember 2019, 07:44:28
Wenn du eine Anleitung zum "Installieren" brauchst, bitte melden.
Bei Fragen einfach melden.

Hiermit meld...

Für den Rest versuche ich mich die nächsten Tage durchzuwursteln....

Dankeschön

Beta-User · 12 Dezember 2019, 11:18:56

Na ja, der Link enthält eine myUtils-file mit noch anderen Progrämmchen, benötigt werden aber diese zwei...
Du kannst die file direkt auch nach /opt/fhem/FHEM packen (Rechte beachten), und dann einen FHEM-Neustart oder einen reload dieser Datei machen, damit die Programme auch aufgerufen werden können.

Alternativ kannst du die auch mit dem FHEM-internen Editor "erstellen", indem du z.B. das "Musterfile" zu myUtils wie im Wiki angegeben öffnest und dann unter dem passenden Namen (=so wie sie jetzt heißt) abspeicherst.

Die file enthält auch eine commandref, auch zu dem anderen Zeug...