[gelöst] iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices

Begonnen von Beta-User, 15 März 2019, 13:13:56

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatWie wäre es, wenn man IsWe() auch mit einem YYYY-DD-MM Datum füttern könnte, jetzt wo 95_holiday das auch verarbeiten kann?
Habs eingebaut, damit man pruefen kann, ob $we an einem bestimmten Tag auch richtig gesetzt sein wird.
Bin trotzdem etwas ungluecklich, weil die Aenderung nach meinem Geschmack zu gross ist fuer so eine zentrale Funktion.

Loredo

Zitat von: Beta-User am 02 Juli 2019, 13:33:19Auch wenn es häufig mühsam sein mag, finde ich persönlich die Weiterentwicklung zentraler Logiken (und die Beibehaltung der Kompabilität) besonders wichtig (siehe die Vordiskussion zu IsWe()). Wenn du schreibst "sondern generiert daraus das Reading "DayType"", dann verursacht das bei mir ein nicht näher spezifiziertes Unbehagen... (Es impliziert, dass man mit sonstigen Logiken dann besser dort andockt.)Wir können gerne (auch mit Rudi) darüber diskutieren, ob es Sinn macht, im Rahmen von h2we ein (!) bestimmtes Reading (vorgelagert zu state, aber bei allen in h2we angegebenen Devices identisch (!)) bei anderen als .holiday-Devices abzufragen, wenn das Sinn macht, aber das weiter aufzufächern, finde ich auf den ersten Blick nicht sooo prickelnd. Bin aber weder ein guter Programmierer, noch habe ich Erfahrung mit Softwarearchitektur, kann also sein, dass mein ungutes Bauchgefühl da völlig täuscht.


DaySchedule ist bei weitem nicht das erste Modul, welches aus einem IsWe() einen Readingwert generiert.
Das global Device hat laut Rudis Definition keinerlei Readings und ich glaube holiday2we hat schon eine recht lange Historie. Mittlerweile favorisiert Rudi ja glaube ich immer, dass man möglichst ein separates Modul schreibt statt zentrale Funktionen einzubauen. Ein gutes Beispiel ist das allowed Modul, ich glaube zu der Zeit hat Rudi begonnen das etwas stärker zu forcieren.
Ich persönlich denke, dass DaySchedule durchaus das Modul sein kann, in welches die holiday2we Logik ausgeweitet werden könnte (zumindest erscheint es mir vom Scope des Moduls her passend). Ich überlege mal, wie eine entsprechende Wrapper Funktion aussehen könnte.


Rudi hatte oben ja mit der letzten Änderung schon Bauchweh geäußert. Es ist also unwahrscheinlich, dass für IsWe() so etwas wie die Unterstützung von DaySchedule und Mehrsprachigkeit kommt, sowas gehört einfach in ein eigenes Modul. Vielleicht kann man aber IsWe() und $we so  mit einbeziehen, dass man ein einzelnes DaySchedule Device optional so markieren kann, dass es als Lieferant für IsWe() und $we dient. Womöglich geht das auch ohne Änderung am fhem.pl Code, ich schaue mal.
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

Beta-User

Ein paar Anmerkungen zu dem DaySchedule-Thema:

- Es geht nicht darum, dass IsWe() genutzt wird, um einen Readingwert zu generieren. Das geschieht an vielen Stellen in einigen Modulen. Das Bereitstellen von IsWe() dient nach meinem Verständnis dazu, es beliebigen Modulen zu ermöglichen, die Frage zu klären, ob jetzt für die FHEM-Instanz $we wahr oder falsch ist, und zwar für die Tage gestern, heute und morgen. Ziel ist Konsistenz zu dieser Frage in FHEM.

- Meine Erwartungshaltung an ein Modul, das es ggf. dem Anwender ermöglichen soll, auf die Frage "$we?" Einfluß zu nehmen, wäre dementsprechend die, dass es sich "rückwärts" so an IsWe() andockt, dass diese Einstellung (z.B. in DaySchedule) auch allen anderen Modulen bekannt gemacht werden _kann_, die IsWe() abfragen, und man als User nicht darauf angewiesen ist, plötzlich seine ganzen Logiken umzustellen, weil es jetzt eine "bessere" Infoquelle gibt. (Ist schon klar, dass man das mit einem Eventhandler usw. auch "zu Fuß" hinbekäme, einen Dummy "zu füttern"; es geht um die aus Anwendersicht "organische" Einbindung in das Gesamtsystem).

