RaspberryMatic
RaspberryMatic copied to clipboard
Inkonsistenzen bei den gesetzten Filtern in der WebUI - "sticky Filter Problem"
Describe the bug Fehler A: Setzt man einen Namensfilter z.B. "filter_sv" bei Status und Bedienung --> Systemvariablen wird dieser Filter auch bei Programme und Zentralenverknüpfungen sowie bei Status und Bedienung --> Geräte (erstes Gerät ist automatisch selektiert) --> rechts bei Kanal gesetzt. Das gleiche tritt auf wenn man bei Programme und Zentralenverknüpfungen mit dem setzen eines Filters beginnt.
Fehler B: Dieser gesetzte Filter aus A lässt sich bei Status und Bedienung --> Systemvariablen sowie bei Programme und Zentralenverknüpfungen durch setzen eines "leeren" Filters löschen. Das geht aber nicht bei Status und Bedienung --> Geräte (siehe A). Hier lässt sich zwar der Filter augenscheinlich auch durch setzen eines leeren Filters löschen, ist aber bei Neuaufruf der Rubrik wieder vorhanden.
Fehler C-1: Setzt man innerhalb eines WebUI Programms über Systemzustand -- > Systemvariablenauswahl im Fenster Programme - Systemvariablenauswahl einen Namensfilter kommt es erstmal wieder zu Fehler A und B.
Fehler C-2: Wiederholt man C-1 (um z.B. eine weitere SysVar im Programm hinzuzufügen) ist im Fenster Programme - Systemvariablenauswahl der Filter nicht mehr gesetzt.
Fehler C-3: Wir sind fertig mit unserem Programm und haben den Filter wie unter B beschrieben gelöscht. Augenscheinlich sind alle Filter weg. Wir wiederholen C-1 aber ohne im Fenster Programme - Systemvariablenauswahl etwas zu filtern. Schon beim schließen des Programms sehen wir das es wieder zu A und B mit dem in C-1 gesetzten Filter gekommen ist.
Der durch C-1 gesetzte Filter lässt sich effektiv nur löschen indem man im selben Fenster einen leeren Filter aktiv setzt. D.h. Filter anklicken und das leere Eingabefeld mit setzen schließen.
To Reproduce Steps to reproduce the behavior:
- Die Fehlerbeschreibung ist gleichzeitig ein Ablauf zum nachstellen.
Expected behavior Zu A u. B u. C:
- So wie ich es verstanden habe und es mir vorstelle sollte jede Kategorie ihre eigenen Filter haben und auch behalten.
- Kein Filter einer Kategorie sollte den Filter einer anderen Kategorie beeinflussen (Ausnahme könnte hier Status und Bedienung --> Systemvariablen + Systemvariablenauswahl im Fenster Programme - Systemvariablenauswahl sein)
System information (please complete the following information):
- Version [RaspberryMatic 3.53.30.20200919]
- Hardware [RaspberryPi4B-2gb]
Additional context Drauf gekommen bin ich durch den Thread im Homematic Forum und anschließendem Trial and Error. Da es bei einer CCU3 die "sticky Filter" und somit die Probleme nicht gibt könnte es mit den Patches: 0029-WebUI-Fix-Variable-selection-and-filter.patch und / oder 0056-WebUI-Sticky-Filters.patch zu tun haben. Danke an @jp112sdl für die Info diesbezüglich.
Der Filter wird sich ja zur pageID
"gemerkt".
Meine Vermutung: Das SV-Auswahl-Popup hat keine eigene eindeutige pageID
(oder sie wird fälschlicherweise nicht berücksichtigt), so dass der Filter der Main-Page zugeordnet wird.
Irgendwas haut mit dem LocalStorage nicht hin. Im Browser sieht man schön, dass beim Setzen des Filters im SV-Popup der Filter-Wert zum Key iseFilters_fltSVS
gespeichert wird.
Kehrt man aus der Programmbearbeitung zurück zur Programmliste, wird dieser Filter auf einmal auf eine andere pageID
angewendet... iseFilters_fltVR
@jp112sdl danke für deine Analysen. Vielleicht kann @psi-4ward hier ja Licht ins Dunkel bringen der ja der ursprüngliche Autor des Sticky Filter WebUI Patches ist.
Die Sache mit den Filtern ist leider etwas hacky (so wie die ganze extrem veraltete WebUI). Leider habe ich aktuell nicht die Zeit hier Arbeit rein zu stecken. Das "schön" zu machen ist bei dieser Code-Base nicht wirklich möglich.
@psi-4ward Ok, danke für die Klärung. Dann müssen wir uns da selber durchwühlen und schauen ob wir das noch repariert bekommen.
Das die WebUI veraltet ist steht ausser Frage, das ist so. Aber wir müssen vmtl. noch sehr lange damit leben. Ausser es setzt sich nen talentierter Webentwickler mit viel Zeit mit mir zusammen und wir klügeln einen Plan aus wie man die WebUI gegen etwas neues/modernes ersetzen kann. Wie angedeutet würde das aber bedeuten VIEL Zeit investieren zu wollen, denn der Anspruch wäre schon mindestens die Funktionalitäten abzubilden die die WebUI momentan zur Verfügung stellt. Und inwieweit man dann die Gerätekonfiguration, usw. mit ähnlichem Aufwand und kompatibel zu zukünftigen Anpassungen bzw. neuen Geräteintegrationen von eQ3 bekommt steht hier noch komplett in den Sternen ;)
Ich glaube ein großes Manko an dem Sysvar-Auswahl-Popup ist, dass es nicht über die Methode updateContent(...)
geladen wird und somit auch keinerlei Events, wie z.B. ContentLoaded
angehängt werden, was wiederum ein restoreFilters
auslösen würde.
Kurzfristige Lösungen wären daher wohl,
- das Problem als "Known (non-critical) Bug" einstufen
- die
setSFilter
-Funktion auf nicht-fltSVS
zu begrenzen, so dass Filter in dem Popup gar nicht erst persistiert werden
Da ich auch heute darüber gestolpert bin, möchten wir an dem Thema noch arbeiten?
IMHO wäre es ja schon mal ein Fortschritt im Sinne von "weniger störend" wenn man den sticky Filter für die SV deaktivieren würde.
Thanks for your contribution! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of RaspberryMatic and tell us. Also check that all relevant details,
Vielen Dank für die Unterstützung! Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüfen Sie, ob das Problem auch in der aktuellsten Version von RaspberryMatic noch relevant ist, und teilen Sie uns dies mit. Überprüfen Sie auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind oder aktualisiert werden müssen.
This issue has been automatically closed because of inactivity. Please open a new issue if still relevant and make sure to include all relevant details, logs and reproduction steps.
Dieses Problem wurde aufgrund von Inaktivität automatisch geschlossen. Bitte öffnen Sie ein neues Issue, falls dies noch relevant ist und stellen Sie sicher das alle relevanten Details, Logs und Reproduktionsschritte enthalten sind.
Da sich an der Problematik nichts geändert hat wäre es gut wenn das Issue wieder geöffnet wird.
Bitte mal mit dem nächsten nightly snapshot testen ob die/welche sticky filter probleme dann noch so existieren. Hab da in commit 43090b1 jetzt ein paar Anpassungen gemacht die die Situation merklich verbessern sollten.
Es wird... 😉
Fehler A + B sind ausgemerzt.
Fehler C-1 hat sich verändert. Setzt man innerhalb eines WebUI Programms über Systemzustand -- > Systemvariablenauswahl im PopUp-Fenster Programme - Systemvariablenauswahl einen Namensfilter ist dieser (nach beenden der Programmeditierung in Programme und Verknüpfungen > Programme beim Namen drin. Lässt sich dort aber löschen.
Fehler C-2 besteht weiterhin. Wobei das akzeptabel ist das man beim erneuten Aufrufen des "Systemzustandes" wieder ohne Filter anfängt.
Fehler C-3 ist in der Form auch weg.
Bleibt also C-1 in neuer (abgeschwächter) Form.
Danke fürs checken. Geht voran :) Kannst du mir dann bitte noch für C-2 ein Screencast machen und hier posten, dann versuch ich das auch mal zu reproduzieren und vielleicht finden wir ja dann dafür auch noch ne Lösung.
Ich denke wir sollten C-2 "vergessen", bzw. ich bin mir nicht sicher was "besser" ist. A: Bei der Systemvariablenauswahl immer ohne Filter beginnen B: Bei der Systemvariablenauswahl immer mit dem "irgendwann mal" gesetzten Filter beginnen
Beides hat imho Vor/Nachteile, ich tendiere aber eher zu A da man ja i.d.R. verschiedene SysVars als Trigger/Bedingung nutzt.
Kommt natürlich auch auf die jeweilige Namensgebung an, z.B. xyz_Temperatur. Da könnte man mit "Temperatur" alle filtern egal wie der Präfix ist.
Deine Entscheidung. 😉
@Baxxy13 So, mit den gerade vorgenommenen Änderungen in 92ad53c sollten die letzten beiden Sticky Filter Probleme hoffentlich auch der Vergangenheit angehören.
Bitte aber nochmal ausführlich testen - lasse das Ticket hier solange offen. Und falls du noch andere Filterprobleme findest dann bitte zeitnah her damit da ich aktuell ja in dem Thema drinstecke ;-)
Also C-1 ist nun auch ausgemerzt. Sehr gut.
Bei C-2 hast du dich entschieden den Filter drin zu lassen, das funktioniert soweit auch. Nur leider wirkt der Filter beim erneuten Öffnen von "Systemzustand -- > Systemvariablenauswahl im PopUp-Fenster Programme - Systemvariablenauswahl" nicht. Soll heißen der Filter steht drin aber es wird nicht gefiltert. Ich muss ihn erst "öffnen" und auf "setzen" klicken damit gefiltert wird. Kann das aktuell aber nicht aufzeichnen.
Ich hätt's gelassen wie es war (C-2). Nach dem "drüber schlafen" bin ich der Meinung das es "besser" ist an dieser Stelle immer ohne Filter zu beginnen.
Ich hätt's gelassen wie es war (C-2). Nach dem "drüber schlafen" bin ich der Meinung das es "besser" ist an dieser Stelle immer ohne Filter zu beginnen.
Die beiden Probleme hingen im Grunde zusammen und hatten den selben Ursprung. Kann prinzipiell verstehen das man es auch für nützlich erachten könnte das dort bei der SysVarAuswahl in dem PopUp fenster quasi kein Filter aktiv war. Aber da das nur dort der Fall war und z.B. bei einer anderen PopUp-Art (Geräteauswahl) das nicht der Fall war und eben die beiden Dinge C-1/C-2 einen Ursprung hatten habe ich mich dafür entschieden das konsistenz wichtiger ist. Nun sollten alle sticky filter auch entsprechend agieren.
Danke nochmal für das melden dieser sticky filter probleme die nun hoffentlich alle gelöst sein sollten.