CometVisu - (interner) Beta-Test

[swiss]

Könnte man dazu nicht das schon existierende Fehlermeldungsfester der Visu verwenden? Im Prinzip wäre der Mechanismus und die Maske ja schon vorhanden. Nur der Aufruf durch den BUS und das anlegen eigener Meldungen ist noch nicht implementiert.

[makki]

@greentux: wie wärs zumindest für ein (Alarm)Log einfach in ein RSS(XML) zu schreiben, dafür gäbs schon ein Widget (das man sicherlich noch verbessern kann)

Vorteil, man kanns auch am PC oder anderweitig leicht mit Standard-Tools verwenden..

Makki

[greentux]

Textanzeige

Letztens wurde hier im Thread schon diskutiert, Pages per GA umzuschalten. Anwendung war eine Alarmmeldung.
Angenommen ich habe einen Sensor, der mir die Überschreitung einer Temperatur mitteilen möchte, diese sinkt dann aber wieder, so kann ich bis dato natürlich dieses Event im linknx auswerten und ins Log schreiben.
Wie kann dieses Log dann ggf in der Visu angezeigt werden? Ich möchte sehen: "da war ein Alarm" und "wann war da welcher Alarm".

Gibts schon was oder gibts eine Idee aus der ich einen Feature Request im Tracker machen kann?

[makki]

..
D.h. wenn Config-Datei neuer als x Stunden, dann mache aus[INDENT]http://wiregate/visu/
...
Ein mod_rewrite (so technisch möglich) wäre da sehr angenehm und transparent, da die CometVisu Dateien selbst so bleiben können wie sie sind.

Das geht nur so AFAIK nicht; Das bereits vorhandene und wirksame Mittel - Cache-control und expires wird in diesem Fall ja schlicht ignoriert..
Wenn dann nur mit einem CGI/PHP/... und das wiederum ist - wie bereits angemerkt - noch viel suboptimaler; das macht im Regelbetrieb mehr Latenz als die ja nur wenige kB grosse config einfach mal zu schicken..
Das Caching (304 - Not modified) der visu_config.xml funktioniert Stand jetzt ohnehin nur mit der Hälfte der Browser (z.B. Arora holt sie jedesmal, warum auch immer..)

Wasserdicht ist immer gut. Und Wasserdich wäre, wenn "r" ein "i" vergibt, dass sich nicht wiederholt, bzw. dessen Wiederholungsfrequenz extrem niedrig ist.

Wieso? i darf ja überlaufen (ist ein uint16 im eibd), zuwas mit dem TS im backend überhaupt rumrechnen, der interessiert da ja garnicht; es geht doch nur darum, den Browser nachhaltig zu überreden das er es wirklich garnienicht aus dem Cache nehmen soll
Wenn wir mit 5 Bytes weniger den Planeten retten wollten, wäre mit der Übertragung der a= als int statt a/b/c mehr gewonnen
In einem weiteren Schritt könnte man das mit dem TS ja clientseitig auf bekannte Problemkinder beschränken..

Makki

[Chris M.]

Leider nein, die Illusion hatte ich anfangs ja auch: man kann RFC's/W3C lesen und verstehen aber wenn der Browser es dann einfach nicht tut (fragen!) dann kann man da rewriten was man will

Es ist irgendwie ganz klar ein quirk aber was soll man machen?? (ich hatte dieselbe Thematik - ganz unabhängig von CometVisu - letzte Woche mitm IE9) -> ist halt so, die Schuldfrage ist zwar wissenschaftlich interessant aber es geht am Ende des Tages darum, das Problem zu lösen..

Ich hatte schon befürchtet, dass der Vorschlag falsch rum verstanden wird.

Es geht nicht darum die URL der Config-Datei umzuschreiben (bzw. das wäre der unschöne Fallback per templateengine), sondern die URL der Visu an sich.

D.h. wenn Config-Datei neuer als x Stunden, dann mache aus

http://wiregate/visu/

ein

http://wiregate/visu/?forceReload=true

Die Unterscheidung ob's templateengine oder der Server macht mag kleinlich erscheinen hat aber einen wichtigen Hintergrund:
Templateengine läuft auf dem Client, und der hat keine Ahnung wie alt die Datei ist. Folglich braucht man eine Server seitige Lösung.
Ein mod_rewrite (so technisch möglich) wäre da sehr angenehm und transparent, da die CometVisu Dateien selbst so bleiben können wie sie sind.

