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:
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.
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?
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).
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?
get hminfo configCheck
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:
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.
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
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...
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:
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?
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:
2019.12.05 00:11:07 3: CUL_HM set ku.fk.Schiebetuer getConfig
...davon stehen einige im Log.
ist hminfo jetzt sauber?
rotes aufleuchten gibt es auch, wenn ein peer nicht antwortet.
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.
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 :-)
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
Moin,
der Code ist hier (https://github.com/rejoe2/FHEM/blob/master/99_myUtils_Homematic.pm) 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).
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:
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):
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
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... :D
Für den Rest versuche ich mich die nächsten Tage durchzuwursteln....
Dankeschön
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...
Zitat von: FHEM-User22 am 12 Dezember 2019, 07:16:13
Ich wäre an dem Code interessiert.
Ich bin mit der Anleitung aus dem Wiki nicht klar gekommen. Besonders der rote Kasten an der Seite hat mich irritiert (muss ich für jeden RT einen separaten virtuellen FK-Kanal verwenden?).
Ich bin nach dieser Anleitung vorgegangen: https://haus-automatisierung.com/projekt/2018/12/29/projekt-homematic-xiaomi-fensterkontakt.html
Und habe den virtuellen FK erstmal testweise mit zwei RTs gepeered. Dann habe ich den FK künstlich ausgelöst und gesehen dass beide RTs auf den virtuellen FK reagiert haben. Also muss ich nur einen Kanal für alle RTs erstellen.
Danach habe ich das direkte Peering aller FKs mit den RTs aufgehoben und den virtuellen FK über eine DOIF ausgelöst (dabei muss ich sagen dass ich lieber gern auf gängige FHEM Devices wie DOIF usw. zugreife als selber Funktionen zu basteln):
define doif_BUFensterVirtual DOIF (([FK1] eq "open") || ([FK2] eq "open") || ([FK3] eq "open"))
(set BU_FensterVirtual_WindowRec postEvent open)
DOELSE
(set BU_FensterVirtual_WindowRec postEvent closed)
Wenn also ein FK "nack" meldet wird das geschlossenes Fenster erkannt. Hatte das vorher als Fehlerfall und die Heizung lief nicht mehr an.
Es reicht, wenn es pro Gruppe einen virtuellen FK gibt, nicht für jeden RT einen. Die Frage ist aber, wie viele RT's dann sicher geschaltet werden können; ich habe max. zwei pro FK, und das geht problemlos...
Aber für jede Gruppe _muß_ man auch ein anderes Basisdevice nehmen, die HmID muß also abweichen. Sonst ist Chaos angesagt... (man kann aber jeweils einen anderen Kanal für Temp. nehmen, und wenn man das ganze nur über WT macht, _scheint_ es auch mit nur einem virtuellen Haupt-Device für mehrere FK-Gruppen zu gehen; jedenfalls mit firmware 1.4 unterscheidet mein einer WT zwischen den Kanälen).
Die Syntax von DOIF verstehe ich wieder nicht, daher mache ich das direkt mit Perl. Ist für mich einfacher und flexibler... Vermutlich ist es darüber auch einfacher, z.B. andere Thermostattypen mit einzubinden (FHEM-User22 hat auch ZWave-Thermostate, die da ggf. ganz andere Logik brauchen...).
Zitat
...ich habe max. zwei pro FK, und das geht problemlos...
Bei mir sind es vier FKs und fünf RTs. Das läuft auch problemlos über eine Gruppe.