CometVisu - (interner) Beta-Test

[makki]

include für visu_config

Ist mir grad so gekommen:
Wenn man nun einige wiederkehrende config-snipplets/pages hat, wäre es doch schön diese irgendwie in visu_config* zu "includen".
Beispiel:
Multiroom, alle Lichter, Rolläden,.. tauchen auf verschiedenen pages/configs immer wieder auf; vor allem unübersichtliche aber eben komplette Detail-Unterseiten.

Definitv eine Sache für Post 0.6, ich hab das jetzt auch nicht im Detail untersucht, die Kurz-Recherche ergab nur das es mit XML wohl eher schwierig bis ganz grausam ist;
-> sollte es so sein, kein Aufwand bitte, macht ein script das auch

Aber wenn es nicht ganz grausam ist, wäre das doch evtl. einen FR Wert (?)

Makki

P.S: Ich meine nur für die config selbst, für den Editor z.B. ist das worst-case, nahe-unmöglich..

[makki]

Eine dumme Frage, sorry, stochere mal wieder grob im JS-Nebel:
Wie z.B. kommt man - in richtig - aus der function infotrigger->action (die auf actorup/down gebunden ist) auf $(actorinfo).data ? Ich blicks nicht..
Oder sollte man das eher mit $actorup/down.bind( addr, this.update ); anmelden?

Makki

[Chris M.]

Eine dumme Frage, sorry, stochere mal wieder grob im JS-Nebel:[...]

Hab's nicht vorher geschafft und jetzt ist's mir zu spät

Ich kann nur empfehlen sich bei anderen Widgets inspirieren zu lassen. Da sollte es hoffentlich alles relevante schon geben.

Evtl. morgen Abend mehr.

[makki]

Naja, ich häng da jetzt seit zwei Tagen, da kommts auf einen nicht mehr an
Irgendwie gehts zwar (parent, sibling, update,..) aber richtig ist das nicht..

In anderen Widgets ist das immer nur $(this), das kapier ich ja, aber das this.parent.daneben, da braucht der Spaghetticode-Mörder ne globale Variable Oder nen Tipp..

Makki

[Chris M.]

In anderen Widgets ist das immer nur $(this), das kapier ich ja, aber das this.parent.daneben, da braucht der Spaghetticode-Mörder ne globale Variable Oder nen Tipp..

Das widget ist fies, da es drei actions enthält

Der Tipp wäre:

$(this).parent().find('.switchInvisible').data()

Aber fies ist außerdem, dass value nur den formatierten Wert (also bei mit mit "°C") enthält
=> jetzt gibts basicvalue auch noch...

Hab's mal in's SVN geschoben, hat fast keinen Test hinter sich - der evtl. notwendige Rest sollte nun aber leicht von der Hand gehen.

[makki]

Danke, jetzt lichtet es sich.
Geht Hab nur meine definition von relative/absolute angepasst und das es nun wirklich rechnet..

$(this).parent().find('.switchInvisible').data()

Also ist es doch so kompliziert, da war ich immerhin vorgestern schon quasi kurz davor (nur .find fehlte, sibling wollte nicht so wie ich)

Aber fies ist außerdem, dass value nur den formatierten Wert (also bei mit mit "°C") enthält
=> jetzt gibts basicvalue auch noch...

Den Rohwert hätte ich mir auch schon ohne suffix abgespeichert gehabt aber ich kam nichtmal ran
Und basicvalue in defaultUpdate, das hätte ich vergeigt..
Aber nachdem ich jetzt 1h damit verbracht habe, mir beizubringen wie man JS beibringt eine Zahl ganz einfach verdammtnochmal als Zahl zu nehmen und damit zu rechnen ( wie schön sind doch manchmal Sprachen, wo Datentypen ganz einfach explizit sind!) käme ich zu der Erkenntniss das es parseFloat(data.value) evtl. auch getan hätte. Egal.. Es geht..


Nächstes Thema: Ich würde "switch" (oder lieber trigger?? passt aber besser zum switch IMHO) gerne so ändern, das er nicht nur 0/1 sondern beliebige Werte aus dem mapping durch-schaltet und anzeigt.
Also so wie das "Switch Design" schon tut und "info" den Text je nach value im mapping anzeigt; Einwände? (dann lieber ein neues Widget aber eigentlich ändert sich für den 0/1 switch ja dadurch nichts, kann nur mehr Werte - je nach Mapping)

