CometVisu - (interner) Beta-Test

[makki]

Ah ok, dann steht das ggfs. auch auf meiner Wunschliste (? ich hab mir den multitrigger ehrlichgesagt noch nicht im Detail angesehen ?)
Weil meine Visu ist seit geraumer Zeit so ein fliessender Meshup aus HSAV&CV Und das Rolladen-Thema ist noch links aber die CV gewinnt an Boden, mühsam ernährt sich das Eichhörnchen

Makki

[Chris M.]

Was ich mir nun wünschen würde, ein Element in der Visu ähnlich dem Multitrigger, das mit den zwei Verschiedenen GAs umgehen kann, so dass auf, ab und stopp in einem Element untergbracht sind.

Das ist ein bekanntes Thema, das hatten wir schon mal...

Mehrere GAs pro Widget widersprechen eigentlich dem Design, dass sich an KNX-Tastern anlegt (1 Taste = 1 GA/Paket das versendet wird).
Das mit kurzem und langen Tastendruck sinbd aus KNX-Sicht nämlich eigentlich zwei verschiedene Tasten...
(Es wäre auch was anderes realisierbar, wie der ColorChooser zeigt, der an 3 GAs senden können muss, aber das ist halt die Ausnahme zur Regel...)

Wenn Du nun explizit Auf/Stopp/Ab als Tasten haben möchtest dann wäre der der CometVisu-Textmodus-Weg einfach drei einzelne Trigger zu machen und die in eine Group zu hängen.
(IM zukünftigen 2D und 3D Modus ist's genau so, nur dass die Widgets dann frei positionierbar sind und diese Beschränkung daher nicht mehr auffallen wird)

Was ich bei Rollläden aber bei mir durchgänig nutze ist ein Slider, der einfach per Prozent sagt, wo der Rollladen hin soll.

(Und bei der Markise mit getrennt ansteuerbaren Volant hab ich einfach diese vier Elemente untereinander bzw. nebeneinander gehängt)

Ah ok, dann steht das ggfs. auch auf meiner Wunschliste (? ich hab mir den multitrigger ehrlichgesagt noch nicht im Detail angesehen ?)

Ein Multitrigger ist im Grunde ein Szenen-Abruf-Widget oder ein RTR-Modus-Umschalt-Widget. Du hast bis zu 4 Trigger, die an die selbe GA jeweils einen eigenen Wert senden.

[panzaeron]

Ah ok, dann steht das ggfs. auch auf meiner Wunschliste

und es steht auf meiner Wunschliste Ich wollte das schon selbst als Plugin realisieren, aber die sind nicht so einfach wie ich dachte...

[greentux]

Mehrere GAs pro Widget widersprechen eigentlich dem Design, dass sich an KNX-Tastern anlegt (1 Taste = 1 GA/Paket das versendet wird).
Das mit kurzem und langen Tastendruck sinbd aus KNX-Sicht nämlich eigentlich zwei verschiedene Tasten...

Das ist vermutlich auch richtig. Dann müsste man am Design was ändern, um einige Widgets noch enger gruppieren zu können. Gruppen von Gruppen oder sowas. Am Taster sind einige Tasten ja auch sehr eng beieinander .

Vermutlich lisse sich damit auch der FR lösen, zwei Anzeigen (Temp, Feuchte) in einem Widget anzeigen zu wollen...

[ctr]

Könnte mir jemand mal bezüglich Stylings etwas auf die Sprünge helfen? Ich habe jetzt schon die css gewälzt und den rekursiven grep gequält, aber schlauer bin ich nicht geworden.
Laut Doku wird mit Styling ein CSS Block angesprochen. Aber wo ist der definiert? Benutze ich das Beispiel mit 0/1 Red/green funktioniert alles, aber schon ein simples "blue" geht nicht mehr, obwohl z.B. designs/discreet_slim/basic.css sehr wohl Definitionen für blue hat (wie auch red und green).

Beim browsen durch den Code ist mir aufgefallen (lib/templateengine.js) das stylings anscheinend auch ranges kennt. Wie es denn dafür die Syntax?
Würde mir gern in einem Info-Element die Raumtemperatur anzeigen lassen und sie entsprechend blau (zu kalt) / grün (alles i.O.) / rot (zu warm) hinterlegen...

[ctr]

Weiß wirklich niemand Bescheid worauf das Styling Attribut zurückgreift?

[netzkind]

Das Styling-Attribut sorgt dafür, dass das Element im entsprechenden Fall eine CSS-Klasse verpasst bekommt, die dem Namen des Stylings entspricht (in deinem Fall "red", "green", "blue").

Das Problem ist, dass das Design discreet* keine echte Formatierung für was anderes als red und green hat - für die beiden wird ein buntes PNG als Hintergrundbild eingebunden. Bei blue, purple, etc. wird zwar laut CSS die Textfarbe geändert, aber bspw. bei Buttons wird die immer mit weiß (o.ä.) überschrieben. Effektiv sieht man da also keine Änderung.

Was man tun müsste, ist die Hintergrundgrafik von red, green (designs/discreet_slim/images/dot_red.png) für blue, purple umbauen, das CSS für .blue, .purple anpassen, und fertig.

Das zumindest gilt so für die Buttons in den discreet-Designs.

Grüße,
Julian

[netzkind]

Nachdem ich deine Frage noch mal gelesen hab, hab ich auch gemerkt dass meine Antwort nicht dazu passte. Sorry.

Also:
ich habs hier ausprobiert, und bei mir läuft es:

    <stylings>
        <styling name="bla">
        <entry range_min="10" range_max="20">blue</entry>
        <entry range_min="20" range_max="25">purple</entry>
        </styling>
    </stylings>
  </meta>
  <page name="Overview">
    <info styling="bla">
    <label>test</label>
    <address transform="DPT:9.001" type="">7/6/0</address>
    </info>
  </page>

Das zeigt bei mir derzeit 14.93 in blau an. Design ist "discreet_slim".
Bei Temperaturen lohnt es sich mir ranges statt mit values bei den Stylings zu arbeiten - siehe mein Beispiel-Code?

Grüße,
Julian

[ctr]

Also das mit den Ranges macht so selbstverständlich Sinn, danke für das Beispiel, das werde ich am WE gleich mal in alle Wikis/Dokus etc einpflegen die nicht rechtzeitig auf dem Baum sind ;-)

