CometVisu - (interner) Beta-Test

[swiss]

Ich finde dass weitreichende Änderungen am System am besten noch vor der öffentlichen Beta oder spätestens VOR der Stable Version gemacht werden sollten.

Momentan ist die Zahl der Nutzer die ihre Config ggf. reparieren (anpassen) müssen noch nicht sehr gross. Wenn dann erst mal der Öffentliche Betatest startet, wird warscheinlich die Zahl der Nutzer explodieren.


PS: Warscheinlich wird es ab dem öffentlichen Betatest der CometVisu ohnehin einen eigenes Support-Forum brauchen, damit die ganzen Anfragen nicht im WG bereich oder sonst wo landen.

[StefanW]

Ich wäre dafür, den Support für die CometVisu im WG-Forum zu leisten.

PS: Warscheinlich wird es ab dem öffentlichen Betatest der CometVisu ohnehin einen eigenes Support-Forum brauchen, damit die ganzen Anfragen nicht im WG bereich oder sonst wo landen.

Kann man darüber nachdenken, aber wir haben im Wiregate Forum zur Zeit gerade mal ein oder zwei neue Threads pro Woche, da kann das CometVisu Thema locker mit rein zumal eine Trennung insofern schwierig ist, da es derzeit die Referenzplattform ist und dann Fragen wie man dies nun mit eibd, 1-Wire-Sensorik. Plugins, scripts, lighthttp, fernzugang per openvpn (wir arbeiten gerade an einem neuen Client), Nutzung eines Hardware Authentikators dafür usw. kombiniert, kommen werden. Es läßt sich also schwer trennen.

In dieser Hinsicht bin ich dafür, dass der Support für die CometVisu im Wiregate Forum bleibt. Was denken die anderen darüber?

LG

Stefan

[Chris M.]

Für die CometVisu gibt's schon ein Forum und auch eine Mailingliste - stellt alles SourceForge zur Verfügung, wird aber (noch?) so gut wie nicht genutzt...

Über ein extra Forum hier hatte ich auch schon nachgedacht, aber ich denke ähnlich wie Stefan, dass man erst mal im offenen WG Forum starten kann, da das WG halt Referenzplattform ist. Die anderen Diskussionen kann man probieren auf das SF-Forum umzuleiten.
Sollte das nicht praktikabel sein, kann man immernoch mit den Admins hier sprechen und ggf. Beiträge verschieben.

[swiss]

Für die CometVisu gibt's schon ein Forum und auch eine Mailingliste - stellt alles SourceForge zur Verfügung, wird aber (noch?) so gut wie nicht genutzt...

Naja das ist für die Entwikler und versierte Anwender die selber weiter etwikeln wollen in Ordnung aber der Endanwender der mit der Programmierung wehnig am Hut hat oder haben will, für den sollte es einen in Deutsch gehaltenes Supportbereich hier im Forum geben. Ob das nun ein separater Bereich wird oder einfach im WG Bereich einfliesst ist da IMHO eigentlich egal.

[JNK]

Inzwischen haben wir ja variant.

Sollen wir das noch vor 0.6.0 "reparieren", was bestehende Configs etwas ungültig macht?
Wäre eine nicht komplett triviale Änderung - aber das später den Anwendern zuzumuten wäre wohl noch döfer...

Full Ack. Am besten jetzt. Wo wir gerade dabei sind: Ich habe mit FR 3349648, weil ich es gerade benötige, da habe ich ein "variant"-reicht-nicht Problem:

need some suggestions for further development:

I coded the multiinfo-widget. Current status: working with 1+ addresses of
same format

The displays are in the same order as the group addresses in the config
file and have to be of the same kind because only one "format", "mapping",
"styling"-identifier is used for all addresses (global to widget).

We have only one "variant" per address and there are several possibilities
to use it:

1) as "ordering code", i.e. the address with "1" is first, "2" is second
...
2) as "format code", i.e. the display uses the format specified by
"variant" of adress instead of "format" of the widget
3) as "mapping/styling/format-combi"

1) is worst regarding flexibility, e.g. temperature and humidity can not
be displayed as "21.0 °C 75 % r.h."
3) is best for flexibility but requires extensive parsing of the
"variant"-value and is not very intuitive for users because the
variant-attribute has to be hand-coded while inserting the widget with the
editor
2) seems to be the best compromise but loses the possibility to use
mappings/stylings

Pls comment

[JNK]

@Chris M.:

wir können das [multiinfo] auch hier diskutieren. Ich hab das gerade mal mit den groups probiert. Das Schachteln von groups funktioniert soweit, nur hilft es nicht, wenn das widget kleiner ist. Auch ein halb so breites widget wird trotzdem untereinander und nicht nebeneinander in einer group platziert.

Ohne Group geht das ganze, ist ziemlich trivial und lässt sich mit ein oder zwei weiteren Optionen in das bestehende info-widget einbauen ohne das bisherige zu brechen. Man bräuchte dann entweder eine Option um das Label auszublenden und die Breite durch eine zusätzliche Klasse im css zu halbieren oder eben zwei Optionen, wenn man das getrennt voneinander einstellen will.

Gruss,

der Jan

[luigi4711]

Kurze Frage:
Es gibt ja das Element Design-Toogle. Aber lässt sich per Editor auch ein anderes Design als 'pure' vorgeben? Über die Shell in der Configdatei ist klar, aber kann ich das auch irgendwie über den Web-Editor ändern, sozusagen die Eigenschaften der 'Hauptseite'!?

Falls nicht, fände ich es gut, wenn es so etwas geben würde, für DAUs. Ich würde dann auch nen Feature Request bei SF aufmachen... wollte nur vorher nachfragen, ob ich da was übersehen habe.

luigi

[netzkind]

Aber lässt sich per Editor auch ein anderes Design als 'pure' vorgeben?

Nein.
Auch wenn es auf meiner persönlichen wish list bereits steht.

Das gleiche gilt für Mappings, Stylings und welche Plugins geladen werden.
Die Footer-Leiste auch, aber die ignoriere ich einfach immer.

Grüße,
Julian

[Chris M.]

Stimmt, da würde der Editor eine extra Seite brauchen, die das alles änderbar macht.

Wichtig, aber wohl erst nach 0.6.0

[makki]

Kurze Zwischenfrage, komm kaum mit dem lesen hinterher
Ich bräuchte gerade ein Widget, so wie infotrigger aber Up/Down mit dynamischen Werten abhängig vom Istwert statt fixen (z.B. Temperatur, Volume, ...)
Befindet sich da was in Arbeit ? Sonst mah ich mal..

Makki

[Chris M.]

Kurze Zwischenfrage, komm kaum mit dem lesen hinterher

Zu viel ?

Ich bräuchte gerade ein Widget, so wie infotrigger aber Up/Down mit dynamischen Werten abhängig vom Istwert statt fixen (z.B. Temperatur, Volume, ...)
Befindet sich da was in Arbeit ? Sonst mah ich mal..

Ich hätte jetzt mit infotrigger geantwortet - aber anscheinend passt der bei Dir nicht? Wo ist da konkret das Problem?

Hab am Wochenende meine Temperatur-Eingabe endlich mal gebaut, eine ganze Seite voller Infotrigger mit +/- 0.5:

[makki]

Hmm, der infotrigger sendet doch aber nur fixe Werte (?), ich hätte lieber direkt den relativen Wert gesendet;
Beispiel
Ist: 22
ValueUp 2
-> 2x auf Up drücken sendet dann 24,26 usw.
Kann man auch mit Logik machen, klar, ist aber unlustig (Vol,Bass,Treble,Onvol,Source,... mind. 5x12 Zonen macht 60 unnötige GA's)

Makki

[JNK]

Da hast Du recht, das geht nicht. Ich verwende dafür ein Plugin.

Gruß,

der Jan

[Chris M.]

Zwei Möglichkeiten:

• Logik in der Visu: Das Widget rechnet selber (Architektur-Bruch, aber ich denke noch vertretbar)
• Logik im Plugin und senden von Relativ-Werten a la KNX-Dimmer

Bei ersterem brauchst Du ein StateSave Plugin.
Bei zweiterem ein Plugin das nicht nur den Zustand merkt, sondern auch noch rechnet.

Beides liegt als Multi-Version (d.h. viele GAs in einem Plugin) bei mir auf dem WG. D.h. schau mal remote, zum Veröffentlichen bin ich noch nicht gekommen, da bin ich gerade dran.

Für die Temperatur sitze ich gerade an der Universal-Lösung mit Multi. Außer dem Delta ist's schon ziemlich vollständig. D.h. auch hier kannst Du schon mal schaun, ein weiteres Paar Augen würde beim Debuggen helfen

[makki]

[*]Logik in der Visu: Das Widget rechnet selber (Architektur-Bruch, aber ich denke noch vertretbar)

Sollte ich vielleicht dazusagen, ich gehe in dem Fall davon aus, das das Gerät (oder eben ein Plugin oder..) sich natürlich selbst seinen Status merkt und den fein per Status-GA ausgibt bzw. dieser jederzeit am Bus lesbar ist.
Die Visu sollte sich natürlich nichts "merken" müssen sondern nur auf Basis des bekannten ist-zustands weiter-rechnen; das sollte mit gängigen Dimmern, RTR ebenso sauber sein wie eben mit Multiroom..
Und das muss jetzt hier mal endlich fertig werden.. grmpf.. Vielleicht auch ohne die technisch perfekte, hehre Lösung sondern dann eben im Zweifel pragmatisch

Aber ich guck trotzdem mal

Makki