- Generell: MMn. sollte FHEM als Basissystem weiter mit recht wenigen Modulen konfiguriert werden _können_, sonst wird der Einstieg noch viel schwieriger, als er heute vermeintlich schon ist. Die wenigsten haben "vom Start weg" eine konkrete Vorstellung, welche (Logik-) Module sie irgendwann mal einsetzen werden, und sich direkt mit der vollen Bewohner/Kalender-Steuerung zu befassen, erscheint schwierig, bevor man sich nicht ein Grundverständnis erarbeitet hat. (Ab da ist dann auch klar, dass es eventuell doch eine individualisierte Betrachtung der Frage geben _kann_ oder sogar geben muß, ob jetzt $we ist oder nicht. Das ist aber eine Sache, die viele eventuell dann nicht mehr so genau interessiert).

- Der o.g. Konsistenzgedanke steht auch hinter dem Vorschlag, rückwärts ein "holiday"-Device exportieren zu können.

- Ergänzend: Ein Export als .holiday ermöglicht dann nicht nur "IsWe()-Konsistenz, sondern bietet eine gewisse Sprachen-Variabilität. Das zwar nicht als echte Mehrsprachigkeit, aber wenn die Sprache vor dem Export berücksichtigt wird, kann man ja zumindest den Rückgabewert einer holiday-Abfrage beeinflussen. (Dass das bei "mehrsprachigen Haushalten" immer noch nicht optimal ist, ist klar, ebenso, dass es evtl. für die eigentliche Anzeige besser ist, Calendar (oder ggf. dein Modul) zu nutzen...)

Sind nur meine Gedanken dazu, wie gesagt: Ich versuche das eher aus der Anwender/Einsteiger-Perspektive zu sehen. Dass man als Modulentwickler ggf. ganz andere Vorstellungen hat, ist auch ok.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Loredo

Es wird ja niemand gezwungen DaySchedule zu verwenden, es ist ein Zusatzangebot.
Ich glaube mangels Konsensfähigkeit und den Erfahrungen aus der Vergangenheit wirst du keinen Idealzustand herbeiführen können.
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

Loredo

Zitat von: Loredo am 03 Juli 2019, 10:00:27
Womöglich geht das auch ohne Änderung am fhem.pl Code, ich schaue mal.


DaySchedule hat jetzt einen global-Mode, bei dem es sich zwischen die globale IsWe() Funktion schaltet, wenn es mit "define name DaySchedule global" definiert wurde. Löscht man das Device, greift wieder die ursprüngliche Funktion aus fhem.pl alleine.
Damit erhält man ein konsistentes Verhalten zwischen dem Reading "DayType" und der Ausgabe von IsWe().
Wenn man .holiday-Dateien verwendet, muss man allerdings auf die gleichzeitige Mehrsprachigkeit verzichten (also wie bisher auch). Wenn man auf Kalender Devices setzt, gibt es keinerlei Beschränkungen.


Wenn DaySchedule global agiert, dann kann man IsWe() auch im Array-Kontext abfragen ("my ($index, $long, $short, $symbol) = IsWe()") und erhält dann ein Array mit den ausgeschriebenen Werten und eine genauere Unterscheidung, ob der Tag tatsächlich ein Wochenende ist oder "nur" ein Feiertag. Diese Unterscheidung kann IsWe() bisher nicht. Außerdem ist eine Abgrenzung zwischen Arbeitstagen und freien Wochentagen möglich.


Zitat von: Beta-User am 03 Juli 2019, 11:07:52
- Der o.g. Konsistenzgedanke steht auch hinter dem Vorschlag, rückwärts ein "holiday"-Device exportieren zu können.

