HM-CC-RT-DN mit HM-SEC-SC2 RT-DN reaagiert nicht bei Fenster-offen

[hauwech]

Hallo zusammen,

ich habe die beiden Komponenten an den HM-LAN-CFG via fhem angelernt. Dann habe ich die Einstellungen wie im Wiki beschrieben gesetzt:

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single
set AnbauBadHZ_WindowRec regSet winOpnTemp 10 AnbauBadFenster
set AnbauBadHZ_Clima regSet winOpnMode off
set AnbauBadHZ regSet burstRx on
get AnbauBadHZ reg burstRx
attr AnbauBadFenster burstAccess 1_auto

AnbauBadFenster ist der HM-SEC-SC2 und AnbauBadHZ ist der HM-CC-RT-DN.

Der Fensterkontakt sendet zwar den Status open/closed an fhem, aber der Thermostat reagiert nicht. Er müßte doch die desired-temp auf 10 setzen und das Ventil umgehend schließen, oder?
Da passiert aber gar nix. Muß man da noch mehr machen? Etwa mit notifies wie wie hier: http://www.meintechblog.de/2014/01/fenster-und-balkontueren-zuverlaessig-mit-dem-homematic-funk-fenster-drehgriffkontakt-ueberwachen/ beschrieben? Das ist zwar ein RHS, aber von der Funktion her sind die beiden doch vergleichbar, oder?

Oder muß ich den Fensterkontakt direkt an den Thermostat anlernen? Das geht nicht mehr (Fehler F4), weil er schon mit einer Zentrale gepairt ist.
Kann mir jemand auf die Sprünge helfen, wo ich was checken muß? Die Werte für die obigen Kommandos sind, soweit ich das überschauen kann, auf den Devices und channels gesetzt.

Vielen Dank und Gruß
Roland

[martinp876]

Hallo Roland

prinzipiell ok.

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single
peert SC und RT.
Am SC anlernen druecken, sonst wird es nicht verarbeitet

Code Auswählen Erweitern

set AnbauBadHZ_WindowRec regSet winOpnTemp 10 AnbauBadFenster
set AnbauBadHZ_Clima regSet winOpnMode off
ist ok. Der RT muss die Kommandos noch verarbeiten, je nach mode. Koennte mehrere Minuten dauern. Es kann passieren, dass er nach dem ersten schreiben pausieren muss - dann dauert es max 10min.
=> Zustand des Protokols beachten ( kann man immer): ist etwas pending? Cmds done? HMInfo bietet m.E. eine komfortable sicht auf das gesamte System.

Code Auswählen Erweitern

set AnbauBadHZ regSet burstRx on
schaltest du erst jetzt ein. Da ist das Programmieren schon vorbei, dann wird der burst frei gegeben. Es wird dir beim naechsten mal helfen, diese show ist over.

Code Auswählen Erweitern

get AnbauBadHZ reg burstRx
was ist der Zweck? sofort nach dem absetzen des Kommandos ist da nicht viel zu sehen. Erst muss das Register im RT gesetzt werden. Wenn es mit wakeup passiert dauert es 3 min. Dann muessen die Register gelesen werden (getConfig). Passiert automatisch, aber es dauert ein wenig (resourcen schonend). Wenn dann alles fertig ist (HMInfo: keine Kommands pending, der RT nicht mehr in den Queues zur Configpruefung)macht das Komamndo sinn.

Code Auswählen Erweitern

attr AnbauBadFenster burstAccess 1_auto
auch hinterher? ok. Beim naechsten Mal dann.

