Demo der 0.8.x?

[Chris M.]

Das wäre aber doch auch der Fall, wenn man die Visu-Seiten auf dem Handy Cached, oder? (cache.manifest)
Warum habt ihr das nicht so gemacht?

Den appcache nutzen wir schon seit einiger Zeit um Transfer-Volumen zu sparen

Bei der CV muss doch 'live' aus xml html gemacht werden (denn das rendert der Browser, oder?). Das entfällt bei der SV (bzw. mach der Server). Ich weiß aber nicht, wie viel "Arbeit" das ist.

Das betrifft auch etwas die Frage dadrüber.
Bei dem Systemdesign muss man sich überlegen, wo welche Ressourcen zur Verfügung stehen.

Bei einer klassischen Web-Seite habe ich einen (ausreichend) leistungsfähigen Server mit genug RAM, CPU, Storage, ... für die typische Zahl der zu erwartenden Kunden (und wenn dann mal Slashdot auf die Seite verlinkt geht's halt per Slashdot-Effekt vorübergehend in die Knie). Der Client dagegen ist vergleichsweise leichtgewichtig, weil der Browser nur nebenbei läuft (d.h. ein Programm von vielen ist), auf einem Mobil-Gerät läuft, ...
=> Hier kann man Ressourcen auf dem Server ausgeben um welche auf dem Client zu sparen.
Und bei modernen Seiten wird das eigentlich auch schon nicht mehr gemacht, da der Client einfach stark genug ist. Da gibt's höchstens noch dynamisches Bandbreiten-Management für Videos per Streaming.
Und die dynamischen Webseiten um die Erstellung der Webseiten zu vereinfachen (z.B. bei CMS) - d.h. hier gebe ich mehr für technische Ressource aus um humane zu sparen.

Und nun zu einer ganz anderen Welt: Heimautomatisierung.
Hier habe ich einen Server, der 24/7 laufen muss, d.h. der Stromverbrauch relevant ist. Der aber kaum Leistung haben muss, schließlich gibt es nur ganz wenige Clients, die auf den Server zugreifen.
Wir reden folglich von Servern wie einer Routern (gute 100 MHz, dickere um 32 MB RAM), WireGate / Alix.1d (500 MHz, 256 MB RAM) oder Raspberry Pi (700 MHz, 256 MB oder 512 MB RAM).
Und dazu von Clients die als PC / Laptop schon seit langem mit 3 GB aufwärts ausgestattet sind und eine CPU mit mehreren Kernen im GHz-Bereich. Oder von mobilen Geräten die auch RAM im Gigabyte Bereich und CPUs im Gigaherz-Bereich haben.
=> Hier hat der Client deutlich mehr Ressourcen als der Server!
=> Da der Server sehr lange im Einsatz bleibt (wer tauscht den schon gerne, wenn der läuft und das Haus davon abhängt?!?), die Clients aber alle Naselang ausgetauscht und leistungsfähiger werden

Insofern ist die Architektur bewusst so gestaltet, dass ein Server mit minimalen Ressourcen zum Einsatz kommen kann. Ein Web-Server reicht. Und der eibd + die CGI-Bin sind winzig klein.

PHP ist ein reines Komfort-Feature, die CV läuft auch wunderbar ohne.
Python (egal welche Version...) wird nicht mal für den Komfort benötigt.

Kommt das nicht darauf an, wie die "App" funktioniert? Sie könnte die Seiten (html?) ja auch jederzeit vom (schnellen) Flash laden, statt beim start komplett in den Flash.

Das könnte man in der CV problemlos zusätzlich implementieren (-> Offline Storage). Bisher habe ich aber noch keine groben Probleme mit der Ladezeit gehört.

Das hängt übrigens auch mit der Architektur zusammen, bzw. den Design-Prämissen:
Eine Visu lädt man 1x und dann läuft die ewig.
=> Beim Laden darf man gerne etwas Zeit investieren, solange ich beim Betrieb keine Zeit vergeude (bei einem klassischen Programm würde man hier von einer Optimierung sprechen wo man die Run-Time dadurch vermeidet, dass man möglichst viel zur Compile-Time erledigt)
=> Die Seiten werden beim Laden aufgebaut und dann im RAM gehalten
=> Beim Betrieb werden nur noch genau diese Rechenoperationen durchgeführt die zwingend und minimal notwendig sind.

Übrigens: Durch Swapping kümmert sich dann das Betriebssystem darum dass die nicht genutzten Seiten notfalls aus dem RAM vorberechnet im Dateisystem abgelegt werden. Mit maximaler (da Null Zusatzberechnungen) Geschwindigkeit wenn die wieder rein geholt werden.

[henfri]

Richtig. Sobald die Visu im Browser geladen wurde, liegt alles notwendige vor und kann "flutschen". Nur noch die Daten werden aktualisiert - genau dann, wenn es neue gibt (d.h. unabhängig vom Seitenwechsel).

Das wäre aber doch auch der Fall, wenn man die Visu-Seiten auf dem Handy Cached, oder? (cache.manifest)
Warum habt ihr das nicht so gemacht?

Richtig bzgl. RAM - aber hier wurde bewusst die Entwicklung der Hardware mit eingerechnet. Die CPU ist davon nicht betroffen.

Bei der CV muss doch 'live' aus xml html gemacht werden (denn das rendert der Browser, oder?). Das entfällt bei der SV (bzw. mach der Server). Ich weiß aber nicht, wie viel "Arbeit" das ist.

Und: wenn man die Visu als "App" oder klassischen Client hätte, würde genau so viel RAM dafür verbraucht werden.

Kommt das nicht darauf an, wie die "App" funktioniert? Sie könnte die Seiten (html?) ja auch jederzeit vom (schnellen) Flash laden, statt beim start komplett in den Flash.

Gruß,
Hendrik

[Chris M.]

Bei der CV muss nach meinem Verständnis beim Seiten-Wechsel kein Code vom Server geladen werden (sondern nur die KNX-Daten), richtig?

Richtig. Sobald die Visu im Browser geladen wurde, liegt alles notwendige vor und kann "flutschen". Nur noch die Daten werden aktualisiert - genau dann, wenn es neue gibt (d.h. unabhängig vom Seitenwechsel).

Das ist sicher ein Vorteil der CV, der aber andererseits durch höhere Anforderungen an den Client (Speicher, Prozessor) erkauft wird, richtig?

Richtig bzgl. RAM - aber hier wurde bewusst die Entwicklung der Hardware mit eingerechnet. Die CPU ist davon nicht betroffen.
Und: wenn man die Visu als "App" oder klassischen Client hätte, würde genau so viel RAM dafür verbraucht werden.
D.h. es entstehen dadurch keine Performance-Nachteile sondern eben Vorteile

[henfri]

Hallo,

na dann ist ja alles gut.
Page-Cache ist aber eine Einstellung in der Konfiguration der SV -Nix im Browser. Nach meinem Verständnis werden die html-Seiten dadurch vor-erzeugt, so dass diese nicht bei jedem Aufruf via php erzeugt werden müssen.

Bei der CV muss nach meinem Verständnis beim Seiten-Wechsel kein Code vom Server geladen werden (sondern nur die KNX-Daten), richtig?

Das ist sicher ein Vorteil der CV, der aber andererseits durch höhere Anforderungen an den Client (Speicher, Prozessor) erkauft wird, richtig?

Gruß,
Hendrik

[Chris M.]

Wobei es auch wirklich nur auf dem Smartphone bemerkbar ist. Auf dem PC nicht. Hattest du bei deinem Versuch den Page-Cache an?

Mein PC ist da eine üble Umgebung - den hab ich mit entsprechenden Erweiterungen (Firebug + ein paar weitere Plugins) da schon auf einen ziemlich unüblichen Stand gebracht - und dann sind da auch noch im Schnitt 100 Tabs auf 4 virtuellen Bildschirmen offen.
U.a. deswegen teste und entwickle ich inzwischen fast nur noch im Chrome - auch wenn ich im Firefox surfe...
=> Keine Ahnung was da der reale Stand war.

Es ist schon lustig, was bemerkt wird und was nicht.

Jepp! :-) Das gilt aber nicht nur für mich, meinst du nicht *zwinker*

