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

[herrmannj]

Bernd,

ich hab Dich im Git eingetragen bei smartvisu-cleaninstall und (neu eingerichtet) bei smartvisu-widgets.

Ich schlage vor die umfangreichen widgets wie uzsu und co in smartvisu-widgets, dort jeweils in einem eigenen Ordner zu speichern.

In smartvisu-cleaninstall würde ich dann eine fhem-widget.js pflegen. Dort würde ich die "basic - type" widgets rein nehmen, also zb ein iconize nach cruser1800 (Lutz).

Wer mag den trage ich gern bei github ein.

vg
jörg

[bgewehr]

@jörg: Danke, ich mach mal was rein...

Allerdings spielt sich UZSU im Git vom mWorion ab und nur der fhem Teil ist von mir neu, wie hast Du Dir das gedacht? Mein Code kommt ja nur in die 99_fronthemUtils.pm rein.

Die anderen Widgets sind einfach...

[herrmannj]

hab nicht bis ins Detail gedacht Mir ging es auch um die Struktur, hoffe das macht so Sinn, auch in Hinblick auf weitere widgets
vg
jörg

[gravidi]

hi all,

ich nutze die config.ini in smartvisu mit festen Einträgen, also nicht über auto_add = true.

Nun wollte ich für jeden Client "Type" (Iphone, Ipad etc) die jeweils von mir erstellte page zuweisen.

Leider greift die Einstellung nicht und es wird mir immer die gleiche also default Seite angezeigt.

Ist die "Funktion" bei einem der letzten Updates rausgeflogen?

Danke und Grüße

Grav

[herrmannj]

nicht wissentlich - teste ich.

Danke
jörg

[HCS]

Ich habe mich nun mal mit der blockierenden Laderei beschäftigt.

Vorbemerkungen:
Man darf auf keinen Fall die (reichliche) Zeit, die SV benötigt,  bis die Seite erscheint, speziell wenn der page cache aus ist, mit der Zeit verwechseln, die die GADs für das initiale Anzeigen brauchen.
Das "blocking GAD init" Problem beginnt ab dem Moment, ab dem die Seite sichtbar wird und noch keine Werte anzeigt werden.

Es ist nicht die Gesamt-Anzahl der GADs entscheidend, sondern wie viele auf der page sitzen, die gerade geladen wird.
Der Treiber frägt nur die GADs der aktuellen page bei fronthem an. Man kann also 500 GADs haben, wenn eine page nur 10 davon drauf hat, hat die kein Problem.
Das Problem ist eigentlich nur beim initialen Laden einer page gegeben, da in diesem Fall, wenn die page z.B. 100 GADs hat, alle 100 GADs sofort benötigt werden, um initial alles anzuzeigen.
Danach ist es sehr unwahrscheinlich, dass sich alle 100 readings in FHEM gleichzeitig ändern, es werden also immer mal nur einige wenige übertragen.

Stand:
Ich habe jquery queue mal testweise eingebaut. Das verbessert das blockieren leider nicht.
Es entsteht aber auch keine queue mit einem Füllgrad, da die GADs einzeln kommen.
Wenn also 100 GADs angefragt werden, dann werden die 100 GADs einzeln mit cmd="item" rübergeschickt.
Somit 100 mal Übertagung, einqueuen usw.

@herrmannj: Es wäre sehr hilfreich, wenn fronthem nach dem "monitor" für die initiale Befüllung alle angefragten GADs in einem cmd="item" gesammelt rüberschicken würde.
Dann könnte ich diese Liste responsiv abarbeiten. Ich habe das mal von meinem addon driver aus simuliert, das hat geklappt.
Es wird ja eh schon ein array rübergeschickt, nur ist da halt immer nur ein GAD mit seinem Wert drin.
Wenn das so klappt, dann haben wir das Thema bereits durch, da es, wie oben beschrieben, meiner Ansicht nach nur ein "Initial-load-Problem" ist.

Für plots regeln wir das ganze unabhängig, die müssen eh mit einem cmd='series' rüberkommen und können somit separat abgearbeitet werden.

[karl0123]

Vorbemerkungen:
Man darf auf keinen Fall die (reichliche) Zeit, die SV benötigt,  bis die Seite erscheint, speziell wenn der page cache aus ist, mit der Zeit verwechseln, die die GADs für das initiale Anzeigen brauchen.
Das "blocking GAD init" Problem beginnt ab dem Moment, ab dem die Seite sichtbar wird und noch keine Werte anzeigt werden.

Das ist schon klar und weiter oben auch von mir beschrieben worden. Der genannte Pagecache ist aber ohnehin ein eher schlechtes Instrument, um Performance zu erhalten. Das müllt nur das DOM zu und hilft bei vielen DOM-Elementen eher nicht und ist Kontraproduktiv (das kann man leicht testen, in dem man mal viele Seiten in den Cache holt). Für genau unseren Anwendungsfall hier ist das eher nicht zu empfehlen, meine ich. Denn dann ist es entscheidend, wie viele gads man insgesamt hat. Zumindest der Domotiga Treiber hat alle Elemente im DOM bei init aktualisiert (so sah es zumindest in der Console aus) und nicht nur die auf der Seite. Das können dann schnell mal 500 werden.

Und was die vielen Gads auf einer Seite angeht: Die hat man sehr schnell, wenn man auch gads im Menü hat. Bei 10 Gads auf einer Seite ist das Blockieren auch schon deutlich spür- und sichtbar (in der Konsole). Bei 40-50 dann fast unerträglich. Und dass diese Zeit erst beginnt, wenn die komplette Seite geladen ist, ist klar. Jedoch ist die Ladezeit der Seite bei mir zu vernachlässigen und das auch ohne Pagecache. Die ist fast sofort da. Das Blockieren macht auch den Unterschied zu z.B. FHEM-Web aus: Der erste Status der Devices wird mit der Seite geladen und man kann sofort interagieren.

[chris1284]

benötigt es für multimedia.image noch weiere vorbereitungen oder reicht  {% import "multimedia.html" as multimedia %} ?

meine def:

Code Auswählen Erweitern

{% import "multimedia.html" as multimedia %}
{{ multimedia.image("WC2", "http://schierke-am-brocken.de/webcam/schierke01.jpg") }}
bringt immer

Fatal error: Call to undefined method __TwigTemplate_bba03a48920a7b9f8724ba2ce9e116e3ccdb15c9f8e14f97f1be7bef41f0ec9a::getimage() in /var/www/smartVISU/vendor/Twig/Environment.php(331) : eval()'d code on line 39

EDIT: wenn man sollte seine pages nicht wie evtl. vorhandene widgets benennen...

[bgewehr]

Das einzige, was mich irritiert, ist das Fragezeichen...

[kumue]

habs bei mir ausprobiert, bild wird ohne probleme geladen... ? vorher entfernt...

[herrmannj]

bzgl der Verzögerung beim initialen Laden:

Ich schlage vor das wir das einfach aufschieben, tritt ja nur auf wenn man echt viele GADs hat und auch dann nur einmal initial. Mittelfristig sollten wir dann mal genaue Messungen machen, wenn die queue dafür nicht funktioniert (wobei sie sollte, die Transitions laufen ja auch non-blocking) brauchen wir halt eine andere Technik, wird sich finden. Die GADs in fronthem initial zu sammeln ist aufgrund der event getriebenen Struktur nicht trivial, mMn wäre der AUfwand höher als der Nutzen.

vg
jörg

[karl0123]

Hm. Ich halte das Performance Problem (und ja, es ist ein Problem) für einen großen Spaßverderber und deshalb für extrem wichtig (manche würden sagen, dass es auch einen extrem schlechten WAF verursacht). Und das es erst bei "echt vielen" Gads ein Problem ist, stimmt ja auch nicht. Es ist aktuell alles noch beta, aber um überhaupt produktiv eingesetzt werden zu können, muss genau das Problem auf jeden Fall gelöst werden, da es sonst produktiv nicht nutzbar ist. Das sind meine 10 Cent zu dem Thema. Ich habe einen extrem schnelle Server und warte 10 Sekunden auf einen Seitenwechsel. Und so viele Gads braucht es dafür nicht einmal. Ich habe ja oben geschrieben, dass es schon bei recht wenigen gads spürbar wird. Und wenn das DOM voll ist, wird es noch schlimmer (Cache ist also kontraproduktiv).

[bgewehr]

Ich nutze noch kein Tablet, sondern im Moment nur das iPhone. Jeder Aufruf ist dabei ein initial load und schön langsam. Da ich beim Zurückblättern auf die Home Seite keine Gads mehr aktualisiert bekomme, ist sogar innerhalb einer Session mehrfach ein Full reload erforderlich. Mich nervts schon ein wenig, dass ich so lange warten muss, bis ich die Garage aufmachen kann...

[Jojo11]

Kann ich bestätigen. Man kommt recht schnell an die Grenze, ab der es zu lange dauert.

schöne Grüße
Jo

[herrmannj]

verstehe ich, aber passt das alles ? Ich habe einen odroid und die Wartezeiten sind sehr überschaubar, wohlgemerkt auf einem nicht über-performanten Tablett. Ich setze es mittlerweile Produktiv ein.

Im übrigen ist das keine Frage von "beta"  - das würde nur fronthem betreffen (läuft doch recht stabil - oder  ). SmartVISU (da würde das hingehören) ist ja ein unabhängiges Paket, das was Du ansprichst betrifft (würde betreffen) alle Installationen quer über alle Systeme (KNX, smarthome.py ++).

Schau doch mal bitte ob diese Geschwindigkeitsbremsen die ja bei Dir sehr drastisch zu sein scheinen vielleicht irgendwo anders verortet werden können. Da scheint was nicht in Ordnung zu sein, zumindest wenn ich Deine Beschreibung in Relation zu der performance setze die ich sehe.

vg
jörg