Optimierung Visu für "KO: Wechseln zwischen 0 und 1 (mit Status-KO)"

[nno]

Ich hätte einen großen Wunsch zur Optimierung der Visu : Aktualisierung eines Status-KO bereits beim Klick, noch bevor sich die Visu refreshed.


An vielen Stellen verwende ich zum Ein- und Ausschalten von Lichtern etc. ein Bildelement, welches über dynamische Designs abhängig vom Status-KO ein anderes Bild anzeigt (Switch on oder off). Beispiel:

Bsp_Switch_Off.png

Bsp_Switch_On.png

(An der Stelle auch nochmal vielen Dank an timberland für die collen Design Ideen)

D.h. das KO vom Bildelement ist gleichzeitig auch das Status KO für den Befehl "KO: Wechseln zwischen 0 und 1 (mit Status-KO)", der beim Klick-Verhalten als Befehl eingetragen ist.

Es funktioniert soweit alles wie erwartet, allerdings gibt es auf der Visu oft eine Verzögerung bis sich das Bild-Element aktualisiert. Technisch ist mir klar, dass sich die Visu erst wieder refreshen muss und dadurch eine gewisse Verzögerung auftritt ... den WAF drückt das aber ziemlich in den Keller. "Ich hab doch gedrückt, das Licht ist auch an, aber hier auf dem iPhone passiert nichts". . Auch wenn ich die Visu Refresh-Zeit auf 1 Sek. runterdrücke hat man beim Bedienen der Visu eine gewisse Latenz.

Ich würde mir daher wünschen, dass das Status-KO temporär bereits beim Klicken auf ein Visuelement im Browser geändert wird, sich das Visuelement dadurch sofort aktualisiert und nicht erst nach dem nächsten Refresh der Visu.

Mir ist klar, dass es Situationen geben kann, wo das Verhalten nicht passt. Wenn der Aktor z.B. gerade gesperrt ist, sich das Status-KO also nicht wie erwartet ändert. Aber der Fall wäre bei mir die absolute Ausnahme. Im schlimmsten Fall würde sich in der Visu der Zustand des Schalters bereits ändern, nach dem nächsten Refresh würde dann aber wieder alles stimmen. Vielleicht könnte man es mit einem neuen Befehl "KO: Optimistischer Wechsel zwischen 0 und 1 (mit Status-KO)" lösen, so dass der bisherige Befehl sein Verhalben beibehält und einer neuer Befehl aber temporär im Browser das Status-KO schon mal ändert, da er ja weiß wie der Wert des Status-KO mit hoher Wahrscheinlichkeit nach dem nächsten Refresh sein wird.

Was meint ihr, macht das Sinn, oder habt ihr das "Problem" mit der Visu-Latenz anders gelöst?

[Crimson]

Ich habe das gleiche 'Problem' mit der Latenz. Finde es zur Zeit auch unschön, dass sich das Bild-Element erst nach dem Refresh aktualisiert. Ich wäre daher auch dafür, falls es Möglichkeiten gibt das anzupassen.

[gaert]

Nee, das würde dem Grundprinzip von KNX widersprechen: Du setzt ja nicht wirklich einen Status, sondern z.B. der Aktor antwortet (irgendwann) mit einem Status...

[Crimson]

Das verstehe ich. Allerdings kommt die Rückmeldung vom Bus meist im Bruchteil einer Sekunde.
Könnte man für die Visu denn alternativ Refresh-Intervalle von weniger als 1 Sekunde implementieren? z.B. 0,5 und/oder 0,25 Sekunden?

[DirtyHarry]

Naja, ständige Refrehs in so kurzen Intervallen sind ja auch nicht unbedingt sinnvoll. Besser wäre wohl nach einem Klick einen Refrehs anzustoßen (optional?).

[nno]

Naja, ständige Refrehs in so kurzen Intervallen sind ja auch nicht unbedingt sinnvoll. Besser wäre wohl nach einem Klick einen Refrehs anzustoßen (optional?).

Hmm, bin mir nicht sicher, ob das zeitlich klappt. Beim Klick wird ja meist auch ein Befehl ausgelöst, d.h. EDOMI schickt etwas auf den Bus und müsste dann ja eine Zwangspause einlegen, damit es die Antwort vom Bus im gleichen Request noch mitbekommt und in der Response an den Brwoser zurückschicken kann.

Mir kommt gerade noch eine andere Idee. Könnte man nicht (zusätzlich) WebSockets verwenden? Alle modernen Browser sollten mittlerweile auch WebSocket-Verbindungen unterstützen. Vorteil ist, dass WebSockets bidirectional sind, d.h. der Server kann zu jedem beliebigen Zeitpunkt Daten an den Browser schicken. Ohne dass der Browser also ständig einen Refresh auslösen muss.

[gaert]

Schonmal die Hilfe gelesen?

• 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

Websockets mag ich nicht... Natürlich wäre das eine Option - nur bedingt dies eine grundsätzlich neue Konzeptionierung der Visu und ist daher nicht auf die Schnelle zu implementieren. Übrigens haben Websockets nicht nur Vorteile, z.B. wird der Akku schnell leergesaugt da ständig Netzwerkverkehr vorhanden ist. EDOMI baut konzeptionell auf dem HS auf, daher die "Ajax"-Variante der Aktualisierung.

