[erledigt]erläuterung/unterschied fhem-befehl perl-modus

[DasQ]

Hi,


Kann sein ich bin blind weil ich es nicht finde, aber gerade bei der Suche von ,,unterschied fhem-befehl perl-modus", bin ich nicht fündig geworden.
Ich hoff ihr könnt mir folgen ... das ist so ne frage die den Anfänger immer wieder extremst verwirrt.
Ihr seht sofort was was ist (ich glaub inzwischen auch). Aber dem Laien bleibt das zuerstmal ein großes Geheimnis.

-warum
-wieso
-weshalb
-was Is besser (notorische Frage)
-wann setzt man was am besten, wie ein (styleguide)
-was sollte man am besten so und nicht so tun (Tue dies, lasse das)

Immer bezogen auf den ,,Unterschied"
Ich weis es kommt am Ende oft das gleiche raus, aber ein ,,sleep 0.1" tut halt dann doch was anderes.

Wie könnte man sowas einfach verständlich im Wiki rüberbringen?  Und am besten so zentral das es von überall aus querverlinkt wird.

Grüssle Andy

[Beta-User]

...dann versuche ich's mal, die wirklichen Experten können das dann ja vollends klarstellen...

In dem Zusammenhang sind m.E. zwei Kürzel wichtig, die man kennen sollte:

TMTOWTDI und TIMTOWTDIBSCINABTE.

Beide Kürzel (eigentlich: die hinter TIMTOWTDI stehende Programmierphilosphie) sind eng mit Perl verbunden, und wir erinnern uns:

FHEM ist ein Perl Server für...

Also: Alles, was wir hier machen ist Perl! Auch was in die Kommandozeile geht, in der cfg steht oder via "Perl"-Modus "{...}" aus einer myUtils mit "fhem ("...")" oder "fhem "..."" aufgerufen wird, ist Perl; auch DOIF oder MSwitch "versteckt" "nur" am Ende Perl vor dem Anwender.

Halten wir daher fest: Es gibt kein "besser", bzw. was "besser" ist, liegt im Auge des Betrachters. Das ist (nach meinem Verständnis auch) die Aussage hinter dem ersten Schlagwort.

Die "consistency"-Erweiterung führt m.E. dazu, dass innerhalb fhem (bzw. der commandref) fast alle Funktionsaufrufe für fhem.pl-Funktionen als "fhem ("...")" notiert und erläutert sind. Das macht m.E. Sinn, damit Leute, die nicht "täglich" damit umgehen müssen, die "vereinfachte" und aus der Kommandozeile/FHEMWEB bekannte Schreibweise nutzen können.
Ergo macht es für diesen Nutzerkreis in der Regel Sinn, genau diese Notation zu nutzen.

Sie ist allerdings immer mit einem Umweg verbunden (und gewissen Sicherheitsfeatures), weswegen "Experten" (v.a. Modulentwickler) in den Wiki-Dokumenten für Developer auch die Darstellung finden, wie "effizienter" gearbeitet werden kann.

Im Falle von "sleep" ist es eben so, dass eine fhem.pl-"Sicherheitsfunktion" die ist, das als InternalTimer in den Hintergrund zu schieben, statt wirklich ein Perl-sleep zu verwenden und FHEM solange anzuhalten. Aus dem Grund gibt es in der cref dazu auch die entsprechenden Hinweise (meine ich doch).

Wie man das (oder die "korrekte" Fassung) "den Leuten" (wo) näherbringen kann? Gute Frage...

Vielleicht könnte man das (übersetzt) bei "Perl" unterbringen, und zunächst mal Links aus dem QuickStart und myUtils-Artikel setzen?

[justme1968]

wenn ich richtig gesehen habe ist der eigentliche ursprung der frage das fhem bzw. perl sleep.

deshalb denke ich das ist der falsche ansatz das zu erklären. das es mehr als einen weg gibt gilt immer und überall und ist nicht perl spezifisch.

fhem sleep und perl sleep haben nichts miteinander zu tun. ausser dem namen der sich im nachhinein als unglücklich darstellt. für das fhem sleep wäre wait, delay, expect oder irgendetwas in der art besser gewesen. erst recht da das fhem sleep inzwischen auch auf ein event warten kann statt nur eine bestimmte zeit.

wichtig ist zu wissen das
- weder fhem noch perl von haus aus nebenläufig sind
- perl sleep wirklich schläft und alles andere dabei steht
- fhem sleep im hintergund wartet bis eine bestimmte zeit vergangen
  ist oder ein event aufgetreten ist.


ansonsten: die fhem ebene stellt bestimmte dinge vereinfacht zur verfügung die man genau so gut (aber mit mehr aufwand) 'zu fuss' direkt in perl machen könnte. es gibt dinge die auf beiden ebenen gehen. hier gibt es in der regel kein 'besser' aber die fhem ebene verhindert gewisse fehler bzw. fängt diese automatisch ab. manches ist klarer und kürzer auf der fhem ebene, manches geht einfacher und mächtiger in perl. jeder fhem befehl/funktion/modul/device/... ist intern perl. die internen fhem routinen kann man von der perl ebene direkt aufrufen um code wieder zu verwenden und die oben angesprochenen sicherheitsfeatures zu nutzen.


als reiner anwender gibt in der regel zu anfang keinen grund 'einfach so' mit der perl ebene anzufangen. man kann problemlos ziemlich lange auf der fhem ebene bleiben.

ich denke ein guter zeitpunk sich umzuschauen ist wenn man hier an grenzen stößt. dann kann man anfangen und die perl ebene 'entdecken'. ein typischer grund wäre ein meinen äugen dinge generischer anzugehen statt für jedes device einzeln. d.h. z.b. routinen bauen die wiederverwendbar dinge in mehreren räumen tun. obwohl man mit passenden device namen auch hier auf der fhem ebene recht weit kommen kann.

[DasQ]

Man lernt nie aus.

Danke den beiden erklären.

Ich bin der Meinung, eure Texte sollte so 1zu1, mal mindestens in QuickStart und alle andern anfängerbereichen.
Das von mir genannte Beispiel sollte aber nicht nun eins bleiben, denn ihr wisst am besten wo die fallen versteckt sind. Wenn man wieder und wieder die selben fragen beantwortet muss.
Mit ähnlich Kontext.


Thx

[Prof. Dr. Peter Henning]

eure Texte sollte so 1zu1, mal mindestens in QuickStart und alle andern anfängerbereichen

Hm.

Die beiden Erklärungen sind gut, aber gehen an der generellen Frage nach dem Unterschied der beiden Zugangswege fhem/perl vorbei und greifen noch andere Aspekte auf. Würde man diese Erklärungen 1:1 in die Dokumentation aufnehmen, würde diese deshalb umfangreicher - aber nicht besser.

Weil ich der Ansicht bin, dass es Zeit für eine stringente und in einem heruntergeschriebene Anleitung ist, habe ich mich dessen angenommen. Ab Herbst kann jeder beurteilen, ob das gelungen ist.

LG

pah

[Beta-User]

Bin auch gegen eine 1:1-Übernahme und finde das sehr gut, wenn jemand der Sache annimmt, der sowohl Perl (und FHEM) gut kennt als auch Ahnung von Didaktik hat.

Bin mal gespannt, wie die Expertenlösung zu dem "Problem" aussieht .

Einstweilen wäre es vermutlich keine ganz schlechte Idee, was (kurzes!) in den Quick-Start aufzunehmen. Wenn ich dazu komme, stelle ich in dem benachbarten 99-myUtils-anlegen Thread mal einen Entwurf zur Diskussion.

[DasQ]

ich bin der meinung, das mit dem 1zu1 war nur meine meinung
über das wenn und aber, kann man bekanntlich streiten, will ich aber garnicht.
ich hatte lediglich versucht anhand eines beispiels, dass unmittelbar zuvor hier im forum aufgetaucht ist
und mir selbst auch schon in änlicher art wiederfahren ist, etwas entwirrung zu schaffen/hinterfragen für mich und andere.

Danke das sich dem einer annimmt.

p.s. weil ich dich @justme1968 gerade seh, in dein Github einträgen ist mir neulich aufgefallen, das etwas deutsch im englisch vorkommt (als bsp. " wenn das reading temperature heisst statt temperature1 muss es nicht angegeben werden.")