[Patch 95_holiday.pm] Dateiname unabhängig vom Device Name

Begonnen von Loredo, 15 Mai 2017, 10:18:49

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: betateilchen am 20 Mai 2017, 12:26:32
Und was ist mit orthodoxen, islamischen und jüdischen Feiertagen?

Die islamischen Feiertage für die Jahre 2017-2019 habe ich gerade beigesteuert. Es ist einfacher, die Feiertage in einzelne Jahresdateien zu packen, als diese Feste auf Basis eines nicht-islamischen Kalenders berechnen zu wollen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Loredo

#16
Zitat von: rudolfkoenig am 17 Mai 2017, 13:16:42
Ich finde ein "cp contrib/he.holiday FHEM" nicht zu viel verlangt


Die ewig gleiche Diskussion um einfacheres Handling... Im Buchladen kaufen auch (ziemlich) alle die gleichen Kalender, offizielle Feiertage fallen ja heutzutage nicht mehr einfach so vom Himmel. Sei es drum, die Konservativen haben eben die Oberhand und als liberaler Mensch akzeptiere ich das natürlich. Also bleibt es dabei Dateien kopieren zu müssen, obwohl vermutlich >90% an der Datei selbst hinterher dann nichts ändern.


Ich werde also vermutlich 100% des Holiday Moduls nehmen und in meine neuen Module duplizieren, um die vorgesehene Automationslogik und Nutzerfreundlichkeit zu erreichen. Ich möchte ja eigentlich keine Parallelitäten, aber offenbar möchten andere es gerne und dem komme ich dann eben auch nach.


Zitat von: rudolfkoenig am 17 Mai 2017, 13:16:42
Darueber bin ich auch nicht gluecklich, insb. dass man dabei von anderen angelegte Dateien modifiziert hat.


Mir war nicht klar, dass ohne eine Nennung in MAINTAINER.txt an Contrib-Dateien trotzdem nichts ergänzt werden darf. Ich würde daher schon darum bitten, dass solche Dateien dann auch explizit dort gekennzeichnet sind, schließlich ist das mit anderen Contrib-Dateien auch der Fall. Die Art und Weise, wie ich hier von Betateilchen angefahren werde, ist mehr als respektlos (auch wenn du, Rudi, deine Formulierung gewählter suchst).


Für die Mehrzahl der Dateien habe ich die Änderung revidiert. Für die by.holiday Datei möchte ich gerne die Maintenance übernehmen und habe dies entsprechend in MAINTAINER.txt hinterlegt.


Zitat von: rudolfkoenig am 17 Mai 2017, 13:16:42
Ich frage mich, wieso "Vatertag" vergessen wurde (siehe auch Gleichberechtigung)


Ihr habt die Logik dahinter nicht verstanden oder euch nicht die Mühe gemacht sie zu hinterfragen. Ich sage nicht, dass meine Logik die einzig richtige und fehlerfreie ist, aber es stecken trotzdem nachvollziehbare Überlegungen dahinter und die Art und Weise, wie ihr danach fragt, wie diese aussehen, finde ich gelinde gesagt mehr als unglücklich formuliert.


Hier die Erläuterung:

Die Prämisse ist die Wiedergabe offizieller Feiertage des Bundeslandes. Für die meisten Menschen in Deutschland sind Feiertage keine Arbeitstage, ebenso der Sonntag.
An einer Reihe von Sonntagen sind sogenannte Festtage in Deutschland definiert (nicht zu verwechseln mit Feiertagen, siehe auch entsprechenden Kommentar im by.holiday File ganz oben).
Die Intention ist diese Festtage, sofern sie auf einen arbeitsfreien Tag (Sonntag) fallen, ebenfalls mit in der Datei zu haben. Mein Verständnis des holiday Moduls und den bisherigen *.holiday Vorlagedateien ist, dass diese in erster Linie genau auf die arbeitsfreien Tage abzielen. Vielleicht täusche ich mich da aber auch.


"Vatertag" ist nicht die offizielle Bezeichnung des Feiertages, sondern "Christi Himmelfahrt". Ich wollte hier niemals eine Gender Diskussion anfangen und denke man kann abwägen, dass man eine zusätzliche Zeile für den selben Tag als Vatertag mit einträgt (habe ich für by.holiday gemacht).


Der Muttertag hingegen ist ein Sonntag und somit ein Festtag, den man zur .holiday Datei hinzufügen kann, ohne die Logik, dass dort nur arbeitsfreie Tage enthalten sein sollen, zu beeinflussen. An diesem Sonntag ist es das einzige Vorkommnis, welches diesen Tag von einem normalen Sonntag unterscheidet und somit gibt es keine offiziellere Feiertagsbezeichnung, die für diesen Tag Vorrang erhalten könnte.


