RaspberryMatic - Verbesserungsvorschläge/Wünsche

[jmaus]

Hallo,
Firmw1019.JPG
ist es so gewollt?
Vorher war es weiß hinterlegt.
Sieht so auch gut aus

Ja, ist gewollt.

[jp112sdl]

Vielleicht kannst du selbst auch mal schauen/debuggen. Ich bin selbst da auch schon dran und ich konnte es schon auf die folgenden drei Zeilen reduzieren:

https://github.com/jens-maus/RaspberryM ... #L119-L121

Das ist genau die Schleife mit der "tmp"-Variable, die vorher von der datapointconfigurator.fn
https://github.com/jens-maus/RaspberryM ... s.htm#L195
und HideCertainParameters überschrieben wurde.

Wenn man den Patch mit der Umbenennung nach "tmpHCP" wieder rückgängig macht, kommt bestimmt wieder der Skriptfehler, aber die Bilder bauen sofort richtig auf?

Ich kann erst morgen weiter testen

[jmaus]

Vielleicht kannst du selbst auch mal schauen/debuggen. Ich bin selbst da auch schon dran und ich konnte es schon auf die folgenden drei Zeilen reduzieren:

https://github.com/jens-maus/RaspberryM ... #L119-L121

Wenn man den Patch mit der Umbenennung nach "tmpHCP" wieder rückgängig macht, kommt bestimmt wieder der Skriptfehler, aber die Bilder bauen sofort richtig auf?

Nein, das scheinen zwei unabhängige Probleme zu sein, denn ich hab das "tmpHCP" gerade mal zurück in "tmp" umbenannt und das Problem mit den überlagerten Gerätebildern taucht trotzdem auf.

Abgesehen davon bin ich inzwischen mit meinem Debugging in ReGaHss soweit, das ich sagen kann, das du wohl einen Sechser im Lotto gemacht hast Da ist nämlich in der Tat ein Laufzeit-Bug in der foreach() Funktion, der nicht nur dieses Problem komplett erklärt (ich kann das nämlich sehr gut reproduzieren und auf die foreach() Funktion schieben), sondern auch die doppelt auftretenden WebUI Elemente erklären könnte denen wir ja schon länger auf der Spur sind, aber eben nie einen reproduzierbaren Fall gefunden hatten!

Und nachdem ich nun in ReGaHss das Problem nicht nur auf die foreach() funktion eingrenzen konnte, sondern auch einen Bugfix dafür bereits einbauen konnte funktioniert das hier in meiner Testumgebung nun tadellos und es kommt nicht mehr zu dieser doppelten Darstellung von Kanälen inkl. der Gerätebilder. Fehlt also nur noch der Test in der Breite, aber dafür muss ich erst eQ3 bitten eine neue Version von ReGaHss im OCCU bereit zu stellen damit ich das dann in RaspberryMatic entsprechend einbauen kann. Ich bin mir aber recht sicher das das nicht nur das Problem, sondern viele andere Probleme (und sogar hier/da versteckte Probleme) mit der nutzung der foreach() Schleifenfunktion erklären könnte und dann auch diese doppelten WebUI Elementdarstellungen erklärt. Dann hat also diese ganze WebUI Verbessungstortur die letzten Tage ja auch unterm Strich sogar geholfen einen wichtige Bug zu Tage zu fördern und mit deiner immensen Hilfe dann auch zu eliminieren! Danke schonmal dafür

[MichaelN]

Hochinteressant. 2 Fragen habe ich dazu:
kannst Du näher erklären unter welchen Bedingungen der Fehler auftritt und wie er sich bemerkbar macht

Und verstehe ich das richtig

eQ3 bitten eine neue Version von ReGaHss im OCCU bereit zu stellen

das Du das nicht ohne die Mitarbeit von eq3 fixen kannst?

[jmaus]

kannst Du näher erklären unter welchen Bedingungen der Fehler auftritt und wie er sich bemerkbar macht

Zu 100% kann ich es leider nicht erklären warum foreach() nicht wie geplant durch die tab-getrennte Liste durchlief wie in dem gezeigten Fall. Aufgetreten ist dies jedoch wohl nur sehr seltenen Fällen und der Grund dafür wird darin begründet sein, das es unter gewissen bedingungen dazu gekommen ist das die zu setzende Variable nicht den korrekten Wert erhalten hat weil intern eine falsche Methode verwendet wurde um diese zu setzen.

Und verstehe ich das richtig

eQ3 bitten eine neue Version von ReGaHss im OCCU bereit zu stellen

das Du das nicht ohne die Mitarbeit von eq3 fixen kannst?

Fixen kann ich das schon (und hab ich ja hiermit) weil ich ja den Quellcode dafür habe. Nur kann/darf ich eben ohne die Erlaubnis von eQ3 keine neuen Binaries von ReGaHss selbst veröffentlichen.

[jp112sdl]

Cool, das war ja dann sehr ein produktiver Tag
Und ich brauch nicht grübelnd ins Bett gehen, wie ich da morgen weiter auf Fehlersuche gehen könnte

[jp112sdl]

Ich war jetzt mal so tollkühn und hab den nightly build 20211019 ins Produktivsystem eingespielt.
Technisch hat sich ja nichts geändert, nur optisch und da habe ich die meisten Geräte nun mal dort.

Was mir auffällt:

Die Gerätesymbole sind nicht zentriert sondern linksbündig?
Scheint nur bei dem Zwischenstecker der Fall zu sein.

Und die Favoriten auf der Startseite sind jetzt extrem breit auseinandergezogen. Ich gewöhne mich hoffentlich dran

Was vorher so aussah (Testsystem ältere Version):

ist nun so (Produktiv mit nightly build):

[jp112sdl]

In "Programme" ist die Aufteilung auch irgendwie ungünstig.

Die rechte Spalte "Aktion" nimmt zu viel Platz ein, während der Text in "Bedingung" gequetscht ist

[MichaelN]

Ich weiß auch nicht, ob es eine gute Idee ist auf einem Monitor mit hoher Auflösung im Vollbild den ganzen verfügbaren Raum zu nutzen. Dann gibt es viel weißen Raum... Vielleicht mit Max-width die Breite begrenzen?

[Baxxy]

Neuer Wunsch...
Anzeige des aktiven Modus (Stichwort Kindersicherung) im Kopfbereich, vielleicht hinter dem angemeldeten Usernamen.

Da ich tatsächlich kürzlich auch mal auf den "vereinfachten Modus" hereingefallen bin und es häufig diverse Problemchen gibt wenn die "Kindersicherung" aktiv ist wäre es vielleicht sinnvoll immer zu erkennen welcher Modus gerade aktiv ist.

Ein einfacher Hinweis "vereinfachter Modus aktiv!" sollte eigentlich reichen.

Grüße, Baxxy