FHEM Forum

Hallo,

ich mache an vielen Stellen Gebrauch von $twe.

Toll wäre es, wenn ich per Tastendruck (am Liebsten im Rahmen eines DOIFs) den nächsten Tag als "Wochenende/Feiertag" definieren könnte.
Wenn z.B. jmd. krank wird, soll er einfach dafür sorgen können, dass die Automatismen, die sonst am Wochenende vorherrschen auch am nächsten Tag anzutreffen sind.

Hat das evtl. schon Einer von Euch gemacht und kann mir helfen?

Gruß Chris

Grobe Skizze einer Idee:
- eine urlaub holday Instanz definieren, sie zu holiday2we hinzufuegen
- dummy mit Knopf definieren, eine notify darauf ersetzt die holiday Datei, und liest sie neu ein mit "set urlaub refresh"
- holiday Datei ersetzen: "echo 1 `date --date=tomorrow +%m-%d` Urlaub > FHEM/urlaub.holiday" (braucht das unter Linux uebliche gnu date)

Das ist für mich als Laie leider zu schwierig. Da ich etwas ganz Einfaches erreichen möchte, gehe ich (noch ::) ) davon aus, dass es auch leicht umzusetzen ist.

Gruß Chris

Zitat von: chq am 08 März 2019, 09:38:22
Das ist für mich als Laie leider zu schwierig. Da ich etwas ganz Einfaches erreichen möchte, gehe ich (noch ::) ) davon aus, dass es auch leicht umzusetzen ist.

Gruß Chris

eine andere möglichkeit wirst du wohl nicht haben , wenn du mit der $twe arbeiten möchtest.

es ist nicht kompliziert und geht wie von rudolf angedeutet.

habe es eben mal gebaut , mit der holidayinstanz 'FREE'.

im Grunde musst du es nur abschreiben , oder für dummy und notify ( oder DOIF ) umbauen. Ich habe es mit Mswitch umgesetzt.

gruss Byte09

Statt { system("cmd") } empfehle ich "cmd", weil es kuerzer ist, und FHEM nicht blockiert.

Zitat von: rudolfkoenig am 08 März 2019, 09:21:17
Grobe Skizze einer Idee:
- eine urlaub holday Instanz definieren, sie zu holiday2we hinzufuegen
- dummy mit Knopf definieren, eine notify darauf ersetzt die holiday Datei, und liest sie neu ein mit "set urlaub refresh"
- holiday Datei ersetzen: "echo 1 `date --date=tomorrow +%m-%d` Urlaub > FHEM/urlaub.holiday" (braucht das unter Linux uebliche gnu date)

- Und dann noch ein Reload auf das holiday-Device damit die neuen Daten auch eingelesen werden?

Yeah, man sollte auch alles lesen ... müsste allerdings set urlaub reload heißen, nicht refresh.

Hab es mal gebaut, für copy and paste:
Die Symbole sind nur Beispielhaft und sollen bloß das Feedback beim Tastendruck geben.

zunächst das Attribute in global setzen oder wenn vorhanden mit Komma getrennt ergänzen!
attr global holiday2we urlaub
Der Zweite Teil für die Raw Def

defmod nty_MorgenUrlaub notify MorgenUrlaub:(set|del) {\
    if ($EVENT eq "set") {qx(echo 1 `date --date=tomorrow +%m-%d` Urlaub > FHEM/urlaub.holiday)};;\
    if ($EVENT eq "del") {qx(echo " " > FHEM/urlaub.holiday)};;\
fhem("set urlaub reload;;set MorgenUrlaub _$EVENT")\
}
attr nty_MorgenUrlaub room Test

defmod MorgenUrlaub dummy
attr MorgenUrlaub devStateIcon _del:system_fhem:set _set:RPi:del
attr MorgenUrlaub room Test
attr MorgenUrlaub webCmd del:set
set MorgenUrlaub del

defmod urlaub holiday
attr urlaub room Test


