Autor Thema: [gelöst] iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices  (Gelesen 2524 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7191
  • eigentlich eher user wie "developer"
Sehr aus der Hüfte:

- Evtl. wäre es beim Starten schon bei verbose=4 (oder 3) angebracht, das Überschreiben ins Log zu werfen (also da, wo es grade durch das Aufheben von strict als Warning mit höherem Level (?) unterdrückt wird, aber mit einem rein informativen Text wie "Info: Function redeclaration - IsWe() is now answered by DaySchedule")?
Ausgaben erst bei "5" könnte (an der Stelle) zu hoch sein, und man hätte die übliche Stelle (log), um eventuelle Fehler-/Irritationsquellen leichter zu lokalisieren, ohne den Hilfesuchenden mit (für diesen irritierenden) Fragen an "exotische" Stellen leiten zu müssen?

- Ob eine Info in global für "Sunrise_EL" angezeigt wäre, mag ich nicht so recht beurteilen. Wenn ich es recht verstehe, muß man das nicht extra aktiv schalten, das rückt es in die Nähe von global.
Grundsätzlich: Wenn man durch ein einfaches "list SCOPE=global" oä. an die Infos kommt, welche Module die Funktionen von fremden Modulen (absichtlich) überschreiben, ist das aber m.E. hinreichend, vielleicht ergänzt um weitere Infos, welche Funktionen betroffen sind (sonst muß man in den Modulcode, was dann sehr weit "unter dem Auto" ist, oder?).
Das müßte dann aber von allen Modulentwicklern beachtet werden, außerdem gehören so eine allgemeinen Vorgaben dann auch in die Doku (dev-module-intro), zusammen mit dem freundlichen Hinweis, dass man als Entwickler (später dann) mal nachfragen sollte, ob es Konflikte geben könnte, die man besser auf anderem Weg löst.

- Bitte seht es mir nach, wenn ich nix zu schreiben kann und mag, welche Absprachen ggf. dazu noch Sinn machen. Da muß evtl. auch insgesamt nochmal etwas länger drüber nachgedacht werden können (von denen, die die Auswirkungen usw. besser beurteilen können).

Wenn mehrere Module IsWe ueberschreiben, dann haengt von der Definitionsreihenfolge der Instanzen ab, welche IsWe() gilt.
...das war naheliegend...

Zitat
Selbst bei einem Modul ist es problematisch, wenn ein Benutzer Code mit IsWe() veroeffentlicht, die fhem.pl Version geaendert wird, oder auf IsWe zurueckfuehrbare Probleme gemeldet werden.
Deswegen ist es m.E. wichtig, dann wenigstens relativ leicht rausfinden zu können, welche möglichen Verursacher überhaupt am Start sind. Für IsWe() ist das noch vergleichsweise einfach, da die Funktion an sich "simpel" ist und keinen großen Änderungen (mehr) unterworfen (zumindest geht mir grad die Phantasie dazu aus...).

Zitat
Das ist mW aktuell der Fall mit apptime, die zentrale fhem.pl Funktionen ueberschreibt.
Sollte der Autor hier mitlesen: vielleicht im obigen Sinn (wenn "man" sich darauf verständigt hat, wie) dann entsprechende Infos bereitstellen.
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7191
  • eigentlich eher user wie "developer"
Dazu wäre noch hinzuzufügen, dass DaySchedule im globalen Modus noch weitere Funktionen global (also für alle Module und auch für selbstgeschriebenen Perl Code) bereitstellt, die etwas genauer als IsWe() funktionieren:
[...]

Der Unterschied zwischen IsWe() und IsWeekend() ist dabei, dass IsWeekend() wirklich nur am Samstag und Sonntag eine 1 zurückliefert, IsWe() jedoch auch an Feiertagen, Urlaubstagen. Sprich, IsWe() wird nur an Arbeitstagen eine 0 liefern, an allen anderen Tagen eine 1, ganz gleich warum es kein Arbeitstag ist.
Sorry, wenn ich das hier aufgreife, (will wie gesagt den anderen Thread nicht "mitlesen") aber das stimmt so nicht ganz (ich habe auch etwas Nachhilfe gebraucht, bis ich das verstanden hatte):
IsWe(;$$) { my ($when, $wday) = @_; ...Gibt man für $wday was an ( > 8 ), bekommt man tatsächlich nur $we an Feiertagen, und mit dem globalen Umschalter weekEnd kann man das auch zur default-Verhaltensweise machen.
Und 0/6 für $we zu halten, berücksichtigt die überwiegenden hiesigen Gepflogenheiten, aber nicht abweichende religiöse Vorstellungen oder andere Kulturkreise...
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3607
  • ~ Challenging Innovation ~

- Evtl. wäre es beim Starten schon bei verbose=4 (oder 3) angebracht, das Überschreiben ins Log zu werfen


Logeintrag hinzugefügt.


Grundsätzlich: Wenn man durch ein einfaches "list SCOPE=global" oä. an die Infos kommt, welche Module die Funktionen von fremden Modulen (absichtlich) überschreiben, ist das aber m.E. hinreichend, vielleicht ergänzt um weitere Infos, welche Funktionen betroffen sind (sonst muß man in den Modulcode, was dann sehr weit "unter dem Auto" ist, oder?).
Das müßte dann aber von allen Modulentwicklern beachtet werden, außerdem gehören so eine allgemeinen Vorgaben dann auch in die Doku (dev-module-intro), zusammen mit dem freundlichen Hinweis, dass man als Entwickler (später dann) mal nachfragen sollte, ob es Konflikte geben könnte, die man besser auf anderem Weg löst.


Können wir erstmal einen Schritt nach dem anderen machen, bitte? Denk nicht, ich habe sowas nicht auch schon bedacht.


Deswegen ist es m.E. wichtig, dann wenigstens relativ leicht rausfinden zu können, welche möglichen Verursacher überhaupt am Start sind. Für IsWe() ist das noch vergleichsweise einfach, da die Funktion an sich "simpel" ist und keinen großen Änderungen (mehr) unterworfen (zumindest geht mir grad die Phantasie dazu aus...).


Wie gesagt, ich halte das für einfach kommunizier- und erkennbar. Bitte nicht zu "deutsch" hier denken, die denken immer gerne es muss alles 100% so eintreten, wie man es vorhersieht, bevor man überhaupt was anfängt...  ::)  Ich mag das Wort "agile Entwicklung" nicht, aber genau das ist es, was ich hier tue.
Wenn es einen besseren Weg gibt oder gar einen direkteren, um älteren Code (wie bei SUNRISE_EL) bzw. dessen duplizierte Funktionalität zu erneuern - nur raus damit. Ich denke aber nicht, dass Rudi sich überreden lässt fhem.pl oder 99_SUNRISE_EL.pm so anzupassen, dass es mit Astro und DaySchedule (dann auch ohne Device bzw. nur optional) arbeitet.


Sollte der Autor hier mitlesen: vielleicht im obigen Sinn (wenn "man" sich darauf verständigt hat, wie) dann entsprechende Infos bereitstellen.


Schwerer, weil es kein Device gibt, es bleibt nur logging, was es derzeit nicht tut.
Soweit ich apptime verstehe, ist es da auch etwas rigoroser beim ersetzen der Funktionen. In Astro und DaySchedule bleiben aber die originalen Funktionen erhalten und werden nur umbenannt. Deshalb kann man das auch zur Laufzeit wieder zurücknehmen, indem man das Device löscht oder per defmod ändert.


Im Falle von DaySchedule wird die Originalfunktion ja sogar auch weiterhin verwendet, nur eben in einem größeren Kontext drum herum (remember, ich schrieb "dazwischen schalten").


Sorry, wenn ich das hier aufgreife, (will wie gesagt den anderen Thread nicht "mitlesen") aber das stimmt so nicht ganz (ich habe auch etwas Nachhilfe gebraucht, bis ich das verstanden hatte):
IsWe(;$$) { my ($when, $wday) = @_; ...Gibt man für $wday was an ( > 8 ), bekommt man tatsächlich nur $we an Feiertagen, und mit dem globalen Umschalter weekEnd kann man das auch zur default-Verhaltensweise machen.
Und 0/6 für $we zu halten, berücksichtigt die überwiegenden hiesigen Gepflogenheiten, aber nicht abweichende religiöse Vorstellungen oder andere Kulturkreise...


Die Cross-Posts gehen mir auf den Senkel. Irgendwie hast du von der Nachricht dort ja aber dann doch erfahren  :o


Danke aber für die Erläuterung, was man mit $wday macht. Ich bin nicht so richtig schlau daraus geworden, weshalb alle Abfragen, für die $wday gesetzt ist, auch direkt weiter von der Funktion in fhem.pl bearbeitet werden (wie gesagt, es wird ja nix überschrieben, nur umbenannt und dann auch weiter angesprochen). Deshalb funktioniert auch alles neue mit weekEnd und noWeekEnd, wenn man das denn verwenden möchte (ist IMHO nur notwendig, wenn man kein DaySchedule einsetzen möchte). Meine Aussage zu Samstag/Sonntag sollte deshalb nur beispielhaft zum Verständnis dienen, aber an der Logik von IsWe() ist wie gesagt an dieser Stelle nichts geändert.
« Letzte Änderung: 04 Juli 2019, 18:26:05 von Loredo »
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/loredo

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, wundergroundAPI

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7191
  • eigentlich eher user wie "developer"
Hallo Loredo,

vorab nochmal Danke, dass du meine Gedanken nachdenkenswert findest (z.B. mit dem Logeintrag).
Du darfst mir glauben, dass mir sehr klar ist, dass du insgesamt eine sehr viel breitere und tiefere Sicht auf praktisch alles hast, was wir hier diskutieren, und dabei insbesondere auch viele Dinge mit bedenkst, deren Existenz mir (vermutlich) auf immer verborgen sein wird. Von daher sieh' es mir bitte nach, dass ich manchmal vielleicht ungeschickt frage, nicht unbedingt zielführende Vorschläge mache oä..

Und wir diskutieren das hier im Entwickler-Board, von daher muß nicht alles schon "fertig" sein (wer mag, sollte sich aber ggf. frühzeitig entsprechend "einnorden" können). Daher: Gerne einen Schritt nach dem anderen, und auch die notwendige Zeit dafür nehmen :) .

Gerne auch zur Diskussion, bisher (v.a. vor dem leidigen Diesel-Thema) hatten die Menschen im In- und Ausland es durchaus zu schätzen gewußt, dass hier manches "solide" gemacht wird, und vielleicht hat das (von mir als solche empfunden) extrem stabile "Laufen" von FHEM auch was damit zu tun, dass zentrale Entwickler sehr konservativ waren, was Anpassungen anging.

Was das Cross-Posting anging, war das ursprünglich auch eine Bauentscheidung, bei der mir erst hinterher aufgegangen ist, um was es mir _auch_ ging:
Den Umgang mit dem Namespace... (ist doch der richtige Begriff, oder?)

Im ersten Post des Threads hier hatte ich ursprünglich mal zwei Funktionen vorgeschlagen, Rudi hat daraus eine gemacht (und das Ganze dann noch "garniert" mit der besagten Nebenfunktion, $wday, deren volle Tragweite ich vermutlich bis heute nicht ganz verstanden habe). Nachdem Rudi und ich neulich schon die Frage des "Namespace-Verbrauchs" (im Zusammenhang mit MQTT2-attrTemplates) mal angeschnitten hatten, kommt mir das (auch vor dem Hintergrund des "ins Gehege Kommens" von Funktionsaufrufen) immer mehr als sehr weitsichtig vor (ich selbst muß meine letzten WDT-Changes da auch nochmal ansehen, gelbe Karte!...), selbst wenn das zur Folge hat, dass die Funktion selbst nicht mehr "so einfach" benutzt werden kann oder "einleuchtend" benannt ist und ggf. sogar geringfügig mehr Ressourcen schluckt.
Unter dem Gesichtspunkt: Was spricht dagegen, aus den 4 angedachten Funktionen im main-Kontext eine zu machen und einen (weiteren?) Parameter zu nutzen, um festzulegen, auf was der Fragende eine Antwort bekommt?
Und was, (z.B. mit einem Präfix) deutlicher zu machen, aus welchem "Paket" die Funktion stammt?

Ansonsten: Ich werde versuchen, das mit den Crosspostings entweder zu lassen, oder mir mehr Mühe geben, mein Bauchgefühl zu analysieren, um es ggf. besser erklären zu können ::) .


