Werteliste und Slider kein Refresh der kompletten Seite

[Hoschiq]

Der Fehler für das fehlerhafte aktualisieren der Werteliste beim Wert 0 liegt wohl in FW_select und ist wie von justme1968 vermutet:


Methode FW_select($$$$$@) -> erzeugt das select.

$def = zu setzender Wert.
$v = aktuell bearbeiteter Wert aus allen definierten Werten der Liste.

Code Auswählen Erweitern

if([b]$def[/b] && $v eq $def) {
$s .= "<option selected=\"selected\" value='$v'>$v</option>\n";
} else {
$s .= "<option value='$v'>$v</option>\n";
}

müsste dann wohl so heißen:

Code Auswählen Erweitern

if([b]defined($def) && $def ne ""[/b] && $v eq $def) {
$s .= "<option selected=\"selected\" value='$v'>$v</option>\n";
} else {
$s .= "<option value='$v'>$v</option>\n";
}


Ich kann es aber erst heute abend ausprobieren..

[rudolfkoenig]

wenn man dem dummy schon mit setList 'kommandos' oder widgets zu einem anderen reading als state zuordnen kann

Das geht mWn nicht. setList liefert nur die Antwort fuer "set dummy ?", sonst nichts. Alle anderen dummy set Befehle setzen state auf die mit Leerzeichen zusammengefuegten Argumente, andere Readings kann man via set nicht setzen.

setList test:1,2,3,4:r

Mit sowas fangen wir gar nicht an. Erstens riecht das nach Hack (== nicht intuitiv), zweitens betrifft es z.Zt. nur dummy, und gleich werden die Stimmen laut, sowas auch anderswo einzubauen, und drittens ist das mit einem notify trivial zu loesen.

Der Fehler für das fehlerhafte aktualisieren der Werteliste beim Wert 0 liegt wohl in FW_select

Habs geaendert und eingecheckt, danke fuer den Hinweis.


Falls Hoschiqs letzter Patch gefallen findet, dann kann ich es einbauen.

[justme1968]

wenn in einem dummy zwei unterschiedliche readings per webCmd auf unterschiedliche werte gesetzt werden sollen dann geht das nicht wirklich elegant. und wenn state dabei nicht angefasst werden soll geht es gar nicht mehr.

ich denke immer noch es wäre sehr hilfreich so etwas machen zu können:

Code Auswählen Erweitern

define d dummy
attr d setList on off reading1:1,2,3 reading2:3,4,5 reading3:slider,1,1,10
attr d webCmd on off reading1 reading2 reading3

damit kännte man z.b. wunderbar die steuerung für einen timer realisieren der über state ein und aus geschaltet wird und zeiten oder Intervalle in den readings hat.

bei einem dummy setreading statt set zu verwenden  wenn das reading nicht state ist (oder sogar immer setreading) wäre ein nützliches feature.

[Hoschiq]

Code Auswählen Erweitern

if([b]defined($def) && $def ne ""[/b] && $v eq $def) {

sollte natürlich

Code Auswählen Erweitern

if(defined($def) && $def ne "" && $v eq $def) {

heißen. Wollte den entsprechenden Teil nur hervorheben was im Code nicht geht.

Noch eine Frage zum Verhalten bei deaktiviertem longpoll.

Ist longpoll deaktiviert, wird mit der neuen Implementierung von Slider, Time, Werteliste die Oberfläche nicht mehr aktualisiert, da kein Reload der Seite durchgeführt wird.
Bei den Befehlen, die via Link dargestellt werden wird mit einem Javascript das Verhalten der Links abhängig von Longpoll geändert. Entweder Post oder Get.

Müsste man das nicht bei den Befehlen hier auch berücksichtigen?
Am einfachsten in der Art und Weise, dass direkt der passende Code (Get oder Post) von FHEMWEB geliefert wird ohne extra Javascript auf dem Client.

Beipiel für Werteliste:
Wenn Longpoll
    

Code Auswählen Erweitern

onChange = "FW_cmd('$FW_ME?XHR=1&cmd.$d=set $d $readng '+ this.options[this.selectedIndex].value+ ' &room=$FW_room')";
Sonst
    

Code Auswählen Erweitern

onChange = "window.location = '$FW_ME?cmd.$d=set $d $readng '+ this.options[this.selectedIndex].value+ ' &room=$FW_room'";

[rudolfkoenig]

Code Auswählen Erweitern

Müsste man das nicht bei den Befehlen hier auch berücksichtigen?
Bin etwas unsicher. Der Befehl wird doch abgeschickt, und wer longpoll deaktiviert hat, der erwartet nicht, dass Aenderungen sofort angezeigt werden. Allerdings ist der Zusatzaufwand minimal, und evtl. hilft das Diskussionen zu vermeiden.

@justme1968: auch wenn das in FHEM zunehmend falsch verwendet wird: Benutzer sollten Wuensche via Attribut und nicht via Reading dem Modul mitteilen, Reading sollte nur vom Programm geaendert werden. D.h. die konsequente Erweiterung des dummys waere ein attrList (analog zu setList), und nicht eine Zweckentfremdung von setList. Und wer diese Attribute direkt von der Raum-Ansicht aendern will, der moege bitte notifies definieren.

[justme1968]

falsch liegt hier im auge des betrachters

aber ernsthaft: selbst wenn ein attrList konsequent wäre haben die attribute den nachteil das man sie nicht in der raumübersicht oder dem floorplan ändern kann. man kann sie nicht einfach in die webCmd liste einfügen.

ich sehe das nicht als zweckentfremdung von setList sondern als nutzen der möglichkeiten die ein dummy bietet. es ist eine einfache möglichkeit (fast) ohne perl code dinge um gui zu machen die sonst nicht möglich wären. eben ein fhem device das auf fhem ebene erstellbar ist ohne perl oder internas wie setFn getFn zu benötigen. also mit recht 'einfachen' mitteln auch recht komplexe dinge inklusive ui zu ermöglichen.

ich weiss das es die angst gibt das fhem an der featureitis erkrankt und es wichtig ist nicht zu übertreiben. bei dieser erweiterung würde ich aber die vorteile für überwiegend halten. erst recht weil andere und vielleicht 'richtigere' lösungen noch sehr viel tiefgreifendere änderungen nötig machen würden.

[rudolfkoenig]

Tja, bleibt die Entscheidung zw. dem gefuehlt richtig und Mitarbeiter nicht vergraulen.
Ich bleibe beim letzteren (wie so oft bei FHEM), d.h. wenn Du sinnvolle Vorschlaege fuer dummy hast...

Mein Vorschlag: alles was im set mehr als ein Argument (Leerzeichen getrennt) hat, wird in dummy.pm zusaetzlich zu state auch als Reading angelegt. Aus deinem vorherigen Beispiel wuerde reading1,reading2,reading3 _auch_ als reading gesetzt, on/off nur als state.

[justme1968]

keine angst. ich lasse mich nicht so schnell vergraulen.

reading und state zu setzen ist glaube ich die schlechteste lösung.

die syntax erlaubt es  doch genau anzugeben welches set bzw reading gemeint ist.

dann lieber garnicht als halbherzig.

auf der anderen seite finde ich das so nützlich das es schade wäre nicht zu haben.

könnte man das _auch_ irgendwie konfigurierbar machen? also entweder nur state wie bisher, oder beides oder nur das reading wenn eines angegeben ist. wenn die funktionalität nach dummy.pm wandert ist es nur eine stelle.

[justme1968]

ich glaube ich habe jetzt einen vorschlag der dir gefallen wird

mit einer passenden trivialen setFn kann man das verhalten direkt mit einem readingsProxy abbilden. es ist weder eine änderung an den widgets noch an dummy nötig.

es bleibt also alles wie es ist und wer es anders möchte nimmt einem readingaProxy statt einem dummy.

[karl0123]

Zum Thema: Wird nun der letzte Patchvorschlag eingebaut? Grundsätzlich finde ich das Verhalten, wie es jetzt ist, inkonsistent. Nur bei der Werteliste aktualisiert sich die Seite. Danke.

[UliM]

Hi,
bei mir folgendes Verhalten nach einer Wertänderung über slider:
- fhemweb-Raumansicht: Seite wird auf PC/Firefox aktualisiert, auf iPad nicht
- floorplan: Seite wird weder auf PC noch auf iPad aktualisiert.
Hab jetzt hier nicht den ganzen Fred gelesen, in der Vergangenheit hat das aber funtktioniert und ich sehe die "Verbesserung" nicht...?

Falls das so bleiben soll: muss ich in floorplan was nachziehen?

Das Wiederherstellen der Seitenaktualisierung nach Slider-Änderung in fhemweb würd ich mir aber wünschen.

Gruß, Uli

[Hoschiq]

Hallo Ulli,

im Nachbar-Thread wird gerade das Problem mit Floorplan beschrieben und gelöst..
http://forum.fhem.de/index.php/topic,27447.msg203512.html#msg203512

Wenn longpoll im FHEMWEB nicht aktiviert ist funktioniert im Floorplan dann das Aktualisieren der Werte im Hintergrund nicht.
Die Einstellung scheint aber mal bei einem Update "verschwunden" zu sein, da ich Sie bei mir nicht deaktiviert hatte Sie aber nicht mehr vorhanden war.

Slider funktioniert bei mir auf PC und auf Android Geräten wie es soll mit Aktualierung im Hintergrund.
Tritt das Problem auf dem IPad bei dir z.B. auch bei Dropdowns auf ?

Falls ja tippe ich auf ein Problem im Zusammenspiel mit longpoll.

Wurde der zuletzt genannte Patch für Dropdown von denen, die mit der ersten Variante Probleme hatten, einmal getestet? Also die Probleme mit readings andere als state?

[UliM]

Hi,
auf der WEBtablet-Instanz ist bewust longpoll aus, da sonst die png-icons nicht dargestellt werden.
Wäre schade wenn man nun wählen müsste zwischen "keine icons" oder "keine Aktualisierung nach slider" - zumal das ja in der Vergangenheit gefunzt hat.
=8-)

[Hoschiq]

Hallo Uli,

das Problem welches du hast ist in Antwort 33 und 34 des Threads beschrieben.
Es fehlt aktuell die Beachtung von longpoll. Ist dieser deaktiviert, so mein Vorschlag, sollte das alte Verhalten (Reload der Seite) durchgeführt werden.

Allerdings habe ich noch nicht herausgefunden, wie man in den Javascripts von Slider und Time sicher herausfindet, ob in der aktuellen Webinstanz longpoll aktiviert ist oder nicht..

Hier würde ich Unterstützung von den Kennern von FHEMWEB benötigen. Evtl. weiß Rudolf da Rat?

[rudolfkoenig]

Allerdings habe ich noch nicht herausgefunden, wie man in den Javascripts von Slider und Time sicher herausfindet, ob in der aktuellen Webinstanz longpoll aktiviert ist oder nicht..

In diesem Fall ist die FW_pollConn JavaScript variable definiert und gefuellt mit readState, responeseText, usw.

Ich habe immer noch keine Antwort auf meine Frage, ob ich deinen letzten Patch einspeilen kann.
Beim "svn diff" faellt aber auf, dass CSRFTOKEN nicht verwendet wird. Ich meine aber, dass das beim aktivierten csrfToken notwendig ist.