[...]

Nö, das ist eine allgemeine Feststellung. Und die betrifft mich selbst auch - gerade wenn ich nur mal schnell einen Überblick will.
=> Ich hab das als Kritik aufgefasst - aber im positiven Sinn ("Theaterkritiker"), nicht als Motzen

[henfri]

Hallo Chris,

doch, ich glaube, das habe ich weiter oben geschrieben -und gesagt hab ich es auch und ich glaube, es ist auch auf dem Video zu sehen -bin jetzt zu faul nachzusehen.

Wobei es auch wirklich nur auf dem Smartphone bemerkbar ist. Auf dem PC nicht. Hattest du bei deinem Versuch den Page-Cache an?

Es ist schon lustig, was bemerkt wird und was nicht.

Jepp! :-) Das gilt aber nicht nur für mich, meinst du nicht *zwinker*

Bitte fair bleiben. Ich habe versucht alle Vor- und Nachteile beider Varianten neutral darzustellen. Ich hoffe, das ist mir gelungen. Wenn ich hier etwas kritisiert habe, war das sicher beabsichtigt, aber ganz sicher auch konstruktiv.
Ich habe auch bemerkt, dass ihr an dem Thema dran seid.

Gruß,
Hendrik

[Chris M.]

Es ist schon lustig, was bemerkt wird und was nicht.
Der dynamische Zoom beim Diagram ist wirklich schön - aber dass der Seitenwechsel bei der SV immer eine Lade-Gedenksekunde dauert hab ich noch nirgends beschrieben gesehen...