Danke auch, dass du dir die Zeit genommen hast, die Funktionsweise des Codes zum Ersetzen bzw. Einkapseln (?) des ursprünglichen Funktionaufrufs zu erläutern (auch im Unterschied zu apptime). Den Code hatte ich zwar kurz angesehen, aber für mich waren/sind das "böhmische Dörfer", die da stehen...
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3607
  • ~ Challenging Innovation ~
Um das ganze programmatisch abfragbar zu machen, setzen Astro und DaySchedule jetzt folgende Variablen, während sie zentrale Funktionen ersetzen:


        $data{redirectedMainFn}{'main::IsWe'}  = 'FHEM::DaySchedule::IsWe';
        $data{redirectedMainFn}{'main::sr_alt'} = 'FHEM::Astro::SUNRISE_EL';


Tatsächlich werden die Funktionen aber nicht ersetzt, sondern vorher umbenannt und stehen unter anderem Namen weiter bereit. Wenn man also weiß, warum man die alte Funktion doch einmal aufrufen will, kann man die neuen Namen der Funktionen über zwei weitere Einträge herausfinden:


        $data{renamedFn}{'main::IsWe'}  = 'main::Main_IsWe';
        $data{renamedFn}{'main::sr_alt'} = 'main::Main_sr_alt';