@Rudi: Dein Einwand funktioniert nicht, weil "cmd" die Pipe nicht unterstütz! Die Datei bleibt dann leer  :-[

Gruß Otto

Zitat von: Otto123 am 08 März 2019, 10:33:46zunächst das Attribute in global setzen oder wenn vorhanden mit Komma getrennt ergänzen!

Wenn ich bereits ein Holidaydevice namens "bwFeiertageUrlaub" habe und dieses auch bereits unter global -> attr -> holiday2we eingetragen ist, sollte ich dann sinnvollerweise auch dieses Holidaydevice für mein Vorhaben verwenden, sprich ich kann diesen Schritt überspringen?

Zitat von: Otto123 am 08 März 2019, 10:33:46Der Zweite Teil für die Raw Def

Bzgl. "Raw Def" hab ich zwar das hier (https://wiki.fhem.de/wiki/Import_von_Code_Snippets (https://wiki.fhem.de/wiki/Import_von_Code_Snippets)) gefunden, kann dies aber nicht in Einklang mit dem von Dir angegebenen Code bringen. Von wo aus muss ich denn in diese Raw Def springen, um den Code dann dort einzutragen? Müsste ich mir hierfür zuerst ein Notify erstellen?

Wäre im Hinblick darauf, dass mein Holidaydevice ja "bwFeiertageUrlaub" heisst, das dann der richtige Code für mein Vorhaben? Ich habe lediglich "urlaub" durch "bwFeiertageUrlaub" ersetzt.

defmod nty_MorgenUrlaub notify MorgenUrlaub:(set|del) {\
    if ($EVENT eq "set") {qx(echo 1 `date --date=tomorrow +%m-%d` Urlaub > FHEM/bwFeiertageUrlaub.holiday)};;\
    if ($EVENT eq "del") {qx(echo " " > FHEM/bwFeiertageUrlaub.holiday)};;\
fhem("set bwFeiertageUrlaub reload;;set MorgenUrlaub _$EVENT")\
}

Gruß Chris

Zitat von: chq am 08 März 2019, 09:07:22
Hallo,

ich mache an vielen Stellen Gebrauch von $twe.

Toll wäre es, wenn ich per Tastendruck (am Liebsten im Rahmen eines DOIFs) den nächsten Tag als "Wochenende/Feiertag" definieren könnte.
Wenn z.B. jmd. krank wird, soll er einfach dafür sorgen können, dass die Automatismen, die sonst am Wochenende vorherrschen auch am nächsten Tag anzutreffen sind.

Hat das evtl. schon Einer von Euch gemacht und kann mir helfen?

Gruß Chris

Du kannst es auch einfach beim DOIF über eine indirekte Wochentagangabe realisieren.

Wenn du eine Zeit für Wochenende definiert hast z. B. DOIF ([10:00|7])..., dann kannst du statt der 7 einen Dummy oder ein Reading angeben, welches du entsprechend ändern kannst

z. b.

DOIF ([10:00|[Wochentag]])...

mit set Wochentag 7 wird nur am Wochenende geschaltet

mit set Wochentag 78 wird am Wochenende und an Arbeitstagen geschaltet, also immer

ZitatWenn ich bereits ein Holidaydevice namens "bwFeiertageUrlaub" habe und dieses auch bereits unter global -> attr -> holiday2we eingetragen ist, sollte ich dann sinnvollerweise auch dieses Holidaydevice für mein Vorhaben verwenden, sprich ich kann diesen Schritt überspringen?

Nein!
Die Idee beruht darauf einen zweiten holiday2we anzulegen, der beliebig modifiziert wird. Die Datei wird von dem notify überschrieben! Also probiere dein notify besser nicht!

Ich hab es doch so geschrieben? Wenn vorhanden mit Komma ergänzen.
attr global holiday2we bwFeiertageUrlaub,urlaub

Du kannst irgendeine Raw Def aufmachen, unter irgendeinem Gerät von mir aus unter global.
Den Inhalt im Fenster markieren und löschen, anschließend meinen Code hinkopieren und dann unten execute drücken.

Gruß Otto

Zitat@Rudi: Dein Einwand funktioniert nicht, weil "cmd" die Pipe nicht unterstütz! Die Datei bleibt dann leer

Kann nicht nachvollziehen:
- erstens wollte ich kein pipe
- zweitens wird "" auch mit system implementiert, es wird nur '>> $currlogfile 2>&1 &' angehaengt
- drittens funktioniert Folgendes (gerade getestet):fhem> ":> FHEM/urlaub.holiday"
fhem> define urlaub holiday
fhem> define n notify n "echo 1 `date --date=tomorrow +%m-%d` Urlaub > FHEM/urlaub.holiday";;set urlaub reload
fhem> trigger n n
fhem> l urlaub
Internals:
   FUUID      5c824b35-f33f-c296-74dd-9c8de5e9e201dd75
   HOLIDAYFILE ./FHEM/urlaub.holiday
   NAME       urlaub
   NR         6
   READONLY   0
   STATE      none
   TRIGGERTIME 1552086002.53953
   TYPE       holiday
   READINGS:
     2019-03-08 12:03:44   state           none
     2019-03-08 12:03:44   tomorrow        Urlaub
     2019-03-08 12:03:44   yesterday       none
Attributes:





@Otto123
Wie muss das Ganze denn aussehen, damit es auch mit der holiday-Datei innerhalb von configdb funktioniert?

hat denn die Einbindung einer Holiday Datei irgendetwas mit configdb zu tun? configdb ist doch die config.
Wo die drei Definitionen stehen ist doch egal.

Oder wird denn die holiday Datei als solche auch in der configdb abgelegt?
Edit:
Hab was gefunden: https://forum.fhem.de/index.php?topic=86243.15

Sorry, da ich keine configdb habe, kann ich da nicht helfen.  Aber von der Idee her, muss das dann "nur" der Befehl nicht die Datei sondern den Inhalt in der configdb modifiziert werden.  Eventuell gibt es da ganz andere Möglichkeiten?

Ja, genau wie du schon berichtigt hast wird die holiday-Datei in der configdb abgelegt.
Die Textdate im Filesystem kann nach dem einmaligem Import gelöscht werden.

Jedoch erzeugt mit das Notify, bzw. der echo-ommand darin eine neue Textdatei im Dateisystem.

Habe eine einfache Lösung gefunden:
Im Notify wird einfach zum Schluss jedesmal die Text-holiday-Datei wieder in die configdb importiert.
configdb fileimport /opt/fhem/FHEM/urlaubstag.holiday

Kannst auch gleich filemove statt fileimport nehmen, damit wird nach Import die Datei vom Filesystem entfernt.

gb#

Zitat von: rudolfkoenig am 08 März 2019, 09:21:17
Grobe Skizze einer Idee:
- holiday Datei ersetzen: "echo 1 `date --date=tomorrow +%m-%d` Urlaub > FHEM/urlaub.holiday" (braucht das unter Linux uebliche gnu date)

Dann ist aber nächstes Jahr zum gleichen Datum wieder arbeitsfrei, wenn man nicht daran denkt, "übermorgen" das holiday file wieder zu leeren.

Eine Lösung, mit der AnalyzePerlCommand() das $we flexibler ermitteln würde, fände ich besser. Muss jetzt zum Kochclub, vielleicht fällt mir während des Schnippelns was dazu ein :)

Die einfache Lösung mit dem Import war mir auch im Kopf, aber die habe ich mir nicht getraut zu sagen. Der Gedanke - dass Daten, die in einer DB stehen, dadurch aktualisiert werden, dass ich ich einen File erzeuge und den importiere - ist mir irgendwie etwas schräg. Ich würde irgendwie versuchen die Daten in der DB direkt zu schreiben.
Aber manchmal zählt ja nach Außen erstmal das Ergebnis  ;)

