CometVisu - (interner) Beta-Test

[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

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

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

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]

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

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

@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

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

[greentux]

Das sind im Grunde zwei Anwendungen.
Zum einen will ich Text anzeigen, sowas wie Historie der Fensterkontakte, Spannungsüberwachung etc. Das kann so ähnlich aussehen, wie bei den Diagrammen. Drin scrollen sollte man aber schon können.

Das zweite wäre via GA umzuschalten bei Alarmen.

Drittens wäre natürlich auch ein Alarm-Popup nett. Ob das dann auf einen DPT reagiert, der ein paar Zeichen Text enthält, wäre ggf. noch zu diskutieren.

[makki]

Das sind im Grunde zwei Anwendungen.

Jep, sehe ich genauso. Das eine ist growl/prowl-like ähnlich der Notifications im Editor (Info,Warning,Error; persistent oder temporär) und das zweite ein Meldungsarchiv im HS-sprech.

Beides wäre quasi 2/3 umgesetzt, mal wieder eine dumme Frage hierzu: wie initialisiere ich ein Widget das nicht selbst in den pages eingefügt wird "the right way(tm)"?
Also eben z.B. Notifications oder etwas in der Status-Bar..

Makki

P.S.: die guten RSS-Plugins basieren leider alle auf Google API-Key, also externem Zugriff, was denke ich nicht so akzeptabel ist..

[greentux]

P.S.: die guten RSS-Plugins basieren leider alle auf Google API-Key, also externem Zugriff, was denke ich nicht so akzeptabel ist..

wäre nicht sowas auch auf dem WG selber denbar:
JavaScript RSS Box Viewer 2.1
Also der rss2javascript converter?

[greentux]

unmotivierte Probleme

Meine Visu verliert seit heute den Status meiner PMs (gesperrt/nicht gesperrt).
Im eib.log ist dazu keinerlei Verkehr vorhanden.
Mir fällt nix ein, was ich ggf. geändert hätte.

Die relevante Config wäre:

<switch mapping="InvAutoOff" styling="InvRedGreen">
      <address transform="DPT:1.001" readonly="false">3/1/0</address>
      <address transform="DPT:1.001" readonly="true">3/7/10</address>
</switch>

mit

<mapping name="InvAutoOff">
   <entry value="1">Off</entry>
   <entry value="0">Auto</entry>
</mapping>

[greentux]

Nochmal für mich: sollten von der Visu die GAs abgefragt werden, sobald man ein Reload macht?

[greentux]

ich muss hinzufügen, das sich die Switch Elemente willkürlich nach einiger Zeit verändern. Derzeit gibt es viele "On", obwohl die Leuchten alle "Off" sind. Das WG eib.log sagt dazu nix.
Nun muss ich dochmal den Busmonitor anmachen...

[Chris M.]

Nochmal für mich: sollten von der Visu die GAs abgefragt werden, sobald man ein Reload macht?

Das hängt vom eibd ab.

Die Visu fragt das Backend (was direkt mit dem eibd spricht) eine ganze Latte von Adressen an.
Das Backend antwortet auf alle - so weit wie bekannt aus dem Cache, bei den anderen wohl per aktiver Nachfrage. (Dies bitte von Makki bestätigen lassen, beim Backend habe ich nur rudimentäre Kenntnisse)