Dummy: Unterschied zwischen den Versionen

dummy
Zweck / Funktion
	Definition von Hilfsobjekten
Allgemein
Typ	Hilfsmodul
Details
Dokumentation	EN / DE
Support (Forum)	Automatisierung
Modulname	98_dummy.pm
Ersteller	Rudolf König/rudolfkoenig (Forum /Wiki)
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Version vom 27. Juni 2018, 07:29 Uhr

Geräte vom Typ dummy können für verschiedene Zwecke genutzt werden, die im folgenden anhand von Beispielen aufgeführt werden.

Zusatzlich zum Device dummy gibt es auch ein gleichnamiges allgemeingültiges Attribut.

Definition

Siehe commandref/dummydefine.

Attribute

Siehe commandref/dummyattr.

Beispiele

Jahreszeiten

Darstellung mit allen vorgesehenen Icons

Eine typische Anwendung eines dummy besteht in der Platzierung eines Buttons (Icon, Schaltfläche) auf der Benutzeroberfläche, wobei diesem "Device" unterschiedliche Werte zugeordnet werden können. Im Detail soll das verdeutlicht werden am Dummy

Auswahlliste in der Details-Ansicht des dummy Objekts aufgrund des Attributs setState

dy_Season
mit dem alias Jahreszeit und
vier vorgesehenen Werten,
die jeweils durch ein spezifisches Icon dargestellt und
durch Klick auf das Icon gewechselt werden können.

Hierbei werden die "erlaubten" Werte für den state durch das Attribut setList festgelegt:

attr dy_Season setList state:Winter,Frühling,Sommer,Herbst

Damit werden "Winter", "Frühling", "Sommer", "Herbst" in der Auswahlliste angeboten.

Die Zuordnung von Icons zu den Werten sowie die Festlegung des Folgezustands nach anklicken des Icons werden mit dem Attribut devStateIcon bestimmt:

attr dy_Season devStateIcon Sommer:weather_summer:Herbst Frühling:weather_pollen:Sommer Herbst:weather_wind:Winter Winter:weather_winter:Frühling

Der bei diesem dummy gesetzte Wert (state) kann in Folge z.B. in Bedingungen verwendet werden; hier ein Auszug aus einem DOIF

([12:45] and [dy_Season:state] eq "Sommer") (...)

bei dem die definierte Aktion (...) um 12:45 Uhr nur dann durchgeführt würde, wenn das beschriebene dummy Objekt auf "Sommer" steht. Generell gesagt lassen sich also mit Hilfe dieses Mechanismus Aktionen in Abhängigkeit einer (benutzerdefinierten!) Jahreszeit bedingt ausführen.

ntfy_setreading

Es wird nur auf Devices getriggert, die mit "d_" anfangen. Sollten die dummy Devices anders heißen, muss das entsprechend in der DEF angepasst werden.

Das Konstrukt mit ~~ verursacht massive Warnungen im Log wegen Smartmatch. Ist nicht zu empfehlen!

Wird bei einem Dummy mit setList gearbeitet, um mehrere Readings in einem Dummy zu haben, erfolgt bei einer Änderung nur das Setzen des Status nach <reading> <value>. Ein Reading wird dabei nicht angelegt oder aktualisiert. Damit dies doch geschieht, muss ein notify nach folgendem Muster angelegt werden:

define ntfy_setreading notify d_.* { if( ($EVENT ~~ / /) and ($EVENT !~ /: /) ) {fhem("setreading $NAME $EVENT")} }

d_label

Für readingsGroups kann es hilfreich sein, Überschriften aus einem Reading zu bekommen. So können sie beispielsweise mit valueColumns bearbeitet werden und Sonderzeichen wie : oder Leerzeichen ( ) müssen nicht umständlich eingefügt werden.

define d_label dummy

Durch das ntfy_setreading können Labels nun einfach über einen set Befehl erstellt werden:

set d_label HHMM (HH:MM)

Damit wird ein Reading HHMM erzeugt mit dem Wert (HH:MM).

Statt in einem dummy können diese Hilfs-Readings auch direkt in der readingsGroup untergebracht werden. Auch die Verwendung mit dem !-Flag in der readingsGroup bietet sich an.

set

Mit der Anweisung

set dummyName dummyWert

wird dem Dummy dummyName der Wert dummyWert zugewiesen. In der Detail-Ansicht (oder dem list) von dummyName erscheint der zugewiesene Wert im Internal STATE sowie im Reading state.

@@ Zeile 36: / Zeile 36: @@
 :<code>attr dy_Season devStateIcon Sommer:weather_summer:Herbst Frühling:weather_pollen:Sommer Herbst:weather_wind:Winter Winter:weather_winter:Frühling</code>
-Der bei diesem ''dummy'' gesetzte Werte (state) kann in Folge z.B. in Bedingungen verwendet werden; hier ein Auszug aus einem [[DOIF]]
+Der bei diesem ''dummy'' gesetzte Wert (state) kann in Folge z.B. in Bedingungen verwendet werden; hier ein Auszug aus einem [[DOIF]]
 :<code>([12:45] and [dy_Season:state] eq "Sommer") (...)</code>
 bei dem die definierte Aktion (...) um 12:45 Uhr nur dann durchgeführt würde, wenn das beschriebene ''dummy'' Objekt auf "Sommer" steht. Generell gesagt lassen sich also mit Hilfe dieses Mechanismus Aktionen in Abhängigkeit einer (benutzerdefinierten!) Jahreszeit bedingt ausführen.
@@ Zeile 42: / Zeile 42: @@
 === ntfy_setreading ===
 {{Randnotiz|RNTyp=[g|Info]|RNText=Es wird nur auf Devices getriggert, die mit "d_" anfangen. Sollten die dummy Devices anders heißen, muss das entsprechend in der DEF angepasst werden.}}
-{{Randnotiz|RNTyp=y|RNText=Das Konstrukt mit ~~ verursacht massive Warnungen im Log wegen Smartmatch. Ist zu nicht empfehlen!}}
+{{Randnotiz|RNTyp=y|RNText=Das Konstrukt mit ~~ verursacht massive Warnungen im Log wegen Smartmatch. Ist nicht zu empfehlen!}}
-Wird bei einem Dummy mit [[setList]] gearbeitet, um mehrere Readings in einem Dummy zu haben, erfolgt bei einer Änderung nur das Setzten des Status nach <reading> <value>. Ein Reading wird dabei nicht angelegt oder aktualisiert. Damit dies doch geschieht, muss ein notify nach folgendem Muster angelegt werden:
+Wird bei einem Dummy mit [[setList]] gearbeitet, um mehrere Readings in einem Dummy zu haben, erfolgt bei einer Änderung nur das Setzen des Status nach <reading> <value>. Ein Reading wird dabei nicht angelegt oder aktualisiert. Damit dies doch geschieht, muss ein notify nach folgendem Muster angelegt werden:
 :<code>define ntfy_setreading notify d_.* { if( ($EVENT ~~ / /) and ($EVENT !~ /: /) ) {fhem("setreading $NAME $EVENT")} }</code>