CometVisu - (interner) Beta-Test

[makki]

Aktuell gibt's in der Konfig das Attribut "datatype". Das ist IMO zu kurz gesprungen.

Das ist die grosse Frage, wierum man das Pferd aufzäumt.
Varianten sind natürlich str/int/float oder eben DPT;
Aber die DPTs haben den grossen Vorteil, das das - wenn es denn konsequent überall umgesetzt (wäre/würde) nicht nur einen Wert enthält sondern auch bereits definiert ist was da & welcher Einheit drinsteht (°C, mA, Bananen,...)

Grundsätzlich finde ich den Gedanken mit den DPT's ja nicht schlecht, das ist auch IMHO nicht grundlegen (zu) KNX-spezifisch.
Insbesondere in der Visu spielt das dann auch seine Vorteile aus; man nötigt den anwender (so komplett zuende gedacht!) nicht an 7 Stellen einzustellen das es nunmal °C oder % sind, welche Range die haben und das man dazu gewöhnlich halt ne Grafik haben will, bei der °C dabeisteht

[*]das Backend darf bei "w" nicht mehr auf "d" hören

Ok, wir können die 7 Zeilen löschen aber das ist ja jetzt schon so, wenn es kein d gibt ist es rohmaterial, das so 1:1 durchgereicht wird (solange es ein A_Groupvalue_Write ist)
Da würde ja jetzt nicht gesprengt wenn ich Dich richtig verstanden hab?

Viel spannender finde ich in dem Kontext mal langsam a bisserl Autorisierung, insbesondere in write-backend einzustricken..

Makki

[Chris M.]

Nebenbei: was heute im Telefonat mit Nils noch hochkam: eine allzugrosse Abhängigkeit von KNX-only (DPT) sollte man IMHO auch im Editor vermeiden, KNX ist nur eines von vielen möglichen, wo sich die Visu ihr Futter holt.

Hier möchte ich etwas tiefgreifender aufräumen:

Aktuell gibt's in der Konfig das Attribut "datatype". Das ist IMO zu kurz gesprungen.
Grundsätzlich hat nämlich das Backend die Daten in einem irgendwie nativem Format da liegen. Diese müssen für die Visu in ein für die Visu passendes Format transformiert werden.
=> Ich möchte bei jedem Datum eine "conversion" (oder gerne ein besserer Namen, falls es Vorschläge gibt) haben, die die Daten, die vom Backend kommen, bzw. dorthin gehen, so transformiert, dass die Visu damit etwas anfangen kann.

Die einfachste "conversion" ist RAW - und die leitet einfach die rohen Werte durch. Beim KNX wird die kaum zu brauchen sein, bei einem Logik-Engine-Backend evtl. schon, bei einem Bus-Monitor definitiv.
Die nächsten "conversions" werden "int", "float" und "string" heißen und den entsprechenden JSON Wert per JavaScript cast konvertieren.

Alle weiteren "conversions" sind nicht bestandteil der normalen Visu, sondern ein Plugin.
Das für uns wichtige Plugin (und damit natürlich im CometVisu-Paket enthalten) ist das KNX-Plugin. Dort werden alle Werte so transformiert, wie jetzt schon gewohnt. (Hier stelle ich mir vor, einen globalen Namespace-Prefix einzustellen, wie z.B. "DPT", an den dann die entsprechenden Einträge angehängt werden)

Neben der dafür grundsätzlichen Infrastruktur benötigt diese Änderung noch folgendes:

• jeder muss seine visu_config.xml anpassen
  (also z.B. aus <info address="1/2/59" datatype="5.001" >R</info> ein <info address="1/2/59" conversion="DPT5.001" >R</info> machen)
• das Backend darf bei "w" nicht mehr auf "d" hören (war eh "illegal" laut Protokoll-Spek) und nur noch die rohen Werte annehmen
• der Editor wird anzupassen sein

Der Vorteil dieser Änderung ist, dass wir gänzlich unabhängig vom Backend werden. Egal ob dort ein KNX, eine Logic-Engine, ein xPL, ein OPC UA, ein MisterHouse, ... dran hängt. Auch lassen sich damit so seltsame Dinge wie Temperaturen in °F statt °C abhandeln.
Und selbst so Sachen, wie wenn ein Backend in Fixed-Point rechnen würde (aus der Ecke habe ich mir dieses Konzept abgeschaut...) würde die Anzeige in der Visu perfekt funktionieren.

