Erster Eintrag der "set" Liste macht kein "refresh"

[Adimarantis]

Hallo,

mir ist schon länger aufgefallen, dass beim ersten Eintrag der "set" Liste die Kurzhilfe nur dann angezeigt wird, wenn man auf einen anderen Eintrag und dann wieder zurück geht.
Zugegeben etwas schwierig zu lösen da ja meist "set" und "get" auf den ersten Eintrag initialisiert werden, wenn man die Seite öffnet - was sollte man nehmen?

Jetzt ist mir aber noch ein Unterschied aufgefallen, der eindeutiger ist:
Bei jedem "set" Befehl wird der Seite nach Ausführung "refreshed", d.h. auch die FW_detailFn aufgerufen, so das dortige dynamische Inhalte aktualisert werden.
Nur beim ersten Befehl der "set" Liste passiert das nicht - da bleibt alles so stehen, was mich gerade in der Modulentwicklung (aufgrund der dynamischen Inhalte) extrem stört. Ist das so gewollt, ein Bug - oder mache ich etwas falsch?

Jörg

[Adimarantis]

Vielleicht noch eine Anregung:

Es wäre Klasse, wenn man irgendwie beinflussen könnte, welches der erste Eintrag in der Liste ist (statt einfach alphabetisch). Das wäre auch ein Workaround für mein Problem.
Ich schätze mal deswegen hat Telegrambot ein redundantes set "_msg", denn das ist ja die Kernfunktionalität und steht sinnvollerweise als default vorne.
Mir gefallen redundante Einträge aber nicht so (macht die set Liste unübersichtlicher).
Eine Idee: Wenn z.B. "_msg" und "msg" definiert ist (Telegrambot), dann werden beide Einträge in der Liste zusammengeführt und nur als "msg" dargestellt, aber an den Anfang gestellt.
Oder einfach im Type ("default,textField" oder "*textField").
Oder noch gezielter im Type mit Sortierung: "1:textField" , "2:noArg" ....
Oder gibts es das gar schon und ich finde es einfach nicht in der Doku?

Jörg

[rudolfkoenig]

Bei jedem "set" Befehl wird der Seite nach Ausführung "refreshed", d.h. auch die FW_detailFn aufgerufen, so das dortige dynamische Inhalte aktualisert werden. Nur beim ersten Befehl der "set" Liste passiert das nicht

Das kann ich so nicht nachstellen, ich sehe den refresh nur bei attr oder bei "set attrTemplate". Kannst du mir was Konkretes zum Nachstellen zeigen?

Wegen Sortieren: erstens bin ich unsicher, ob eine Modulspezifische Sortierung ueberhaupt sinnvoll ist.
Wenn Andere sich auch dafuer aussprechen, dann muesste man eine Modul- und eine Instanzpezifische Moeglichkeit schaffen, die Liste zu sortieren. Einen Hack wie Prefix oder doppelte Eintraege will ich vermeiden, weil diese Liste nicht nur in FHEMWEB verwendet wird.

[Beta-User]

Weiß nicht, ob man es modulspezifisch braucht, und ob es überhaupt in allen Fällen wünschenswert ist, das sortieren zu können, aber attrTemplate vorne oder blink als 2. finde ich eigentlich auch nicht in allen Fällen die optimale Lösung, dto. für case-Sensivität.

Evtl. könnte man einfach die Reihenfolge beachten, die getAllSets liefert? Dann hätte es der Modulautor durch das

Code: [Auswählen]

return "Unknown argument, choose one of execNow:noArg active:noArg inactive:noArg"
      if $arr[1] eq '?';in der Hand...?

[rudolfkoenig]

Evtl. könnte man einfach die Reihenfolge beachten, die getAllSets liefert?

Erstens ist das nicht ganz so einfach (sort ist relativ tief versteckt), zweitens wuerde das zunaechst zu "Unordnung" in den meisten Modulen fuehren.

[Adimarantis]

Evtl. könnte man einfach die Reihenfolge beachten, die getAllSets liefert?

Grundsätzlich würde das funktionieren - schmeisst nur bei allen Modulen die sich auf die Sortierung verlassen die sets möglicherweise durcheinander, was potentiell die Anwender verwirren wird. (da war Rudi schneller)

Vor kurzem wurde ja eine Gruppierung in den Attributen eingebaut, was die Übersichtlichkeit sehr erhöht hat. Sowas wäre bei Modulen die sehr viele sets/gets haben auch recht nett - greift natürlich noch tiefer in das Konzept ein.

Ich finde ja generell, dass der Rückgabewert der "set" Funktion geparsed wird ein gewöhnungsbedürftiges Konzept. Ich weiss, ich mache da jetzt ein grosses Fass auf, aber da könnte man sich auch überlegen einen spezifischen API Call zur Verfügung zu stellen (nimmt einen %sets Hash als Parameter) - da könnte man dann auch Sortierung, Divider, Überschriften etc. abbilden da es nicht rückwärtskompatibel sein muss.

Das kann ich so nicht nachstellen, ich sehe den refresh nur bei attr oder bei "set attrTemplate". Kannst du mir was Konkretes zum Nachstellen zeigen?

Ok, ich hatte gehofft das es da einen offensichtlichen Unterschied gibt. Dann muss ich mal sehen, das ich ein Minimalmodul baue. Vielleicht habe ich ja selbst noch irgendeinen Unterschied drin, der mir bei meinem doch recht grossen Modul einfach nicht auffällt.

