Status des Fensterkontakts beim Heizkörperthermostat gibt den Status unknown an

Begonnen von bitgulli, 19 Februar 2017, 12:49:23

Vorheriges Thema - Nächstes Thema

bitgulli

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

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

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

bitgulli

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

frank

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?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

bitgulli

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

frank

R-pairCentral    0x000000
ZitatHier hab ich überhaupt keine Probleme.

warum dann der thread?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

bitgulli

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

martinp876

Ich sehe kein peerings in der Terrassentür. Warum sollte sie den RT adressieren.

bitgulli

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

frank

dann fangen wir also wieder von vorne an.  :)

solange die fk nicht gepairt sind, können sie auch nicht gepeert werden.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

bitgulli

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.


frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

bitgulli

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.

frank

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".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

bitgulli

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: -.


frank

haben deine devices kein attr IODev?
poste mal ein list von deinem cul.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

bitgulli

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



bitgulli

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