CometVisu - (interner) Beta-Test

[makki]

Jetzt mit 3 Nullen mehr

Makki

[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

[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]

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

[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

[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!

[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?

[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.]

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,...)

Wahrscheinlich habe ich mich mal wieder konfus ausgedrückt... Mein Ziel ist von Einheiten weg zu gehen und zu Transformations-Formeln hin zu gehen. Das Ergebnis einer Transformation ist immer ein JavaScript nativer Wert (also ein int, float oder string) mit optional einer Einheit.

Grundsätzlich finde ich den Gedanken mit den DPT's ja nicht schlecht, das ist auch IMHO nicht grundlegen (zu) KNX-spezifisch.

Die sind schon gut und bleiben deswegen bestehen. Nur setze ich einen Level tiefer an und abstrahiere das zugrunde liegende System weg.

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?

War mir nicht klar, dass das jetzt schon geht. Dann wird der Übergang schmerzfrei gehen

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

Gerne - da darfst Du Dich jetzt austoben. IIRC hattest Du da ja schon ein paar Ideen zu.
Im Zweifel einfach mal das Konzept schreiben, Client-Seite würde ich implementieren, Server/Backend liegt eh bei Dir

[makki]

Authz

Wahrscheinlich habe ich mich mal wieder konfus ausgedrückt...

Ich werds verstehen wenns fertig ist, das reicht ja

Gerne - da darfst Du Dich jetzt austoben.

Naja, derzeit kann man mir hier direkt das Licht (und mehr wenn man weiss wie) ausknipsen, andererseits finde ich eine "echte" Demo aber immer schöner & vor allem glaubwürdiger.

Die meisten technischen & krypto-Details mal weggelassen (ich bin mal so frech und unterstelle das als richtig ):
a) die CometVisu bekommt beim l(ogin) einen "Token" (=SESSION?) und zeigt diesen bei jedem read/write einfach mit vor. Das ist nicht 100% was der paranoide in mir verlangt, aber ich will vermeiden das bei jedem Request komplexe Algorithmen abgefahren werden müssen (vielleicht unbegründet die Perf-Angst..)
b) dieser Token muss natürlich irgendwann ablaufen - entweder zeitbasiert, 1-4h oder so und die ablaufzeit wird mitgeliefert - vermutlich mehr Aufwand im Client. (+ möglicher server-restart etc.)
Oder r/w liefern irgendwann einfach "Nein" in Form eines bestimmten json-Feldes und der Client macht einen erneuten l(ogin)


Die "erlaubten" GA's würde ich beim login jetzt erstmal ganz stumpf&ohne Kunstwerk aus der gezogenen config_..xml holen (davor ist nämlich ggfs. später die Authentisierung - wer editieren darf, bestimmt ganz einfach wer was sehen lesen/schreiben kann).
info=darf lesen, dim=schreiben usw., vielleicht könnte man das noch in dem XSD unterbringen (da versth ich jetzt wieder weniger von..)
-> dafür müsste man aber evtl. das login um den _config-Namen erweitern (?)
Ich würde hier aber gerne irgendwo einen Strich ziehen zwischen selbergebaut & Webserver liefert die config einfach nicht, wenn der User nicht passt. Vielleicht ist hier auch ein cgi sinnvoller, das zusammen mit dem l(ogin) die visu_config ausliefert.

Andererseits sollte es nämlich IMHO auch dringend ohne Authentisierung ganz einfach funktionieren - so wie jetzt auch - weil im LAN und damit in den meisten Fällen braucht diese ganze Security-Funktions-Verhinderung kaum einer


Jedenfalls, das login macht man dann irgendwie nen hübschen hash von, speichert sich das temporär im Filesystem, da will ich aber noch ein paar Tests machen - schliesslich soll es beim read auf keinen Fall bremsen.


Den Rest macht der Webserver mit Basic/Zertifikats-Authentisierung, SSL & Co.
Das Gesamtkonzept ist da aber (in komfortabel!) ehrlichgesagt noch etwas unscharf, letztlich wird es aber denke ich darauf hinauslaufen, welche Rechte der REMOTE_USER im Webserver auf die jeweilige config.xml hat.

Makki

[Bodo]

Hoi an's Team

Apropos <Wunschkonzert>

Könnte man eigentlich auch Popups vorsehen, die entweder sticky sind oder einfach nach einstellbarer Zeit wieder verschwinden?

[Chris M.]

Apropos <Wunschkonzert>

Der Wunschzettel steht auf SourceForge - andere Wünsche können nicht berücksichtigt werden...

Könnte man eigentlich auch Popups vorsehen, die entweder sticky sind oder einfach nach einstellbarer Zeit wieder verschwinden?

Wie gut dass es da schon den Eintrag SourceForge.net: Open Automation: Detail: 3109762 - Info / Warning / Error Pop-Up gibt.

Gestern Abend habe ich übrigens die erste, noch experimentelle Version eingecheckt (Revision: 183), d.h. solche Wünsche über bestimmtes Verhalten der Popups kommen gerade zur rechten Zeit

[Bodo]

Voll coool ey. Danke

[makki]

Der Wunschzettel steht auf SourceForge - andere Wünsche können nicht berücksichtigt werden...

Schon verstanden
Ich denk mir halt, lieber so manches erstmal zärtlich zur Diskussion zu stellen, weil ein 100x Wunschkonzert mit unrealistischem Stoff bringts auch ned.. Welchen Aufwand/Nutzen was bringt, tut man sich schwer zu beurteilen..

Ich muss darauf nochmal zurückkommen: Thema Browser-Cache nach Update: heute wieder nach svn up: schwarzer schirm im FF (diesmal aber bewusst)
Irgendwann stunden später zufällig den Firebug angeworfen, plötzlich gehts (ohne Cache leeren oder STRG+F5!)
Wenn ich hier manuell teste und z.B. nur ein js ändere, wird das aber beim normalen laden ganz sauber neu geholt; jegliche Idee wie man das im Zweifelsfall "hinprügeln" kann?
Ich glaube weder der Webserver noch der Browser machen hier bei manueller Aufsicht was falsch, vermutlich aber dann doch ein schlichter Bug im Browser?!


Zwecks Session&config: die Endfassung ist jetzt visu/index.html?config=xyz um eine andere als die default visu_config.xml zu holen, richtig?
-> Dann wäre es für die Authz auf GA-Ebene glaube ich schön, wenn der Visuclient config=xyz noch beim l(ogin) mitgeben würde.
(ja, es bleibt hier eine theoretisch "Lücke" weil die Visu könnte beim login natürlich eine config anfordern, auf die es lt. remote_user garkeinen Zugriff hat; das kann man aber später immernoch im login.php/whatever abfangen und es ist wirklich eher theoretisch, weil er dafür erstmal grundsätzlich zugriff braucht..)

Makki

[Chris M.]

Ich denk mir halt, lieber so manches erstmal zärtlich zur Diskussion zu stellen, weil ein 100x Wunschkonzert mit unrealistischem Stoff bringts auch ned.. Welchen Aufwand/Nutzen was bringt, tut man sich schwer zu beurteilen..

Ich will hier auch keine Diskussion unterbinden - nur hab ich keine Lust nochmal 275 Postings durchzupflügen damit keine Wünsche et al. verloren gehen.
=> Am besten hier und dort schreiben...

Ich muss darauf nochmal zurückkommen: Thema Browser-Cache nach Update: heute wieder nach svn up: schwarzer schirm im FF (diesmal aber bewusst)
Irgendwann stunden später zufällig den Firebug angeworfen, plötzlich gehts (ohne Cache leeren oder STRG+F5!)
Wenn ich hier manuell teste und z.B. nur ein js ändere, wird das aber beim normalen laden ganz sauber neu geholt; jegliche Idee wie man das im Zweifelsfall "hinprügeln" kann?
Ich glaube weder der Webserver noch der Browser machen hier bei manueller Aufsicht was falsch, vermutlich aber dann doch ein schlichter Bug im Browser?!

Ich konnte bisher nur beobachten, dass wenn FireBug aktiv ist, der Reload mancher JS nicht immer durchgeführt wird.
Was mich aktuell wesentlich mehr ausgebremst, ist dass die CSS manchmal ums Verrecken nicht neu geladen wird

Unterstützt der lighty eigentlich .htaccess o.ä. um in einem Verzeichnis die HTTP-Cache-Dauer auf no-cache zu setzen?
(Bei'm Releasten Paket macht das Cachen aber durchaus Sinn, d.h. ich würde nur gern die SVN Version hier etwas "modifizieren")

Zwecks Session&config: die Endfassung ist jetzt visu/index.html?config=xyz um eine andere als die default visu_config.xml zu holen, richtig?

An so etwas hatte ich nicht gedacht - aber das wäre natürlich durchaus denkbar.

-> Dann wäre es für die Authz auf GA-Ebene glaube ich schön, wenn der Visuclient config=xyz noch beim l(ogin) mitgeben würde.
(ja, es bleibt hier eine theoretisch "Lücke" weil die Visu könnte beim login natürlich eine config anfordern, auf die es lt. remote_user garkeinen Zugriff hat; das kann man aber später immernoch im login.php/whatever abfangen und es ist wirklich eher theoretisch, weil er dafür erstmal grundsätzlich zugriff braucht..)

Mit dem l(ogin) hätte ich die Credentials mitgeschickt - mit denen kann der Server prüfen ob der User auf die entsprechenden GAs zugreifen darf. Diesen Mechanismus könnte man natürlich erweitern um die Übertragung der Config abzusichern.