Damit können andere Module zumindest programmatisch erkennen, dass dort etwas anders ist. Da die Funktionen ja die gleichen Parameter erwarten, um vollständig kompatibel zu sein, gibt es sonst keinen anderen Weg das zu erkennen, außer es zu wissen bzw. implizit über das SCOPE Internal zu ermitteln. Das fällt damit nun weg.
« Letzte Änderung: 06 Juli 2019, 13:49:39 von Loredo »
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/loredo

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, wundergroundAPI

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20665
Ich moechte betonen, dass ich das Ersetzen der fhem.pl Funktionen nicht gut finde, und werde bei Aenderungen keine Ruecksicht auf Nachahmer/Kopien nehmen, es reicht schon, dass ich zu der alten Version kompatibel bleibe. Wenn dieser Beispiel Mode macht, dann haben wir einen Support-Albtraum, weil je nach Reihenfolge der Modul-Initialisierung andere Funktionen verwendet werden.

Weiso wird den Leuten nicht nahegelegt, statt den altmodischen IsWe() den schicken DaySchedule::IsWe() zu verwenden?
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3607
  • ~ Challenging Innovation ~
Na weil du es damit auf den User abschiebst, dass er nicht vergisst an allen Stellen die andere Routine aufzurufen.
Genauso brummst du anderen Modulautoren damit auf, dass sie extra Support für etwas einbauen müssen und der Benutzer muss wieder je Modul, welches er einsetzen möchte, entscheiden, woher nun die Daten kommen. Das hat mit Datenkonsistenz wenig zu tun.


