CometVisu - (interner) Beta-Test

[luigi4711]

Ich hatte auch mal den Colorchooser probiert und war auch nicht so ganz glücklich mit
der Farbwahl. Das es 'fast immer weiss', bzw. 'extrem blaulastig' war kann ich zwar nicht bestätigen, aber es war dennoch oft nicht ganz die gleiche Farbe wie die auf dem Farbkreis.

Aufbau war der hier https://knx-user-forum.de/diy-do-you...-wiregate.html

[Da kann man sogar bei genauer Betrachtung noch sehen, was auf dem Smartphone angezeigt war]

Kann das ganze leider momentan nicht mehr ausprobieren, da die Sachen weggepackt sind... ich bin momentan im Rohbau (Sanierung eines alten Hauses).

luigi

[JNK]

Colorchooser

Hallo,

ich habe gerade folgende Installation in Betrieb genommen:

12V-RGB LED Stripe, DMX4ALL MiniRGB LED Dimmer, DMX4ALL NanoDMX, WG-Plugin von makki

Was gut funktioniert: mit "slide"-widgets R,G,B ansteuern, es gehen die richtigen Farben an und auch die Helligkeit wechselt irgendwie, wenn auch gefühlt nicht unbedingt 50%=halbe Helligkeit.

Und vermutlich ist genau das auch das Problem: Der colorchooser lässt die Farben auch wechseln, aber die ausgewählt und die tatsächliche Farbe haben oft nix miteinander zu tun, die tatsächliche Farbe ist ziemlich oft "fast weiss" bzw. extrem blau-lastig.

Ist das ein Problem meines Stripes, des colorchoosers oder von sonst irgendwas? Kann man an den Dimmkurven was regeln? Und wenn ja, im WG-plugin oder im Colorchooser?

Gruss,

der Jan

[makki]

Mach das, was Julian empfiehlt...

Eh, wenn ihr das sagt mach da nen Haken dran und fertig

Erweitere lieber das Design / Flavour um zusätzliche Farben als welche zu raten. Das geht im Zweifel nur schief...

Ich bin da schon sensibilisiert (gefühlte 5 mit Rot-Grün-Sehschwäche in der Firma..), wünsche mir sowas halt sinnvoll vorbelegt, man soll es ändern können aber nicht per se müssen.. Ich z.B. will kurven, ob die rot, grün oder lilablassblau sind ist mir wurscht (zweideutig, ich ich weiss )

Ich könnte mir vorstellen, dass man 3 Farben im Design vorgibt und per Default bei der nächsten einfach wieder vorne anfängt (so lange nicht explizit was anderes angegeben wurde)

Dachte ich mir etwas anders aber Fakt, gehört ins Design, ist damit anpassbar. Die ersten nahe am flavour, danach möglich kontrastreich unterscheidbar. Das hilft nicht nur den Rot-Grün-schwachen sondern auch normalsichtigen aufm Touch mit Sonne von hinten

Makki

[Chris M.]

Also address, kein Duplikat davon?

Mach das, was Julian empfiehlt...

(muss ich ausprobieren aber die Farben halt so, das sie zum design/flavour passen und trotzdem unterscheidbar sind..)

Erweitere lieber das Design / Flavour um zusätzliche Farben als welche zu raten. Das geht im Zweifel nur schief...
Ich könnte mir vorstellen, dass man 3 Farben im Design vorgibt und per Default bei der nächsten einfach wieder vorne anfängt (so lange nicht explizit was anderes angegeben wurde)

Letzte Frage: in der SVN-Version das diagram_popup ändern und damit config-seitig komplett breaken oder ein neues? Ich bin für letzteres, info_diagram o.ä.

Ich würde auch ein getrenntes machen - vereinigen kann man dann immernoch

Jo, macht die Liste mal ruhig länger. Wenns die Liste in komprimierter Form gibt arbeite ich die vielleicht auch mal ab

Hab die Liste mal in der dafür vorgesehenen Form angefangen (-> SF Bug und Feature Request)

[makki]

@Julian: Danke! jetzt weiss ich wenigstens warum ich das in element das nie gefunden hätte wenns im parent steckt

Zwecks rrd-Attribute in address: solange es technisch&strategisch so auf Zustimmung stösst kann ich damit leben, ich denke ich bekomme das auch in den Editor eingebunden (eben "händisch" so wie transform etc auch, muss ich ja nur kopieren )

