erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[bgewehr]

Wvc für IOS ist nicht in Sicht, oder?

[HCS]

Ich teste in Kürze einige Alternativen (fifo mit Timeout), denke das wird funktionieren.

An einem fifo im triber zu responsive Aktualisierung der widgets bin ich auch gerade dran.
Da sollten wir achtgeben, dass wir keine Arbeit doppelt machen.
Kannst Du mal kurz beschreiben, was du wo machst?

[HCS]

EDIT: www/smartvisu/temp löschen... könnt ihr dafür ein script einbauen das zu machen? evtl in smartvisu einstellungen einen punkt "clear cache" 
winscp  um auf dem server den cache zu leeren ist eine sehr schlechte lösung wenn man nicht am rechner sondern zb am handy/tablet sitzt...

Die Idee hatte ich kürzlich auch schon, aber in der Form, dass es sinnvoll wäre, wenn man in SV den page cache abschaltet, dass dann auch automatisch das temp Verzeichnis geleert wird.
Das wäre aber aus meiner Sicht eher ein natives SV Feature. Du kannst es ja mal im SV-Forum vorschlagen, ob die das machen würden.
Wenn nicht, können wir dann immer noch unsere eigene Lösung dafür bauen.
Je mehr wir an SV ändern, umso schwieriger und aufwändiger wird es, wenn man das nächste SV Update aufspielen will.

[marvin78]

Die SmartVisu Jungs haben das löschen wohl in ihrer smarthome.py mit drin (Neustart löscht Cache). Die Hoffnung, dass sowas also nativ eingebaut wird, ist eher gering. Ich kann mich jedoch dunkel erinnern, dass im KNX-SmartVisu-Forum jemand eine Lösung gepostet hat.

[herrmannj]

Wvc für IOS ist nicht in Sicht, oder?

Ja, hab schon überlegt zumal ich selber zufriedener apple mobile Nutzer bin. Nur: die machen es einem echt schwer ohne Mac zu entwickeln, dann muss man da noch ca 100,- Jahresbeitrag abdrücken und ob das Ding dann in den store darf ist, wegen deren teilweise fast willkürlichen Bedingungen, auch nicht sicher.

Von daher versuche ich erst mal die Zeit für Android aufzubringen, bzgl apple: maybe later ...

vg
jörg

[herrmannj]

Die SmartVisu Jungs haben das löschen wohl in ihrer smarthome.py mit drin (Neustart löscht Cache). Die Hoffnung, dass sowas also nativ eingebaut wird, ist eher gering. Ich kann mich jedoch dunkel erinnern, dass im KNX-SmartVisu-Forum jemand eine Lösung gepostet hat.

Also in fronhtem (und darum gehts ja hier  ) seh ich das nicht. Bau Dir doch ein php script was den cache löscht und ruf das vom fhem server auf.

Wofür soll das denn eigentlich gut sein ? Wenn ich an / in sv entwickle schalte ich den twig cache in den settings ab und lösche den cache einmal. Da sitz ich doch eh am nb und bin auf dem sv server eingeloggt ... ?

vg
jörg

[herrmannj]

An einem fifo im triber zu responsive Aktualisierung der widgets bin ich auch gerade dran.
Da sollten wir achtgeben, dass wir keine Arbeit doppelt machen.
Kannst Du mal kurz beschreiben, was du wo machst?

bisher nur Plan und Untersuchung. Zu erst war mir wichtig zu schauen ob fronthem die performance bringt. Das tut es - im Prinzip wäre es sogar gut wenn fronthem langsamer liefern würde aber das ist natürlich nicht Sinn der Sache.

Das sv Thema sehe ich schon eher sekundär weil es hier ja um fronthem. Das von Karl beschriebene Setup mit 300GADs pro page sehe ich auch für mich nicht - genauso wenig sehe ich das auch in den Demohäusern die ja auch aus produktiv Umgebungen stammen. Ich habe gestern nochmal durchgeschaut. Dort sehe ich so an 30Gads (plus / minus) pro Seite, das kommt bei mir auch hin und funktioniert prächtig.

Trotzdem: ich habe noch untersucht was man machen kann. Am liebsten wäre mir ein event von jquery was signalisiert "alle widget gezeichnet" um danach das nächste GAD aus dem ws zu holen. Ich habe aber nichts gefunden was da geht. Von daher würde ich vorschlagen die GAD bei "onmessage" aus dem ws zu holen un in ein array (als fifo) zu schreiben. Die eigentlich aktualisieren würde ich dann so machen das jeweils ein widget aktualisiert wird und danach ein settimeout mit 5-10ms aufgerufen wird. In diesen 5-10ms kann die ui aktiv werden (sv ist responsive) und danach kommt das nächste item aus dem ws dran.

Wie sieht Dein Plan aus ?

vg
jörg

[HCS]

