Bin noch neu im Umgang mit dem Holiday-Modul.
Wenn ich es richtig verstehe wird die Datei durch ein Fhem-Update ebenfalls aktualisiert.
Wenn man eigene Tage in die Datei aufnimmt, werden diese dann bei einem Update überschrieben?
Mir fehlt zum Beispiel Heiligabend und Silvester. Auch wenn es keine echten Feiertage sind würde ich doch gerne an diesen Tagen reagieren.
Falsches Unterforum für Fragen zu holiday.
ZitatModule: 95_holiday.pm Maintainer: rudolfkoenig Forum: Sonstiges
Ein Blick in die commandref beantwortet Deine Frage vollumfänglich:
Zitat
Set
createPrivateCopy
if the holiday file is opened from the FHEM/holiday directory (which is refreshed by FHEM-update), then it is readonly, and should not be modified.
With createPrivateCopy the file will be copied to the FHEM directory, where it can be modified.
Du brauchst also nur ein "set <deviceName> createPrivatCopy" in Deinem holiday-device ausführen, danach kannst Du die Kopie der holiday-Datei über "Edit files" um eigene Einträge erweitern.
Dann wird die Kopie aber auch gar nicht mehr aktualisiert, oder sehe ich das falsch?
Das Zitat habe ich in der deutschen Commandref nicht gesehen. Fehlt es dort oder habe ich es doch nur übersehen?
Zitat von: Superposchi am 09 Januar 2023, 07:47:01Dann wird die Kopie aber auch gar nicht mehr aktualisiert, oder sehe ich das falsch?
Wie oft ändern sich die Feiertage denn? ::) Und ja, die per update gelieferte holiday Datei wird dann überschrieben.
Zitat von: Superposchi am 09 Januar 2023, 07:47:01Das Zitat habe ich in der deutschen Commandref nicht gesehen. Fehlt es dort oder habe ich es doch nur übersehen?
Hast du
ZitatcreatePrivateCopy
Falls die Datei in der FHEM/holiday Verzeichnis geöffnet wurde, dann ist sie nicht beschreibbar, da dieses Verzeichnis mit FHEM update aktualisiert wird. Mit createPrivateCopy kann eine private Kopie im FHEM Verzeichnis erstellt werden.
https://fhem.de/commandref_DE.html#holiday (https://fhem.de/commandref_DE.html#holiday)
Man kann übrigens
mehrere holiday Dateien und Devices im FHEM nutzen. Du kannst also deine "Feiertage" Silvester und Heiligabend in eine extra Datei eintragen (und Urlaub und Wintersonnenwende und Cthulhu-Gedenktag usw) und darauf zugreifen.
Du kannst auch die holiday-Datei editieren via cli und diese dann aus dem update exkludieren.
Ich dachte dabei an die beweglichen Feiertage wie Oster, Pfingsten etc..
Habe ich wohl überlesen, ich verstehe eh immer nur die Hälfte der Anweisungen.
Christliche Pfeiertage wie Pfingsten, Happy Kadaver, Christi Himmelfahrt und co hängen idR von Ostern (https://de.wikipedia.org/wiki/Gesetzliche_Feiertage_in_Deutschland#Bewegliche_Feiertage) ab; alle anderen (https://de.wikipedia.org/wiki/Gesetzliche_Feiertage_in_Deutschland#Unbewegliche_Feiertage) sind imho fix - und grundsätzlich je nach Bundesland unterschiedlich. Heiligabend und Silvester sind auch keine gesetzlichen Feiertage; daher durchaus sinnvoll, dass sie in der Bundeslandspezifischen holiday Datei (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/holiday) nicht auftauchen. Silvester und co sind übrigens in der de_social.holiday (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/holiday/de_social.holiday) enthalten.
Struktur der holiday Einträge sind in der commandref (https://fhem.de/commandref_DE.html#holiday) gut erklärt.
Alles verständlich, wobei Ostern selbst auch nicht Fix ist sondern soweit ich weiß vom ersten Vollmond nach Frühlingsanfang abhängt.
Was Heiligabend und Silvester angeht war es ja nur eine Frage, da an diesen Tagen eben oft auch abweichende Programmierungen genutzt werden. Für mich persönlich wäre zum Beispiel auch noch Karneval interessant.
Stehen die zufällig auch in der de_social mit drin?
Zitat von: Superposchi am 09 Januar 2023, 07:47:01
Dann wird die Kopie aber auch gar nicht mehr aktualisiert, oder sehe ich das falsch?
Das ist Sinn und Zweck der "privaten Kopie": Deine individuellen Änderungen sollen erhalten bleiben.
Deshalb wird die Kopie von FHEM respektiert und beim Update eben nicht mehr angefasst.
Das Original "gehört" nach wie vor FHEM und kann auch im Update aktualisiert werden.
Zitat von: yersinia am 09 Januar 2023, 08:16:46
Du kannst auch die holiday-Datei editieren via cli und diese dann aus dem update exkludieren.
Dann hätten wir uns nicht vor einiger Zeit die Arbeit machen brauchen, die privateCopy einzuführen - damit man
genau das nicht mehr tun muss.
Zitat von: Superposchi am 09 Januar 2023, 12:13:18
Ich dachte dabei an die beweglichen Feiertage wie Oster, Pfingsten etc..
Zitat von: Superposchi am 09 Januar 2023, 18:50:20
Alles verständlich, wobei Ostern selbst auch nicht Fix ist sondern soweit ich weiß vom ersten Vollmond nach Frühlingsanfang abhängt.
So clever ist das holiday-Modul durchaus, um das zu berücksichtigen. Deshalb gibt es mehrere (afaik aktuell 6) verschiedene Typen von Einträgen in einer .holiday Datei, erkennbar an der ersten Ziffer einer Zeile in der Datei. Die Ostern-abhängigen sind Einträge mit einer 2 am Anfang.
Wie schon geschrieben wurde:
Zitat von: yersinia am 09 Januar 2023, 12:31:38
Struktur der holiday Einträge sind in der commandref (https://fhem.de/commandref_DE.html#holiday) gut erklärt.
Zitat von: Superposchi am 09 Januar 2023, 18:50:20
Für mich persönlich wäre zum Beispiel auch noch Karneval interessant.
Auch Karneval hängt von Ostern ab und könnte dementsprechend automatisch errechenbar in Deine "private Datei" eingetragen werden.
Zitat von: Superposchi am 09 Januar 2023, 18:50:20
Stehen die zufällig auch in der de_social mit drin?
Nein, die stehen da nicht zufällig drin.
Sondern absichtlich, weil sich in der Vergangenheit schonmal jemand vor Dir Gedanken zu dem Thema gemacht hat.
Zitat von: Superposchi am 09 Januar 2023, 18:50:20
Was Heiligabend und Silvester angeht war es ja nur eine Frage, da an diesen Tagen eben oft auch abweichende Programmierungen genutzt werden.
Das musst Du mir bitte genauer erklären. In all den vielen Jahren, die ich inzwischen auf dem Planeten Erde lebe, war Heiligabend in Deutschland immer am 24.12. und Silvester am 31.12. eines Jahres. Nur Feiertage (im gesetzlichen Sinne) sind das eben nicht.
Edit: achso, Du meinst mit "Programmierungen" eventuell Aktionen in FHEM? Dann vergiss bitte meine Frage.
(offtopic)
Zitat von: yersinia am 09 Januar 2023, 08:16:46
Wie oft ändern sich die Feiertage denn?
Nun, in den vergangenen paar Jahren gab es durchaus mehrere Fälle, in denen das passiert ist. So wurde in einigen Bundesländern der Reformationstag neu als Feiertag eingeführt und Berlin hat beispielsweise den Frauentag zum Feiertag gemacht.
Aber auch solche Fälle sind ja problemlos - die trägt man dann eben einmalig von Hand in die privateCopy ein und alles ist gut.
Gut erklärt, das ist hilfreich.
Nachdem ich mich jetzt etwas eingearbeitet habe habe ich eine abschließende Frage und das meine ich nicht böse.
Mit dem Holiday-Modul wird im State der Name des Feiertags angezeigt. Es muss also auf jeden Namen einzeln geprüft werden. Nun also die Frage wo der Vorteil liegt ob ich jetzt in einer DOIF auf die Feiertagsnamen oder mit $md auf das Datum Abfrage. Zumindest auf Weihnachten oder andere feste Feiertage. Vorteil sehe ich nur bei flexiblen Feiertagen.
Zitat von: Superposchi am 09 Januar 2023, 22:06:10
Mit dem Holiday-Modul wird im State der Name des Feiertags angezeigt.
Ja, das ist aber nur ein Nebeneffekt eines holiday devices, aber nicht die Hauptaufgabe.
Hauptaufgabe ist es, festzustellen,
ob es überhaupt einen Eintrag in den readings für gestern/heute/morgen gibt und somit (irgend)ein Feiertag ist.
Welcher Feiertag das ist, ist an dieser Stelle grundsätzlich zweitrangig.
Ja das ist klar.
Aber im anderen Thread hast du ja behauptet, dass das holiday-device für den damals genannten Zweck viel besser wäre.
Und da muss ich einfach sagen das ich da keinen Unterschied sehe. Ob ich jetzt im DOIF mit or auf drei feste Datumsangaben prüfe oder auf drei Feiertagsnamen ist doch das gleiche.
Sogesehen war es damals die richtige Entscheidung es erstmal über die Datumsfunktion zu machen und mich in Ruhe und nicht unter Zeitdruck in das Modul einzulesen.
Wobei ich es im Punkt "irgendein Feiertag" etwas anders sehe, denn immerhin muss man zur Prüfung ja wissen um welchen Feiertag es sich handelt.
Zitat von: Superposchi am 09 Januar 2023, 22:06:10
Gut erklärt, das ist hilfreich.
Nachdem ich mich jetzt etwas eingearbeitet habe habe ich eine abschließende Frage und das meine ich nicht böse.
Mit dem Holiday-Modul wird im State der Name des Feiertags angezeigt. Es muss also auf jeden Namen einzeln geprüft werden. Nun also die Frage wo der Vorteil liegt ob ich jetzt in einer DOIF auf die Feiertagsnamen oder mit $md auf das Datum Abfrage. Zumindest auf Weihnachten oder andere feste Feiertage. Vorteil sehe ich nur bei flexiblen Feiertagen.
Der Trick an der Sache ist, dass man Wochentage um Feiertage erweitern kann, ohne die eigentliche Zeitsteuerung anpassen zu müssen.
Wenn du im Device global das Attribut holiday2we auf deine holiday-Device setzt, dann erweiterst du das Wochenende um die Feiertage.
z. B.
DOIF ([06:00-09:00|AT] or [08:00-09:00|WE]) (set lampe on) DOELSE (set lampe off)Wochenende (WE) inkludiert dann auch die Feiertage aus deiner holiday-Datei und damit ist die Bedeutung von WE bewusst zwar verfälscht, dafür stimmt dann eher die Bedeutung von Arbeitstagen (AT) als das Gegenteil von WE, zumindest bei den meisten :)
Ich habe mir gerade das de_social File angesehen.
Wenn ich z.b. den 6. Jan auslesen lasse, wird Heilige Drei Tage, Jahreswechsel, Weihnachtszeit ausgegeben.
Wenn ich auf heilige drei Könige prüfen lasse muss ich das dann mit .* angeben?
Steht der Feiertagsname immer als erstes oder kann er auch mitten drin stehen? Dann müsste ja zusätzlich ein .* davor geschrieben werden.
Also müsste die Bedingung im DOIF so aussehen:
... DOIF [de_social] = ".*Heilige drei Könige.*" ...
Zitat von: Superposchi am 09 Januar 2023, 23:37:51
Also müsste die Bedingung im DOIF so aussehen:
... DOIF [de_social] = ".*Heilige drei Könige.*" ...
Interessehalber: Für was braucht man so eine kleinteilige Logik?
Wenn überhaupt eine Unterscheidung zu "normalen" Feiertagen erforderlich ist, könnte man daraus eine (nicht in holiday2we eingebundene) eigene holiday-Datei generieren, und dann Logiken bauen, die berücksichtigen, ob heute (bzw. gestern oder morgen) so ein Tag war, und dann aber alle diese Tage gleich behandeln.
Ansonsten würde jedenfalls ich den Überblick verlieren, warum wann was passiert...
PS: Man kann solche holiday-Dateien auch relativ einfach selber automatisiert aus Calendar-Devices ableiten und so dann z.B. einen Familien-Kalender oä. auswerten. Mache ich z.B. für Mülltermine (kein $we) oder Ferien (auch bewegliche!) und Urlaubstage ($we).
Also den Begriff Kleinteile verstehe ich in dem Zusammenhang nicht.
Es geht um den Ausdruck nach dem in der Bedingung gesucht wird. Ist der Falsch oder Unvollständig greift die Bedingung ja nicht.
Wenn im STATE "Heilige Drei Könige, Jahreswechsel, Weihnachtszeit" drin steht und ich lediglich nach "Heilige Drei Könige" suche würde das DOIF ja nicht anschlagen
Zitat von: Superposchi am 10 Januar 2023, 08:53:33
Es geht um den Ausdruck nach dem in der Bedingung gesucht wird. Ist der Falsch oder Unvollständig greift die Bedingung ja nicht.
Wenn im STATE "Heilige Drei Könige, Jahreswechsel, Weihnachtszeit" drin steht und ich lediglich nach "Heilige Drei Könige" suche würde das DOIF ja nicht anschlagen
Ah, entschuldige bitte, war mir bisher nicht klar, dass es unter diesem Thread-Titel um DOIF geht.
Nach meinem (eher sehr begrenzten) Verständnis der Modulsyntax (die im übrigen sehr ausführlich in der DE-comamndref erläutert ist), dürfte ein einfaches "=" nicht passen, das ist eigentlich immer eine Zuweisung. Vielleicht klappt es mit "=~"...?
Falls du da nicht mit der Doku weiterkommst, solltest du entweder den Thread-Titel ändern und den Thread verschieben, oder einen neuen Thread aufmachen ;) .
Zitat von: Superposchi am 10 Januar 2023, 08:53:33
Also den Begriff Kleinteile verstehe ich in dem Zusammenhang nicht.
"Kleinteilig" meint: Du willst irgendeinen Zweig nur ausführen, wenn ein bestimmter Tag (1/365 bzw 1/366) im Jahr ist. Was ist an diesem einen Tag speziell?
Vermutlich hast du eher eine Liste mit Tagen, die du gleich behandeln willst... Dann wäre die Logik anders zu gestalten und am Ende wahrscheinlich übersichtlicher wie bei einer "irgendwo verstreuten" Sammlung von Schnippseln für einzelne Tage ;) .
Nicht zwangsläufig um DOIF, aber irgendwo muss der Inhalt ja ausgewertet werden sonst macht das Modul generell wenig Sinn. Ich bevorzuge aber inzwischen DOIF weil es umfangreicher ist und mehr Möglichkeiten bietet.
Das = war ein Schnellschuss, meistens nutze ich ein eq.
Es ging aber grundsätzlich darum, dass ein = oder eq ja den exakten Suchbegriff finden muss. Wenn in der holiday aber mehrere kommagetrennte Texte für einen Tag kommen können würde die Bedingung ja nicht greifen. Ich kenne ja im Vorfeld nicht den kompletten String sondern nur den Namen des "(Feier)tags".
Ursprünglich ging es um eine Sonderprogrammierung der HUE-Elemente an den Weihnachtsfeiertagen. Da hatte mit Betateilchen mit Nachdruck das Holiday-Modul ans Herz gelegt.
Aktuell habe ich es einfach mit einem Datumsabgleich gelöst, also ist $md der xyz.
DOIF ([myholidaydevice:state] =~ "der gesuchte Feiertag") (...)
Hm,
irgendwie komme ich nicht mehr so gaaanz mit.
Zunächst wird nach dem holyday Modul gefragt und wie es funktioniert
Dann, wie werden bewegliche Feiertage abgebildet
Dann, wie kann ich einen String in einem String suchen
Zwischendurch immer mal wieder, wie mache ich das mit DOIF
Aber. Was ist der der Use Case oder Neudeutsch, die User Story?
Also, was möchtest Du umsetzen und was sind Deine Akzeptanzkriterien für eine skizzierte Lösung?
Grüße Jörg
Zitat von: JoWiemann am 10 Januar 2023, 13:35:59
irgendwie komme ich nicht mehr so gaaanz mit.
Aus dem gleichen Grund sitze ich schon lange auf dem Sofa, genieße mein Popcorn und beobachte das Ganz hier lachend.
Zitat von: JoWiemann am 10 Januar 2023, 13:35:59
Zunächst wird nach dem holyday Modul gefragt und wie es funktioniert
Dann, wie werden bewegliche Feiertage abgebildet
Dann, wie kann ich einen String in einem String suchen
Zwischendurch immer mal wieder, wie mache ich das mit DOIF
Das ist bei diesem Fragesteller nicht unüblich...
Irgendwann gibt man als Helfer einfach auf.
Steht eigentlich im Post direkt über deinem im letzten Absatz.
Ursprünglich ging es um die "Sonder"-Programmierung meiner Hue-Devices an den Feiertagen und die Frage wie man dies in einem DOIF umsetzen kann.
Daraufhin kam von Betateilchen der Hinweis dies mit dem Holiday-Modul zu machen. Da dieses Modul für mich bis Dato unbekannt war habe ich es alternativ erstmal mit der $md Funktion des DOIF selbst gelöst.
Da ich aber Neugierig bin und stets dazu lernen möchte, habe ich mir das Holiday-Modul jetzt angesehen, woraus sich nach und nach diese Fragen ergeben haben.
Eigentlich typisch wenn man etwas Neues dazulernen, oder?
Betateilchen ist ja leider sofort angepisst wenn nicht alles so läuft wie er sich das vorstellt. Das andere Menschen auch anders denken ist für ihn halt unvorstellbar.
Zitat von: Superposchi am 10 Januar 2023, 18:50:19
Betateilchen ist ja leider sofort angepisst wenn nicht alles so läuft wie er sich das vorstellt.
Bei so einem Schwachsinn hilft nichtmal mehr Popcorn...
Zitat von: Superposchi am 10 Januar 2023, 18:50:19
Steht eigentlich im Post direkt über deinem im letzten Absatz.
Ursprünglich ging es um die "Sonder"-Programmierung meiner Hue-Devices an den Feiertagen und die Frage wie man dies in einem DOIF umsetzen kann.
Ok, dann mal ganz von Vorne. Was verstehst Du unter "Sonder"-Programmierung.
Vielleicht mal an einem meiner User Stories:
Ich möchte meine alten FS20 FHT80b durch Homematik IP HmIP-STHD Thermostate ersetzen. Da durch die FHT FS20 ST3 Funksteckdosen mit integriertem on-for-timer und off-for-timer gesteuert werden und diese Funktion aus Sicherheitsgründen weiter genutzt werden muss, sind die HmIP-STHD entsprechend in Fhem einzubinden.
Akzeptanzkriterien sind:
- alle Funktionen der alten FHT20b werden abgebildet
- die Möglichkeit der Nutzung eines Anwesenheits- und einen Abwesenheit-Profil ist gegeben
- die manuelle Veränderung der Zieltemperatur ist zeitlich begrenzt
- die Konfiguration für die Standardzieltemperatur und die zeitliche Begrenzung ist über FhemWeb möglich
- die Profile werden in der CCU3 konfiguriert
Das ist jetzt wirklich nur rudimentär und soll verdeutlichen, wie geholfen aber auch dabei gelernt werden kann.
Zum Schluss der Code eines notifiy, wie er aus dieser Anforderung entstanden. Ob dieser Optimal ist lässt sich trefflich diskutieren. Dies ist nur ein Teil, da auch noch ein Dummy Device dazu gehört und das Umschalten des Heizprofils bei verlassen des Hauses.
Grüße Jörg
TT_HM_Badezimmer.* {
unless($EVTPART0 eq "hmstate:") {
# return undef;
}
my $Bez = "act_TT_HM_Badezimmer";
my $llev = 3;
my $tt_hm_m_temp = ReadingsNum("TT_HM_Badezimmer", "measured-temp", 0, 1);
my $tt_hm_d_temp = ReadingsNum("TT_HM_Badezimmer", "desired-temp", 10, 1);
Log3 $Bez, $llev, "$NAME: $EVENT - mTemp: $tt_hm_m_temp <-> dTemp: $tt_hm_d_temp";
my $FHB = ReadingsVal("FK_HM_Badezimmer", "hmstate", "open");
my $THB = ReadingsVal("TK_HM_Badezimmer", "hmstate", "open");
my $hst = ReadingsVal("HZ_ST_Badezimmer", "state", "");
my $at_hst = ReadingsVal("at_HZ_ST_Bad", "state", "inactive");
my $des_temp = ReadingsVal("cfg_TT_HM", "desired-temps-badezimmer", "17.0 19.0 21.0 22.0 22.5");
my $des_chg = ReadingsVal("cfg_TT_HM", "chg-badezimmer", "off");
my $des_dur = ReadingsVal("cfg_TT_HM", "duration-badezimmer", 30);
my $hm = sprintf("%02d:%02d", $hour, $min);
unless($des_temp =~ m/$tt_hm_d_temp/ ) {
if ($des_chg eq "off") {
Log3 $Bez, $llev, $NAME . ": desired temp: manuell verändert";
fhem("set cfg_TT_HM chg-badezimmer on");
my $Zeit_Stop = strftime("%H:%M",localtime(time() + ($des_dur * 60)));
fhem("delete tme_TT_HM_Bad", 1);
fhem('defmod tme_TT_HM_Bad at ' . $Zeit_Stop . ' {fhem("set TT_HM_Badezimmer auto");; fhem("set cfg_TT_HM chg-badezimmer off");; Log3 "' . $Bez . '", "' . $llev . '", "' . $NAME . ': desired temp: manuell zu auto";;}');
fhem("attr tme_TT_HM_Bad room Badezimmer");
fhem("set HZ_ST_Badezimmer on-for-timer 512");
}
} else {
fhem("set cfg_TT_HM chg-badezimmer off") if($des_chg eq "on");
}
if((round($tt_hm_m_temp, 0) < round($tt_hm_d_temp, 0)) && left($at_hst,4) ne "Next"){
if($FHB ne "open" && $THB ne "open") {
fhem("set at_HZ_ST_Bad active");
fhem("set HZ_ST_Badezimmer on-for-timer 512");
Log3 $Bez, $llev, $NAME . ": Termostat: Heizung ein";
}
} elsif((round($tt_hm_m_temp, 0) >= round($tt_hm_d_temp, 0)) && left($at_hst,4) eq "Next"){
fhem("set at_HZ_ST_Bad inactive");
fhem("set HZ_ST_Badezimmer off-for-timer");
Log3 $Bez, $llev, $NAME . ": Termostat: Heizung aus";
}
}
Zitat von: Superposchi am 09 Januar 2023, 23:37:51
Ich habe mir gerade das de_social File angesehen.
Wenn ich z.b. den 6. Jan auslesen lasse, wird Heilige Drei Tage, Jahreswechsel, Weihnachtszeit ausgegeben.
Wenn ich auf heilige drei Könige prüfen lasse muss ich das dann mit .* angeben?
Steht der Feiertagsname immer als erstes oder kann er auch mitten drin stehen? Dann müsste ja zusätzlich ein .* davor geschrieben werden.
Also müsste die Bedingung im DOIF so aussehen:
... DOIF [de_social] = ".*Heilige drei Könige.*" ...
Am 06.01. kann es nur Heilige 3 Könige geben - keine Weihnachtszeit und keinen Jahreswechsel.
Das zugehörige .holiday-Device (es kann durchaus mehrere geben) ist Tagesabhängig.
Es gib ein tomorrow, ein today und ein yersterday-Reading das man abfragen und auf das man prüfen kann.
Mir persönlich ist es in 48 Jahren noch nicht untergekommen das Weihnachten und Silvester und Heilige 3 Könige am selben Tag gewesen wären.
Also erschliesst sich mir der Sinn nicht ganz nach der Suche nach einem String im Reading eines Holiday-Devices.
Wie aber schon erwähnt wurde kann man gerne x-beliebige holiday-Devices anlegen und dann je nach Device auf ReadingsVal tomorrow oder today oder auch yesterday triggern und sich
- Erinnerungen an Geburtstage (hab ich als geburtstag.holiday) schicken,
- Erinnerung an Verlobungs- und Hochzeitstag (hab ich als schatz.holiday) schicken,
- beliebige Tage die einem wichtig sind (kann man als irgendwas.holiday benennen) schicken,
- und die übrigen Feiertage kann man doch locker in die vorhandenen .holiday unterbringen und dann
-- auf das Reading tomorrow im Device meinWeihnachten.holiday (so man diese Datei angelegt hat) schauen und die beliebigen Lampen danach schalten.
-- auf das Reading today im Device meinSilvester.holiday schauen und die Raketen passend um 23:59:59 starten.
Oder was auch immer man machen will ...
Und ja, die holiday-Dateien lassen sich doch glatt über FHEM bearbeiten ;)
@Jörg
Langsam und gemütlich so wie eine lecker Havanna Cohiba
Zitat von: betateilchen am 10 Januar 2023, 18:53:14
Bei so einem Schwachsinn hilft nichtmal mehr Popcorn...
Ich kann Whiskey und Zigarren anbieten
@JoWiemann
Sonderprogrammierung bedeutet halt anders als üblich.
Beispielsweise ging die Weihnachtsbaumbeleuchtung mit Sonnenuntergang an. Davon abweichend am 1. und 2. Weihnachtstag aber schon fest um 10 Uhr.
Das Thema ist aber gelöst und braucht gar nicht weiter vertieft werden.
@Puschel74
Dann solltest du mal mit get den 6.1. im de_social testen wenn du davon so überzeugt bist. Desweoteren habe ich nicht Weihnachten und Silvester geschrieben, sondern Weihnachtszeit und Jahreswechsel. Einträge die für diverseste Daten in der de_social ausgegeben werden. Bei beiden an ca. 20 verschiedenen Tagen.
Die nächste Frage bezieht sich darauf was in dem Fall in der Bedingung als Vergleich eingetragen werden muss. Ist in meinen Augen ganz legitim, ansonsten müsste ich für jedes Datum das ich irgendwann mal in irgendeinem Device abfragen will den get im Holiday-Device prüfen.
Und um all das zu lernen stelle ich die Rückfragen weil das meine Art ist zu lernen.
Ich verwende die de_social.holiday nicht aber hab ich jetzt getestet.
Und ja, du hast recht, die de_social.holiday liefert mit get 01-06 Heilige Drei Könige, Jahreswechsel, Weihnachtszeit zurück.
Das ändert aber nichts daran das man eigene .holiday nehmen darf und dann in diesen eintragen kann was man möchte ... und darauf auch beliebig triggern kann.
Meine benutzte bw.holiday liefert mit get 01-06 nur Heilige Drei Könige zurück.
Dennoch benutze ich auch meine eigenen .holiday Dateien.
Du brauchst im holiday-Device nicht mit get umzurühren - das Device liefert dir im Reading tomorrow den morgigen "Feiertag" (von dir! definiert), im Reading today den heutigen "Feiertag" (von dir! definiert) und im Reading yesterday darfst du auch gern noch deine HUE-Lampen entsprechend schalten.
Fazit: Du darfst soviele .holiday anlegen wie du magst, du darfst auf soviele Ereignisse in diesen .holiday triggern wie du willst, und du darfst soviele Lampen unterschiedlich schalten wie du willst.
Du darfst das ganze aber auch in deinem DOIF mit deiner eigenen Programmierung lösen.
Das ist das schöne an FHEM - fühl dich frei und mach was du willst.
Ich werf noch ne Runde Cohiba rein und ... viel Spaß
Das habe ich dank der Antworten auch alles inzwischen gelernt und hoffentlich verstanden.
Muss ich mal schauen wie ich es am Ende genau mache.
Aber was zur Hölle ist Cohiba? 😄
Das einzige was mich eventuell noch interessiert ist die Frage ob man das Device irgendwie umbenennen kann?
Habe es mit rename probiert, aber dann findet er das holiday-file nicht mehr. Und wenn ich dies auch umbenennen würde es ja nicht mehr bei einem Update aktualisiert. Also besteht da eine Möglichkeit?
Zitat von: Superposchi am 10 Januar 2023, 23:07:02
Aber was zur Hölle ist Cohiba? 😄
Google hilft dir sicher weiter
Zitat von: Superposchi am 10 Januar 2023, 23:12:06
Das einzige was mich eventuell noch interessiert ist die Frage ob man das Device irgendwie umbenennen kann?
Habe es mit rename probiert, aber dann findet er das holiday-file nicht mehr. Und wenn ich dies auch umbenennen würde es ja nicht mehr bei einem Update aktualisiert. Also besteht da eine Möglichkeit?
Du kannst jedes Device in einen dir beliebigen Namen umbenennen - und dieses Device gehört dann dir allein.
Es wird durch ein update von FHEM nie wieder aktualisiert weil ... es gehört ja dir.
Nein, ich versuche das jetzt nicht in meinem Testsystem weil ... ich zu faul dafür bin.
... GN8 und viel Spaß mit FHEM