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

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