Sollte das nicht gehen, muss man entweder immer ein TS anhängen (also ein forceReload=true als Default setzen), was nicht wirklich schön ist. Oder aber die templateengine live auf dem Server ändern (z.B. per PHP Einzeiler), was verhindert, dass die CometVisu auch auf ganz simplen Servern wie einer Fritz!Box laufen kann.

Richtig, also lieber gleich 210% wasserdichter-workaround, oder?

Wasserdicht ist immer gut. Und Wasserdich wäre, wenn "r" ein "i" vergibt, dass sich nicht wiederholt, bzw. dessen Wiederholungsfrequenz extrem niedrig ist.
Übrigens, wenn man "i" nicht dezimal, sondern hexadezimal überträgt, ist Platz gespart und vermutlich auch ein paar Rechenzyklen auf dem Backend...
=> Vorschlag: Ändere das "i" in mit Null aufgefülltes Hex und hänge einfach in Hex hinten in 32 Bit die Zeit in Sekunden seit 1970 dran.

[makki]

Hm, könnte man da harmlos so etwas wie einen mod_rewrite einbauen, der bei Alter der Config-Datei < x Stunden einfach ein ?forceReload=true an die URL hängt?

Leider nein, die Illusion hatte ich anfangs ja auch: man kann RFC's/W3C lesen und verstehen aber wenn der Browser es dann einfach nicht tut (fragen!) dann kann man da rewriten was man will

Es ist irgendwie ganz klar ein quirk aber was soll man machen?? (ich hatte dieselbe Thematik - ganz unabhängig von CometVisu - letzte Woche mitm IE9) -> ist halt so, die Schuldfrage ist zwar wissenschaftlich interessant aber es geht am Ende des Tages darum, das Problem zu lösen..

Und sollte es doch mal Ärger machen, dann kann man ganz leicht "r" so ändern, dass kein Zähler sondern die Timestamp des letzten übertragenen Paketes übertragen wird. Das Protokoll gibt's ja her

Richtig, also lieber gleich 210% wasserdichter-workaround, oder?
Auch wenn ich da selber viel dreck am stecken habe ist mein Ansporn zumindest bei aktuell vorhersehbaren Dingen zu verhindern, das es nicht 10J durchläuft

Makki

[Chris M.]

Aber selbst wenn es im Browser gefixed ist/wäre, erfahren diese Endgeräte da nur seltenst Updates -> Irgendwie muss man nun pragmatisch aus der Nummer raus..
Bei neuen Versionen anderer Files ist der Workaround den Cache zu löschen ja noch tragbar, bei der config eher nicht und es kostet ja nicht die Welt..

Hm, könnte man da harmlos so etwas wie einen mod_rewrite einbauen, der bei Alter der Config-Datei < x Stunden einfach ein ?forceReload=true an die URL hängt?

-> Ebenso würde ich den TS bei eibread-cgi (/r?..) einbauen da ich -ungetestet- davon ausgehe das eine lange laufende Visu nach einem Überlauf von i= (lastpos) denselben Mist macht.. Und das finde dann mal einer nach Wochen oder Monaten, warum *manchmal* uralte Werte in der Visu stehen..

Da halte ich die Wahrscheinlichkeit für nicht gegeben. Zum einen sollte "r" sowieso ein No-Cache übertragen (und damit die Browser das richtig handlen - im gegesatzt zur Config, bei der wir ja ein Cache eigentlich wollen). Zum anderen sollte die Zeitdauer, bis das "i" überläuft so groß sein, dass da sicher nichts mehr im Cache ist. Außerdem zählt das "i" ja mit der Laufzeit des Backends hoch und nicht mit der des Frontends, d.h. wird so gut wie nie neu gestartet.

Zum Vergleich: Mein WireGate hat gerade eine Uptime von 72 Tagen. Es greifen 2 Wand-PCs und mein Laptop auf die CometVisu zu, d.h. drei Clients. Und "i" steht bei mir gerade mal bei 63084. D.h. es sind noch nicht mal 0,003 % der Zahlenraums bis zum Überlauf vergangen (Annahme, da ich nicht in den Code geschaut habe, "r" verwendet ein signed int mit 32 Bit für "i")
Und sollte es doch mal Ärger machen, dann kann man ganz leicht "r" so ändern, dass kein Zähler sondern die Timestamp des letzten übertragenen Paketes übertragen wird. Das Protokoll gibt's ja her

[makki]

Bevor wir nun irgendwo etwas diesbezüglich ändern, würde ich gerne vorher das Problem nochmal genauer verstehen:
Wo, wann und wie ist der Browser-Cache so irritiert, dass wir ein Problem haben?

