Drehgriffkontakte unzuverlässig?

[dtp]

Sicher ist wie gesagt, das danach bei jedem Aktor der Anlernknopf betätigt werden muss...

Aus diesem Grund würde ich die Umstellung auch bei jedem Fenster-Drehgriffkontakt händisch im WebUI vornehmen. So groß ist der Aufwand ja auch bei 20 Kontakten nicht unbedingt.

Bis dann,

Thorsten

[Roland M.]

Hallo!

Sicher ist wie gesagt, das danach bei jedem Aktor der Anlernknopf betätigt werden muss, LazyConfig unterstützen die AFAIK nicht,

Doch, hab selbst gerade zwei DGK umkonfiguriert.
Einmal Griff betätigt, Servicemeldung "Konfigurationsdaten stehen zur Übertragung an" weg.


Roland

[AlphaZulu]

Mal geht es, mal nicht. Ich habe jetzt bei allen Drehgriffkontakten die gesicherte Übertragung rausgenommen. Bei drei Fenstern muss ich wohl die Anlerntaste drücken, weil die sich nicht durch eine Griffdrehung die neuen Einstellungen holen. Alle anderen haben das gemacht.

hat jemand eine Idee, woran das liegt? (Es kann übrigens nicht an den LAN-Adaptern liegen, denn einer der hartnäckigen Kontakte hängt direkt an der CCU2.)

Scriptende Grüße

Axel

[Roland M.]

Hallo Axel!

hat jemand eine Idee, woran das liegt?

Keine Ahnung, vielleicht Firmware?
Meine haben zumindest FW 2.0 und 2.4.


Roland

[Herbert_Testmann]

Hallo

ich könnte jetzt noch den Tip geben, ein kleines Loch in das Gehäuse zu bohren und den Antennendraht in grader Linie nach draussen zu legen, anstatt im Gehäuse aufzuwickeln. Das kann aber optisch nicht gewollt sein, da dann ein schwarzer Draht da rum hängt.

Ausserdem schreibst Du ja, die LED quittiert immer mit grün. Dann liegt es offenbar nicht an der schlechten Funkverbindung

Hast Du den Kontakt mal auf Protokolliert gestellt? Steht im System Log File auch der falsche Zustand, oder ist es nur ein grafisches Problem der CCU.

[AlphaZulu]

Es wird alles fröhlich protokolliert, aber nicht immer! Wenn die CCU2 meint, dass das Fenster geöffnet ist (obwohl es das schon lange nicht mehr ist und der Drehgriffkontakt auch brav grün geleuchtet hat, als das Fenster geschlossen wurde), dann ist auch kein Eintrag im Log, dass geschlossen wurde. Öffne ich erneut und schließe dann, springt in der Regel auch die Darstellung in der CCU2 um und es wird ein Logeintrag generiert.

[AlphaZulu]

Hallo Roland,

alle Drehgriffkontakte haben die Firmware 2.4. - Daran kann es also nicht liegen.

Scriptende Grüße

Axel

[Familienvater]

Hi,

wenn er grün meldet, und die CCU empfängt nichts, würde ich tendenziell das Gerät mit Löschen/Werkszustand ablernen und neu anlernen. Bei mir kein Problem, da ich bei mir dann nicht x-Programme neu machen müsste.

Versuche mal, ein neues einfaches Programm mit diesem Drehgriff zu erstellen, wo Du auf jeden der möglichen Stati mit auf Änderung triggerst (wenn drehgriff offen oder wenn Drehgriff gekippt oder wenn Drehgriff verriegelt dann drücke virtuelle Taste x).
Das Programm kannst/solltest Du nach dem Erstellen aber auf Inaktiv setzen. Jetzt sollte eigentlich eine Konfigurationsänderung an den Drehgriff zur Übertragung anstehen, und der Drehgriff müsste jede Änderung am Status nicht nur der CCU mitteilen, sondern auch auf die Quittung warten, und darf eigentlich erst dann auf grün umspringen. Wenn das danach zuverlässiger funktionieren sollte, und Du löscht das Dummy-Programm dann wieder, müsste wahrscheinlich auch wieder eine Konfig-Änderung an den Drehgriff gehen, und er fällt wahrscheinlich in sein altes Muster zurück, dann hilft ggf. nur, die Programme, in denen der Drehgriff genutzt wird, neu zu erstellen.
Evtl. funktioniert auch eine erneute Übertragung der Config-Daten an den Drehgriff (über die Dev-Config-Seite).

Du kannst auch mal per Konsole oder in einem Backup der CCU2 (die sbk-Datei mit 7zip öffnen, und dann ins usr_local.tar.gz eintauchen) im Ordner /usr/local/etc/config/rfd/SERIENNUMMER.dev schauen, dort müsste eigentlich so etwas wie das hier drin stehen:

Code: Alles auswählen

<device serial="KEQ0847xxx" type="HM-Sec-RHS" address="0x238xyz" aes_key_index="0" firmware_version="2.1" bidcos_interface="MEQ0006abc" roaming="true" sysinfo="00001234...langeZahlenkette">
	<config>
		<list index="0">
			<chunk address="0x00" dev_dirty="0" file_dirty="0" used="111E05" must_be_read="false" data="00000100000000000001164xyz000000000000000A"/>
		</list>
	</config>
	<channel index="0" type="MAINTENANCE"/>
	<channel index="1" type="ROTARY_HANDLE_SENSOR" aes="false">
		<config>
			<list index="1">
				<chunk address="0x00" dev_dirty="0" file_dirty="0" used="101" must_be_read="false" data="000000000000000000"/>
				<chunk address="0x20" dev_dirty="0" file_dirty="0" used="10007" must_be_read="false" data="6C0102000000000000000000000000000A"/>
			</list>
		</config>
		<peer address="0x164xyz" channel="63" link_name="">
			<description>
			</description>
			<config>
				<list index="4">
					<chunk address="0x00" dev_dirty="0" file_dirty="0" used="3" must_be_read="false" data="0000"/>
				</list>
			</config>
		</peer>
		<values/>
		<value_usage id="STATE" refcount="2"/>
	</channel>
	<values/>
</device>

Glaskugel AN (ich kann nur anhand der Struktur und der Namen Rückschlüsse ziehen):
Wenn Du den channel="63"-Eintrag hast, und der value_usage id="STATE" refcount="2" da ist (die 2 gibt die Anzahl an, wie oft der STATE verwendet wird, bei mir jetzt 2), dann sollte sich der Drehgriff nach meinem Verständnis auf jeden Fall per Handshake mit der Zentrale unterhalten. Falls Du Direktverknüpfungen mit anderen Geräten angelegt hast, dann müssten die da auch auftauchen, aber keine Ahnung, wie das dann aussehen könnte.

Der Familienvater

[funkleuchtturm]

Ich hatte ebenfalls Zuverlässigkeitsprobleme, obwohl sende/empfangsseitig sehr gute Bedingungen da sind. Dann habe ich mir das Ding genauer angesehen. In der Drehgriffmanschette ist ein Drehmagnetmagnet, dessen Feld ausgewertet wird. Probleme entstehen offensichtlich besonders dann, wenn der metallische Fensterrahmenkern meines Kunststofffensters sehr nah an der Oberfläche ist, also die Überdeckungsdicke des Kunststoff sehr klein ist. In diesem Fall wird vermutlich das Magnetfeld des Drehsensors stark abgelenkt und es entsteht eine unzuverlässige Signalerkennung.

Nachdem ich eine dünne Pertinaxscheibe (1,6mm) zugeschnitten und unterlegt habe , ist die Zuverlässigkeit erheblich besser. Zwar habe ich das beschriebene Problem immer noch alle paar Wochen, aber es ist eben spürbar besser geworden.
Man müßte vermutlich eine noch dickere Scheibe unterlegen, aber das sieht dann schrecklich aus!

... ich denke , dieses Problem haben nur die Kunststofffenster mit Metallkern.

[Herbert_Testmann]

Hallo

wirklich nicht einfach das Problem.
Gibt es ausser der CCU noch weitere direkt verbundene Partner? Heizung?
Die grüne Quittung könnte von der Übertragung zum Heizungsthermostat kommen. Allerdings dürfte ohne Quittung der CCU ja nur Orange erscheinen. Oder der Drehgriff hat einfach "vergessen" , dass er auch an die CCU melden muss.

Wenn Direktverknüpfungen da sind, Ist der Status an den Heizungsreglern denn immer richtig?