Das ganze soll auch keine Einladung sein es mir nachzutun. Wenn jemand den Code (1-zu-1) klaut, dann sorgt die Logik im Code dafür, dass kein zweites Modul die gleiche Prozedur für die selbe Subroutine noch einmal machen kann. Marko habe ich vorgeschlagen die Subroutinen für das Redirecten einer Subroutine, wie ich es jetzt mal lieber nenne, in GPUtils.pm aufzunehmen. Ob man das als Einladung verstehen mag, oder nicht, sei dahingestellt. Zumindest hilft es klar zu dokumentieren, was passiert und dass nix doppelt passiert.


Aber um es klar zu sagen: Mein Favorit wäre eine Lösung einen Data Provider für etwas zentral angeben zu können. Nachdem du bei SUNRISE_EL/sr_alt aber dafür schon nicht offen warst denke ich nicht, dass du bei IsWe nun empfänglicher bist. Daher bleibt nichts als an fhem.pl vorbei an Lösungen zu suchen, da mir dort keine andere angeboten wird.
Wenn du dich hier bewegen könntest und konstruktiv mit überlegst, wie man das besser machen kann, dann bin ich absolut offen dafür.
« Letzte Änderung: 06 Juli 2019, 13:53:25 von Loredo »
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/loredo

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, wundergroundAPI

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20665
Ich habe jetzt sehr haeufig bis zehn gezaehlt, damit ich auf die vielen persoenlichen Schuldzuweisungen nicht eingehe.

