CometVisu - (interner) Beta-Test

[makki]

Keine Ahnung - ich hab's mir noch nicht angesehen

Ich habe mir Mühe gegeben und auch getestet, aber die unbekanntenn Seitenwirkungen sind->?

Das ganze jQuery-UI CSS finde ich ungeschickt. Mal vom unnötigen Speicherplatz (= Bandbreite) abgesehen, ist das nicht wirklich optimal, wenn man eigene Designs erstellen will - denn was von dem ganzen Schmodder muss man nun anfassen? Was kann man lassen?

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.. Klar, es soll keine Minuten dauern aber hier ja absolut nicht der Fall.. Wir reden von 33kB die der Webserver eh (Default wird alles gzipped) auf 6 kB eindampft. Da wirds echt esotherisch in Zeiten von ADSL, VDSL und UMTS oder LTE, gegen sinnlose Verschwendung aber..
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?

(draufgekommen bin ich nur, weil in ähnlichem hatte ich jQuery-UI.js+CSS nach Qucikstart-Guide eingebunden und mich dann gewundert warum die Notifications/Statusbar im Editor so hässlich aussah)
Hey, das interessiert mich doch nicht, warum es cool aussieht, wenn es cool aussieht! (und es nicht die Welt kostet)

Auch die bestehenden CSS sind da schon ziemlich unübersichtlich. Eigentlich müsste man da mal drüberfräsen und die Elemente identifizieren, die entscheidend sind...

Wenn man da das fräsen anfängt, dann bitte auf ein verbreitetes UI-Framework migrieren (jQuery-UI, qooxdoo)..
Halte ich ehrlichgesagt für am zielführendsten, gutes verwenden, ggfs. ergänzen, bitte nicht neu erfinden.

Passen die DPT bei Dir? Sind die alle gleich? Und sind manche GAs ggf. nicht read-only?
Das könnte so ein Verhalten verursachen...

die DPT's sollten passen, mit diesen GAs mache ich seit Jahren meine tests Eine ist schreibend (dimmwert setzen), eine ist feedback, RO (Dimmwert-Status); reine KNX Lehre glaube ich..

Zur Zeit sind die Slider noch so, dass die einen KNX Wert empfangen, den anzeigen, so gut die können, und sollte ihr bester Versuch einen anderen KNX-Wert entsprechen, diesen versenden (damit Anzeige zum Wert passt).

Nochmal, IMHO sollte die Visu niemals irgendetwas senden, wenn nicht auf dieser Visu gedrückt wurde.
Beispiel: Ich schalte am B.IQ das Terassenlicht ein. Dimmzeit 60sek. Status-Rückmeldunng ist 5.10,15,20% usw. -> am Ende waren aber 100% (oder was auch immer) gefragt, nicht das irgendeine Visu anhand des Statustelegramms von 5% dann den Sollwert auf 5% zurücksetzt
So vermute ich, flickert mein Slider böse rum.. Aber ich schau mir das am Mo nochmal im Detail an.. (morgen ist Kommunion der Grossnichte, super,

Du musst dem Gateway irgendwie beibringen, dass es bei Wert-Änderung den neuen absoluten Ist-Wert verschickt

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 )

Das Problem ist dabei, dass die Visu nicht weiß, dass der Wert sich geändert hat...

Schon, aber lieber zeigt die Visu IMHO ggfs. bei Fehlkonfiguration einen falschen Ist-Wert an, als ungefragt einen falschen Ist-Wert zu versenden
Ersteres ist unschön in der Visu, zweiteres ein reales WAF-desaster weil ein Licht nicht so angeht wie es wollte

Makki

P.S./Edit: genau dieses Thema hatten wir übrigens bei der /oldvisu auch schonmal (das die Visu niemals etwas senden darf, nachdem sie nicht gefragt wurde) und auch gelöst (MA, nicht ich), wenn man diese Ansicht allgemein teilt, wirds auch nochmal implementiert

[renzge]

Am Bild im Anhang ist zu sehen was der Busmonitor aufzeichnet.

