Drehgriffkontakte unzuverlässig?

[AlphaZulu]

Hallo zusammen,

ich habe hier inzwischen 7 Fenster-Drehgriffkontakte im Einsatz. Letztlich sollen diese zum einen auf einem Display an der Haustür anzeigen, ob und welche Fenster geöffnet oder gekippt sind, und später zum anderen dafür sorgen, dass bei geöffneter Terrassentür nicht die Rollade herunterfährt.

Aber leider stelle ich immer wieder fest, dass der Zustand der Fenster und der Status in der WebUI nicht übereinstimmen. Gerade war zum Beispiel angeblich das Fenster im Gäste-WC geöffnet, aber es war definitiv zu. Ein erneutes Öffnen und Schließen korrigierte die Darstellung. Es wird aber jedes mal grün bestätigt, wenn etwas geändert wurde. Ich habe sogar die Reaktionszeit auf 3 Sekunden hochgesetzt, weil ich irgendwo gelesen hatte, dass es Probleme geben kann, wenn ein Fenster von geschlossen (über geöffnet) zu gekippt eingestellt wird und der Sensor alle Zustände melden will, so dass es dadurch zu Falschmeldungen kommt.

Da ich neben der CCU2 auch 3 LAN-Adapter im Einsatz habe, habe ich zudem schon versucht, bei den Fenster-Drehgriff-Kontakten das Roaming abzuschalten und diese fest auf die CCU2 einzustellen, soweit das von der Sendestärke machbar war. Allerdings hat das keinerlei Unterschied gemacht.

Spätestens bei Einbindung der Rolladen in HomeMatic habe ich ein Problem, wenn die CCU2 nicht weiß, dass die Terrassentür geöffnet ist und daher die Rollade herunterfährt. Na ja, ein angeblich geschlossenes Fenster, das jedem Einbrecher dann weit offenstehend einlädt, ist sogar ein noch größeres Problem.

Gibt es da ein Grundproblem oder habe ich einen Denkfehler.

Scriptende Grüße

Axel

[Familienvater]

Hi,

es kennt keiner Deine genauen Sende-/Empfangsbedingungen, meine Drehgriffe sind eigentlich ziemlich zuverlässig, und ich habe vielleicht ein mal im Monat einen falschen Status, bei 6 Drehgriffen. Das größte Problem ist ein Neustart der CCU bei geöffneten Fenstern/Türen, dann stimmt der Status nicht, weil die CCU das grundsätzlich als geschlossen annimmt, bis sie eines besseren belehrt wird.

Sende-Verzögerung hast Du schon eingebaut, dann bleibt z.B. noch das Abschalten der verschlüsselten Übertragung für die Drehgriffe. Da Du die Drehgriffe wohl in WebUI Programmen benutzt, müssten die eigentlich auf die Quittung bei einer Statusänderung von der CCU warten, und es je nach Konfig-Einstellung auch mehrfach probieren, den Zustand zu übermitteln. (Ansonsten ein Dummy-Programm anlegen, was die Drehgriffe nutzt, und dann das Programm deaktivieren, damit will der Drehgriff dann eine Quittung von der CCU).

Der Familienvater

[ChristianF]

Es wurde andernorts mal dazu geraten die Schrauben der Fenstergriffe nicht so stark anzuknallen. Vielleicht ist das auch ein Problem.

[Herbert_Testmann]

Hallo

eigentlich sollte es Servicemeldungen geben, wenn die Kommunikation mal gestört ist. Sobald die LED grün leuchtet, sollte der Status in der CCU auch stimmen, denn es wurde ja eine Quittung empfangen. Das dann der Status in der WebUi nicht stimmt ist sehr ungewöhnlich.

ich hatte auch Probleme mit Drehgriffsensoren. Bei mir hat das Abschalten der gesicherten Übertragung eine Verbesserung gebracht.

[Challenger]

Unzuverlässig?!
Das kann ich bestätigen.

