Mapping für Trigger

[mivola]

Hallo zusammen,

ich möchte ein Mapping für einen Trigger benutzen. Dazu folgender Code:

        <group nowidget="true" flavour="sodium">
          <layout colspan="3"/>
          <trigger mapping="Lueften" styling="GreyGrey" value="50">
            <label>Lüften</label>
            <address transform="DPT:5.001" mode="write">3/4/44</address>
            <address transform="DPT:5.001" mode="read">3/4/46</address>
          </trigger>
        </group>

Das Mapping an sich funktioniert, da ich es erfolgreich zb in einem info-Element benutze. Jedoch wird für den Trigger immer das zu dem value-Wert (hier: "50") gehörende Icon angezeigt. Gibt es eine Möglichkeit statt dem "value"-Wert den Wert aus der read-Adresse zu nutzen?

Danke und viele Grüße,
Micha

[lo4dro]

Ich glaube du hast das selbe Problem wie ich mit de Trigger.
Der Unterstützt keine Rückmeldungen.

[Chris M.]

Der Trigger ist wirklich nur als Fire&Forget gedacht (gewesen).

Wenn hier andere/neue Wünsche kommen, müsste das halt eingebaut werden. Der Code ist offen

[mivola]

Der Trigger ist wirklich nur als Fire&Forget gedacht (gewesen).

Wenn hier andere/neue Wünsche kommen, müsste das halt eingebaut werden. Der Code ist offen

OK, ich könnte mal versuchen mich daran zu setzen. Sollte ja durch Copy & Paste (zb vom Info-Widget) machbar sein. Da es meine erste Anpassung wäre: wie ist da sinnvoller Workflow?

Aber: soll tatsächlich das (bisherige) Default-Verhalten (Anzeige des value-Werts) geändert werden? Oder sollte es eine dedizierte neue Funktionalität sein? Oder könnte man sich auf soetwas einigen:

• wenn (mind.) eine read- oder readwrite-Adresse angegeben ist, wird ein ankommender Wert für das Mapping benutzt
  • das sollte bisher ja nicht vorhanden sein, wg "Fire & Forget"
• anderfalls wird auf das aktuelle Verhalten (dh value-Wert) zurückgegriffen

Was meint ihr?

VG
Micha

[Chris M.]

Ich hätte das bestende Trigger erweitert.
Ob ein reines Schauen auf read bzw. readwrite reicht müsste man sehen. Vermutlich hätte ich eher ein zusätzliches Attribut spendiert, dass das "statefull" (schreibt man das so? Ich meine das Gegenteil von "stateless") macht.

Ich bin eher der experimentelle Programmierer, beim Schreiben sehe ich ob's passt, oder ob hier gerade ein Kozept missbraucht wird. Falls letzteres, dann wäre es Zeit für ein zusätzliches Widget.

[mivola]

Ich wollte mich jetzt grade mal an das Thema setzen. Und da kam mir der Gedanke: könnte man nicht auch den Switch erweitern? Der hat doch eigentlich eher Ähnlichkeit mit dem was wir haben wollen, oder?

Man könnte dem <switch> selbst oder dem zugehörigen Mapping einen neuen Parameter (zB "writeValue"?) spendieren.

Was meint ihr?

[Chris M.]

Philosophie-Frage: mir kam neulich auch die Idee alle Buttons (Swtich, Trigger, ...) in einem einzigen Widget zu vereinen. Bei den KNX Tastern ist das ja auch so, da wähle ich in der Applikation aus ob's nun Umschalter, 1-Button-Dim, ... ist.
Außerdem dürfte das die Code-Menge in Summe reduzieren. Und die Unterscheidung was dieser Button nun ist wird erst bei der Interaktion fällig, ein Zeitpunkt wo die paar CPU Zyklen mehr für ein Switch-Statement nicht wirklich in's Gewicht fallen.

Aber: das wäre eine nicht kompatible Änderung mit der aktuellen Config-Datei-Struktur.
=> Wir sollten das nur zu einem größeren Versions-Sprung machen.

Nun ist es aber so, dass ich als nächstes durchaus auf eine Version 0.9 wechseln würde (dank Lade-Skript haben wir eine deutliche interne Änderung hinter uns), d.h. der Zeitpunkt würde passen.
Aber: eigentlich wollte ich diese Version ASAP heraus bringen.
Tja, was nun?

[mfd]

Aber: eigentlich wollte ich diese Version ASAP heraus bringen.

Jetzt im "Sommerloch" sollte es ja niemand stören wenn v0.9 etwas länger auf sich warten lässt...

[XueSheng]

Alle Buttons in einem Widget? Das würde ich auch begrüßen. Aus Endanwendersicht hat sich mir die Trennung nie wirklich erschlossen.

[MGK]

Fände ich auch sinnvoll.

Michael

[mivola]

Na da hab ich ja wieder was losgetreten ... ;-)
Also wenn es eine Konsolidierung geben würde, würde ich das auch begrüßen. Allerdings traue ich mir es (fachlich & zeitlich) nicht zu, diese umzusetzen :-(

VG
Micha