Zitat von: rudolfkoenig am 17 Mai 2017, 13:16:42
und wenn man konsequent ist, dann muesste man den Sysadmin-Tag und Tag des Borkenkaefers auch eintragen.


Ich wüsste nicht weshalb. Der Sysadmin Day fällt weder mit einem offiziellen Feiertag zusammen noch auf einen anderen, arbeitsfreien Tag wie dem Sonntag.
Den Borkenkäfer Tag nachzuschlagen bin ich gerade nicht so wirklich daran interessiert, aber wenn er den oben genannten Kriterien entsprechen sollte, sollten wir ihn absolut ergänzen.


Beide Vorschläge sind aber ggf. in einer separaten Datei "nerdy.holiday" super aufgehoben! Ist zumindest eine Überlegung wert.


Zitat von: rudolfkoenig am 17 Mai 2017, 13:16:42
Btw. de-social: das Mischen von Christilichen (Osterzeit, Passionszeit, Adventzeit) und Nicht-Christlichen Festen (Halloween, Wiesnzeit) koennte fuer Diskussion sorgen. Ich wusste z.Bsp. gar nicht, dass Halloween eine ganze Woche dauert. Und dass ab 27. Dezember Jahreswechsel ist.


Ich lese aus diese Aussage heraus, dass du mit meiner Beschreibung am Anfang der Datei de-social.holiday "Festtage und regional-soziale Jahreszeiten in Deutschland" nichts anfangen kannst oder sie schlichtweg nicht gelesen hast.


Meine Definition eines Festtages bzw. die Abgrenzung zu einem Feiertag habe ich oben bereits erläutert. Hier für die restlichen Worte der Beschreibung:

       
  • Regional-soziale Jahreszeit
    Sagt aus, dass es hier um (kürzere oder längere) Zeiträume geht, die das Leben der Gesellschaft während einer bestimmten Periode des Jahres teils maßgeblich beeinflusst. Dazu gehören über die Zeit entstandene Traditionen, die teilweise stark auf die christliche Religion zurückgehen, deren Ursprung heutzutage jedoch für eine teils große Mehrzahl der Menschen nicht mehr unbedingt erkennbar ist. Trotzdem orientieren viele Menschen ihr Verhalten nach wie vor daran, ohne zu wissen weshalb. Während der Adventszeit ist es vielerorts normal seine Wohnung vorweihnachtlich zu schmücken und in den letzten Jahren ist es mehr und mehr allgegenwärtig kurz vor und zu Halloween ebenfalls entsprechende Gegenstände um sich herum zu haben. Andere Beispiele sind Fasching/Karneval, das Oktoberfest, die Starkbierzeit ... einiges davon hat innerhalb von Deutschland mehr Bedeutung als anderswo, aber die meisten Ereignisse sind trotzdem deutschlandweit mehr oder weniger präsent.
    Bei FHEM gibt es eine ganze Reihe von Leuten, die nach solchen Bräuchen und Traditionen Schaltungen vornehmen wie zum Beispiel eine Weihnachtsbeleuchtung, bestimmte Farbstimmungen - you name it.
  • in Deutschland
    Besagt, dass sich die Definition auf den Kulturkreis der Bundesrepublik Deutschland bezieht, zu dem sich die Mehrzahl der Menschen dort zählt. Bitte hier keine Rassismus Debatte aufmachen und es einfach so neutral verstehen, wie es gemeint ist.
Die Datei de-social.holiday ist ein Angebot an jeden, der sie benutzen möchte - so wie jede andere .holiday Datei auch. Ihr habt ja mehr als deutlich gemacht, dass ihr das auch so seht; vor allem gut erkennbar daran, dass man die Datei duplizieren soll, um sie zu nutzen. Eine individuelle Anpassung bestimmte Dinge rauszulöschen ist dann ja logisch.


Mein kultureller Hintergrund wurde eben in Deutschland (genauer Niedersachsen und Bayern) geprägt und mit diesem Hintergrund habe ich die Datei erstellt. Sie steht in Contrib zur Verfügung für den Fall, dass sie jemand für sich aufgreifen möchte, da ich generell ein Freund davon bin Informationen miteinander zu teilen anstatt sie nur für mich zu behalten.