Ich habe 2 Griffe im Einsatz, dort ist die Fehlerquote bei ca 25%.
Das finde ich für den Preis der Geräte sehr enttäuschend.

Beispiel: Ich öffne die Terrassentür indem ich den Griff zügig von "zu" über "offen" nach "gekippt" stelle - das funktioniert noch.
Aber bei jedem 4 mal Schließen, d.h. von "gekippt" über "offen" auf "zu" registriert der Kontakt die Bewegung nicht.
Dann kann man zudem keinen Statuswechsel am Türgriffkontakt direkt erkennen, d.h. die LED leuchtet nicht
oder sie wechselt von grün auf rot, d.h. Statuswechsel fehlerhaft.

Dann bleibt nur die Möglichkeit den Griff laaaangsam zu bewegen, damit die Drehbewegung erkannt wird.
Diese Art der Nutzung hat nichts mit normalem Nutzerverhalten zu tun.

Habe die beiden Türgriffkontakte mehrfach demontiert, mit weniger Druck verschraubt - bringt alles nichts.

Ich denke hier muss dringend ein Firmwareupdate her!


UPDATE:
Habe grad im o.a. Threat gelesen, eine Änderung der Sendeverzögerung von 0.0 (Default) auf 3.0 kann hier helfen - das teste ich jetzt mal.
Danke.

[AlphaZulu]

Das hat bei mir definitiv geholfen, was das "nicht mitbekommen" von Drehgriffstellungen anging, allerdings hatte es keinen Einfluss auf das aktuelle Problem, dass der Zustand nicht sicher erkannt wird. Wenn es wenigstens Kommunikationsprobleme geben würde, aber da wird nichts angezeigt:

Griff drehen, LED signalisiert gelb, dann grün -> Ergebnis im Logfile: Manchmal gar keins .

[Herbert_Testmann]

Hallo

auch ich habe eine Verzögerung von 2...3 sec eingebaut. Wenn der Drehgriff die Endlage erreicht hat, wird erst die zeit abgewartet und dann gesendet. Das Vermeidet in jedem fall das Senden der Zwischenstellung.

Nachteil ... wird damit der Rollladen gesteuert, startet er auch erst 3 sec nachdem die Tür geöffnet wurde. Das muss man einfach wissen und warten.

[ChristianF]

Gibt es eine Möglichkeit, diese Änderungen (Zeit und gesicherte Übertragung deaktivieren) automatisch für alle an der CCU bekannten RHS zu machen? In meinem Fall wären das fast 20...

Viele Grüße,
Christian

[Familienvater]

Hi,

nicht mit normalen Mitteln. Evtl. ginge das mit dem Homematic-Manager von Hobbyquaker, aber selbst da müsstest Du zu jedem Drehgriff laufen, und das Anlernknöpfchen drücken, um die Konfig zu übernehmen.

STOP: Mir fällt setParam.tcl ein, bin mir aber nicht sicher, ob das Parameter sind, die damit gesetzt werden könnten, dann bräuchtest Du nur noch schnell ein Shell-Script zusammenkopieren, das die Seriennummern der Geräte kennt.

Geht, habe gerade mal einen RHS von mir befragt:

Code: Alles auswählen

tclsh getParam.tcl KEQ0846912:1 MASTER
AES_ACTIVE 0 EVENT_DELAYTIME 1.000000 LED_ONTIME 0.010000 MSG_FOR_POS_A 1 MSG_FOR_POS_B 2 MSG_FOR_POS_C 3 TRANSMIT_TRY_MAX 8

Man müsste entsprechend mit setParam AES_ACTIVE und die EVENT_DELAYTIME setzen können, so in dieser Art, bin mir aber mit :1 und den Datentypen nicht wirklich sicher

Code: Alles auswählen

tclsh setParam.tcl KEQ0846912:1 AES_ACTIVE boolean 0 EVENT_DELAYTIME string?????? 1.000000

