[Gelöst ] Opt. Fensterkontakt HM-SEC-SCo mit HM-CC-RT-DN Peering nicht möglich?

[FFHEM]

Hallo liebe Leute,
ich versuche nach Anleitung einen opt. Fensterkontakt mit einem Heizkörperthermostat zu peeren: bei Fensteröffnung -> Temperaturabsenkung.
Beide Teile wurden vorher in FHEM gepairt, der Fensterkontakt funktioniert schon seit Monaten für eine Alarmanlage einwandfrei.
Frage: in den Anleitungen wurde bisher nie explizit der opt. Fensterkontakt erwähnt, nur der magnetische. Ist der optische dafür geeignet?
Das Absenken der Solltemperatur funktioniert auch MANCHMAL, dann sehr oft wieder nicht. Habe schon so ziemlich alles probiert, Peeren, getconfig mehrfach, Unpeeren, wieder neu Peeren.

Im RT sieht es ok aus:

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/fhem_geraete.cfg
   DEF        44E88103
   NAME       HT_Gaeste_WC_WindowRec
   NR         150
   NTFY_ORDER 50-HT_Gaeste_WC_WindowRec
   STATE      last:trigLast
   TYPE       CUL_HM
   chanNo     03
   device     HT_Gaeste_WC
   peerList   Melder_Gaeste_WC,
   Readings:
     2016-01-30 14:59:41   R-sign          off
     2016-02-03 14:49:19   RegL_01.        08:00 00:00
     2016-02-03 14:49:20   RegL_03.Melder_Gaeste_WC_chn-01 04:32 00:00
     2016-02-03 14:49:20   RegL_07.Melder_Gaeste_WC_chn-01 05:18 00:00
     2016-02-03 15:09:25   peerList        Melder_Gaeste_WC,
     2016-02-03 15:09:25   state           unknown
   Helper:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
Attributes:
   group      Heizkörperthermostat
   model      HM-CC-RT-DN
   peerIDs    00000000,444CD201,
   room       Heizung
   stateFormat last:trigLast

Aber im Fensterkontakt:

Code Auswählen Erweitern

CFGFN      ./FHEM/fhem_geraete.cfg
   DEF        444CD2
   IODev      CUL_0
   NAME       Melder_Gaeste_WC
   NR         373
   NTFY_ORDER 50-Melder_Gaeste_WC
   STATE      closed
   TYPE       CUL_HM
   Readings:
     2016-02-03 15:09:25   Activity        alive
     2016-02-03 14:51:02   D-firmware      1.0
     2016-02-03 14:51:02   D-serialNr      MEQ1657962
     2016-02-03 14:49:04   R-HT_Gaeste_WC_WindowRec-expectAES set_off
     2016-02-03 14:49:04   R-HT_Gaeste_WC_WindowRec-peerNeedsBurst set_on
     2016-02-03 14:50:38   battery         ok
     2016-02-03 14:50:38   contact         closed (to broadcast)
     2016-02-03 14:50:38   state           closed
     2016-02-03 14:50:38   trigger_cnt     223
   Helper:
     HM_CMDNR   1
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +444CD2,00,00,00
       prefIO
       rxt        2
       vccu
       p:
         444CD2
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
Attributes:
   IODev      CUL_0
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon open:10px-kreis-rot closed:10px-kreis-gruen
   expert     2_full
   firmware   1.0
   group      Fenster/Tür
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       Alarmanlage
   serialNr   MEQ1657962
   subType    threeStateSensor

sieht R-HT_Gaeste_WC_WindowRec-expectAES und
R-HT_Gaeste_WC_WindowRec-peerNeedsBurst verdächtig aus.

Ähnliche Probleme habe ich mit dem Wandthermostat in einem anderen Raum und dem dortigen Fensterkontakt: funktioniert ein paar Mal, danach Ende.
Der Rest (Temperaturregelung per FHEM usw.) läuft einwandfrei.

(Neueste FHEM-Version, Raspberry PI 2, CUL).

Vielen Dank!

[Otto123]

Der Fensterkontakt ist noch nicht fertig. Nochmal Anlerntaste drücken damit die Daten übertragen werden.

[FFHEM]

