CometVisu - (interner) Beta-Test

[makki]

Schau mal sicherheitshalber in den vbusmonitor, ETS Gruppenmonitor oder eib.log auf den Rohwert; da hat sich sicher jeder von uns schon mehrfach verhaspelt

Wenns das nicht ist (es gibts da beim N141/01 eine artverwandte sache die allerdings speziell und selten und daher nicht Wert das nochmal hier im falschen Kontext auszuführen): Ich hab mir damals was geschrieben und fertig, würde weder von ABB, Siemens, Tridonic oder Philips auf irgendeinen Fix für irgendwas warten
Beim Plugin assistiere ich gerne
Allgemein in der CometVisu macht das IMHO nur Sinn wenn es auch ein Problem ist, das jeder mit bestimmten EVG's und/oder GW's hat. Kann ich schlecht beurteilen, ich hab nur Tridonic und Siemens.. -> Also input von weiteren gefragt!

Makki

[vlamers]

Hallo,

in Bezug auf das Problem mit den Mobilen Endgeräten hab ich mal "versucht" zu googeln.
Als absoluter Laie herzlich wenig Ahnung davon, aber evtl hilft es:

jQuery Mobile | jQuery Mobile

Für mich klingt das so als könnte man damit u.a die slider bedienen. Nur ob das dann ne komplett andere Baustelle ist, kann ich leider nicht beurteilen.

Gruß

[vlamers]

Noch was:

Das funktioniert bei mir in einer einfachen webseite rel. gut.
Die Erstellte Seite funktionierte mit dem FF noch und hatte keine Einschränkungen durch das Plugin. Und am Handy/Tablet konnte ich die Seiten Swypen. Evtl wäre das was für die Comet? Mir würde es gefallen

Mein Versuch das in die CometVisu einzubauen ist kläglich gescheitert da ich den Code nicht überblicke... Respekt an diejenigen die das noch tun!

http://plugins.jquery.com/files/jque...-1.2.4.js_.txt


Gruß

Edit: unterstützt i* und Android Devices, wie bei anderen aussieht (Meego etc) konnte ich nicht testen.

[Chris M.]

Aus der verlinkten Datei:

A jQuery plugin to capture left, right, up and down swipes on touch devices.

Das klingt schon mal gut.

Kann das jemand mal einbauen, der ein Androiden zum Testen hat?

Ein left wäre optimal um zurück zu navigieren. Das up und down zum scrollen. Nur ein right dürfte wenig Sinn machen.

[vlamers]

Falls das jemand schafft, wäre ich an der Auflösung des Rätsels interessiert in welchen Datein was geändert wurde.
Gerne auch per pm oder E-mail um den Thread nicht voll zu spamen.

Danke

Gruß

[makki]

Klingt, gut, geht auch auf N900 (Maemo/Meego - totes Ding, das rennen hat Android auf Sicht vorerst definitiv gewonnen..)
einbauen traue ich mir ehrlichgesagt nicht zu aber ich finde die Verwendung von jQ(UI) und dgl. absolut sinnvoll! Mehr davon..
Wie ich sicher schonmal anmerkte fände ich auch jQ-UI Themes fast besser als "eigene" Flavours&Designs aber da verstehe ich vielleicht auch nur zuwenig davon.

Makki

[Chris M.]

Wie ich sicher schonmal anmerkte fände ich auch jQ-UI Themes fast besser als "eigene" Flavours&Designs aber da verstehe ich vielleicht auch nur zuwenig davon.

Man kann da sicher mal versuchen etwas Kompatabilität rein zu bringen. Sehe ich aber nicht als sonderlich hohe Priorität an... (Wer am Design was ändern will, sollte CSS so gut kennen, dass er auch gleich an den Source gehen kann)

Was ich aber heute Abend mal gemacht habe, ist ein paar Änderungen am pure Design, die ich schon länger umsetzen wollte. (Warum zum Teufel kann nur FF und IE das CSS calc()?!? Das haben sich Web Designer seit Jahren gewünscht und genau da ist die Umsetzung so lahm )

Gerade bei zwei Änderungen ist der Unterschied deutlich und vermutlich Geschmackssache. Hier würde mich mal das Feedback interessieren:

• Alles ist etwas kleiner geworden. IMHO aber noch gut per Wurstfinger bedienbar
• Die Widgets haben keinen Rahmen mehr (außer beim Editor), was IMHO deutlich edler aussieht.