Gibt es dazu andere Meinungen?
Und wie können wir das am besten und mit den wenigsten Verlusten umstellen, da hier gleichzeitig das Backend und die CometVisu (dort sowohl Client wie auch Visualisierung) geändert werden müssen?

[Chris M.]

So, jetzt habe ich 275 Postings auf 28 Seiten gelesen und alle dort geposteten Wünsche und Bug in den Tracker auf SF eingefügt.
=> Bitte dort nachsehen ob alles stimmt und nichts vergessen wurde.

Bitte außerdem prüfen, ob nicht noch Wünsche oder Bugs mal per Mail oder PN geschrieben wurden und diese dann dort bitte mit eintragen.

Alles was nicht dort im Tracker steht, wird vergessen werden!

[makki]

<Wunschkonzert>

Ich hoffe ich hab euch nicht die Sprache verschlagen
aber am ende des Tages will ich ja auch "nur" die perfekte Visu.. Wenn ich mich da mit dem flot&js hinsetze, dann dauerts halt 720h und es sieht danach halt trotzdem k*** aus..
Wie die Daten rauskommen und wo man da noch 100-200ms rausholt: das versteh ich, das sind eher 10 Minuten

Ich musste gerade wieder schmunzeln: hier
Sorry, das könne wir doch zusammen echt erheblich besser, odrrr ?

Makki

[makki]

Hmm, nan hätte ich eigentlich wissen müssen, bei dem alten .sh war das schonmal gefiltert
Ist "getüdelt", selbes .tar.gz..

Noch was anderes: theoretisch kann es ja mehrere Datasources in einem RRD geben. In der Praxis halte ich davon zwar jetzt nicht soviel und man kann das auch aktuell kaum erreichen aber wenn man damit rechnen würde müssten wir eigentlich sowas wie
[[time,["ds0","ds1",...]]]
ausspucken.
Im "Normalfall" wäre das natürlich
[[time,["ds0"]]]

Ich habs jetzt mal so gemacht.. (Beispiel für mehrere ds: /rrdfetch?rrd=owserver_bus0.rrd&ds=MAX&start=-2day&end=-1day&res=1800)

<Wunschkonzert>
Zur Ausgabe:
a) "Popup" ähnlich wie in /oldvisu/ beim anklicken einer Temperatur (info)
b) Eingebunden als Standalone-widget mit Graph direkt auf der page
c) Auflösung/Zeitraum sollten IMHO sinnvoll vorbelegt sein, damit man sich nicht totklicken muss (Tag/Woche/Monat/Jahr wirds in 90% ja tun) - zusätzlich konfigurierbar (->auch ein Thema für multilanguage..) wäre natürlich bestimmt schön
</Wunschkonzert>

Makki

[netzkind]

Jetzt mit 3 Nullen mehr

Super.
Und jetzt: nan rausfiltern oder als String (tüddelchen außenrum) ausgeben
Sonst weigert sich der Browser schon beim Laden des Strings das als JSON zu akzeptieren, und wir kommen im Javascript garnicht erst an die Daten um irgendwas zu machen.

Abgesehen davon gibt es Fortschritte
Fragen die sich mir noch stellen: sollen Auflösung (rrdfetch -r) und Zeitraum (-s, -e) automatisch gewählt werden, oder über die Konfiguration abgelegt werden?
Und: Diagramm inline oder als "lightbox" - oder konfigurierbar (ich fürchte ich weiß was die Antwort ist).

Grüße,
Julian

[makki]

Ich bin ja schon ganz fuchsig auf das flot-widget
Aber was anderes: Refresh von images (in diesem Fall RRD in visu-svn unter Wetter) funzt zumindest in Chromium ned.

Makki

[makki]

Jetzt mit 3 Nullen mehr

Makki

[netzkind]

Hi makki,

schaut schon viel besser aus.
Jetzt muss ich nurnoch den Timestamp für die Ausgabe auf miliseconds umstellen (javascript erwartet das so), dann sollte das relativ bald rocken.

Da ich mein wiregate jetzt nicht mit einem vollen build-environment belasten will ... falls du das zufällig kurz umsetzen könntest, makki, dann wäre das klasse )

Grüße,
Julian

[makki]

Content-type: uuups
War wohl ein sehr schneller Quickhack..

und richtig wäre auch "application/json". Ich würds an der Stelle einfach ganz rausschmeißen, das kann das shellskript übernehmen.

application/json kann man nur nicht so schön im Browser gleich sehen - ist geändert.
Das Shellscript soll natürlich am Ende des Tages eigentlich ganz weg, aber obs die 20ms jetzt rausreissen?...

