CometVisu - (interner) Beta-Test

[JNK]

Ist das nur ein Problem bei mir oder funktioniert im pure-design die Umschaltung "switchPressed" und "switchUpressed" nicht?

Folgender Code aus structure_pure.js:

update: function(e,d) { 
      var element = $(this);
      var value = defaultUpdate( e, d, element );
      var off = element.data( 'off_value' );
      element.removeClass( value == off ? 'switchPressed' : 'switchUnpressed' );
      element.addClass(    value == off ? 'switchUnpressed' : 'switchPressed' );
    },

Das Problem bei mir ist nun:

attributes: on_value=1, off_value=0

In der Routine sagt mir Firebug:

value = "An"
off="0"

folglich wird switschPressed gesetzt. Wenn ich dann nochmal drücke passiert folgendes:

value = "Aus"
off="0"

und logischerweise bleibt switchPressed.

Vorschlag für einen Fix:

update: function(e,d) { 
      var element = $(this);
      defaultUpdate( e, d, element );
      var off = element.data( 'off_value' );
      var  value = element.data( 'value' );

      element.removeClass( value == off ? 'switchPressed' : 'switchUnpressed' );
      element.addClass(    value == off ? 'switchUnpressed' : 'switchPressed' );
    },

Das behebt das Problem zumindest bei mir, aber ich kann nicht ganz überblicken, ob as side-effects hat. Einchecken?

Gruss,

der Jan

[Chris M.]

Ist das nur ein Problem bei mir oder funktioniert im pure-design die Umschaltung "switchPressed" und "switchUpressed" nicht?

Der Code ist ziemlich neu, d.h. gut möglich dass da noch ein Bug drinnen steckt.

Wie lautet denn bei Dir der entsprechende Eintrag in der Konfig-Datei?

Dann schau ich mir das mal genauer an und würde dann den Fix einchecken.

[JNK]

Der Code ist ziemlich neu, d.h. gut möglich dass da noch ein Bug drinnen steckt.

Wie lautet denn bei Dir der entsprechende Eintrag in der Konfig-Datei?

Dann schau ich mir das mal genauer an und würde dann den Fix einchecken.

 <mapping name="OnOff">
        <entry value="0">Aus</entry>
        <entry value="1">An</entry>
      </mapping>

und

<switch mapping="OnOff" styling="RedGreen" align="center" off_value="0" on_value="1">
        <label>Allgemeinlicht</label>
        <address transform="DPT:1.001" type="">1/1/3</address>
        <address transform="DPT:1.001" readonly="true" type="">1/7/3</address>
      </switch>

[Chris M.]

OK, das sieht nach 08/15 aus, das muss gehen. Ich schau mir das an (denn wenn's nicht funktioniert hätte, hätte ich's auch nicht commited )

[makki]

@Chris: Ok, vermutlich kapiert, werd das mal etwas leben (weil irgendwas stimmt da nicht zumindest mit discreet und nach dem switchen von Designs; aber um das halbwegs zu finden muss ich verstehen wie es richtig sein sollte..)

zum letzten Post: ich glaube das Problem war mit mehreren hörenden GA's, melde mich falls es nicht funzt.

RTR-(WG)-Plugin machen wir besser bei diesem weiter, ich glaube dieser Thread ist schon unübersichtlich genug

Makki

[makki]

Thema Editor, hätte mir morgen mal vorgenommen:
- Umstellung von alert auf jnotify
- Fehlerhandling (und anzeige dieser) in get_addresses (und allgemein)
- AbholenAuswahl verfügbarer RRD's fürs diagram_*-widget

Einwände?

Sofern der Grössenwahn einsetzt (Denn sie wissen nicht was sie tun..):
- flavor-Bug #3187464
- mehrere RRD's im diagram_*-Widget (das backend kann das ja schon )
-> wie sollte das in die config??
<diagram_popup rrd="28.7FD4EB010000_temp" rrd1="28.12345000000" ..
(ist bestimmt eher falsch..)

Makki

[Chris M.]

