mal wieder: WindowRec mit HM-RT und HM-Fensterkontakt

[Pfriemler]

Ich bin hier drauf gestoßen, weil auch ich mich gerade frage, ob ich den Fensterkontakt mit dem HK, dem WT oder mit beiden peeren soll... laut MadMax-FHEM reicht WT, mit dem Nachteil der Zeitverzögerung, aber...

Wie soll denn die Fensterauferkennung ohne Burst funktionieren. Wäre ja total unbrauchbar, wenn ich 5 Minuten Stoßlüfte und das Ding erst nach 3 Minuten die Temperatur runterregelt.

Bei nur Peering mit dem Wandthermostaten ist das definitiv so.
Fenster-auf geht an den Wandthermostaten (burst device), dieser erkennt das sofort und gibt dann bei der nächsten Kommunikation zum Heizkörperthermostaten die Fenster-auf-Temp als desired-temp vor...

Fragt mich nicht, wie ich das hinbekommen habe, aber bei mir sind auch Wand- und Heizkörperthermostat in _Weather und _Climate gepeert. Stelle ich am Wandthermostaten die Temperatur anders, weiß das der Heizkörper nach <10 Sekunden.

@theophiloui85: Wundert mich sehr, deine Leuchtorgien. Hängt sicher mit dem AES zusammen. FHEM kennt zudem die Register nicht, Dir fehlen noch getConfigs auf die FKs.

Code Auswählen Erweitern

Internals:
   DEF        359B02
...
   NAME       wz0_kon00
...
   protCmdPend 4 CMDs pending
...
   Readings:
...
     2017-01-05 01:06:51   R-pairCentral   set_0x000001


Und, ja, sehe ich auch so:

Code Auswählen Erweitern

Internals:
   NAME       wz0_kon00
...
     2016-12-30 03:07:35   R-wz0_kon01-expectAES on
     2016-12-30 03:07:35   R-wz0_kon01-peerNeedsBurst off
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-expectAES on
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-peerNeedsBurst off

Willst Du den Fensterkontakt mit dem anderen peeren? Dat wird nix... weil jeht nich ...

Mach mal n set wz0_kon00 clear readings, und dann erst getConfig.

[MadMax-FHEM]

Ich bin hier drauf gestoßen, weil auch ich mich gerade frage, ob ich den Fensterkontakt mit dem HK, dem WT oder mit beiden peeren soll... laut MadMax-FHEM reicht WT, mit dem Nachteil der Zeitverzögerung, aber...
Bei nur Peering mit dem Wandthermostaten ist das definitiv so.
Fenster-auf geht an den Wandthermostaten (burst device), dieser erkennt das sofort und gibt dann bei der nächsten Kommunikation zum Heizkörperthermostaten die Fenster-auf-Temp als desired-temp vor...

Fragt mich nicht, wie ich das hinbekommen habe, aber bei mir sind auch Wand- und Heizkörperthermostat in _Weather und _Climate gepeert. Stelle ich am Wandthermostaten die Temperatur anders, weiß das der Heizkörper nach <10 Sekunden.

Also ich muss gestehen, dass ich noch nicht (selten / vielleicht anfangs mal) direkt auf die Heizkörperthermostate schaue, wenn ich an den Wandthermostaten rumstelle...
Ab und an, wenn ich das Fenster öffne sehe ich, dass der Wandthermostat bereits erkannt und umgestellt hat (ich habe eine ReadingsGroup-Übersicht dafür) und auf dem Heizkörperthermostaten dauert es ein Weilchen.
Ich habe mir das hal einfach mit dem Schlafen/Aufwachen erklärt und nach spät. dieser Zeit (3min) war er auch umgestellt und das hat mir so gereicht.

Tiefere Analysen habe ich nicht durchgeführt.

Ich habe aber Heizkörperthermostate die ich nicht direkt über den Fensterkontakt schalte (peering) sondern den Heizkörperthermostat per Notify schalte weil ich ihn bewusst später wieder hochdrehen will (also erst wenn das Fenster bereits 5-10 min wieder zu ist, da hat sich der Raum "erholt" und das Thermostat muss dann nicht gleich voll hochschalten).

Da habe ich beim Heizkörperthermostaten dann aber Burst aktiviert damit das sofort geht.

Wie gesagt: keine größeren Analysen vorgenommen

@theophiloui85: Wundert mich sehr, deine Leuchtorgien. Hängt sicher mit dem AES zusammen. FHEM kennt zudem die Register nicht, Dir fehlen noch getConfigs auf die FKs.

Code Auswählen Erweitern

Internals:
   DEF        359B02
...
   NAME       wz0_kon00
...
   protCmdPend 4 CMDs pending
...
   Readings:
...
     2017-01-05 01:06:51   R-pairCentral   set_0x000001


Und, ja, sehe ich auch so:

Code Auswählen Erweitern

Internals:
   NAME       wz0_kon00
...
     2016-12-30 03:07:35   R-wz0_kon01-expectAES on
     2016-12-30 03:07:35   R-wz0_kon01-peerNeedsBurst off
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-expectAES on
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-peerNeedsBurst off

Willst Du den Fensterkontakt mit dem anderen peeren? Dat wird nix... weil jeht nich ...

Mach mal n set wz0_kon00 clear readings, und dann erst getConfig.

Ähnliches wollte ich heute Nacht schon schreiben aber da es schon sehr spät war wollte ich vermeiden irgendwas zusammenzuschreiben was dann nicht weiter führt...

Gruß, Joachim

[Pfriemler]

