CometVisu - (interner) Beta-Test

[tjakobi]

Hallo Chris,
bin neu in Forum und sehr begeistert was bei Euch so los ist....

Habe am Wochenende die Cometvisu aufegsetzt und einmal Übersichten zu Fensterkontakten und Temperaturen erstellt. Soweit erstmal sehr schick!


Frage bzgl. dem "info" widget.

Meine Fensterkontakte als (dpt1.001) sind im geschlossenen Zustand "offen" und daher grün. In Wirklichkeit sind Sie aber "geschlossen" und sollten grün sein. (grün = geschlossen & rot = offen)

Wäre nicht eine checkbox zur Invertierung der Darstellung sinnvoll?
=> Evtl. könnte das auch im "mapping" hinzugefügt werden.
(OpenClose und CloseOpen)
=> sowie im styling:
(RedGreen und GreenRed)

Gruß Tim

[Chris M.]

Meine Fensterkontakte als (dpt1.001) sind im geschlossenen Zustand "offen" und daher grün. In Wirklichkeit sind Sie aber "geschlossen" und sollten grün sein. (grün = geschlossen & rot = offen)

Wenn ich im Standard mal nachsehe, dann gilt offiziell:

• DPT1.009 (DPT_OpenClose)
• 0 = Open
• 1 = Close

Also ist die Demo-Config-Datei, bzw. das OpenClose Mapping eigentlich falsch, das 0=zu und 1=offen setzt.

Andererseits könnte man auch DPT1.002 (DPT_Bool) verwenden und seine GA mit Dachfenster_Offen benennen, und da gilt:

• DPI1.002
• 0 = False
• 1 = True

Oder man ließt im Standard weiter, und findet den noch besseren Datentyp:

• DPT1.019 (DPT_Window_Door)
• 0 = closed
• 1 = open

So gesehen ist die Demo-Config-Datei wieder richtig...

Da man zwar den DPT ziemlich frei wählen kann, kommt allerdings verschärfend hinzu, dass man ja diesen Wert durchaus als Sperrobjekt (für Rollladen, um sich nicht auszusperren) oder zur Sicherheit (Einfrierschutz bei Heizung) verwenden will und dort die Aktoren teilweise eine festgelegte Bedeutung von 0 und 1 verlangen.

=> Egal was jetzt offiziell richtig ist, es muss funktionieren. Ändere daher einfach das Mapping in der Config-Datei, so wie Du es brauchst.
So wie es ein RedGreen und ein GreenRed gibt, kannst Du natürlich zum OpenClose noch ein CloseOpen hinzufügen

Wäre nicht eine checkbox zur Invertierung der Darstellung sinnvoll?

Ne, das macht keinen Sinn - genau dafür ist das Mapping da.

=> Evtl. könnte das auch im "mapping" hinzugefügt werden.
(OpenClose und CloseOpen)

Das ist die richtige Lösung, s.o. - aber das ist etwas für Deine Config-Datei.
Leider kann der eingebaute Editor diese Einträge nicht ändern, aber mit einem beliebigen Text-Editor kannst Du natürlich selber die Config-Datei anpassen. (Wir sind hier im internen Beta-Test, da können wir das von den Anwendern locker erwarten )

[makki]

Ich hab in der /visu-svn/ Demo mal den Wasseralarm als CloseOpen eingetragen, letztlich reicht es das Mapping in der config einzutragen wie Chris schon schrub.. Wäre dann eher ein Feature für den Editor, einfach die Mappings und Styles zu bearbeiten/erweitern..

Andere Frage, DPT14: beim coding-style bin ich noch sehr wackelig:
ist ja ne rechte sauerei mit dem DPT14, ich hab eine kleine Klasse gefunden die man aber mittelfristig vermutlich an mehr Stellen als nur dem transform_knx brauchen kann.
Nur den Teil in transform_knx reinwuschteln oder separat das ganze Ding?
Würde es Sinn machen, für universellen Kleinkram eine allgemeine helper.js (die dann auch gleich compatibility.js enthielte) zu machen?
Es sollen ja möglichst wenig Files geladen werden..
Fertig isses je nachdem comitte ich das dann..

Makki

[netzkind]

Um mal kurz wieder ein Lebenszeichen zu geben:
ich bin leider nicht wie erwartet über Weihnachten zur Anpassung des Editors an den aktuellen SVN-Stand gekommen. Ich hab den Editor aber noch nicht aufgegeben, und hoffe da in den nächsten Tagen wieder etwas mehr zeitlichen Freiraum zu haben um dann auch das Einfügen multipler GAs pro Widget etc. umzusetzen.

Da der aktuelle Source aber im SVN liegt wäre ich niemandem böse der sich auch daran versuchen will. Dann bitte kurze Info, nicht dass da mehrgleisig Energie verwendet wird

Grüße,
Julian

[netzkind]

Hi,

Wenn ich im Standard mal nachsehe, dann gilt offiziell:

• DPT1.009 (DPT_OpenClose)
• 0 = Open
• 1 = Close