[Crimson]

Danke für den Hinweis mit der Klicklatenz. Ich probiere damit mal ein wenig rum. Hatte den Wert bisher auf 0,1 Sekunden stehen. Das scheint dann für die Rückmeldung doch zu kurz zu sein, denn es dauert immer gut diese eine Sekunde für den refresh bevor die Visu aktualisiert wird. Mal sehen wie sich das mit 0,25 oder 0,5 anfühlt.

[MIT]

Nee, das würde dem Grundprinzip von KNX widersprechen: Du setzt ja nicht wirklich einen Status, sondern z.B. der Aktor antwortet (irgendwann) mit einem Status...

=> Verstehe ich schon. Aber: Aktuell nutze ich bspw. die Cometvisu (CV) immer noch parallel zu edomi, weil die Latenz in der CV - zumindest gefühlt - nicht vorhanden ist. Es kommt so oft vor, dass ich bspw. einen Aktor für einen Musik-Verstärker (Squeeze) ein- oder ausschalte (oder - noch schlimmer - den 19" Netzwerkswitch im Netzwerkschrank), ohne gerade sicher zu sein, ob er denn aktiv ist oder nicht. Da hilft aktuell nur der Blick in die CV um zu sehen, ob der Aktor geschaltet hat oder nicht.
Sehe ich als ein großes Problem bei der Visu von edomi an.

[gaert]

Ich sehe da kein Problem Die Visu läuft quasi in Form von 2 Instanzen: Der Status wird alle x Sekunden aktualisiert, und jeder "Klick" führt unmittelbar entsprechende Befehle aus (und führt bei Bedarf "unmittelbar" zu einer anschließenden Status-Aktualisierung). Alles andere hängt vom Backend ab bzw. vom Bus: Wenn der Status noch nicht gesetzt/empfangen wurde, gibt's auch nix zu aktualisieren...

Der einzige Unterschied zu Websockets (bzw. push-Benachrichtung) ist also das Intervall der Aktualisierung: Bei Push würde sofort bei Statusänderung aktualisiert werden, per Polling eben im angegebenen Intervall. Dennoch hängt in beiden Fällen das Ergebnis auch von der Latenz der Statusänderung als solches ab - logisch.

Websockets/Push kann man sich also effektiv wie eine passive Aktualisierung mit einem Intervall von annähernd 0 Sekunden vorstellen, so dass die Latenz nur noch von der Statusänderung abhängt.

[webasti321]

Für mich war es auch ungewohnt als ich von Smartvisu zu Edomi gewechselt habe. Da aber die Vorzüge von Edomi stark überwiegen, habe und werde ich es weiterhin so hinnehmen.

Was mir noch aufgefallen ist, wenn man etwas länger auf ein Symbol klickt (ohne Option Langer Klick) wird in den meisten Fällen der Status sofort aktualisiert.
Oder man klickt direkt nach dem ersten Klick auf ein zweites Symbol, das erste wird sofort nach dem zweiten Klick upgedatet (deutlich kürzer als ohne zweiten Klick) und das zweite nach der üblichen Zeit.

Habe auch mit der Klicktlatenz gespielt jedoch ohne den erwünschten erfolg. Auch wenn ich 3 Sekunden Latenz einstelle wird der Status dennoch in ca. einer Sekunde aktualisiert.

[gaert]

Das hängt mit den Einstellungen der "Klick-Queue" zusammen - siehe Hilfe

[webasti321]

Die Klickqueue habe ich nicht aktiv!

[gaert]

Eben Daher wird nach jedem Klick (je nach Einstellung) aktualisiert - manchmal ist der Status dann schon verfügbar, manchmal nicht. Dies ist quasi vom Zufall/Buslast/etc. anhängig.

Mit aktivierter Queue werden die Klicks innerhalb eines Zeitraums erstmal "eingesammelt" und erst dann zusammen verarbeitet.

[webasti321]

Klicklatenz und Queue ist mir denke ich Klar. (ich stehe aber auch gerne mal auf dem Schlauch)


Was mich nur wundert ist, dass bei einem Langen Klick bzw. einem zweiten Klick in folge der aktuelle Status doch da ist.
Heist für mich dass die Visu erst deutlich nach dem eintreffen des Status aktualisiert wird.

Um vorweg zu nehmen. Aktuell ist die Latenz auf 0,75s und die Queue "aus". Ich habe probiert mit der Latenz Schrittweise hoch zu gehen um vorzubeugen das der Status erst nach dem refresh der Visu an kommt. Ändert aber nichts!

Ich habe es mir jetzt nicht nehmen lassen, dass ganze mal als Videomaterial darzustellen.

https://youtu.be/YsMuM1iKiDE

Zuerst normaler Klick, dann langer Klick, dann zweiter Klick.

Der Rechte Button schaltet nur ein Internes Test KO der linke auf den Bus. Da der rechte deutlich schneller ist, liegt es rein logisch gesehen am Bus/Netzwerk. Aber warum wird es dann durch den langen klick beschleunigt. Ich habe mir es schon angewöhnt den Finger länger gedrückt zu halten.

Wäre auch mal Interessant andere Mitschnitte der Visu zu sehen.

Gruß