[gelöst]Aktion abhängig von dummy Gerät triggern ...

Begonnen von llinus76, 29 Dezember 2023, 20:47:32

Vorheriges Thema - Nächstes Thema

llinus76

Liebe Community,

irgendwie stehe ich gerade komplett am Schlauch, oder es ist schon zu spät für mich :o . Ich habe ein Gerät vom Typ dummy und das hat Argumente die aktionen triggern sollen
ZitatInternals:
   FUUID      658dce2d-f33f-54a3-874d-b11b54eb5f451789
   NAME       aWATTar
   NR         387
   STATE     
   TYPE       dummy
   eventCount 8
   READINGS:
     2023-12-29 17:21:39   ZeitfensterInH  2
     2023-12-29 17:21:30   mittelwertGesamt 2.37
     2023-12-29 17:21:27   mittelwertOpt   .57
     2023-12-29 17:21:33   mittelwertRest  2.5
     2023-12-29 17:21:36   startzeit       2023-12-30 03:00:00
Attributes:
   group      Boiler

Ich würde jetzt gerne, wenn die Startzeit erreicht, ist ein Event für die Dauer von ZeitfensterInH triggern. In meinem Fall also am 2023-12-30 um 03:00:00 eine Steckdose für 2 Stunden einschalten und danach wieder aus.

Ich habe da bei at und notify geschaut, aber irgendwie bekomme ich das nicht gelöst ...  >:( . Ich zweifel gerade an mir  :-[ .

Kann mir da ev. wer unter die Arme greifen, das wäre toll ...

Danke und lG,
Martin

Aurel_B

Viele Wege führen nach Rom, ich arbeite viel mit DOIFs. Z.B. kannst du im DOIF mit Zeitangaben aus einem Reading arbeiten (siehe https://wiki.fhem.de/wiki/DOIF/Perl-Modus#Zeittrigger), also "[[<device>:<reading>]]".

Dafür müsste dein Reading allerdings in einem Format sein, dass DOIF versteht.

Otto123

#2
Hallo Martin,

ich beschreibe es mal verbal, nur laut gedacht nicht getestet:
Ein notify auf den Event
define Test_notify_1 notify aWATTar:startzeit:.* {}Im Ausführungsteil ein define a_timer at ... mit sowas $EVTPART1.'T'.$EVTPART2 siehe help at
Im Ausführungsteil des at ein set Dose on ; sleep ReadingsNum('aWATTar','ZeitfensterInH',0) * 3600 ; set Dose off
Oder set Dose on-for-timer ...

Edit: So in der Art: (getestet)
defmod Test_notify_1 notify aWATTar:startzeit:.* {my $string= $EVTPART1.'T'.$EVTPART2;; fhem("defmod test_at at $string set SD3 on-for-timer {(ReadingsNum('aWATTar','ZeitfensterInH',0) * 3600)}") }

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

llinus76

Hallo Otto,

na bist du ..., das ist ja genial!!!! Genau das habe ich gesucht und es funktioniert perfekt!

Ich Danke dir!

LG und schönen Abend,
Martin

Otto123

Hi,

im neuen Jahr nochmal nachgedacht gibt es eine kürzere Schreibform, die allerdings auch etwas "schräg" aussieht:
defmod Test_notify_1 notify aWATTar:startzeit:.* defmod test_at at $EVTPART1T$EVTPART2 set SD3 on-for-timer {([aWATTar:ZeitfensterInH]*3600)}Der hintere Teil ist eine andere Schreibform des set magic - set magic finden hier im Forum an sich einige etwas schräg. ;)
Der vordere Teil funktioniert mMn nur, weil fhem mit $EVTPARTx eine Textersetzung macht und nicht wirklich im Code Variablen auflöst. Mit Perl Variablen in einem Perl Ausdruck könnte man das so auch schreiben: "${EVTPART1}T${EVTPART2}" oder eben so wie schon in meinem Beispiel mit den Punkten.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

llinus76

Hi Otto,

cool, danke - schaue ich mir am WE gleich mal an.

Danke dir und lG,
Martin

llinus76

Guten Morgen Otto,

ich habe deine neue Variante eben getestet und auch diese funktioniert einwandfrei, wie erwartet  ;D . Ich würde auf die neue Version umsteigen, denn dein Kommentar, "Der vordere Teil funktioniert mMn nur, weil fhem mit $EVTPARTx eine Textersetzung macht und nicht wirklich im Code Variablen auflöst." klingt für mich so, als dass sich da das Verhalten bei einem zukünfigen fhem Upgrade ändern könnte.

Siehst du das auch so, oder was ist deine Empfehlung?

Danke und lG,
Martin

rudolfkoenig

Zitatklingt für mich so, als dass sich da das Verhalten bei einem zukünfigen fhem Upgrade ändern könnte.

Ich sehe z.Zt. keinen Grund, daran was zu aendern.

Wenn mich doch jemand umstimmen sollte:
- wird das in UPGRADE bekanntgegeben
- wird die "alte" Schreibweise mit "attr global featurelevel 6.3" (oder vgl.) noch viele Jahre moeglich sein.