DOIF Devices als Attribut

[LHBL2003]

Hallo,

Info:
Im Anhang Befinden Sich Screenshots der Restlichen Konfiguration.

Vorwort zu mir (Vorgeplenkle nicht wichtig):
im Thema Watchdog, At und Notify bin ich zwar Einzwischenzeit ganz Fit sowie auch Perl,
aber die Tage habe ich mal bewusst das DOIF begonnen zu nutzen.

Code Inhalt (Falls jemand das bereits funktionierende Beispiel mal gebrauchen kann, hier die Zusammenfassung):
Der nachfolgende Code wird ein Ausgang des ELTAKO-FSR14-4x Bus-Schaltaktor (in dem fall ein baugleiches Model von OPUS) gesteuert (Licht Garten), dieser wird durch ein Bewegungsmelder ausgelöst, der im minimum 15 sek. ein Signal auf einem ELTAKO FTS14 EM (10 Fach Eingangsmodul) setzt.
Ist das Licht aus und wird eine Bewegung erkannt, so wird das licht eingeschaltet.
Ist der Bewegungsmelder nach 15 sek. aus und wird innerhalb von weiteren 25 Sek. (DOIF Konfigurierbare Zeit) nicht mehr eingeschaltet, so geht das Licht aus.

Frage (Grund für das Thema):
Für dieses Beispiel werde ich es evtl. noch nicht brauchen, aber mir geht es um das Prinzip für nachfolgende Umsetzungen.
Ich habe im Code einen Aktor und einen Sensor angegeben. Dieser wird im Code immer wieder vorkommen, daher würde ich diesen gerne Parametrisierbar machen.
Ich dachte hierbei das ich den Namen des Aktors und Sensors in Attribute Speicher "DeviceActor" "DeviceSensor" wenn ich alles in Perl Form schreibe dann wüsste ich wie.
Aber ich würde es gerne in der DOIF Form belassen. Da man dort schön SET CheckAll und co auslösen kann.

Kann mir jemand ein Beispiel für den CodePart nennen?
Dabei muss OPUS_GN20ARSR4_01_A02 gegen den Wert aus Attribut "DeviceActor" ersetzt werden.
Bissher habe ich noch keine Idee wie und auch nichts dazu gefunden. Ich bekomme aktuell bei meinen Versuchen nur Errors oder keine Reaktionen ausgegeben.

Code Auswählen Erweitern

[OPUS_GN20ARSR4_01_A02:state] eq "off" and


Code:

Code Auswählen Erweitern

##Bedingung 1
(
    ##Wenn Aktor nicht AN UND
    ##Wenn Sensor nicht Aktiv dann
    [OPUS_GN20ARSR4_01_A02:state] eq "off" and
    [ELTAKO_FTS14EM_01_E01:buttons] eq "pressed"
)

##Aktion 1
(
    ##Dann aktiviere Aktor
    set OPUS_GN20ARSR4_01_A02 on
)

##Bedingung 2
DOELSEIF
(
   ##Wenn zuvor Bedingung 1 ausgelöst wurde (Readings cmd = 1) UND
   ##Wenn der Sensor nicht mehr aktiv ist dann
   [$SELF:cmd] eq "1" and
   [ELTAKO_FTS14EM_01_E01:buttons] eq "released"
)

##Aktion 2
(
    ##Dann setze den Aktor Zeitverzögert zurück (Siehe auch Attribut do=resetwait und wait)
    set OPUS_GN20ARSR4_01_A02 off
)

[Damian]

Indirekte Timer gibt es in DOIF, allerdings bisher keine indirekten Device-Angaben als Trigger.

[Ellert]

Über einen Umweg gibt es eine Möglichkeit - für Raw definition

Code Auswählen Erweitern

defmod indirektDOIF DOIF ([$SELF:I_value] eq "on") {Log 1,"$DEVICE: $EVENT von [$SELF:I_ndirect]"}
attr indirektDOIF DOIF_Readings I_value:[@"^(du1|du3|du5)$"];;ReadingsVal([$SELF:I_ndirect],"state","error")
attr indirektDOIF uiTable WID([$SELF:I_ndirect],"du1,du3,du5")

Über uiTable wird ein Widget mit den Gerätenamen erzeugt, das den ausgewählten Gerätenamen in das Reading I_ndirect schreibt.

