optimierung readingsGroup

[rudolfkoenig]

Ok, das Problem (room=all in FW_roomStatesForInform) sollte jetzt gefixed sein.

room=all wird nur bei longpollSVG benoetigt, das wird jetzt in fhemweb.js genauer geprueft, und nur falls noetig gesetzt.

Der doppelte Aufruf bleibt aber weiterhin erhalten, damit zwischen Seiten-Rendering und JavaScript-Aufruf keine Events verlorengehen.

[justme1968]

ich bin gerade dabei die optimierungen beim triggern der events an deine letzten änderungen anzupassen. beim debuggen sind mir einige sehr seltsame dinge aufgefallen:

• der doppelte aufruf ist natürlich noch da wie du gesagt hast.
  ich bin aber immer noch der meinung das das das falsch ist und nichts mit dem verloren gehen von etwas zu tun hat/hatte.
  
  
  
  • für eine rg im raum everyting wird summaryFn ein mal aufgerufen -> ok. aber longpoll geht nicht.
  • für eine rg im raum unsorted wird summaryFn ein mal aufgerufen -> ok. aber longpoll geht nicht.
  • für eine rg in einem beliebigen anderen raum wird summaryFn zwei mal aufgerufen -> nicht ok. aber longpoll geht
    ein aufruf ist aus FW_showRoom und ein mal aus FW_devState. eine readingsGroup hat genau so wie ein weblink oder ein SVG plot keinen status und kein icon. dieser aufruf sollte für alle et ends entfallen. auch SVG plots werden zwei mal aufgerufen, rendern zwei mal die pfeile. weblinks rendern doppelt.
  • für eine rg in der detail ansicht wird ein mal die detailFn und ein mal die summaryFn aufgerufen -> nicht ok. aber longpoll geht.
    ein mal aus FW_showRoom und ein mal aus FW_devState. SVG plots werden doppelt aufgerufen und rendern die pfeile doppelt. weblinks rendern aber nur einmal. in der detail ansicht wird für kein device ein icon angezeigt. auch hier sollte der zweite aufruf grundsätzlich entfallen.
• es gibt doppelte aufrufe von SVG_showLog und somit auch ein unnötiges doppeltes auslesen der werte aus dblog für jeden dargestellten plot. das scheint aber unabhängig von den doppelten aufrufen oben zu sein. es passiert auch im raum all.
• es sind noch ein paar überflüssige aufrufe dazu gekommen
  sobald die readingsGroup ein DoTrigger aufruft wird die summaryFn aufgerufen. und das für jedes DoTrigger unabhängig davon ob es state/STATE betrifft, das die readingsGroup gar nicht hat. der aufruf ist auch hier aus FW_devState heraus und überflüssig weil bei keinem der at ends ein state und ein icon angezeigt wird. das war vorher auch nicht so.


• das verhalten und die anzahl und reihenfolge der aufrufe von summaryFn und detailFn und longpoll ist für die fälle all/Unsorted/irgendeinRaum/detail ansicht unterschiedlich. das verhalten von longpoll hat sich mehrfach mehr oder weniger zufällig geändert in letzter zeit. zur zeit geht es weder in all noch in unsorted. letzte woche ging es in all aber nicht unsorted. ich meine das war auch schon mal genau umgekehrt.


• die temporäre fhemweb instanz die im raum all für den aufruf der summaryFn verwendet wird ist später zum zeitpunkt des notify nicht mehr da. das passiert nur im raum all und hat nichts mit der anzahl der devices zu tun.


• es lassen sich nur 6 tabs parallel öffnen. danach bleiben tabs hängen oder haben longpoll probleme oder beides. sobald man einen tab schliesst werden alle hängenden tabs aktualisiert. auch wenn es mehr als 6 sind. aber longpoll geht dann auf diesen tabs nicht. (safari)

ich würde gerne vorschlagen:

• FW_devState sollte nicht aufgerufen werden/nichts tun wenn ein device kein icon haben kann (wie alle atends) oder wenn es die detail ansicht ist wo kein icon angezeigt wird
• FW_devState nur dann aufgerufen wird wenn sich am state/STATE tatsächlich etwas geändert hat.
• longpoll in allen räumen zum laufen zu bekommen. egal ob all,unsorted oder irgendein anderer
• das ein weg gefunden wird mit dem ein device feststellen kann ob es gerade in einem browser fenster angezeigt wird. dadurch das die temporäre fhemweb instanz mit der die summaryFn im raum all aufgerufen wird am ende nicht mehr vorhanden ist geht das nur noch durch iterieren über alle web instanzen.

wie wäre es das verhalten von longpoll und summaryFn bzw detailFn für alle möglichen fälle von all/unsorted/raum/detail zu definieren und eine test konfiguration dafür zusammen zustellen um bei änderungen möglichst schnell sicherzustellen das alles so tut wie es soll.

das ist gerade viel länger geworden als es sollte. aber beim testen ist mir immer mehr aufgefallen.

[rudolfkoenig]

Bin nicht sicher, dass ich alles verstehe, aber ich sehe auch die Probleme.

FW_devState sollte nicht aufgerufen werden/nichts tun wenn ein device kein icon haben kann (wie alle atends) oder wenn es die detail ansicht ist wo kein icon angezeigt wird

Ich habe atEnds beim FW_roomStatesForInform ausgeschlossen. Das ist zwar in Prinzip falsch, allerdings sind die Nebeneffekte und die Bugs, die dadurch aufgedeckt werden (u.a. http://forum.fhem.de/index.php/topic,18583.new.html#new) stoerender.
Ich bleibe immer noch dabei, dass zwischen Rendering und longpoll Aktivierung was verloren gehen kann, und deswegen alles, was auf der Seite sichtbar ist, an das JavaScript uebertragen werden muss. Vermutlich kann man sowas elegant nur mit einem reinen JavaScript Client loesen.

FW_devState nur dann aufgerufen wird wenn sich am state/STATE tatsächlich etwas geändert hat.

Das ist vmtl. sinnvoll, habe ich aber erstmal aufgeschoben.

longpoll in allen räumen zum laufen zu bekommen. egal ob all,unsorted oder irgendein anderer

Ich meine das funktioniert jetzt wieder. Dass Everything nicht tat, war mir nicht bewusst, von Unsorted wusste ich.

das ein weg gefunden wird mit dem ein device feststellen kann ob es gerade in einem browser fenster angezeigt wird.

Das ist immer noch fuer alle _nicht_ atEnd Module gegeben, da diese, falls sie sichtbar sind, ueber FW_roomStatesForInform aufgerufen werden, und dies ist die longpoll Verbindung.

Ich bin auch fuer eine Test-Konfiguration, wuerde mich aber freuen, wenn ich das nicht selbst erstellen muss. Waere nett, wenn wir dafuer die demo Konfiguration nutzen koennten.

[justme1968]

danke. ich schau mir in ruhe an was deine änderungen bewirken. vielleicht kann ich das gleich so systematsich das man es wiederholbar für eine testkonfiguration verwenden kann.

mal sehen ob ich auch einen weg finde wie ich die optimierung um die es eigentlich ging wieder einschalten kann.

ansonsten war oben (vermutlich zu versteckt) noch der punkt das alle plots zwei mal daten aus filelog/dblog holen (also zwei mal SVG_showLog  mit anschließendem get auf das log device) und zwei mal plotten. das scheint unabhängig von den mehrachen summaryFn/detailFn aufrufen zu sein. und fällt natürlich besonders auf wenn man einen raum mit plots hat und raus zoomt.

[rudolfkoenig]

Wg. plots: sollte auch weg sein.