Der "schuldige" ist identifiziert:

<mapping name="OnOff">

Denni ch hatte wohl ohne Mapping getestet...

(denn wenn's nicht funktioniert hätte, hätte ich's auch nicht commited )

Um das zu lösen, müssen wir eine Design-Entscheidung treffen. Es gibt zwei Möglichkeiten:

1. on_value / off_value wird auf den jeweiligen KNX-Wert gesetzt, d.h. den nicht gemappten Wert (wie "0" und "1")
2. on_value / off_value wird auf den Wert des Mappings gesetzt (wie "An" und "Aus")

JNK hat intuitiv Version 1. verwendet. Ein Anwender mag dadurch evtl. verwirrt sein, dass der angezeigte Name nicht zu den Werten in on_value / off_value passt (insbesondere bei "offen" und "geschlossen" wo der KNX-Standard sich selbst nicht klar ist, wie die 0 und 1 darauf verteilt werden...)
Wenn man nun bedenkt, dass man das Mapping ja leicht ändern kann, würde das wieder für 1. sprechen. Man könnte ja auch den Editor so erweitern, dass der live ein Mapping übernimmt und die Werte übersetzt.

Welche Lösung sollen wir einbauen? 1. oder 2.?

[Chris M.]

Einwände?

Nö

- mehrere RRD's im diagram_*-Widget (das backend kann das ja schon )
-> wie sollte das in die config??
<diagram_popup rrd="28.7FD4EB010000_temp" rrd1="28.12345000000" ..

Die saubere und richtige Lösung wäre es analog der <address> Elemente bei den anderen Widgets. Das Problem ist nur, dass das in der aktuellen Implementierung des Editors wohl schwierig zu realisieren ist...

Da sich schon ein paar Dinge für den Editor angesammelt haben, würde ich fast dazu tendieren, die Liste einfach noch bisschen größer zu machen.

Julian, liest Du mit? Was meinst Du?

[makki]

Dachte ich mir schon, ich kann zwar nicht OO/XML-"denken" aber zumindest sehe ich wenns nicht dazupasst und wann sich strategische "Denkfehler" anbahnen (rrd1..99=)
Einfaches, ohne strukturelle Änderungen bekomme ich halt ggfs hin, wenns tiefer geht muss ich meist nach Stunden feststellen, das ich einfach scheitere..

Ich denke ich mache ggfs. erstmal ein neues Widget - Kopie von diagram_popup - und versuche das dort analog mit <address> einzubauen (ich will ja eh, das statt dem preview der aktuelle KNX-Wert angezeigt wird..)
Aber ich steh halt auf Kurven und bevor ich jetzt den flot in die Webmin-Sache reinfummel ist das hier IMHO sinniger, die Zeit zu verbraten

Ich brauche&nutze das selbst täglich, drraw&Co sind mir ja selbst ehrlichgesagt einfach zu lahm, HS geht garnicht (Diagramm anlegen und dann ne Viertelstunde warten bis man sieht wie es aussieht..)
(Wenn ich mir das aus den Flot-examples per Copy&Paste hole ist das ja alles ganz einfach - aber das dann integrieren...)

Makki

P.S.: Wie ist die Meinung zu den "jQuery-Tabs" ? jegliche Meinungen sind gerne gehört! Ich würde mir eine Visu halt so vorstellen, das sie die Widgets automatisch (je nach Auflösung/Orientierung) halt ggfs auf solche Tabs verteilt statt einem nur schwerlich bedienbaren scroll-balken an der Seite o,ä...

[vlamers]

Ich bin auch der Meinung dass scrollen auf den endgeräten sch*** ist. Soll ja kein ewiges gefummel sein bis ich schalten kann.
Denke auch dass das seitliche wischen nicht so gut ist!? Mir persönlich wären 2 Pfeile lieber.

Gruß

[JNK]

Ich denke ich mache ggfs. erstmal ein neues Widget - Kopie von diagram_popup - und versuche das dort analog mit <address> einzubauen (ich will ja eh, das statt dem preview der aktuelle KNX-Wert angezeigt wird..)

