status.toast reagiert auf on_update

[loeserman]

loeserman
danke für Deine Tests. Dadurch konnte das Websocket-Problem mit dem shNG-Release v1.9.5 gelöst werden, das heute erschienen ist.

Wenn Du das Update durchgeführt hast, kannst Du den Toast gelegentlich nochmal testen? Das mehrfache Triggern sollte dann hoffentlich beseitigt sein.

Gruß
Wolfram

Also das Thema ist mit der v1.9.5 behoben. Kann es nicht mehr nachstellen. Weder mit mehreren Instanzen auf einem oder auch verschiedenen PCs.

Klasse!

[loeserman]

@loeserman,
da war noch ein Bug im Code, so dass das Schließen des Toasts durch ein "false" bei param_allowclose nicht sicher verhindert wurde. Im develop branch ist jetzt eine geänderte Version, in der dies behoben ist. Austauschen der status.html und status.js sollte ausreichen, wenn Du v3.3.1 verwendest.
Setzt man "param_allowclose" auf "false" und "param_hideafter" auf "30000" (30 Sekunden), dann verschwindet der Toast automatisch nach 30 Sekunden, sofern nicht vorher der Türöffner betätigt wurde.

Es wird bei jedem Trigger-Impuls (Item geht von 0 auf 1) ein Toast getriggert. Das 30 Sekunden aktive Hilfsitem braucht man also weiterhin, um das mehrfache Triggern zu verhindern. Geht das item von 1 auf 0, wird der Toast jetzt nur noch gelöscht, wenn "param_allowclose" = "true" ist.

Gruß
Wolfram

Ich bin mal bei smartvisu auf den develop branch gewechselt. Aber irgendwie macht der bei mir immer noch etwas komisches.

Ich habe nun auf meiner minimalistischen Seite zwei Toasts eingebaut. Einer (AAA) reagiert auf LONG_IMPULSE_TEMP und der andere (BBB) auf LONG_IMPULSE.

{{ status.toast('toasttesta', 'SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE_TEMP', '', '', '', 'Klingel', 'AAA', 'message_bell', '', 'R12.HAUSTUER.OEFFNER', '   Hier drücken zum Tür öffnen   ', 'true', 'true', '50000', 'slide', 'true', '#FFFFFF', '#FF1356', '1', 'right') }}
{{ status.toast('toasttestb', 'SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE'     , '', '', '', 'Klingel', 'BBB', 'message_bell', '', 'R12.HAUSTUER.OEFFNER', '   Hier drücken zum Tür öffnen   ', 'true', 'true', '50000', 'slide', 'true', '#FFFFFF', '#FF1356', '1', 'right') }}

An der Item Struktur habe ich nichts geändert.

Ich verwende nicht das Item AKTIV, sondern arbeite hier nur mit den beiden LONG_IMPULSE_TEMP und LONG_IMPULSE, die ich aus der Visu einfach anklicke und so setze.


Test 1
Wenn ich nun auf LONG_IMPULSE in der VISU drücke, dann erhalte ich einen Toast (BBB), der auch nach 30sek wieder verschwindet. Ich habe auch noch diesen Toast Schließ Mechanismus von 50sek eingebaut (zusätzlich)

Rechts kann man sehen, dass die korrekt status.js geladen ist (kein Block mit "super." nach den Optionen). Man sieht weiterhin, dass nur die richtigen Items angemeldet werden und auch genau einmal kommen und auch wieder gehen. Es kommt damit auch genau ein Toast und geht wieder, wenn das Item geht. Alles wie es sein soll.

2023-04-02 12_59_32-Loeserhome 3.0.png

2023-04-02 13_01_25-Loeserhome 3.0.png




Test 2
Wenn ich aber auf LONG_IMPULE_TEMP in der VISU drücke, dann erhalte ich drei Toasts (2x AAA, 1x BBB). Erwartung war eigentlich zwei Toasts (1x AAA und 1x BBB). Warum kommt das AAA Toast zwei mal, auch wenn im Log die Variable auch nur einmal erscheint.

