$we funktioniert nicht mehr

igami · 23 März 2019, 09:02:57

Zitat von: Beta-User am 22 März 2019, 17:52:39
Wird wohl Zeit für einen neuen Thread in "unterstützende Dienste", oder wäre es besser, igami direkt anzuschreiben?.

Ab jetzt lese ich hier mit. Bin nur aktuell stark ausgelastet und würde am liebsten einen komplettes rewrite des WeekdayTimer Moduls machen.

CoolTux · 23 März 2019, 09:07:04

Ist sicherlich eine gute Idee, aber vielleicht schauen wir erstmal das wir das aktuelle Problem gefixt bekommen. Dann stehst Du auch nicht so unter "Druck".
Alles was wir brauchen ist jemand der die Änderungen testen kann. Wenn der Test positiv aus fällt kann man ja erstmal einchecken und den großen Umbau machen wenn Zeit da ist.

Beta-User · 23 März 2019, 09:44:37

Zitat von: CoolTux am 23 März 2019, 09:07:04
Alles was wir brauchen ist jemand der die Änderungen testen kann. Wenn der Test positiv aus fällt kann man ja erstmal einchecken und den großen Umbau machen wenn Zeit da ist.

Nochmal der Hinweis:
Hatte gestern den Code von CoolTux leicht modifiziert, FHEM läuft damit, läßt sich starten usw. und heute wurde auch der Samstag berücksichtigt. Leider hatte ich es versäumt, gestern zum Feiertag zu erklären und dann einfach einen meiner wdt's entsprechend mal zu ändern...

Kann ich am Mo nachholen.

Anbei der diff (das mit CommandGet() ist m.E. besser wie der fhem-Aufruf von innerhalb eines Moduls).

@igami:
Wenn du gerne Unterstützung bei dem Rewrite haben willst oder Tester suchst: Sag Bescheid...
Zumindest diese internen fhem-Aufrufe sollten recht einfach zu eliminieren sein, und irgendwie fand ich das auch nachdenkenswert, wie da die Prognose erstellt wird, wenn es um die Feiertage geht (der Monat ändert sich nicht, auch wenn man für morgen nachsieht und heute der 31. ist, oder interpretiere ich das falsch?).

Vielleicht macht es wirklich Sinn, da eine zentrale IsHoliday() vorzubereiten, die man dann zu gegebener Zeit nach woanders zur Nutzung auch durch andere Module umziehen kann...

CoolTux · 23 März 2019, 10:05:33

Ich hatte auch noch mal nachgebessert. Bitte den Post mit den Anhängen beachten.

Beta-User · 23 März 2019, 10:41:27

@CoolTux:
Das hatte ich gesehen. Der wesentliche Unterschied ist der get-Aufruf.
In deinem ursprünglichen Anhang war das ein "CommandGet()", jetzt ist es wieder ein "fhem("get...".

Wie geschrieben, funktioniert das auch mit CommandGet, nur war die Syntax in der ersten Fassung nicht ganz korrekt. Jetzt paßt es. Da CommandGet m.E. der modulintern sauberere Aufruf ist, sollte man das ggf. vollends in diese Richtung umbauen. Brauchen wir dazu noch einen Import in der Modulinitialisierung? (Ich hatte FHEM gestern mit dem diff aus meinem Post gestartet, das lief problemlos...).

@ToKo: Kannst du uns bitte noch verraten, ob du tatsächlich mehrere Einträge in holiday2we hast?
Nicht, dass wir hier zwar ein Problem beheben, aber nicht deines...

@igami:
Wenn der Test am Mo "sauber" ist (also bei mehreren h2we-Einträgen nicht $we ist, und bei einem Eintrag irgendwo dann $we wahr wird), kann ich das gerne (ohne die auskommentierte Zeile) am Mo dann einchecken, wenn dir das recht ist.

CoolTux · 23 März 2019, 10:45:42

Ich gehe davon aus das das Modul aktuell nicht packages verwendet, daher läuft das Modul unter main und kann problemlos auf die Funktionen aus fhem.pl zu greifen.

Grüße

igami · 25 März 2019, 06:06:15

Zitat von: Beta-User am 23 März 2019, 09:44:37
@igami:
Wenn du gerne Unterstützung bei dem Rewrite haben willst oder Tester suchst: Sag Bescheid...
Zumindest diese internen fhem-Aufrufe sollten recht einfach zu eliminieren sein, und irgendwie fand ich das auch nachdenkenswert, wie da die Prognose erstellt wird, wenn es um die Feiertage geht (der Monat ändert sich nicht, auch wenn man für morgen nachsieht und heute der 31. ist, oder interpretiere ich das falsch?).

Zitat von: Beta-User am 23 März 2019, 10:41:27
@igami:
Wenn der Test am Mo "sauber" ist (also bei mehreren h2we-Einträgen nicht $we ist, und bei einem Eintrag irgendwo dann $we wahr wird), kann ich das gerne (ohne die auskommentierte Zeile) am Mo dann einchecken, wenn dir das recht ist.

Ich habe auch kein Problem damit, das Modul komplett abzugeben

Habe das Modul seinerzeit von Dietmar übernommen, jedoch aus Zeitmangel nie etwas dran geändert. Ziel war es das ganze mit uzsu kompatibel zu machen.

Habe mir den Patch angeschaut und bin damit einverstanden, dass du das einchecken nachher übernimmst.

Beta-User · 25 März 2019, 07:10:36

Moin,

hab's kurz getestet, funktioniert für "echte" holiday-Devices.

Leider gab's beim Eincheck-Versuch eine Fehlermeldung ("nicht unter Versionskontrolle..."), daher kann ich vermutlich diesen Service nicht ohne weiteres übernehmen.

Was weiter problematisch sein dürfte: Nutzt jemand statt eines holiday-TYPE einen Dummy, was "manche Leute" neuerdings woanders als Würgaround empfehlen (

) dürfte auch immer $we@WeekdayTimer sein... Ich habe dazu zwar eine Idee, das wird aber ggf. dauern, bis ich einen getesteten Patch liefern kann.
Anbei der patch nochmal ohne die überflüssige auskommentierte Zeile.

@CoolTux: Hast du da mehr Rechte?

@igami: Ich werde über das Maintainer-Thema nachdenken, allerdings sind meine Perl-"Kenntnisse" eher mau, und sowas wie uzsu-Kompabilität ruft bei mir große Augen hervor...

CoolTux · 25 März 2019, 08:04:44

Das wird mit Rechten nichts weiter zu tun habe denke ich.
Du hast die ,1 am Ende weg gelassen. Weißt Du wo für genau die da ist? Ich hatte das mal getestet, der get Befehl vom Holiday Device nimmt das an.

Ansonsten kann ich auch versuchen es ein zu checken.

Beta-User · 25 März 2019, 09:37:11

Zitat von: CoolTux am 25 März 2019, 08:04:44
Du hast die ,1 am Ende weg gelassen. Weißt Du wo für genau die da ist?

Hmm, ich hatte das aus dem Vorschlag von dir rausgeworfen, weil es einen prototype mismatch verursacht hatte, soweit ich mich entsinne. Daher hatte ich die Doku zu CommandGet konsultiert, und da war es nicht erforderlich.

Näheres kann ich nicht sagen, ich würde vermuten, dass die ursprüngliche ",1" evtl. auch zu dem fhem-Aufruf gehört und verhindern soll, dass eine Fehlermeldung kommt, wenn kein h2we-Device in global angegeben ist. Das würde aber in der neuen Variante sowieso bereits im Vorfeld durch das foreach verhindert, oder?

Ich kann daher nur sagen, dass es auf meinem Echtsystem mit 2 h2we-Devices so funktioniert hat wie in dem von mir angehängten Patch enthalten. Genauer: heute kein Schaltzeitpunkt in der Übersicht angegeben, wenn $we verwendet, aber kein hit in einer der beiden holiday-Dateien vorhanden ist, bzw. ein eingetragener Schaltzeitpunkt, wenn dort was steht (und das holiday-Device aktualisiert wurde).

Ansonsten sollten wir den code m.E. so ändern, dass heute und morgen IsWe() abgefragt wird und der direkte Rückgriff auf h2we nur an den anderen Tagen erfolgt, und dabei dann die MM-DD-Abfrage auf "echte" holiday-Devices beschränkt wird.

CoolTux · 25 März 2019, 09:46:42

Da ckecke ich entsprechend so wie Du es gemacht hast jetzt ein?

Wir sollten mal schauen das wir im original Thread einmal nach fragen wer sonst noch Probleme bemerkt hat.
Irgendwie meldet sich ja sonst niemand weiter. Oder die haben noch nicht upgedatet.

Beta-User · 25 März 2019, 10:06:29

Einchecken ist m.E. - erst mal - richtig.

Im "Original"-Thread ist/war WeekdayTimer kein Thema, weil es mit der Änderung in fhem.pl m.E. überhaupt nichts zu tun hat. Hier haben wir ja (noch) eine eigenständige Implementierung von $we, es wird lediglich intern auf h2we zurückgegriffen, dann aber wieder unabhängig mit eigener Logik ausgewertet.
Eine Rückfrage macht dort also m.E. keinen großen Sinn. Es wäre allenfalls eine Idee, dahin zurückzumelden, dass es in der Tat eine gute Idee zu sein scheint, zumindest für die Abfrage von heute und morgen auf IsWe() umzustellen, damit wenigstens das FHEM-weit einheitlich ist...

Was evtl. sinnvoll wäre: Diskussion zu IsHoliday().

CoolTux · 25 März 2019, 10:08:54

Zitat von: Beta-User am 25 März 2019, 10:06:29
Einchecken ist m.E. - erst mal - richtig.

Im "Original"-Thread ist/war WeekdayTimer kein Thema, weil es mit der Änderung in fhem.pl m.E. überhaupt nichts zu tun hat. Hier haben wir ja (noch) eine eigenständige Implementierung von $we, es wird lediglich intern auf h2we zurückgegriffen, dann aber wieder unabhängig mit eigener Logik ausgewertet.
Eine Rückfrage macht dort also m.E. keinen großen Sinn. Es wäre allenfalls eine Idee, dahin zurückzumelden, dass es in der Tat eine gute Idee zu sein scheint, zumindest für die Abfrage von heute und morgen auf IsWe() umzustellen, damit wenigstens das FHEM-weit einheitlich ist...

Was evtl. sinnvoll wäre: Diskussion zu IsHoliday().

Ich habe im original Thread mal eine Spur hinterlassen. Desweiteren checke ich jetzt erstmal die neue Version ein und hoffen das beste.

CoolTux · 25 März 2019, 10:13:02

Ok ich habe 98_WeekdayTimer.pm soeben eingecheckt.

Beta-User · 25 März 2019, 10:51:50

Zitat von: CoolTux am 25 März 2019, 10:08:54
Ich habe im original Thread mal eine Spur hinterlassen. Desweiteren checke ich jetzt erstmal die neue Version ein und hoffen das beste.

Danke!

Ich will den anderen Thread im Moment nicht auch noch abbonieren, daher hier:

Zitat von: Beta-User am 25 März 2019, 07:10:36
Was weiter problematisch sein dürfte: Nutzt jemand statt eines holiday-TYPE einen Dummy,

So wie ich die Meldung von ToKa in dem anderen Thread (über den ich erst gestolpert bin, nachdem CoolTux geschrieben hatte, er hätte in dem anderen Thread eine Nachricht hingerlassen hätte und ich im falschen Thread (IsWe()) gesucht hatte...) gelesen hatte, ist genau das der Fall bzw. er nutzt jedenfalls KEIN holiday-Device.

(@ToKa: eine Rückmeldung hier wäre auch hilfreich gewesen, jedenfalls ich hatte das erst eben gesehen...)

Ich kümmere mich drum, es wird aber vermutlich erst Mitte/Ende der Woche ein getestetes Ergebnis geben. Muß erst diesen Teil des Codes besser verstehen.