[Gelöst] Peering Fensterkontakt SCo an Thermostat RT funktioniert nicht

yersinia · 04 November 2017, 14:22:02

Hallo zusammen,

vorneweg: ich habe gerade mit FHEM angefangen und bin noch ziemlich neu.
FHEM ist aktuell (letztes Update heute) und läuft auf einem RPi 3 Model B. Dran ist ein nanoCUL 868 (CUL_HM).

Ich habe angefangen, sechs Thermostate HM-CC-RT-DN anzubauen, zu pairen und zu konfigurieren (Temperaturlisten eingestellt via FHEM) - dies hat soweit auch funktioniert. Die Hmid erscheint bei PairedTo sowie R-pairCentral.
Nach einiger Mühe habe ich es auch geschafft den ersten fensterkontakt HM-SEC-SCo zu pairen - die Hmid erscheint bei PairedTo sowie R-pairCentral. (Mit Hilfe aus dem Forum: https://forum.fhem.de/index.php?topic=59746.0) Ich kann auch den state (open oder closed) sehen.

Allerdings gelingt es mir nicht den Fensterkontakt mit dem Thermostat so zu peeren, dass die Temperatur automatisch runtergeregelt wird wenn der Fensterkontakt state open ist.

Zum Peeren bin ich nach dieser Anleitung vorgegangen: https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Channel_.28Kanal.29_03_WindowRec

Code Auswählen

set HM_123ABC peerChan 0 HM_DEF456_WindowRec single set
set HM_DEF456_WindowRec getConfig
set HM_DEF456_WindowRec regSet winOpnTemp 16 HM_123ABC
set HM_123ABC regSet peerNeedsBurst on DEF456_WindowRec

Im Kanal _WindowRec sehe ich iin den Internals aber auch in den Reading unter peerList den Namen des Fensterkontakts (HM_######) allerdings ist das Reading state unknown; somit ist das Internal STATE last:trigLast.
Der Fensterkontakt gibt aber als state bzw. STATE den entsprechenden Wert open/closed an.

Die Einsteiger-PDF habe ich überflogen aber auch bezgl des Peerings (Seite 73ff) schon durch. Aber langsam bin ich mit meinem Latein am Ende - und G00gle mag auch nichts mehr sinnvolles ausspucken.
Beim Schreiben fiel mir noch ein, dass im Wiki

Zitat<fensterSensor> [ist] die FHEM-Kanalbezeichnung für den Fensterkontakt

steht. Sollte dann der Peering code für <fensterSensor> anstelle des Namens HM_123ABC nur die Id des Fensterkontakts plus Kanal beinhalten, also: 123ABC01 (für den ersten Kanal)?
In etwa so:

Code Auswählen

set 123ABC01 peerChan 0 HM_DEF456_WindowRec single set

Für weitere Infos einfach fragen - ich hab sicherlich etwas vergessen.

Danke schon einmal.

CBSnake · 04 November 2017, 14:27:05

Hi,

der Fensterkontakt muss um neue "Infos" von der Zentrale auch zu bekommen, in deinem Fall das Peering, durch drücken der Anlerntaste dazu "aufgefordert" werden diese "abzurufen", drück die doch mal und evtl ein paar minuten später nochmal

stehen noch cmd_pending im Fensterkontaktdevice?

Grüße
Achim

Pfriemler · 04 November 2017, 15:07:19

Das mit der HMID + Kanal ist eigentlich der Holzweg. Du gehst aber ohnehin richtig, wenn Du peerChan aus der Definition des Fensterkontakts aufrufst. Und wie erwähnt zeitnah s Knöbbl drücken und das Blinken beobachten.

yersinia · 05 November 2017, 13:46:29

Vielen Dank für die antworten Achim und Pfriemler,

also ich habe das jetzt mehrfach probiert - erst den Knopf drücken und dann den Befehl senden und andersrum. Das Ergebnis bleibt unverändert. Manchmal blinkt der Fensterkontakt langsam grün/rot (= orange?) nach dem Drücken des Anlernknopfes und quittiert dann mit grün oder auch gar nicht (dann versuche ich es nochmal). Laut protState sind CMDs_done. Manchmal mit Error, manchmal ohne.
Nachdem ich den Befehl

Code Auswählen

set HM_123ABC peerChan 0 HM_DEF456_WindowRec single set
gesendet habe (wie gesagt: einmal Knöpfchen vorher, dann Knöpfchen nachher - in allen Kombinationsmöglichkeiten), war das Internals STATE immer Nack. Nach dem Auslösen des Fensterkontaktes war es dann entsprechend open/closed.
Ich weiß auch nicht, was ich von dem Reading CommandAccepeted = no halten soll.

Muss ich am Thermostat noch was drücken um das Peering von dort aus zu Quittieren?
Das Reading state des _WindowRec unterhalb vom peerList ist immernoch unknown - und der STATE der Internals last:trigLast.

Übrigens: der Fensterkontakt ist gut 1m (zum Testen) vom CUL weg und der Thermostat ca 10m - beide mit freier Sicht zum CUL.

Btw: Gott ist das ein Krampf mit reCAPTCHA hier. -.-

Edit hat noch herausgefunden:
ich habe den Befehl

Code Auswählen

set HM_123ABC peerChan 0 HM_DEF456_WindowRec single set
nochmals abgesetzt und bekomme jetzt vom Fensterkontakt den STATE MISSING ACK.
Zudem weiss ich auch nicht, was ich von dem Reading aesCommToDev = fail halten soll.

VG
yersinia

linuxpaul · 05 November 2017, 15:51:37

sicher dass der HM-SEC-SCo richtig gepaired ist?

Zitatnochmals abgesetzt und bekomme jetzt vom Fensterkontakt den STATE MISSING ACK.
Zudem weiss ich auch nicht, was ich von dem Reading aesCommToDev = fail halten soll.

Schaut für mich ehr nach nein aus. Was hat du bei Contact open/close ? to broadcast?
Aber dazu gibt es hier schon etliche posts.

linuxpaul

martinp876 · 05 November 2017, 18:24:23

Wie schon (immer) beschrieben: erst einmal pairen und das prüfen.
Zu beachten sind die Kommunikationsoptionen eines Device.
- always: lasse sich immer ansprechen. Nur beim Pairen muss man den Knopf drücken (meist) um die korrekte Zuordnung zu erhalten und den Nachbarn das übernehmen des Device zu erschweren
- wakeup: Devices mit batterie sparen strom Devices welche regelmäsig senden ( der RT bspw) reagieren beim Aufwachen. Das kann bis zu 3 min dauern. Falls FHEM etwas wieserholen muss noch einmal 3 min
- burst: Devices mit Batterie welch man aufwecken kann. Die also einen plotzlichen Trigger bekömmen können
- conditional burst: (auch RT - bspw trigger von SCO...). Den burst mode muss man freischalten - kostet Batterie, ist aber bei Nutzung des SCO notwendig. FHEM setzt das bem peeren automatisch
- config: Das konnen ALLE devices. Nach drücken der Config Taste kann man kommunizeiren Batteriedevices welche kein Burst oder wakeup unterstützen fallen darunter - also auch SCO
- lazy config: wieoben allerdings kann man mit den Devices reden, wenn sie korrekt gepeert (nicht gepairt, gepeert!) sind und zufällig einen trigger senden.

Also teste erst einmal dass der RT korrekt eingebunden ist. Pairing ok. Temp kann von FHEM aus eingestellt werden,...
Dann der SCO. Pairen, config lesen. wenn das klappt bist du im Geschäft.

nun peeren wie du beschrieben hast. Es wird nun das peering auf beiden Devices eingetragen. Wieder ist der Kommunikationsmode wichtig. Der RT wird es übernehmen wenn er aufwacht oder du config drückst oder du burst aktivierst.
Der SCo wird es übernehmen wenn du config drückst oder den Kontakt bewegst ( kann er lazyConfig?)

Dass alles korrekt ist sagen dir die Protokoll Informationen (basis Wissen für FHEM).
Am Übersichtlichsten mit HMinfo

Code Auswählen

define hm HMInfo
get hm protoEvents

es sollten keine Fehleraufgetreten sein - und keine Kommandos Pendig sein. Dann ist alles ok.
Da alle Fehler akumuliert werden solltest du es gelegentlich löschen um deine letzten Aktionen überwachen zu können

Code Auswählen

set hm clearG msgEvents

Wenn dann alles da ist noch ein

Code Auswählen

get hm configCheck

yersinia · 05 November 2017, 20:42:07

Danke für die Antworten linuxpaul und martinp876.

Nein, der HM-SEC-SCo sendet (to VCCU). Ich erinner mich, dass dieser (to broadcast) hatte als dieser noch nicht gepaired gewesen ist.

Ok, der RT scheint korrekt eingebunden zu sein: R-pairCentral und PairedTo zeigen meine Hmid: 0x123456 (ohne set davor). Temperatur konnte ich auch ändern - desired Temperatur, gesetzt, Sichtprüfung: ok. Wie gesagt, Temperaturtabellen einstellen und ändern ging ohne Probleme.
Der SCo ist auch gepaired - analog zum RT sind die beiden Readings gesetzt. Dies war zwar ein Krampf (Hilfe durch Forum), aber FHEM zeigt es richtig an. Ich hab aber mittlerweile herausgefunden, dass für jeden CMD man beim SCo der Anlernknopf gedrückt werden muss (dann blinkt die LED schnell grün/rot (orange) und quittiert grün.
Nach dem Absetzen des Peering-Befehls blinkt der SCo langsam grün/rot (orange) und hört nach einer gewissen Zeit einfach auf (keine Quittierung mit rot oder grün)

HMInfo war ein guter Tipp. Für den SCo habe ich folgendes Resultat. Der scheint das Peering nicht zu akzeptieren:

Code Auswählen


name                  :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
[SCo_Name]            : done_Errors:1  |  -       | 4:       | 1:       # 7        |  -       | 1:       |  -

Der config check gibt mir nur folgendes (in Bezug auf den SCo) aus:

Code Auswählen


peer not verified. Check that peer is set on both sides
    [RT_WindowRec] p:[SCo]

Liegt es ggf. an einer -wohlmöglich nicht vorhandenen- AES Verschlüsselung?
Im SCo gibt es noch folgende Readings:

Code Auswählen

R-[RT]_WindowRec-expectAES = set_off
R-[RT]_WindowRec-peerNeedsBurst = set_on
aesCommToDev = fail

Ich hatte das Rijndael-Modul installiert nachdem ich den RT und bevor ich den SCo gepaired hatte. Möglicherweise hängt dies damit zusammen...

Den Burst müsste ich im RT mit

Code Auswählen

set [SCo] regSet peerNeedsBurst on [RT]_WindowRec
aktiviert haben.

Nach einer Weile hat es dann doch noch geklappt - ein wildes drücken zwischen SCo und Befehle absetzen. irgendwann wird das grün/rote Blinken rot quittiert. Dann ging es. Im SCo ist das Reading für die peerList nun der RT im RT_WindowRec sehe ich auch den State. Aber WIE ich das geschafft habe...keine Ahnung. -.-

Wichtig fand ich diesen Hinweis in diesem Wiki welcher beim RT Wiki Eintrag fehlt:
https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt#Hinweise_zum_Peeren_mit_HM-CC-TC

Danke für die Hilfe nochmals!