HM-CC-RT-DN erkennt Signal vom HM-SEC-SCo nicht

Begonnen von amielke, 26 August 2017, 12:33:57

Vorheriges Thema - Nächstes Thema

amielke

Hallo,
ich setzte seit ein paar Monaten einen FHEM mit Homematic-Themostaten erfolgreich ein und will diese mit optischen Fensterkontakten koppeln. Die Kontakte wurde mit FHEM gepairt und melden auch ein open und close. Das Peering mit dem Thermostaten auf Channel3 habe ich auch nach Anleitung gemacht, jedoch merke ich keine Reaktion am Themostat. Was mache ich falsch?
Wo ist iegentlich die "Fenster offen-Absenktemperatur" eingestellt, ich konnte nix sehen. :-[

Bin für jeden Tipp dankbar!
Danke und viele Grüße
Andreas

Hier die Konfig vom Thermostat Channel3
nternals:
   DEF        51199503
   NAME       HeZ_Heizung_WindowRec
   NOTIFYDEV  global
   NR         105
   NTFY_ORDER 50-HeZ_Heizung_WindowRec
   STATE      last:trigLast
   TYPE       CUL_HM
   chanNo     03
   device     HeZ_Heizung
   peerList   HeZ_Dachfenster1,
   Readings:
     2017-02-11 17:45:02   R-sign          off
     2017-08-26 11:57:30   RegL_01.          08:00 00:00
     2017-08-26 11:57:30   RegL_03.HeZ_Dachfenster1_chn-01   04:32 00:00
     2017-08-26 11:57:30   RegL_07.HeZ_Dachfenster1_chn-01   05:18 00:00
     2017-08-26 11:57:46   peerList        HeZ_Dachfenster1,
     2017-08-26 11:57:46   state           unknown
   Helper:
     peerIDsRaw ,474AB601,00000000
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
     Shadowreg:
Attributes:
   model      HM-CC-RT-DN
   peerIDs    474AB601,
   stateFormat last:trigLast


und hier die Konfig vom Fensterkontakt
Internals:
   CUL_0_MSGCNT 282
   CUL_0_RAWMSG A0CFD8641474AB6000000017E00::-42.5:CUL_0
   CUL_0_RSSI -42.5
   CUL_0_TIME 2017-08-26 12:15:57
   DEF        474AB6
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     282
   NAME       HeZ_Dachfenster1
   NOTIFYDEV  global
   NR         36
   NTFY_ORDER 50-HeZ_Dachfenster1
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:FD - t:41 s:474AB6 d:000000 017E00
   protCmdDel 28
   protLastRcv 2017-08-26 12:15:57
   protResnd  12 last_at:2017-08-26 12:09:21
   protResndFail 4 last_at:2017-08-26 12:09:39
   protSnd    22 last_at:2017-08-26 12:09:36
   protState  CMDs_done_Errors:1
   rssi_at_CUL_0 avg:-51.69 lst:-42.5 min:-86.5 cnt:282 max:-30
   Readings:
     2017-08-26 11:55:09   Activity        alive
     2017-08-26 11:55:09   D-firmware      1.0
     2017-08-26 11:55:09   D-serialNr      NEQ0356957
     2017-02-11 19:11:44   R-HeZ_Heizung_WindowRec-expectAES set_off
     2017-02-11 19:11:44   R-HeZ_Heizung_WindowRec-peerNeedsBurst set_on
     2016-11-26 21:19:55   R-pairCentral   set_0xA4E21F
     2017-02-07 18:50:01   STATE           0
     2017-08-19 11:55:10   aesKeyNbr       00
     2017-08-26 11:51:00   alive           yes
     2017-08-26 12:15:57   battery         ok
     2017-08-26 12:15:57   contact         closed (to broadcast)
     2017-02-07 19:35:11   powerOn         2017-02-07 19:35:11
     2017-08-26 11:51:00   recentStateType info
     2017-08-26 11:51:00   sabotageError   off
     2017-08-26 12:15:57   state           closed
     2017-08-26 12:15:57   trigDst_broadcast noConfig
     2017-08-26 12:15:57   trigger_cnt     126
   Helper:
     HM_CMDNR   253
     cSnd       01A4E21F474AB601015119950300,01A4E21F474AB601055119950304
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +474AB6,00,00,00
       nextSend   1503742557.17755
       prefIO
       rxt        2
       vccu
       p:
         474AB6
         00
         00
         00
     Mrssi:
       mNo        FD
       Io:
         CUL_0      -40.5
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_0:
         avg        -51.6985815602837
         cnt        282
         lst        -42.5
         max        -30
         min        -86.5
     Shadowreg:
       RegL_04.HeZ_Heizung_WindowRec  01:01
Attributes:
   IODev      CUL_0
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   icon       fts_window_roof@orange
   model      HM-SEC-SCo
   room       Helenas Zimmer
   serialNr   NEQ0356957
   subType    threeStateSensor

LuckyDay

2017-08-26 12:15:57   contact         closed (to broadcast)

dein Fensterkontakt ist nicht gepairt , zwar angelegt in Fhem , Fhem lauscht nur mit.

martinp876

Ob er gepairt ist kann ich nicht sehen. Durch ein getconfig kann man es bestätigen.
Ist allerdings für die direkte Kommunikation RT SC egal.
Ob der rt auf den Schutz reagiert kann man erkennen, wenn der rt ein ACK sendet.
Der SC scheint nicht gepeert, da er nur Trigger an Broadcast sendet, nicht an den RT. Somit reagiert der er auch nicht. Kann nicht, da in diesem Fall der SC ein burst schicken müsste. Da es aber nicht gepeert ist, weiss er dies auch nicht
Was er tun sollte, und wann, steht wie immer in den Registern. Hier bitte die beiden Register des winrec studieren.


Seltsam in der config ist, dass der SC Register für einen Peer hat, dieser aber nicht gepeert scheint. Scheinbar gibt es eine Vorgeschichte

Grinsekatze

#3
Wie der Knecht schon sagte, der Fensterkontakt ist nicht gepaired:
     2016-11-26 21:19:55   R-pairCentral   set_0xA4E21F

Wenn vor den Werten "set_" steht, dann ist das Pairing nicht abgeschlossen. Paire ihn noch mal. Ich hatte mit meinen HM-Geräten (spez. den HM-Sec-SCo) auch zu Beginn Schwierigkeiten. Oft muss ich die Geräte zwei mal pairen.

Versuche einfach analog zum pairen auch das peeren zwei Mal.

Sonst schon mal das gemacht:
https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt

Das erklärt dann auch
     2017-02-11 19:11:44   R-HeZ_Heizung_WindowRec-expectAES set_off
     2017-02-11 19:11:44   R-HeZ_Heizung_WindowRec-peerNeedsBurst set_on


Hier ist auch noch eine schöne Erklärung zum generellen peeren der beiden Geräte:
http://blog.wenzlaff.de/?p=2782

Grinsekatze

#4
Ok, ich habe es eben noch mal bei mir gemacht - hatte ganz übersehen, dass ich das peering bei meinem neuen Wohnzimmer-Kontakt noch nicht gemacht habe.

Ich nutze die Reihenfolge: Erst mit FHEM pairen, dann untereinander peeren. Dabei aufpassen, dass der Fensterkontakt den Status "closed" hat - also Fenster geschlossen halten.

1. Zuerst den Fensterkontakt mit der Zentrale pairen (ggf. musst Du 2 Mal pairen, wenn im Reading "PairedTo" ein "set_" steht).
2. Dann das Thermostat mit der Zentrale pairen (ggf. musst Du 2 Mal pairen, wenn im Reading "PairedTo" ein "set_" steht).
3. Fensterkontakt mit Thermostat peeren (für jedes zu peerende Thermostat / Wandthermostat durchführen): set <HM-SEC-SCo> peerChan 0 <HM-CC-RT-DN>_WindowRec single set
4. Am Fensterkontakt zügig nach dem vorigen Schritt die Anlerntaste drücken, um das peering zu übernehmen.
5. Interne Fenster-Offen-Erkennung des Thermostaten deaktivieren, da der Fensterkontakt schneller reagiert (für jedes gepeerte Thermostat durchführen): set <HM-CC-RT-DN>_Clima regSet winOpnMode off
6. Absenktemperatur des Thermostaten einstellen (für jedes gepeerte Thermostat / Wandthermostat durchführen): set <HM-CC-RT-DN>_WindowRec regSet winOpnTemp 5 <HM-SEC-SCo>

Wenn Du nun das Fenster öffnest, siehst Du im Web-Frontend, dass die Soll-Temperatur des Thermostaten sofort auf 5°C wechselt, bis das Fenster wieder geschlossen wird. Dann springt die Soll-Temperatur wieder auf den vorigen Wert.

amielke

Hallo,
vielen Dank für die Tipps, die soweit verstanden habe, allerdings in Praxis keinen Erfolg hatten.
Ich habe das Device im FHEM gelöscht, den Sensor resetet und dann neu mit dem CUL gepairt. Es bleibt aber beim R-pairCentral   set_0xA4E21F .
Auch mehrmaliges Pairing hintereinander brachte keine Änderung. Ebenfalls habe getConfig erfolglos probiert.
Ich bin ratlos! :-(


Gesendet von iPad mit Tapatalk

Otto123

Hi,

man darf den Fensterkontakt beim pairen bzw. getConfig nicht auslösen! Wohl aus Sicherheitsgründen führt er die notwendige Datenübertragung nur durch, wenn man den configtaster drückt!
Beim Pairen muss man den configTaster mindestens zweimal drücken. Also
set <IO> hmPairForSec 60
configTaster drücken (und nicht aus Versehen den Sensor auslösen) Datenübertragung abwarten (blinkern endet mit Grün)
nochmal
configTaster drücken (und nicht aus Versehen den Sensor auslösen) Datenübertragung abwarten (blinkern endet mit Grün)

Also wenn es schon die Vorgeschichte gibt (     2016-11-26 21:19:55   R-pairCentral   set_0xA4E21F ) und seit dem viel probiert wurde, würde ich als erstes ein
set <> clear all machen
dann set <> getConfig
dann configTaster drücken (und nicht aus Versehen den Sensor auslösen) Datenübertragung abwarten (blinkern endet mit Grün)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

amielke

#7
Hallo Otto,

ich habe jetzt sowohl ein
Zitatset <> clear all machen
dann set <> getConfig
dann configTaster drückenset <> clear all machen
dann set <> getConfig
dann configTaster drücken
gemacht. Ohne Erfolg, das Reading R-pairCentral set_0xA4E21F bleib bestehen.

Dann habe ich den Sensor auf Werkseinstellung zurückgesetzt und von Anfang begonnen gemäß deiner Anleitung
Zitatset <IO> hmPairForSec 60
configTaster drücken (und nicht aus Versehen den Sensor auslösen) Datenübertragung abwarten (blinkern endet mit Grün)
nochmal
configTaster drücken (und nicht aus Versehen den Sensor auslösen) Datenübertragung abwarten (blinkern endet mit Grün)

Beim zweiten Mal config-Taster erhalte ich kein Grün.
Woran kann das liegen, was mache ich falsch? 

Habe jetzt gerade nochmal nach Anleitung einen fabrikneuen Sensor genommen und habe genau den gleichen Effekt. >:(

Bin leider immer noch ratlos.
Vielen Dank und viele Grüße!
Andreas

Otto123

#8
Hi,

alle Homematic Geräte mit Sec im Namen werden mit aktiviertem AES ausgeliefert. Du hast einen CUL?
ZitatFür alle CUL-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.
Bei CUL Kompatiblen Geräten kann es zu Timingproblemen kommen. Für CUL Geräte ist für HomeMatic generell die TS Firmware angeraten!

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

amielke

Zitat von: Otto123 am 03 September 2017, 19:56:09
Hi,

alle Homematic Geräte mit Sec im Namen werden mit aktiviertem AES ausgeliefert. Du hast einen CUL?
Gruß Otto
Hallo Otto,
du liegst mit deiner Vermutung richtig, ich habe einen CUL-Stick im Einsatz.
Dein Hinweis ist sehr interessant. Das hatte ich so noch nicht gewusst! An der Stelle muss ich mich wohl noch fortbilden.
Das Pairing habe ich deshalb noch nicht hinbekommen, wohl aber das Peering zwischen optischem Kontakt und Thermostat, indem ich das Pairing zum FHEM ausgelöst habe und das Thermostat resetet und direkt mit dem Kontakt gepeert habe.

Vielen Dank für deine Hilfe!


Gesendet von iPad mit Tapatalk

Burny4600

ZitatInterne Fenster-Offen-Erkennung des Thermostaten deaktivieren, da der Fensterkontakt schneller reagiert (für jedes gepeerte Thermostat durchführen):
Code: [Auswählen]

set <HM-CC-RT-DN>_Clima regSet winOpnMode off
Wie sieht das aus wenn ein <HM-CC-RT-DN> und <HM-TC-IT-WM-W-EU> gepeert ist aus?
Ich dachte immer winOpnMode muss auf on gesetzt werden damit die Fenstersensoren die Absenkung bzw. beim geschlossenen Fenster wieder auf den alten Sollwert zurückgesetzt werden.
So habe ich das aus Anleitungen zumindest übernommen und es funktioniert auch.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess