CometVisu - (interner) Beta-Test

[vento66]

Ja Du hast recht, es ist das alte cometvisu Paket, ich war der Meinung das es das ein Update gab.....

Aber setzen wir doch mal hier an:

D.h. entweder nimmst Du die aktuellste Version aus dem SVN (gut machbar, bedingt aber die Bereitschaft mit Entwickler-Tools zu arbeiten)

Das bedeutet im Klartext?

[Chris M.]

Naja soweit hatte ich das auch gedacht jedoch:
Ups! Dieser Link scheint nicht zu funktionieren.

Wahrscheinlich nutzt Du nicht die Version aus dem SVN sondern das cometvisu Paket. Das ist zu alt - da gibt es noch keinen Editor...
D.h. entweder nimmst Du die aktuellste Version aus dem SVN (gut machbar, bedingt aber die Bereitschaft mit Entwickler-Tools zu arbeiten) oder Du musst warten, bis Makki ein neues Paket schnürt.

Ein neues Paket wäre auch langsam an der Zeit - aber dazu würde ich gerne vorher den dynamischen Design-Wechsel noch einbauen (heute Abend?). Meine Vorstellung wäre dann, dass die Demo-Visu immer den aktuellen Paket-Stand zeigt. Und das das Paket auf einem Release aufsetzt, d.h. einem Tag/Branch im SVN. Aber evtl. können wir das dieses Wochenende mal üben

PS: nicht ausprobiert, aber wahrscheinlich funktioniert der Editor mit dem entsprechenden Link/Datei auf Makkis Demo-Visu

[vento66]

Naja soweit hatte ich das auch gedacht jedoch:
Ups! Dieser Link scheint nicht zu funktionieren.

jetzt hab ich mal auf der Konsole reingeschaut, und mein Browser hat recht!

Also jetzt doch noch mal für die "Geistig etwas unterbelichteten" Woher bekomme ich die edit_config.html?

[Chris M.]

So wenn jemand einem Doofen mal kurz erklärt, wie der Editor auf das Wiregate kommt

Für die Doofen gilt die selbe Beschreibung wie für die Nicht-Doofen :

Im Visu-Verzeichnis musst Du im Browser nur die Datei edit_config.html aufrufen, d.h. typischerweise

http://wiregateXXX/visu/edit_config.html

PS: Linux-Kenntnisse sind dafür nicht notwendig

[vento66]

So wenn jemand einem Doofen mal kurz erklärt, wie der Editor auf das Wiregate kommt wäre ich sehr dankbar (ich und Linux- das sind 2 verschiedene Sachen die sich erst noch finden müssen ) Aber langsam wirds

[makki]

