Visu Reaktionszeit - Faktoren?

[mfd]

Bei einigen Tests mit der EDOMI-Visu ist mir aufgefallen, dass die Reaktion des Rückmeldeobjekts (in der Visu) auf eine Schalterbetätigung relativ lang auf sich warten läßt (>> 1s).
Geschalten wurde dabei einmal eine echte GA und als Antwort wurde ein aktives Rückmeldeobjekt verwendet.
Im zweiten Szenario wurden iKOs von LBS-Ausgängen geschalten und ebenso iKOs als Rückmeldeobjekte verwendet.

Es macht auf mich den Eindruck, als würde die Antwort auch nicht immer gleich lang auf sich warten lassen... so als hätte das mit dem Aktualisierungsintervall der Visu (derzeit auf 3s) zu tun. Bisher bin ich davon ausgegangen, dass dieses Intervall lediglich für den Ruhezustand der Visu gilt und bei einer Nutzerinteraktion nicht zum Tragen kommt.

Gibt es eine Möglichkeit das Verhalten irgendwie (positiv) zu beeinflussen?

[jonofe]

Das Rückmeldeobjekt ist doch asynchron zum Schalt-KO und damit Visubetätigung, d.h. wenn einen Schaltvorgang auslöst (Schalt-KO) weiß die Visu ja nicht, ob es eine Rückmeldung (Status-KO) geben wird. Die Rückmeldung kommt dann irgendwann und wird bei der nächsten Aktualisierung der Visu visualisiert.
Daher können natürlich unterschiedliche Reaktionszeiten des Rückmeldeobjekts im Bereich 0 bis Aktualisierungsintervall auftreten.

[mfd]

Die Rückmeldung kommt dann irgendwann und wird bei der nächsten Aktualisierung der Visu visualisiert.

Gibt es dafür einen Workaround oder eine Umsetzung die das Problem vermeidet? So sind ja alle Rückmeldeobjekte für die Tonne, solange sie direkt auf eine Betätigung folgen (sollen).

Vielleicht ist das ja auch "normal" ich kannte dieses Problem von der CometVisu her nur noch nicht...

[gaert]

So ist aber das Konzept...

Also:

• in der Visu wird ein Button geklickt, als Bestätigung wird der Klickindikator angezeigt (kurzzeitig)
• die Visu führt die gewünschten Befehle aus - hier z.B. das Setzen eines KOs auf einen Wert
• der KNX-Aktor registriert z.B. diesen "Schaltwunsch" und setzt ggf.(!!!) das Status-KO entsprechend
• EDOMI verarbeitet ggf. dieses Status-KO und teilt es der Visu mit
• Visu wird "irgendwann" (Refreshzeit) aktualisiert (je nach Einstellung erfolgt die Aktualisierung auch kurz nach dem Klick)

[mfd]

Soweit alles bekannt und nachvollziehbar.

[*]Visu wird "irgendwann" (Refreshzeit) aktualisiert (je nach Einstellung erfolgt die Aktualisierung auch kurz nach dem Klick)

Ich bin naiverweise davon ausgegangen, dass das Status-KO, sofern im entsprechenden Visuelement (z.B. Universalelement) als solches angegeben, "sofort" aktualisiert.

Welche Einstellung ist denn vorzunehmen, damit die Aktualisierung kurz nach dem Klick erfolgt?

[jonofe]

AFAIK: Die Refreshzeit. Kleinster Wert: 1s

[gaert]

"Sofort" geht schlecht bei einer Event-getriggerten Applikation... Es könnte ja z.B. eine Logik dazwischen hängen oder sonstiges, das das Setzen eines KOs verzögert.

[mfd]

gaert Das verstehe ich nicht. Wenn ein Status-Telegramm vom Bus kommt, kann das doch, sobald es über die entsprechende Schnittstelle empfangen und ggf. noch übers Netzwerk den Weg ins EDOMI-System gefunden hat direkt verarbeitet werden, wer sollte das "aufhalten"?

Also bleibt nur die Refreshzeit der gesamten Visu auf 1s zu setzen?