2023-04-02 13_03_57-Loeserhome 3.0.png

Nach den 30sek gehen die beiden items und die beiden AAA toasts bleiben stehen, obwohl auch das LONG_IMPULSE_TEMP auf FALSE zurückgewechselt ist. Was ist da falsch. Die Konfig ist ja gleich?

2023-04-02 13_04_31-Loeserhome 3.0.png

Nach den 50sek gehen dann die beiden Toasts. Aber das ist der interne Counter vom Toast selbst.

2023-04-02 13_04_46-Loeserhome 3.0.png


Vielleicht finden wir das auch noch raus?

[loeserman]

wvhn Ich habe noch etwas herausgefunden, kann aber noch nicht sauber erklären, was da genau passiert und warum. Aber vielleicht hilft es Dir oder Dir ist es schneller klar.

Ich habe ja zwei Items
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE_TEMP
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE

Das LONG_IMPULSE_TEMP Item setzt das LONG_IMPULSE bei on_change.

Wie oben gezeigt, kommt dann das Toast 2x, welches auf LONG_IMPULSE_TEMP hört und das andere Toast 1x, welches auf LONG_IMPULSE lauscht.

Was mir nun aber aufgefallen ist. Das ganze passiert nicht, wenn ich die Items so umbenenne, dass das eine Item nicht das andere Item komplett enthält.

Alles läuft einwandfrei, wenn sie so lauten:
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE_TEMP
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG1_IMPULSE
oder auch so
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG1_IMPULSE_TEMP
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE

Aber das Verhalten ist wieder falsch (mit den doppelten Toasts), wenn das TEMP Item das andere komplett enthält:
Zum Beispiel, wie in meiner Ursprungskonfiguration
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE_TEMP
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG_IMPULSE
oder auch so, wenn beide die 1 inne haben und so das längere Item wieder das komplette kürze Item beinhaltet.
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG1_IMPULSE_TEMP
SONDERFUNKTIONEN.KLINGEL.AKTIV.LONG1_IMPULSE

Werde mal heute Abend weiter forschen, aber vielleicht hilft das schonmal.

Sipple Hast Du auch eine ähnliche Item Konfiguration?

[loeserman]

wvhn Ich habe noch etwas probiert.

Es ist so, dass wenn ein Item angesprochen wird, welches textuell in dem Itemnamen vom Toast enthalten ist, dann wird dieses Toast angetriggert. In dem kommenden Beispiel TEST.TEST, obwohl das Toast auf TEST.TESTA lauscht. Ändere ich von TEST.TEST den Status, dann wird das ToastA getriggert, obwohl es darauf gar nicht hört.

Zusatz:
Das passiert sogar bei dem Item TEST. Also Ändere ich TEST, so wird das Toast angetriggert, welches auf TEST.TESTA hört. Es wertet aber den Status von TEST.TESTA aus, aber es wird angetriggert.


Vielleicht kannst Du das mal nachstellen. Auch ohne "on_change" oder soetwas. Völlig eigenständige Items.

Ganz simple Itemkonfig

TEST:
    TEST:
        name: Test
        type: bool
        visu_acl: rw
        value: 'False'
    TESTA:
        name: Test A (enthält von der Namengebung auch das Item TEST.TEST)
        type: bool
        visu_acl: rw
        value: 'False'

Ebenfalls einfach die beiden Toasts

{{ status.toast('a', 'TEST.TESTA', '', '', '', 'TESTA', 'TESTA', 'message_bell', '', 'R12.HAUSTUER.OEFFNER', '   Hier drücken zum Tür öffnen   ', 'true', 'true', '50000', 'slide', 'true', '#FFFFFF', '#FF1356', 1, 'left') }}
{{ status.toast('b', 'TEST.TEST', '', '', '', 'TEST', 'TEST', 'message_bell', '', 'R12.HAUSTUER.OEFFNER', '   Hier drücken zum Tür öffnen   ', 'true', 'true', '50000', 'slide', 'true', '#FFFFFF', '#FF1356', 1, 'left') }}

