Was ich bislang glaube rausgefunden zu haben:
- Es gibt das zentrale Skript fhem.pl, das verhält sich wie ein Daemon wenn es gestartet wird (entkoppelt sich vom Terminal) und lädt irgendwie Module, die sich unter dem FHEM Verzeichnis befinden. Das "irgendwie" ist mir schon irgendwie klar (symbolic reference, vermutlich etwas eval black magic).
- fhem.pl definiert einige Funktionen, die von den geladenen Modulen genutzt werden.
- die <nummer>_Modulname.pm Dateien unter FHEM sind eher historisch, heutzutage ist die Zahl nicht von Bedeutung.
Fragen:
- Die meisten der .pm module unter FHEM definieren ein "package main" Namespace. Damit wird der in diesem Kontext definierte Code Teil vom fhem.pl Namespace. Richtig?
- Einige Pakete definieren nur "package main", wie z.B. 99_utils.pm und sind dann de facto einfach nur ausgelagerter Code von fhem.pl (damit die Datei nicht so groß wird). Richtig?
- Wie erfolgt das Laden von Modulen unter FHEM? On Demand, oder alle/einige beim Start?
- Die .pm Module unter contrib werden nicht per se geladen, sondern nur, wenn der user sie nach FHEM verschiebt? Ich gehe davon aus, "contrib" sind Community-Beiträge mit "optionaler Funktionalität" - also nicht zum Standard-Funktionsumfang gehörig?
Gibt es einen Grund für diese Duplikate, oder sind die nicht mehr notwendig?
./contrib/statistics/2017/lib/Geo/IP/Record.pod
./contrib/statistics/lib/Geo/IP/Record.pod
./contrib/statistics/2017/lib/Geo/IP/Record.pm
./contrib/statistics/lib/Geo/IP/Record.pm
./contrib/statistics/2017/lib/Geo/IP.pm
./contrib/statistics/lib/Geo/IP.pm
./contrib/statistics/2017/lib/Geo/Mirror.pm
./contrib/statistics/lib/Geo/Mirror.pm
Hoffe mal, du kannst mit folgendem Halbwissen jedenfalls zum Einstieg etwas anfangen:
fhem.pl agiert als eine Art daemon, _wenn_ es mit einer Konfiguration aufgerufen wird.
https://wiki.fhem.de/wiki/Fhem.plhttps://wiki.fhem.de/wiki/Konfiguration
Dann stellt es auch diverse zentrale Funktionen zur Verfügung, die von allen Modulen bzw. vom User in "Einzeilern" genutzt werden können (siehe neben der commandref/Perl-Specials https://wiki.fhem.de/wiki/DevelopmentModuleAPI).
Man kann fhem.pl auch anders aufrufen (siehe Einleitung der commandref).
Geladen wird
- was in der Konfiguration steht, mit der fhem.pl aufgerufen wird. Vorausgesetzt wird für das Laden eines Moduls, dass es am richtigen Ort liegt (idR. fhem/FHEM).
ODER
- was den "richtigen" Namen hat und im Modulverzeichnis liegt (https://wiki.fhem.de/wiki/99_myUtils_anlegen)
=> "99_.*" ist speziell, alle anderen Nummern sind in der Tat historisch.
contrib ist nicht nur "am falschen Ort", sondern wird auch nicht via update aktualisiert. Nur was ein Maintainer in's Modulverzeichnis eincheckt, braucht verpflichtend Doku (commandref), in "contrib" gelten weniger "strenge" Regeln; ergo sind das vermutlich "Leichen", auf die man denjenigen ansprechen sollte, der das "verbrochen" oder übersehen hat (falls man den noch feststellen kann).
Wg. Daemon: nur wenn nicht mit "-d" gestartet oder logfile=-
1. ja
2. ja
3. on demand, 99_* immer.
4. ja. Contrib ist das, was man nicht supporten will/kann, muss auch nicht die Eincheck-Pruefung bestehen (siehe contrib/pre-commit)
Zu den erwaehnten Dateien muss der Autor was sagen.
So richtig egal scheint aber die Zahl vor dem Dateinamen nicht zu sein.
Wenn ich z.B. 98_WOL.pm nach WOL.pm umbenenne, wird das Modul anschliessend nicht mehr gefunden (define xxx WOL mac ip BOTH => Unknown Module WOL)
Belasse ich es auf 98_WOL.pm funktioniert es einwandfrei.
Es ist im übrigen durchaus beeindruckend wieviele Geräte sich im Haushalt finden mit denen FHEM was anfangen kann.
Bis auf 99 ist die Zahl egal, Module mit 99 werden automatisch geladen. Soweit ich weiß, muß der Dateiname nur mit "xx_" anfangen, die eigentliche Nummer hat keine Bedeutung mehr.
Das muss man nicht raten denn das steht hier: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Dateiname
Und so könnte eine ticket/issue-basierte Diskussion aussehen, wenn man Codeänderungen mit commits bzw. Codeverweisen verknüpfen könnte (geht ja auch in Trac): https://gl.petatech.eu/root/HomeBot/issues/1
Das zentrale Thema des Tickets ist das relativ gute Handling von 73_AutoShuttersControl.pm was Namespace betrifft. Ein wenig verbesserungswürdig, aber immerhin wesentlich besser als einige andere Module, die hart in "main" bleiben.
Da du in deinem issue#1 Fragen zu IsWe() (speziell im Zusammenhang mit AuroShuttersControl) stellst: Die Entstehungsgeschichte der Funktion und auch einige "Geburtswehen", über die wir hier und anderswo diskutieren, findest du in diesem (nicht allzu langen) Thread: https://forum.fhem.de/index.php/topic,98583.msg919649.html#msg919649.
(Ich hatte übrigens ziemlichen "Spaß", die Fernwirkungen dieser Aktion im Modul WeekdayTimer in den Griff zu bekommen; das hatte vorher nämlich eine Parallelimplementierung der holiday2we-Einträge, die mit den dann (dankenswerterweise!) eingeführten Einträgen weekEnd und noWeekEnd gar nicht klar gekommen wäre...
Es gab dann einige weitere Irritationen, weil es mind. noch ein weit verbreitetes Modul gab, das eine eigene $we-Auswertung kannte).
Seit der Umstellung auf IsWe() brauchst du übrigens nicht mehr zwingend holiday.pm, es kann auch ein beliebiges anderes Modul in holiday2we eingetragen werden, das für state "irgendwas" oder "none" liefert (bzw. weitere Readings mit yesterday bzw. tomorrow hat).
Von daher: Über Stilfragen mag ich mich nicht auslassen, über den richtigen Weg kann man streiten, aber die Vision, sinnvolle Funktionen zentral beizusteuern und auch "Gelegenheitsmaintainer" wie mich zu lehren, wie man es richtig macht, die kann ich teilen ;) .
Zitat von: RichardCZ am 21 März 2020, 11:28:51
Und so könnte eine ticket/issue-basierte Diskussion aussehen, wenn man Codeänderungen mit commits bzw. Codeverweisen verknüpfen könnte (geht ja auch in Trac): https://gl.petatech.eu/root/HomeBot/issues/1
Das zentrale Thema des Tickets ist das relativ gute Handling von 73_AutoShuttersControl.pm was Namespace betrifft. Ein wenig verbesserungswürdig, aber immerhin wesentlich besser als einige andere Module, die hart in "main" bleiben.
Ich habe mir das mal angeschaut.
In that effort, I started documenting/testing it:
Detail
Warum wurde in dem Code die holidaytowe Attributsabfrage komplett auskommentiert? Zum testen?
Wenn ich das richtig verstehe dürfte Deine Implementierung im ASC ja jetzt bereits funktionieren, ist das korrekt?
Zitat von: CoolTux am 21 März 2020, 15:21:13
Warum wurde in dem Code die holidaytowe Attributsabfrage komplett auskommentiert? Zum testen?
Ja, klar. Weil ich den Code in ein externes modul ausgelagert habe um mit einem *.t testfile drauf loszugehen.
holiday2we zieht so einen Rattenschwanz nach sich, dass ich das erstmal außen vor habe.
Ich muss ja auch erstmal den Code verstehen. Wenigstens einer dann... ;)
Oftmals In der Regel macht der Code in FHEM mehr bzw. zusätzlich noch Sachen von denen entweder keiner oder nur Rudolf weiß, dass er diese Sachen macht.
IsWe verwendet z.B. mktime, eine POSIX Funktion, die weißgottwo importiert wird, und die z.B. ein nettes Feature hat: Datumsnormalisierung.
D.h. man kann z.B. als Monat "14" eingeben. Die Regex fängt das nicht ab und das bedeutet dann "März nächsten Jahres". k.A. ob das bekannt oder gewollt ist - so weit bin ich noch nicht.
das ist gewollt und wird an einigen (anderen) stellen auch genutzt. z.b. in logProxy um den bereich zu verschieben.
Zitat von: justme1968 am 21 März 2020, 16:19:46
das ist gewollt und wird an einigen (anderen) stellen auch genutzt. z.b. in logProxy um den bereich zu verschieben.
Das muss ich dann in der Doku übersehen haben. 8)
Aber irgendwie verwendet man das "Feature" ja dann auch nur in Maßen:
my $dt = ($when && $when =~ m/^((\d{4})-)?([01]\d)-([0-3]\d)$/);Also bis Monat 19 und bis Tag 39. Also ich weiß nicht... Für eine Validierung ist die Regex zu locker und für ein "nutzen wir mktime aus" ist sie zu straff.
meine antwort bezog sich nicht auf die holiday geschichten sondern ganz allgemein auf die normalisierung. wenn du mit doku die von logProxy meinst: da wird beschrieben was geht. nicht wie es intern implementiert ist.
aber zurück zu IsWe: da es auch vom endandwender direkt genutzt werden gibt es auch hier ganz sicher fälle die sich auf die normalisierung verlassen.
Zitat von: justme1968 am 21 März 2020, 16:35:49
aber zurück zu IsWe: da es auch vom endandwender direkt genutzt werden gibt es auch hier ganz sicher fälle die sich auf die normalisierung verlassen.
Ich hatte noch meinen Text vor Deiner Antwort editiert. Mischung aus Normalisierung und halbstraffer Regex ist ein wenig halb Fisch halb Fleisch.
95_holiday.pm nutzt ja auch reichlich mktime, aber da sagt die Doku ja fast das Gegenteil:
4 12-20 01-10 Winterferien # FUNKTIONIER NICHT,
stattdessen folgendes verwenden:<br>
4 12-20 12-31 Winterferien<br>
4 01-01 01-10 Winterferien<br>Ja sorry - wenn ich dicke mktime Klöten habe, dann sollte ja
4 12-20 13-10 gehen. Oder?