Wenn du meinst, dass Bedarf fuer ein "Ist-denn-jetzt-Wochenende-Framework" existiert, dann erfinde und bewerbe bitte dein Eigenes, und kapere bitte nicht eine vorhandene Funktion.

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3607
  • ~ Challenging Innovation ~
Ich nehme Abstand von der gefundenen Lösung. Es tut mir leid für Beta-User und andere, aber über das Gesamtsystem mit den selben Daten zu arbeiten ist somit nicht machbar. Mit Abweichungen muss man also leben bzw. den fehlenden Einstellungsmöglichkeiten.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/loredo

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, wundergroundAPI

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7191
  • eigentlich eher user wie "developer"
[...] Es tut mir leid für Beta-User und andere, aber über das Gesamtsystem mit den selben Daten zu arbeiten ist somit nicht machbar. [...]
Hmm, also für mich muß dir das m.E. nicht leid tun, ich kann mit der zentralen IsWe() bislang jedenfalls gut leben.

Ist zwar hier leicht OT, aber dennoch eine Anmerkung zu dem Schluß von SUNRISE_EL auf IsWe():
Das irritiert mich sehr, ich empfinde das als nicht ausschließlich sachliches Argument, und wir sollten bitte (v.a.) solche Dinge gerade im Interesse der Konsistenz sachlich besprechen (da ich aber nicht den Sachverstand besitze, um das alles ohne einen für mich riesigen Aufwand mit "harten" Argumenten zu diskutieren, muß ich mich hier darauf beschränken, kurz meine Beobachtungen und Eindrücke zu schildern, die nicht richtig sein müssen):

Der Ablauf war nach meinem Eindruck dort so: Rudi hat konkret nachgefragt, welche Verbesserungen denn gewünscht sind und um Übermittlung eines Patches gebeten, damit er sich eine Meinung bilden kann. Jedenfalls soweit ich diesen Thread verfolgt hatte, kam dazu keine weitere Info, sondern die Rückmeldung, dass sich das ganze dann erledigt hat; scheint also nicht wichtig gewesen zu sein.

Was zentrale Fragen angeht, wäre meine Erwartung, dass man darüber ggf. Argumente austauscht und (vorrangig) im Rahmen der derzeitigen Lösungen versucht, für alle Seiten passende, wartbare und konsistente Lösungen zu finden, und ich gehe auch davon aus, dass diese Erwartung alle teilen, die hier mit diskutieren. Das ist im Fall von SUNRISE_EL - aus welchen Gründen auch immer - unterblieben. Im Prinzip ist das dort auch ok, es ist CoolTux Entscheidung, etwas weiter zu verfolgen oder eben auch nicht. Aber es ist eben m.E. daher kein Argument für das hiesigen IsWe().

Was jetzt wiederum IsWe() angeht, weiß ich, dass sich darüber "normale WE"-Tage abfragen lassen und auch "echte" Feiertage, was deckungsgleich wäre mit zwei der von dir für erforderlich gehaltenen Funktionen. Ob IsWe() noch mehr liefern kann und dann noch Bedarf für weitere Logikbausteine (die 3.+4. neue Funktion) besteht, kann ich im Moment nicht beurteilen.