[henfri]

[smartVISU] Demohaus

v.a. smartVISU Documentation v2.7
ganz unten zoomable (Rechteck zeichnen).

--> Funktionalität. Man kann auch einzelne Linien ausblenden (klick auf die Legende)
Eben interaktiv statt statisch.

Gruß,
Hendrik

[MicHau]

Die Plots in der SV sind viel besser. Aber ich glaube, an der Front tut sich gerade noch etwas (flot), oder?

Ja, wir haben daran ein bisschen was verbessert. Was ist denn in der SV besser, Fuktionalität, Design, etc.?

[henfri]

Ach so.
Die Plots in der SV sind viel besser. Aber ich glaube, an der Front tut sich gerade noch etwas (flot), oder?

Gruß,
Hendrik

[henfri]

geht jetzt.

Gruß,
Hendrik

[henfri]

Hallo,

ich gucke morgen mal nach den Videos.
Ich habe nix geschaltet in der CV. Da(her) ist mir nix negatives aufgefallen.

Gruß,
Hendrik

[Knaller]

Moin. Ich kann mir nur das Video von Smart Visu ansehen
CV ist der link tot
Gruß Herbert



Sent from my iPhone using Tapatalk

[swiss]

Hallo Hendrik

Leider kann ich keines deiner beiden Videos aufrufen. Ich hoffe die CV war nicht zu lahm. Denn hinter der CV Visu in dem Link den ich oben gepostet habe werkelt kein KNX BUS sondern ein Perl-Plugin dass einen KNX simulieren soll...

Dies hat aber 2 Nachteile...

1. Wenn längere Zeit niemand die GA's beschreibt, werden beim aufrufen keine Zustände angezeigt. (lesen von Zuständen ist im Plugin nicht vorgesehen)


2. Durch den Umstand, dass ein relativ umfangreiches Plugin auf eine Zustandsänderung reagieren und eine passende Antort erzeugen muss, ist die Rückmeldung relativ träge.

Die "live" Demo ist also nicht wirklich dazu geeignet die Performanc zu demonstrieren. Es ging eher darum, dass man einen Einduck davon bekommen kann, wie so eine config aussehen könnte. Man kann die CometVisu damit selber erforschen

[henfri]

Hier die Videos:
SmartVisu (smarthome.py lief gerade nicht, daher keine Werte; die kommen mit etwa der gleichen Verzögerung wie bei der CV.
CometVisu

Gruß,
Hendrik