Von daher würde ich vorschlagen die GAD bei "onmessage" aus dem ws zu holen un in ein array (als fifo) zu schreiben. Die eigentlich aktualisieren würde ich dann so machen das jeweils ein widget aktualisiert wird und danach ein settimeout mit 5-10ms aufgerufen wird. In diesen 5-10ms kann die ui aktiv werden (sv ist responsive) und danach kommt das nächste item aus dem ws dran.

Wie sieht Dein Plan aus ?

Der sieht ungefähr so aus, wie das, was Du beschrieben hast. Ich hatte das mal als wackeliges Experimet so probiert.
Hatte es aber erst mal nicht weiter verfolgt, da ich die Hoffnung hatte, dass Du initial nach monitor die GADs am Stück liefern kannst.
Dann hätte ich es nicht queuen müssen, da es ja schon als array vorliegt.

Der aktuelle Plan ist also momentan:
Alles, was in onmessage reinkommt in den fifo schieben und den so rausspulen, dass die Oberfläche responsiv bleibt.
Dann dauert es minimal länger, bis der letzte Wert auf dem Bildschirm steht, dafür bleibt das Ganze bedienbar.

[HCS]

Die SmartVisu Jungs haben das löschen wohl in ihrer smarthome.py mit drin (Neustart löscht Cache). Die Hoffnung, dass sowas also nativ eingebaut wird, ist eher gering. Ich kann mich jedoch dunkel erinnern, dass im KNX-SmartVisu-Forum jemand eine Lösung gepostet hat.

Dann machen wir doch einfach ein Sys-Admin widget, das man sich auf eine seiner pages drauf setzt und da kann man das und weiter Dinge reinpacken.
Ich habe mir z.B. auch im menü einen refresh button, der einen page-reload macht, reingepackt, da es in einer WebApp ja keinen gibt und ein reload doch mal irgendwann erforderlich ist.

So:

Code Auswählen Erweitern

  <div class="ui-btn ui-corner-all" id="reload" onclick="location.reload(true);">
    <img class="icon" src="{{icon0}}control_clear.svg"/>
  </div>


[marvin78]

Also in fronhtem (und darum gehts ja hier  ) seh ich das nicht. Bau Dir doch ein php script was den cache löscht und ruf das vom fhem server auf.

Wofür soll das denn eigentlich gut sein ? Wenn ich an / in sv entwickle schalte ich den twig cache in den settings ab und lösche den cache einmal. Da sitz ich doch eh am nb und bin auf dem sv server eingeloggt ... ?

vg
jörg

Ich brauche das nicht Ich habe nur beschrieben, was ich in diversen Quellen gelesen habe ...

[herrmannj]

Hatte es aber erst mal nicht weiter verfolgt, da ich die Hoffnung hatte, dass Du initial nach monitor die GADs am Stück liefern kannst.
Dann hätte ich es nicht queuen müssen, da es ja schon als array vorliegt.

Du, das würde nix bringen. Was passiert denn wenn kurz (0 - x Sekunden) nach dem "monitor" ein fhem device ein event produziert - sv aber noch mit abarbeiten der initialen GAD beschäftigt ist ? Fifo ... 

Dann zieh ich mich da raus - ok ?

vg
jörg

[HCS]

Dann zieh ich mich da raus - ok ?

Ja, ist OK. Komme aber wohl erst am WE dazu.
Wenn ich nicht weiter komme rufe ich um Hilfe.

Muss aber wohl parallel noch einen weiteren Punkt erforschen. Bei der Experimentiererei ist mir in letzter Zeit sehr häufig FHEM gestorben. Ich will mal dahinter kommen, wie ich das gezielt reproduzieren kann. Da melde ich mich dann dazu, wenn ich was konkretes weiß.

[bgewehr]

Also, iPad1 unterstützt nur draft-76 websockets. Jörg, kann fronthem da etwas flexibler werden?


Gesendet von meinem iPad mit Tapatalk

[herrmannj]

Leider nein - für diesen Teil wird net::websocket::protocol verwendet. Da wird unterstützt

    draft-ietf-hybi-17 (latest)
    draft-ietf-hybi-10
    draft-ietf-hybi-00 (with HAProxy support)
    draft-hixie-75

die einzelnen Versionen unterscheiden sich auch nicht nur mal eben marginal, da sind teils große Unterschiede. Nicht despektierlich gemeint: dort den support für -76 nachzurüsten ist umfangreich und steht in keinem Verhältnis zu eine gebrauchten ipad-2.

Evtl kannst Du einen anderen browser einsetzen ?

vg
jörg

[marvin78]

Ich bin auch der Meinung, dass hier mit der modernen Oberfläche nicht um jeden Preis jedes alt Schätzchen unterstützt werden sollte. Man sollte nicht den Fehler machen und die Abwärtskombatibität zu weit treiben. Auch die Unterstützung von zu vielen exotischen Systemen ist IMHO nicht sinnvoll.