Joachim, es ist nicht so einfach ... Ich habe gerade experimentiert:
Zuerst den FK mit dem WT gepeert. Dabei ist mir aufgefallen, dass das sofort zu einem Problem führt, weil bei diesem Peervorgang beim Fensterkontakt nicht automatisch "peerNeedsBurst" gesetzt wird. Ich werde mal Martin nochmal darauf anschreiben, ich glaube nicht dass er alles hier mitliest. Das Ergebnis ist jedenfalls eine rote LED nach der Fensterbetätigung. Aber ich wusste um die Problematik und habe peerNeedsBurst von Hand auf on gesetzt. Und schon klappt die Verbindung einwandfrei: praktisch in der nächsten Sekunde ist das Fenstersymbol auf dem Display des WT da oder weg. Ein Druck auf die Tag/Nacht-Taste liefert als Solltempertatur auch sofort die zuletzt gewählte oder die winOpenTemp (12° default). Aber der Heizkörperthermostat bekommt dies erst sehr verzögert mitgeteilt! Ändre ich hingegen die Solltemperatur am WT, weiß der Heizkörper das zuverlässig in wenigen Sekunden. Das klappt übrigens auch umgekehrt - eine Änderung der Solltemp am Heizkörper weiß der WT ebenfalls in Sekunden.
Ich nehme an, dass die Solltemp hier jeweils verzögert übertragen wird, es wird sicher gewartet, bis man nicht mehr am Rad dreht.
Was nicht klappt, ist dass der WT die wegen des betätigten Fensters geänderte Temperatur sofort an den Heizkörper übermittelt. Das funktioniert wohl erst im Rahmen der normalen zyklischen Meldung, also sogar mit ungewisser Verzögerung.

Also habe ich den Fensterkontakt zusätzlich mit dem Heizkörper gepeert. Hier wird übrigens peerNeedsBurst sofort richtig gesetzt. Und seither ist auch die Fenstererkennung (logischerweise) am Heizkörper praktisch sofort.

Noch ein Ding am Rande: Im betreffenden Raum konkurrieren mein HMLAN und mein HMUART im -75..-85 dB-Bereich (rssi). peerChans und getConfigs waren anfangs Glückssache, bis ich mit "set HMUART close" den (schwächeren) in die Mittagspause geschickt habe. Ab da liefen alle Configs im ersten Rutsch. Das regelt die vccu offenbar nicht sauber.

[MadMax-FHEM]

Hi Pfriemler,

vielleicht nicht klar ausgedrückt bzw. ist es ja so wie du schreibst!?

Also der Wandthermostat erkennt bei mir (ohne komische Lichtorgel und ohne zusätzliches Setzen von needs burst) sofort das offene Fenster nach erfolgtem Peering...

Da hatte ich noch nie Probleme, außer evtl. das öftere Absetzen des Befehls bevor es alle beteiligten Parteien "gefressen" hatten bzw. seit ich halt immer langsam mit Config-Knopf drücken beim Fensterkontakt mache auch nicht mehr...

Das mit der Temperaturübertragung zwischen Wand- und Heizkörperthermostat bei "am Rad drehen" habe ich noch nicht so verfolgt, drehe immer nur über die ReadingsGroupÜbersicht "am Rad"

Und schaue selten am Heizkörperthermostat, ob er das dann auch so sieht

Allerdings das mit der Übertragung bei Fenster auf ist mir halt zu Beginn aufgefallen, weil der Heizköperthermostat ja direkt beim Fensteröffnen in Sicht ist...
...und da ist mir halt aufgefallen, dass er nicht "sofort" umschaltet, wenn ich das Fenster öffne.
Hab dann mal gekuckt, ob er das dann noch macht, um einen Fehler auszuschließen: ja. Damit war das für mich ok (also mit der Verzögerung kann ich gut leben).

Was ich immer sofort beim Fensterkontakt deaktiviert habe ist AES und die zyklischen Meldungen aktiviert.

Gibt es nicht auch ein attr preferedIODev?? Da kannst du selbst entscheiden welches besser geeignet ist (soweit ich das verstanden habe)...

Gruß, Joachim

P.S.: ich werde es weiterhin so machen: Wandthermostat_Weather mit Heizkörperthermostat_Weather, Wandthermostat_Climate mit Wandthermostat_Climate und Wandthermostat_WindowRec mit Fensterkontakt...

[Pfriemler]

Ja. Aneinander vorbei. Also Du hattest gleich recht mit der verzögerten Reaktion:  FK ->sofort > WT > verzögert > RT-DN. Und ich hatte recht mit HK <- sofort -> RT-DN bei manuellen Temperaturänderungen.
Ich wollte Dir das eigentlich nur bestätigen... außerdem findet's vielleicht mal ein anderer und freut sich.
AES ... ja witzig: Der FK hat R-sign on, beide peers (WT und RT-DN) hingegen off. Trotzdem hat FHEM beim FK expectAES zum WT gesetzt, statt des peerNeedsBurst. ...  Komisch, dass das bei Dir sofort geklappt hat.
preferedIO stellt man über IOGrp ein: "vccu:HMLAN1" legt's dann fest, hatte ich bei dem Ding tatsächlich offen gelassen, kann daran gelegen haben. Trotzdem sollte die vccu zwar Wahlfreiheit im Sendedevice haben, das aber nicht ständig umswitchen - oder die doppelt eintreffenden Meldungen überfordern, das kann Martin besser einschätzen. Damit kann ich leben, ein IO bei kritischen Aktionen zu pausieren. Beim Firmwareupdate etwa muss das HMLAN in Pause, bricht sonst immer ab.
Ich wiederum bevorzuge übrigens eine sofortige Reaktion auf offenes Fenster und ein möglichst zügiges Wiederaufheizen... kann ja jeder für sich entscheiden.

[theophilou85]

Ich glaube mit meinem Halbwissen verwirre ich nur mich und euch, deshalb einfach mal all meine Lists:

Stellantrieb

Code Auswählen Erweitern

