Hallo,
ich verwende bei mir die Werteliste und den Slider im FHEMWEB an einigen Dummy Devices.
Dabei ist mir aufgefallen, dass bei einer Wertänderung in der Werteliste und im Slider ein reload der kompletten Seite durchgeführt wird.
Das ist bei längeren Seiten insofern unschön, da man nach Wertänderung immer wieder an die Stelle scrollen muss, an der man gerade den Wert geändert hat.
Bei der Definition verwende ich ausschließlich setList und Webcmd.
Beispieldefinition:
define test1 dummy
attr test1 setList state:2,3,4,5,7,9,10,12,15
attr test1 webCmd state
define test2 dummy
attr test2 devStateIcon 1:HomeStatus.1 2:HomeStatus.2 3:HomeStatus.3 4:HomeStatus.4
attr test2 setList state:slider,1,1,4
attr test2 webCmd state
Verwende ich allerdings an einem Dummy, welcher nur on off unterstützt das Attribut devStateIcon, dann kann ich mit einem Klick auf das Icon oder auf das WebCmd den State ändern, ohne dass die ganze Seite neu geladen wird.
Beispieldefinition:
define test dummy
attr test devStateIcon on:remotecontrol/black_btn_GREEN:off off:remotecontrol/black_btn_RED:on
attr test setList on off
attr test webCmd  
Liegt das Verhalten von Werteliste und Slider bei Wertänderungen die Seite neu zu laden an meiner Definition? Wie kann man den beiden beibringen, dass bei Wertänderung nicht die ganze Seite neu geladen werden soll?
Danke
Habs geaendert, die naechste Version laedt die Seite bei Aenderung der Slider nicht mehr neu.
Hallo Rudolf,
danke für die Änderung.
Ich hätte noch einen Patch für fhemweb_time.js. Bei time gab es auch das Verhalten des Reloads der kompletten Seite nachdem die neue Uhrzeit eingestellt und mit dem Button bestätigt wurde.
In der Funktion FW_timeCreate(el,cmd) muss document.location = cmd.replace('%',v); durch FW_cmd(cmd.replace('%',v)+"&XHR=1"); ersetzt werden.
Danke fuer den Hinweis, habs eingecheckt.
Hallo,
nachdem die Slider nun keine Seite mehr neu laden fehlt nur noch das Dropdown ohne Relaod.
Allerdings komme ich hier nicht weiter und benötige etwas Hilfe:
die folgende Definition:
define dropdownTest dummy
attr dropdownTest room Test
attr dropdownTest setList state:0,2,4,6
attr dropdownTest webCmd state
erzeugt diesen HTML Code:
<tr class="even"><td><div class="col1"><a href="/fhem?detail=dropdownTest">dropdownTest</a></div></td>
<td informId="dropdownTest"><div id="dropdownTest" class="col2">4</div></td>
<td colspan='2'><form method="post"><input type="hidden" name="arg.dropdownTest" value="state"/><input type="hidden" name="dev.dropdownTest" value="dropdownTest"/><input type="hidden" name="room" value="Test"/><select onchange="submit()" id="dropdownTest-state" informId="dropdownTest-state" name="val.dropdownTest" class="dropdown"><option value='0'>0</option>
<option value='2'>2</option>
<option selected="selected" value='4'>4</option>
<option value='6'>6</option>
</select><input type="hidden" name="cmd.dropdownTest" value="set"/></form></td>
</tr>
</table>
</td></tr>
Hier wird durch das submit des Forms beim onChange ein Neuladen der Seite nach absenden des Formulars ausgelöst.
Ich habe durch Anpassen der beim onChange aufgerufenen Methode statt eines Posts nun ein GET daraus gemacht, dem der aktuell gewählte Wert mitgegeben wird.
onchange="FW_cmd('/fhem?XHR=1&cmd.dropdownTest=set dropdownTest '+ this.options[this.selectedIndex].value+ ' &room=Test')"
Jetzt ist aber noch folgendes offen:
1. an welcher Stelle wird das Select mit den options im fhemweb definiert. Habe schon in 01_FHEMWEB.pm geschaut aber nix gefunden.
2. ich bin mir nicht sicher ob das nur für den state eines devices funktioniert oder aber auch für andere Readings
Ich hoffe Rudi kann hierzu etwas sagen..
Danke.
Die zustaendige Stelle in 01_FHEMWEB.pm ist in FW_dropdownFn, und der ist in $data{webCmdFn} eingetragen, als Fallback.
FW_dropdownFn ist fehlerhaft (verwendet form, was in einem weiteren form sein kann, was IE stoert) und ueberkompliziert, und ich wuerde es heute als javascript-only bauen. Alle webCmdFn sind noch doppelt angelegt, einmal in FHEMWEB und einmal in JavaScript, die FHEMWEB Versionen muessten eigentlich alle rausfliegen.
Allerdings habe ich gerade nicht die Muße alles umzubauen, und mit allen Randbedingungen (FLOORPLAN/Raum-Ansicht,Detail-Ansicht, etc) zu testen, sorry.
Ich habe die Methode FW_dropdownFn in 01_FHEMWEB.pm überarbeitet. Dabei habe ich das Form und die Hidden Fields entfernt.
Bei Auswahl des neuen Wertes wird ein Get zum Wert übermitteln verwendet.
Die Funktion scheint nur in der Raumsicht verwendet zu werden, in der Detailsicht wird eine andere verwendet, es muss daher dort wie bei Slider und Time der Button set und ein Page reload verwendet werden.
Mit der Modifikation verhält sich die Werteliste nun analog zu Slider und Time.
FW_dropdownFn()
{
my ($FW_wname, $d, $FW_room, $cmd, $values) = @_;
return "" if($cmd =~ m/ /); # webCmd temp 30 should generate a link
my @tv = split(",", $values);
# Hack: eventmap (translation only) should not result in a
# dropdown. eventMap/webCmd/etc handling must be cleaned up.
if(@tv > 1) {
my $txt;
if($cmd eq "desired-temp" || $cmd eq "desiredTemperature") {
$txt = ReadingsVal($d, $cmd, 20);
$txt =~ s/ .*//; # Cut off Celsius
$txt = sprintf("%2.1f", int(2*$txt)/2) if($txt =~ m/[0-9.-]/);
} else {
$txt = ReadingsVal($d, $cmd, Value($d));
$txt =~ s/$cmd //;
}
my $fpname = $FW_wname;
$fpname =~ s/.*floorplan\/(\w+)$/$1/; #allow usage of attr fp_setbutton
my $fwsel;
$fwsel = ($cmd eq "state" ? "" : "$cmd ") .
FW_select("$d-$cmd","val.$d", \@tv, $txt,"dropdown","FW_cmd('$FW_ME?XHR=1&cmd.$d=set $d '+ this.options[this.selectedIndex].value+ ' &room=$FW_room')");
return "<td colspan='2'>".
"$fwsel</td>";
}
return undef;
}
Der folgende HTML Code wird daraus erzeugt.
<tr class="even"><td><div class="col1"><a href="/fhem?detail=dropdownTest">dropdownTest</a></div></td>
<td informId="dropdownTest"><div id="dropdownTest" class="col2">4</div></td>
<td colspan='2'><select onchange="FW_cmd('/fhem?XHR=1&cmd.dropdownTest=set dropdownTest '+ this.options[this.selectedIndex].value+ ' &room=Test')" id="dropdownTest-state" informId="dropdownTest-state" name="val.dropdownTest" class="dropdown">
<option value='0'>0</option>
<option value='2'>2</option>
<option selected="selected" value='4'>4</option>
<option value='6'>6</option>
</select></td>
</tr>
Hast du es auch mit FLOORPLAN oder gesetzten csrfToken probiert? Falls ja, dann wuerde ich es einchecken.
Mit gesetztem Token csrfToken funktioniert es.
Im Floorplan funktioniert es wie folgt: (gilt für Slider, Time und Werteliste, Lampensymbol bei on off dummy)
Nach Auswahl eines neuen Wertes wird der neue Wert gesendet via FW_cmd(). In einem parallel geöffneten Tab mit der Raumsicht oder z.B. Dashboard wird der neue Wert aktualisiert dargestellt. Der Floorplan aktualisiert allerdings nicht das ICON bzw. den angezeigten STATE.
Nach einem Reload der Seite mit dem Floorplan werden die geänderten Werte angezeigt.
Ändert man bei geöffnetem Floorplan in der Raumsicht einen Wert wird dieser im Floorplan auch nicht aktualisiert.
Zum Vergleich: bei einem Dummy mit on off und dem Lampensymbol klappt im Floorplan das Ändern des Status durch Klicken auf das Lampensymbl auch nicht. Es muss hier erst auf einen der Befehle geklickt werden, bei dem dann die Seite neu geladen wird.
Bin mir nun nicht sicher ob das im Floorplan so ok ist, allerdings ist das Verhalten bei allen genannten Elementen ja gleich.
Ich bin davon ausgegangen, dass sich der Floorplan wie z.B. die Raumsicht verhält und den STATUS selbst nachzieht bei Änderungen, was er aber nur durch einen reload hinbekommt.
Ich habe auf meine Testseite auch keine Negativ-Effekte bemerkt, habs also eingecheckt.
readingsGroup hat problem mit der änderung (http://forum.fhem.de/index.php/topic,14425.msg198586.html#msg198586 (http://forum.fhem.de/index.php/topic,14425.msg198586.html#msg198586)). ich weiss aber noch nicht ob in der raumübersicht oder im floorplan oder in beidem. ich schaue mal was ich rausfinde.
das problem betrifft den floorplan. vor einer weile gab es schon mal ein ähnliches problem. da lag es daran das die verschachtelten forms mal post und mal get verwendet haben. in fhemweb post und in floorplan ein get. floorplan wurde dann umgestellt auf $FW_formmethod und hat somit die gleiche method verwendet wie fhemweb und alles war gut.
der patch jetzt scheint fhemweb auf get umzustellen ohne $FW_formmethod zu ändern. d.h. fhemweb verwendet get und floorplan post. und es passt wieder nicht zusammen.
wie kann man das ganze so reparieren das nicht immer an einer stelle nachgezogen werden muss?
ein einfaches setup zum testen:define d dummy
attr d setList test:1,2,3,4
attr d room test
set d 1
define rg readingsGroup d:
attr rg commands { 'd.state' => "test:" }
attr rg room test
im room test kann man das menü in der readingsGroup benutzen, im floorplan leider nicht mehr.
Bei mir geht es in einem Raum (NICHT FLOORPLAN) auch außerhalb der Readingsgroup nicht (normales webCmd).
Es sollte über das Dropdown folgendes gesendet werden
set <device> favorites <name>
Es wird aber (mit Firefox Konsole getesetet) folgendes gesendet:
set <device> <name>
(2 Leerzeichen zwischen <device> und <name>. Es fehlt also das "favorites".
ich war zu schnell. zumindest dieses problem hat nichts mit dem floorplan zu tun.
es wird scheinbar wenn es nicht um state geht das commando nicht mehr ins set mit eingebaut.
wenn man den dummy von oben mit define dummy d
attr d setList reading:1,2,3
attr d webCmd readingdefiniert wird auch im webCmd state aktualisiert und nicht reading. hat also nichts mit der readingsGroup zu tun.
Ich kann das Verhalten ebenfalls bestätigen. Sobald man mit der Werteliste (Dropdown) ein set macht, das nicht auf state abzielt, funktioniert es nicht. Wie justme1968 schon schreibt, wird das entsprechende Kommando nicht in den set Befehl mitgenommen. Schaut man sich das ganze in der Javascript-Konsole an, findet man in den Parametern den set Befehl ohne das entsprechende Kommando.
Ich habe den letzten FHEMWEB/dropdown Patch wieder ausgebaut, und es fuer den sofortigen update bereitgestellt.
Falls die hier erwaehnten Problemfaelle in einem neuen Patch beruecksichtigt werden, dann werde ich es wieder einspielen.
Ich werde mir das fehlerhafte Verhalten einmal anschauen..
@justme1968 wenn man den Beispiel Dummy (siehe unten) nimmt und in der Befehlszeile den Befehl
"set d reading 1" ausführt wird der state des dummies auf "reading 1" gesetzt. Ist das in diesem Fall das gewünschte Verhalten?
Sollen readings des Devices aktualisiert werden so muss ja laut doku setreadings verwendet werden.
Die Frage ist nun, muss die Werteliste immer den Befehl "set" verwenden oder auch einmal setreadings?
define dummy d
attr d setList reading:1,2,3
attr d webCmd reading
Anbei eine Testversion, die den set Befehl verwendet und auch andere Readings als state unterstützt, diese muss in 01_FHEMWEB.pm eingebaut werden und ersetzt die dortige Funktion FW_dropdownFn. Bitte einmal testen.
FW_dropdownFn()
{
my ($FW_wname, $d, $FW_room, $cmd, $values) = @_;
return "" if($cmd =~ m/ /); # webCmd temp 30 should generate a link
my @tv = split(",", $values);
# Hack: eventmap (translation only) should not result in a
# dropdown. eventMap/webCmd/etc handling must be cleaned up.
if(@tv > 1) {
my $txt;
if($cmd eq "desired-temp" || $cmd eq "desiredTemperature") {
$txt = ReadingsVal($d, $cmd, 20);
$txt =~ s/ .*//; # Cut off Celsius
$txt = sprintf("%2.1f", int(2*$txt)/2) if($txt =~ m/[0-9.-]/);
} else {
$txt = ReadingsVal($d, $cmd, Value($d));
$txt =~ s/$cmd //;
}
my $fpname = $FW_wname;
$fpname =~ s/.*floorplan\/(\w+)$/$1/; #allow usage of attr fp_setbutton
my $readng;
if ($cmd eq "state" ){
$readng = "";
} else {
$readng = "$cmd"." ";
}
my $fwsel;
$fwsel = ($cmd eq "state" ? "" : "$cmd ") .
FW_select("$d-$cmd","val.$d", \@tv, $txt,"dropdown","FW_cmd('$FW_ME?XHR=1&cmd.$d=set $d $readng '+ this.options[this.selectedIndex].value+ ' &room=$FW_room')");
return "<td colspan='2'>".
"$fwsel</td>";
}
return undef;
}
@Hoschiq:
du musst hier tatsächlich zwischen dummys und 'echten' devices unterscheiden.
ein echtes device hat normalerweise ein zum reading passendes set kommando und dieses soll ausgeführt werden. der dummy hat dieses passende set kommando nicht deshalb landet der komplette string in state. das verhalten ist also erst mal korrekt. setreading wäre für die normalen devices verkehrt.
nur wenn es sich wirklich um einen dummy handelt (oder eventuell auch für devices die kein passendes set anbieten) ist setreading das richtige. ersteres sollte meiner meinung nach passieren, zu letzterem hat rudi sicher was zu sagen.
gruss
andre
Wenn ich das richtig sehe, geht es aber hier doch gar nicht um das Setzen von readings. Ein erweiterter set Befehl mit einem Kommando setzt nicht notwendigerweise ein reading auf einen Wert. Das Kommando muss in einem Device ja nicht einmal als reading existieren.
deswegen habe ich ja geschrieben das zwischen dummy und 'echtem' device unterschieden werden muss. für das device ist das set mit kommando richtig. für den dummy ist das setreading richtig.
gruss
andre
Dass fuer dummy ein setreading verwendet werden soll, sehe ich nicht.
Set bleibt set, keine Ausnahmen fuer manche Geraete, war bisher auch nicht der Fall.
dann gibt es (weiterhin) leider keine möglichkeit in einem dummy per frontend mehr als state zu setzen.
das ist schade...
wenn man dem dummy schon mit setList 'kommandos' oder widgets zu einem anderen reading als state zuordnen kann sollte das auch mit setreading auf dieses reading gehen.
bei einem dummy sollte setreading statt set berwenset werden wenn das kommando in der setList ist.
Der oben gepostete Patch unterstützt das Verhalten, wie es Rudi vorschlägt, also ausschließlich set.
Ich hätte noch eine alternativen Vorschlag bzgl. set und setreading.
Man könnte um unabhängig von Devices bzw. Dummies zu bleiben die Definition von setList erweitern.
Beispiel:
setList state:1,2,3,4
setList test:1,2,3,4
setList test:1,2,3,4:r
Die erste Definition zielt auf state ab und ist wie gewohnt. Es wird der set Befehl verwendet.
Die zweite Definition setzt mit set den Wert von test bei einem echtem Device. Es wird der set Befehl verwendet.
In der dritten Definition wird durch das angehängte :r definiert, dass es sich um ein Dummy reading oder um ein userReading eines echten Devices handelt. Hier wird setreading verwendet.
Somit könnte die Werteliste sehr universell eingesetzt werden, ohne spezielle Devices zu unterscheiden. Allein die Definition entscheidet über den abgesetzen Befehl.
Das müsste dann aber auch bei slider und time nachgezogen werde.
mal sehen ob rudi überhaupt bereit ist dazu.
es vom device abhängig zu machen hätte den vorteil das es keine zweideutigkeiten beim parsen gibt.
wenn es explizit hingeschrieben wird würde ich es lieber vorne beim reading/commando namen sehen. z. b. <name>[,r]:...
da , im reading namen Bucht erlaubt ist wäre es ohne konfliktpotential.
und ja. die anderen widgets sollten dann nachgezogen werden. also slider, time, test, colorpicker und die dials die hoffentlich noch kommen.
ich fände es ein sehr nützliches feature.
Hallo,
da das Thema setList hier nun doch ausführlicher diskutiert wurde, möchte ich auf einen Bug hinweisen:
attr Test myreading:aus,0,1,2,23
attr Test webCmd myreading
Setzt man bei dem dummy mit setreading Test myreading <Wert>
Wird an der Weboberfläche das durch entsprechende Vorauswahl des passenden Menüeintrages auch visualisiert.
Nur nicht für den Wert "0".
Dies scheint bisklang nicht aufgefalen zu sein, da meist "0" in setList der oberste Wert ist.
Hat mich einige Nerven gekostet, weil ich zuerst den Fehler in meinem Code gesucht habe.
Ich denke, dass da beim Menü-Widget so eine Abfrage wie if($value... drin steht und damit "0" als Wert rausfällt.
Konte die Stelle aber in der fhemweb nicht finden, das war mir dann doch zu komplex...
Gruß
Elektrolurch
0 wird wohl nicht aktualisiert, weil es in Perl dem Wert False entspricht!?
eher weil irgendwo eine bedingung falsch geprüft wird. vermutlich ein if($value) das eigentlich if(defined($value) && $value ne "") heißen muss.
gruss
andre
Ich wollte es ja finden, bis zur Abarbeitung von webCmd und den Verzweigungen bzgl. slider,menü usw. bin ich noch gekommen, danach habe ich nur Bahnhof verstanden. Es muss ja die Stelle sein, an der der Wert des readings in die Web-Oberfläche abgebildet wird....
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.
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:
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..
Zitatwenn 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.
ZitatsetList 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.
ZitatDer 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.
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: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.
if([b]defined($def) && $def ne ""[/b] && $v eq $def) {
sollte natürlich
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
onChange = "FW_cmd('$FW_ME?XHR=1&cmd.$d=set $d $readng '+ this.options[this.selectedIndex].value+ ' &room=$FW_room')";
Sonst
onChange = "window.location = '$FW_ME?cmd.$d=set $d $readng '+ this.options[this.selectedIndex].value+ ' &room=$FW_room'";
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.
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.
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.
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.
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.
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.
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
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 (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?
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-)
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?
ZitatAllerdings 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.
Anbei ein Patch für Slider und Time.
Dieser Patch fügt die folgende Funktionalität zu Slider und Time hinzu.
Ist Longpoll eingeschaltet, so wird ein Get zur Aktualisierung in FHEM verwendet.
Ist Longpoll ausgeschaltet, so wird die Seite neu geladen und die Werte werden per Post übermittelt.
Hierbei habe ich statt document.location window.location verwendet, da document.location veraltet ist.
Mit der Funktion addcsrf wird beim Post sichergestellt, dass bei aktiviertem csrfToken dieses angehangen wird. Innerhalb der Funktion FW_cmd wird dies ebenfalls aufgerufen.
Hier der Patch für Time, ist in der Funktion FW_timeCreate(el,cmd) einzubauen.
Es wird ersetzt:
if(cmd)
FW_cmd(cmd.replace('%',v)+"&XHR=1");
durch
if(cmd){
if(typeof FW_pollConn != "undefined"){
FW_cmd(cmd.replace('%',v)+"&XHR=1");
}else {
window.location = addcsrf(cmd.replace('%',v));
}
}
Hier der Patch für Slider.
In der Funktion mouseMove(e) wird
if(cmd.substring(0,3) != "js:")
if(typeof val != "undefined")
FW_cmd(cmd.replace('%',val)+"&XHR=1");
durch:
if(cmd) {
if(cmd.substring(0,3) != "js:")
if(typeof val != "undefined"){
if(typeof FW_pollConn != "undefined"){
FW_cmd(cmd.replace('%',value)+"&XHR=1");
}else{
window.location = addcsrf(cmd.replace('%',value));
}
}
} else {
if(typeof val != "undefined")
slider.nextSibling.setAttribute('value', val);
}
ersetzt.
@Rudi, im Patch für das Dropdown, wird innerhalb von der Javascript Funktion FW_cmd "csrfToken" verwendet, sofern ich die Funktion richtig interpretiere.
Um die Funktionalität (longpoll ein aus) auch im Dropdown zu verwenden habe ich mir die 01_FHEMWEB.pm angeschaut.
Dort wird z.B. so auf longpoll geprüft.
if(AttrVal($FW_wname, "longpoll", 1)
denke dass das so richtig ist und auch im Floorplan funktionieren könnte?
Testet bitte das Dropdown ohne Reload der Seite..
Hi,
ist das eingecheckt?
Ich hab heut ine update gemacht. Nach Werteänderung über slider wird auf dem iPad nach wie vor die Seite nicht mehr neu geladen.
Sehr lästig.
Wäre schön wenn das alsbald wieder funktionieren würde.
Gruß, Uli
@UliM: vermutlich nicht, weiss aber nicht genau, was du mit "das" meinst, manches habe ich eingecheckt, und manches nicht.
@Hoschiq: sorry, dass es bei mir so lange gedauert hat.
ZitatIst Longpoll eingeschaltet, so wird ein Get zur Aktualisierung in FHEM verwendet.
Ist Longpoll ausgeschaltet, so wird die Seite neu geladen und die Werte werden per Post übermittelt.
Kannst du mir bitte sagen, wieso das notwendig ist? Inzwischen habe ich FW_cmd auf POST umgestellt, aendert das was?
Und koenntest du auch fuer den "alten" dropdown einen aktuellen und kompletten Patch bereitstellen, da ich nicht mehr sicher bin, was alles reingehoert und was nicht. Wenn moeglich, haette ich gerne den Patch als "diff -u" Output, damit ich das nicht manuell anwenden muss.
@rudi - die Patches ermöglichen ein Aktualisieren er Seiteninhalte ohne Reload der Seite wenn longpoll eingeschaltet ist.
Ist longpoll ausgeschaltet, so wird die Seite neu geladen und dadurch die Werte der Seite nach der Änderung akualisiert.
Ich zitiere dich mal aus diesem Thread, wozu das gut sein soll.
ZitatBin 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.
Ein Umstellen von FW_cmd auf POST ändert nichts am Seitenreload Problem.
Wie erkenne ich im Modul 01_FHEMWEB.pm ob longpoll aktiviert ist? Das fehlt mir noch für den Dropdown Patch.
Ich versuche die Patches in den nächsten Tagen zur Verfügung zu stellen.
Danke fuer den Hinweis. Ich meine jetzt, dass der (minimale) Zusatzaufwand nicht gerechtfertigt ist.
Wer JavaScript nicht haben will, soll JavaScript abschalten.
ZitatWie erkenne ich im Modul 01_FHEMWEB.pm ob longpoll aktiviert ist?
AttrVal($FW_wname, "longpoll", 1)
Hi Hoshiq,
bis wann ist denn mit nem fix zu rechnen?
Gruß, Uli
Hallo,
hier die Patches für fhemweb_slider und fhemweb_time.
### Eclipse Workspace Patch 1.0
#P fhem
Index: www/pgm2/fhemweb_slider.js
===================================================================
--- www/pgm2/fhemweb_slider.js (revision 6816)
+++ www/pgm2/fhemweb_slider.js (working copy)
@@ -96,8 +96,14 @@
document.ontouchmove = oldFn3; document.ontouchend = oldFn4;
if(cmd) {
if(cmd.substring(0,3) != "js:")
- if(typeof val != "undefined")
- FW_cmd(cmd.replace('%',val)+"&XHR=1");
+ if(typeof val != "undefined"){
+ if(typeof FW_pollConn != "undefined"){
+ FW_cmd(cmd.replace('%',val)+"&XHR=1");
+ }
+ else{
+ window.location = addcsrf(cmd.replace('%',val));
+ }
+ }
} else {
if(typeof val != "undefined")
slider.nextSibling.setAttribute('value', val);
### Eclipse Workspace Patch 1.0
#P fhem
Index: www/pgm2/fhemweb_time.js
===================================================================
--- www/pgm2/fhemweb_time.js (revision 6816)
+++ www/pgm2/fhemweb_time.js (working copy)
@@ -19,8 +19,14 @@
if(brOff > 0) {
par.innerHTML = par.innerHTML.substring(0, brOff).replace('"-"','"+"');
- if(cmd)
- FW_cmd(cmd.replace('%',v)+"&XHR=1");
+ if(cmd){
+ if(typeof FW_pollConn != "undefined"){
+ FW_cmd(cmd.replace('%',v)+"&XHR=1");
+ }
+ else{
+ window.location = addcsrf(cmd.replace('%',v));
+ }
+ }
return;
}
Am Dropdown arbeite ich noch, da im Floorplan die Erkennung ob Longpoll an noch nicht richtig funktioniert.
Habs eingecheckt.
Hallo,
hier der Patch für das Dropdown ohne reload.
Ein TODO ist noch offen, das Ermitteln des Webinstanz-Namens im Floorplan.
Aktuell wird im Floorplan immer ein Reload der Seite durchgeführt.
### Eclipse Workspace Patch 1.0
#P fhem
Index: FHEM/01_FHEMWEB.pm
===================================================================
--- FHEM/01_FHEMWEB.pm (revision 6947)
+++ FHEM/01_FHEMWEB.pm (working copy)
@@ -2509,17 +2509,28 @@
my $fpname = $FW_wname;
$fpname =~ s/.*floorplan\/(\w+)$/$1/; #allow usage of attr fp_setbutton
+
+ my $readng;
+ if ($cmd eq "state" ){
+ $readng = "";
+ } else {
+ $readng = "$cmd"." ";
+ }
+
+ # TODO in case of running in a floorplan split $FW_wname to get name of webInstance.
+ # Actually in floorplan the dropdown will refresh the page always independently from
+ # setting in corresponding web instance, cause statement if( AttrVal($FW_wname, "longpoll", 0) == 1) will always fail.
+
+ if( AttrVal($FW_wname, "longpoll", 0) == 1) {
+ $selFunct = "FW_cmd('$FW_ME?XHR=1&cmd.$d=set $d $readng '+ this.options[this.selectedIndex].value+ ' &room=$FW_room')";
+ } else {
+ $selFunct = "window.location = addcsrf('$FW_ME?cmd.$d=set $d $readng '+ this.options[this.selectedIndex].value+ ' &room=$FW_room')";
+ }
my $fwsel;
- $fwsel = ($cmd eq "state" ? "" : "$cmd ") .
- FW_select("$d-$cmd","val.$d", \@tv, $txt,"dropdown","submit()").
- FW_hidden("cmd.$d", "set");
- $fwsel .= FW_hidden("fwcsrf", $defs{$FW_wname}{CSRFTOKEN}) if($FW_CSRF);
-
- return "<td colspan='2'><form method=\"$FW_formmethod\">".
- FW_hidden("arg.$d", $cmd) .
- FW_hidden("dev.$d", $d) .
- ($FW_room ? FW_hidden("room", $FW_room) : "") .
- "$fwsel</form></td>";
+ $fwsel = ($cmd eq "state" ? "" : "$cmd ") .
+ FW_select("$d-$cmd","val.$d", \@tv, $txt,"dropdown","$selFunct");
+ return "<td colspan='2'>" .
+ "$fwsel</td>";
}
return undef;
}
Das deckt sich nicht mit meine. Beobachtungen. Aktuell wird in FP Hariri. Reload durchgeführt.
Ärgerlich dass das nun so defekt in den neuen Release geht.
Was ist den. Eigentlich der Anlass Fürsorge Veränderung gewesen?
In floorplan.pm wird die Webinstanz ermittelt, man müsste also nur abschreiben?
Gruß Uli
@Hoschiq: ich warte mit dem Einchecken, bis UliM auch zufrieden ist.
@UliM: bitte Reschtschreibkorrektur abschalten, ich verstehe nicht wirklich, was du meinst.
Hallo Ulli,
es geht darum, dass das Dropdwon nur ein Reload durchführen soll, wenn longpoll aktiviert ist.
Das klappt in FHEMWEB + Dashboard auch.
Im Floorplan wird bei Verwendung von Dropdown allerdings nicht der Name der Webinstanz, sondern noch der komplette Pfad mit floorplan/fp_name übergeben.
Im Dropdown wird geprüft, ob in der webistanz longpoll aktiviert ist. Schlägt die Prüfung fehl, so wird als Fallback das aktuelle Verhalten umgesetzt sprich Reload der Seite, vorher eben submit des Form.
Das Dropdown ist nun außerdem kein Form mehr, was wohl in einigen Fällen bei Schachtelung Probleme machte.
Es fehlt nur das Zerlegen der Pfades um an die Webinstanz zu kommen.
Im Dashboard erfolgt der Aufruf so:
foreach my $fn (sort keys %{$data{webCmdFn}}) {
no strict "refs";
$htmlTxt = &{$data{webCmdFn}{$fn}}($FW_wname, $d, $FW_room, $cmd, $values);
Im Floorplan wird noch was angehangen:
$FW_ME = "$FW_ME/floorplan/$FP_name";
foreach my $fn (sort keys %{$data{webCmdFn}}) {
my $FW_room = ""; ##needed to be able to reuse code from FHEMWEB
no strict "refs";
my $htmlTxt = &{$data{webCmdFn}{$fn}}("$FW_ME", $d, $FW_room, $cmd, $values);
$FW_ME = "$FW_ME/floorplan/$FP_name"; kommt im Dropdown als interne Variable $FW_wname an.
Es ist also keine Verschlechterung der aktuellen Funktion zu erwarten im Floorplan.
VG
Hi,
Sorry für die Rechtschreib"korrekturen".
Aus meiner persönlichen Sicht hatte ich nie ein Problem mit Seiten-Neuladen nach Dropdown-Menü-Auswahl, habe aber sehr wohl ein Problem, wenn genau das nicht passiert.
Da hat sicher jeder ein anderes setup und damit andere Prios.
Wenn ich in floorplan was nachziehen soll/muss schick mir bitte nen Patch.
Aktuell beobachte ich, dass ohne eine Änderung meinerseits etwas nicht mehr tut, was vorher ging - das find ich doof :)
Lässt sich das wieder richten?
LG Uli
Hallo Uli,
es gab auch keine Probleme mit dem Reload beim Dropdown. Nur ist ein Reload der Seite bei längeren Seiten oder z.B. im Dashboard unschön,
da man entweder wieder an die Stelle der Änderung Scrollen muss oder im Dashboard den Tab erneut öffnen muss.
Es ist eine Verbesserung, dahingehend, dass sich das Dropdown nun wie Slider, Time und z.B. das Ein- Ausschalten von Aktoren verhält.
ZitatDas Patch ermöglicht ein Aktualisieren er Seiteninhalte ohne Reload der Seite wenn longpoll eingeschaltet ist.
Ist longpoll ausgeschaltet, so wird die Seite neu geladen und dadurch die Werte der Seite nach der Änderung akualisiert.
Im Floorplan wird beim Dropdown allerdings unabhängig von longpoll immer ein Reload der Seite durchgeführt.
ZitatAktuell beobachte ich, dass ohne eine Änderung meinerseits etwas nicht mehr tut, was vorher ging - das find ich doof :)
Lässt sich das wieder richten?
Damit kann ich leider nicht viel anfangen, da ich nicht weiß was (welche Elemente oder Funktionen) bei dir nicht mehr funktioniert.
Falls es Slider und Time waren kannst du ein Update machen, da hat Rudi das Patch eingespielt.
Ich habe für die die es einmal testen wollen die geänderte FHEMWEB Datei angehangen.
VG
Hi,
mit aktuellem update-Stand sehe ich kein page-refresh nach slider.
Internals:
NAME wakeupChange
NR 282
STATE 06:25
TYPE dummy
Readings:
2014-11-13 21:58:10 state 06:25
Attributes:
fp_Grundriss 492,828,2,Wakeup
fp_PlotsPage 640,201,2,
group Wohnung
icon time_timer
room Wohnung,Schlafzimmer
setList state:time
webCmd state
Nach Änderung des Wertes erfolgt zwar (vmtl. llongpoll) eine Aktualisierung der Anzeige des state dieses device, aber die Startzeit des via notify abhängigen device
define a_heizStart at *06:05 set ez_FHT desired-temp 21.5;set hzg_SollTemp 21.5
wird nicht mit ihrem neuen Wert angezeigt.
Nach einem reload durch erneutes klicken auf denselben flooaplan-namen erscheint dann sehr wohl die aktualiserte Startzeit,
Zuvor wurde die aktualiserte Zeit auf letzterem device sofort refreshed - ich gehe daher davon aus, dass kein refresh der ganzen Seite stattfindet.
Gruß, Uli
Hi Uli,
handelt es sich bei dem Floorplan um das erwähnte Tablet?
Zitat
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-)
War dort longpoll ein oder ausgeschaltet in der Webinstanz als du getestet hast?
Falls longpoll eingeschaltet war kannst du mal mit ausgeschaltetem longpoll testen?
Hast du einmal mit der im vorherigen Post angehängten FHEMWEB getestet, ob das Verhalten beim Dropdown so für dich funktioniert?
VG
@Hoschiq: habs eingecheckt, damit wir bessere Testergebnisse haben.
Ich habe es mit fhem.cfg.demo und mit meiner Widget-Test-Konfiguration getestet, und mir ist nichts aufgefallen.
Komisch: weder im Patch noch in deinem 01_FHEMWEB.pm war $selFunct deklariert, weswegen bei mir FHEMWEB gar nicht geladen werden konnte.
Hi,
nach erneutem update (also jetzt wohl mit der neueren fhemweb) getestet.
longpoll 1:
fhemweb Raumansicht: Nach Änderung über slider findet refresh des Wertes statt, scheinbar kein kpl. page-reload
floorplan: Nach Änderung über slider findet refresh des Wertes statt, jedoch kein kompletter page-reload
longpoll 0:
fhemweb Raumansicht: Nach Änderung über slider findet refresh des Wertes statt, kompletter page-reload
floorplan: Nach Änderung über slider findet refresh des Wertes statt, kompletter page-reload
Bei longpoll 0 also ok.
Bei longpoll 1 hab ich noch ein Problemchen: ich habe abhängige dummies, deren Wert via notify aktualisiert wird, nachdem der slider auf dem Primärdevice verwendet wurde. Die Wertänderung wird auf den abhängigen dummies nicht aktualisiert. Das ist suboptimal, aber zu verschmerzen.
Gruß, Uli
Hi Uli,
deinem Test nach zu urteilen arbeitet es wie vorgesehen. Das bei aktviertem Logpoll nicht automatisch alle
Werte bei Änderung aktualisiert werden sehe ich als Problem beim longpoll..
VG
Hallo,
habe es gerade gefunden: Das Update der 01-FHEMWEB.pm scheint wohl Nebeneffekte bezüglich der Bedienung per Tastatur zu haben:
http://forum.fhem.de/index.php/topic,29923.0.html#
(Menüps schliessen nicht mehr bei <CR> - nicht mehr barrierefrei)
Habe damit ein großes Problem.
Gruß
Elektrolurch