Zusammengefaßt wäre nach meinem bisherigen Verständnis der Vorteil der "Umleitung" daher darauf beschränkt, z.B. auch ein Calendar-Device direkt mit einbeziehen zu können.

Dass das mit Calendar ohne Diskussion darüber nicht möglich ist, an welcher Stelle jetzt was zu ändern wäre, ist halt so. Ich für mich habe das Problem dadurch gelöst, dass ich mir den Calendar (bzw. bestimmte Elemente darin) immer mal wieder automatisch in ein holiday-file exportiere. Das mag nicht die cleverste Lösung sein, funktioniert aber, von daher braucht man mich dazu nicht bedauern.
Ob es für andere hilfreich wäre, kann man ja diskutieren, und vermutlich wäre dafür auch nur eine kleinere Anpassung von IsWe() erforderlich (anderes Reading vorrangig zu state berücksichtigen), sofern Calendar entsprechend "tickt" (und wer das nicht will, kann ja einen dummy füllen...). Oder wie immer bei FHEM: vieles denkbar...

Meine Bitte wäre, das Kind nicht mit dem Bade aus den falschen Gründen auszukippen und sich jeweils die Mühe zu machen zu erklären, warum man was für zielführend hält (bei solchen zentralen Funktionen) :) . Bisher haben "wir" doch meistens eine Lösung gefunden und dabei hin und wieder noch was gelernt.

 (Zum Lernen, auch wieder in Teilen OT, aber evtl. interessant, weil da Aspekte drin sind, auf die man mit rein naturgesetzlicher Logik nicht kommt: Da gab es zu SUNRISE_EL mal einen Thread, aus dem hervorging, dass die Anhänger mancher religiösen Gruppen eben "exaktere" Werte für erforderlich halten als SUNRISE_EL sie grade liefert. Wenn sich da jetzt aber wieder verschiedene Meinungen entgegenstehen, dann "müssen" "wir" eben mit mehreren Funktionen leben, oder sunset() mit Argumenten so ergänzen, dass wir die jeweilige korrekte Rückmeldung dafür erhalten, wenn das evangelisch, griechisch-orthodox, jüdisch, sunnitisch .... berechnet werden soll ;D . Mir persönlich sind die 6 Minuten, die ggf. dazwischen liegen ziemlich egal, aber ohne dass man die Argumente kennt, die Unterschiede offenlegt und die Ergebnisse verglicht, kann man keine sinnvolle Entscheidung dazu fällen, was denn jetzt "default" sein soll und welche Logik man benötigen würde, um das umzusetzen ::) ).
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3607
  • ~ Challenging Innovation ~

Ganz so kann ich das nicht stehen lassen. Es ist richtig, dass ich ganz sicher keinen Roman darüber geschrieben habe, was die Anwendungsfälle alle sein können. Jeder darf auch gerne selbst die Murmel ein wenig anstrengen und sich eine Vorstellung darüber machen. Ich habe auch früher schon betont: Ich selbst bin weder religiös noch möchte ich mir unterstellen lassen aus religiösen Gründen etwas zu wollen. Ich weiß also beim besten Willen nicht, wie man auf sowas kommen kann, davon war nie die Rede. Ich sagte ja schon, dass keine der genannten Funktionen über ein FHEM Device repräsentiert wird und man kaum Einstellungsmöglichkeiten für fest definierte Werte hat. Du selbst, lieber Beta-User, hast geschrieben, dass es dir darum geht, dass Werte übereinstimmen - ganz egal ob da nun 1 Sekunde oder 3 Minuten Unterschied bestehen. Es geht dabei ums Prinzip der Datenkonsistenz und dem habe ich dir absolut beigepflichtet - offenbar (m)ein großer Fehler.

Ich nehme für mich mit: Beta-User nicht allzu ernst nehmen und auf keinen Fall versuchen seine Wünsche im mutmaßlichen Sinne nachzuverfolgen. Das darf er gerne selbst tun.
« Letzte Änderung: 10 Juli 2019, 13:14:58 von Loredo »
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/loredo

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, wundergroundAPI

 

decade-submarginal