Internals:
   DEF        269BFF
   IODev      wz0_cul00
   LASTInputDev wz0_cul00
   MSGCNT     268
   NAME       wz0_sta00
   NOTIFYDEV  global
   NR         120
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 wz0_sta00_Weather
   channel_02 wz0_sta00_Climate
   channel_03 wz0_sta00_WindowRec
   channel_04 wz0_sta00_Clima
   lastMsg    No:A1 - t:10 s:269BFF d:000000 0AA0EB8B0000
   protLastRcv 2017-01-06 23:14:18
   protResnd  1 last_at:2017-01-06 16:15:56
   protSnd    11 last_at:2017-01-06 22:45:08
   protState  CMDs_done
   rssi_ActionDetector min:-56 cnt:6 lst:-56 avg:-54.66 max:-54
   rssi_at_wz0_cul00 lst:-58.5 cnt:268 min:-68.5 avg:-54.71 max:-51.5
   wz0_cul00_MSGCNT 268
   wz0_cul00_RAWMSG A0FA18610269BFF0000000AA0EB8B0000::-58.5:wz0_cul00
   wz0_cul00_RSSI -58.5
   wz0_cul00_TIME 2017-01-06 23:14:18
   Readings:
     2017-01-06 23:09:45   CommandAccepted yes
     2017-01-05 01:10:11   D-firmware      1.4
     2017-01-05 01:10:11   D-serialNr      LEQ0105862
     2017-01-05 02:01:51   PairedTo        0x000001
     2016-12-26 01:50:04   R-backOnTime    10 s
     2016-12-26 01:50:04   R-burstRx       on
     2016-12-26 01:50:04   R-cyclicInfoMsg on
     2016-12-26 01:50:04   R-cyclicInfoMsgDis 0
     2017-01-05 00:08:01   R-pairCentral   0x000001
     2017-01-05 02:01:51   RegL_00.        01:01 02:01 09:01 0A:00 0B:00 0C:01 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2017-01-05 18:02:26   RegL_07.
     2017-01-06 23:14:18   actuator        0
     2017-01-06 22:45:08   battery         ok
     2017-01-06 23:14:18   batteryLevel    2.6
     2017-01-01 17:15:43   controlMode     auto
     2017-01-06 23:14:18   desired-temp    20.0
     2017-01-06 23:14:18   measured-temp   23.5
     2017-01-06 23:14:18   motorErr        communicationERR
     2017-01-01 12:46:31   powerOn         2017-01-01 12:46:31
     2017-01-01 12:46:31   recentStateType info
     2017-01-04 23:55:30   sabotageAttackId_ErrIoId_26043E cnt:17
     2017-01-04 23:55:30   sabotageAttack_ErrIoAttack cnt 17
     2017-01-06 22:45:08   state           CMDs_done
     2017-01-06 20:28:10   time-request    -
   Helper:
     HM_CMDNR   161
     cSnd       11000001269BFF860428,11000001269BFF860428
     mId        0095
     rxType     140
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      173972188
       lstRecType 10
       lstSndTgd  120
       newChn     +269BFF,00,00,00
       nextSend   1483740858.49501
       nxtSndMcnt A1
       prefIO
       rxt        2
       tgtDly     120
       vccu
       p:
         269BFF
         00
         00
         00
     Mrssi:
       mNo        A1
       Io:
         wz0_cul00  -56.5
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       prs        1
     Rssi:
       Actiondetector:
         avg        -54.6666666666667
         cnt        6
         lst        -56
         max        -54
         min        -56
       At_wz0_cul00:
         avg        -54.7126865671642
         cnt        268
         lst        -58.5
         max        -51.5
         min        -68.5
     Shregw:
       07         04
     Tmpl:
Attributes:
   IODev      wz0_cul00
   actCycle   000:10
   actStatus
   alias      Stellantrieb Wohnzimmer
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   group      [Homematic] Stellantriebe
   model      HM-CC-RT-DN
   room       X_Geräte
   serialNr   LEQ0105862
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit

Wandthermostat:

Code Auswählen Erweitern

Internals:
   DEF        26043E
   IODev      wz0_cul00
   LASTInputDev wz0_cul00
   MSGCNT     395
   NAME       wz0_the00
   NOTIFYDEV  global
   NR         81
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 wz0_the00_Weather
   channel_02 wz0_the00_Climate
   channel_03 wz0_the00_WindowRec
   lastMsg    No:49 - t:70 s:26043E d:000000 00EB24
   protLastRcv 2017-01-06 23:14:37
   protSnd    7 last_at:2017-01-06 22:45:01
   protState  CMDs_done
   rssi_ActionDetector max:-57 avg:-57.33 min:-58 cnt:3 lst:-57
   rssi_at_wz0_cul00 max:-62 avg:-67.11 lst:-67 cnt:395 min:-85
   wz0_cul00_MSGCNT 395
   wz0_cul00_RAWMSG A0C49847026043E00000000EB24::-67:wz0_cul00
   wz0_cul00_RSSI -67
   wz0_cul00_TIME 2017-01-06 23:14:37
   Readings:
     2017-01-06 23:09:44   CommandAccepted yes
     2017-01-05 19:06:41   D-firmware      1.3
     2017-01-05 19:06:41   D-serialNr      LEQ0000562
     2017-01-05 02:00:19   PairedTo        0x000001
     2016-12-26 00:57:22   R-burstRx       on
     2016-12-26 00:57:22   R-cyclicInfoMsg on
     2016-12-26 00:57:22   R-cyclicInfoMsgDis 0
     2017-01-05 01:06:36   R-pairCentral   0x000001
     2017-01-05 02:00:19   RegL_00.        01:01 02:01 09:01 0A:00 0B:00 0C:01 0F:00 11:00  12:16 16:00 18:00 19:00 1A:00 00:00
     2017-01-05 18:09:10   RegL_07.
     2017-01-06 23:08:58   battery         ok
     2017-01-06 23:08:58   batteryLevel    2.6
     2017-01-06 23:08:58   desired-temp    20.0
     2017-01-06 23:08:58   measured-temp   23.5
     2017-01-05 01:02:41   powerOn         2017-01-05 01:02:41
     2017-01-05 01:02:41   recentStateType info
     2017-01-06 22:45:01   state           CMDs_done
     2017-01-06 22:37:45   time-request    -
   Helper:
     HM_CMDNR   73
     PONtest    1
     cSnd       1100000126043E860430,1100000126043E860428
     mId        00AD
     rxType     6
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      173991160
       lstRecType 70
       lstSndTgd  120
       newChn     +26043E,00,00,00
       nextSend   1483740877.46662
       nxtSndMcnt 49
       prefIO
       rxt        0
       tgtDly     120
       vccu
       p:
         26043E
         00
         00
         00
     Mrssi:
       mNo        49
       Io:
         wz0_cul00  -65
     Prt:
       awake      0
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       Actiondetector:
         avg        -57.3333333333333
         cnt        3
         lst        -57
         max        -57
         min        -58
       At_wz0_cul00:
         avg        -67.1101265822785
         cnt        395
         lst        -67
         max        -62
         min        -85
     Shregw:
       07         02
     Tmpl:
Attributes:
   IODev      wz0_cul00
   actCycle   000:10
   actStatus
   alias      Thermostat Wohnzimmer
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.3
   group      [Homematic] Thermostate
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       X_Geräte
   serialNr   LEQ0000562
   subType    thermostat
   webCmd     getConfig:clear msgEvents

Kontakt 0:

Code Auswählen Erweitern

Internals:
   DEF        359B02
   IODev      wz0_cul00
   LASTInputDev wz0_cul00
   MSGCNT     63
   NAME       wz0_kon00
   NOTIFYDEV  global
   NR         160
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:12 - t:10 s:359B02 d:000001 06010000
   protLastRcv 2017-01-06 23:10:02
   protSnd    13 last_at:2017-01-06 23:10:02
   protState  CMDs_done
   rssi_at_wz0_cul00 max:-54.5 avg:-59.44 cnt:63 lst:-59 min:-66
   wz0_cul00_MSGCNT 63
   wz0_cul00_RAWMSG A0D12A610359B0200000106010000::-59:wz0_cul00
   wz0_cul00_RSSI -59
   wz0_cul00_TIME 2017-01-06 23:10:02
   Readings:
     2017-01-05 01:06:53   CommandAccepted yes
     2017-01-05 01:06:51   D-firmware      1.0
     2017-01-05 01:06:51   D-serialNr      LEQ1510020
     2017-01-05 00:51:02   PairedTo        0x000001
     2016-12-30 02:32:04   R-cyclicInfoMsg on
     2016-12-30 02:32:05   R-eventDlyTime  0 s
     2017-01-05 01:06:51   R-pairCentral   set_0x000001
     2016-12-30 02:32:04   R-sabotageMsg   on
     2016-12-30 02:32:05   R-sign          on
     2016-12-30 03:07:35   R-wz0_kon01-expectAES on
     2016-12-30 03:07:35   R-wz0_kon01-peerNeedsBurst off
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-expectAES on
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-peerNeedsBurst off
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-expectAES set_off
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-peerNeedsBurst set_on
     2017-01-05 01:06:53   aesKeyNbr       00
     2017-01-06 23:10:02   alive           yes
     2017-01-06 23:10:02   battery         ok
     2017-01-06 23:10:02   contact         closed (to ActionDetector)
     2017-01-06 23:09:43   powerOn         2017-01-06 23:09:43
     2017-01-06 23:10:02   recentStateType info
     2017-01-06 23:10:02   sabotageError   off
     2017-01-06 23:10:02   state           closed
     2017-01-06 23:09:45   trigDst_ActionDetector noConfig
     2017-01-06 23:09:58   trigDst_wz0_kon01 noConfig
     2017-01-06 23:09:45   trigDst_wz0_sta00 noConfig
     2017-01-06 23:09:44   trigDst_wz0_the00 noConfig
     2017-01-06 23:09:58   trigger_cnt     1
   Helper:
     HM_CMDNR   18
     PONtest    0
     mId        00C7
     rxType     28
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      173716180
       lstRecType 10
       lstSnd     1483740602.4918
       lstSndTgd  120
       newChn     +359B02,00,00,00
       nextSend   1483740602.4918
       nxtSndMcnt 12
       prefIO
       rxt        2
       tgtDly     120
       vccu
       p:
         359B02
         00
         00
         00
     Mrssi:
       mNo        12
       Io:
         wz0_cul00  -57
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         wz0_cul00
       flg        A
       ts         1483740602.44609
       ack:
         HASH(0x29058f4)
         128002000001359B0200
     Rssi:
       At_wz0_cul00:
         avg        -59.4444444444444
         cnt        63
         lst        -59
         max        -54.5
         min        -66
     Tmpl:
Attributes:
   IODev      wz0_cul00
   actCycle   002:50
   actStatus
   alias      Fensterkontakt Wohnzimmer links
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      [Homematic] Kontakte
   model      HM-SEC-SCo
   peerIDs
   room       X_Geräte,Kontakte
   serialNr   LEQ1510020
   subType    threeStateSensor

Kontakt 1:

Code Auswählen Erweitern