- Ergänzend: Ein Export als .holiday ermöglicht dann nicht nur "IsWe()-Konsistenz, sondern bietet eine gewisse Sprachen-Variabilität. Das zwar nicht als echte Mehrsprachigkeit, aber wenn die Sprache vor dem Export berücksichtigt wird, kann man ja zumindest den Rückgabewert einer holiday-Abfrage beeinflussen. (Dass das bei "mehrsprachigen Haushalten" immer noch nicht optimal ist, ist klar, ebenso, dass es evtl. für die eigentliche Anzeige besser ist, Calendar (oder ggf. dein Modul) zu nutzen...)


Das verstehe ich nicht, kannst du das näher erläutern? Warum sollte ich einen Export von etwas machen, was ich schon in einer  anderen .holiday Datei oder einem Kalender habe, den ich pflege? Ich hätte die Inhalte doch nur doppelt und eine .cal-Datei umzuwandeln in eine .holiday-Datei erscheint mir etwas, was das Calendar Modul bieten sollte, wenn man sowas braucht.
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

Beta-User

Hmmm,

ich will nicht behaupten, dass ich deine Antwort in der Tiefe verstehe, aber wenn sich das Modul nebenwirkungsfrei in die IsWe()-Abfrage einklinkt (was hoffentlich auch der Fall ist, wenn die Funktion von fhem.pl selbst aufgerufen wird mit AnalyzeCommand()&Co), dann klingt das für mich sehr nach Konsistenz  :) .

Und einen Export braucht man dann auch nicht anzubieten, weil es ja keine Differenz zwischen den unterschiedlichen Ebenen/Abfragemechanismen gibt. Das war nur ein Vorschlag, um eben über die vorgelagerten Daten Konsistenz zu erreichen, um den Preis der zugegebenermaßen doppelten Datenhaltung. (Eine ical2holiday-Funktion hatte ich mir im Sinne der genannten Konsistenz z.B. selbst mal geschrieben, um jeweils (u.a.) die aktuellen Feriendaten im "klassischen" holiday-Format zu haben (deswegen auch der Hinweis, dass es beliebig schwierig ist, die unterschiedlichen Varianten zu berücksichtigen, wie verschiedene User ical-Daten füllen und wie man das dann wieder seitens FHEM interpretiert). Da dein neues Modul die Interpretation bereits übernimmt (?), war die Annahme, dass der Export der _vorgefilterten/interpretierten_ Daten leichter ist als in Calendar direkt. Exportieren ist aber wie gesagt gar nicht mehr notwendig, wenn es stattdessen nachgelagert dasselbe Ergebnis gibt...)

Im Ergebnis: Danke, dass du dir die Zeit genommen hast, über den Einwand nachzudenken! Dass das Thema auch insoweit gelöst zu sein scheint, freut mich sehr, bin mal gespannt, wie viele das dann auch nutzen :) .