Es ist schlicht so, das manch (vor allem Webkit fiel mir da bisher auf, zwischendurch hatte ich es aber auch mal mit FF, IE9 hat da auch was) in manch Version auf manch Plattform (Android, i*, Chumby) sich schlicht nicht genötigt fühlt, den Webserver überhaupt zu Fragen, ob es da was neueres gibt Mehrfach selbst nachgesnifft..

Man könnte das sicher einen Bug im Browser nennen, weil Expires, Cache-Control Header sind alle richtig.
Aber selbst wenn es im Browser gefixed ist/wäre, erfahren diese Endgeräte da nur seltenst Updates -> Irgendwie muss man nun pragmatisch aus der Nummer raus..
Bei neuen Versionen anderer Files ist der Workaround den Cache zu löschen ja noch tragbar, bei der config eher nicht und es kostet ja nicht die Welt..

-> Ebenso würde ich den TS bei eibread-cgi (/r?..) einbauen da ich -ungetestet- davon ausgehe das eine lange laufende Visu nach einem Überlauf von i= (lastpos) denselben Mist macht.. Und das finde dann mal einer nach Wochen oder Monaten, warum *manchmal* uralte Werte in der Visu stehen..

Makki

[JNK]

was diesbezüglich ändern, würde ich gerne vorher das Problem nochmal genauer verstehen:
Wo, wann und wie ist der Browser-Cache so irritiert, dass wir ein Problem haben?

Bei unseren iPhones: jedes Mal, wenn die Config geändert wurde. Auch zwei Tage später tut sich da garnix, es bleibt alles beim alten. Normaler Reload tuts nicht, den Cache vom Safari löschen hilft immer und sofort.

Gruss,

der Jan

[Chris M.]

...könnte man eigentlich "Mappings & Styling" dahin gehend erweitern,
dass man ein SVG Bild, (Makkis Link zu "The Noun Project) einbinden kann und es dann noch abhängig farblich mit einem Hintergrund versieht?

Evtl. hab ich den Kontext verloren: Machen kann man sehr viel, insbesondere mit SVGs und Bildern
Aber was genau willst Du wo haben?

Ich bin da bestimmt nicht das Mass aller Dinge, aber TS sind m.E. ne gute Lösung und relativ sicher gegen diese Problematik. Und bei allem Schielen auf knappe Ressourcen: auf die paar Byte kommt es nun wirklich nicht an.

Einen TS anhängen ist ziemlich harmlos. Bei der Config-Datei machen wir das aber nicht, weil wir die eben nicht jedes mal wieder übertragen wollen - und ein ?forceReload=true genau das macht.

Bevor wir nun irgendwo etwas diesbezüglich ändern, würde ich gerne vorher das Problem nochmal genauer verstehen:
Wo, wann und wie ist der Browser-Cache so irritiert, dass wir ein Problem haben?

[Chris M.]

@Chris M.
Kannst Du schreiben, welcher Wert genau ausgelesen wird?
Vielleicht habe ich beim Alaska Design diesen Wert nicht richtig eingefügt...

Ab Zeile 180:

diagramColors = {
    data: $("<span class='link'><a href='#' /></a>").find("a").css("color")
};

D.h. es wird die Farbe eines Links ausgelesen. Aber: Es scheint nicht so richtig zu funktionieren

=> Hier müssen wir noch Hand anlegen.

Welche CSS-Eigenschaft sollen wir denn nehmen?

Sie sollte halt vom Flavour abhängen. Somit bleibt Link (bzw. Page, was einem .link a" entspricht) oder Linie ("hr").

[Chris M.]

ich bin da nicht untätig gewesen, und hab es mir auch mehrmals angeschaut. Derzeit verzweifel ich daran:
das Drag&Drop funktioniert nicht im Zusammenhang mit Gruppen. Man kann Elemente nur in Gruppen reinschieben - aber nicht raus. Und man kann innerhalb von Gruppen nicht sortieren. Ganze Gruppen kann man auch nicht in der Seite verschieben. Oder so ähnlich. Insgesamt ein PITA.
Ich denke das hat damit zu tun, dass die Elemente verschachtelt sind.

Was sollte möglich sein:

• Gruppe anlegen und Löschen
• Gruppe verschieben
• Elemente in Gruppe ziehen bzw. aus Gruppe herausziehen (oder in Gruppe befindlich löschen)
• Elemente in Gruppe umherschieben zum sortieren

Wenn ich mir stand Jetzt den Editor ansehen (ok, mein letzte svn up ist ein paar Tage her, an der Stelle aber wohl unkritisch):

• Gruppe anlegen und Löschen scheint zu funktionieren und ist intuitiv (nämlich genau so wie andere Widgets auch)
• Gruppe (als ganzes) Verschieben funktioniert wunderbar. Die verhält sich wie ein dickes Widget und ist daher Intuitiv.
• Ein Element in die (gefüllte!, Vgl. Demo-config) Gruppe zu ziehen funktioniert eigentlich auch und ist intuitiv, aber leider springt die Gruppe selbst meistens (weil der Editor vermutlich meint, dass das Widget außerhal verschoben werden soll und nicht darauf vorbereitet ist, das ich etwas in die Gruppe schieben kann)
  Aus der Gruppe herausziehen funktioniert nicht (und beim Löschen verwschwindet die ganze Gruppe) - hier schätze ich, dass das mit wenig Aufwand(?) leicht behebbar ist.
• Umsortieren in der Gruppe mag auch schon jetzt

D.h. ich gehe mal naiv davon aus, dass die Gruppen eigentlich kein großes Problem sein sollten. Der Speicher-Befehl muss die lernen und beim Editieren selbst brauchts ein paar kleine Anpassungen.

Aber wenn's so einfach wäre, gäb's den Beitrag vermutlich nicht, oder?
Wo liegt denn genau das Problem?

PS: Wenn Du Deine Änderungen eincheckst könnte ich mal drüber schaun. IMHO wäre es aktuell absolut i.O. wenn ein neuer Editor-Code diese Funktion erst mal kaputt macht. Ein stabiles Release ist nämlich draußen und für's nächste ist eigentlich nur noch der Editor offen.

[JNK]

P.S.: Was ist denn mit dem leidigen Cache-Thema, das nunmal bei jedem zweiten Browser (ohne IE) wieder aufkommt? Timestamp anhängen bekomme ich schon selber hin, aber ohne Feedback/Ack mag ichs auch nicht einfach commiten(?)..

Ich bin da bestimmt nicht das Mass aller Dinge, aber TS sind m.E. ne gute Lösung und relativ sicher gegen diese Problematik. Und bei allem Schielen auf knappe Ressourcen: auf die paar Byte kommt es nun wirklich nicht an.

Gruss,

der Jan

[makki]

..
das Drag&Drop funktioniert nicht im Zusammenhang mit Gruppen. Man kann Elemente nur in Gruppen reinschieben - aber nicht raus. Und man kann innerhalb von Gruppen nicht sortieren. Ganze Gruppen kann man auch nicht in der Seite verschieben.

Wenn das der Showstopper ist, wäre mein Vorschlag das es nun eben erstmal so ist, es wird ein Caveat gefiled, das man Gruppen im Visu-Editor derzeit nicht nachbearbeiten kann.

Makki

P.S.: Was ist denn mit dem leidigen Cache-Thema, das nunmal bei jedem zweiten Browser (ohne IE) wieder aufkommt? Timestamp anhängen bekomme ich schon selber hin, aber ohne Feedback/Ack mag ichs auch nicht einfach commiten(?)..

[Chris M.]

Vielleicht zu späte, aber ggf wäre ein Editor, der nicht stringent WYSIWYG umsetzen muss besser.

Das wäre mein Ansatz gewesen: Einen simplen Tree-View basierten "XML-Editor" bauen, der die CometVisu-Config erzeugt bzw. bearbeitbar lässt.
Und nach meinem Ansatz hätte ich dass die Jungs von Elaborated Netowrks machen lassen, da ich ja keinen Editor brauche.

Etliche Seiten früher im Thread kann man diese Ansicht von mir nochmal nachlesen.

Dann kam Julian und hat einen super Editor geschrieben, der sich deutlich besser einfügt, als ich mir das hätte vorstellen können (bzw. wo ich von einem immensen Implementierungsaufwand ausgegangen wäre...)

Editor und Gruppen:
[...]
Hat irgendwer eine Idee, wie man die Gruppen behandeln könnte?

Meinst Du programmiertechnisch oder diesbezüglich abstrakt nur das UI?

Für letzteres kann ich nachher mal ein paar Überlegungen anstellen.

PS: War die letzten paar Tage etwas leiser da ein paar andere Sachen unter den Nägeln gebrannt haben. Jetzt wird's hoffentlich besser.