Internals:
   DEF        359B3E
   IODev      wz0_cul00
   LASTInputDev wz0_cul00
   MSGCNT     42
   NAME       wz0_kon01
   NOTIFYDEV  global
   NR         164
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:E0 - t:41 s:359B3E d:359B02 010B00
   protLastRcv 2017-01-06 23:09:04
   protSnd    10 last_at:2017-01-06 23:08:50
   protState  CMDs_done
   rssi_at_wz0_cul00 lst:-80.5 cnt:42 min:-82 max:-66 avg:-74.2
   wz0_cul00_MSGCNT 42
   wz0_cul00_RAWMSG A0CE0A241359B3E359B02010B00::-80.5:wz0_cul00
   wz0_cul00_RSSI -80.5
   wz0_cul00_TIME 2017-01-06 23:09:04
   Readings:
     2017-01-05 01:07:42   CommandAccepted yes
     2017-01-05 01:07:41   D-firmware      1.0
     2017-01-05 01:07:41   D-serialNr      LEQ1510062
     2017-01-05 00:52:04   PairedTo        0x000001
     2016-12-30 02:40:39   R-cyclicInfoMsg on
     2017-01-01 12:47:48   R-eventDlyTime  0 s
     2017-01-05 01:07:41   R-pairCentral   set_0x000001
     2016-12-30 02:40:39   R-sabotageMsg   on
     2017-01-01 12:47:48   R-sign          on
     2017-01-01 12:47:49   R-wz0_kon00-expectAES on
     2017-01-01 12:47:49   R-wz0_kon00-peerNeedsBurst off
     2017-01-01 12:47:49   R-wz0_kon00_chn-01-expectAES on
     2017-01-01 12:47:49   R-wz0_kon00_chn-01-peerNeedsBurst off
     2017-01-05 00:51:50   R-wz0_sta00_WindowRec-expectAES set_off
     2017-01-05 00:51:50   R-wz0_sta00_WindowRec-peerNeedsBurst set_on
     2017-01-01 13:16:45   R-wz0_the00_WindowRec-expectAES set_off
     2017-01-01 13:16:45   R-wz0_the00_WindowRec-peerNeedsBurst set_on
     2017-01-05 01:07:42   aesKeyNbr       00
     2017-01-06 22:54:20   alive           yes
     2017-01-06 23:09:04   battery         ok
     2017-01-06 23:09:04   contact         closed (to wz0_kon00)
     2017-01-05 18:56:23   powerOn         2017-01-05 18:56:23
     2017-01-06 22:54:20   recentStateType info
     2017-01-06 22:54:20   sabotageError   off
     2017-01-06 23:09:04   state           closed
     2017-01-06 23:08:50   trigDst_ActionDetector noConfig
     2017-01-06 23:09:04   trigDst_wz0_kon00 noConfig
     2017-01-06 23:08:50   trigDst_wz0_sta00 noConfig
     2017-01-06 23:08:50   trigDst_wz0_the00 noConfig
     2017-01-01 14:39:06   trigLast        wz0_kon00:open
     2017-01-01 14:39:06   trig_wz0_kon00  Open_168
     2017-01-06 23:09:04   trigger_cnt     11
   Helper:
     HM_CMDNR   224
     mId        00C7
     rxType     28
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      173657996
       lstRecType 41
       lstSndTgd  120
       newChn     +359B3E,00,00,00
       nextSend   1483740544.30893
       nxtSndMcnt E0
       prefIO
       rxt        2
       tgtDly     120
       vccu
       p:
         359B3E
         00
         00
         00
     Mrssi:
       mNo        E0
       Io:
         wz0_cul00  -78.5
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_wz0_cul00:
         avg        -74.2023809523809
         cnt        42
         lst        -80.5
         max        -66
         min        -82
     Tmpl:
Attributes:
   IODev      wz0_cul00
   actCycle   002:50
   actStatus
   alias      Fensterkontakt Wohnzimmer rechts
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      [Homematic] Kontakte
   model      HM-SEC-SCo
   room       X_Geräte,Kontakte
   serialNr   LEQ1510062
   subType    threeStateSensor

Wie ihr seht sind jetzt alle CMD's done und die meisten peerIDs leer.
Öffne und schließe ich eines der beiden Fenster reagiert der Stellantrieb unmittelbar in weniger als 10s, auf und ab, IMMER.
Öffne ich ein Fenster leuchtet der Kontakt ewig (ca 30s) orange und dann kurz rot. Fenstersymbole erscheinen korrekt an Wandthermostat und Stellantrieb.

Wenn ich die Wiki und was ich sonst noch so zusammengelesen habe richtig interpretiert habe, dürfte das nicht so sein. Anfangs als die Fensterkontakte nur gepaired und nicht gepeert waren, leuchteten sie orange wenn ich das Fenster öffnete und kurz grün und beim Schließen wieder die gleiche Sequenz.
Es funktioniert bei mir ja alles, ich würde es nur so gerne verstehen, nachdem ich schon soviel Zeit in die Dinger investiert habe. Alle anderen Device (sogar der doofe 55er Bewegungsmelder) arbeiten so, wie man es sich von ihnen erwartet.

[MadMax-FHEM]

Ja. Aneinander vorbei. Also Du hattest gleich recht mit der verzögerten Reaktion:  FK ->sofort > WT > verzögert > RT-DN. Und ich hatte recht mit HK <- sofort -> RT-DN bei manuellen Temperaturänderungen.
Ich wollte Dir das eigentlich nur bestätigen... außerdem findet's vielleicht mal ein anderer und freut sich.
AES ... ja witzig: Der FK hat R-sign on, beide peers (WT und RT-DN) hingegen off. Trotzdem hat FHEM beim FK expectAES zum WT gesetzt, statt des peerNeedsBurst. ...  Komisch, dass das bei Dir sofort geklappt hat.

Ah, dann is ja gut...

Jep, bislang hat es bei den Wandthermostaten immer sofort geklappt das Peering.

Zuvor halt alles schön sauber Gepaired und AES aus und cyclig Messages an...

Gruß, Joachim

[MadMax-FHEM]

Wie ihr seht sind jetzt alle CMD's done und die meisten peerIDs leer.
Öffne und schließe ich eines der beiden Fenster reagiert der Stellantrieb unmittelbar in weniger als 10s, auf und ab, IMMER.
Öffne ich ein Fenster leuchtet der Kontakt ewig (ca 30s) orange und dann kurz rot. Fenstersymbole erscheinen korrekt an Wandthermostat und Stellantrieb.

Wenn ich die Wiki und was ich sonst noch so zusammengelesen habe richtig interpretiert habe, dürfte das nicht so sein. Anfangs als die Fensterkontakte nur gepaired und nicht gepeert waren, leuchteten sie orange wenn ich das Fenster öffnete und kurz grün und beim Schließen wieder die gleiche Sequenz.
Es funktioniert bei mir ja alles, ich würde es nur so gerne verstehen, nachdem ich schon soviel Zeit in die Dinger investiert habe. Alle anderen Device (sogar der doofe 55er Bewegungsmelder) arbeiten so, wie man es sich von ihnen erwartet.

Also solange AES NUR bei den Fensterkontakten aktiviert ist also erwartet wird, wird es immer Rot enden, da der Fensterkontakt ein ACK mit AES erwartet aber nur ein "normales" bekommt -> Fehler -> Rot.

Dass es trotzdem funktioniert (oder für dich so aussieht) liegt daran, dass "auf/zu" als normales Telegramm verschickt und empfangen wird und entsprechend angezeigt und reagiert wird.

Peer-IDs konnte ich keine sehen.
Ist noch nichts gepeered??
Einige Register sehen "eigenartig" aus.

Z.B. beim Kontakt00:

Code Auswählen Erweitern


     2016-12-30 03:07:35   R-wz0_kon01-peerNeedsBurst off
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-expectAES on
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-peerNeedsBurst off
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-expectAES set_off
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-peerNeedsBurst set_on


