CometVisu - (interner) Beta-Test

[swiss]

Bei mir nicht Kommt aber stark darauf an was du auskommentieren willst. bzw. wo! Auskommentieren ist nicht überall im xml erlaubt. Desshalb steht dass auch nicht in der Doku.

[daviid]

Die Idee is mir auch schon gekommen, aber dann blieb die CV einfach beim "Loading ..." hängen, aber ich probiers nochmal ...

[swiss]

ömm

Wie wärs z.B. mit <!-- und -->?

Also z.B.

 <!-- <mapping name="OpenClose">
        <entry value="0">zu</entry>
        <entry value="1">offen</entry>
      </mapping> -->

[daviid]

Was mir grad aufgefallen ist, gibt es keien Möglichkeit in der config.xml etwas auszukommentieren?

[swiss]

... (außer den Konfigs bei den Beta-Testern...)

Die sind egal Wir sind hart im nemen. Dafür sind wir ja auch noch im internen BETA Test.

OK...

Wenn ein einfaches umbenennen ausreicht, wäre das in meinen Augen doch sinnvoll. Es macht die Konfiguration etwas verständlicher. Wenn der Vorschlag für das umbenennen angenommen würde, werde ich dass natürlich in der Doku auch noch ändern.

[makki]

Nur zur Klarstellung: Ich bin nicht dafür es nochmal umzubenennen, das war eher als erklärende Anmerkung gedacht (das absolut/relativ hat mich tagelang gefuchst, so bin ich halt, nicht weiter wichtig..)
-> Es ist jetzt so, fertig.. (müsste ich meine Russound-Steuerung dann zum 5. mal komplett umstellen, auch wenns mittlerweile ausm Script fällt..)
-> Es ist jetzt so dokumentiert, bitte keinen verwirren, so alt bin ich auch noch nicht, das nicht adaptieren zu können

Ich bin nur dafür, eben einen Default-Wertversand beim infotrigger mit leerem variant zu machen.

Makki

[Chris M.]

Bei den änderungen würden es sich ja nicht nur um ein simples umbenennen handeln.

Ein einfaches Umbenennen sollte reichen, daher sehe ich auch keine problematischen Querwirkungen (außer den Konfigs bei den Beta-Testern...)

[swiss]

Von mir aus muss dass nicht unbedingt angepasst werden. Ist ja glaube ich auch gut beschrieben in der Doku.

Bei den änderungen würden es sich ja nicht nur um ein simples umbenennen handeln. Vor allem weil sonst warscheinlich das Widget so umgebaut werden müsste, dass die beiden "variant" fix und unabhängig von change sind.

Momentan wird je nach Einstellung für die Schaltflächen einmal relative und einmal absolute verwendet. Danach wäre es immer z.B. switch. Geht dass ohne grossen Aufwand?

[Chris M.]

Was aber tatsächlich nicht optimal ist, ist dass die auch "relative" und 2absolute" heißen. Wahrscheinlich würde ich die nun "switch" und "display" nennen...

Womit auch geklärt wäre, warum ich die initial genau andersrum benannt habe: ist eine Frage der Sichtweise: absoluter Wertversand (jetzt absolute) kann man auch als relative Wertänderung betrachten
Auch egal, der AW muss es kapieren und das steht ja jetzt schön in der Doku.

Wer ist noch dafür hier die Bezeichnung zu ändern (SVN ist ja frozen, daher Änderung nur nach Abstimmung...)?

Ein neues Release ist ja gleich gemacht und wir wären etwas mehr Poka Yoke...

[makki]

Vorab: Wenn was am Verhalten der config geändert wird, dann müssen wir das jetzt, vor der 0.6.0 machen.

Nein, an der config wird&soll es nichts ändern, nur wenn die config sagt variant="" sollte es IMHO nen sinvollen default geben.

Was aber tatsächlich nicht optimal ist, ist dass die auch "relative" und 2absolute" heißen. Wahrscheinlich würde ich die nun "switch" und "display" nennen...

Womit auch geklärt wäre, warum ich die initial genau andersrum benannt habe: ist eine Frage der Sichtweise: absoluter Wertversand (jetzt absolute) kann man auch als relative Wertänderung betrachten
Auch egal, der AW muss es kapieren und das steht ja jetzt schön in der Doku.

Meine Vermutung:

Es sind - wie so oft - mindestens 2 Ursachen. Aber bevor ich Vermutungen in den Raum stelle -> lieber erstmal die Detailanalyse machen (die TTF sind zwar definitiv Teil des Problems, nur sollten die ja trotzdem gecached werden.. meine Baustelle..)
Wenn dem so ist wie ich denke, klar ist es im 100MBit LAN total egal, sollte man zumindest eben darauf hinweisen..

Makki

[Chris M.]

Hab ich vielleicht unverständlich geschrieben, aber genau das gemeint: bei relative fällt mir kein Anwendungsfall ein, wo man jemals den Wert der "sendenden GA" zur Anzeige bringen wollen wird! Ergo ists obsolet:
-> bei absolute ists klar (da muss man den variant nicht angeben, sonst hätten bei mir beide Fälle gestern nicht funktioniert..)
-> bei relative ist die Sache für mich auch klar(*): Default ist: nur anzeigen der hörenden (readonly) GA's.
*Vielleicht hab ich heute zuviel "reine KNX-Lehre" gefrühstückt, aber für mich gibts immer eine Schalt- und eine Status-GA (sei es nun Lautstärke, Rolladen oder Dimmwert), würde mich auch bereiterklären es (post 0.6 natürlich) zu ändern; wer Spass dran hat kann den variant ja dann trotzdem anders eingeben aber default sollte man IMHO nicht müssen..

Vorab: Wenn was am Verhalten der config geändert wird, dann müssen wir das jetzt, vor der 0.6.0 machen.

Du brauchst aber den Variant eben um zwischen "Schalt-GA" (-> variant="relative") und "Status-GA" (-> variant="absolute") zu unterscheiden. Ich wüsste auch nicht, wie das anders gehen soll.
Was aber tatsächlich nicht optimal ist, ist dass die auch "relative" und 2absolute" heißen. Wahrscheinlich würde ich die nun "switch" und "display" nennen...

[Designtoggle]
-> Ich will aber jedenfalls möglichst noch rausfinden - deadline morgen - woran es liegt und damit ob sich das mit vertretbarem Aufwand abstellen lässt..

Meine Vermutung: das Einbinden der Schriftart bei Alaska. Die muss sich erst durch die Leitung quälen...

Das ist übrigens der Grund, warum ich beim Pure ganz bewusst auf eine Schriftart gesetzt habe, die nach allgemeinem Verständnis auf den meisten Endgeräten per Default ist...
Dennoch finde ich es gut, wenn Alaska seine eigene Schriftart nutzt - denn es gibt genug Anwendungen wo die paar Millisekunden (im lokalen Netz) schnurz sind. Und im Zweifel nutzt man halt Alaska an der Wand und Pure auf dem Smartphone.

[makki]

.. denn sonst kann das Widget nicht unterscheiden, ob die Adresse für den Status oder für die Buttons ist.

Hab ich vielleicht unverständlich geschrieben, aber genau das gemeint: bei relative fällt mir kein Anwendungsfall ein, wo man jemals den Wert der "sendenden GA" zur Anzeige bringen wollen wird! Ergo ists obsolet:
-> bei absolute ists klar (da muss man den variant nicht angeben, sonst hätten bei mir beide Fälle gestern nicht funktioniert..)
-> bei relative ist die Sache für mich auch klar(*): Default ist: nur anzeigen der hörenden (readonly) GA's.
*Vielleicht hab ich heute zuviel "reine KNX-Lehre" gefrühstückt, aber für mich gibts immer eine Schalt- und eine Status-GA (sei es nun Lautstärke, Rolladen oder Dimmwert), würde mich auch bereiterklären es (post 0.6 natürlich) zu ändern; wer Spass dran hat kann den variant ja dann trotzdem anders eingeben aber default sollte man IMHO nicht müssen..

Keine Ahnung was und wo's klemmt. Aber Designtoggle ist kein Feature..

Ich auch noch nicht so genau und Sonnenklar: es ist blödsinn sich in den Flur zu stellen und Designtoggle zu drücken.
Aber es sieht halt blöd aus. Ich sags nur ungern, aber hier gehts rein um die Leute aus der Marketingsabteilung
Der erste Kontakt mit der CV wird regelmässig u.a. mit dem (coolen!) Designtoggle stattfinden und der sollte halt genauso ratz-fatz sein wie später im echten Leben damit; nötigenfalls ehrlichgesagt auch gerne halb-gefaked..
-> Ich will aber jedenfalls möglichst noch rausfinden - deadline morgen - woran es liegt und damit ob sich das mit vertretbarem Aufwand abstellen lässt..

