Visu Reaktionszeit - Faktoren?

[mfd]

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

Ich würde zwar gern verstehen, warum das konzeptionell Sinn macht, da es ja offenbar auch ohne die Client-Polling-Geschichte geht, ist hier aber etwas OT und wohl eh nicht zu ändern.

• 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

Soweit ich verstehe ist hier der entscheidende Punkt, wenn eine Rückmeldung noch nicht vorliegt, da "zu schnell" aktualisiert wurde muss man bis zum nächsten Aktualisierungsintervall der Visu warten um das Ergebnis zu sehen...?
Wenn die Klicklatenz höher eingestellt wird ist die Rückmeldung zwar sicher schon da, aber man muss die größere Verzögerungszeit in Kauf nehmen...

Weshalb kann bei diesem Konzept nicht das Status-KO selbst (sobald es eingetroffen ist) den Refresh der Visu auslösen?

[*]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

Welches Szenario gibt es, dass eine Klickqueue >0 Sinn macht?
(wäre ggf. gut es in der Hilfe zu ergänzen)

[jonofe]

Weshalb kann bei diesem Konzept nicht das Status-KO selbst (sobald es eingetroffen ist) den Refresh der Visu auslösen?

Das genau wäre Server-side-push, denn der Server bekommt ja den Status und nicht der Client. EDOMI basiert aber auf Client-side-poll und daher wird es so einfach nicht umsetzbar sein.

[mfd]

EDOMI basiert aber auf Client-side-poll und daher wird es so einfach nicht umsetzbar sein.

Verstehe.
Habe jetzt mal nach den Seitenaufrufen per KO gesucht, weil ich dachte da muss das ja auch irgendwie funktionieren. In der Tat scheint da die gleiche Einschränkung (Aktualisierungsintervall Visu) zu bestehen. Das ist wirklich... unschön.

Gibt es denn wenigstens auch einen Vorteil durch das Client-side-polling? Bisher sehe ich aus Anwendersicht nur die Nachteile.

[jonofe]

Grundsätzlich ist ja das Ziel eines regelmäßigen Pollings möglichst nah an realtime Informationen zu kommen. Daher ist es immer ein Kompromiss, wenn es darum geht Serverseitige Events mitzubekommen. Daher stimme ich dir zu, dass es aus Nutzersicht mit Erwartungen nach Realtime Informationen wohl kaum Vorteile beim Polling gibt.

Im Zusammenhang mit EDOMI ist es aber müßig darüber zu philosophieren, denn das ist eine grundsätzliche Design Entscheidung, die Christian so getroffen hat und die man nicht mal kurz umwerfen kann. Wenn es wirklich ein K.O. Kriterium ist, dann ist EDOMI die falsche Visualisierung für dich, was ja nicht bedeutet, dass man die Logikengine nicht nutzen kann. Hast du mal Node-Red mit MQTT Anbindung ausprobiert? Dazu gibts auch Dashboards, mit denen man eine Visualisierung bauen kann. Ich denke dort sollte die Reaktionszeit dann vermutlich schneller sein. Müsste man aber ausprobieren.

Ggf. wäre ja Long-Polling noch eine Option, die in ferner Zukunft umsetzbar ist. Dabei pollt der Client weiterhin den Server. Wenn dieser aber keine neuen Daten für den Client hat, dann bleibt die Connection offen, bis neue Daten vorliegen. Neue Daten werden dann sofort vom Server an den Client gesendet und danach wird die Verbindung beendet und direkt wieder eine neue Verbindung geöffnet und dasselbe Spiel startet von vorn. D.h. es ist immer eine Polling Verbindung offen, so dass der Server sofort seine Daten an den Client weiterleiten kann. Dazu müsste aber dann Christian etwas sagen, da dies auch ein gewissen Redesign nach sich ziehen würde, welches vermutlich aber deutlich geringer ist, als Websockets oder Server-Side-Push.

[mfd]

Wenn es wirklich ein K.O. Kriterium ist, dann ist EDOMI die falsche Visualisierung für dich, was ja nicht bedeutet, dass man die Logikengine nicht nutzen kann. Hast du mal Node-Red mit MQTT Anbindung ausprobiert?