Leicht OT:
Ggf. müßte "man" (vermutlich ich) den WeekdayTimer dann nochmal ansehen: Der schaut (nach meinem evtl. unvollständigen Verständnis) immer 7 Tage in die Zukunft und wertet auch h2we-Daten direkt aus. Da war es bisher am einfachsten, vorgelagert die h2we-holiday-Dateien auszuwerten und erforderlichenfalls IsWe() nur für heute und morgen zu nutzen.
Das war (erzwungenermaßen) "schon immer" in der weiteren Vorausschau (ab übermorgen) nur teilweise richtig, es ergeben sich in der Zusammenschau insbesondere mit Calendar-gesteuerten Dummys aber ggf. Probleme, weil die Auswerte und Änderungszeitpunkte "falsch herum" sein können (WDT macht das immer um Mitternacht; wer also die Kalender=>Dummyfunktion (zufällig) etwas später aufruft, hat noch Urlaub... Muß mal über eine notify-fn hirnen, das Problem gibt's noch nicht so lange ;) ...)

Wenn ein (vorhandenes/als global definiertes) DaySchedule da im Rahmen der Vorausschau irgendwie sinnvoll berücksichtigt werden kann, versuche ich mich gerne darin, auch ein insoweit konsistentes Ergebnis für WDT zu erzielen :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Loredo

Ja, es gibt einige Module, die an IsWe() vorbei direkt holiday2we auswerten:

- 95_DOIF.pm
- 98_DOIFtools.pm
- 98_WeekdayTimer.pm
- UConv.pm (ist obsolete, Code wurde in DaySchedule integriert und wird bald gelöscht)
- HOMESTATEtk.pm (ist obsolete, Code wurde in DaySchedule integriert und wird bald gelöscht)
- RESIDENTStk.pm (passe ich an)

Diese gehören so oder so entsprechend umstellt, da sie ansonsten auch mit allen anderen neuen Funktionen in IsWe() inkompatibel sind. Ist aber auch dem geschuldet, dass es seinerzeit nur $we gab und IsWe() als zentrale Funktion noch nicht existierte.
Um weiter als 1 Tag in die Zukunft zu schauen, braucht man aber seit IsWe() nichts eigenes mehr. Das ist wie gesagt ziemlich sicher alles noch aus alter Vorzeit.


Ich behaupte DaySchedule geht sehr vorsichtig mit Datumwechsel und DST um, aber genau hier erwarte ich mir auch mehr Tests von Dritten.

Edit: Genau an dieser Stelle war mir der 2 Sekunden Versatz aufgefallen, wenn man einen InternalTimer auf 00:00:00 stellt. Wahrscheinlich begegnest du dem selben Phänomen bei deiner Beobachtung.
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

Beta-User

Na, jedenfalls für WDT stimmt das nur zum Teil:
- Direkt nach der Bereitstellung von IsWe() kam eine Version ins svn, die für heute und morgen IsWe() nutzt ;) ;
- für weekEnd und noWeekEnd gibt es seit So. (wenige Tage nach Erscheinen der aktualisierten fhem.pl!) hier eine Testversion:https://forum.fhem.de/index.php/topic,101899.0.html
Ergo: sollte von Userseite keine Fragen aufwerfen (unterstellt, ich bekomme auch noch sich ändernde Dummy...-Devices in den Griff, Vorschläge nehme ich gerne entgegen).

...es scheint sich nur keiner zu trauen, das zu testen (0 downloads bisher)... (Wenn jemand mit besseren Perl-Kenntnissen mal über die Änderungen drüberschauen könnte, wäre ich demjenigen sehr verbunden, ist nicht soooo viel, aber diese Art Funktionen und ihre Verschachtelungen? Bin mit sowas stark gefordert (der Hauptteil des Codes stammt bekanntlich von jemandem anderen) und habe einige Zeit gebraucht, bis ich den Eindruck hatte, das Ergebnis paßt... Mein FHEM läuft jedenfalls mit dem Code und ein paar WDT's soweit erkennbar problemlos, die machen aber seit ASC auch nichts mehr besonders "spürbares" am $we, und schichten tue ich auch nicht; (btw: evtl. wäre es aber eine Idee, holiday-Devices per Attribut zu den h2we-Geräten hinzufügbar zu machen?)).

Und was die beiden genannten weiteren Module angeht, werden die Maintainer da sicher einen Weg finden, wenn sie sich dazu entschließen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Loredo

Zitat von: Beta-User am 03 Juli 2019, 17:28:52
(Wenn jemand mit besseren Perl-Kenntnissen mal über die Änderungen drüberschauen könnte, wäre ich demjenigen sehr verbunden, ist nicht soooo viel


Es wäre leichter, wenn du auf Github ein Repository für den Delta Vergleich hättest.
Ich kenne allerdings WeekdayTimer überhaupt nicht.


Zitat von: Beta-User am 03 Juli 2019, 17:28:52
(btw: evtl. wäre es aber eine Idee, holiday-Devices per Attribut zu den h2we-Geräten hinzufügbar zu machen?)).


Dafür gibt es bei DaySchedule eben mehrere Attribute, u.a. eines analog zu holiday2we, bei dem man aber neben holiday-Devices auch Calendar Devices verlinken kann. Ansonsten weiß ich aber wohl leider nicht, was du meinst.
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

Beta-User

Zitat von: Loredo am 03 Juli 2019, 18:05:06
Es wäre leichter, wenn du auf Github ein Repository für den Delta Vergleich hättest.
Ich kenne allerdings WeekdayTimer überhaupt nicht.
Danke für's Angebot. Das mit den Deltas mag halt jeder "ein wenig anders"...
Ich werde da sowieso vor dem Hintergrund der heutigen Diskussion nochmal drübergehen und dann wohl erst heute/morgen IsWe() auswerten, und erst danach den allg. Durchlauf über die h2we-devices  machen. Wenn ich das fertig habe, schicke ich dir einen Link? Wenn's zu speziell ist, darfst du auch gerne nein sagen (für mich war's jedenfalls schwierig zu erkennen, wo der vorhandene Code eigentlich was macht...).