Hallo Otto,
danke, das habe ich jetzt auch gemacht, aber es hat nichts gebracht. Beim Öffnen des Fensters kommt direkt nach dem Peeren vielleicht nach dem 2. oder 3. Mal eine Reaktion am HT. Dann erscheint das Fenstersymbol und die 12 °C werden angefahren. Beim Schließen klappt es dann auch nicht immer, ist zufällig. Nach einer Zeit lang reagiert der HT gar nicht mehr auf den Kontakt.

Zusatzinfo:
Um Hardwareprobleme auszuschließen: Das Gleiche habe ich in einem anderen Raum, hier ist ein Wandthermostat, der z. T. 2 HT steuert, alle Teile mit FHEM gepairt, dann erst Wandthermostat mit HTs gepeert. Normale Heizungsregelung klappt einwandfrei.
Nur wenn ich den dortigen Fensterkontakt mit dem Wandthermostat peere, habe ich den gleichen Effekt wie oben: im Wandthermostat steht der Fensterkontakt schön in der Peerlist, aber im Fensterkontakt stehen diese beiden komischen Readingseinträge:

     2016-02-04 15:56:38   R-Wohnzimmerthermostat_WindowRec-expectAES set_off
     2016-02-04 15:56:38   R-Wohnzimmerthermostat_WindowRec-peerNeedsBurst set_on

Über den Zustand "set_off" bzw. "set_on" kommen die Readings nicht hinweg, müssten die nicht irgendwann auf "on" oder "off" stehen?
Habe danach natürlich auch wieder ein getconfig an beiden Devices gemacht, keine Änderung.

Hier nochmal alles:

Code Auswählen Erweitern

CFGFN      ./FHEM/fhem_geraete.cfg
   CUL_0_MSGCNT 61
   CUL_0_RAWMSG A0ECEA01037B1BAF112340100000000::-59:CUL_0
   CUL_0_RSSI -59
   CUL_0_TIME 2016-02-04 16:03:10
   DEF        37B1BA
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     61
   NAME       Melder_Wohnzimmer_links
   NR         355
   NTFY_ORDER 50-Melder_Wohnzimmer_links
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:CE - t:10 s:37B1BA d:F11234 0100000000
   protCmdDel 6
   protLastRcv 2016-02-04 16:03:10
   protNack   1 last_at:2016-02-04 15:56:47
   protSnd    15 last_at:2016-02-04 16:03:10
   protState  CMDs_done
   rssi_at_CUL_0 max:-53.5 lst:-59 avg:-59.6 cnt:61 min:-65.5
   Readings:
     2016-02-04 16:03:09   Activity        alive
     2016-02-04 15:56:47   CommandAccepted no
     2016-02-04 16:03:09   D-firmware      1.0
     2016-02-04 16:03:09   D-serialNr      MEQ0285779
     2016-02-04 16:03:10   PairedTo        0x000000
     2016-02-04 15:56:38   R-Wohnzimmerthermostat_WindowRec-expectAES set_off
     2016-02-04 15:56:38   R-Wohnzimmerthermostat_WindowRec-peerNeedsBurst set_on
     2016-01-31 16:09:02   R-cyclicInfoMsg on
     2016-01-31 16:09:03   R-eventDlyTime  0 s
     2016-01-31 16:09:02   R-pairCentral   0x000000
     2016-01-31 16:09:02   R-sabotageMsg   on
     2016-01-31 16:09:03   R-sign          on
     2016-02-04 16:03:10   RegL_00.          02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
     2016-02-04 16:03:10   RegL_01.          08:01 20:9C 21:00 30:06 00:00
     2016-02-04 15:56:47   aesKeyNbr       00
     2016-02-04 15:49:02   alive           yes
     2016-02-04 16:02:21   battery         ok
     2016-02-04 16:02:21   contact         closed (to broadcast)
     2016-02-04 15:49:02   recentStateType info
     2016-02-04 15:49:02   sabotageError   off
     2016-02-04 16:02:21   state           closed
     2016-02-04 16:02:21   trigger_cnt     252
   Helper:
     HM_CMDNR   206
     cSnd       01F1123437B1BA01040000000001,01F1123437B1BA0103
     mId        00C7
     peerIDsRaw ,00000000
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +37B1BA,00,00,00
       nextSend   1454598190.73895
       prefIO
       rxt        2
       vccu
       p:
         37B1BA
         00
         00
         00
     Mrssi:
       mNo        CE
       Io:
         CUL_0      -57
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1454598190.64297
       ack:
         HASH(0x20c0668)
         CE8002F1123437B1BA00
     Rssi:
       At_cul_0:
         avg        -59.6065573770492
         cnt        61
         lst        -59
         max        -53.5
         min        -65.5
     Shadowreg:
       RegL_04.Wohnzimmerthermostat_WindowRec  01:01