(könnte bisschen Platzverschwendung werden, wenn mehrere Designs die selben Dateien nutzen - aber die sind nur auf der Platte und da kostet's nix)

Mach Dir da mal keinen Kopp Wir haben 4GB, durch das löschen von 500 in den Basics überflüssigen Paketen könnte man nochmal >500MB einsparen aber das wurde bewusst nicht wegen 20 EUR kompliziert gekrippelt..
Ich mag "fette Systeme" der einfachheit halber; solange es keine Not gibt - 20 EUR lösen bei mir keine Not aus

(evtl. auch ein PHP?)

Finde ich Ok/egal. PHP (wie py/pl/whatever) ist ja "eh da".
Bei solchen geschichten IMHO egal, wenn es "gemein tackert" mache ich aber lieber etwas resourcenschonendes (weil die REG-Variante mit krüppel-ARM liegt nunmal schon aufm Tisch )
-> siehe RRD, da will ich einfach das die Grafik unterhalb der bekannten Akzeptanzschwelle von 300ms "da" ist - da will ich offengestanden P*&Co meiden wo es geht.
Man lernt ja auch dazu

Makki

[Chris M.]

(*) Mein Ziel - aber noch nicht umgesetzt - war bei dem Styling zwei Level anzubieten, ein Design und als Variante dann ein "Flavour". Konkret wäre das Design das was man bisher gesehen hat und was netzkind gerade geändert hat. Das Flavour wäre bei dem klassischen Design unterschiedliche Farben, d.h. das bekannte Orange, oder ein Blau, oder Grün, oder ... - und das Sub-Seiten abhängig.
Die konkrete Umsetzung, v.a. die Auswirkung auf's CSS, habe ich mir aber noch nicht überlegt.

Hier bin ich jetzt einen kleinen Schritt weiter:

• jedes Design hat seinen eigenen Unterordner bekommen (könnte bisschen Platzverschwendung werden, wenn mehrere Designs die selben Dateien nutzen - aber die sind nur auf der Platte und da kostet's nix)
• Das Design ist nun in der normalen Config-XML einstellbar
• Die Flavours sind bereits einstellbar - die Umsetzung ist aber noch nicht implementierbar
• Wie der Editor mitbekommen wird, welche Designs es zur Auswahl gibt ist noch offen (evtl. auch ein PHP?); beim Editor habe ich auch keinerlei Integration diesbezüglich getrieben
• Für die Demo-Visu schreibe ich noch ein User-Widget, dass dynamisch durch die Designs toggelt - dann müssen wir uns nicht endgültig entscheiden, wass das Standard-Design ist und der Endanwender sieht die Möglichkeiten

[makki]

Wie viele Images hast du denn?

Nicht so viele aktuell
Aber wir haben bei der letzten Visu ein paar "usability"-Tests und umfragen gemacht; das wurde als störend empfunden

Dann mach das mal, und dann ist das mit flot sicher machbar.

Ist das json so genehm? (siehe http://mm-ho-dyndns.org/cgi-bin/rrdf...-1day&res=1800 - das ist NICHT das in /oldvisu verwendete - 100x awk&grep weniger )
Hab kurz das rrdtool umgehacked, das es gleich json ausgibt, wie man das distributionstechnisch eintütet..
Die Timestamps sind UTC, die Daten %0.2float

Da in den Feature-Requests viel gutes und wichtiges steht und es in diesem Thread einfach zu unübersichtlich wird das alles wieder zu finden ohne dass etwas verloren geht, schlage ich vor, den dafür vorgesehenen Bug-Tracker auf SF zu nutzen:
SourceForge.net: Open Automation: Tracker

Klingt sinnvoll, ich schreib gleich mal was rein..

Makki

[Chris M.]

Featurevorschlag: [...]

Da in den Feature-Requests viel gutes und wichtiges steht und es in diesem Thread einfach zu unübersichtlich wird das alles wieder zu finden ohne dass etwas verloren geht, schlage ich vor, den dafür vorgesehenen Bug-Tracker auf SF zu nutzen:
SourceForge.net: Open Automation: Tracker

Find ich eine gute Idee. Platz sollte genug sein - falls Chris das nicht in 24 Stunden umgesetzt hat setz ich mich dran

Mensch machst Du hier Druck - dabei probiere ich gerade die Plugins dazu zu bringen das zu tun was ich will, schließlich soll meine Visu automatisch an und aus gehen
(Die State-Machine für An- und Abwesend läuft super - aber die Inter-Plugin-Kommunikation über GAs schein doch etwas, ähm, speziell zu sein...)

[netzkind]

- kombiniertes toggle/dim-Widget (so ähnlich wie in meiner alten Demo-Visu - wieder online unter http://mm-ho.dyndns.org/oldvisu/ - den Slider auf 0 zu ziehen misslingt gerne&oft)

Find ich eine gute Idee. Platz sollte genug sein - falls Chris das nicht in 24 Stunden umgesetzt hat setz ich mich dran

- Klickbarer Link bei images -> yr.no in neuem Tab oder die Unwetterwarnung würde viel parsen und viel gefummel sparen, weil man braucht ja nur die Infos; optimal wäre wohl sowas wie ein "??frame"-Popup, das man aufm Fullscreen-touch sicher wieder schliessen kann (?)

Iframe in einer Lightbox. Technisch sicher machbar.

- jetzt sicher eher feintuning, aber ein preloaden der images würde den start noch leicht verhübschen IMHO

Wie viele Images hast du denn? Ich seh da eher ein Problem mit der eingebetteten Schriftart, die wird vom Browser offenbar nicht über den Cache gezogen und dadurch relativ lahm. Ggf. wechsel ich da noch mal auf Systemschriftarten, obwohl ich im Sinne der "any device - same visual" eingebettet bevorzuge.

- hinter die "info" (evtl. neues widget "info-graph"?) könnte man ja jetzt schön den flot legen (siehe ebenso /oldvisu, sind aber jetzt dort nicht live die Daten).. aus dem rrdfetch.sh mach ich dann auch was gescheites, versprochen..

Dann mach das mal, und dann ist das mit flot sicher machbar.

Grüße,
Julian

[makki]

@Julian: Super!

Featurevorschlag:
- kombiniertes toggle/dim-Widget (so ähnlich wie in meiner alten Demo-Visu - wieder online unter http://mm-ho.dyndns.org/oldvisu/ - den Slider auf 0 zu ziehen misslingt gerne&oft)
- Klickbarer Link bei images -> yr.no in neuem Tab oder die Unwetterwarnung würde viel parsen und viel gefummel sparen, weil man braucht ja nur die Infos; optimal wäre wohl sowas wie ein "??frame"-Popup, das man aufm Fullscreen-touch sicher wieder schliessen kann (?)
- jetzt sicher eher feintuning, aber ein preloaden der images würde den start noch leicht verhübschen IMHO
- hinter die "info" (evtl. neues widget "info-graph"?) könnte man ja jetzt schön den flot legen (siehe ebenso /oldvisu, sind aber jetzt dort nicht live die Daten).. aus dem rrdfetch.sh mach ich dann auch was gescheites, versprochen..

Makki

P.S.: die visu_config ist nicht mehr speicherbar - absicht - man sieht ja trotzdem wie es funktioniert..
P.P.S.: ich geh jetzt mal den segfault suchen, passiert hier aber nur homöopathisch..

[netzkind]

@Julian: Jetzt kapiert: der widget-Editor zeigt bei egal was die letzte ausgewählte GA, nicht unbedingt die für das Widget eingestellte an..

Kann ich reproduzieren, Grund ist gefunden, ich habs jetzt auf der Todo.

Grüße,
Julian

[netzkind]

Hi makki,


Ich hab eben im SVN noch die CSS-Datei für den Editor-Modus angepasst - hab das eben erst bei dir gesehen dass Editor und Visu in unterschiedlichen Designs ausgeliefert werden - unschön.

Chris warf noch die Idee in den Raum da auf duplicate code zu verzichten, das sollte ich mal versuchen für den Editor mehr zu beherzigen.

Grüße,
Julian

[netzkind]

Bei dem Thema RGB LEDs kam mir folgender Gedanke. Wäre es evt. sinnvoll den schönen Farb- (Grau-)verlauf hinter dem Slider noch jeweils in einer R,G & B Variante anzubieten!? Würde hier direkt helfen die jeweils richtige LED anzufassen...

Das müsste man über einen Style ableisten können denke ich spontan.
Werd ich mir auch mal auf die Todo-Liste schreiben.

Grüße,
Julian

[luigi4711]

Sieht gut aus, schön einfach gehalten, so dass man auch gleich nen Überblick hat.

Bei dem Thema RGB LEDs kam mir folgender Gedanke. Wäre es evt. sinnvoll den schönen Farb- (Grau-)verlauf hinter dem Slider noch jeweils in einer R,G & B Variante anzubieten!? Würde hier direkt helfen die jeweils richtige LED anzufassen...

luigi