Zwei Weekday-Timer zusammenführen

Begonnen von stephan20, 22 Mai 2020, 23:14:18

Vorheriges Thema - Nächstes Thema

stephan20

Hallo Zusammen,

im Zuge meines Urlaubes erweitere ich meine FHEM Installation etwas. Dabei bin ich auf meine zwei Weekday-Timer gestoßen, die meine Rolläden steuern. Da ich Dienstags bis Freitags arbeite, gehen die Rollos deutlich früher hoch als an den arbeitsfreien Tagen Samstag bis Montag. Ich möchte nun in einem Doif den State der Rollotimer benutzen und muss daher beide Timer zusammenführen. Dazu bin ich eindeutig zu doof  ::) Gibt es eine Möglichkeit zwei Bedingungen in einem Weekday-Timer zu nutzen?

Hier die Definitionen von beiden Timern:

Dienstag-Freitag
TYPE=DUOFERN:FILTER=duskAutomatic=off de 2345|{sunrise_abs("REAL",0,"07:45","09:00")}|up 2345|{sunset_abs("CIVIL",-900,"16:00","23:00")}|down {fhem ("set $NAME:FILTER=STATE!=$EVENT $EVENT")}

Samstag-Montag
TYPE=DUOFERN:FILTER=duskAutomatic=off de 1607|{sunrise_abs("REAL",0,"13:00","13:30")}|up 1607|{sunset_abs("CIVIL",-900,"16:00","23:00")}|down {fhem ("set $NAME:FILTER=STATE!=$EVENT $EVENT")}

Freue mich über jede Hilfe.

Grüße aus Oberhausen

Stephan

Beta-User

Hi,

warum sollte das nicht gehen?

z.B. so:
TYPE=DUOFERN:FILTER=duskAutomatic=off de 2345|{sunrise_abs("REAL",0,"07:45","09:00")}|up|w 2345|{sunset_abs("CIVIL",-900,"16:00","23:00")}|down|w 1607|{sunrise_abs("REAL",0,"13:00","13:30")}|up 1607|{sunset_abs("CIVIL",-900,"16:00","23:00")}|down {fhem ("set $NAME:FILTER=STATE!=$EVENT $EVENT")}

Anmerkungen:
- Das "|w" bewirkt, dass 2-5 am $we nicht ausgeführt werden;
- "1607" ist in den meisten Fällen gleichbedeutend mit "17", denn "06" wird ohne spezielle Einstellungen in global-holiday2we als $we bewertet;Frage zu "1": Falls der Mo generell (systemweit) wie $we behandelt werden soll, kann man das über entsprechende Einstellungen an global-holiday2we iVm. einem passenden holiday-Device (oä). steuern.
- über die Spracheinstellung in global wird auch der WDT konfiguriert, wenn man das nicht (wie hier) im einzelnen WDT angibt.
- ob es im Ausführungsteil Perl braucht, sei mal dahingestellt, man könnte das z.B. auch in das commandTemplate in der normalen Form schreiben.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

stephan20

Hi Beta-User

vielen Dank! Das war mir nicht klar, dass ich einfach mehrere Argumente vor dem Ausführungsteil aneinanderreihen kann. Manchmal sollte man sich einfach trauen und Dinge ausprobieren. Aber seit mir vor gut einem Jahr meine ganze FHEM Installation durch eine Verkettung sehr unglücklicher Umstände den Bach runtergegangen ist, bin ich viel zu vorsichtig geworden.

Danke für die hilfreichen Tipps, werde mir diese genauer ansehen. Der Montag sollte aber nicht systemweit als $we behandelt werden, da ich diverse Timer auch noch für den Außenbereich nutze (Bewässerung etc.), die stört es nicht, wenn ich mal länger schlafe ;-)

Bringt die Nutzung von Perl im Ausführungsteil irgendwelche Nachteile mit sich? Ich habe das wohl sicher mal irgendwo aus dem Forum übernommen.

Gruß
Stephan

Beta-User

Nachteile sehe ich keine, wenn man Perl nimmt, meine eigenen sind auch ganz oft "Perl-oneliner". Bin nur grade am Überlegen, ob es nicht Sinn machen würde, diesen FILTER ($NAME:FILTER=STATE!=$EVENT) per Attribut allgemein verfügbar zu machen, da ich grade eh' dabei bin, am WDT was rumzuschrauben... Mal schauen.

(Testversion gibt's hier: https://forum.fhem.de/index.php/topic,111401.0.html)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files