Attributes:
   IODev      CUL_0
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon open:10px-kreis-rot closed:10px-kreis-gruen
   expert     2_full
   firmware   1.0
   group      Fenster/Tür
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       Alarmanlage
   serialNr   MEQ0285779
   subType    threeStateSensor

Wie schon gesagt, habe bereits auch ein "unset" und wieder neues "set" gemacht:

set Melder_Wohnzimmer_links peerChan 0 Wohnzimmerthermostat_WindowRec single set
(gefolgt von getconfig an beiden Devices)

sowie ein
set Melder_Wohnzimmer_links peerChan 0 Wohnzimmerthermostat_WindowRec single unset
(+ getconfig und anschließend wieder ein set).

Ich komme nicht weiter.

[frank]

ohne pairing wird das alles nichts. siehe wiki pairen.

Code Auswählen Erweitern

2016-02-04 16:03:10   PairedTo        0x000000

[FFHEM]

Tausend Dank, werde ich mir anschauen!

[FFHEM]

Habe im Pairing-Wiki und Foreneinträge nachgelesen.  Bei mir ist  irgendwie ein Mischmasch von 2 hmIDs in den Geräten:
meine FHEM-Installation ist schon 3 Jahre alt, habe aber immer die neueste FHEM-Version geupdatet.
Mir fällt auf, dass neuere Geräte - wie die Fensterkontakte und Thermostate - alle mit 0x000000 als FHEM-Zentrale gepairt sind (s. oben), ältere Geräte aber noch mit
"PairedTo 0xF11234". Das will ich jetzt aufräumen und eine neue hmID und alle Geräte neu pairen vergeben, aber das klappt nicht oder ich mache immer den gleichen Fehler.
Habe vor Erstellen der hmID mit bspw.

Code Auswählen Erweitern

set Melder_Arbeitszimmer_Tuer regSet pairCentral FF0430
ein Gerät auf die neue hmID FF0430 gesetzt:

Code Auswählen Erweitern

PairedTo
0x000000

R-pairCentral
set_0xFF0430
Der Set-Befehl kann aber trotz getconfig nicht abgearbeitet werden, ich sehe das Gerät immer noch, es müsste doch beim Schreiben der neuen Pairzentrale nicht mehr ansprechbar sein, oder?
Die Readings kommen auch noch alle durch, es ist so, als wäre nichts passiert 
Habe auch Werkseinstellung und ein neues Pairen mit neuer hmID und Neustart FHEM-Server versucht, kein Erfolg. Das Pairen greift nicht.
Hat noch einer eine Idee? Habe schon Kopfschmerzen..
Vielen Dank!

[martinp876]

Wenn 000000in den pairen steht ist es nicht gepairt.
Manchmal kann man das pairing Register setzen, eher selten. Am besten man pairt ganz normal, dann wird das Register gesetzt. Sollte das device schon gepairt sein ist es am einfachsten, es zu resetten.
Wenn nicht gepairt ist funktioniert das getconfig nicht.

[FFHEM]

Danke, Martin!
Ich habe > 35 Geräte.
Leider funktioniert bei mir das Pairing jetzt bei keinem Gerät mehr. Meine CUL_0-Definition in fhem.cfg sieht so aus:

Code Auswählen Erweitern


define CUL_0 CUL /dev/ttyACM0@9600 1234
attr CUL_0 hmId FF0430
attr CUL_0 rfmode HomeMatic
define hm HMinfo
attr hm room System
attr hm sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
attr hm sumStatus battery,sabotageError,powerError,motor
attr hm webCmd update:protoEvents short:rssi:peerXref:configCheck:models


Nach dem Rücksetzen z. B. eines Fensterkontakts auf Werkseinstellung (5 s Taster drücken -> rotes Blinken, nochmal 5 s Taster drücken) und starten des CUL_0-Pairings mit

Code Auswählen Erweitern

set CUL_0 hmPairForSec 180  und dann Drücken des Fensterkontakttasters klappt das Pairing nicht. Der Fensterkontakt blinkt einfach orange weiter und hört dann irgendwann auf.

