[gelöst] Reservierte Namen für Attribute und Readings (bspw. trigger)

[FHEMAN]

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

Code Auswählen Erweitern

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

[justme1968]

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.

[FHEMAN]

Verstehe. Das heißt, ich müsste entweder mein Notify einschränken durch

Code Auswählen Erweitern

define notify2 notify MyDummy:(on|off)
oder meinen Dummy mit event-on-change-reading austatten:

Code Auswählen Erweitern

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?

[justme1968]

es ist normalerweise sinnvoll beides zu tun. event-on-change setzen und die notifys so genau wie möglich zu definieren.

gruss
  andre

[FHEMAN]

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.

[justme1968]

best practice ist beides