Zitat
Dafür gibt es bei DaySchedule eben mehrere Attribute, u.a. eines analog zu holiday2we, bei dem man aber neben holiday-Devices auch Calendar Devices verlinken kann. Ansonsten weiß ich aber wohl leider nicht, was du meinst.
...Analog zu holiday2we, aber ohne Calendar (kann man ohne zusätzliche Info nicht einfach so verwenden), das war die Idee (einschl. weekEnd und noWeekEnd). Damit man z.B. für einen Raum, in dem ein schichtender Mitmensch lebt, die dortigen Rollläden "anders" als den Rest mit WeekdayTimer steuern kann (so man nicht ASC nehmen mag). Da geht aber auch schon heute manches mit den vorhandenen Attributen, mal schauen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 03 Juli 2019, 18:55:50
Danke für's Angebot. Das mit den Deltas mag halt jeder "ein wenig anders"...
[...] Wenn ich das fertig habe, schicke ich dir einen Link?
Wenn du also magst (oder sonst wer):
https://github.com/rejoe2/FHEM/commit/c2614b009b3708b76ac54c2686859139d8be77b1
Ist bislang nur kurz angetestet, es scheint aber zu passen, weitere Tests im Echtsystem mache ich vorauss. am WE ( ;D ).



Zitat von: Loredo am 03 Juli 2019, 17:07:51

Edit: Genau an dieser Stelle war mir der 2 Sekunden Versatz aufgefallen, wenn man einen InternalTimer auf 00:00:00 stellt. Wahrscheinlich begegnest du dem selben Phänomen bei deiner Beobachtung.
Hab's nochmal im Code nachgesehen: Der WDT-Timer zur täglichen Neuberechnug macht das tatsächlich genau und (wohl damit andere Routinen bereits tendenziell durch sein können) absichtlich und schon immer 5 Sek. nach Mitternacht. Hat als mMn. nichts mit dieser Beobachtung zu tun (und an 2 Sek. wegen veränderter Tageslänge glaube ich nach wie vor nicht, das sind in unseren Breiten irgendwas um die 8 Minuten (würde mal unterstellen, das ist effektiv schwankend, da irgendeine Sinuskurve, jedenfalls wären mehrfach beobachte genaue 2 Sek. (mit denen man auf ca. 20 Min Delta-Tageslänge p.a. käme) schon ein extremer Zufall).

Damit man ggf. die Neuberechnung manuell bei Bedarf/Erneuerung einer heutigen h2we-Info starten kann, habe ich den vorhandenen "enable"-setter jetzt etwas aufgebohrt.



Was anderes:
Wenn _ein_ Modul "IsWe()" überschreibt, mag das noch angehen, aber wenn mehr Entwickler das als gutes Beispiel begreifen, _könnte_ das irgendwann Nebenwirkungen haben, deren Ursache dann schwer zu ergründen sein könnte (sagt mir mein evtl. nicht begründetes Bauchgefühl).

EDIT: Ich werde vermutlich trotzdem am WE mal die Testversion von Astro einspielen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Loredo

Zitat von: Beta-User am 04 Juli 2019, 15:24:50
Wenn _ein_ Modul "IsWe()" überschreibt, mag das noch angehen, aber wenn mehr Entwickler das als gutes Beispiel begreifen, _könnte_ das irgendwann Nebenwirkungen haben, deren Ursache dann schwer zu ergründen sein könnte (sagt mir mein evtl. nicht begründetes Bauchgefühl).