Das Konzept der Mappings finde ich hier übrigens sehr gut. Müsste "nur noch" in den Editor und könnte - für KNX weitergedacht - auch automatisch aus den DPT's gefüllt werden wenn kein anderes, lokales Mapping angegeben wird.

Makki

[makki]

Hab das mal commited: toogle
Ist wie switch nur ohne presses/unpressed, toggelt beliebig viele Werte eines Mappings einfach durch, auch wenn diese nicht mit 0 anfagen;
Also z.B. Multiroom-Quelle 0-5
<mapping name="RussoundSRC">
<entry value="0">UKW</entry>
<entry value="1">vdr/mpd</entry>
<entry value="2">Denon WZ</entry>
<entry value="3">WG1</entry>
<entry value="4">WG2</entry>
<entry value="5">Kino</entry>
</mapping>

Oder Heizung-Betriebsart oder sowas wie 0,40,60,100% etc.

Makki

[greentux]

Heisst das, es wird immer ein anderer Wert auf genau eine GA gesendet?
Oder ist es ggf auch möglich, wieder mehrere Aktionen zu starten?
Ich bräuchte ein Licht ein/aus/Automatik, was dann wohl die GA des Aktors und die Sperre des PM betreffen würde...

[makki]

Ja, der Toogle schaltet eine GA beliebig um; also je nach mapping und Möglichkeiten des DPT 0/1/400/.. , 10/30/50/.. oder leer/mittel/voll/übergelaufen

Ich verwende das aktuell in der HS-Visu recht oft (allerdings braucht man dort zu jedem Button eine zus. Logik )

Für die PM-Sperre ist wohl Multitrigger eher der Freund, wobei wir hier halt auch immer ganz hart an der grenze zur Logik schrammen (die IMHO in der Visu nichts verloren hat) -> der Toggle bedient hier primär nicht KNX-Teile.

-> Bei meinen PM "bediene" ich sowieso nur das Sperrobjekt, der Rest ist in der Appl des PM hinterlegt und das ist so auch nicht ganz falsch..
Aber wenn Du näher beschreibst was es machen soll und warum genau es nicht mit "normalem" KNX geht, kann man mal sehen; bin mit dem toggle eh noch nicht ganz zufrieden..

Makki

P.S.: einen hab ich noch weil ich grad drin war
jqclock (Uhr-Widget) ist submitted.

Optional auch in der Statuszeile z.B. (wichtig ist nur id="jqclock_status"):
...
<status type="html"><![CDATA[
- <a href="check_config.php">Check Config</a>
<div class="jqclock" id="jqclock_status" lang="de" date="true">-</div>
<div style="float:right;padding-right:0.5em">Version: SVN</div>
]]></status>
...

CSS ist wie immer noch nicht wirklich optimal

P.P.S: demo-config für infotrigger/relative, toggle und jqclock folgt noch ins SVN wenn das sich etwas gesettled hat.

[Chris M.]

Ist mir grad so gekommen:
Wenn man nun einige wiederkehrende config-snipplets/pages hat, wäre es doch schön diese irgendwie in visu_config* zu "includen".

Ja, bitte Feature-Request, damit wir's nicht vergessen. Nicht für 0.6.0.

P.S.: einen hab ich noch weil ich grad drin war

Es ist höchst unbefriedigend, wenn ich hier einbremsen muss (mich selbst eingeschlossen) - aber wird sind gerade in der Endphase und damit Feature-Freeze für die 0.6.0

Gerade bei Features die man selber braucht und die ungefährlich wirken ist die Versuchung leider sehr groß.

Vorschlag: Änderungen bitte nur noch um Fehler zu beheben - dazu zählen auch Useability-Bugs (bei denen der Übergang zum neuen Feature leicht verschwimmen kann).
Sollte man doch noch ein neues Feature haben und dringen einbauen wollen, dann bitte nebenwirkungsfrei, d.h. wenn man an jeglichen vorher existierenden Configs nichts ändert, dass der neue Code dann nicht ausgeführt wird.
Alles andere bitte vorher hier absprechen oder in einem Fork, den man nach der 0.6.0 wieder zusammenführen kann.

[makki]