Bei einer LED-16-Display-Anzeige ebenfalls nicht: Werkseinstellung durch 5 s Drücken mittlerer Taster auf Rückseite, blinkt rot, danach nochmal 5 s Drücken, blinkt kurz rot, dann 1 s rot.
Anlernen: CUL in Anlernmodus, Drücken des Tasters für 5 s: blinkt rot, aber es kommt kein Grün.
Es wird immer mysteriöser, es sieht so aus, als wenn ich noch nicht mal mehr die Werkseinstellung hinbekomme.

Um ein Gerät neu zu pairen, muss ich aus der fhem.cfg doch nicht die zugehörigen Einträge entfernen, oder?

[frank]

Um ein Gerät neu zu pairen, muss ich aus der fhem.cfg doch nicht die zugehörigen Einträge entfernen, oder?

nein.

wenn die geräte einen aes-key von dir bekommen haben, funktioniert reset nicht.
ansonnsten leere die cmd-queue mit clear msgEvents bevor du pairst. sniffe das pairen wie im wiki sniffen beschrieben, dann sieht man, was passiert.

[FFHEM]

wenn die geräte einen aes-key von dir bekommen haben, funktioniert reset nicht.
ansonnsten leere die cmd-queue mit clear msgEvents bevor du pairst. sniffe das pairen wie im wiki sniffen beschrieben, dann sieht man, was passiert.

Nein, habe noch nie einen AES-Key vergeben. clear MsgEvents probiere ich aus und dann sniffen.

Eine Frage vorweg: da ich eine neue hmId vergeben habe, warum kann ich denn noch alles sehen und bedienen?
Nach diesem Thread hier:
http://forum.fhem.de/index.php/topic,27444.15.html
müsste doch, sofort nachdem ich einen neue hmId vergeben habe, die Kommunikation zu den Geräten abbrechen, oder?
Es sieht so aus, als wenn der CUL die neue hmId noch gar nicht angenommen hat.

So sieht das Sniffen des Pairings aus, hmId ist FF3004 (alte hmId war F11234):
Melder_Arbeitszimmer_Tuer ist auf Werkseinstellung resetted worden (zumindest Versuch), dann Pairen mit CUL_0
Merkwürdig finde ich das "need Crypt::Rijndael to answer signing request with CUL".

Code Auswählen Erweitern


2016.02.05 10:16:12.376 4: CUL_Parse: CUL_0 A 14 95 A270 A64793 F11234 00CF3027FA0000006209C41C -60
2016.02.05 10:16:13.079 4: CUL_Parse: CUL_0 A 14 95 A270 A64793 F11234 00CF3027FA0000006209C41C -60
2016.02.05 10:16:13.782 4: CUL_Parse: CUL_0 A 14 95 A270 A64793 F11234 00CF3027FA0000006209C41C -60
2016.02.05 10:16:23.649 4: CUL_Parse: CUL_0 A 0D 00 8610 37B1A6 000000 060100002B -52.5
2016.02.05 10:16:23.751 4: CUL_send:  CUL_0As 09 02 A112 FF3004 37B1A6
2016.02.05 10:16:23.896 4: CUL_send:  CUL_0As 0C 04 A011 FF3004 20F767 800202
2016.02.05 10:16:24.053 4: CUL_Parse: CUL_0 A 0A 04 8002 20F767 FF3004 806C -20
2016.02.05 10:16:24.502 4: CUL_Parse: CUL_0 A 0F 3C 8610 44E8FD 000000 0AACCA90640034 -48
2016.02.05 10:16:25.871 4: CUL_Parse: CUL_0 A 0C 01 8641 37B1A6 000000 0101002C -52
2016.02.05 10:16:25.972 4: CUL_send:  CUL_0As 09 01 A112 FF3004 37B1A6
2016.02.05 10:16:26.135 4: CUL_send:  CUL_0As 0C 05 A011 FF3004 20F767 800202
2016.02.05 10:16:26.291 4: CUL_Parse: CUL_0 A 0A 05 8002 20F767 FF3004 806C -20
2016.02.05 10:16:32.505 4: CUL_Parse: CUL_0 A 1A 02 8400 37B1A6 000000 1000C74D4551303238353735388081010124 -56
2016.02.05 10:16:32.606 4: CUL_send:  CUL_0As 10 03 A001 FF3004 37B1A6 00050000000000
2016.02.05 10:16:32.805 4: CUL_Parse: CUL_0 A 11 03 A002 37B1A6 FF3004 04159F2B510A880025 -55.5
2016.02.05 10:16:32.809 1: CUL_HM Melder_Arbeitszimmer_Tuer need Crypt::Rijndael to answer signing request with CUL
2016.02.05 10:16:32.906 4: CUL_send:  CUL_0As 0A 03 8002 FF3004 37B1A6 00
2016.02.05 10:16:32.918 4: CUL_send:  CUL_0As 13 04 A001 FF3004 37B1A6 000802010AFF0B300C04
2016.02.05 10:16:38.715 4: CUL_Parse: CUL_0 A 14 ED 845E 370497 000000 80358B000000000008E3FE1D -59.5