Hallo Ihr Spezialisten
muss es so aufwändig sein?
Ich habe es mit einem einfachen Dummy gelöst.
define WeckerAktivDummy dummy
und
webCmd on:off
das es etwas schöner aussieht noch:
attr WeckerAktivDummy devStateIcon on:general_an_fuer_zeit@orange off:general_aus_fuer_zeit@grey
und dann im eigentlichen DOIF Wecker die Abfrage
.... and [WeckerAktivDummy] eq "on" ....
Damit sehe und schalte ich jetzt am Tag vor dem freien ob mein Wecker mich nicht wieder mal an einem freien Tag unnötig wecken wird.
Natürlich macht die holiday Datei die festen Feiertage automatisch. 
Viel Spass und schöne Grüße
NewRasPi

Ist so sicher auch machbar , die Anforderung war aber die , die vorhandene variable $twe zu  nutzen , um wohl eine Vielzahl von doifs nicht ändern zu müssen.

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Zitat von: Otto123 am 10 März 2019, 11:43:47
Die einfache Lösung mit dem Import war mir auch im Kopf, aber die habe ich mir nicht getraut zu sagen. Der Gedanke - dass Daten, die in einer DB stehen, dadurch aktualisiert werden, dass ich ich einen File erzeuge und den importiere - ist mir irgendwie etwas schräg.