du1, du3, du5 sind die Gerätenamen, die müssen angepasst werden auf die OPUS-Namen.

Mit DOIF_Readings wird ein Reading I_value erzeugt, dass durch alle angegebenen Geräte getriggert wird [@"^(du1|du3|du5)$"], aber nur , wenn der Wert von ReadingsVal sich ändert. ReadingsVal liest nur den Wert des ausgewählten Gerätes.

[Damian]

Ganz schön tricky und damit recht umständlich.

Wäre die Verwendung von Templates nicht eine bessere Wahl?

https://wiki.fhem.de/wiki/Template

[Ellert]

An template hatte ich auch zuerst gedacht, habe den initialen Beitrag dann doch so verstanden, dass die Auswahl zur Laufzeit erfolgen soll.

[LHBL2003]

Hi,

Die Antworten von Damian zielen schon auf meine Frage.

,,Indirekte Timer gibt es in DOIF, allerdings bisher keine indirekten Device-Angaben als Trigger."
Vereinfacht gesagt: Platzhalter für Timer gibt es, aber für Device Namen nicht.

Das mit dem Template ist eine interessante Sache, die ich noch nicht kannte und mir mal die Tage anschauen werde.
Allerdings ist es dann weiterhin so, das ich nicht einfach den Code 1:1 auf ein anderes bestehendes DOIF rüber kopieren kann. Denn die Device Namen stehen dann doch wieder im Code und nicht in der Attr. Konfiguration.

Danke schön mal für die Vorschläge / Workarounds , dennoch würde mich die erste saubere Variante für die Zukunft am meißen interessieren evtl. geht das anderen auch so.

Gruß

[Damian]

Der Wunsch eine DOIF-Definition zu "generalisieren" ist nicht neu. Man kann so etwas z. B. wie folgt realisieren:

Zuerst braucht man eine Regex-Definition, die alle vorkommenden Fälle abdeckt. Im zweiten Schritt kann man dann das triggernde Device auswerten und mit einem Dummy oder Attribut, wo das relevante Device abgelegt ist, vergleichen.

Bsp.

Code Auswählen Erweitern

(["^Opus"] and "$DEVICE" eq [devicedummy] and [$DEVICE:state] eq "on") (....)

Damit würde das Modul auf alle Devices, die hier mit Opus beginnen triggern und das triggernde Opus-Device mit dem im devicedummy abgelegten Opus-Device vergleichen.

Damit reagiert das DOIF-Device nur auf das Device, welches sich gerade im entsprechenden Dummy oder auch im Attribut befindet.

[LHBL2003]

Hi,

das Thema ist zwar schon ein Jahr her, aber die passende Lösung war ja noch nicht dabei. Daher möchte ich erneut mal nachfragen, ob es inzwischen etwas dazu gibt.

Wie gehabt, möchte ich im DOIF Code die Device Namen zum vergleich aus den Attribut Feldern des DOIFs beziehen um den Namen nur einmalig schreiben zu müssen:

Ausgangssituation:

Code Auswählen Erweitern


##Bedingung 1
(
    ##Wenn Aktor nicht AN UND
    ##Wenn Sensor wurde aktiviert dann
    [OPUS_GN20ARSR4_01_A02:state] eq "off" and
    [ELTAKO_FTS14EM_01_E01:buttons] eq "pressed"
)

##Aktion 1
(
    ##Dann aktiviere Aktor
    set OPUS_GN20ARSR4_01_A02 on
)



evtl. so die Umsetzung:

##Bedingung 1
(
    ##Wenn Aktor nicht AN UND
    ##Wenn Sensor wurde aktiviert dann
    [[$SELF:AttributNameRelai]:state] eq "off" and
    [[$SELF:AttributNameTaster]:buttons] eq "pressed"
)

##Aktion 1
(
    ##Dann aktiviere Aktor
    set [$SELF:AttributNameRelai] on
)

[Damian]

Da muss ich dich enttäuschen. An der Stelle hat sich im Modul nichts geändert. Es gelten immer noch die vorgeschlagenen Varianten hier als Alternative.

[Ellert]

Statt [devicedummy] könntest Du auch ein im DOIF selbst angelegtes Attribut mit AttrVal abfragen.