[FFHEM]

Erster Erfolg!
Habe anhand des Logs libcrypt-rijndael-perl nachinstalliert.
Dann den Fensterkontakt noch mal auf Werkseinstellung, dann ein Pairing versucht, nach getconfig steht jetzt endlich:
Paired_to 0xFF0430 drin! (Die neue HM-ID)
Werde weitere Geräte neu pairen, melde mich wenn ok.
Danke vielmals! Ich hoffe, das war's.

[frank]

müsste doch, sofort nachdem ich einen neue hmId vergeben habe, die Kommunikation zu den Geräten abbrechen, oder?

würde ich so erwarten. eventuell hilft restart.
empfangen geht aber immer.

[FFHEM]

Hallo Frank und alle anderen,
habe mittlerweile einige der Geräte mit der neuen hmId gepairt, sieht alles prima aus. Dafür war jeweils - je nach Funkmodus - ein Rücksetzen auf Werkseinstellung notwendig.
Auch der opt. Fensterkontakt im Gäste-WC "schaltet" jetzt den Heizkörperthermostat bei offenem Fenster. Danke nochmal für den Hinweis auf das fehlende Pairing.

Im HT kommt jetzt auch

Code Auswählen Erweitern

STATE

last:Melder_Gaeste_WC:closed
an, endlich!

Im Melder_Gaeste_WC steht jetzt auch richtigerweise:

Code Auswählen Erweitern

RegL_04.HT_Gaeste_WC_WindowRec

01:80 00:00

Allerdings habe ich 2 Fragen.
1. Im Melder_Gaeste_WC kommen immer noch die beiden folgenden Readings vor, sind die ok, kann das mal jemand bestätigen?

Code Auswählen Erweitern

R-HT_Gaeste_WC_WindowRec-expectAES

on

2016-02-08 18:10:22
R-HT_Gaeste_WC_WindowRec-peerNeedsBurst

off
Muss ich da was ändern? Ich habe R-sign auf off gestellt, benutze kein AES.

2. Das Pairing hatte bei mir ursprünglich die hmId 0xF11234, damit sind einige Geräte gepairt, dann gibt es einige Geräte, die sind anscheinen gar nicht gepairt (0x000000) und einige sind jetzt mit neuer hmId gepair (0xFF0430). Nun das Lustige: ich kann jetzt immer noch alle Geräte sehen und bedienen! Wie ist das möglich? Ich habe das Wiki mehrfach durchgelesen, danach kann das nicht sein, und Frank hat das ja auch erwartet.
Lediglich das Peeren setzt ein vorhandenes Pairing voraus.
Ich hatte Pairing immer als Anlernen an die Zentrale verstanden - mit der eindeutigen hmId, aber da ich mittlerweile 3 hmIds in den Geräte verstreut habe und ich alle bedienen kann, verstehe ich es nicht mehr.

Wer hat eine Erklärung?

Vielen Dank!

[martinp876]

Wenn ein sco mit einem RT gepeert ist ohne AES sollte AES auf off stehen. Peerneedsburts muss an sein.

Wenn in den reedings die zentrale nicht angezeigt wird kann es daran liegen, dass kein getconfig gemacht wurde und die readings schlicht alt sind.
Wenn ein device nicht gepairt ist sind manche Kommandos dennoch möglich. Es hängt von device ab. Manches würde ich als bug der hmfw bezeichnen. Detailliert verfolge ich das nicht.
Versuche ein getconfig zu machen. Pairen wo es immer noch nicht gemacht ist. Sichere und lade die Registerreadings über hminfo archConfig loadConfig.

[FFHEM]

Danke für die Erklärung!
Gruß Friedhelm