und Koontakt01:

Code Auswählen Erweitern


     2017-01-01 12:47:49   R-wz0_kon00-expectAES on
     2017-01-01 12:47:49   R-wz0_kon00-peerNeedsBurst off
     2017-01-01 12:47:49   R-wz0_kon00_chn-01-expectAES on
     2017-01-01 12:47:49   R-wz0_kon00_chn-01-peerNeedsBurst off
     2017-01-05 00:51:50   R-wz0_sta00_WindowRec-expectAES set_off
     2017-01-05 00:51:50   R-wz0_sta00_WindowRec-peerNeedsBurst set_on
     2017-01-01 13:16:45   R-wz0_the00_WindowRec-expectAES set_off
     2017-01-01 13:16:45   R-wz0_the00_WindowRec-peerNeedsBurst set_on


Sieht irgendwie so aus als wären die Fensterkontakte untereinander gepeered was aber (wie bereits Pfriemler ausgeführt hat) nicht geht...
Auch sieht es so aus als wäre gepeered worden, allerdings sehe ich (oder habe es übersehen) Peer-IDs...

Das mit dem Rot geht weg, wenn entweder AES aktiviert wird überall bzw. bei allen beteiligten Komponenten oder bei den Fensterkontakten deaktiviert wird.

(es ist, wie bereits ausgeführt denke ich, von Beginn an aktiviert weil diese potetiell "sicherheitsrelevant" sind [Alarmanlegen] allerdings [für mich total sinnfrei   ])

Ansonsten sieht es schon mal gut aus...
...die set_ müssen halt noch abgearbeitet werden bzw. halt direkt bei den Geräten entsprechend eingestellt werden, je nachdem was der Peer "fordert"...

...also AES und burst...

Gruß, Joachim

[Pfriemler]

Wie ihr seht sind jetzt alle CMD's done und die meisten peerIDs leer.

Das ist nicht normal. Komisch. Normalerweise steht da wenigstens 000000 drin. Späte Rache der falschen hmID-Entscheidung. Da Heizkörper und Wandthermostat reagieren, gehören dort beide _WindowRec-Kanäle hinein, klarschriftlich oben, in den attr peerIDs 269BFF03 und 26043E03. Bitte nicht dort eintragen, das mach FHEM selbst. Normalerweise.

Öffne und schließe ich eines der beiden Fenster reagiert der Stellantrieb unmittelbar in weniger als 10s, auf und ab, IMMER.
Öffne ich ein Fenster leuchtet der Kontakt ewig (ca 30s) orange und dann kurz rot. Fenstersymbole erscheinen korrekt an Wandthermostat und Stellantrieb.

Nein, das dürfte nicht so sein. Rot kommt, wenn nur eine der erforderlichen Kommunikationen nicht bis zu Ende durchgeführt ist. Da die Fenstersymbole an Wandthermostat und Heizkörper sofort kommen, wissen die Geräte dass sie auf die FKs hören sollen. Anscheinend ist dann bei beiden im Kanal _WindowRec auch Was die Fensterkontakte für ACKs erwarten, kann man ohne gültige Registerliste nicht einsehen.
Du hast clear Readings und getConfig offenbar nicht durchgeführt, sonst wären die Peerings der FKs each other und die veralteten "set_off"/"set_on" weg.

Also wir brauchen eine gültige peer-Liste der Fensterkontakte, sonst befragen wir die Glaskugel umsonst, was die Fensterkontakte als Antwort erwarten: Sie schicken eine Botschaft in die Welt und erwarten von allen Peers eine korrekte Antwort. Also müssen wir wissen wer gefragt ist. Befindet sich darunter noch eines, was noch nichts von seinem Glück weiß, dann wird es auch nicht antworten.

Last but not least kommt natürlich auch ein Defekt des Empfangsteils des Fensterkontakts (also dass zwar Antworten gesendet werden, aber nicht ankommen). Aber bei beiden?

Ach, ich sehe gerade, eine Antwort ist schon da ...

Also dazu: Nein, bei mir ist der Fensterkontakt von heute AES-aktiviert, erwartet vom Wandthermostaten AES, nicht vom Heizkörper - beide Geräte sind im gepeerten Kanal aber R-sign off. Und es gibt kein rot. Das ist in der Theorie zwar seltsam, aber praktisch funktioniert es...

[MadMax-FHEM]

Ach, ich sehe gerade, eine Antwort ist schon da ...

Also dazu: Nein, bei mir ist der Fensterkontakt von heute AES-aktiviert, erwartet vom Wandthermostaten AES, nicht vom Heizkörper - beide Geräte sind im gepeerten Kanal aber R-sign off. Und es gibt kein rot. Das ist in der Theorie zwar seltsam, aber praktisch funktioniert es...

Wie gesagt ich schalte AES sofort nach dem Pairing der Fensterkontakte bei selbigen aus...
...daher nur Theorie (habe einige Threads bzgl. AES etc. verfolgt, weil ich überlege es irgendwann mal zu aktivieren) in der Praxis fahre ich noch komplett ohne AES...

Gruß, Joachim

[theophilou85]

Sodala, Neuigkeiten auf meiner Front: Nagelneuen optischen Fensterkontakt bekommen. Interessanterweise leuchtet der schon vor dem Pairing korrekt, schnell von orange auf grün.
Kontakt gepaired, leuchtet noch immer korrekt, get config:

Code Auswählen Erweitern

