CometVisu - (interner) Beta-Test

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

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

[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

[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

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

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

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]

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

[manu241]

Hallo,

ich habe aber nicht nur das Wiregate sondern auch Biq´s die gefüttert werden müssen mit dem Sollwert. Daher muss dafür bestimmt ein extra Plugin geschrieben werden.

Gruß Manuel

[Chris M.]

Eigenes Widget fänd ich gut. Vielleicht versuch ich mich daam Wochenende mal dran. Praktisch wärs auf jeden Fall, im Prinzipo eine Kombi aus Multitrigger und info.

Dafür gibt es 2-3 Wege:

1. Offizielles Widget (d.h. in structure_pure.js), das bekommt jeder immer
2. Plugin (d.h. Unterverzeichnis unter /plugins/), das kann man bei Bedarf dazu laden
3. Eine private Erweiterung, d.h. in structure_custom.js - die darf jeder überschreiben und sollte vom Paket-Management nicht angefasst werden.

Bei jedem neuen Widget sollte man sich überlegen, wo es am besten rein gehört.
In 2. kommen "große" und "fette" Dinge, d.h. Widgets die die Ladezeit verzögern können und die viele nicht zwingend brauchen. Das hier beschriebene Widget ist dagegen klein, d.h. in 2. passt es nicht so ganz.
Der Unterschied zwischen 1. und 3. ist eigentlich nur, ob das für die Allgemeinheit wichtig ist (-> 1.) oder nicht (-> 3.)
So ein Temperatur-Wähler halte ich für die Allgemeinheit für sinnvoll => 1. wäre meine Wahl

Das Plugin ist fertig, das funktioniert so, aber ich wollte das noch auf mehrere Kanäle aufbohren, bevor ich das veröffentliche.

Ich hatte bei meinen PI-Regler-Plugins mir am Anfang auch öfters gewünscht, die in einem großen Plugin zu sammeln.
Da ich aber bei manchen eine zeitbasierte Umschaltung eingebaut habe, etc. bin ich inzwischen eigentlich froh, dass ich für jeden Heizkreis ein eigenes Plugin habe.

[JNK]

@ ChrisM:

Eigenes Widget fänd ich gut. Vielleicht versuch ich mich daam Wochenende mal dran. Praktisch wärs auf jeden Fall, im Prinzipo eine Kombi aus Multitrigger und info.

@manu:

Das Plugin ist fertig, das funktioniert so, aber ich wollte das noch auf mehrere Kanäle aufbohren, bevor ich das veröffentliche.

Gruss,

der Jan

[Chris M.]

Sorry, ich stehe da immernoch grob auf dem Schlauch Wo steht das flavour lithium=Farbe xy? Mag ne dumme Frage sein, aber ich kapiers nicht ganz..

In der normale Konfig-Datei steht beim <page> Element, welchen Flavour es haben soll (optional, Fallback auf Standard).
Das Aussehen des Flavours ist in der entsprechenden CSS definiert, z.B. in /designs/pure/basic.css so ab Zeile 329.

Die Darstellung funktioniert übrigens darüber, dass die Styles "überladen" lassen, d.h. demm Class-Attribut einer Seite einfach zuätzlich noch eine Flavour-Klasse hinzugefügt wird. (Am besten einfach mal das HTML im FireBug ansehen, dann wird der Satz klar )

Wenn nun ein Element die Akzent-Farbe eines Flavours haben möchte, dann sollte es vermutlich auf die background-color des <hr> schauen.

[makki]

Flavour ist eigentlich ganz einfach:
Das Design der CometVisu lässt sich auf drei verschiedenen Ebenen anpassen:

Sorry, ich stehe da immernoch grob auf dem Schlauch Wo steht das flavour lithium=Farbe xy? Mag ne dumme Frage sein, aber ich kapiers nicht ganz..


1) ist klar (heisst nicht das ich wüsste es zu erweitern aber das wäre der Ansatz um aus dem jetzigen jQ-Tabs/Slides zu machen..)

[*]Das Design. Hier wird einfach per entsprechender CSS definiert, wie die Widgets konkret aussehen, d.h. Farben und Formen. Hier gibt's die bekannten Varianten wie "pure" und "discreet"

Das ist schon hinbekommen (in der demo-visu gibts pure_mobile)

[*]Der Flavour. Jedes Design(!) kann Flavours definieren, die quasi die "Geschmacksrichtung" der entsprechenden Seite definieren. Z.Zt. sind die nur im Design "pure" definiert und bestimmen dort die Akzent-Farbe.

Gut, da hats jetzt gerade "klick" gemacht.. Ok, das Diagramm hat in den Kurven immer die Farbe des initialen Designs (ich schätze mal das darf man fehlendes Feature der discreet-Design nennen, ist aber jetzt nicht so wichtig, ich wills verstehen warum..)

An dem stören mich drei Dinge, hoffentlich liegen möglichst viele davon an meiner Unfähigkeit:
[LIST=1][*]Sau lahm (trotz Core i7 und Hauptspeicher der für zwei 32 Bit Systeme mehr als reichen würde)

Naja, es ist Java Aber ich würde sagen: zum testen ok, läuft auf meinem dagegen mickrickigen Core2 Duo P8700 flüssig. Ich bin aber 32Bit-Fan, vielleicht liegts daran (und Java..)
Sonst haben wir ja vermutlich dasselbe OS drauf, Windows 10.04,10.10,11.04 ging..

[*]Ich kann den Browser-Cache nicht ausschalten (nur per Hand löschen,

lästig, ja, aber zum testen und entwickeln kann man ja den Desktop-Browser verwenden, zum finetuning dann den Emu; finde ich ehrlichgesagt immernoch komfortabler als das Endgerät selbst..
Wenigstens hat man da den adb-Debugger-Logger.. Aber bis Android und ich echte Freunde werden, wird auch noch ne Weile vergehen Beim derzeitigen Marktanteil ohne sichtbare bessere Alternativen (Maemo/MeeGo wäre meins aber naja, das ist halt eher tot) hab ich mich halt vorerst einfach nur damit abgefunden das es so ist wie es ist. Besser als Apple

Als Ziel sehe ich hier übrigens primär/ausschliesslich den Onboard-Webkit (Chrome/Safari), den sich die beiden derzeit verbreiteten Smartphone-Plattformen ja quasi teilen, ob das mit einem Fancy-XY-Opera/Mobile-FF oder sonstwas läuft halte ich für sekundär (und ich habe selber ein Smartphone, auf dem FF4 läuft aber kein Webkit.. aber das ist nunmal nicht kriegsentscheidend..)

-> Aber das ist IMHO die Killerapplikation, das muss aufm mobile genauso lüppen wie ein sch*** Command(con)fusion und das tut es ja schon fast (um real, endlich, nochmal, das dämliche Gerücht zu wiederlegen das sowas mitm Browser ohne "App" nicht auch in realtime ginge.. tuts nämlich..)

Makki

[Chris M.]

Das ist jetzt so eine Sache mit CSS und flavors die ich ehrlichgesagt noch nicht ganz blicke Ich weiss zwar wie ich jetzt *irgendwie* die Farben ändere aber ich würds gern verstehen, wie es richtig&gedacht ist.

Flavour ist eigentlich ganz einfach:
Das Design der CometVisu lässt sich auf drei verschiedenen Ebenen anpassen:

1. Das prinzipielle Aussehen, Seitenaufbau, Navigation, ... Hier gibt es zur Zeit nur eine Implementierung (nämlich die in templateengine.js), d.h. es weiß kaum einer, dass man hier zumindest theoretisch wählen könnte
2. Das Design. Hier wird einfach per entsprechender CSS definiert, wie die Widgets konkret aussehen, d.h. Farben und Formen. Hier gibt's die bekannten Varianten wie "pure" und "discreet"
3. Der Flavour. Jedes Design(!) kann Flavours definieren, die quasi die "Geschmacksrichtung" der entsprechenden Seite definieren. Z.Zt. sind die nur im Design "pure" definiert und bestimmen dort die Akzent-Farbe.
   (In naher Zukunft werde ich noch Gruppen einbauen, d.h. einen optischen Rahmen um Widgets, um auf einer Seite für mehr Struktur sorgen zu können. Denen werde ich auch Flavours geben, die dort den Rahmen oder den Hintergrund bestimmen können)

D.h. das Diagramm sollte sich in der Farbe des aktuellen Flavours malen.

Irgendwas ist da zumindest bei mir verhunzt, wo genau sollte (um beim Beispiel diagram_popup zu bleiben) die Farbe der Linie stehen ?

Im Zweifel ist immer die config=demo entscheidend. Wenn die mag (und die hat Flavour-Beispiele drinnen), dann ist die Installation i.O.

Zum testen geht das Andriod-SDK mit dem emulator eigentlich ganz gut (bzw. ist es eh bequemer aber das "feeling" fehlt natürlich wie z.B. das die obere linke Ecke einfach nicht direkt erreichbar ist)

An dem stören mich drei Dinge, hoffentlich liegen möglichst viele davon an meiner Unfähigkeit:

1. Sau lahm (trotz Core i7 und Hauptspeicher der für zwei 32 Bit Systeme mehr als reichen würde)
2. Ich kann den Browser-Cache nicht ausschalten (nur per Hand löschen, das macht aber wegen 1. keinen Spaß)
3. Ich weiß nicht wie ich an die Browser internen Debug-Infos a la FireBug komme.

[makki]

Das letzte mal, wo ich mir das angesehen hatte, hatte sich das Plugin die Farbe aus der Seite selbst geholt - was eigentlich genau der richtige Weg ist. Denn das Plugin kann nie wissen, wie die Seite aussehen soll - dass weiß nur das CSS.

Das ist jetzt so eine Sache mit CSS und flavors die ich ehrlichgesagt noch nicht ganz blicke Ich weiss zwar wie ich jetzt *irgendwie* die Farben ändere aber ich würds gern verstehen, wie es richtig&gedacht ist.
Irgendwas ist da zumindest bei mir verhunzt, wo genau sollte (um beim Beispiel diagram_popup zu bleiben) die Farbe der Linie stehen ?

Ohne Beispiel kann ich mir da gerade wenig vorstellen.

Hier
Ich würde es so ähnlich (!) machen;
Scrollen finde ich ehrlichgesagt blöd, es geht schon aufm Desktop nur sehr leidig.. Scrollbalken wären hässlich..
Die Navigationsbuttons würde ich allerdings nicht mehr in die Ecke packen, das ist in der Praxis IMHO schlecht bedienbar.
So oder so (ohne Slideshow natürlich)
Man beachte, das man mit den kleinen Bommeln unten auch Seiten anspringen kann.. (die dürfen ja auch etwas grösser sein)

Hoch/Runter-Scrollen geht per Irgendwo-touchen-und-hoch/runter-ziehen.
Seiten-Wechsel geht per Verschieben des Bildschirminhaltes nach links/rechts.

Genau.. links rechts sliden kann man sicher abfangen und damit die Tabs springen lassen.
Ich will langsam endlich meine HS-Visu abschaffen
Auf dem mobile ist das aber noch leicht holprig, die Navigation mit dem page-namen links oben z.B. da bricht man sich jedesmal nen Finger, in einer perfekten Welt lässt sich die Visu mitm dicken Daumen bedienen..
Zum testen geht das Andriod-SDK mit dem emulator eigentlich ganz gut (bzw. ist es eh bequemer aber das "feeling" fehlt natürlich wie z.B. das die obere linke Ecke einfach nicht direkt erreichbar ist)

Makki