Dein Bauch ist aber wirklich was ganz besonderes  :D


Es ist natürlich keineswegs gedacht, dass noch irgendein anderes Modul die selbe Methode verwendet. Das soll auch nicht notwendig sein, denn diese Module sollen sich ja nur mit dem Wert befassen, den IsWe() liefert. Wenn es Bedarf gibt das Verhalten weiter zu verfeinern, sind das Erweiterungen für DaySchedule. Genau das ist ja der Sinn die Logik in ein Modul zu verlagern. Auf diese Weise sind wir aber flexibel genug keine bestehenden Installationen zu brechen.

Außerdem gibt es bei verbose=5 ein entsprechend verändertes Logging, es lässt sich also aufspüren.


Zitat von: Beta-User am 04 Juli 2019, 15:24:50EDIT: Ich werde vermutlich trotzdem am WE mal die Testversion von Astro einspielen...

Jetzt nur nichts durcheinander bringen: Astro kann isday(), sunrise(), sunset() etc ersetzen, DaySchedule kann nur IsWe() ersetzen.
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

Beta-User

 ;D Auf meinen "Bauch" (auch) zu hören, hat sich für mich als recht effektive Methode rausgestellt, manchen Problemen aus dem Weg zu gehen ;D . Dass das aber vor dem Hintergrund meiner sehr begrenzten Erfahrung kein verläßlicher Indikator für wirkliche Problem in einem Software-Umfeld ist, ist klar, und genau darauf wollte ich mit der flapsigen Wortwahl hinweisen... ::)

Und dass Astro "ganz woanders" ansetzt, ist (auch mir) schon klar, und an sich finde ich die Methode nicht unbedingt verkehrt, zentrale Routinen "global" zu überschreiben (ohne jetzt die Feinheiten zu kennen, warum die ersetzende Funktion im Detail die "bessere" ist). Problematisch wird es nur dann, wenn es von mehreren Seiten kommt (weil jemand es "noch besser" kann, aber keine "Lust", das durch/nach Diskussion mit einem anderen Entwickler in die zentrale Codebasis zu bringen (das ist bitte nur leicht ironisch zu lesen...)).

Ist angedacht, derartige Überschreibungen irgendwo (auf einfache Weise) sichtbar zu machen? (Oder gibt es das schon, z.B. in einem list zu global?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Loredo

Zitat von: Beta-User am 04 Juli 2019, 15:59:25
Ist angedacht, derartige Überschreibungen irgendwo (auf einfache Weise) sichtbar zu machen? (Oder gibt es das schon, z.B. in einem list zu global?)


Wenn die anderen Routinen aktiv sind, gibt es ein entsprechend verändertes Logging bei verbose=5.
Wenn Astro oder DaySchedule im "global mode" laufen, gibt es dort das Internal SCOPE=global. In die Internals vom global Device möchte ich nur auf Rudis expliziten Wunsch schreiben, um dort solche Änderungen noch sichtbarer zu machen. Dann wäre allerdings auch zu überlegen, ob die Markierung, welches Gerät nun eine bestimmte zentrale Aufgabe übernommen hat, nicht auch programmatisch noch anders gekennzeichnet werden sollte. Astro und DaySchedule merken sich aktuell im Modul-Hash, welches Gerät im globalen Kontext angesprochen werden soll. Das kann man natürlich auch nach $modules{global}{<USECASE>} schreiben, dafür gibt es aber keine Absprache bisher.
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

ZitatWenn _ein_ Modul "IsWe()" überschreibt, mag das noch angehen, aber wenn mehr Entwickler das als gutes Beispiel begreifen, _könnte_ das irgendwann Nebenwirkungen haben, deren Ursache dann schwer zu ergründen sein könnte (sagt mir mein evtl. nicht begründetes Bauchgefühl).
Wenn mehrere Module IsWe ueberschreiben, dann haengt von der Definitionsreihenfolge der Instanzen ab, welche IsWe() gilt.
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.
Das ist mW aktuell der Fall mit apptime, die zentrale fhem.pl Funktionen ueberschreibt.