FHEM Modul "Timer", das war wohl nichts!

In FHEM¹ gibt es ein Modul namens Timer^🖹. Und es klingt sehr interessant! Nur ist es ein zimelicher Fail!

Weil es nicht richtig geht.

Und dabei handelt es sich leider um einen grundsätzlichen Fehler, der ziemlich schnell auffallen muss, wenn man das Modul wirklich nutzt.

1if ($i == 2) { $month = $selected_buttons[$i]-1; }
2....
3if ((time() - fhemTimeLocal($sec, $min, $hour, $mday, $month - 1, $year)) > 0) { return 'ERROR: The time is in the past. Please set a time in the future!'; }
4if ((fhemTimeLocal($sec, $min, $hour, $mday, $month - 1, $year) - time()) < 60) { return 'ERROR: The next switching point is too small!'; }

Fällt es auf? Der Monat wird 2x decrementiert. Somit schlägt der 1. Test an, wenn man einen Timer in näheren zeitlichen Umfeld definiert.

Warum bemerkt das keiner?

Sieht man sich die original Sourcen in GITHUB^🖹 an, findet man sogar eine Korrektur. Diese hat es aber nicht ins Hauptrepo von Fhem geschafft.

Echt schade! Es ist auf der offizellen Seite dokumentiert und wird im Fhem-Repo bereitgestellt. Somit kein Grund für ein externes Repo.

Noch mehr ärgert mich aber der Ort, wo die Timer gespeichert werden: ./FHEM/lib - ernsthaft, ein relatives Verzeichnis zu "was"? Und somit vermutlich zu dem Verzeichnis, das beim Programmstart von FHEM gerade aktuell war. Keine so gute Idee.

Das wäre bei mir also entweder aus systemd heraus mitten in den Sourcen von Fhem, so wie es wohl gemeint ist. Oder, wenn ich meine Testinstanz für Moduelentwicklung starte, mein Homeverzeichnis - wo es aber weder ein FHEM noch ein FHEM/lib gibt.

Och Mensch, das zeigt mir leider wieder nur zu deutlich: es wird keine gute Software geschrieben und meine Entscheidung, das Schrieben von Software für andere (Arbeitgeber aber auch gepflegte freie Softwareprojekte), aufzugeben, war richtig.

Nachtrag 06.02.2023: Die aktuelle Version im FHEM Repo geht immer noch nicht.