DOIF neue Features: Generalisierung, $DEVICE, $EVENT, Attribut notexist

[Damian]

Wenn ein Timer der Trigger ist, hat man mit $DEVICE auch ein Problem. Und bei mehreren Readings hat man mit der split-Methode auch ein Problem. Ohne "Eigenverantwortung" kommt man so oder so nicht aus.

BTW: kann man mit [$DEVICE:reading] oder [$device:reading] bzw [$_:reading] auch im Perl-Mode im Ausführungsteil arbeiten? Ich bekomme bei den verschiedenen Versuchen entweder eine Fehlermeldung oder "komische" Werte ("HASH(xxxxxx)"...). Mit ReadingsVal geht es natürlich, ist aber viel umständlicherer Code.

Also $DEVICE wird konsequent im Perl- und FHEM-Modus durch das triggernde Device ersetzt. Daher ist [$DEVICE:reading] die optimale Lösung, um aus einem allgemeinen Event-Trigger den Inhalt eines bestimmten Readings in beiden Modi zu erhalten. Das ist auch so beabsichtigt und im Modul programmiert.

Daher ist es nicht unbedingt sinnvoll noch mehr Platzhalter wie z. B. $READING einzubauen. Denn solche Platzhalter wie z. B. $DEVICE oder eben $READING müssen bei jedem Trigger im Code durchsucht und ersetzt werden. Das kostet unnötig Performance insb. für die, die es nicht brauchen.

[Per]

Und Teil 2 des Postes?

[Damian]

Und Teil 2 des Postes?

Was ist damit?

[$DEVICE:reading] geht, die anderen nicht. Zu bedenken ist, dass im Perlmodus eine Perlfunktion an dieser Stelle eingesetzt wird, im FHEM-Modus wird dagegen der Wert selbst eingestellt.