Also ist die Demo-Config-Datei, bzw. das OpenClose Mapping eigentlich falsch, das 0=zu und 1=offen setzt.

Andererseits könnte man auch DPT1.002 (DPT_Bool) verwenden und seine GA mit Dachfenster_Offen benennen, und da gilt:

• DPI1.002
• 0 = False
• 1 = True

Oder man ließt im Standard weiter, und findet den noch besseren Datentyp:

• DPT1.019 (DPT_Window_Door)
• 0 = closed
• 1 = open

So gesehen ist die Demo-Config-Datei wieder richtig...

mich verwirrt es auch regelmässig in der Visu, ist aber eigentlich ganz klar:
DPT1.009 sind Verben, also "öffnen" und "schließen"
DPT1.019 sind Zustände, also "geschlossen" und "offen"
Beide bilden das gleiche ab:
0 = Zustand: geschlossen, mögliche Aktion: öffnen
1 = Zustand: offen, mögliche Aktion: schließen

Die Frage ist was von beidem man in der Visu haben will: Zustand oder auszuführende Aktion? Das dürfte für INFO und SWITCH/TOGGLE unterschiedlich sein.

Grüße,
Julian

[Micha]

Wenn man sich mal Applikationen anschaut, ist es eigentlich anders :

Die "0" gesendet führt immer in einen gefahrlosen Grund-Zustand

- Tür, Fenster zu
- Rolladen, Jalousie hoch
- Licht, Antrieb u.a. AUS

Die "1" gesendet führt die Aktion aus, die aus dem Grundzustand in einen gewünschten Zustand wechselt

- Tür, Fenster auf
- Rolladen, Jalousie herunter
- Licht, Antrieb u.a. EIN

So machen beide DPT Sinn, definieren also den Beginn einer Aktion und nach Beendigung der Aktion den Status des Objektes

Gruß Micha

[netzkind]

Wenn man sich mal Applikationen anschaut, ist es eigentlich anders :

Die "0" gesendet führt immer in einen gefahrlosen Grund-Zustand

- Tür, Fenster zu
- Rolladen, Jalousie hoch
- Licht, Antrieb u.a. AUS

Die "1" gesendet führt die Aktion aus, die aus dem Grundzustand in einen gewünschten Zustand wechselt

- Tür, Fenster auf
- Rolladen, Jalousie herunter
- Licht, Antrieb u.a. EIN

Das entspricht doch dem was ich geschrieben habe, oder?
0 = öffnen = Rolladen hoch-fahren
1 = schließen = Rolladen herunter-fahren

Oder ich steh auf dem Schlauch und versteh grade nicht worauf sich das "eigentlich anders" bezieht ...

Grüße,
Julian

[Micha]

Das anders bezog sich darauf :

• DPT1.009 (DPT_OpenClose)
• 0 = Open
• 1 = Close

• DPT1.019 (DPT_Window_Door)
• 0 = closed
• 1 = open

und die daraus folgende mögliche Verwirrung

Für mich ist " 0 = gefahrloser Zustand " die einheitliche Regel beim Beschalten von Aktoren

[Chris M.]

Für mich ist " 0 = gefahrloser Zustand " die einheitliche Regel beim Beschalten von Aktoren

Das Problem bei dieser Annahme ist, dass nicht immer klar ist, was der "gefahrlose Zustand" ist.

Der gefahrlose Zusand eines Wasseranschlusses oder gar Gas-Ventils dürfte geschlossen sein (also müsste 0 = geschlossen sein).
Der gefahrlose Zustand einer Fluchttüre dürfte offen sein (also müsste 1 = offen sein).

Genau so leicht lassen sich Gegenbeispiele finden. (Müsste nicht die Gas-Versorgung offen = 0 sein, damit im Winter keiner erfriert?!?)

Letztendlich kann man sich das hereindichten (bzw Standard-Nachvollziehen) sparen. Da ist definiert was was ist - und nun muss man damit passend umgehen.
Dem Visu-Anwender ist es nämlich egal ob da eine 0 oder eine 1 dahinter steht - das was er liest und sieht muss passen.
(Und dem KNX Parametrierer, äh, Programmierer, ist's auch egal - die Polarität des Sperrobjektes muss passen. Und wenn die sich überall außer in einem Aktor drehen lässt, dann macht man's halt so um den einen, mit der minderbemittelten Applikation, auch glücklich zu machen)

[luigi4711]

Hab's nach längerer Zeit auch endlich mal wieder geschafft auf den aktuellen SVN Stand zu aktualisieren. Aufgefallen ist mir, dass mein NoScript Blocker plötzlich Sourceforge.net und doubleclick.net beim Demo Widget anzeigt.

Ich vermute mal, das hängt mit dem Counter zusammen, der in der Demo drin ist!?
Soweit ich mich erinnere war der Counter dazu da, etwas Übersicht zu behalten, wie viele Betas da draussen laufen. Finde ich auch ok.

Nur könnte die doubleclick Geschichte etwas Bedenken hervorrufen, was denn dort im Hintergrund getrieben wird...



luigi