[Beta-User]

Das mit der Verwirrung ist klar, eventuell müßte man da irgendeine Art Übergangszeit einplanen, modulseitig ein Flag setzen können o.Ä..

Andererseits ist es an dieser Stelle ja von den Maintainern relativ leicht zu "reparieren", und man könnte klarer machen, was ggf. "im Modul" abgebildet wird, und was dann an SetExtensions weitergegeben wird (falls es z.B. eine modulinterne Implementierung für on-for-timer gibt). Hier entstehen nämlich andererseits auch immer wieder Fragen, weil nicht klar ist, dass z.B. bei CUL_HM der Timer auf dem Aktor läuft (kein gutes Beispiel, denn das reicht "den Rest" nicht an SetExtensions durch).

Nachtrag: Da jede neue Art der Sortierungsmöglichkeit Rückfragen der User provozieren wird, ist es m.E. fast egal, wie herum man das angeht... Der eigentliche Unterschied zu einem zusätzlichen Hash besteht dann darin, dass es der jeweilige Maintainer in der Hand hätte, wann bestimmte Sortierungen dann greifen.

[Adimarantis]

Ok, mein Minimodul mit 2 "sets" verhält sich wie gewünscht.
Ich finde nur nicht was mein Modul bei diesem einen "set" Punkt anders macht - und bevor ich den Namen so geändert hatte, das es "erster" wurde hatte es auch geklappt (oder ich hab im selben Zuge was anderes geändert?). Da muss ich wohl selber erstmal weiter stöbern.

Die Diskussion was man an der Sortierung/Darstellung der "sets" verbessern könnte, finde ich aber weiter interessant. Kommentare dazu?

Jörg

[Adimarantis]

Ich glaube ich das Szenario gefunden!

Das Problem tritt auf, wenn es ein Reading gibt, das den selben Namen hat wie das "set"!

Wenn man das reading mit setreading/deletereading erstellt/löscht kann man das wunderbar nachstellen.

Ich hänge mal mein Mini Modul an.
Wenn man hier die beiden "set" Befehle ausführt, dann wird dynamisch das Detail geändert und immer aktualisert.
sobalb man z.B.

Code: [Auswählen]

setreading test account xxxxmacht, funktioniert das plötzlich für das eine "set" nicht mehr wie gewohnt (erst nach einem Browser refresh)

Ich hoffe damit kann man der Sache auf den Grund gehen.

Gruß,
Jörg

[rudolfkoenig]

Das Problem tritt auf, wenn es ein Reading gibt, das den selben Namen hat wie das "set"!

Wenn bei set oder attr ein Element mit dem gleichen informid Attribut auf der Seite vorhanden ist, dann wird kein reload durchgefuehrt, weil in diesem Fall nur der Inhalt des Readings/Attributes aktualisiert werden muss, und das passiert automatisch per longpoll, d.h. man kann das Laden der Seite sparen.

[Adimarantis]

Ok, heisst das ich muss einfach darauf achten, dass sets, gets, attribute und readings immer unterschiedliche Namen haben müssen?

Mir ist das schon an anderer Stelle aufgefallen, dass sich manche attr oder set Kommandos "komisch anfühlen" - wohl weil man kein optisches Feedback (durch den refresh) bekommt. Da ist man dann versucht mehrmals zu klicken weil man das Gefühl hat FHEM reagiert nicht. Ich schätze mal auch hier die Namensgleichheit zuschlägt.

Kann man diese ID nicht eindeutiger machen um dieses Verhalten konsistenter zu machen?

[rudolfkoenig]

Noch eindeutiger als gleich?

[Adimarantis]

Was meinst du jetzt?

Ich würde bevorzugen, wenn sich alle Aktionen gleich verhalten und nicht davon abhängen ob es Readings mit dem gleichen Namen gibt.
Vielleicht noch ein Aspekt hierbei:
Wenn ich einen "set" Befehl ausführe, der nicht der erste in der Liste ist, dann springt die "set" liste zurück auf den ersten Eintrag.
Wenn es aber ein reading mit dem selben Namen gibt, dann bleibt "set" auf dem aktuellen Befehl stehen.

Kann ich den "refresh" irgendwie manuell auslösen? (sonst muss ich für meinen Anwendungsfall jetzt wirklich readings oder set Befehle umbenennen um das erwünschte Verhalten zu bekommen)

[rudolfkoenig]

Ich würde bevorzugen, wenn sich alle Aktionen gleich verhalten und nicht davon abhängen ob es Readings mit dem gleichen Namen gibt.

Ich bin anderer Ansicht: Ich versuche bestimmte haeufig auftretende Faelle zu optimieren.
Das "Zurueckspringen" ist ein Artifakt des Seite-Neu-Ladens.

Kann ich den "refresh" irgendwie manuell auslösen? (sonst muss ich für meinen Anwendungsfall jetzt wirklich readings oder set Befehle umbenennen um das erwünschte Verhalten zu bekommen)

Du kannst per eigenes JavaScript das Verhalten ueberschreiben.

[Adimarantis]

Ich bin anderer Ansicht: Ich versuche bestimmte haeufig auftretende Faelle zu optimieren.

Da bin ich bei dir. Ich plädiere einfach nur für ein deterministisches Verhalten. Ich weiss nicht wie viele Stunden ich jetzt gesucht habe, bis ich drauf gekommen bin dass die Ursache des "Problems" einfach die Namensgleichheit zwischen "set" und "reading" ist.