Ich selbst kenne mich in anderen, nicht-christlichen Kulturkreisen nicht gut aus und sie betreffen mich nicht sonderlich stark in meiner Lebensart. Wenn Betateilchen sich im Islam auskennt, finde ich seine Ergänzung um die weiteren Dateien absolut begrüßenswert. Wer weitere Dateien für die genannten orthodoxen, jüdischen (oder buddhistischen, badhaianischen... usw.) Festtage (Feiertage eher weniger, da in Deutschland die meisten gesetzlichen Feiertage nunmal auf dem christlichen Glauben beruhen) erstellen kann - natürlich, absolut, her damit!








----
PS: Ich bin seit jeher Agnostiker und habe somit keinen strengen religiösen Bezug in irgendeiner bestimmten Richtung.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

ZitatMein Verständnis des holiday Moduls und den bisherigen *.holiday Vorlagedateien ist, dass diese in erster Linie genau auf die arbeitsfreien Tage abzielen.

Ich habe holday gebaut, damit ich diverse Vorgaenge (wie Rolladenfahrten) an Feiertagen anders behandeln kann, wie an normalen Arbeitstagen. Diese Feiertage sind gesetzlich, betreffen deswegen alle in einem Bundesland.

Ich habe Schwierigkeiten, den Nutzen von sowas wie Muttertag in diesem Zusammenhang zu verstehen. Wenn jemand mich damit daran erinnern will, rechtzeitig  einen Blumenstrauss zu kaufen, dann muss auch Valentinstag, Geburtstag, Namenstag, Hochzeitstag, etc reingenommen werden was wiederum dem urspruenglichen Zweck widerlaeuft. "Nur so, weil es nicht wehtut", ist kein Argument, weil erstens (insb. Anfaenger) verwirrt, und zweitens die Pflege der Datei erschwert.

Ich habe kein Problem solche Dinger in neuen holiday Dateien zu haben (wie de-social), aber bitte nicht in den bisherigen. Meine Kommentare bezueglich de-social sind rein neugieriger Natur, das sehe ich deutlich entspannter. Ich vermute, es ist nicht unveraendert verwendbar, aber als Inspiration durchaus zu gebrauchen.

ZitatFür die by.holiday Datei möchte ich gerne die Maintenance übernehmen und habe dies entsprechend in MAINTAINER.txt hinterlegt.
Meinen Segen hast du (nachtraeglich), ich hoffe dass diese Reihenfolge nicht zum Normalfall wird :) Ich (als Maintainer des holiday Moduls) faende aber gut, die urspruengliche Intention fuer die "Bundesland-Holiday-Dateien" zu behalten.

ZitatIch werde also vermutlich 100% des Holiday Moduls nehmen und in meine neuen Module duplizieren, um die vorgesehene Automationslogik und Nutzerfreundlichkeit zu erreichen.
Bin heute wohl nicht so schnell beim Verstehen: was hat dein Modul mit holiday zu tun, bzw. wieso kann dein Modul holiday nur dann nutzen, wenn man die Dateien ohne Kopieren mit holiday verwenden kann? Vielleicht koennte man doofe Diskussionen ersparen, wenn man mir nicht als erstes die Loesung, sondern das Problem zeigt.

betateilchen

Rudis Sichtweise bezüglich Beschränkung auf "gesetzliche Feiertage" in den Bundesländern teile ich 100%. Und diese Beschränkung sollte auch für das Bayern-File gelten und eingehalten werden. Egal, wer der Maintainer dafür ist.




Zitat von: Loredo am 20 Mai 2017, 14:39:10
Die Art und Weise, wie ich hier von Betateilchen angefahren werde,

Ich wüßte nicht, wo ich Dich hier angefahren hätte. Wenn Du aus meiner ursprünglichen Intention, auf mögliche/vorhersagbare Probleme durch den von Dir vorgeschlagenen Patch hinzuweisen, als "anfahren" betrachtest - ok, damit kann ich leben.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Loredo

#19
Zitat von: rudolfkoenig am 20 Mai 2017, 15:40:58
Ich habe Schwierigkeiten, den Nutzen von sowas wie Muttertag in diesem Zusammenhang zu verstehen. Wenn jemand mich damit daran erinnern will, rechtzeitig  einen Blumenstrauss zu kaufen, dann muss auch Valentinstag, Geburtstag, Namenstag, Hochzeitstag, etc reingenommen werden was wiederum dem urspruenglichen Zweck widerlaeuft.