Internals:
   DEF        414C50
   IODev      wz0_cul00
   LASTInputDev wz0_cul00
   MSGCNT     26
   NAME       HM_414C50
   NOTIFYDEV  global
   NR         313
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:57 - t:41 s:414C50 d:000001 012400
   protCmdDel 1
   protLastRcv 2017-01-10 01:20:14
   protResnd  3 last_at:2017-01-10 01:20:20
   protResndFail 1 last_at:2017-01-10 01:20:25
   protSnd    7 last_at:2017-01-10 01:20:14
   protState  CMDs_done_Errors:1
   rssi_at_wz0_cul00 avg:-70.28 max:-63.5 min:-78 cnt:26 lst:-68
   wz0_cul00_MSGCNT 26
   wz0_cul00_RAWMSG A0C57A641414C50000001012400::-68:wz0_cul00
   wz0_cul00_RSSI -68
   wz0_cul00_TIME 2017-01-10 01:20:14
   Readings:
     2017-01-10 01:05:12   CommandAccepted yes
     2017-01-10 01:05:10   D-firmware      1.0
     2017-01-10 01:05:10   D-serialNr      MEQ0947186
     2017-01-10 01:05:10   R-pairCentral   set_0x000001
     2017-01-10 01:05:12   aesKeyNbr       00
     2017-01-10 01:05:22   battery         ok
     2017-01-10 01:05:22   contact         closed (to ActionDetector)
     2017-01-10 01:20:25   state           RESPONSE TIMEOUT:RegisterRead
     2017-01-10 01:20:14   trigDst_ActionDetector noConfig
     2017-01-10 01:20:14   trigger_cnt     36
     Regl_00.:
       VAL
   Helper:
     HM_CMDNR   87
     cSnd       01000001414C5000040000000000,01000001414C5000040000000000
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      440733356
       lstRecType 41
       lstSnd     1484007614.39814
       lstSndTgd  360
       newChn     +414C50,00,00,00
       nextSend   1484007614.39814
       nxtSndMcnt 57
       prefIO
       rxt        0
       tgtDly     120
       vccu
       p:
         414C50
         00
         00
         00
     Mrssi:
       mNo        57
       Io:
         wz0_cul00  -66
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         wz0_cul00
       flg        A
       ts         1484007614.41894
       ack:
         HASH(0x400327c)
         578002000001414C5000
     Rssi:
       At_wz0_cul00:
         avg        -70.2884615384615
         cnt        26
         lst        -68
         max        -63.5
         min        -78
     Tmpl:
Attributes:
   IODev      wz0_cul00
   autoReadReg 4_reqStatus
   expert     2_raw
   room       CUL_HM

Bei diesem nagelneuen Kontakt bekomme ich jetzt wieder ein "RESPONSE TIMEOUT:RegisterRead".

[martinp876]

Io ist cul. Fw ist tscul? Sonst geht hm nicht.
Wenn es so ist dann ein getconfig sniffen.

[theophilou85]

Korrekt, io=cul, fw=tscul

Code Auswählen Erweitern

2017.01.11 23:04:26.822 4: TSCUL_Parse: wz0_cul00  494899 A FF01 12164744 00 0C 63 8470 26043E 000000 00F227 -65
2017.01.11 23:04:28.681 4: TSCUL_send:  wz0_cul00                         As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:28.731 4: TSCUL_Parse: wz0_cul00  496810 A FF13 12166704 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:28.978 4: TSCUL_Parse: wz0_cul00  497056 A FF13 12166956 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:29.275 4: TSCUL_Parse: wz0_cul00  497353 A FF13 12167208 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:29.494 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E6A48001002A001000001414C5000
2017.01.11 23:04:29.494 4: TSCUL_Parse: wz0_cul00  497572 A FF10 12167456 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:34.368 4: TSCUL_send:  wz0_cul00                         As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:34.478 4: TSCUL_Parse: wz0_cul00  502557 A FF13 12172392 02 10 02 A001 000001 414C50 00 _CCAdly:8 -138
2017.01.11 23:04:34.712 4: TSCUL_Parse: wz0_cul00  502791 A FF13 12172640 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:34.978 4: TSCUL_Parse: wz0_cul00  503057 A FF13 12172892 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:35.197 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E6FD5001002A001000001414C5000
2017.01.11 23:04:35.197 4: TSCUL_Parse: wz0_cul00  503275 A FF10 12173140 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:38.306 4: TSCUL_Parse: wz0_cul00  506383 A FF11 12176316 00 0C A0 A641 414C50 000001 012BC8 -71
2017.01.11 23:04:38.321 4: TSCUL_send:  wz0_cul00                         As 0A A0 8002 000001 414C50 00
2017.01.11 23:04:38.321 3: TSCUL_XmitDlyHM:  wz0_cul00  id:414C50 dDly:35 toms:67
2017.01.11 23:04:38.494 4: TSCUL_Parse: wz0_cul00  506572 A FF13 12176436 01 0A A0 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:04:38.555 4: TSCUL_send:  wz0_cul00                         As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:38.666 4: TSCUL_Parse: wz0_cul00  506744 A FF13 12176576 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:260 -138
2017.01.11 23:04:38.869 4: TSCUL_Parse: wz0_cul00  506947 A FF13 12176828 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:512 -138
2017.01.11 23:04:39.088 4: TSCUL_Parse: wz0_cul00  507166 A FF13 12177080 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:764 -138
2017.01.11 23:04:39.306 4: TSCUL_Parse: wz0_cul00  507383 A FF11 12177312 00 0C A1 A641 414C50 000001 012C00 -70.5
2017.01.11 23:04:39.416 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E73F7001002A001000001414C5000
2017.01.11 23:04:39.416 4: TSCUL_Parse: wz0_cul00  507494 A FF10 12177372 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:39.853 4: TSCUL_Parse: wz0_cul00  507930 A FF11 12177872 00 0C A2 A641 414C50 000001 012C00 -71
2017.01.11 23:04:40.635 4: TSCUL_Parse: wz0_cul00  508711 A FF11 12178648 00 0C A3 A641 414C50 000001 012C00 -73
2017.01.11 23:04:41.571 4: TSCUL_send:  wz0_cul00                         As 0A A1 8002 000001 414C50 00
2017.01.11 23:04:41.635 4: TSCUL_Parse: wz0_cul00  509713 A FF13 12179592 01 0A A1 8002 000001 414C50 00 _CCAdly:4 _dhmSt:944 -138
2017.01.11 23:04:41.649 4: TSCUL_send:  wz0_cul00                         As 0A A2 8002 000001 414C50 00
2017.01.11 23:04:41.713 4: TSCUL_Parse: wz0_cul00  509791 A FF13 12179684 01 0A A2 8002 000001 414C50 00 _CCAdly:4 _dhmSt:1036 -138
2017.01.11 23:04:41.728 4: TSCUL_send:  wz0_cul00                         As 0A A3 8002 000001 414C50 00
2017.01.11 23:04:41.791 4: TSCUL_Parse: wz0_cul00  509869 A FF13 12179772 01 0A A3 8002 000001 414C50 00 _CCAdly:4 _dhmSt:1124 -138
2017.01.11 23:04:43.213 4: TSCUL_Parse: wz0_cul00  511289 A FF11 12181228 00 0C A5 A641 414C50 000001 012DC8 -72
2017.01.11 23:04:43.227 4: TSCUL_send:  wz0_cul00                         As 0A A5 8002 000001 414C50 00
2017.01.11 23:04:43.228 3: TSCUL_XmitDlyHM:  wz0_cul00  id:414C50 dDly:40 toms:67
2017.01.11 23:04:43.369 4: TSCUL_Parse: wz0_cul00  511447 A FF13 12181348 01 0A A5 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:04:43.384 4: TSCUL_send:  wz0_cul00                         As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:43.384 3: TSCUL_XmitDlyHM:  wz0_cul00  id:414C50 dDly:0 toms:67
2017.01.11 23:04:43.494 4: TSCUL_Parse: wz0_cul00  511572 A FF13 12181436 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:208 -138
2017.01.11 23:04:43.712 4: TSCUL_Parse: wz0_cul00  511791 A FF13 12181688 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:460 -138
2017.01.11 23:04:43.978 4: TSCUL_Parse: wz0_cul00  512056 A FF13 12181940 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:712 -138
2017.01.11 23:04:44.212 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E78AB001002A001000001414C5000
2017.01.11 23:04:44.212 4: TSCUL_Parse: wz0_cul00  512291 A FF10 12182188 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:44.759 4: TSCUL_Parse: wz0_cul00  512836 A FF11 12182788 00 0C A6 A641 414C50 000001 012E00 -66.5
2017.01.11 23:04:45.306 4: TSCUL_Parse: wz0_cul00  513383 A FF11 12183332 00 0C A7 A641 414C50 000001 012E00 -65.5
2017.01.11 23:04:46.197 4: TSCUL_Parse: wz0_cul00  514274 A FF11 12184172 00 0C A8 A641 414C50 000001 012E00 -65
2017.01.11 23:04:46.399 4: TSCUL_send:  wz0_cul00                         As 0A A6 8002 000001 414C50 00
2017.01.11 23:04:46.478 4: TSCUL_send:  wz0_cul00                         As 0A A7 8002 000001 414C50 00
2017.01.11 23:04:46.556 4: TSCUL_send:  wz0_cul00                         As 0A A8 8002 000001 414C50 00
2017.01.11 23:04:46.619 4: TSCUL_Parse: wz0_cul00  514697 A FF13 12184576 01 0A A8 8002 000001 414C50 00 _CCAdly:4 _dhmSt:404 -138
2017.01.11 23:04:46.728 4: TSCUL_Parse: wz0_cul00  514807 A FF13 12184668 01 0A A6 8002 000001 414C50 00 _CCAdly:4 _dhmSt:496 -138
2017.01.11 23:04:46.838 4: TSCUL_Parse: wz0_cul00  514916 A FF13 12184756 01 0A A7 8002 000001 414C50 00 _CCAdly:4 _dhmSt:584 -138
2017.01.11 23:04:47.041 4: TSCUL_Parse: wz0_cul00  515110 A FF12 12184948 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.01.11 23:04:47.369 4: TSCUL_Parse: wz0_cul00  515446 A FF11 12185292 00 0C A9 A641 414C50 000001 012E00 -66
2017.01.11 23:04:47.384 4: TSCUL_send:  wz0_cul00                         As 0A A9 8002 000001 414C50 00
2017.01.11 23:04:47.447 4: TSCUL_Parse: wz0_cul00  515525 A FF13 12185412 01 0A A9 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:04:49.338 4: TSCUL_Parse: wz0_cul00  517412 A FF11 12187260 00 0F D3 8610 269BFF 000000 0AA0F28B0000 -60
2017.01.11 23:05:20.875 4: TSCUL_Parse: wz0_cul00  024656 A FF12 12218888 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.01.11 23:05:25.203 4: TSCUL_Parse: wz0_cul00  029002 A FF01 12223164 00 0C AA A641 414C50 000001 012FC8 -71.5
2017.01.11 23:05:25.218 4: TSCUL_send:  wz0_cul00                         As 0A AA 8002 000001 414C50 00
2017.01.11 23:05:25.281 4: TSCUL_Parse: wz0_cul00  029081 A FF13 12223284 01 0A AA 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:05:27.640 4: TSCUL_Parse: wz0_cul00  031440 A FF01 12225656 00 0C AB A641 414C50 000001 013000 -69.5
2017.01.11 23:05:27.655 4: TSCUL_send:  wz0_cul00                         As 0A AB 8002 000001 414C50 00
2017.01.11 23:05:27.655 3: TSCUL_XmitDlyHM:  wz0_cul00  id:414C50 dDly:45 toms:73
2017.01.11 23:05:27.828 4: TSCUL_Parse: wz0_cul00  031628 A FF13 12225776 01 0A AB 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138

[theophilou85]

So, ich bin jetzt ziemlich am Ende meiner Reise mit den Fensterkontakten. Dank der neuen Firmware sehe ich endlich alle peerID's. Habe jetzt alle alten peerID's gelöscht und mir werden nun alle Peers korrekt angezeigt.

Stellantrieb und die beiden Fensterkontakte arbeiten tadellos. Das einzige was im Moment nicht übertragen wird, ist das Fenstersymbol an das Wandthermostat. Es erscheint aber korrekt am Stellantrieb.

Was ist jetzt eigentlich die korrekte Form des Peerings? Fensterkontakte(WindowRec) mit Stellantrieb(WindowRec)+Fensterkontakt(WindowRec) mit Wandthermostat(WindowRec). Oder Fensterkontakt(WindowRec) mit Stellantrieb(WindowRec)+Stellantrieb(WindowRec) mit Wandthermostate(WindowRec)?