@JNK: schon klar, die spannende Frage wär nun, welchen Wert das info-Widget anzeigt.. Lass es mich erstmal halbwegs umsetzen (das wichtigere wär mir gerade mehrere RRD's..) und dann beurteilen was ich hinbekomme; eine Idee hätte ich dafür..

Makki

[netzkind]

Nö

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?

Jetzt wieder.

Ich sehe das wie du (schwierig, aber richtig) - falls sich das nicht zwischenzeitlich schon erübrigt hat


Jo, macht die Liste mal ruhig länger. Wenns die Liste in komprimierter Form gibt arbeite ich die vielleicht auch mal ab

Grüße,
Julian

[netzkind]

Den Editor habe ich komplett Julian überlassen. Meine Hoffnung ist, dass er sich bald hier meldet...
(Sein Input wäre auch für diese Frage hilfreich: )

Meld.
Scheiß Nebenhöhlen verderben einem den ganzen Spaß mit den Kopfschmerzen. Derzeit bin ich froh wenn ich nach dem Arbeitstag nicht mehr auf den Monitor schauen brauche

Habe jetzt seit ein paar Wochen nicht mehr mitgelesen, werde also nach und nach einiges aufarbeiten müssen. Die Dinge an denen ich bislang meinen Namen gesehen hatte: siehe SVN rev#345.

Grüße,
Julian

[JNK]

Naja, der aktuelle Wert=address, kommt eh vom KNX+rrd.
Mehrere: ich hab halt rund 50 Temperaturen und die würde ich gerne kompakt darstellen.

Ja, was ich meine ist: wenn Du statt der Preview einen Wert anzeigst, gibt's ja nur genau einen, also reicht egal was Du im Diagramm hast eine Adresse.

<infodiagram>
<Address transform=...>1/2/3</Address>
<rrd variant="Yellow">rrd1_name</rrd>
<rrd variant="Red">rrd2_name</rrd>
</infodiagram>

[makki]

Naja, der aktuelle Wert=address, kommt eh vom KNX+rrd.
Mehrere: ich hab halt rund 50 Temperaturen und die würde ich gerne kompakt darstellen.

Aber wiegesagt: ich warte vor der Umsetzung gerne noch auf etwas Feedback, weil es geht vieles aber 1x richtig fände ich auch zielführender

Makki

[JNK]

Also address, kein Duplikat davon? Falls kein Einspruch kommt setze ich es so um..



Denke schon, man kann pro address ja dann optional z.B. eine Farbe, eine Legende etc.pp. hinzufügen.

Mir ist das noch nicht ganz klar.

Infodiagram: Address für die Anzeige des aktuellen Werts.

Wofür braucht man da mehrere?

Was multi-rrd-popup angeht:

Ich würde da ein

<rrd variant="red">rrd_name</rrd>

Einem Missbrauch von Address deutlich vorziehen.

Und: ja, was neues. Wer weiß wozu man das andere doch nochmal gebrauchen kann.

Gruß,

Der Jan

[makki]

(Sein Input wäre auch für diese Frage hilfreich: )

Definitiv. Ich hab mich vorgestern ja ganz gut durch den Editor gekämpft, aber da ist Schluss (wobei das sicher mit meinen 3 Problemen zu tun hat: OO, OO&OO..)

Ich bin für ein <address>-Element pro RRD.
Farbe sollte erst mal aus dem Design-abhängigen CSS kommen, aber der User übersteuern können.

Also address, kein Duplikat davon? Falls kein Einspruch kommt setze ich es so um..
(muss ich ausprobieren aber die Farben halt so, das sie zum design/flavour passen und trotzdem unterscheidbar sind..)

Reicht da unser "universal"-Attribut "variant",

Denke schon, man kann pro address ja dann optional z.B. eine Farbe, eine Legende etc.pp. hinzufügen.

Letzte Frage: in der SVN-Version das diagram_popup ändern und damit config-seitig komplett breaken oder ein neues? Ich bin für letzteres, info_diagram o.ä.
Dito, wenn kein Einspruch kommt (spart Antwort) mache ich ein sep.

Makki

[Chris M.]

Anderes: Sorry, #3187464 (flavour im Editor), habs versucht, die Fundstelle in den Bug geschrieben aber am Fix bin ich schlicht gescheitert, ich finde nicht wo die weiteren Attribute der page sich verstecken..

Den Editor habe ich komplett Julian überlassen. Meine Hoffnung ist, dass er sich bald hier meldet...
(Sein Input wäre auch für diese Frage hilfreich: )

Multi-RRD: address klonen oder erweitern, jegliches fachliches Feedback willkommen!
Die hälfte hätte ich schon fertig und ich will da die Tage weiter/fertigmachen bevor ich wieder raus bin..
Und gehört die Farbe verschiedener Datenkurven ins CSS (sagt der Verstand) oder ham die defaultwerte (evtl. abgeleitet von flavour?) und snd pro Wert im Editor als attribut einstellbar.

Ich bin für ein <address>-Element pro RRD.
Farbe sollte erst mal aus dem Design-abhängigen CSS kommen, aber der User übersteuern können. Reicht da unser "universal"-Attribut "variant", oder haben wir da jetzt schon den Fall, von dem ich gehofft habe, dass der nie auftritt? (D.h. dass wir noch mehr Attribute pro <address>-Element brauchen?)

[makki]

Anderes: Sorry, #3187464 (flavour im Editor), habs versucht, die Fundstelle in den Bug geschrieben aber am Fix bin ich schlicht gescheitert, ich finde nicht wo die weiteren Attribute der page sich verstecken..

Multi-RRD: address klonen oder erweitern, jegliches fachliches Feedback willkommen!
Die hälfte hätte ich schon fertig und ich will da die Tage weiter/fertigmachen bevor ich wieder raus bin..
Und gehört die Farbe verschiedener Datenkurven ins CSS (sagt der Verstand) oder ham die defaultwerte (evtl. abgeleitet von flavour?) und snd pro Wert im Editor als attribut einstellbar.

Makki

[makki]

Die Visu kann mit den 4 Bit Dingern ziemlich wenig anfangen, denn die sagen ja nur wie relativ gedimmt werden soll. Die Visu braucht zum Anzeigen aber einen absoluten Wert.
(Was natürlich geht, ist die 4 Bit GAs auf den Trigger oder der Multitrigger zu legen und die Werte zu versenden - aber wie soll man die vernünftig anzeigen?)

Eigentlich einfach, die Visu-Anzeige erfolgt IMHO ausschliesslich über das RO-Dimmwert-Rückmeldeobjekt, aus den 4Bit Telegrammen ist ebenso wie aus dem Dimmwert-setzen nichts zu schliessen (wenn z.B. die Dimmzeit einfach auf 1h eingestellt ist )
Mein Vorschlag wäre, das sobald ein RO-Rückmeldeobjekt angelegt ist, keine Visu-Aktualisierung über das schaltobjekt mehr stattfindet. Also, in flexibler: ein Write-only flag. (Für Dimmwert setzen, 4bit, ..)
Jeder halbwegs vernümftige KNX-Dimmaktor/DALI-GW kann das ja..

OK, mir war nicht klar, dass sich die Änderung nur auf den Editor bezogen hatte.
Ich hatte da noch im Ohr, dass wir das auch hernehmen wollten um z.B. eine abgebrochene Verbindung anzuzeigen u.ä.

Stimmt schon, das fände ich schön (auch als eine Art Growl-Notification, wo man ein noch nicht existierendes Widget bestimmte Infos zeitlich begrenzt einblenden lässt - jeder mit HS kennt das Problem: ein Popup steht auf einer von mehreren Visus die man seit Tagen nicht angeschaut hat und man muss es wegklicken obwohl die Papiertonne vor 3 Tagen war..)
Gegeben folgendes: könnte man dann das jQ-UI-CSS natürlich auf das verwendete ausdünnen. aber wiegesagt, 6kB on wire..naja.. (das jQ-UI js ist aktuell dafür nicht verwendet/notwendig!)

Man kann sicher ein paar Dinge vereinheitlichen. Aber die ganze Struktur der Darstellung liegt im CSS, d.h. eine "Eigenstrick-CSS" wird es zwingend immer geben.

Ok, das kann ich ehrlichgesagt nicht beurteilen aber der Laie findet jQ-UI schön, weils schon dutzende Styles (designs,flavours, oder wie auch immer man es nennt) fertig gibt.
Sollte sich der Laie irren, zumindest sowas wie Statusbar-boxen muss man nicht nochmal im CSS malen und es erschiene mir praktisch wenn man dafür eben sich einfach sein jQ-ui design aussuchen kann.

Ist ja gut, das hab ich schon in meinen ToDos.

Sollte ja nicht negativ pushen aber das sehe ich eben so Vielleicht wäre o.g. Write-only Flag zumindest eine einfach handhabbare Zwischenlösung ? Ich denke viele (die KNX verstanden haben) haben das eh so mit sep. KO's für Schalten/Dimmwert/Statusrückmeldung z.B. beim Dimmer, Rolladen etc.
(zugegeben: das hat bei mir aber auch gedauert, das zu verinnerlichen! deswegen das Beispiel mit 1h Dimmzeit, so richtig kapiert man das erst wenn man die Dinger auf der Visu hat..)
Ich dachte an etwas globales im update/senden jeglichen Wertes, dies grundsätzlich zu blocken wenn einfach nicht gedrückt wurde. In der /oldvisu ist das ja ziemlich kompliziert gemacht..

Ich wusste gar nicht, das das Siemens-Teil da zu zickt. Mein ABB macht da was ich erwarte...

OT/egal, aber das N141/01 sendet bei Ansteuerung der einzelenen EVG's (in 16 Gruppen schon!) keinen Dimmwert-/Schaltstatus pro EVG sondern alle zusammen in einem obskuren Format (ist ein 3-Zeiler aber..)

Makki

[Chris M.]

Zitat MDT:
"Bei der Übertragung der Funktion "Heller/Dunkler" wird ein 4Bt Telegramm geschick und es ist von KNX eine vordefinierte Größe für Dimmfunktion. Deshalb vermute ich, dass die Visualisierung diese Werte auch auslesen kann."

Die Visu kann mit den 4 Bit Dingern ziemlich wenig anfangen, denn die sagen ja nur wie relativ gedimmt werden soll. Die Visu braucht zum Anzeigen aber einen absoluten Wert.
(Was natürlich geht, ist die 4 Bit GAs auf den Trigger oder der Multitrigger zu legen und die Werte zu versenden - aber wie soll man die vernünftig anzeigen?)

b) Bandbreite: bin ich echt immer dabei, ich hab sogar die rrdfetch nach 2h Performance-Analyse mit 6 Endgeräten gezippt -> Aber bitte nicht beim Editor, IMHO ziemlich sekundär..