Was passiert?

Fall A:
TEST.TEST auf 1 --> Toast kommt
TEST.TEST auf 0 --> Toast geht
--> korrekt

Fall B:
TEST.TESTA auf 1 --> ToastA kommt
TEST.TESTA auf 0 --> ToastA geht
--> korrekt
--> Alleine gehen sie auf jeden Fall


Fall C:
TEST.TESTA auf 1 --> ToastA kommt
TEST.TEST auf 1 --> ToastA bleibt, neues ToastA kommt dazu und Toast ebenfalls
--> Es hätte kein zweites ToastA kommen dürfen!


Fall D1:
TEST.TEST auf 1 --> Toast kommt
TEST.TESTA auf 1 --> Toast bleibt und ToastA kommt dazu
--> okay
TEST.TESTA auf 0--> ToastA geht, Toast bleibt
TEST.TEST auf 0--> Toast geht auch
--> korrekt

Fall D2 (fast wie D1, aber das Rücksetzen umgekehrt):
TEST.TEST auf 1 --> Toast kommt
TEST.TESTA auf 1 --> Toast bleibt und ToastA kommt dazu
--> okay
TEST.TEST auf 0--> Es passiert nichts, beide Toasts bleiben stehen
TEST.TESTA auf 0--> ToastA geht, Toast bleibt stehen
--> eigentlich hätte Toast als erstes gehen müssen


Fall E1:
TEST.TESTA auf 1 --> ToastA kommt
TEST.TEST auf 1 --> ToastA bleibt und es kommt noch ein ToastA und ein Toast dazu
--> falsch, es hätte nur Toast dazukommen dürfen
TEST.TESTA auf 0 --> Toast geht, die beiden ToastA bleiben
--> falsch, hier hätten beide oder zumindest ein ToastA gehen müssen
TEST.TEST auf 0 --> Die beiden ToastA gehen hierbei
--> falsch, da eigentlich ToastA gar nichts mit dem gehenden Item zu tun hat

Fall E2 (fast wie E1, aber das Rücksetzen umgekehrt):
TEST.TESTA auf 1 --> ToastA kommt
TEST.TEST auf 1 --> ToastA bleibt und es kommt noch ein ToastA und ein Toast dazu
--> falsch, es hätte nur Toast dazukommen dürfen
TEST.TEST auf 0--> es passiert nichts, alle drei Toasts bleiben stehen
--> falsch, hier hätte Toast gehen müssen
TEST.TESTA auf 0--> Toast geht, die beiden ToastA bleiben
--> falsch, hier hätte ich erwartet, dass etwas mit den beiden ToastA passiert


Es sieht so aus, dass sich das Toast A verschluckt, da ein anderes Item im Itemnamen von dem ToastA enthalten und bereits aktiv ist.

Es reicht übrigens auch, wenn nur das ToastA im HTML angelegt ist und keine weiteren. Auch dann verschluckt sich das Toast.

Wie wird denn das Item dem Toast zugeorndet? Bei VisualBasic hatte ich auch mal solche Effekte, wenn man Texte vergleicht und das nicht binär macht. Da hat sich dann der Vergleicher auch irgendwie seltsam verhalten.

Vielleicht hilft das Beispiel ja noch, um der Sache auf den Grund zu gehen.

[wvhn]

loeserman
Vielen Dank! Du machst Deinem Namen wirklich alle Ehre 👍

Du bist da auf einen ganz alten Bug gestoßen, der sich offenbar nur beim Toast bemerkbar macht, weil hier mit dem item-Update eine sichtbare Aktion ausgelöst wird.

Hintergrund (TL;DR):
Bei item-Updates werden die Update-Methoden aller Widgets aufgerufen, die den jQuery-Selektor

$(sv.activePage).find('[data-item*="' + item + '"]')

