HomeMatic-Forum / FHZ-Forum

Hallo,
ich setze bei einem Neubau u.a. auf die IP Wired Komponenten wie z.B. das 32fach-Eingangsmodul (HmIPW-DRI32) und dan 8-fach-Schaltaktor (HmIPW-DRS8) in Verbindung mit der Homeputer CL-Software. Dabei handelt es sich ja um ein Drahtgebundenes System, welches sich bei mir nun in der letzten Aufbauphase befindet und ich angefangen habe kleine, einfache Verknüpfungen zu erstellen. Dabei ist mir ein merkwürdiges Problem aufgefallen, wenn ich z.B. bei einem Tasterdruck ein Makro auslöse, welches lediglich „Licht umschalten“ ausführt. Bei einem einfachen Tastendruck passiert auch das was passieren soll, nur wenn ich mehrmals hintereinander drücke passiert nichts. Wenn ich z.B. 2x hintereinander drücke, müsste das Licht doch an und gleich wieder aus gehen – passiert aber nur wenn ich etwa 1-2 Sekunde Pause zwischen den Tastvorgängen lasse. Weshalb ist das so? Geht es nicht anders oder ist es eine Konfigurationsgeschichte? In der WebUi hab ich beim Kanalverhalten: Taster / Doppelklick-Zeit (Tastensperre) 0,00 s / Mindestdauer für langen Tastendruck: 5,00 s / Timeout für langen Tastendruck 2 Minuten zu stehen.
Demgegenüber können Makros ja (zumindest laut Einstellungsmöglichkeit ab 10x je Sekunde ausgeführt werden… ??
Hat wer eine Idee??

Das liegt daran, auch wenn es wired Geräte sind, Telegramme gesendet werden, welche von den Aktoren gelesen und ausgewertet werden müssen:

Telegramm an Aktor 3 Licht ein wird gesendet.

Aktor 1 hört Telegramm, liest, ist nicht für mich, verwirft es.
Aktor 2 hört Telegramm, liest, ist nicht für mich, verwirft es.
Aktor 3 hört Telegramm, liest, ist für mich - was soll ich tun? => Wird ausgewertet und führt die Aktion aus.
Aktor 3 schickt Telegramm (im Normalfall) zurück mit dem Inhalt Befehl erfolgreich ausgeführt!

Dies geschieht zwar alles im Millisekundenbereich aber auch hier sind grundsätzlich Wartezeiten (Latenzzeit) eingeplant, daher kann nicht zwei mal kurz hintereinander ein und derselbe Befehl ausgeführt werden!

Das was du beschreibst, die Doppelklicktastensperre ist eigentlich eine ungewollte Betätigungsschutzfunktion, d. h. die Taste muss gedrückt werden, um sie zu entsperren und innerhalb des vorgegebenen Zeitrahmens noch einmal betätigt werden, um den Befehl (das Telegramm) zu senden.

Die Mindestdauer für langen Tastendruck beschreibt nur den Zeiteaum, in welcher der Taster mindestens gedrückt und gehalten werden muss (vorher natürlich die Tastensperre deaktivieren, falls aktiv), um einen langen Tastendruck auszuwerten bzw. gilt ab dieser Dauer der Tastendruck als lang.

Der Timeout für langen Tastendruck beschreibt die Zeit, innnerhalb welcher der lange Tastendruck nicht gewertet wird nachdem ein langer Tastendruck ausgeführt wurde. (Jetzt hoffe ich einmal, dabei hab ich mich nicht vertan, da ich mit dem Timeout nichts zu tun habe)

Also Antwort auf deine Frage im Betreff: Ja, die sind notwendig um die Antwort abwarten und empfangen zu können.

MfG René

Danke René!
Das Prinzip ist mir durchaus klar, dennoch habe ich das Gefühl das es eine zu lange Verarbeitungszeit ist und deshalb wollte ich herausfinden ob es (zu dem was Du schreibst) noch weitere Faktoren (Einstellungen) gibt, die diese Zeit verkürzen könnten.
Wenn ich zwei verschiedene Taster gleichzeitig drücke, wird der Schaltbefehl ja auch ausgeführt, dann zwar hintereinander, aber er kommt an. Somit könnte das zweimal hintereinander drücken auch -mit einer kleinen Zeitverschiebung- hintereinander abgearbeitet werden - wird es aber nicht...

Vielleicht lässt du mal deine Einstellungen / Parameter mit einem Screenshot sehen, dann kann man vielleicht noch etwas mehr dazu sagen!

Aber ich denke, die Wartezeit von maximal 2 Sekunden für eine erneute Ausführung der Aktion ist vertretbar - ich verwende selber zwar nur Wireless-Geräte, bin damit aber relativ zufrieden, auch mit der Reaktionszeit.

Womöglich wurde aber dein Makro noch nicht vollständig abgearbeitet, sodass das System noch nicht bereit ist, es erneut auszuführen?

MfG René

Hey, ich hab's gefunden
Unter "Allgemein" gibt's einen Punkt "Reset-Zeit in Sekunden" - dort stand bei mir eine "3". Habe es auf "0" geändert - dann ging gar nichts mehr und dann auf "1" - nun geht es so wie ich es haben wollte *freu*

...dann werde ich das mal 32x von "3" auf "1" ändern

Hey dv-20.

Testweise sind vor kurzem auch bei mir ein 32fach-Eingangsmodul (HmIPW-DRI32) und ein 8-fach-Schaltaktor (HmIPW-DRS8) in Betrieb genommen worden. Ist der Eingang als Taster konfiguriert, wird der Ausgang (Direkt-Verknüpfung) relativ verzögerungsfrei geschaltet. Ist der Eingang jedoch als Tür-/Fensterkontakt definiert, reagiert der Ausgang (wie von dir im ersten Post geschrieben) verzögert um 1.5 - 2 Sekunden. D.h. wird das Fenster geschlossen und springt in demselben Moment (z.B. durch Luftzug) innert diesen 2 Sekunden wieder auf, wird dies vom System gar nicht detektiert. Für ein Sicherheitsskontakt finde ich diese Verzögerung zu hoch.
Leider konnte ich deine Einstellung "Reset-Zeit in Sekunden" nicht finden. Wo befindet sich dieser Parameter genau?

Gruss & vielen Dank
ADB

Hi,

DiBi_83 hat geschrieben: ↑

14.01.2020, 06:40

... wird dies vom System gar nicht detektiert.

Von welchem 'System' sprichst du hier - CCU oder HPCL?

DiBi_83 hat geschrieben: ↑

14.01.2020, 06:40

Leider konnte ich deine Einstellung "Reset-Zeit in Sekunden" nicht finden.

Unter Aktor > Allgemein.
Macht aber bei einem als TFK konfigurierten Eingang abs. keinen Sinn.

Hast du im DRI32 den Eingang auf eine 'Eventverzögerung' gesetzt?

Ja, unter Allgemein! Ich komme mit 1 Sekunde meist gut klar, aber auch nicht in jedem Fall. Das Problem ist, das das Makro nach der Zeit erneut gestartet wird, sollte der Taster immer noch gedrückt sein. was dann bestimmte Aktionen ungewollt mehrfach auslösen würde.

Entschuldigt... dass es ums Thema "Homeputer CL" ging, habe ich glatt überlesen.
Mein System besteht aus einem Raspberry 3 und dem Funkmodul RPI-RF-Mod. Installiert wurde Raspberrymatic 3.49.17.20191225.
Im WebUi über Einstellungen -> Geräte -> Einstellungen wurde der Eingang vom DRI32 als "Tür-/Fensterkontakt" mit Eventverzögerung = "nicht aktiv" konfiguriert. Dieser Eingang wurde anschliessend per Direktverknüpfung mit einem Ausgang vom DRS8 vernüpft.