Logik -> trigger[‚by‘]

[Msinn]

Ja, in trigger['by'] steht normalerweise der Plugin Name. Das kann allerdings leiderbei einigen Plugins anders sein, weil die Angaben für by und source in den Plugins vom Plugin Author gesetzt werden.

[Msinn]

Ich habe da mal tiefer reingeschaut. Das erscheint mir im Code etwas ungeordnet. Wie die Elemente des trigger-Dicts belegt werden unterscheidet sich je nach Auslöser der Logik.

Der Scheduler schickt andere Werte als z.B. Items die bei change oder update einen Trigger auslösen.

Ich überlege, ob es sinnvoll ist beim Triggern durch Items ein zusätzliches Key/Value Pair im trigger-dict zu übergeben. So etwas wie trigger['source_details'] könnte die Zusatzinformationen transportieren (Plugin-Name, Plugin-Instanz, Adresse des Device (bei Gateway Plugins). Evtl. könnte es auch sinnvoll sein die Details in unterschiedlichen key/value Pairs zu übergeben (z.B. "Plugin" und "Device_Id"?).

[schuma]

Ich finde die Idee mit dem dict in unterschiedlichen Key:value Paaren gut.
Da hat man es dann im weiteren Verlauf einfacher.

[schuma]

Ja, in trigger['by'] steht normalerweise der Plugin Name. Das kann allerdings leiderbei einigen Plugins anders sein, weil die Angaben für by und source in den Plugins vom Plugin Author gesetzt werden.

Onkelandy Guckst Du hier noch, ob da was im uzsu Plugin nicht gesetzt wird?
Oder hattest Du das in Post #24 schon erledigt?
Edit: Hab schon gesehen. Ist geändert

[Msinn]

Im Moment steht in Logiken, die von Items getriggert werden im trigger dict immer folgendes:

by: 'Item'
source: <Pfas des Items>
dest: None
value: <Wert des Items>

Andere Werte werden nicht durchgeschleust.

Das sieht anders aus, wenn Logiken nicht direkt getriggert werden, sondern wenn ein Scheduler aufgesetzt wird, der dann später triggert.

Für das direkte Triggering aus Items habe ich eine Möglichkeit gefunden zusätzlich weitere Werte an die Logik durchzuschleusen (Siehe Post #32).

schuma Bist Du auf dem master- oder dem develop Branch unterwegs? Ich könnte eine Version für Dich zum testen heute Abend im develop pushen.

Ich habe gestern bereits zwei Gateway Plugins angepasst um mehr Informationen zu zeigen. Bei Gateway Plugins ist das besonders interessant, da das eigentlich auslösende Device dann im Backend angezeigt wird (und an eine Logik übergeben werden könnte).

Angepasste Plugins:

• knx: Statt KNX:<pa> wird jetzt knx:<pa>:ga=<ga> übergeben bzw. (Bei Konfiguration mehrere Instanzen knx:<instance>:<pa>:ga=<ga>)
• homematic: Statt HomeMatic wird jetzt homematic:<device-id>:<channel> übergeben. (Bei Konfiguration mehrere Instanzen homematic:<instance><device-id>:<channel>)

[schuma]

Ich bin auf dem Master unterwegs. Und das ist auch mein Produktiv System.
Ich wollte schon immer mal ein neuen Pi kaufen wo dann ein DEV drauf laufen soll. Habe ich aber bis jetzt leider nicht geschafft.

[Msinn]

Ok, dann wirst Du erst um den Jahreswechsel in den Genuss der Erweiterungen kommen können. Der Jahreswechsel wäre vom Zyklus her das angestrebte Zeitfenster für das nächste Release.

Ich würde es dann für Items die Logiken triggern erstmal so implementieren, dass in trigger['source_details'] der String übergeben wird, der auch im Backend unter changed_by bzw. updated_by sichtbar ist.

(updated_by würde gelten bei einem Update (nicht Change), falls enforce_updates gesetzt ist.)

[schuma]

Ja, das ist doch super.
Im Moment komme ich ja mit meiner Lösung gut klar. Muss dann nur meine Logik wieder anpassen. Aber das geht ja schnell.

[android]

Habe ein ähnliches Problem. Will im eval auswerten, wer der trigger war. Wenn ich changed_by nutze ist das erst nachher aktuell. Gibts im eval noch eine andere Möglichkeit den trigger abzufragen?