erfüllen. Leider bedeutet das "*=", dass wenn TEST.TEST gesucht wird, sowohl TEST.TEST als auch TEST.TESTA gefunden werden und die Update-Methoden aller Widgets in der aktiven Seite aufgerufen werden, die diese items abonniert haben. Dabei erhalten die jeweiligen Widgets zuverlässig die richtigen Daten. Das kostet also nur Performance, ist aber in der Regel unschädlich. Leider funktioniert die Umstellung auf den Word-Selektor (also "~=" statt "*=") im Schnelltest nicht bei widgets mit mehreren items.

Ich teste mal weiter und melde mich, wenn ich eine Lösung habe. Vorerst sollte man item-Namen vermeiden, bei denen der Name eines items vollständig im Namen eines anderen items vorkommt.

Gruß
Wolfram

[loeserman]

Ah, aber nun wissen wir schon mal woran es liegt.

Sipple Das ist dann auch Dein Problem, da "Klingel" in "Klingelmeldung" enthalten ist. Wenn also "Klingelmeldung" schon 1 ist und nochmal das Item "Klingel" kommt, dann hast Du 2 Toasts.

Vieleicht findet Wolfram ja eine Lösung. Ist ja wirklich nur bei diesem Item so, da es aufpoppt und so eins dazu kommt. Wäre natürlich cool, wenn wir das optimieren können, da sonst bei hierarchischen Items immer die Parents die Child Items mit antriggern.

Das ganze passiert übrigens nur, wenn auch das Item TEST oder TEST.TEST auch auf der Seite angemeldet ist auf der das Toast auf TEST.TESTA lauscht. Es ist also schon ein besonderer Fall, aber dennoch vielleicht finden wir eine Lösung.

[Sipple]

Ich habe da ein etwas anderes Problem mit meinem Klingel-Toast.
Bei mir klappt das ja wie oben beschrieben fast so wie gewünscht.

Aber für meinen Geschirrspüler hab ich das Problem mit den zwei Toasts. Das muss ich mir anschauen.

Edit:

Das bekommt man doch gar nicht gelöst, wenn das Hilfsitem ein Child-Item ist, oder habe ich da einen Knoten im Hirn?

Kueche:
    Geschirrspueler:
        type: bool
        knx_dpt: 1
        knx_cache: 5/5/2
        Meldung:
            type: bool
            knx_dpt: 1
            knx_listen: 5/5/2
            autotimer: 10 = 1
            Toast:
                type: bool
                eval: not sh...()
                eval_trigger: ..​

Da ist doch ein Parent-Item per Definition IMMER vollständig im Child enthalten. D.h., man müsste die Struktur grundlegend ändern. Richtig?

[wvhn]

Im develop branch sind jetzt 2 Commits:

1. die item update Methode wurde umgestellt, so dass jetzt nur noch die vollen item-Namen ausgewertet werden. Damit sollte das Problem des Parent-items gelöst sein.
2. Das Widget status.toast hat bisher immer den zuletzt erschienenen Toast gelöscht, wenn ein item auf 0 ging. Jetzt bekommt jedes Widget eine eindeutige ID, auch wenn im Parameter-Satz keine id angegeben ist. Damit wird immer der dem jeweiligen item zugeordnete Toast geschlossen.

Für intensive Tests insbesondere der neuen update-Methode wäre ich dankbar. Ich habe einen Großteil der Doku und der Beispiele durchgetestet, aber es könnte noch Widgets geben, bei denen dies nicht funktioniert. (Abhilfe ist dann aber einfach).

Gruß
Wolfram

[loeserman]

Ich update mal und teste gern mit.

[loeserman]

wvhn Mensch so schnell schon umgebaut. Tolle Arbeit und vielen Dank für Deinen Einsatz (... wie immer)!

Also bei dem Toast sieht es schonmal gut aus. Da bekomme ich aktuell keine Fehler mehr hin. Lasse es mal mitlaufen und prüfe ob ich irgendwo anders etwas feststellen kann.

Mal sehen wie es bei Sipple läuft. Hoffe da klappt es dann auch gleich auf Anhieb.