Das ist bitter, das Konzept kann ich aus Benutzersicht nicht so recht nachvollziehen... auch wenn es sicher programmiertechnische Hintergründe hat.
Wie setzt man das sinnvoll in die Praxis um?
Es bräuchte dann ja jeweils einen Button, der bei Betätigung "schaltet" damit der Nutzer nicht irritiert ist (oder es bei dem Klick-Indikator belassen), und dann separat nochmal den ausgeführten Schaltvorgang visualisiert.

Ich kann mir da gerade keine WAF-kompatible Lösung vorstellen, zumal es dann heißen würde: "...das hat aber doch bisher immer sofort umgeschaltet [...] weshalb muss man da jetzt drauf warten..."

Es muss doch einen eleganteren Weg geben, oder ist das für alle, die bisher mit EDOM Visualisierungen umgesetzt haben irrelevant?

[hx5]

oder ist das für alle, die bisher mit EDOM Visualisierungen umgesetzt haben irrelevant?

Bestimmt nicht aber für mich ist die Visu mehr eine Statusinformation. Schalten tue ich bevorzugt mich echten Schaltern.
Ist vielleicht ein Nachteil in EDOMI dafür gibt es für mich mehr Vorteile....

[mfd]

Ist vielleicht ein Nachteil in EDOMI dafür gibt es für mich mehr Vorteile....

Ähhh... das soll jetzt heißen die EDOMI-Visu taugt nur zum Anzeigen? Schalten besser wo anders? Das ist doch nicht euer Ernst?

[hx5]

Ähhh... das soll jetzt heißen die EDOMI-Visu taugt nur zum Anzeigen?

Nur um es klar zu stellen: Ich habe weder explizit von EDOMI geschrieben noch meine Meinung verallgemeinert (euer Ernst).

Und ich will auch nicht damit sagen "das EDOMI-Visu nur zum anzeigen taugt" sondern nur das mir die Reaktionsgeschwindichkeit der Rückmeldung in der Visu einfach nicht so wichtig ist....

Natürlich würde es aber die Nützlichkeit der Visu für mich verbessern/erweitern.

[Brick]

Also mir ist das ehrlich gesagt noch nie aufgefallen.. weiß jetzt nicht ob ich die Visu auf 1s. gestellt hab, aber ich glaube nicht..
und wenn doch ist mein System immer noch performant genug das ich daran keinen Nachteil spüre...


EDIT: es sind 3 sec eingestellt...

[MrMirror]

Mir ist es auch damals direkt aufgefallen, aber bei 1s geht es eigentlich so gerade, ich lebe halt damit.
Wobei z.B. kurzzeitig nach Empfang eines Status-KO z.B. 250mS schon cool wären, um den Status praktisch "live" zu sehen. Die Frage ist nur wie teilt man Edomi mit, dass es sich um ein Status-KO (für die Visu) handelt...!? Bzw. selbst wenn man das über eine Konfig macht, wäre es überhaupt umsetzbar, die Visu dann unmittelbar neu zu laden?

[gaert]

Die Visu wird in EDOMI nicht gepusht (vom Server), sondern vom Client regelmäßig gepollt (abgerufen). Das ist konzeptionell so und bleibt auch so. Intern (also im Backend) werden KOs etc. natürlich sofort empfangen/verarbeitet - nur die Visu ruft die neuen Zustände lediglich in festen Intervallen ab.

EDOMI orientiert sich dabei (bekanntermaßen) am HS


Wer spielen mag, sollte auch mal die Hilfe bemühen:

• Klicklatenz: Wartezeit, bis nach einer Nutzerinteraktion die Visualisierung aktualisiert wird
  • dies ermöglicht eine Verkürzung des Visu-Aktualisierungsintervalls nach einer Nutzerinteraktion
  • die Zeitmessung wird bei jeder Nutzerinteraktion zurückgesetzt
• Klickqueue: ermöglicht eine gesammelte Übermittlung von Nutzerinteraktionen an den Server
  • keine Queue: jede Nutzerinteraktion wird unmittelbar an den Server übermittelt
  • 0.25..3 Sekunden: alle Nutzerinteraktionen innerhalb dieses Zeitraums werden gesammelt an den Server übermittelt
  • nach der Übermittlung wird die Visualisierung nach Ablauf der "Klicklatenz" (s.o.) aktualisiert

[MrMirror]

Kein Problem, wie gesagt ich kann damit leben, bei mir steht Klicklatenz und Queue auf 0.25 und Aktualisierung auf jede Sekunde.