Sicher ist wie gesagt, das danach bei jedem Aktor der Anlernknopf betätigt werden muss, LazyConfig unterstützen die AFAIK nicht, und natürlich musst Du entsprechend die beiden tcl-Scripte auf die CCU schaffen, die sind nicht per Default vorhanden.

Der Familienvater

[dtp]

Also ich habe insgesamt 10 Fenster-Drehgriffkontakte seit nunmehr etwas über drei Jahren im Einsatz. Sie sind über vier Stockwerke im Haus verteilt. Fünf von Ihnen kommunizieren über ein LAN-Gateway mit der CCU2, der Rest direkt.

Die meisten meiner Fenster-Drehgriffkontakte funktionieren absolut fehlerlos. Bei einigen kommt es hin und wieder vor, dass sie regelmäßig gestörte Kommunikationsmeldungen erzeugen. Dann hilft es, die zyklische Datenübertragung auszuschalten und sie anschließend wieder einzuschalten.

Die Zustände der Drehgriffe werden in der Regel sehr zuverlässig angezeigt. Ein grüne Quittierungs-LED führt eigentlich immer dazu, dass die CCU2 den Zustand korrekt übernommen hat. Meistens wird der Zustand auch bei einer roten Quittierungs-LED korrekt übernommen.

Entscheidend für ein gutes Funktionieren sind potente Knopfzellen. Da ist die Streuung durchaus recht groß. Ein Wechsel der Knopfzellen war meiner Erinnerung nach bereits bei sämtlichen Fenster-Drehgriffkontakten notwendig. Einige haben bereits ihren dritten Batteriewechsel hinter sich. Das hängt dann logischerweise von der Betätigungshäufigkeit ab. Unsere Terrassentüren werden z.B. im Schnitt ca. 10 bis 15 Mal am Tag geöffnet und geschlossen bzw. auf Kipp gestellt. Unser Kellerfenster steht dagegen oftmals mehrere Tage am Stück auf Kipp. Um den Batterieverbrauch so gering wie möglich zu halten, aber gleichzeitig eine rasche Meldung von Zustandsänderungen zu gewährleisten, habe ich die Verzögerung auf eine Sekunde eingestellt. Das funktioniert soweit sehr gut, und es werden nicht unnötige Zustandswechsel (z.B. von Kipp über offen nach geschlossen und umgekehrt) gemeldet. Die Übertragung steht übrigens überall auf Standard.

Sehr gute Erfahrungen habe ich übrigens mit den Hoppe London Griffen gemacht. Wir nutzen diese im Haus zum Einen mit Druckknöpfen zur Entriegelung und zum Anderen mit Schlössern. Da die Griffe über eine feste Stahlplatte im Fuß verfügen, kann man sie in Verbindung mit den Fenster-Drehgriffkontakten sehr fest anziehen, ohne dass die Funktionsfähigkeit der Fenster-Drehgriffkontakte auch nur im Geringsten leidet. Mit anderen Fenstergriffen hatte ich da deutlich schlechtere Erfahrungen machen dürfen. Wenn es hier aber Probleme gibt, wird Einem der Zustandswechsel erst gar nicht über die LED angezeigt. Somit kann man das recht gut erkennen.

Insgesamt bin ich mit den Fenster-Drehgriffkontakten recht zufrieden, auch wenn mich der eine oder andere nach einem Batteriewechsel schon mal den letzten Nerv gekostet hat. Da war es dann z.B. nötig, ihn komplett zurückzusetzen und neu an die CCU2 anzulernen. Danach tat er dann aber wieder seinen Dienst. Noch sensibler in diese Richtung sind aus meiner Erfahrung die Tür-/Fensterkontakte.

Übrigens sind fast alle meine Fenster-Drehgriffkontakte direkt mit entsprechenden Wand- und/oder Heizkörperthermostaten verbunden. Über die Direktverknüpfungen werden die Zustandswechsel der Fenster und Türen sehr zuverlässig erkannt.

Bis dann,

Thorsten