Falls noch nicht bekannt: Der Design-Gedanke hinter "pure" ist eine minimalistische aber edle Visu auf dunklem Hintergrund.

[Chris M.]

Die Idee mag ich - grundsätzlich. Was zu klären wäre, ist dass hier die Datenstruktur sauber bleibt, d.h. dass nicht mehrere Informationen gleichzeitig in dieses Universal-Attribut geschrieben werden. (Nach Datenbank-Theorie ganz böse...)

Wird uns auf absehbare Zeit ein Attribut reichen?

Ich schätze ja. Dann würde ich das einfach "type", "variant" o.ä. nennen ("option" finde ich nicht so gut, da es hier ja keine Option der Adresse ist, sondern deren Art festlegt)

Da haben wir uns auf 1 Attribut namens "variant" geeinigt - und nun befürchte ich, dass das nicht reicht.

Heute dachte ich mir nämlich, dass ich ein paar mehr und aufwändigere Diagramme brauche. Dabei wichtige Punkte:

• Mehrere Datenquellen bzw. Graphen in einem
• Mehrere Einheiten auf einmal (z.B. Temp + Luftfeuchtigkeit)
• Evtl. bisschen mehr Darstellungsarten, wie z.B. ein Min/Max-Band mit dem AVG in der Mitte drüber
• (für hier nicht wichtig: Zoomen)

Für den ersten Punkt entscheidend wäre vom Attribut "rrd" auf ein Address-Element zu wechseln. Das wäre erst mal straight foreward (außer dass der Editor z.Zt. nur KNX als Address-Quellen kann)
Den zweiten Punkt könnte man noch mit "variant" erschlagen - aber spätestens ab dem dritten bräuchte man deutlich mehr Attribute.

Nun gibt es aber dafür zwei Schwierigkeiten:

1. Der Editor unterstützt das nicht (der kann auch das einfache "variant" noch nicht)
2. Wir sind im Feature Freeze (gerade damit der Editor nachziehen kann)

Was tun?

Wunsch wäre, dass der Editor evtl. etwas in dieser Art verstehen würde:

[...]
elements: {
    label:      { type: 'string',    required: true, multi: false },
    address:    { type: 'address',   required: true, multi: true,
                  address: { type: 'rrd', 
                             source:  { type: 'string', required: true  },
                             color:   { type: 'string', required: false },
                             display: { type: 'list'  , required: false, list: {'bar':'bar', 'line':'line' } }
                           }
                }
},[...]

[makki]

Mir gefällt beides, kleiner finde ich aber besser, hab bei mir ja auch schonmal die Fontsize runtergedreht..
Mit dem variant&Co: die Anforderungen hast Du bereits beschrieben, ich halte mich da leidenschaftslos wie: aber man brauchts irgendwie! (Also mir fehlts richtig, ich behelfe mir mit graph2 solange als image aber das das langsam und keine echte Lösung ist, weiss ich bestens selbst)

Was anderes:
#1) wenn man da eh an dem Diagram rumdreht (ich nehme es mir seit Wochen vor..): Vielleicht kann man das laden der RRD's in unterseiten irgendwie unterpriorisieren.
Es geht zwar eigentlich recht schnell aber bei sportlich vielen (siehe Demo-Visu SVN) z.B. merkt man eine deutliche Verzögerung bis die KNX-stati da sind.
Nicht zuende gedacht: aber so eine Verzögerung bei onload von 500ms für die RRD's damit der /eibread erstmal alleine schnell darf oder sowas ? (In komplex eine Request-queue mit Prios.. Neh..)

#2) sind wir mit dem rrdtool fetchj so zufrieden (funktional, nicht umsetzung)? Ich werde mich dann nämlich mal echt auf den Hosenboden setzen das so oder so ähnlich Upstream ins rrdtool zu bekommen weil ich will davon wirklich mittelfristig keinen fork pflegen.. Und wenn man das sauber einkippt wirds schon werden (mein erster diff war ja gegen die "uralt-version" in lenny)

Makki

[Chris M.]

[...]
Nun gibt es aber dafür zwei Schwierigkeiten:

1. Der Editor unterstützt das nicht (der kann auch das einfache "variant" noch nicht)
2. Wir sind im Feature Freeze (gerade damit der Editor nachziehen kann)

Was tun?

@Julian: Was ist Deine Meinung?