Vorgehen (eine variante mit komfort)
- IMMER protokoll events im auge haben
- HMInfo fenster mit protoEvents short aufmachen
- HMInfo  set hm clear msgStat => loescht fehlerzaehler, macht den ueberblick einfacher
- HMInfo protoEvents => refresh: info cleared bei allen devices
- Konfiguration absetzen (register, was du willst
- HMInfo protoEvents => refresh : pruefen, was pending ist, wo fehler aufgetreten sind. Pruefen ob noch devices in den Queues stehen und die Config noch nicht wieder gelesen wurde

Frage: sind bei die Kommandos an beide Devices durch gegangen? fehler?
Gruss Martin

[hauwech]

Hallo Martin,

das Ganze ist schon ein paar Tage her. Ich hatte bisher aber am SC nicht auf Anlernen gedrückt. Den Satz im Wiki:
"Der Peer-(Lösch)Vorgang muss auf dem SC/RHS Sensor durch "drücken" der Anlerntaste bestätigt werden."
hatte ich so verstanden, daß das nur beim Löschen nötig ist. Ich habe vorhin eben nochmal

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single abgesetzt und auf Anlernen gedrückt. Der SC hat eine Weile orange geblinkt, dann mit rot quittiert. Ich habe nochmal gedrückt und wieder orange blinken und rot quittieren. Zwei oder drei Minuten später habe ich aus Jux nochmal auf Anlernen gedrückt, dann hat er mit grün quittiert.
Jetzt habe ich mal zum Test das Fenster geöffnet und im Event Monitor steht:

Code Auswählen Erweitern

Events:
2014-03-12 09:54:32 CUL_HM AnbauBadFenster open
2014-03-12 09:54:32 CUL_HM AnbauBadFenster contact: open (to AnbauBadHZ)
2014-03-12 09:54:32 CUL_HM AnbauBadHZ_WindowRec trig_AnbauBadFenster: open
2014-03-12 09:54:32 CUL_HM AnbauBadHZ_WindowRec trigLast: AnbauBadFenster :open
2014-03-12 09:54:33 CUL_HM AnbauBadFenster open
2014-03-12 09:54:33 CUL_HM AnbauBadFenster contact: open (to HMLAN1)
2014-03-12 09:54:33 CUL_HM AnbauBadHZ_WindowRec trig_AnbauBadFenster: open

Das heißt, daß der RT getriggert wurde. In meiner Übersicht sehe ich, daß die gewünschte Temperatur gesetzt und das Ventil geschlossen wurde.

Es lag also offenbar daran, daß ich nicht auf Anlernen gedrückt habe. Was mich jetzt noch irritiert, daß der Fensterkontakt direkt nach dem

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single nach dem Drücken auf Anlernen orange blinkt und mit rot quittiert. Erst beim dritten Drücken auf Anlernen hat der Fensterkontakt mit grün quittiert. Kann das sein, daß er die Pause braucht, bevor man auf Anlernen drückt?
Was die Reihenfolger der Kommandos angeht: Ich habe einfach Step by Step das Wiki abgearbeitet. Daß man mit

Code Auswählen Erweitern

set AnbauBadHZ regSet burstRx on den Burst Mode "für  die Zukunft" war mir soweit klar. Und das "get" danach hatte zeitlichen Abstand, ich habe das nur schlecht dargestellt.
Auf jeden Fall funktioniert es jetzt und ich werde mir HMInfo mal genauer anschauen, da steckt 'ne Menge drin wie es aussieht.
Danke für die Hinweise.

Gruß Roland

[martinp876]

"Der Peer-(Lösch)Vorgang muss auf dem SC/RHS Sensor durch "drücken" der Anlerntaste bestätigt werden."

das ist zumindest nicht sauber ausgedrueckt.
jedes Kommando an ein config-only device muss durch ein Anlernen(config taste) gestartet werden.
ein SC/RHS ist ein device, das gerne und viel schlaeft. Man kann nur mit ihm reden, wenn es aufwacht - und dazu ist die Configtaste zu druecken. Wenn es zum Fenster-oeffnen aufwacht reicht das (leider) nicht.
So man einen reboot zwischendurch macht sind die Kommandos natuerlich verloren.

immer wichtig: Protokoll im Auge behalten - da faellt so etwas auf. Again: HMInfo screen.

abgesetzt und auf Anlernen gedrückt. Der SC hat eine Weile orange geblinkt, dann mit rot quittiert.

ggf rohmessages aufzeichnen. so kann ich nichts sagen.

Kann das sein, daß er die Pause braucht, bevor man auf Anlernen drückt?

nein

Ich habe einfach Step by Step das Wiki abgearbeitet.

schlechte Anleitung.
a) durch das peeren sollte der RT automatisch in burst gesetzt werden (muss ich noch einmal checken - also hoffenltich ist das so)
b) burst sollte, so man es haben will (beim SC/RHS braucht man es) als erstes setzen. Insbesonderen wenn man mit "attr AnbauBadFenster burstAccess 1_auto" eine sofortige Bearbeitung der Kommandos erreichen will.
=> bust mode einschalten sollte ein eigener schritt sein
=> immer wieder wird vergessen auf die Kontrolle der Verarbeitung hinzuweisen. Es gibt genug Hilfsmittel. Die uebersichtlichsten fuer Anfaenger (auch fuer mich) sind HMInfo mit 'loesche alle protokoll-events" und "zeige den kompletten protokoll-status" - und nachher ein config check. Optional saveConfig und die archive funktion.

Wer alles in den unuebersichtlichen variablenlisten nachsehen will ist selbst schuld. Wer garnicht nachsieht noch mehr.

Gruss Martin

[betateilchen]

jedes Kommando an ein config-only device muss durch ein Anlernen(config taste) gestartet werden.
...
Wenn es zum Fenster-oeffnen aufwacht reicht das (leider) nicht.

Aber bei seiner regelmäßigen Statusmeldung ist es wach genug, um auch ohne Anlerntaste Befehle entgegenzunehmen

[martinp876]

hast wieder einmal recht. Das ist ein config und wakeup device.
Kann man in HMInfo "models" nachsehen, was das Device fuer modes unterstuetzt.

In diesem Fall bedeuted es (vielleicht nicht allen klar)
- kommando absetzen (auch mehrere meoglich)
- warten bis der RHS/SC aufwacht (taeglich ein mal) und arbeiten lassen
- danach (evtl. naechter Tag) pruefen, obs geklappt hat. Koennte sein, dass es noch einmal wiederholt wird - also am naechsten Tag... => siehe protoEvents
- kein reboot/reread,... zwischen rein machen! das loescht pending kommandos.

Wer also etwas aus der Ferne machen will hat eine Chance
wer genug Zeit hat auch.
Generall verlangt die lange Wartezeit deutlich mehr kontrolle des User!

[betateilchen]

In diesem Fall bedeuted es (vielleicht nicht allen klar)
- kommando absetzen (auch mehrere meoglich)
- warten bis der RHS/SC aufwacht (taeglich ein mal) und arbeiten lassen

Das ist auch genau die Verfahrensweise, wie auch die Homematic CCU arbeitet, wenn ich beim Absetzen eines Befehls die zugehörige "Fehler"-Meldung bekomme und dann auf "Ignorieren" klicke (was ich höchst unlogisch, zumindest aber verwirrend beschrieben finde)

[martinp876]

danke, hatte ich nicht gewusst von der CCU - hat mich zumindest "verwirrt". So eine schlechte Meldung hatte ich von HM nicht erwartet.

[betateilchen]

naja, man muss die Meldung mindestens dreimal lesen, um zu kapieren, dass sich "Ignorieren" nicht auf die beabsichtigte Änderung selbst bezieht, sondern auf die ausgegebene Meldung 

Danach sind die zur Übertragung anstehenden Daten in den Servicemeldungen und am Blinken der Service-LED an der CCU2 zu erkennen.