Nach erfolgreichem peering eines Fensterkontankts (HM-Sec-SCo) mit meinen Heizkörperthermostaten (HM-CC-RT-DN) wird dieser zwar in den Readings der <Thermostat>_WindowRec (PeerList) angezeigt, jedoch steht bei state immer unknown.
Ich bin streng nach den Wiki vorgegangen: https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat
Was könnte denn da schief gelaufen sein?
Gruß
Bitgulli
Da bisher noch niemand geantwortet hat hier noch einige Daten:
Fensterkontakt:
Internals:
CUL_0_MSGCNT 16
CUL_0_RAWMSG A1A1F84004EFE100000001000C74E45513132383530353380810101::-62:CUL_0
CUL_0_RSSI -62
CUL_0_TIME 2017-02-20 14:36:52
DEF 4EFE10
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 16
NAME Terrassentuer
NOTIFYDEV global
NR 71
NTFY_ORDER 50-Terrassentuer
STATE closed
TYPE CUL_HM
lastMsg No:1F - t:00 s:4EFE10 d:000000 1000C74E45513132383530353380810101
protCmdPend 17 CMDs_pending
protLastRcv 2017-02-20 14:36:52
protResnd 3 last_at:2017-02-20 14:36:54
protSnd 11 last_at:2017-02-20 14:36:52
protState CMDs_pending
rssi_at_CUL_0 lst:-62 avg:-60.37 min:-65 max:-57.5 cnt:16
Readings:
Activity alive
D-firmware 1.0
PairedTo 0x000000
R-HKWohnzimmer_WindowRec-expectAES set_off
R-HKWohnzimmer_WindowRec-peerNeedsBurst set_on
R-cyclicInfoMsg on
R-eventDlyTime 0 s
R-pairCentral 0x000000
R-sabotageMsg on
R-sign on
aesKeyNbr 00
alive yes
battery ok
contact closed (to broadcast)
recentStateType info
sabotageError off
state closed
trigger_cnt 192
Attributes:
ODev CUL_0
actCycle 000:50
actStatus alive
alias Terrassentür
autoReadReg 4_reqStatus
devStateIcon closed:fts_door_right open:fts_door_right_open@red
expert 2_full
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000
room CUL_HM,Wohnzimmer
subType threeStateSensor
Heizkörperthermostat_WindowRec
Internals:
DEF 51AD8403
NAME HKWohnzimmer_WindowRec
NOTIFYDEV global
NR 109
NTFY_ORDER 50-HKWohnzimmer_WindowRec
STATE last:trigLast
TYPE CUL_HM
chanNo 03
device HKWohnzimmer
peerList Terrassentuer
Readings:
R-sign off
RegL_01. 08:00 00:00
RegL_03.Terrassentuer_chn-01 04:32 00:00
RegL_07.Terrassentuer_chn-01 05:18 00:00
peerList Terrassentuer,
state unknown
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,4EFE1001
stateFormat last:trigLast
Das peering hab ich folgendermaßen vorgenommen.
set Terrassentuer peerChan 0 HKWohnzimmer_WindowRec single set
Natürlich war der Anlernknopf am Fensterkontakt gedrückt worden und der Kontakt stand auch auf closed.
Ich weiß nicht mehr weiter und bin für jeden Hinweis dankbar.
Gruß
Bitgulli
der fk ist nicht gepairt. dann funktioniert auch kein peering, etc.
ausserdem musst du das knöpfchen öfter mal drücken, bis alle pending cmds abgearbeitet sind.
Irgendwie komm ich nicht weiter.
Womit soll ich den FK pairen? Mit dem Thermostat, vermutlich, denn mit dem CUL ist er ja schon gepairt.
Allerdings krieg ich dann auf dem Thermostat bei den Internals: protState CMDs_done_Errors:1
und bei den Readings: state Nack
Beim FK krieg ich bei state MISSING ACK
Übrigens egal ob ich zuerst den Pairing-Befehl beim FK oder beim Thermostat auslöse.
Meinst Du mit dem Knöpfchen das vom FK?
Gruß
Bitgulli
ZitatWomit soll ich den FK pairen?
gepairt wird immer mit einer zentrale, also fhem, mit hmpairforsec beim cul. schau dir mal das wiki übers pairen an, dann kannst du auch erkennen, wie ein erfolgreiches pairing aussieht. vorher pending cmds löschen mit set clear msgEvents.
das device nicht vorher löschen, einfach drüberpairen.
hast du das perlmodul crypt:rijindael installiert?
Also mit dem CUL sind alle Geräte gepairt, sowohl alle Thermostate als auch die Fensterkontakte. Das läuft auch alles ohne Probleme.
Die Thermostate werden über den CUL und FHEM wie erwünscht gesteuert, und die Fensterkontakte liefern ihren Status über den CUL und steuern auch andere Geräte. Hier hab ich überhaupt keine Probleme.
Allerdings haut es mit dem peering zwischen den Fensterkontakten und der Thermostaten scheinbar nicht hin.
Alle pending commands sind inzwischen weg. Allerdings hat sich an der Situation nichts geändert.
Mir geht es vor allem um die Abschaltung von Heizkörpern, falls ein Fenster aufgemacht wird.
Gruß
Bitgulli
R-pairCentral 0x000000ZitatHier hab ich überhaupt keine Probleme.
warum dann der thread?
weil die Fensterkontakte die Thermostate nicht abstellen, wenn sie auf offen stehen. Ich krieg immer nur deren state als unknown in <Thermostat>_WindowRec, und das kann es ja wohl nicht sein, denn dort stehen sie ja auch in der peerList. Warum kommt deren state den der CUL bzw. FHEM ja registriert nicht bis dorthin durch?
Das genau war ja meine Frage bei der Eröffnung des Threads.
Gruß
Bitgulli
Ich sehe kein peerings in der Terrassentür. Warum sollte sie den RT adressieren.
Andrerseits ist ein peering in der <Thermostat>_WindowRec zu sehen, was sich auch mit
set Terrassentuer peerChan 0 HKWohnzimmer_WindowRec single set setzen bzw. mit
set Terrassentuer peerChan 0 HKWohnzimmer_WindowRec single unset wieder lösen lässt.
Und genau hier setzt ja meine Frage an, was ich denn vielleicht falsch gemacht haben könnte, dass es nicht zu einem vollständigen peering kommt. Denn nach dem Wiki sollte es ja so funktionieren.
Gruß
Bitgulli
dann fangen wir also wieder von vorne an. :)
solange die fk nicht gepairt sind, können sie auch nicht gepeert werden.
Die FK sind mit dem CUL_HM gepairt und versehen auch einwandfrei ihren Dienst. Ich kann ja in FHEM sehen, ob ein Fenster oder eine Tür offen oder geschlossen ist.
Außerdem steuern sie ja auch meinen Einbruchsalarm, der ausgelöst wird, wenn kein Smartphone im Haus ist, und eine(s) der Fenster/Türen unbefugt geöffnet wird.
Die Thermostate sind auch mit dem CUL_HM gepairt, sonst würden ja meine Wochenpläne für die Steuerung der Heizkörper nicht funktionieren.
ZitatDie FK sind mit dem CUL_HM gepairt und versehen auch einwandfrei ihren Dienst. Ich kann ja in FHEM sehen, ob ein Fenster oder eine Tür offen oder geschlossen ist.
Außerdem steuern sie ja auch meinen Einbruchsalarm, der ausgelöst wird, wenn kein Smartphone im Haus ist, und eine(s) der Fenster/Türen unbefugt geöffnet wird.
leider kein indiz für pairing.
warum bist du eigentlich so stur? ;)
in deinem list war doch genau zu sehen, dass nicht gepairt ist. seltsam.
und das empfohlene wiki, hast du auch nicht angeschaut.
Das hat mit Sturheit nichts zu tun ;).
Ich war mir absolut sicher, dass ich die FKs (sind schon länger im Einsatz) bei der Einrichtung richtig gepairt hatte. Eventuell bin ich beim peering mal zu lange auf der Anlerntaste geblieben und habe dadurch die FKs in den Werkszustand zurückversetzt :( .
Jetzt steht beim Heizkörperthermostat (HKT) sowohl bei PairedTo als auch bei R-pairCentral 0xF11034 also der CUL drin. Bei den FKs steht er nur in R-pairCentral und in PairedTo steht 0x000000.
Beim peering hat sich aber auch jetzt nichts geändert. In der peerList des HKT steht der FK aber der state ist immer noch unknown.
ZitatBei den FKs steht er nur in R-pairCentral und in PairedTo steht 0x000000.
erst wenn
beide readings korrekt sind, dann kannst du das peering erneut versuchen.
in beiden devices (rt und fk) muss jeweils der andere in der peerlist stehen.
zur kontrolle empfiehlt sich "get hminfo configCheck".
Ich kann machen was ich will, ich krieg einfach den CUL nicht in pairedTo rein.
der configChk gibt aus:
missing register list
Badfenster: RegL_00.,RegL_01.
Buerotuer: RegL_00.,RegL_01.
Haustuer: RegL_00.,RegL_01.
Terrassentuer: RegL_00.,RegL_01.
Register changes pending
Badfenster
Buerotuer
Haustuer
Terrassentuer
peer list incomplete. Use getConfig to read it.
incomplete: Haustuer:
peer not verified. Check that peer is set on both sides
HKBad_WindowRec p:Badfenster
HKDusche_WindowRec p:Badfenster
HKWohnzimmer_WindowRec p:Terrassentuer
trigger sent to undefined device
triggerUndefined: Buerotuer:F11034
triggerUndefined: Haustuer:F11034
PairedTo mismatch to IODev
Badfenster paired:set_0xF11034 IO attr: -.
Buerotuer paired:set_0xF11034 IO attr: -.
HKBad paired:0xF11034 IO attr: -.
HKDusche paired:0xF11034 IO attr: -.
HKKueche paired:0xF11034 IO attr: -.
HKWohnzimmer paired:0xF11034 IO attr: -.
HM_5243DE paired:0xF11034 IO attr: -.
Haustuer paired:set_0xF11034 IO attr: -.
Terrassentuer paired:set_0xF11034 IO attr: -.
haben deine devices kein attr IODev?
poste mal ein list von deinem cul.
Internals
CMDS BbCFiAZNkGMKUYRTVWXefmLltux
CUL_0_MSGCNT 61
CUL_0_TIME 2017-02-21 15:44:31
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:
DEF /dev/ttyACM0@9600 1034
DeviceName /dev/ttyACM0@9600
FD 10
FHTID 1034
NAME CUL_0
NR 19
NR_CMD_LAST_H 43
PARTIAL
RAWMSG A0FE7861051AB410000000A4C930B00001D
RSSI -59.5
STATE Initialized
TYPE CUL
VERSION V 1.66 CUL868
initString X21 Ar
Readings und Attributes sind Standard
Endlich hab ich es.
Nachdem ich nochmals von vorne qngefangen habe (Alle RTs und FKs in den Auslieferungszustand zurückversetzt) hab ich erst mal dem CUL eine persönliche hmId verpasst.
Dann habe ich nochmals sauber gepairt, bis in allen Geräten sowohl bei R-pairCentral als auch bei PairedTo die hmId des CUL drinstandt.
Das anschließende Peering mittels set <FT> peerChan 0 <RT>_WindowRec bei vorher Aktivierter Anlerntaste am FK resultiert erst mal darin, dass nach einer gewissen Wartezeit der FK in den Einträgen PeerList (Readings) als auch PeerIDs (Attributes) des RT_WindowRec erscheint.
Allerdings ist der RT noch nicht in PeerIDs des FK zu sehen, und folglicherweise tut sich auch nichts beim Öffnen des Fensters bei den RTs.
Und jetzt kommt es, und das hab ich bisher weder im Wiki noch sonst irgendwo gefunden:
Erst nachdem man dann zuerst die Anlerntaste beim RT und dann nochmals unmittelbar den Anlernknopf beim FK ausgelöst hat, erscheint der RT auch in PeerIDs beim FK.
Dann nur noch, wie im Wiki beschrieben, die gewünschte Temperatur für den Zustand FensterOffen einstellen und die interne FensterOffen-Erkennung des RT abschalten, und die Sache läuft.
Allerdings, im state der Attributes von <RT>_WindowRec steht immer noch unknown. Wozu ist dieses Reading eigentlich da?
Gruß
Bitgulli
p.s.: RT = HM-CC-RT-DN, FK = HM-Sec-SCo