Nach JS Umbau FHEMWEB hat Readingsgroup anderes verhalten bzw. ist defekt

[Risiko]

Hallo Rudi,

nachdem du deine Änderungen vom branch FHEMWEB_JS_UMBAU   in trunk übernommen hast (so um Revision 7500), funktioniert Readingsgroup anders.
Scheint im Zusammenhang mit den commands und den mappings zu stehen!?
Anbei mal eine kleine Demo.cfg und die Unterschiede.

Hoffe ihr könnt damit die Sache klären.

Risiko.

[rudolfkoenig]

Sollte man Rudi nicht durch Andre ersetzen?

[Risiko]

Ich kann leider nicht genau sagen, wo das "Fehlverhalten" her kommt. Readingsgroup oder FHEMWEB. Aber von mir aus eben Andre

[justme1968]

ich habe eben einen version der readingGroup eingecheckt die ein paar probleme mit dem layout bei dropDown menüs behebt.

mit dieser version schaut deine demo so aus wie auf dem ersten screenshot.

schau mal bitte ob bei dir auch alles wieder funktiuoniert.

gruss
  andre

ps: das war eine vorbildliche fehlermeldung mit vorher/nachher screenshot und kompletter config zum reproduzieren. danke!

pps: @rudi: damit longpoll für die widgets in der readingsGroup auch wieder geht habe ich hier: http://forum.fhem.de/index.php/topic,31293.msg244079.html#msg244079 noch etwas gepostet.

[Risiko]

Hallo Andre,

danke für die schnelle Reaktion.
Im Demo funktioniert bis auf longpoll (nehme mal an es liegt daran - muss Seite manuell aktualisieren damit Änderungen in den Readings sichtbar sind) soweit alles.

In der "realen" Anwendung gibt es noch ein Problem mit den Spalten.  Es werden mehr Spalten als Readings erzeugt.
Soll und Mode werden einmal als aktueller Wert und als Dropdownbox dargestellt. Leider lässt es sich in der vereinfachten Demo nicht nachvollziehen.

Werde morgen oder übermorgen nochmal schauen, ob ich eine Demo mit dem gleichen Verhalten hin bekomme.

Risiko.

[justme1968]

longpoll für die widgets sollte mit dem update morgen wieder gehen.

gruss
  andre

[Risiko]

Hallo Andre,

nach heutigem Update (Revision  7537) funktioniert das Layout wieder. Prima.

Mit longpoll gibt es aber noch Probleme bzw. es funktioniert anders. Für state funktioniert es, aber nicht für das im Beispiel Reading "refresh".
Ich habe die Demo noch etwas modifiziert.

Wenn man über die DropDownbox "Soll" ändert, wird durch ein notify das Reading "refresh" mittels setreading auf 1 gesetzt und der Button müsste rot werden.
In der alten Variante (vor JS Umbau) wurde die Änderung auch sofort sichtbar. Jetzt muss man die Seite erst manuell aktualisieren.

In die andere Richtung gehts - also wenn refresh==1 (Button ist rot) der Button geklickt wird, wird "refresh" auf 0 und er wechselt auch sofort zurück so grün.

Risiko.

[justme1968]

das problem ist weniger ein readingsGroup problem als das wenn in einem notify setreading aufgerufen wird dieses keine weiteren events triggert. wenn du in den event monitor schaust solltest du auch das sehen.

das ist eigentlich schon eine ganze weile bzw. schon immer so und sollte sich genau so wie vor dem update verhalten. wenn es hier einen unterschied gibt verstehe ich ihn nicht.

der einfache workaround dafür ist vor das setreading auf refresh ein sleep 1 zu stellen. wichtig: es muss im gleichen fhem() aufruf sein. dein notfy schaut dann etwa so aus:

Code Auswählen Erweitern

{ if( ($EVENT ~~ / /) and ($EVENT !~ /: /) ) {fhem("setreading $NAME $EVENT");fhem("sleep 1 ; setreading FAKE_WT refresh 1");}}

gruss
  andre

[Risiko]

Hallo Andre,

das ist eigentlich schon eine ganze weile bzw. schon immer so und sollte sich genau so wie vor dem update verhalten. wenn es hier einen unterschied gibt verstehe ich ihn nicht.

Also das Verhalten hat sich klar geändert. Man muss nur ein paar Revisionen (z.B. 7490) zurück, gleiche cfg-Datei und es geht.
Ob es nun was mit dem JS-Umbau zu tun hat, oder an einer anderen Änderung liegt, ist nun aber auch egal.
Mit dem sleep als workaround  funktioniert es wieder (habe es sogar auf 0.5 reduziert), obwohl ich leider nicht verstehe warum.

Vielen vielen Dank.

Risiko.