Äh. Danke. Ich finde das gut, dann könnte ich nämlich einfach ein Feld freiräumen. Wenn ich ein Preview will, nehme ich ein diagram_inline.

P.S.: Wie ist die Meinung zu den "jQuery-Tabs" ? jegliche Meinungen sind gerne gehört! Ich würde mir eine Visu halt so vorstellen, das sie die Widgets automatisch (je nach Auflösung/Orientierung) halt ggfs auf solche Tabs verteilt statt einem nur schwerlich bedienbaren scroll-balken an der Seite o,ä...

Ich finde das Beispiel aus Tabs 13/13 (also mit den kleinen Punkten unten und den Pfeilen rechts und links) am besten.

@Chris: Ich halte Option "1" für "strukturell" am sinnvollsten. die KNX-Werte sind die quasi die "Grundlage", und an denen sollten wir uns orientieren. Die Idee im Editor ein "Live-Mapping" zu machen finde ich gut.

Gruss,

der Jan

[Chris M.]

Dachte ich mir schon, ich kann zwar nicht OO/XML-"denken"

Da muss man einmal durch, ist danach aber ein deutlich besserer Programmierer. Ich hatte das auch jahrelang vor mir hergeschoben, aber es bringt wirklich was!
Das wichtigste dabei ist, sich nicht verwirren zu lassen. Denn OO Programmierer verwenden für trivial normale Dinge gerne mal ein anderes Wort. So ist eine "Methode" eigentlich auch nur eine stink normale Funktion.

Am saubersten und einfachsten für den Einstieg halte ich da tatsächlich die Klassen bei C++ (bitte das Erweiterte wie Templates, STL, ... erst mal ignorieren. Qt ist da bodenständig unterwegs).

P.S.: Wie ist die Meinung zu den "jQuery-Tabs" ? jegliche Meinungen sind gerne gehört! Ich würde mir eine Visu halt so vorstellen, das sie die Widgets automatisch (je nach Auflösung/Orientierung) halt ggfs auf solche Tabs verteilt statt einem nur schwerlich bedienbaren scroll-balken an der Seite o,ä...

Ich finde das Beispiel aus Tabs 13/13 (also mit den kleinen Punkten unten und den Pfeilen rechts und links) am besten.

Mit der Text basierten Visu könnt ihr machen, was ihr für sinnvoll haltet, da bin ich nicht sonderlich emotional.
Was mir aber wichtig ist, ist dass sich transparent auch 2D und 3D Seiten einfügen lassen. D.h. im <page> Element kommt das Attribut "type" (= "text", "2d" oder "3d") dazu. Die dann "einfliegende" Seite ist entweder eine Hintergrund-Grafik mit frei platzierten Widgets oder das ganze in 3D und interaktiv bewegbar (SourceForge.net: JavaScript 3D Floorplan - Open Automation)

@Chris: Ich halte Option "1" für "strukturell" am sinnvollsten. die KNX-Werte sind die quasi die "Grundlage", und an denen sollten wir uns orientieren. Die Idee im Editor ein "Live-Mapping" zu machen finde ich gut.

Ist auch mein Favorit. Wenn jetzt keine gegenteilige Meinung mehr kommt, setzte ich das so um.

[JNK]

Tag zusammen,

noch eine Design-Frage:

Ich baue gerade an dem Trigger-mit-Anzeige Widget (Arbeitsname: infotrigger, wer was besseres hat: immer her damit).

Zumindest so wie das bei mir implementiert ist, sende ich auf einer GA (4/1/3) ein DPT:1.001, je nachdem ob rauf oder runter mit der Temperatur. Die Rückmeldung kommt auf einer anderen GA (4/2/3) als DPT:9.001:

<infotrigger styling="STempSet" uplabel="+" upvalue="0" downlabel="-" downvalue="1" align="center" format="%.1f °C">
   <label>Testtrigger</label>
   <address transform="DPT:1.001">4/1/3</address>
   <address transform="DPT:9" readonly="true">4/2/3</address>