[Edit: Sehe gerade, dass kommt vom Einbinden der Sourceforge Seite ins iFrame Widget...
Hab ich zu Unrecht den guten Zähler verdächtigt.... ]

[Chris M.]

Soweit ich mich erinnere war der Counter dazu da, etwas Übersicht zu behalten, wie viele Betas da draussen laufen. Finde ich auch ok.

Der Counter ist eigentlich nur dazu da zu zeigen, dass ein Bild alle x Sekunden neu geladen wird.
Das mit der Anzahl der aktuell aktiven Visu ist eher ein interessanter Nebeneffekt - verlässlich ist der überhaupt nicht, denn sobald man seine eigene Visu designt, fliegt der typischer Weise ja raus... (Wenn ich das wirklich wissen wollte, würde ich einen Web-Bug einbauen...)

Nur könnte die doubleclick Geschichte etwas Bedenken hervorrufen, was denn dort im Hintergrund getrieben wird...
[...]
[Edit: Sehe gerade, dass kommt vom Einbinden der Sourceforge Seite ins iFrame Widget...

Richtig gesehen, die SourceForge Seite im iframe ist schuld.
Das ist auch nur da, um das iframe-Widget zu demonstrieren (und die SF Seitenaufrufe / Projektaktivität zu "tunen" - wobei das, wenn man's genau nimmt, eigentlich vollkommen egal ist). Doubleclick ist da zwar doof - aber da das bei der eigenen Visu ja auch sicher rausfliegt, denke ich, dass wir das den Usern zumuten können.

[makki]

Andere Frage, DPT14: beim coding-style bin ich noch sehr wackelig:
ist ja ne rechte sauerei mit dem DPT14, ich hab eine kleine Klasse gefunden die man aber mittelfristig vermutlich an mehr Stellen als nur dem transform_knx brauchen kann.
Nur den Teil in transform_knx reinwuschteln oder separat das ganze Ding?
Würde es Sinn machen, für universellen Kleinkram eine allgemeine helper.js (die dann auch gleich compatibility.js enthielte) zu machen?

War die Frage zu dumm oder ging das unter ?

Makki

[Chris M.]

War die Frage zu dumm oder ging das unter ?

Vermutlich untergegangen...

Bei der float Codierung auf etwas bewährtes und debugtes zurückzugreifen ist sicher Sinnvoll (wir brauchen hier kein zweites PHP - wobei die ja wohl genau deshalb auf die Nase gefallen sind...). Bei dieser Klasse hab ich jedoch das mit den Copyright-Bedingungen nicht ganz verstanden...

Bei externen dependencies (wie bei dieser Klasse) würde ich die auch getrennt ablegen. Das Optimieren auf niedrige Datei-Anzahl kann man dann später per cat vor dem Komprimieren machen, wenn die ...min.js erzeugt werden.

Das mit compatibility.js -> helper.js können wir gerne machen.

[makki]

Bei der float Codierung auf etwas bewährtes und debugtes zurückzugreifen ist sicher Sinnvoll

Das sah ich genauso, sowas schreib ich nicht selber weil da sind 10 Fehler vorprogrammiert.
Ebenso wie ich es nicht mehr ungesehen kopiere (siehe DPT9 - mh) ohne ein Testskript das mal 15k-Werte durchgeht

Bei dieser Klasse hab ich jedoch das mit den Copyright-Bedingungen nicht ganz verstanden...

Doch ich denke schon (auch wenns dämlich gemacht ist.. aber da bin ich mittlerweile ganz gut im Saft ), 1:1 mit Author usw. rüberkopieren sollte ok sein, es gäbe auch noch drei alternativen (wovon eine schon wieder satte Fehler hat..)

Lieber gleich zusammenfassen, wir sprechen hier ja nicht von hunderten Zeilen.. Ich comitte das morgen mal, was davon nicht gefällt kann man dann gerne nullen.
Das "neue" jsmin fügt jeweils nur einen C-Verweis auf die ja mitaugelieferte nicht-minified-Version ein, ich denke das ist moralisch und rechtlich 100% safe..

Makki

P.S.: Ob das mit dem DPT14 gerade bei dem am besten aufgehoben ist, der eine Mantisse immernoch für ne unerklärliche Sonderform des Mantelrochens hält = ?

[Chris M.]

Um einen weiteren untergegangenen Beitrag zu bergen...

Um mal kurz wieder ein Lebenszeichen zu geben:

ich bin leider nicht wie erwartet über Weihnachten zur Anpassung des Editors an den aktuellen SVN-Stand gekommen.

Das ist einer der Unterschiede zwischen kommerziell und privat: das kann ich gut nachvollziehen und hoffe(!) dass Du nun wieder wieder etwas mehr dazu kommst.

Da der aktuelle Source aber im SVN liegt wäre ich niemandem böse der sich auch daran versuchen will. Dann bitte kurze Info, nicht dass da mehrgleisig Energie verwendet wird

Ich werde mich da nicht drum kümmern, da ich momentan am GLE sitze (neben dem 19"-Rack aufräumen, Fotos bearbeiten, damit bald mehr als nur ein Bild an der Wand hängen kann, Markise kaufen, ... )