Die erste Antwort trifft schon eher den Kern meiner eigentlichen Verwirrung:
Ich habe sowohl mit alaska_slim als auch discreet_slim getestet und bei einem Textfeld (!) klappt die Zuweisung der Textfarbe mit Styling wunderbar, aber eben nur für red und green und nichts anderes.
Nun finde ich aber nicht die Stelle an der das in einem CSS definiert ist (bzw an der Stelle an der ich denke das es definiert wird, wird gleichzeitig auch blue usw. definiert und die gehen NICHT)...

Davon abgesehen würde es eventuell Sinn machen für solche (und eventuell auch andere Zwecke?) eine globale/Designübergreifende Include-Datei mit CSS Definitionen zu haben. Wenn man darüber auch Grafiken einbinden kann (das sollte doch mit CSS "background-image" gehen?) käme ich meinem Ziel von dynamischen Icons ja auch etwas näher :-)

[Chris M.]

Juhu! Das ist Post 1000 in diesem Thread!

[Chris M.]

Julian hat's schon gut beschrieben

Davon abgesehen würde es eventuell Sinn machen für solche (und eventuell auch andere Zwecke?) eine globale/Designübergreifende Include-Datei mit CSS Definitionen zu haben.

Nein, das macht leider keinen Sinn, da jedes Design diese Farben anders umsetzen kann. Eines würde z.B. die Schriftfarbe anpassen, das andere den Hintergrund.

Was aber Sinn macht, wäre ein paar Farbnamen zu definieren die jedes Design implementieren sollte.

Wie wäre es mit:

• Rot
• Grün
• Blau
• Gelb
• Cyan
• Magenta

[ctr]

ja man könnte doch aber auch mit anderen variablen arbeiten, dann kann es immernoch jedes Design anders umsetzen (oder auch nicht wenn es paßt, was den Arbeitsaufwand erheblich reduzieren sollte).
Geht es nicht eventuell sogar mit Prioritäten? Wie verhält sich ein Include wenn eine Variable aus zwei verschiedenen CSS herkommt? Wird die erste, letzte oder irgendeine Definition benutzt?

Mir geht es dabei (der globalen Variante) gar nicht so sehr um die Farben sondern um z.B. Icons aber auch darum gleiche (Mindest-)Vorraussetzungen in allen Designs zu haben.

Edit: Jetzt gehts komischerweise auch mit blue, hing wahrscheinlich noch was im Cache...

[netzkind]

ja man könnte doch aber auch mit anderen variablen arbeiten, dann kann es immernoch jedes Design anders umsetzen (oder auch nicht wenn es paßt, was den Arbeitsaufwand erheblich reduzieren sollte).
Geht es nicht eventuell sogar mit Prioritäten? Wie verhält sich ein Include wenn eine Variable aus zwei verschiedenen CSS herkommt? Wird die erste, letzte oder irgendeine Definition benutzt?

Könnte man, aber das scheint mir nicht zielführend:
Wer ein neues Design entwickelt, sollte die volle Kontrolle haben und sich nicht damit beschäftigen müssen, erst mal alte Definitionen zu überschreiben. Zumal es echt nervig ist, wenn sich die Dinge anders verhalten als man es definiert hat, nur weil einem ein altes System zu zwischen die Beine grätscht.

Ich bin sogar der Ansicht: wer ein neues Design entwickelt soll das bitte vollumfänglich planen, inklusive aller Elemente. Und wer ein neues Element entwickelt, sollte alle bestehenden Designs vervollständigen, oder dafür Sorge tragen dass der ursprüngliche Entwickler der Designs weiß dass er das tun sollte. Sonst haben wir bald nurnoch unvollständige Designs.

Was die Frage mit der Priorität angeht: das ist bei CSS relativ umfangreich gelöst. Die Prio wird dabei nach Genauigkeit des Selektors sowie Ort und Reihenfolge der Definitionen sortiert, kann stellenweise aber per !important überdreht werden.

Grüße,
Julian

[ctr]

Wer ein neues Design entwickelt, sollte die volle Kontrolle haben und sich nicht damit beschäftigen müssen, erst mal alte Definitionen zu überschreiben. Zumal es echt nervig ist, wenn sich die Dinge anders verhalten als man es definiert hat, nur weil einem ein altes System zu zwischen die Beine grätscht.

Ich bin sogar der Ansicht: wer ein neues Design entwickelt soll das bitte vollumfänglich planen, inklusive aller Elemente. Und wer ein neues Element entwickelt, sollte alle bestehenden Designs vervollständigen, oder dafür Sorge tragen dass der ursprüngliche Entwickler der Designs weiß dass er das tun sollte. Sonst haben wir bald nurnoch unvollständige Designs.

Dieser Ansatz hat durchaus seine Vorteile aber damit erzwingt man eine starre Maintainer-Struktur. Das mag in komplexen Umgebungen (Linux Kernel/Treiber) sehr sinnvoll sein ist aber meiner Meinung nach bei so einem Projekt kontraproduktiv, da Du damit verhinderst das jemand mal schnell einen Bugfix oder auch eine Erweiterung comitted die er bei sich selbst zu laufen hat.

Ich z.B. möchte ein Design nutzen, ich weiß noch nicht welches und ich bin gern bereit mehrere auszuprobieren und meine Änderungen (wenn ich sie denn für sinnvoll erachte) zu commiten. Ich möchte mich aber weder mit jedem einzelnen Design-Maintainer vorher absprechen müssen, noch für eine kleine Erweiterung einen kompletten Fork starten, noch Änderungen (zwangsläufig und sofort) für alle Designs (selbst) nachziehen.

Ist mein Ansatz nun naiv?

Ich denke eher man müßte nochmal genau definieren wofür ein Design überhaupt ist.
- die Optik zu definieren
- Funktionen zu ermöglich/einzuschränken
Meiner Meinung sollte es nur die Optik (eben das Design) betreffen und keine Funktionen. Wenn ich aber in der visu_config.xml eine Funktion "styling" nutze, muß ich mich doch auch darauf verlassen können, dass das im Design irgendwie Beachtung findet. *Wie* es umgesetzt wird (z.B. leichte Farbschattierungen) mag dem Design überlassen sein, aber solange es *nicht* definiert ist (z.B. bestimmte Farben) sollte es doch auf einen "sinnvollen" Default-Wert gehen und damit meine ich nicht weiß...

[greentux]

1000 Posts... Wie gehts nun weiter mit der Cometvisu?