Es wäre dann ein K.O. Kriterium wenn die potenzielle zukünftige Visu (EDOMI) insgesamt schlechter reagiert als die bisher genutzte (CV). Im Moment bin ich noch am Testen, die Einschränkungen (wenn man sie bisher nicht kannte) sind natürlich unschön.
Das Einfachste wäre natürlich weiterhin bei der CV zu bleiben, allerdings ist das an einigen Punkten unpraktikabel, bspw. wenn es darum geht Werte von (eigentlich internen) KOs über den Bus zu jagen, nur um sie mit der nächstbesten Visu wieder "einzusammeln".
Dazu kommt, dass es mit den DPTs jenseits der 14 Zeichen schwierig wird (ist ja auch nicht der Sinn des KNX irgendwelchen Senderinfo-Quatsch darüber zu schicken).
MQTT Anbindung wäre wohl ein Ausweg, würde aber noch eine zusätzliche Baustelle aufmachen - braucht man auch nicht unbedingt.

Ggf. wäre ja Long-Polling noch eine Option, die in ferner Zukunft umsetzbar ist.

Das ist das Verfahren, wie es die CometVisu macht, vermute ich...
aus Wikipedia: ..."Als Übertragungsprotokoll wird das frei verfügbare CometVisu-Protokoll verwendet. Basis ist ein „Long Polling“, auch bekannt unter dem Namen Comet-Pattern, einer Ajax-Programmiertechnik."

Aus Anwendersicht würde ich da sagen

[WagoKlemme]

Oder Du baust eine SPS ein, dann hast Du wie in Industriesteuerungen nahezu Echtzeit.

Kannst dich gerne an mich wenden. Bei mir verstauben sonst die Teile.

[gaert]

"AJAX" hat zunächst mit Long-Polling nix zu tun, sondern beschreibt u.a. die Art und Weise wie die Kommunikation zw. Client und Server grundsätzlich abläuft: In Javascript werden die Daten vom Server abgeholt und verarbeitet. Früher (z.B. bei der Standard-Visu des HS) machte man sowas noch mit iFrames etc...

EDOMI arbeitet natürlich auch mit "AJAX"-Requests. Ein Server-Push-Mechanismus ist mittlerweile prinzipiell recht einfach umsetzbar - das war vor ein paar Jahren noch anders (die Geburtsstunde von EDOMI) und mündete gerne in Problemen (je nach Browser und Sonnenwind - aka "Zufall").