Dem Dali-GW hab ich schon begebracht auf realive und absolute Dimmwerte zu reagieren.

Aber die Visu erkennt die relativen nicht.

Im Dali-GW gibt es drei Positionen pro EVG.
1: Ein/Aus (2/1/1)
2: Heller/Dunkler (2/1/101)
3: 8-Bit (2/1/102)

ich habe jetzt einen Taster angesteuert betreffend (2/1/1) für Ein/Aus (Tastendruck kurz)
bzw. Dimmen +/- (2/1/101) (Tastendruck lang)

von der Visu aus kommt ein 8-Bit Befehl auf 2/1/102

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."

[Chris M.]

ich hoffe ich hab nix kaputtgemacht

Keine Ahnung - ich hab's mir noch nicht angesehen

(das komplette jQuery-UI CSS müsste sicher nicht sein aber statt rausfriemlen nimmt man sowas komplett denke ich)

Das ganze jQuery-UI CSS finde ich ungeschickt. Mal vom unnötigen Speicherplatz (= Bandbreite) abgesehen, ist das nicht wirklich optimal, wenn man eigene Designs erstellen will - denn was von dem ganzen Schmodder muss man nun anfassen? Was kann man lassen?

Auch die bestehenden CSS sind da schon ziemlich unübersichtlich. Eigentlich müsste man da mal drüberfräsen und die Elemente identifizieren, die entscheidend sind...

Was tun? Ich bin da gar unschlüssig..:

Da habe ich leider die Fragestellung zu den möglichen Antworten schon nicht verstanden...

Andere Sache: meine Slider zappeln schon wieder fürchterlich, ich *glaube* das ist neu und ich fühle mich unschuldig..

Passen die DPT bei Dir? Sind die alle gleich? Und sind manche GAs ggf. nicht read-only?
Das könnte so ein Verhalten verursachen...

Zur Zeit sind die Slider noch so, dass die einen KNX Wert empfangen, den anzeigen, so gut die können, und sollte ihr bester Versuch einen anderen KNX-Wert entsprechen, diesen versenden (damit Anzeige zum Wert passt).
Da aber eine 100% Umrechnung von KNX-Wert zu Slider-Position nicht immer möglich ist, kann es da zu komischen Effekten kommen.
(Das muss ich mal ändern...)

aber vielleicht kann mir schnell einer eine Lösung zu meinem Problem sagen.
[...]
Funkt auch - aber es werden nicht die aktuellen Werte vom Taster übernommen.

Du musst dem Gateway irgendwie beibringen, dass es bei Wert-Änderung den neuen absoluten Ist-Wert verschickt

Es muss doch eine Möglichkeit geben dass die Visu den aktuellen Wert auslesen kann.

Das Problem ist dabei, dass die Visu nicht weiß, dass der Wert sich geändert hat...

[renzge]

Wo ich gerade vom Slider lese,
tut zwar nix zum aktuell interessanten Thema aber vielleicht kann mir schnell einer eine Lösung zu meinem Problem sagen.

Vorhanden:
Taster von MDT (sendet 4bit für "Heller/Dunkler")
funktioniert auch mit Dali GW Siemens N141/02 und Leuchtmittel wird brav heller und dunkler.

Aber in der Visu habe ich eine weitere Adresse angelegt die dem Dali-GW einen 8bit-Wert schickt (0-100 in 10% Schritten)
Funkt auch - aber es werden nicht die aktuellen Werte vom Taster übernommen.

Es muss doch eine Möglichkeit geben dass die Visu den aktuellen Wert auslesen kann.

Verstehe schon dass "Dimm UP oder DOWN" nur Prozentveränderungen sind und keine absoluten Werte, aber wie kann ich Taster und Visu vereinen?

[makki]

Andere Sache: meine Slider zappeln schon wieder fürchterlich, ich *glaube* das ist neu und ich fühle mich unschuldig..