Makki

[Chris M.]

-> variant="relative" fehlte bei der GA

Finde ich aber mindestens "deutlich unschön" das man den da händisch reintipsen soll; das ist doch doppelt gemoppelt/ging vorher auch ohne(?)
Man wird bei relative (z.B. 0/1 für lauter/leiser, hoch/runter, ...) ja eh niemals den zuletzt gesendeten Wert zur Anzeige bringen wollen sondern den Status, also kann man das "relative" doch auch einfach vom widget übernehmen odrr?

Siehe Tabelle unter: SourceForge.net: CometVisu/infotrigger (Deutsch) - Open Automation

Das variant="relative" kann man im relativen Modus nicht weg lassen, denn sonst kann das Widget nicht unterscheiden, ob die Adresse für den Status oder für die Buttons ist.
(Genauer, entweder variant="relative" oder variant="absolute" kann man weg lassen, müsste noch mal im Code nachlesen welches, aber das sorgt für noch mehr Verwirrung. Daher die dringende Empfehlung im change="relative" Modus immer die Variant mit angeben!)

P.S.: Packerl folgt, ich will aber vorher noch etwas rausfinden, das mir Micha (vento) gestern zeigte und das via GPRS (Kemmern halt..) auch deutlich nachvollziehbar war: beim switchen der Designs mit wird (bisher nur eine Vermutung, scheint ne Webkit-spezifische Sache zu sein) trotz cache usw. was nachgeladen, das gefühlt ewig dauert..
Ich bau mir jetzt zum generellen testen solch widriger Umstände mal ein Wlan mit Traffic-shaping auf 56kps

Keine Ahnung was und wo's klemmt. Aber Designtoggle ist kein Feature der CometVisu (sondern ein Hack für die Widget Demo) und daher für mich kein relevanter Anwendungsfall.
Oder wie oft steht einer vor der Visu und Toggelt die Designs durch, weil ihm Langweilig ist oder gerade die Wand anders gestrichen wurde...

[makki]

infotrigger

Die Config-Änderung ist nicht abwärtskompatibel. Daher mal bitte gegen die aktuelle Syntax prüfen.

Nee, den Fehler hab ich gemacht: den source nicht gelesen
-> variant="relative" fehlte bei der GA

Finde ich aber mindestens "deutlich unschön" das man den da händisch reintipsen soll; das ist doch doppelt gemoppelt/ging vorher auch ohne(?)
Man wird bei relative (z.B. 0/1 für lauter/leiser, hoch/runter, ...) ja eh niemals den zuletzt gesendeten Wert zur Anzeige bringen wollen sondern den Status, also kann man das "relative" doch auch einfach vom widget übernehmen odrr?

Makki

P.S.: Packerl folgt, ich will aber vorher noch etwas rausfinden, das mir Micha (vento) gestern zeigte und das via GPRS (Kemmern halt..) auch deutlich nachvollziehbar war: beim switchen der Designs mit wird (bisher nur eine Vermutung, scheint ne Webkit-spezifische Sache zu sein) trotz cache usw. was nachgeladen, das gefühlt ewig dauert..
Ich bau mir jetzt zum generellen testen solch widriger Umstände mal ein Wlan mit Traffic-shaping auf 56kps

[Chris M.]

Release 0.6.0-RC4

Jetzt ist's ernst: Relase 0.6.0-RC4 ist hochgeladen!

Das heißt für uns Entwickler: das SVN(*) ist eingefroren. Bitte keine Check-Ins ohne vorherige Diskussion!

Das heißt für alle (Beta-)Tester: bitte noch mal alles testen.
Entweder jetzt schon das Paket oder das hoffentlich bald von Makki erzeuge Debian-Paket. Wer SVN nutzt, kann natürlich jetzt schon updaten.

Die -RC3 habe ich übrigens quasi übersprungen, da kaum dass die im SVN angekommen war, ich noch gemerkt hatte, dass die XSD veraltet war

--
(*) Natürlich nur der CV trunk