OK, mir war nicht klar, dass sich die Änderung nur auf den Editor bezogen hatte.
Ich hatte da noch im Ohr, dass wir das auch hernehmen wollten um z.B. eine abgebrochene Verbindung anzuzeigen u.ä.

a) eigene Designs
Ehrlich, viel weniger optimal finde ich nach dem ganzen hacken heute, das eher Eigenstrick-CSS und nicht jQuery-UI verwendet wird. Das gibts schon x-hundertfach fertig, warum nochmal neu erfinden?

Man kann sicher ein paar Dinge vereinheitlichen. Aber die ganze Struktur der Darstellung liegt im CSS, d.h. eine "Eigenstrick-CSS" wird es zwingend immer geben.

Der einzige Vorteil am jQ-UI.CSS ist der Design-Editor von deren Homepage.

Nochmal, IMHO sollte die Visu niemals irgendetwas senden, wenn nicht auf dieser Visu gedrückt wurde.

Ist ja gut, das hab ich schon in meinen ToDos.
(Lustiger Effekt bei mir: in der Früh fahren wir den Rollladen bisschen hoch, so in Lüftungsstellung. Wenn dann der erste in den Flur geht, geht dort per PM die Visu an - die sieht die Rollladenposition und will die auf den darstellbaren Wert ändern => der Rollladen zuckt etwas...)

Naja, Du kennst die DALI-GW's selber, es geht was geht und die einzelne Status-Rückmeldung beim N141/01 (/02 geht so) ist schon ein selbergestrickter HS-Baustein (ginge natürlich auch mitm WG, ich hab des HS-BS geschrieben )

Ich wusste gar nicht, das das Siemens-Teil da zu zickt. Mein ABB macht da was ich erwarte...