Logik -> trigger[‚by‘]

[schuma]

hmmm.... irgendwie wird es doch nicht.....

Hier mal meine Testlogik:

tmpsource = sh.return_item(trigger['source'])
tmptrigger = trigger['by']
if tmpsource != None:
    tmpchanged = tmpsource.changed_by()
else:
    tmpchanged = 'None'
logger.info('Trigger All: ' + str(trigger))
logger.info('Trigger source: ' + str(tmpsource))
logger.info('Trigger by: ' + str(tmptrigger))
logger.info('last changed by: ' + str(tmpchanged))

Irgendwie scheint auch changed_by micht immer den richtigen Wert zu liefern. Es sieht so aus, als würde manchmal kein neuer Wert kommen und dann wird immer der zu letzt gesetzte Wert genommen.

Es gibt im Backend bei dem Item eine Information: "Update durch" da steht dann, wenn eine uzsu schaltet: UZSU Plugin.
Das wäre im Grunde das was ich suche. Das mit dem changed_by spiegelt sich auch im Backend wieder. Aber der Wert "Update durch" passt eigentlich immer.
Wie komme ich in einer Logik an diese Information (Update durch - aus dem Backend)?

[Onkelandy]

Wäre es nicht generell schlüssiger, statt trigger['by'] trigger['caller'] zu verwenden? Weil source, dest und value sind die Keywords aus dem Item-Aufruf, by eben nicht.
Aber offenbar stimmt hier noch generell etwas nicht..? Ich kann noch vom autoblind/stateengine Plugin berichten, dass es hier auch eine komplexere Abfrage brauchte, um den tatsächlichen Caller zu finden. Siehe hier im Logfile..:

2018-11-03 17:12:07.889250 running for item 'jalousien.og.sueden_stiegenhaus.automatik.manuell' source 'Eval' caller 'jalousien.og.sueden_stiegenhaus.lamellen'
2018-11-03 17:12:07.895643 Current value of item jalousien.og.sueden_stiegenhaus.automatik.manuell is False
2018-11-03 17:12:07.898856 get_original_caller(Eval, jalousien.og.sueden_stiegenhaus.lamellen): changed by StateEngine Plugin, None at 2018-11-03 17:12:07.854168+01:00
2018-11-03 17:12:07.900448 get_original_caller: returning StateEngine Plugin, None
2018-11-03 17:12:07.901409 original trigger by caller 'StateEngine Plugin' source 'None'

Im Code wird hier auch auf changed_by zurückgegriffen, wie ich das sehe:

    def get_original_caller(self, elog, caller, source):
        original_caller = caller
        original_source = source
        while original_caller == "Eval":
            original_item = self.__sh.return_item(original_source)
            if original_item is None:
                elog.debug("get_original_caller({0}, {1}): original item not found", original_caller, original_source)
                break
            original_changed_by = original_item.changed_by()
            if ":" not in original_changed_by:
                text = "get_original_caller({0}, {1}): changed by {2} -> separator missing"
                elog.debug(text, original_caller, original_source, original_changed_by)
                break
            oc = original_caller
            os = original_source
            original_caller, __, original_source = original_changed_by.partition(":")
            elog.debug("get_original_caller({0}, {1}): changed by {2}, {3} at {4}", oc, os, original_caller, original_source, original_item.last_change())

        elog.debug("get_original_caller: returning {0}, {1}", original_caller, original_source)
        return original_caller, original_source

[Msinn]

Ok, hier arbeitet sich das Plugin aber auch rekursiv durch eine Kette von eval Expressions. Das war nie der Anspruch des trigger-dicts, zumal so etwas, wenn es bei jedem Trigger Event das in SmartHomeNG auftritt, berechnet wird, einen ziemlichen Overhead erzeugen kann.

Man kann darüber diskutieren, ob man Logiken eine Funktion zur Verfügung stellen kann, die das Bei Aufruf (also nur in Logiken, die diese Info benötigen) berechnen. Wenn jemand als Request beschreibt was diese Funktion leisten soll, kann ich sie bei Gelegenheit gerne implementieren. Dazu wäre es aber wichtig genau zu beschreiben was zurück geliefert werden soll: Original triggerndes Item, die Device Addresse von Devices die über Gateway Plugins angebunden sind (KNX, HomeMatic, etc.), oder evtl. noch weitere Informationen.

[schuma]

Msinn Gibt es denn eine Möglichkrit auf die Information, die im Backend/items „Update durch“ heißt, per Logik Aufruf zuzugreifen?

[Msinn]

Suchst Du explizit nach dem Inhalt von "Update durch" und nicht nach "Geändert durch"? "Geändert durch" liefert Dir die Funktion changed_by().

[schuma]

Aber mit changed_by() bekomme ich nicht zuverlässig die Information wer das Item geändert hat. Habe ich ja weiter oben geschrieben. Wenn das funktionieren würde, würde mir changed_by() natürlich auch reichen. Das war ja mein erster Ansatz.
Der Wert, der im Backend bei „updated durch“ steht, passt aber immer. Zumindestens wenn ich es geprüft habe. Das würde jetzt halt erstmal meine Anwendung abdecken.
Ich muss halt in meiner Rolladen Logik zwischen Uzsu getriggert oder von anderswo getriggert unterscheiden.

[Tom Bombadil]

Dürfte doch diese Stelle sein, oder?
/tom

[psilo]

die frage ist, wie schnell sich das changed_by ändert denke ich.. k.a. wie er was ausführt, aber vielleicht wird das item inzwischen von etwas anderem erneut geändert?

[Onkelandy]

Das könnte dann aber wohl am Plugin liegen. In Zeile 172 wird tatsächlich kein Source mitgegeben, vielleicht liegt es daran?
https://github.com/onkelandy/plugins...f5e166b257c634

[Msinn]

schuma Das Backend zeigt bei „Geändert durch“ die Information an, die es selber per change_by() erhält. Du hattest weiter oben aber von "Update durch" geschrieben. Meinst Du nun „Geändert durch“ oder "Update durch"?

[schuma]

Ich meinte „Update durch“ passt.

Ich teste gerade mit updated_by().
Muss nur erstmal wieder nach Hause kommen.
updated_by hatte ich im Code gefunden.

[schuma]

So, habe das mit .updated_by() gerade noch einmal getestet.

So funktioniert es, zumindest eben bei einigen kleinen Tests, bei mir.

Hier im Log gut zu sehen:

2018-11-04  19:42:00 INFO     logics.rolladen last changed by: KNX:1.1.32
2018-11-04  19:42:00 INFO     logics.rolladen last updated by: UZSU Plugin:None

Der Trigger, ein Rolladen move, war eine uzsu.

Bleibt die Frage warum sich der Rest nicht so verhält wie erwartet.
1.1.32 ist bei mir ein Tastsensor 3. Den hat zum Fahren keiner betätigt. War ja die uzsu. Eine Rückmeldung sollte eher vom Aktor als vom Tastsensor kommen.
Ist also ein Rätsel für mich.
Allerdings war die Aktion vor dem uzsu fahren des Rolladens eine Tastsensor. Irgendwie wird da etwas nicht aktuallisiert. Denke ich.

Msinn Sollte man die Doku an der Stelle anpassen? Wie auf dem Bild weiter oben gezeigt (Post #8)? Also das beim Trigger['by'] eine KNX:1.1.x als Beispiel steht? Ich bekomme an der Stelle nur ITEM oder BACKEND.

[Msinn]

Das ist kürzlich dazugekommen. Ist nicht mehr dokumentiert worden, weil das Handling von Item-Properties zur v1.6 komplett überarbeitet wird und die Funktion dann die Funktion nicht mehr genutzt werden soll.

[Msinn]

Also das beim Trigger['by'] eine KNX:1.1.x als Beispiel steht?

Nein, dafür gibt es trigger['source']

[schuma]

Nein, dafür gibt es trigger['source']

Also müsste man da doch die Doku anpassen?