Hauptmenü

[gelöst] holiday2we

Begonnen von Vize, 05 Mai 2020, 08:06:07

Vorheriges Thema - Nächstes Thema

Vize

Guten Morgen,

in diesem Faden klick
hatte ich eine Frage zu holiday2we in Verbindung mit DOIF gestellt und mir wurde empfohlen, das Thema noch einmal hier zu starten.
Sorry, ging zeitbedingt nicht eher...

Situation:
Da ich für längere Zeit freitags frei habe, habe ich meine Jalousiensteuerung angepasst, damit diese nun freitags zu den späteren Zeiten wie am Wochenende öffnen sollen.
Im DOIF sieht das so aus:
([{sunrise(900,"06:15","08:30")}|1234] or [{sunrise(900,"08:15","09:30")}|57])
Dadurch sollten die Jalousien doch montags bis donnerstags "früh" öffnen und freitags und am Wochenende später, richtig?

Nun hatte ich in folgender Zeit Urlaub und habe das auch in der holiday-Datei eingetragen:
4 04-13 04-16 Urlaub

Das globale Atrribut holidy2we verweist auch auf das entsprechende Device.

Das holiday Device (aus der Urlaubswoche):
Internals:
   NAME       nrw
   NR         30
   STATE      Urlaub
   TRIGGERTIME 1587074402.37055
   TYPE       holiday
   READINGS:
     2020-04-16 00:00:02   state           Urlaub
     2020-04-16 00:00:02   tomorrow        none
     2020-04-16 00:00:02   yesterday       Urlaub
Attributes:


Mich hatte dann gewundert, dass die Jalousien an diesem Tag (Urlaub) um 06:15 Uhr geöffnet haben...

Wo ist mein (Denk)Fehler oder sehe ich vielleicht nur den Wald vor lauter Bäumen nicht?
Stehe bisher irgendwie auf dem Schlauch...

Vielleicht kann mir hier jemand weiter helfen?

Vielen Dank schonmal für jegliche Tipps und Hilfe!

PS Ich habe (leider) schon länger kein Update mehr gemacht, daher weiß ich nicht, ob sich "DOIF-intern" diesbezüglich etwas geändert hat...

VG
Andreas


Beta-User

Die Frage war mMn. beantwortet:
Zitat von: Beta-User am 16 April 2020, 09:21:57
"Vermutlich" ist auch heute "4", aber DOIF kenne ich ansonsten nicht und kann dir daher nicht sagen, wie man da die Zusatzbedingung !$we reinbringt.
Zitat von: Vize am 05 Mai 2020, 08:06:07
([{sunrise(900,"06:15","08:30")}|1234] or [{sunrise(900,"08:15","09:30")}|57])
Dadurch sollten die Jalousien doch montags bis donnerstags "früh" öffnen und freitags und am Wochenende später, richtig?
Genau: UND = AUCH...
Du mußt aber das UND auch in die erste Abfrage mit integrieren, wenn es heißen soll:
(Montag bis Donnerstag, aber nicht am WE) ODER (freitags und am WE)...

Alternativ kannst du für so ein starres Modell auch den WeekdeyTimer verwenden, der kann das "aber nicht am WE" mit einem zusätzlichen "|w"-Parameter: https://fhem.de/commandref_modular.html#WeekdayTimer

Insgesamt ist es für Rollladensteuerung mMn. lohnenswert, einen Blick auf AutoShuttersControl zu werfen. Da kann man das ganze anwesenheitsbasiert abbilden, wenn man Residents&Co nutzt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Vize

OK,

danke für die Antwort...der Wald ist schonmal etwas lichter geworden.

Aber wie bringe ich nun !$we in die erste Abfrage?  :-[

Anwesenheitsbedingte Steuerung macht für meinen Anwendungsfall keinen Sinn, da noch andere Faktoren mit hinein spielen.
WeekdayTimer schaue ich mir mal an, aber es würde mich schon interessieren, ob und wie man es mit einem DOIF abbilden kann.

VG
Andreas

Beta-User

Wie an anderer Stelle geschrieben: Bin völlig unbeleckt, was DOIF angeht und finde mich in der Doku zu dem Modul auch nicht wirklich zurecht...

Hätte mal getippt, dass es so gehen müßte:
(([{sunrise(900,"06:15","08:30")}|1234] and !$we) or [{sunrise(900,"08:15","09:30")}|57])

In jedem Fall solltest du dich besser einarbeiten. Solche logischen Fehler/Mißverständnisse fallen dir sonst ständig vor die Füße...

Und "andere Faktoren" kann ich an dem DOIF keine ablesen, wenn das also stimmen sollte, unterliegt das dem Verdacht, dass es irgendwie "von hinten durch die Brust ins Auge" gelöst ist...

Just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Vize

Zitat von: Beta-User am 05 Mai 2020, 10:53:11Und "andere Faktoren" kann ich an dem DOIF keine ablesen, wenn das also stimmen sollte, unterliegt das dem Verdacht, dass es irgendwie "von hinten durch die Brust ins Auge" gelöst ist...

Hi,

wollte damit nur zum Ausdruck bringen, dass die Schaltung der Jalousien nicht alleinig von meiner Anwesenheit abhängig ist.
Eine Abfrage meiner Anwesenheit spielt in diesem "DOIF-Fall" sogar gar keine Rolle. Weiß nicht, wie ich es hier besser ausdrücken soll...tippen ist immer schwieriger, als es jemanden "mündlich" zu beschreiben, finde ich.
Weitere Bedingungen gibt es in diesem DOIF auch nicht...aber egal...das führt jetzt zu weit weg...  ;)