Recht hast du, aber schräg ist ja auch eigentlich schon direkt in eine Textdatei zu schreiben, weil es das Holiday Device selbst nicht unterstützt.
Dafür war es natürlich auch nie gedacht, das ist schon klar. Alles so ein wenig "Von hinten durch die Brust ins Auge!"

Vielleicht hat Betateilchen beim Kochen ja noch eine wunderbare Idee.

Zitat von: Otto123 am 10 März 2019, 11:43:47
Der Gedanke - dass Daten, die in einer DB stehen, dadurch aktualisiert werden, dass ich ich einen File erzeuge und den importiere - ist mir irgendwie etwas schräg. Ich würde irgendwie versuchen die Daten in der DB direkt zu schreiben.

Das ist auch völlig schräg und völlig überflüssig.

Zitat von: Papaloewe am 10 März 2019, 17:05:49
Vielleicht hat Betateilchen beim Kochen ja noch eine wunderbare Idee.

Naja, ein bisschen was ist mir schon dazu eingefallen.

Wenn man anstatt dem Rumgehampel mit Systembefehlen und anschließendem Import in die Datenbank einfach die von FHEM bereitgestellten Mechanismen verwenden würde, kann man sich das Leben sehr viel einfacher machen.

FHEM hat eine interne Funktion FileWrite() die genau dafür geschaffen wurde, dass der Anwender bei der Erstellung einer Datei nicht mehr darüber nachdenken muss, ob er mit einer Konfigurationsdatei oder einer -datenbank arbeitet. FileWrite schreibt die holiday-Datei automatisch an die richtige Stelle


{ FileWrite('./FHEM/tomorrow.holiday', ' hier kommt der Zeilentext hin, der in der holiday Datei stehen soll') }


Was mir aber noch viel besser als Lösung gefallen würde:

define tomorrow holiday

und das holiday Modul legt anhand des Schlüsselwortes "tomorrow" ein temporäres device (ähnlich eines einmal auszuführenden at) an, das spätestens übermorgen automatisch wieder verschwindet.

Muss bei der nächsten Bahnfahrt mal in mich gehen und schauen, was mir dazu einfällt.

Moin,

ich habe mit Udos Hinweis noch ein Variante mit Filewrite gemacht. Könnte ja Papalöwe mal testen.
defmod nty_MorgenUrlaub notify MorgenUrlaub:(set|del) {\
    my $hdev='urlaub';;\
    my $hfile='./FHEM/'.$hdev.'.holiday';;\
    my $morgen = `date --date=tomorrow +%m-%d`;;\
    chomp($morgen);;\
    if ($EVENT eq "set") {\
        FileWrite($hfile, '1 '.$morgen.' Urlaub ') ;;\
        fhem("defmod deltomorrow at +48:00:00 set MorgenUrlaub del")\
    };;\
    if ($EVENT eq "del") {\
        FileWrite($hfile, '#')\
    };;\
    fhem("set $hdev reload;;set MorgenUrlaub _$EVENT")\
  }
Nach zwei Tagen wird die "Morgen ist Urlaub Einrichtung" auch wieder durch ein at gelöscht. Ob das jetzt so die richtige Idee ist weiß ich nicht. Mir fiel erstmal nichts besseres ein. Das defmod ist auch nicht ganz unkritisch, ich wollte halt, dass man morgen auch nochmal "verlängern" kann.  ;)

Gruß Otto

besser zum "Löschen":

FileWrite($hfile, '#')

Zitat von: NewRasPi am 10 März 2019, 12:22:54
Hallo Ihr Spezialisten
muss es so aufwändig sein?

Ja, wenn z.B. abends "Aktionen" ablaufen, die sich darauf beziehen, ob morgen ein Feiertag/Wochenende/freier Tag ist, oder nicht.

Gruß Chris

Zitat... Könnte ja Papalöwe mal testen.

Getestet und läuft wie erwartet auch mit configdb  ;)
Vielen Dank.