Ich halte eher wenig von einer solchen "Websocket"-Lösung, denn diese Mechanismen sind allesamt irgendwie nachträglich in die Browser gefummelt worden und sorgen gerne für Verbindungsprobleme. Ein Browser ist konzipiert als Polling-Applikation, d.h. der Browser fragt den Server und dieser antwortet - nicht umgekehrt. Spätestens beim Zugriff per 3G spürt man das recht gut (und erkennt's auch ggf. auf der Rechnung).

Natürlich sorgt dies für Latenzen, aber ich empfinde das als vollkommen hinnehmbar. Zumal es in einer Visu i.d.R. um komplexere Zustände etc. geht, die ohnehin erstmal eine Logik durchlaufen oder von nicht-realtime-Faktoren bestimmt werden. Wenn ich z.B. eine Lampe schalte und der Zustand erst nach 1 Sekunde angezeigt wird, kann ich damit leben (ich bin's vom HS auch nicht anders gewohnt, vielleicht liegt's daran).

Anders ausgedrückt: Für mich ist eine Visu in erster Linie eine Visualisierung von Zuständen - für routinemäßige "Schalthandlungen" drücke ich einen echten Knopp an der Wand Von daher sind mir solche Latenzen vollkommen schnuppe - es interessiert mich nicht, ob die Pumpe X genau JETZT angegangen ist oder vor 1 Sekunde...

[Brick]

Hauptsache das Licht geht zackig an.. wenn man drückt..

[mfd]

es interessiert mich nicht, ob die Pumpe X genau JETZT angegangen ist oder vor 1 Sekunde...

Da stimme ich vollkommen zu.

Es geht mir hauptsächlich um eine optisch sinnvolle Umsetzung in der Visu.
Wenn ich bspw. die Lüftungsstufe der KWL über die Visu ändere (wäre ja Verschwendung in jeden Raum einen Taster dafür zu montieren), dann ist es mit einem Button, bei dem das Rückmeldeobjekt den Buttonzustand anzeigt etwas hakelig, wenn die Rückmeldung >1 Sekunde auf sich warten läßt.
Anders ausgedrückt, das Rückmeldeobjekt ist in diesem Fall - und den meisten anderen Fällen - so nicht nutzbar.

In Zeiten von 8-Kern-Geräten für die Hosentasche ist einfach niemand (Stichwort "WAF") mehr bereit nach dem Tippen auf einen Bildschirm auf dessen Reaktion "zu warten".
Vor 10 Jahren wäre man vermutlich mehr als glücklich gewesen, dass ein berührungsempfindlicher Bildschirm an der Wand eine saubere KNX-Steuerung ermöglicht. Aber leider ändern sich die Anforderungen heutzutage schneller, als einem als "Smarthome-Admin" lieb sein kann...

[gaert]

Aber so funktioniert KNX nunmal... Ich fordere etwas an und erhalte "irgendwann" eine Reaktion - oder auch nicht, z.B. wenn der Aktor gerade keine Lust hat oder ein Sperrobjekt irgendetwas verhindert.

Die Visu funktioniert nunmal wie eine Webseite (bzw. IST eine solche), d.h. mit Echtzeit ist da nix. Genau wie im Forum: Klickst Du auf "Absenden", erfolgt die Rückmeldung (in Form eines Posts) erst nach einigen Sekunden

[mfd]

Aber so funktioniert KNX nunmal... Ich fordere etwas an und erhalte "irgendwann" eine Reaktion - oder auch nicht, z.B. wenn der Aktor gerade keine Lust hat oder ein Sperrobjekt irgendetwas verhindert.

Das ist "Frau" aber doch egal wie KNX funktioniert, es wird auf dem Bildschirm was gedrückt, wenn nicht gleich eine Reaktion kommt wird nochmal gedrückt und dann festgestellt es geht nicht so wie es soll... und es wird umgehend der "hauseigene Support" kontaktiert...

Btw.:
gaert könnte doch eine kostenlose EDOMI-Support-Hotline für "unzufriedene KNX-Ehefrauen" einrichten, das könnte so manchen User(innen)-Wünschen bestimmt den nötigen Nachdruck verleihen.

[DirtyHarry]

Es steht außer Frage, dass eine sofortige Aktualisierung am Schönsten wäre. Bei geschickter Anpassung der Werte (vor allem der Klicklatenz) bekommt man das schon recht gut in den Griff: Nach dem Klick immer 500ms (z.B.) warten stört weniger, als einmal nach 200ms die Aktualisierung zu haben und manchmal aber auch erst nach 1 Sekunde.

Btw.:
gaert könnte doch eine kostenlose EDOMI-Support-Hotline für "unzufriedene KNX-Ehefrauen" einrichten, das könnte so manchen User(innen)-Wünschen bestimmt den nötigen Nachdruck verleihen.

Wenn die Hotline auf deinen Telefonanschluss geschaltet wird, hat Christian bestimmt kein Problem damit.

[WWebber]

Das ist "Frau" aber doch egal wie KNX funktioniert, es wird auf dem Bildschirm was gedrückt, wenn nicht gleich eine Reaktion kommt wird nochmal gedrückt und dann festgestellt es geht nicht so wie es soll... und es wird umgehend der "hauseigene Support" kontaktiert...

Ich würde es für "diesen" User auch begrüßen, wenn ich das Highlighting des Buttons länger liegen lassen könnte und in dieser Zeit auch das "retriggern" desselben Buttons gesperrt sein würde. Damit wären zumindest die Mehrfach-Betätigungen vom Tisch. DAUs machen ja auch im Browser vielfache Sinnlos-Doppelcklicks, weil sie keine Statusänderung oder Reaktion sehen.

[hx5]

gaert

Ich bin jetzt auch nicht so tief im Thema aber wäre es vlt. recht einfach zu Implementieren das man bei einem Visuelement einstellen könnte das man den Soll-Wert vor der Rückmeldung anzeigen lassen kann?

Das Element würde dann einfach schon mal so tun als ob es den Status schon erhalten hätte bis es von der GA/iKO aktualisiert wird.

Oder das der Indikator genau so lange an bleibt bis die Rückmeldung ankommt?

Das würde den WAF sicherlich deutlich verbessern.

[coliflower]

Gibt’s eh, oder ?

Bildschirmfoto 2017-07-19 um 22.30.40.png