VG
Andreas

Vize

Zitat von: Beta-User am 05 Mai 2020, 10:53:11
Hätte mal getippt, dass es so gehen müßte:
(([{sunrise(900,"06:15","08:30")}|1234] and !$we) or [{sunrise(900,"08:15","09:30")}|57])

Ahoi,

das war der richtige Tipp.
Danke dafür!

Heute getestet - Urlaubstag - und es funktioniert, die Jalousien fuhren um 08:15 hoch...  8)

Habe da noch eine Frage zum Verständnis. Wird in DOIF eigentlich strickt nacheinander geprüft, sprich erst die erste Bedingung, wenn die dann schon "wahr" ist, die zweite dann nicht mehr?
Bezogen auf mein Beispiel: Wenn ich das !$we in der ersten Bedingung weglasse, wird geprüft, ob heute Mo, Di, Mi oder Do ist. Das ist wahr, also fahren die Rolläden um 06:15 hoch.
Die zweite Bedingung - Freitag oder Wochenende - wird dann nicht mehr beachtet?
Baue ich !$we ein, wird in der ersten Bedingung geprüft, ob heute Mo, Di, Mi oder Do UND kein Wochenende ist. Das ist falsch, also greift die zweite Bedingung und die Rolläden fahren um 08:15 hoch.

Müsste das ganze Konstrukt dann nicht auch ohne !$we funktionieren, wenn ich es einfach "umdrehe":
([{sunrise(900,"08:15","09:30")}|57] or [{sunrise(900,"06:15","08:30")}|1234])

Vielen Dank nochmal für die Unterstützung und Hilfe zur Lösung!

VG
Andreas

Beta-User

Zitat von: Vize am 19 Mai 2020, 10:21:41
Ahoi,

das war der richtige Tipp.
Danke dafür!
Danke für die Rückmeldung.

ZitatHabe da noch eine Frage zum Verständnis. Wird in DOIF eigentlich strickt nacheinander geprüft, sprich erst die erste Bedingung, wenn die dann schon "wahr" ist, die zweite dann nicht mehr?
Bezogen auf mein Beispiel: Wenn ich das !$we in der ersten Bedingung weglasse, wird geprüft, ob heute Mo, Di, Mi oder Do ist. Das ist wahr, also fahren die Rolläden um 06:15 hoch.
Die zweite Bedingung - Freitag oder Wochenende - wird dann nicht mehr beachtet?
Baue ich !$we ein, wird in der ersten Bedingung geprüft, ob heute Mo, Di, Mi oder Do UND kein Wochenende ist. Das ist falsch, also greift die zweite Bedingung und die Rolläden fahren um 08:15 hoch.

Müsste das ganze Konstrukt dann nicht auch ohne !$we funktionieren, wenn ich es einfach "umdrehe":
([{sunrise(900,"08:15","09:30")}|57] or [{sunrise(900,"06:15","08:30")}|1234])

Vielen Dank nochmal für die Unterstützung und Hilfe zur Lösung!

VG
Andreas
Wie gesagt: eigentlich habe ich keine Ahnung von DOIF. Afaik wird nur "stur von oben nach unten" geprüft, wenn man DOELSIF (?) verwendet. Der erste passende Zweig wird ausgeführt, und dann hat es sich. Vermutlich ließe sich dein dingsda auch entsprechend umbauen.

Hier ist es aber was anderes, da wird afaik immer "alles" (in dem Zweig) geprüft, und ganz allgemein ist es bei "or" eben immer so, dass bei der ersten passenden Bedingung ausgeführt wird und nicht weiter geprüft. Da hier aber "vorne" die Uhrzeit nicht gepaßt hätte, wäre auch die "Frühfahrt" durchgeführt worden, denn es ist ja immer noch "4"...

(Aber was hindert dich daran, sowas selbst auszutesten? Einfach das Ergebnis z.B. in einen Dummy schicken oder loggen. Generell noch: mMn. ist DOIF nicht wirklich einsteigerfreundlich; das ganze ist eher eine Zustandsmaschine und daher nicht mehr gut zu überblicken, wenn man mehrere Zweige hat. Außerdem kann sich die Funktionsweise mit diversen Attributen komplett verändern. Mir ist wirklich linear zu lesender Code daher lieber und ich verwende für solche kleinen Aufgaben auch lieber "Spezialisten" (bzw. für Rollladensteuerung eben AutoShuttersControl).)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Otto123

Hallo Andreas,
ZitatWird in DOIF eigentlich strickt nacheinander geprüft
DOIF prüft die einzelnen Zweige von "oben" nach "unten" - ist der erste "wahre" gefunden werden die anderen nicht mehr geprüft. Steht irgendwo auch so in der Doku :)
Innerhalb der Bedingung geht es im wesentlichen nach Perl https://perldoc.perl.org/perlop.html#Operator-Precedence-and-Associativity

Edit: Beta-User war schneller - ich lasse es trotzdem :)

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

Vize

Super, danke euch beiden!

Das erhellt schonmal einiges.
Wenn ich mal Zeit und Muße haben, werde ich mal weiter ausprobieren...z.B. mit dummies...

Schönen Tag noch und viele Grüße
Andreas