Eine Erinnerung im eigentlichen Sinne ist nicht der Grund. Es geht darum, dass mein Haus so viel wie nur irgend möglich über seine Umwelt und mich weiß. Hierbei ist das Interesse im Rahmen einer Haus- und Weckautomation dem Haus zu ermöglichen, mir per Sprach- oder Messenger Ausgabe einen Ausblick auf den Tag zu geben. Dazu gehört neben dem Wetter selbstverständlich auch, was sonst noch so abgeht (Normal-/Sommerzeitumstellung, Wechsel der meteorologischen oder kalendarischen Saison, aber eben auch der gesellschaftlichen Jahreszeit). Wenn also ein Sonntag neben dem Ruhetag noch ein weiteres Merkmal für den Fortschritt während des Jahres hat, finde ich es interessant das zu wissen und es mir auch auf einem Tablet entsprechend mit anzeigen zu lassen. Es gehört irgendwie dazu, auch wenn es für andere eher ist wie "und was bringt mir das nun".


Du hast ja holiday absichtlich so programmiert, dass man mehrere Devices definieren kann. Der von dir beschriebene Einsatzzweck ist eng mit der Hinterlegung des holiday Devices in global/holiday2we verknüpft. Da gibt es auch gar keine Zweifel dran. Ich habe nur die Gelegenheit gesehen die vorhandene Datei mit zusätzlichen Informationen anzureichern in der Annahme, dass dem eigentlichen Einsatzzweck damit nicht geschadet wird (eben die holiday2we Funktion zu füttern). Solange man nicht angeben kann, wann für eine Person tatsächlich Wochenende ist (Schichtarbeiter haben nicht unbedingt Samstags oder Sonntags frei), wird die Variable $we ja immer auf 1 gesetzt, egal ob es ein einfacher Sonntag ist oder das verknüpfte holiday Modul zusätzlich etwas anderes als "none" für diesen Tag meldet.


Damit die Puristen wieder ausschließlich auf die Feiertage der Gesetzestafel schauen, habe ich by.holiday jetzt komplett in den Urzustand zurückversetzt und die erweiterte Fassung by_ext.holiday genannt.


Zitat von: rudolfkoenig am 20 Mai 2017, 15:40:58
Bin heute wohl nicht so schnell beim Verstehen: was hat dein Modul mit holiday zu tun, bzw. wieso kann dein Modul holiday nur dann nutzen, wenn man die Dateien ohne Kopieren mit holiday verwenden kann? Vielleicht koennte man doofe Diskussionen ersparen, wenn man mir nicht als erstes die Loesung, sondern das Problem zeigt.


Pardonne-mois. Dieses Forum hat mich über die Zeit dazu gebracht, Gedanken und Ideen vorab nicht mehr so freizügig zu äußern, weil ich keine Lust darauf habe, dass eine eigentlich im Grundsatz (für mich) gute Idee sofort zerredet wird (und die Motivation damit gleich mit). Das ist leider so typisch Deutsch und spiegelt für mich auch hier wieder, dass die deutsche Gründlichkeit und der Drang einen Startpunkt erst dann zu setzen, wenn man sich sicher sein kann, wann/wo/wie der Endpunkt sein wird, den Weg für vielleicht tolle neue Dinge, die man mit etwas mehr Offenheit und Mut gemeinsam erreichen könnte, sich selbst im Weg steht. Die Amerikaner sehen sowas immer viel lockerer und steuern auch gerne mal auf Sicht und korrigieren den Kurs auch während der Fahrt; mutmaßlich eine der Quellen des Erfolgs des Silicon Valley. Mir persönlich liegt diese Denkart viel näher, aber leider den wenigsten in Europa und insbesondere nicht in Deutschland, wie ich an vielerlei Orten feststelle.
(Btw: Ich finde es alarmierend eine solche Aussage schreiben zu müssen... sagt für mich einiges über den Community Status aus).


Im Bezug auf meinen Mini-Patch vom Anfang kann ich dazu nur sagen: Ich kann eure Bedenken durchaus nachvollziehen, aber deren praktische Auswirkung sehe ich weit weniger dramatisch als es hier dargestellt wird.



TL;DR

Um dir die Aufgabenstellung noch kurz zu umreißen:


Die Module RESIDENTS, ROOMMATE und GUEST sowie deren in Entwicklung befindlichen Companion Module HOMESTATE, FLOORSTATE und ROOMSTATE verwenden holiday, um beispielsweise eine Basis für eine Weckautomation bereitzustellen. Die neueren Companion Module sollen dabei neben dem reinen arbeitsfreien Tag aus dem per global/holiday2we verknüpften holiday Device weitere holiday Devices verwenden können, aus denen zusätzliche Informationen gewonnen werden wie beispielsweise eben die momentane gesellschaftliche Jahreszeit. Die Intention war hier die Grundfunktionen von holiday zu verwenden, statt wieder das Rad neu zu erfinden. Erste Gehversuche ohne holiday und ohne diese Funktion in ein eigenständiges Modul einzubauen gab es bereits einmal mit DOIF, aber das ist schlichtweg nicht wartbar und hat auch nie richtig wie gewollt funktioniert.


Es ist aber ziemlich kompliziert einem Nutzer nun für die reine Aktivierung einer Funktion wie der Berücksichtigung der gesellschaftlichen Jahreszeit zu sagen:


1. Kopiere die Datei von A nach B, denn weil es eventuell vorkommen kann, dass es einen neuen deutschen Feiertag oder eine 6. Jahreszeit gibt, muss die Datei in ./FHEM liegen, weil der FHEMWEB Editor der Einschränkung unterliegt nur von dort Dateien editierbar zu haben.
2. Benenne sie so. wie das FHEM Device hinterher heißen soll, denn aus irgendeinem Grund kann man den nicht frei wählen und er muss so heißen.
3. Lege das holiday Device mit dem zuvor gewählten Dateinamen an.
4. Verknüpfe das angelegte holiday Device mit deinem HOMESTATE Gerät im Attribut mit dem Namen xyz.


All diese Schritte kann man auch programmatisch mit einem einzelnen Set-Befehl oder gar nur durch das setzen des Attributes alleine abhandeln. Ich empfinde es aber als eine zu große Zumutung an den Benutzer, wenn ich in seinem Namen eine Datei kopiere und umbenenne, um schließlich das dazu passende holiday Device anzulegen. Wenn ihm dann das holiday Device unter dem Namen nicht passt, kann er es nicht einfach so umbenennen, ohne die Datei nachzuziehen. Das muss man wissen und ich höre jetzt schon wieder die Stimmen "ja, dann muss er sich halt vorher genau damit auseinander setzen" und "wir wollen es den Leuten hier absichtlich nicht zu einfach machen, weil sie sonst nicht nachdenken und nur dumme Fragen stellen". Nun, meinen Standpunkt dazu sollte man inzwischen kennen...
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

ZitatDamit die Puristen wieder ausschließlich auf die Feiertage der Gesetzestafel schauen, habe ich by.holiday jetzt komplett in den Urzustand zurückversetzt und die erweiterte Fassung by_ext.holiday genannt.
Danke, finde diese Loesung gut.


Zitatich keine Lust darauf habe, dass eine eigentlich im Grundsatz (für mich) gute Idee sofort zerredet wird
Du musst ja deine Idee gar nicht verraten, nur das Problem. :)


ZitatEs ist aber ziemlich kompliziert [...]
Ich finde du uebertreibst. Durch deinen Patch entfaellt lediglich das Kopieren, das Umbenennen ist ueberfluessig. Wir haben nicht fuer alle Bundes- oder anderweitige Laender eine .holiday Datei, und auch die Vorhandenen sind meist erst mit lokale Anpassung nutzbar -> eine Kopie ist sinnvoll. Notfalls kann diese Kopie dein Modul mit einer Zeile durchfuehren, dafuer spare ich mehrere in FHEMWEB.

betateilchen

Zitat von: rudolfkoenig am 21 Mai 2017, 12:19:04
> eine Kopie ist sinnvoll. Notfalls kann diese Kopie dein Modul mit einer Zeile durchfuehren, dafuer spare ich mehrere in FHEMWEB.

Man muss gar nicht kopieren, ein symbolischer Link reicht völlig. Das hat den Vorteil, dass bei einem update per svn (wie auf allen meinen FHEM Installationen aktiv) auch eine in ./contrib liegende aktualisierte holiday-Datei automatisch wirksam wird.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Loredo

Zitat von: betateilchen am 25 Mai 2017, 17:40:35
Man muss gar nicht kopieren, ein symbolischer Link reicht völlig. Das hat den Vorteil, dass bei einem update per svn (wie auf allen meinen FHEM Installationen aktiv) auch eine in ./contrib liegende aktualisierte holiday-Datei automatisch wirksam wird.


Genau aus diesem Grund wollte ich ja, dass man die Datei direkt adressieren kann, nur eben ohne Symlink. Nicht jedes OS kann Symlinks und man muss dazu extra auf die Kommandozeile wechseln.


Aber legen wir bitte auch diese Diskussion zu denk Akten.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER