Mahlzeit!
Ich wollte an einigen Dummys das Reading "trigger" setzen, um nachträglich das Sender-Device bzw. Sender-Notify zu identifizieren.
Das funktioniert zwar, allerdings verursacht anscheinend das Wort trigger im Aufruf ein weiteres Event.
Beispiel
define notify1 notify MySender {
fhem("setreading MyDummy trigger $NAME:$EVENT");
fhem("set MyDummy off");
}
define notify2 notify MyDummy {
my $Trigger = ReadingsVal("MyDevice", "trigger", 0);
Log 1, $NAME.": ".$EVENT;
}
verursacht:
MyDummy: trigger:MySender:off
UND
MyDummy: off
Mache ich einen Logikfehler, ist es ein Bug oder darf ich bei den Attributnamen und -Readings keine FHEM Funktionsnamen verwenden?
Danke für eine Antwort!
Ronny
du bekommst ein event für das reading trigger (aus setreading) und ein event für state (aus set). das korrekt so. da ist nichts doppelt.
Verstehe. Das heißt, ich müsste entweder mein Notify einschränken durch
define notify2 notify MyDummy:(on|off)
oder meinen Dummy mit event-on-change-reading austatten:
attr MyDummy event-on-change-reading state
Nur zur Vervollständigung:
Ich nehme an, dass bei solchen Konstrukten aus Performancegründen wohl die 2. Variante zu empfehlen ist, da keine Events von FHEM verarbeitet werden müssen?
es ist normalerweise sinnvoll beides zu tun. event-on-change setzen und die notifys so genau wie möglich zu definieren.
gruss
andre
Du meinst, damit nicht in den Codeteil gesprungen wird bei einem Fall, den man eventuell nicht berücksichtigt hat? Alleine aus Perfomancesicht müsste aber event-on-change-reading reichen, oder?
Ich frage deswegen nochmal nach, weil ich eine Art Best-Practice bei der Programmierung erreichen will. Aber auch, um sämtliche Verzögerungen im Ablauf zu minimieren.
best practice ist beides