Dummy: Unterschied zwischen den Versionen
K (Schreibweise im des Modulnamen korrigiert) |
F Klee (Diskussion | Beiträge) KKeine Bearbeitungszusammenfassung |
||
| (11 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt) | |||
| Zeile 9: | Zeile 9: | ||
}} | }} | ||
Geräte vom Typ [[dummy]] können für verschiedene Zwecke genutzt werden, die im folgenden anhand von Beispielen aufgeführt werden. | Geräte vom Typ [[dummy]] können für verschiedene Zwecke genutzt werden, die im folgenden anhand von Beispielen aufgeführt werden. Wenn geplant ist, mit einem dummy Schalter zu definieren (Ein-/Ausschaltung), ist wahrscheinlich ein [[readingsProxy]] besser geeignet. | ||
Zusatzlich zum Device ''dummy'' gibt es auch ein gleichnamiges [[dummy (Attribut)|allgemeingültiges Attribut]]. | |||
== Definition == | == Definition == | ||
Siehe | Siehe {{Link2CmdRef|Anker=dummydefine}}. | ||
== Attribute == | == Attribute == | ||
Siehe | Siehe {{Link2CmdRef|Anker=dummyattr}}. | ||
== Beispiele == | == Beispiele == | ||
=== Jahreszeiten === | |||
[[Datei:dummySeasons.png|mini|right|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 | |||
[[Datei:dummySeasonsInternals.png|mini|right|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: | |||
:<code>attr dy_Season setList state:Winter,Frühling,Sommer,Herbst</code> | |||
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: | |||
:<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 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. | |||
=== ntfy_setreading === | === 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=[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.}} | ||
Wird bei einem Dummy mit [[setList]] gearbeitet, um mehrere Readings in einem Dummy zu haben, erfolgt bei einer Änderung nur das | 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: | ||
<br clear=all> | |||
{{Randnotiz|RNTyp=y|RNText=Das Konstrukt mit ~~ verursacht massive Warnungen im Log wegen (der Perl Funktion) Smartmatch und ist aus diesem Grund nicht zu empfehlen!}} | |||
:<code>define ntfy_setreading notify d_.* { if( ($EVENT ~~ / /) and ($EVENT !~ /: /) ) {fhem("setreading $NAME $EVENT")} }</code> | :<code>define ntfy_setreading notify d_.* { if( ($EVENT ~~ / /) and ($EVENT !~ /: /) ) {fhem("setreading $NAME $EVENT")} }</code> | ||
| Zeile 31: | Zeile 55: | ||
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. | 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 | |||
:<code>set ''dummyName'' dummyWert</code> | |||
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''. | |||
<!-- Der folgende Text stammt aus Forentopic #13498 und hat keinen speziellen Bezug zu 'dummy' --> | |||
<!-- Auskommentiert, da in diesem Kontext weder auffindbar noch speziell relevant. | |||
Man kann fhem Kommandos nicht mit Perl vermischen, wenn der Autor des Moduls, in diesem Fall set es nicht vorgesehen hat. | |||
Das Kommando "set <dummy> <value>" verändert den Inhalt von <dummy> auf den Text <value>. | |||
Achtung, falsch!!: | |||
set twilight_condition {ReadingsVal(myTwilight, condition, "99")} | |||
Das dummy twilight_condition wird durch deine Zuweisung vermutlich den Inhalt "{ReadingsVal(myTwilight, condition, "99")}" bekommen. Der PerlCode wird '''nicht''' ausgeführt. | |||
Richtig: | |||
fhem ("set twilight_condition " . ReadingsVal("myTwilight","condition",99)) | |||
Als ganzes notify, bei jedem Temperaturupdate (Aussen) die Vorlauftemperatur neu berechnen und in Heizung_VL_Soll zur Verfügung stellen: | |||
define setVL notify S300TH:temperature.* { fhem("set Heizung_VL_Soll ". calcVL(ReadingsVal("Heizung_Slider","state","0"),"0","0.5","0.7"))} | |||
-- Ende der auskommentierten, nicht wirklich sachdienlichen Passage --> | |||
Aktuelle Version vom 22. Juli 2024, 11:22 Uhr
| 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! | |
Geräte vom Typ dummy können für verschiedene Zwecke genutzt werden, die im folgenden anhand von Beispielen aufgeführt werden. Wenn geplant ist, mit einem dummy Schalter zu definieren (Ein-/Ausschaltung), ist wahrscheinlich ein readingsProxy besser geeignet.
Zusatzlich zum Device dummy gibt es auch ein gleichnamiges allgemeingültiges Attribut.
Definition
Siehe commandref/dummydefine.
Attribute
Siehe commandref/dummyattr.
Beispiele
Jahreszeiten
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
- 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.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:
Das Konstrukt mit ~~ verursacht massive Warnungen im Log wegen (der Perl Funktion) Smartmatch und ist aus diesem Grund nicht zu empfehlen!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.