</infotrigger>

Ich habe das jetzt so gelöst, dass die Buttons an jede GA senden, die schreibbar ist und die "readonly"-GA für die Anzeige verwendet wird. So richtig gefallen tut mir das nicht, man müsste dann noch abfangen, dass nicht mehrere read-only angegeben werden.
Oder sagen wir, das ist Pech, wenn jemand ohne Editor am XML-File rumfummelt und der Editor verhindert dass mehr als eine GA read-only wird?

Gruss,

der Jan

[Chris M.]

Hallo Jan,

Zumindest so wie das bei mir implementiert ist, sende ich auf einer GA (4/1/3) ein DPT:1.001, je nachdem ob rauf oder runter mit der Temperatur. Die Rückmeldung kommt auf einer anderen GA (4/2/3) als DPT:9.001:

Stimmt, das ist bei dieser Art Widget ein Problem, da die implizite Annahme 1 Widget = 1 Adresse nicht mehr gilt.

Eine magische Lösung, die nur auf readonly schaut, finde ich auch nicht glücklich, da Dinge gemischt werden, die eigentlich nichts miteinander zu tun haben.

Das einzige Widget, dass wir bisher haben, dass mehrere verschiedene Arten von Adressen gleichzeitig handlen muss, ist der Colorchooser. Da ist das gelöst über:

    <colorchooser>
      <label>A colorChooser</label>
      <address transform="DPT:5.001" color="r">1/2/59</address>
      <address transform="DPT:5.001" color="g">1/2/60</address>
      <address transform="DPT:5.001" color="b">1/2/61</address>
    </colorchooser>

D.h. bei diesem Widget könnte man ein Attribut "type" = "info" oder = "value" (o.ä.) dem <address> Element hinzufügen.

Nachteil: der Editor kann damit (noch) nicht umgehen, d.h. man müsste aktuell per Hand die Config-Datei editieren - und jede Verwendung des Editors zerstört an dieser Stelle die Config-Datei. (Vgl. was z.Zt. beim ColorChosser passiert)

@Julian / Netzkind: was ist da Deine Meinung?

PS @Jan: Falls Du die SVN Mailingliste aboniert hast, dann weist Du's schon - falls nicht: der Bug von vor ein paar Posts ist jetzt behoben. Dein Fix wäre auch gut gewesen, ich habe mich jedoch entschieden, den gemappten Wert zu vergleichen, das dürfte im Grenzfall für den Anwender logischer erscheinen.

[JNK]

Hallo Jan,
Eine magische Lösung, die nur auf readonly schaut, finde ich auch nicht glücklich, da Dinge gemischt werden, die eigentlich nichts miteinander zu tun haben.

Dann sehen wir das ja gleich.

D.h. bei diesem Widget könnte man ein Attribut "type" = "info" oder = "value" (o.ä.) dem <address> Element hinzufügen.

Hatte ich auch schon überlegt. Das Problem ist dann, dass ein Config-Check viele falsche Sachen kaum abfangen kann. Man müsste dann checken, ob ein attribute "color" nur dann verwendet wird, wenn das Widget "colorchooser" ist und das attribute "type" nur bei sowas wie dem "infotrigger".

Ich glaube hier müssen wir uns entscheiden, für wen das "einfach" sein soll. Man könnte ja auch einfach ein attribute "option" einführen. Beim colorChooser wird das für die Farbe "r", "g", "b" verwendet, hier dann für "info" und "actor".

Ganz allgemein: Ich hab das jetzt funktionierend hinbekommen, aber irgendwie bin ich nicht zufrieden, das scheint mir sehr "unelegant" gelöst. Ich glaube die Mozillas machen dass so, dass man einen Patch produziert und dann im Bug/Featurerequest postet und irgendjemand guckt sich das mal an. Soll ich das auch mal so machen? Oder einchecken, es geht ja bei keinem anderen was kaputt.

Gruss,

der Jan