Szenario: Slider, 1 Dimmwert-GA, 1 Rückmelde-GA (readonly) -> es wird ständig geschrieben (damit ständig gelesen), zwar eine gute Performance-Demo aber...
Falls kein Einzelschicksal mach ich nen Bug auf und falls nicht nachvollziehbar: in der Demo /visu-svn "Terasse Spots Dimmwert" und Terasse Spots Dimmwert Status" mal hinzufügen (ich hab aktuell die Rückmelde-GA rausgenommen weil das fürchterlich knattert..)

Makki

P.S.: Das ist übrigens wirklich das Licht auf der Terasse, wenn so wie vorgestern jemand Nachmittag um 2 einschaltet darf ers auch nach dem testen gerne wieder ausmachen

[makki]

Erster Teil wurde vorhin commited (jnotify-Statusbar statt alert, ich finds erheblich weniger "intrusiv"); ich hoffe ich hab nix kaputtgemacht
Geht sicherlich eleganter und schöner (das komplette jQuery-UI CSS müsste sicher nicht sein aber statt rausfriemlen nimmt man sowas komplett denke ich)

Ein Teil des RRD-holens war auch schon mit drin, das was man unabhängig eh braucht. Der Rest hab ich nicht commited, weil halb unfertig und gedanklich auch nicht ganz durch..
Was tun? Ich bin da gar unschlüssig..:

1a) Ein weiteres Attribut zu address. So hab ichs jetzt angefangen weil erscheint mir auch am sinnigsten.
Im Endeffekt geht es um GA+RRD die meist eh "zusammengehören"; ich stelle mir wiegesagt sowieso als zusätzliches info_diagram -Widget eine (oder mehrere) Wertanzeige + Diagramm-popup bei klick vor.
address/address transform sollten dann aber nicht mehr mandatory sein bzw. weiterhin möglich das preview statt dem (KNX-) Wert anzuzeigen. Weil es könnte ja auch die USV sein..
Gedanklich passt das aber garnicht zum ursprünglichen Sinn von multi-address, ist mir auch klar (ist ja primär für hörende GA's)

1b) Ein "klon" von address, address_rrd, selbiger multiedit ?

-> Das knickt natürlich die aktuelle config beides komplett, gehe aber davon aus das mehrere rrd= Attribute im jetzigen diagram_* eh nicht so richtig erlaubt sind.
-> Hat aber den Vorteil das es vermutlich sauberer ist und man auch noch weitere Attribute/Wert einfach hinzufügen kann. (Farben der Linien; gehört zwar vermutlich wieder eher ins CSS aber..)

2a) wäre mehrere rrd-Attribute, gehen tuts aber ist das "gut"?


Zum Rest halte ich mich Meinungsfrei, bin froh da durchgestiegen zu sein (wenn die 2h nicht wären, bis man mal drin ist.. hoffte da heute eigentlich weiterzukommen aber..)

Makki

[JNK]

Wird uns auf absehbare Zeit ein Attribut reichen?

Ich schätze ja. Dann würde ich das einfach "type", "variant" o.ä. nennen ("option" finde ich nicht so gut, da es hier ja keine Option der Adresse ist, sondern deren Art festlegt)

Da würde ich für "variant" plädieren, weil du "type" ja schon für "text", "2d" und "3d" verwenden willst. Auch wenn das nicht direkt kollidiert, fände ich der Übersicht wegen verschiedene Begriffe besser.

[Chris M.]

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".

Die Idee mag ich - grundsätzlich. Was zu klären wäre, ist dass hier die Datenstruktur sauber bleibt, d.h. dass nicht mehrere Informationen gleichzeitig in dieses Universal-Attribut geschrieben werden. (Nach Datenbank-Theorie ganz böse...)

Wird uns auf absehbare Zeit ein Attribut reichen?

Ich schätze ja. Dann würde ich das einfach "type", "variant" o.ä. nennen ("option" finde ich nicht so gut, da es hier ja keine Option der Adresse ist, sondern deren Art festlegt)

[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

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

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

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]

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

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

[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,ä...