Das war auch nicht unbedingt so gedacht in 0.6.0 zu müssen, dafür gibts ja doch schon eine release-branch..

Makki

[greentux]

Ich hatte gehofft, das es einen Branch gibt.

Zum PM:
Ich hätte gern für den Flur, der normalerweise Argus gesteuert ist, einen Switch, wo man
- "Licht ein"
- "Licht aus"
- "Licht Auto" togglen kann.
Momentan habe ich zwei Switche dafür (siehe Screenshots im SF Bereich).
Wenn ich auf "Licht ein" gehe, sollte einmal der PM gesperrt werden und der Aktor EIN bekommen. Klar kann man das im PM hinterlegen (Aktion bei Sperre EIN -> Aktor EIN). Spätestens wenn das bei "Licht aus" auch so sein soll, gehts dann irgendwie nicht mehr via Aktor (oder ich übersehe gerade etwas).

[Chris M.]

Das war auch nicht unbedingt so gedacht in 0.6.0 zu müssen, dafür gibts ja doch schon eine release-branch..

Ich hatte gehofft, das es einen Branch gibt.

OK, das war schlecht (ok, gar nicht) von mir kommuniziert.

Mein aktuelles vorgehen ist:
Alle Entwicklung findet unter trunk statt. Jedes Release wird davon weg gebrancht. Im Branch findet nur noch die Arbeit für's entsprechende Release statt, was so 1-2 Dateien betrifft.
Wenn tatsächlich später mal ein gravierendes Problem in einem Release auftreten sollte und man nicht ein neues aus trunk ableiten möchte (z.B. weil schon inkompatible Änderungen bzgl. Config-Datei drinnen sind), dann könnte man aus einem branch den (Bugfix-)Nachfolger ableiten.

Was ich nicht geplant hatte, war dass an der nächsten Version gearbeitet wird, wenn die alte noch nicht draußen ist. Dazu habe ich unsere Ressoucen als zu limitiert eingeschätzt - wenn sich jeder nämlich gleich auf's neue stürzt, hat man niemanden mehr, der das langweilige Bugfixing im alten übernimmt. => Es wird gar kein Release geben können

Um hier einen Kompromiss hin zu bekommen, habe ich jetzt unter

https://openautomation.svn.sourceforge.net/svnroot/openautomation/CometVisu/tags/post_0.6.0

einen branch / tag erzeugt. Hier kann man schon mal Code einbauen der nach der 0.6.0 in den trunk wandern soll...

Wie oben geschrieben, bitte verantwortungsvoll damit umgehen und primär die Bogs beheben damit das Release endlich raus kann!

An alle Nicht-Entwickler:
Was wir für die öffentliche Beta gut gebrauchen könnten, wäre eine Erweiterung des Benutzerhandbuch um Details für jedes Widget. (Z.B. auf der Seite XML-Elemente)
Dabei stelle ich mir für jedes Widget einen Screenshot (bzw. Screenshot-Ausschnitt) vor, so wie die im Editor sichtbaren Parametern und deren Bedeutung.

[swiss]

Ich arbeite gerne an der Doku mit aber das Probelem ist, dass meistens nur die Entwikler selbst alle Einstellungen und Möglichkeiten im Detail kennen. Ich habe mal versucht einen Lexikonbeitrag für das Forum vorzubereiten muss aber gesteehn dass gerade bei der Beschreibung der Parameter noch einige Fragen offen bleiben

Vieleicht wäre es mal eine Möglichkeit, dass ich den Vorabzu für den Lexikoneintrag hier in Unterforum in einem neuen Thema eröffne und dann jeder drüber schauen und Imputs geben kann. Wenn dann alle Parameter klar sind kann man daraus dann das Wiki füllen. Das kann dan sehr viel deteilierter und mit Screenshots erfolgen.

Was haltet ihr von diesem Vorschlag?

[Chris M.]

Das mit den "geheimen" Parametern ist genau das Problem das ich lösen möchte.
=> Fang doch einfach an mit dem was Du weist, dann müssen die Kenner der Internas nur noch die Lücken auffüllen.

Den Artikel hier im Forum sehe ich (wie schon mal geschrieben) mehr als allgemeine Info über die CometVisu.
Die Dokumentation selbst gehört IMHO dann in's SF Wiki.