Was anderes:
#1) wenn man da eh an dem Diagram rumdreht (ich nehme es mir seit Wochen vor..): Vielleicht kann man das laden der RRD's in unterseiten irgendwie unterpriorisieren.

Wie's das Diagramm aktuell macht, weiß ich nicht - aber bei den KNX-Größen ist es tatsächlich so, dass die z.Zt. einfach alle mal pauschal geladen werden.

Das zu optimieren hatte ich aufgeschoben, bis es da Performance-Probleme gibt

=> Ja, ist wohl möglich.
==> Bitte Feature-Request oder Bug report stellen

#2) sind wir mit dem rrdtool fetchj so zufrieden (funktional, nicht umsetzung)?

Das ist das RRD Backened für die Graphen, oder?
Nein, damit bin ich nicht zufrieden - dass ausgegebene Datenformat passt nicht (mehr) zu Flot. D.h. hier muss ich live das Datenformat anpassen, seit dem ich Flot auf die neue Version gebracht habe...
Aber, bevor Du das anfasst und upstream schickst, sollten wir die Multi-Daten-Graphen implementieren. Nicht dass die schon wieder ein anderes Datenformat verlangen...

[makki]

Das zu optimieren hatte ich aufgeschoben, bis es da Performance-Probleme gibt

=> Ja, ist wohl möglich.
==> Bitte Feature-Request oder Bug report stellen

Ist jetzt nicht dramatisch, bremst beim initalen laden hier so gefühlte 4 sek. Bei 48 (!) diagrams in der Visu. Fände es halt schöner wenn erst die IMHO wichtigeren (KNX) Werte geholt werden bevor das losbläst; sollte ja auch übersichtlich sein, war mehr eine Diskussions/Geschmacksfrage..
-> FR ist drin, damits nicht untergeht..

Das ist das RRD Backened für die Graphen, oder?

Jep.
Nun. momentan haben wir noch Wunschkonzert (soweit es meine beschränkten C-Kenntnisse zulassen)
Aktuell ist das "rrdtool fetch" (das hat sehr viele Vorteile ggü dump o.ä., die hochoptimierten internas des rrdtools zu nutzen, liefert automatisch beste Auflösung, ...)
-> Kann aber (jetzt schon, ich hab die Ausgabe nur von Zeilen auf JSON umgenudelt) nur mehrere DS in einem RRD, nicht mehrere DS aus versch. RRD's (was wir hier brauchen)

-> Nachdem ich meine Gedanken hierzu aber auch für halbgar halte und das nur ein Quickhack war, das wrapper-Shellscript ist ja nun auch nicht der Königsweg, sollte man sich das evtl. nochmal vorher im Detail überlegen.
Aber an Flot hat sich doch nichts geändert(?); bin da grad nicht so richtig drin (kanns also schlecht begründen), aber mein Plan wäre gewesen für mehrere DS (RRD's) einfach mehrere fetch zu machen und die in die zu flottenden Daten zu schieben.
Weniger wegen der Angst, es nicht hinzubekommen als das halbe rrdtool nach/umzubauen (fetch(j) ist optimal, 10J optimiert, xport etc. dagegen schnarchend langsam (ok: wir sprechen über ms aber es wird diese Visus geben; ich brauch locker auch 200 Diagramme am Ende des Tages - mindestens

Makki

[ctr]

Ich habe mal zwei Fragen:
1. Wie komme ich von einer Unterseite zurück zur vorherigen Ebene? "Back" Button des Browsers ist ja eher eine schlechte Idee, aber ich habe noch kein Element gefunden, mit dem sich zurück navigieren ließe...
2. Wenn ich ein neues Element "Page" anlege, kann ich darauf auch anders Referenzieren? Ich würde eine (die selbe!) Page gern mit einer Grafik und daneben Text verlinken...
(Edit: das ist wohl zur Zeit eher eine theoretische Frage, habe gerade gesehen, dass man aus einem Bild gar keine Page verlinken kann)

Danke!

[vlamers]

Zu 1. Da ist oben eine navigations leiste.
Meinevisu. -> pagename
Wenn du dann auf Meinevisu klickst bist wieder am Anfang.

Gruß

Sent from my Dell Streak using Tapatalk

[ctr]

Das scheint aber nur in bestimmten Designs zu funktionieren, bei "pure" gibts das zB nicht...

[vlamers]

Ich nutze discreet. Aber Pure hat die leiste oben auch!