CometVisu - (interner) Beta-Test

[Chris M.]

Die Gerüchte sind ja bereits hoch gekocht - und jetzt ist es endlich so weit: der interne Beta-Test der CometVisu startet!

Doch der Reihe nach:

Was ist die ?

Die CometVisu ist eine echtzeitfähige, Browser basierter Visualisierung (nicht nur) für den KNX. Dabei ist besonders zu beachten, dass auf dem Client-PC keine extra Applikation installiert werden muss - ein moderner Web-Browser reicht vollkommen aus. Dadurch sollte es auch auf Smartphones laufen.

Wie bekomme ich die ?

Für Besitzer des WireGates ist das ganz einfach - einfach in der normalen Administrations-Oberfläche (webmin) auf "Updates" gehen und dort

cometvisu

oben links bei "Paket installieren" eingeben.

Wie konfiguriere ich die ?

Hier sind nun etwas Kenntnisse der Kommandozeile oder alternativer Tools notwendig - der Grund warum ich dieses Beta hier im Beta-Forum starte. Endanwendern würde ich das nicht zumuten wollen.
Auf dem Dateisystem unter

/var/www/visu

liegt die Datei

visu_config.xml

Hier wird die Visu konfiguriert. Zur notwendige Syntax s.u.

Wie zeige ich die an?


Ganz einfach Einfach mit dem Web-Browser auf die Seite

http://wiregateXXX/visu/

gehen.

Wo stehen mehr Information zur ?

Hier in der Ankündigung, können natürlich nur grundlegende Informationen stehen. Mehr Informationen stehen auf SourceForge auf der Beta-Seite:

https://sourceforge.net/apps/mediawi...CometVisu/Beta

Auf SourceForge ist außerdem im Subversion-Repository die jeweils aktuellste Version zu finden - aber das muss ich ja Beta-Testern nicht sagen
Wie geht es weiter? Was wird von Beta-Testern erwartet?

Jetzt wo die Beta draußen ist, startet die aktive Phase der verteilten Entwicklung. D.h. wir brauchen weitere Entwickler, die die Basis weiter treiben, oder die Plugins schreiben. Wir brauchen Designer, die die Oberfläche weiter verschönern. Wir brauchen Tester, die Fehler melden. Wir brauchen helfende Hände bei der Dokumentation. Wir brauchen gute Screenshots. Wir brauchen ... - im Grunde jeden

Und damit erkläre ich die Diskussion für eröffnet!

[lbau]

Nice.

Ich schaue mir morgen mal die config genauer an.

Liest der direkt von den GAs ein?

Lbau

[NilsS]

Super Chris

dürfen wir hier denn dann das Wunschprogramm nochmal einwerfen

ich mach mal einfach. kennst die Wünsche ja eh schon aber dann muss sie dir nicht noch einer per PN schicken


Slider:
Min/Max werte um z.B. Warmwassertemp von 25-55°C regeln zu können.

Style und Mappings evaluiren.
also nicht statisch value="1" sondern value="0-19"

[lbau]

also ich bekomme beim Start immer

Error! "error"

und obwohl ich die visu_config.xml angepasst habe, ist auf der Startseite immer noch der alte Inhalt zu sehen Terasse Licht etc.

??

Lbau

PS. müssen die Umlaute so komisch geschrieben werden im xml file?
<page name="Ã~\bersicht">

[NilsS]

also ich bekomme beim Start immer und obwohl ich die visu_config.xml angepasst habe, ist auf der Startseite immer noch der alte Inhalt zu sehen Terasse Licht etc.

??

Lbau

PS. müssen die Umlaute so komisch geschrieben werden im xml file?
<page name="Ã~\bersicht">

das mit dem config_xml ist so ne Sache, generell nimmt das xmlhttp lieber den Cache, da kann man eigentlich IMHO nur mit nem PHP Script oder einer anderen Möglichkeit Serverseitig nachhelfen, das das automatisch geht.
Manuelle Lösung: http://wiregatexxx/visu/visu_config.xml im Browser direkt aufrufen und gegebenenfalls <strg>+<f5> drücken.
Am besten behällt man von der visu_config.xml eine Sicherungskopie, da man das XML sehr schnell zerschießen kann.