Ich muss doch auch nochmal was fragen. Otto, ich habe Deinen Code von hier genommen (https://forum.fhem.de/index.php/topic,98268.msg916202.html#msg916202) und holiday2we kommasepariert um urlaub ergänzt. Wenn ich unter holiday2we auf urlaub klicke, komme ich auf das neue erstellte Holidaydevice.

Für den heutigen Tag steht bei mir unter dem Tab "Everything -> holiday" Folgendes:

<bisherige Holidaydatei> none
urlaub Urlaub

Das ist auch richtig so, weil ich gestern über einen Klick auf den Dummy definiert hatte, dass heute ein Urlaubstag sein soll.

Leider hat das die Hausautomation nicht interessiert; sprich sie hat sich so verhalten, wie wenn ein gewöhnlicher Arbeitstag wäre.

Woran kann das liegen?

Gruß Chris

was sagt denn {$we} in der FHEM Kommandozeile?
gib mal ein list urlaub

1

Internals:
   FUUID      5c824ecf-f33f-b9fb-6f3c-713861a9a7fee280
   HOLIDAYFILE ./FHEM/urlaub.holiday
   NAME       urlaub
   NR         81
   READONLY   0
   STATE      Urlaub
   TRIGGERTIME 1552518002.04766
   TYPE       holiday
   READINGS:
     2019-03-13 00:00:02   state           Urlaub
     2019-03-13 00:00:02   tomorrow        none
     2019-03-13 00:00:02   yesterday       none
Attributes:
   comment    Dieses Device wird benötigt, um folgende Funktionalität gewährleisten zu können: "Morgen frei?"

Hierfür benötigte Devices in Summe: Dummy, Notify, Holiday

Das passt eigentlich, oder? Ich denke, dass Du denkst, das der Beweis hiermit erbracht ist, dass es eigentlich so passt. Liege ich da richtig?  :D

Gruß Chris

Edit: Hab grad nochmal einen Test gemacht:

DOELSEIF ([10:45|AT]) ()

Das hat eben ausgelöst, trotz gestern für heute definiertem Urlaubstag.  :(

Wenn ich das ,urlaub aus holiday2we entferne, ergibt {$we} 0.
Wenn ich das ,urlaub wieder der holiday2we hinzufüge, ergibt {$we} 1.

aus meiner Sicht ist das ok und passt. Warum das DOIF auslöst weiß ich nicht.

Hast du die DEF des DOIF mal geändert oder irgendeinen anderen Trigger dazugefügt, der das DOIF dazu bringt, seine Zustände auszuwerten?

DOIF verwaltet eventuell einige Zustände intern und bekommt dann evtl. nicht mehr mit, wenn sich extern was ändert.

Das kann gut sein. Wie könnte man das DOIF denn "resetten"?

Gruß Chris

Zitat von: chq am 13 März 2019, 14:28:29
Das kann gut sein. Wie könnte man das DOIF denn "resetten"?

Gruß Chris

Effektiv habe ich keine Ahnung, wie DOIF funktioniert, ich nutze das nicht. Aber da stand schon ein Vorschlag, wie es gehen könnte:

Zitat von: Beta-User am 13 März 2019, 12:59:48
Hast du die DEF des DOIF mal geändert  [...]

Hast du das ausprobiert? (es müßte reichen, an irgendeiner Stelle z.B. ein Leerzeichen einzufügen...)

Ja, das habe ich.

Wenn ich heute {$we} in die Kommandozeile eingebe, erhalte ich eine 1 zurück.

Ganz aktuell:

DOELSEIF ([14:53] and !$we) () triggert
DOELSEIF ([14:54] and $we) () triggert nicht

Gruß Chris

DOIF arbeitet z. Zt. noch mit "nur einer Holiday-Datei". Die Umstellung auf mehrere Holiday-Dateien muss  ich in DOIF noch nachziehen.

Vielen Dank für diese wichtige Info!  :)

Gruß Chris

Zitat von: Damian am 13 März 2019, 15:03:10
DOIF arbeitet z. Zt. noch mit "nur einer Holiday-Datei". Die Umstellung auf mehrere Holiday-Dateien muss  ich in DOIF noch nachziehen.

Ganz allgemein: Gibt es einen Grund, warum nicht auf die global vorhandene(n) Variable(n) zurückgegriffen wird? (Außer, dass die von fhem.pl immer zur Laufzeit ausgewertet werden, wenn sie benötigt werden).
M.E. macht es keinen Sinn, wenn fhem.pl und DOIF da nicht gleichlaufend sind, das versteht kein Mensch... Für mich waren solche seltsamen Effekte damals ein Grund, DOIF aus der config zu verbannen!

(Und im übrigen "verstehe" ich jetzt zwar, warum du vor einiger zeit zwar das $twe-Ding in DOIF eingebaut hast, aber keinen Versuch unternommen, das Rudi schmackhaft zu machen, dass es zentral zur Verfügung steht. Sehr schade :( . Motiviert mich persönlich jedenfalls nicht gerade, meine Haltung zu überdenken).

Zitat von: Beta-User am 13 März 2019, 15:19:49
Ganz allgemein: Gibt es einen Grund, warum nicht auf die global vorhandene(n) Variable(n) zurückgegriffen wird? (Außer, dass die von fhem.pl immer zur Laufzeit ausgewertet werden, wenn sie benötigt werden).
M.E. macht es keinen Sinn, wenn fhem.pl und DOIF da nicht gleichlaufend sind, das versteht kein Mensch... Für mich waren solche seltsamen Effekte damals ein Grund, DOIF aus der config zu verbannen!

(Und im übrigen "verstehe" ich jetzt zwar, warum du vor einiger zeit zwar das $twe-Ding in DOIF eingebaut hast, aber keinen Versuch unternommen, das Rudi schmackhaft zu machen, dass es zentral zur Verfügung steht. Sehr schade :( . Motiviert mich persönlich jedenfalls nicht gerade, meine Haltung zu überdenken).

Wenn du mal in fhem.pl genau reinschaust, dann wirst du sehen, warum $we nachbauen musste ;)

Zitat von: Damian am 13 März 2019, 16:20:57
Wenn du mal in fhem.pl genau reinschaust, dann wirst du sehen, warum $we nachbauen musste ;)

Zum einen maße ich mir nicht an, wirkliche Aussagen zur Qualität von bestimmtem Perl-code zu machen, sondern beurteile das ganze weiterhin erst mal aus Usersicht: Da ist es - gelinde gesagt nicht optimal -, wenn zwei dieselben Worte nutzen, aber in nicht ganz unerheblichem Umfang Teilen was anderes meinen.

Daher erlaube ich mir nur die Gegenfrage: Wann und wo hast du Rudi einen Gegenvorschlag mit aus deiner Sicht besserem Code gemacht und was hat er dazu gesagt?

(Ich gebe zu, dass mir für diese eigentlich statischen Sachen eine Logik im Sinne von "habe ich das heute schon geprüft? ja? Gut, dann schicke ich das Ergebnis raus" näher läge, aber wie man sieht, gibt es User, die auch nachmittags heute noch zum $we erklären...)

Zitat von: Damian am 13 März 2019, 15:03:10
DOIF arbeitet z. Zt. noch mit "nur einer Holiday-Datei". Die Umstellung auf mehrere Holiday-Dateien muss  ich in DOIF noch nachziehen.

Morgen per Update verfügbar.

Zitat von: Beta-User am 13 März 2019, 16:36:50
Zum einen maße ich mir nicht an, wirkliche Aussagen zur Qualität von bestimmtem Perl-code zu machen, sondern beurteile das ganze weiterhin erst mal aus Usersicht: Da ist es - gelinde gesagt nicht optimal -, wenn zwei dieselben Worte nutzen, aber in nicht ganz unerheblichem Umfang Teilen was anderes meinen.

Daher erlaube ich mir nur die Gegenfrage: Wann und wo hast du Rudi einen Gegenvorschlag mit aus deiner Sicht besserem Code gemacht und was hat er dazu gesagt?

(Ich gebe zu, dass mir für diese eigentlich statischen Sachen eine Logik im Sinne von "habe ich das heute schon geprüft? ja? Gut, dann schicke ich das Ergebnis raus" näher läge, aber wie man sieht, gibt es User, die auch nachmittags heute noch zum $we erklären...)

$we kann Rudi nicht als globale Variable zur Verfügung stellen, weil sie immer dynamisch aktualisiert werden muss.

Zitat von: Damian am 13 März 2019, 15:03:10
DOIF arbeitet z. Zt. noch mit "nur einer Holiday-Datei". Die Umstellung auf mehrere Holiday-Dateien muss  ich in DOIF noch nachziehen.

Uihuihui - damit habe ich jetzt nicht gerechnet.  ::)