Ideal wäre es die Daten einfach als array zu bekommen, nicht als Objekt, also

Deswegen fragte ich ja

Da ich leider nur die binary-Version von rrdtoolj habe bin ich da jetzt auf deine Zuarbeit angewiesen

Ich eile, diff zu meiner Entlastung im Anhang

Allerdings wärs 30 Minuten schneller gegangen, wenn ich mir nicht eingebildet hätte, das mit dpkg, quilt&Co... (quilt ist mal wieder so ganz böse hanky-cranky.. aber man lernt eben nie aus..)
Unter der alten URL zu laden.
(gzip ist fertig, habe ich jetzt aber weggelassen, weil das spielt zum testen glaube ich echt keine Rolle - wir reden von 10 vs 30 kB )

Makki

Index: rrdtool-1.3.1/src/rrd_tool.c
===================================================================
--- rrdtool-1.3.1.orig/src/rrd_tool.c	2010-11-12 21:14:36.000000000 +0100
+++ rrdtool-1.3.1/src/rrd_tool.c	2010-11-12 21:16:52.000000000 +0100
@@ -695,6 +695,30 @@
             free(ds_namv);
             free(data);
         }
+    } else if (strcmp("fetchj", argv[1]) == 0) {
+        time_t    start, end, ti;
+        unsigned long step, ds_cnt, i, ii;
+        rrd_value_t *data, *datai;
+        char    **ds_namv;
+        int written = 0;
+
+        if (rrd_fetch
+            (argc - 1, &argv[1], &start, &end, &step, &ds_cnt, &ds_namv,
+             &data) != -1) {
+            datai = data;
+            // printf("Content-Type: text/plain\n\n");
+            printf("[");
+            for (ti = start + step; ti <= end; ti += step) {
+                if (written==1)
+			printf(",");
+                printf("[%10lu,", ti);
+                for (ii = 0; ii < ds_cnt; ii++)
+                    printf(" %0.2f", *(datai++));
+                printf("]");
+                written = 1;
+            }
+            for (i = 0; i < ds_cnt; i++)
+                free(ds_namv[i]);
+            free(ds_namv);
+            free(data);
+            printf("]\n");
+        }
     } else if (strcmp("xport", argv[1]) == 0) {
         int       xxsize;
         unsigned long int j = 0;

[netzkind]

Hi makki,

Zum testen reichts, bei einem Release wird man sich da was anderes ausdenken..

mir reichts leider nicht
Die rrdtoolj gibt im Body ein "Content-type text/plain" aus - das ist am falschen Ort, und richtig wäre auch "application/json". Ich würds an der Stelle einfach ganz rausschmeißen, das kann das shellskript übernehmen.

Und die Daten sind nicht valide (vergleiche JSONLint - The JSON Validator.).
Ideal wäre es die Daten einfach als array zu bekommen, nicht als Objekt, also

[
    [
        1290631500,
        417.18 
    ],
    [
        1290633000,
        451.21 
    ],
   ...
]

Zusätzlich wichtig ist, dass vor schließenden ] keine Komma gesetzt sein dürfen - sonst ist es nicht valide.

Da ich leider nur die binary-Version von rrdtoolj habe bin ich da jetzt auf deine Zuarbeit angewiesen

Grüße,
Julian

[makki]

zum rrdfetch noch:
Die timestamps sind UTC, ich denke das ist Ok (kennt man im JS/Browser die lokale TZ?) - ansonsten sollte man das Datenformat evtl. noch mit aktueller lokaler TZ am Server erweitern?)

Und ich hab gerade mal ein bisschen mit gzip/zlib dafür gespielt:
- Performanceunterschied an Client&Server: nicht messbar
- übertragene Datenmenge: natürlich 1/3
- macht via Wlan&GSM schon wieder ggfs. 100ms (ok, wir sprechen von 200 vs. 300..)
(wer probieren will: genannte URL und rrdfetch-gz statt rrdfetch)

Makki

[makki]

rrdfetch

Ganz dirty hier

Mir hat das alles nicht getaugt, bzw. wars mir 200ms zu langsam deswegen hab ich einfach kurz das rrdtool auf json-Ausgabe umgeschrieben
Zum testen reichts, bei einem Release wird man sich da was anderes ausdenken..

Makki

[netzkind]

Hi makki,

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

wo bekomme ich das denn her? Flot-Einbindung scheint jetzt nicht wirklich so schwer zu sein, schwerer zu entscheiden wie man es optisch haben will

Grüße,
Julian

[luigi4711]

Funktioniert