Das Encoding der Datei ist UTF8 daher ist es wichtig, das man die Datei weder mit einem Lokalen Editor öffnet (vi/nano/mcedit), als auch darauf achtet das ein Windows editor dies beachtet.

Unter windows empfehle ich Notepad2 http://www.flos-freeware.ch/zip/notepad2.zip

[lbau]

Am besten behällt man von der visu_config.xml eine Sicherungskopie, da man das XML sehr schnell zerschießen kann.

Das Encoding der Datei ist UTF8 daher ist es wichtig, das man die Datei weder mit einem Lokalen Editor öffnet (vi/nano/mcedit), als auch darauf achtet das ein Windows editor dies beachtet.

OK, das erklärt einiges.

Also nix mit vi :-)

Lbau

[netzkind]

das mit dem config_xml ist so ne Sache, generell nimmt das xmlhttp lieber den Cache, da kann man eigentlich IMHO nur mit nem PHP Script oder einer anderen Möglichkeit Serverseitig nachhelfen, das das automatisch geht.

Wenn das ein wiederkehrendes Problem ist kann man auch jQuery so einstellen dass es ein Umgehen des Caches erzwingt indem es an die Anfrage-URL immer einen Parameter mit Timestamp hängt:

Index: templateengine.js
===================================================================
--- templateengine.js	(Revision 25)
+++ templateengine.js	(Arbeitskopie)
@@ -61,6 +61,7 @@
 
 $(document).ready(function() {
   // get the data once the page was loaded
+  $.ajaxSetup({cache: false});
   window.setTimeout("$.get( 'visu_config.xml', setup_page );", 200);
 
   // disable text selection - it's annoying on a touch screen!

So würde bei jedem Aufruf der Visu der Cache umgangen. Müsste man abwägen wie wichtig der Browser-Cache fürs XML ist wenn das System dauerhaft in Betrieb ist und sich am XML nicht mehr viel ändert.
Bei Interesse kann ich das ins SVN einchecken.

Grüße,
Julian

[NilsS]

Ja das wäre auch ne möglichkeit, per php o.ä. könnte man aber den FileModified auslesen, sollte eigentlich auch so gehen, hab ich aber auch bei anderen Dingen schon häufig beobachtet, das das doch nicht geht. Evtl. könnte man den timestamp ja nur beim click auf reload anhängen.

[Chris M.]

Also nix mit vi :-)

Doch, doch. Vi geht - den nutze ich ja selbst... (auch wenn mir per sshfs dieser Punkt nicht mehr wichtig ist)
Der Trick ist, dass Du das Encoding für deine Konsole passend setzen musst:

export LANG=de_DE.utf8
vi visu_config.xml

(In Zukunft wird das hoffentlich Standard im WireGate)

Wenn das ein wiederkehrendes Problem ist kann man auch jQuery so einstellen dass es ein Umgehen des Caches erzwingt

Gute Idee!

Müsste man abwägen wie wichtig der Browser-Cache fürs XML ist wenn das System dauerhaft in Betrieb ist und sich am XML nicht mehr viel ändert.
Bei Interesse kann ich das ins SVN einchecken.

Ja, bitte einchecken.

Der Reload-Button ist eh noch ein Relikt meiner Entwicklungszeit - der da gar nicht so unpraktisch war. In eine finale Visu gehört der natürlich nicht. Daher sehe ich es auch absolut i.O. an, wenn die XML jedes mal neu geladen wird.

[makki]

Die UTF8-Nummer.. jaja
Am besten nicht lokal per ssh editieren (macht eh nicht so richtig Spass mit nano etc. ein XML..)
Keinesfalls aber die LANG= dauerhaft ändern, sonst rappelts richtig (ergo, visu_config ist dann gut, die restlichen Sachen geschr**)

Ein harter no-cache beim starten der Visu ist sicher kein Thema, das schafft der lighty hier auch 100x in der Sekunde..

Makki

[NilsS]

Der pfad/Name zur visu_conf.xml sollte vielleicht vom /cgi-bin/l zurück gegeben werden

[netzkind]

Ich hab grade eben mal einen browserbasierten Inline-Config-Editor ins SVN eingecheckt.
Bislang gibt es den Code noch nicht als Debian-Paket zum installieren sondern nur im Subversion-Repository.

Getestet bislang nur auf Windows XP (FF3.6 und IE8 - wobei letzterer sowieso grade Unsinn angezeigt hat, unerklärlicherweise).

Vorraussetzung für die Funktionsfähigkeit des Editors ist, dass visu_config.xml für den Webserver-Prozess schreibbar ist.

Was der Editor bislang kann:
- widgets und pages innerhalb einer Seite umsortieren
- widgets hinzufügen, löschen, bearbeiten
- pages hinzufügen, löschen, umbenennen
- die daraus resultierende Config direkt auf den Server speichern

Was ich noch auf der Ideenliste habe was eventuell implementiert werden könnte;
- Validierung für die Eingabefelder, speziell für Pflichtfelder; aktuell fliegt einem noch das Javascript um die Ohren wenn man DPT oder address weglässt oder falsch schreibt
- die Liste der mappings, styles editieren
- Name der Hauptseite ändern
- kopieren/verschieben zwischen mehreren Seiten - über eine Art Zwischenablage
- die Editor-Elemente anhübschen


Der Editor hat NULL Sicherheitsbewusstsein - die wichtigsten Dateien liegen aber in einem eigenen Ordner, so dass man mit .htaccess zumindest ein Grundgefühl von Sicherheit herstellen könnte. Das ist erst mal jedem selbst überlassen.

Der Editor erscheint im Default-Design der Visu - visudesign_custom.js wird nicht berücksichtigt. Technischer Hintergrund ist dass damit Position und Inhalte der "widgets" für den Editor nachvollziehbar sind. Abweichend vom Default-Design werden "line"-Elemente in einer Box dargestellt damit die Editorelemente hineinpassen.

Da ich nur mein eigenes Szenario getestet habe empfehle ich DRINGEND vor dem Testen ein Backup der eigenen visu_config.xml zu machen.

Grüße,
Julian

[NilsS]

Vorraussetzung für die Funktionsfähigkeit des Editors ist, dass visu_config.xml für den Webserver-Prozess schreibbar ist.

wenn es sich nachher dabei nicht um eine Datei, sondern eine Datenbank o.ä. handelt sicher noch einfacher

[netzkind]

wenn es sich nachher dabei nicht um eine Datei, sondern eine Datenbank o.ä. handelt sicher noch einfacher

Richtig, und relativ leicht einflanschbar. Die Übersetzung vom JSON in das XML macht ein PHP-Skript - das könnte nun statt DOMDocument-Objekte zu erzeugen die Daten auch anders umsetzen, ohne dass man an die Datenpräsentation oder Verarbeitung im Javascript ranmüsste.
Man kann das Backend also beispielsweise auch serverseitig konfigurierbar machen.

Grüße,
Julian

[makki]

coole Sache! Denke auch vom Ansatz die richtige Richtung.
Schön finde ich, das man das Ergebniss gleich sieht und bedienen kann..

Info: funzte auf Anhieb mit Ubuntu FF3.6, im chromium kann man die Felder nicht ändern.

zwecks GA's: kann ich auch beim import gleich irgendwie als json/xml rausschreiben? einfach bescheidsagen..

Die config hat da natürlich mittelfristig garnichts verloren, DB finde ich etwas überzogen, xml tuts doch IMHO..
Vorschlag: /etc/cometvisu/*.xml ? ins web wird das dann per symlink bzw. vom PHP direkt angesprochen.
Ich sollte/wollte das eigentlich schon im initialen package machen

Security: kann man IMHO wirklich später nachrüsten, das hält glaube ich derzeit nur auf und es geht ja jederzeit.. cgi-bin/l ist ja nur ein Platzhalter..

P.S.: Natürlich kann man das theoretisch auch gleich in pywiregate einwurschteln, mit der Gefahr viele voneinander abhängig Baustellen zu haben, denke es ist erstmal auch wichtig was eigenständiges "zum anfassen" zu haben..

Makki