Zitat von: Otto123 am 13 März 2019, 19:32:11
Uihuihui - damit habe ich jetzt nicht gerechnet.  ::)

ich schon: https://forum.fhem.de/index.php/topic,94728.msg875471.html#msg875471  ;)

naja ich hatte nicht damit gerechnet, dass $we im System nicht $we im DOIF ist. Ich lese zwar viel mit, aber manches geht eben doch vorbei ... :-[

Zitat von: Otto123 am 13 März 2019, 19:54:43
naja ich hatte nicht damit gerechnet, dass $we im System nicht $we im DOIF ist. Ich lese zwar viel mit, aber manches geht eben doch vorbei ... :-[

Die Wochentagsteuerung wird im DOIF in erster Linie nicht über $we gesteuert (ist 'ne Draufgabe), sondern über Zeitintervalle mit Wochentagangaben.

Daher hat $we oder $wte für mich keine große Bedeutung.

Zitat[<time>|0123456789] 0-9 entspricht: 0-Sonntag, 1-Montag, ... bis 6-Samstag sowie 7 für Wochenende und Feiertage (entspricht $we), 8 für Arbeitstage (entspricht !$we) und 9 für Wochenende oder Feiertag morgen (entspricht intern $twe)

Naja da hab ich bisher immer gedacht: entspricht $we wird wohl auch $we sein. Also was in $we passiert ist dann auch in der 7 enthalten. Auf die Idee, dass es parallele Prozesse sein könnten, kommt man freiwillig nicht.

Zitat von: Otto123 am 13 März 2019, 20:10:16
Auf die Idee, dass es parallele Prozesse sein könnten, kommt man freiwillig nicht.

Das war der Grund, warum ich nach dem tieferen Sinn der Parallelität gefragt hatte; dazu ist bisher keine substantielle Antwort gekommen.

Es ist halt bisher kaum jemandem aufgefallen, weil erst seit der ASC-Geschichte überhaupt einige mehr Leute auf die Idee gekommen sind, das holiday2we mehrere Devices zuläßt und das ja ganz toll ist, dass das zentral zur Verfügung steht.

Dass der code in fhem.pl das dynamisch macht, ist mir soweit bekannt. Aber es war ja danach gefragt gewesen, ob es eine Diskussion über den behauptet besseren Ansatz gegeben hat, den Damian da verfolgt. Gab es scheinbar nicht...

Aber dann halt weiter parallel, mir auch egal, ich nutze kein DOIF und werde das u.a. wegen dieser Grundhaltung, die da zum Ausdruck kommt auch zukünftig nicht tun.

(Und nein, das braucht nicht weiter kommentiert werden, und war nur als Rückmeldung zu dieser von mir als ausweichend wahrgenommene Antwort gemeint, nachdem auch andere langjährige User diese Falle nicht wahrgenommen hatten.)

Zitat von: Otto123 am 13 März 2019, 20:10:16
Naja da hab ich bisher immer gedacht: entspricht $we wird wohl auch $we sein. Also was in $we passiert ist dann auch in der 7 enthalten. Auf die Idee, dass es parallele Prozesse sein könnten, kommt man freiwillig nicht.

Ich weiß nicht, was du mit parallelen Prozessen meinst.

Also noch mal zu DOIF $we zusammengefasst:

1) DOIF $we wurde vor ca. 4 Jahren FHEM $we nachgebaut, weil $we global für Modulentwickler nicht zur Verfügung stand und steht

2) Irgendwann wurden multiple holiday Dateien in fhem.pl eingebaut -> muss vom Modulentwickler nachgezogen werden, was ich heute gemacht habe

3) Es gilt immer: DOIF $we = 7, d. h. bis heute ohne multiple holiday Dateien, ab morgen mit multiplen holiday Dateien

Edit: 
4) Es gilt immer: DOIF $twe = 9, d. h. bis heute ohne multiple holiday Dateien, ab morgen mit multiplen holiday Dateien

P. S. Die Diskussion hat mich jetzt mehr Zeit gekostet, als ich für die eine Zeile Änderung gebraucht habe. Da Rudi hier mitliest, kann er sich überlegen, ob er eine zentrale weekday Funktion den Entwicklern zur Verfügung stellen will, die dokumentiert werden muss, falls es überhaupt jemand braucht. Ich habe kein Problem damit, in vier Jahren wieder eine Zeile anzupassen. :)

Vielen Dank für das Update. Works flawless! :P

Gruß Chris