Wiki-Erklärung zu $NAME, $EVENT,$EVTPARTx

balli1187 · 30 Dezember 2019, 15:12:14

Hallo,

Ich stoße immer mal wieder auf Probleme wenn ich im mit den oben genannten (und ähnlichen) Variablen arbeiten möchte.
Entweder bin ich zu blind oder es gibt wirklich keine Wiki-Seite, in der kurz zusammengefasst ist, was wann in diesen Variablen steht.
Letzltlich behelfe ich mir immer mit Google Suche und rumprobieren aber so richtig das wahre ist es ja nicht....

In irgendeinem Thread habe ich auch gelesen, dass die Variablen je nach Modul unterschiedlich behandelt werden. Vielleicht lässt sich das im Kreise der Entwickler ja sich vereinheitlichen.

Grüße, Stephan

Gesendet von iPhone mit Tapatalk

CoolTux · 30 Dezember 2019, 15:15:11

Die erste Wahl sollte immer die Commandref sein

https://commandref.fhem.de/commandref_DE.html#notify

Beta-User · 30 Dezember 2019, 15:28:31

Zitat von: CoolTux am 30 Dezember 2019, 15:15:11
Die erste Wahl sollte immer die Commandref sein

https://commandref.fhem.de/commandref_DE.html#notify

Das betrifft aber "nur" den "notify"-Part und "alles", was Rudi direkt&"schon immer" betreut (z.B. kann man $EVTPART1 auch in setList bei MQTT2_DEVICE nutzen unter Verwendung der Definition aus notify (oder besser: aus https://fhem.de/commandref_DE.html#SingleFileLog)).

Was $NAME (und $name) angeht, ist das Bild "bunter", aber da halte ich jede Art der Vereinheitlichung für schwierig bis unmöglich: Es würde bestehende Implementierungen brechen. Da hilft nur, jeweils in die commandref des Moduls zu sehen, in dessen Kontext das grade verwendet wird (bei WeekdayTimer steht $NAME z.B. nämlich für das zu schaltende Device...).

@balli1987: Ergo kannst du gerne einen Wiki-Artikel zu dem Thema anlegen und die User (einmal mehr) darauf hinweisen, dass sie in die commandref als erste Infoquelle zu sehen haben. Nutzt man die "modular"-Variante, ist man mit einer einfachen Suche im Browser auch schnell am Ziel...
(Deine Art zu Suchen ist übrigens auch lt. Wiki nicht optimal: https://wiki.fhem.de/wiki/Dokumentationsstruktur).

Just my2ct.

Otto123 · 30 Dezember 2019, 16:34:04

Zitat von: Beta-User am 30 Dezember 2019, 15:28:31
Nutzt man die "modular"-Variante, ist man mit einer einfachen Suche im Browser auch schnell am Ziel...

Du meintest die "nicht modular" Variante? Weil mit der modular Variante hat man ja nur die Einleitung und das Inhaltsverzeichnis.
Suche im Browser (ctrl-f) geht doch nur, wenn alles da ist - also link oben im Forum -> Commandref

oder hab ich was falsch verstanden?

Beta-User · 30 Dezember 2019, 16:45:06

Doch, es war schon "modular" gemeint gewesen. Hätte vielleicht noch erwähnen sollen, dass man selbstredend erst mal auf den Link des betreffenden Moduls klicken sollte, damit man (nur) dessen commandref-Teil durchsuchen kann und die teils überbordende andere Doku "mancher Module" ignorieren... Der "Rahmen" ist dabei allerdings "hilfreiches Beiwerk"!

(Man kommt übrigens auch auf fast dieselbe Seite ohne den allgemeinen Rahmen, wenn man "help <Modulname>" eingibt oder die "devicespecific help" im der Detailansicht eines Devices (unten rechts) aufruft. Machen scheinbar auch zuwenig user, sonst müßte man sowas nicht separat erläutern

.)

balli1187 · 31 Dezember 2019, 10:10:22

Zitat von: Beta-User am 30 Dezember 2019, 15:28:31
Das betrifft aber "nur" den "notify"-Part und "alles", was Rudi direkt&"schon immer" betreut (z.B. kann man $EVTPART1 auch in setList bei MQTT2_DEVICE nutzen unter Verwendung der Definition aus notify (oder besser: aus https://fhem.de/commandref_DE.html#SingleFileLog)).

Was $NAME (und $name) angeht, ist das Bild "bunter", aber da halte ich jede Art der Vereinheitlichung für schwierig bis unmöglich: Es würde bestehende Implementierungen brechen. Da hilft nur, jeweils in die commandref des Moduls zu sehen, in dessen Kontext das grade verwendet wird (bei WeekdayTimer steht $NAME z.B. nämlich für das zu schaltende Device...).

@balli1987: Ergo kannst du gerne einen Wiki-Artikel zu dem Thema anlegen und die User (einmal mehr) darauf hinweisen, dass sie in die commandref als erste Infoquelle zu sehen haben. Nutzt man die "modular"-Variante, ist man mit einer einfachen Suche im Browser auch schnell am Ziel...
(Deine Art zu Suchen ist übrigens auch lt. Wiki nicht optimal: https://wiki.fhem.de/wiki/Dokumentationsstruktur).

Just my2ct.

Dass es sehr schwierig sein würde das bestehende zu vereinheitlichen, ist klar. Daher habe ich dies auch nicht als ersten Wunsch geäußert. Das dies aber die beste (wenn auch aufwendigste) Lösung wäre, sollte ebenso klar sein. Vielleicht kann man es ja aber für neue Module als kleines grundgerüst mitgeben, damit es nicht immer bunter und wilder wird. Gerade da bei FHEM ja alles über Events funktioniert, wäre es doch für alle besser, wenn man da eine einheitliche Linie fährt.

Was meine Artder informationssuche angeht, ist Google halt die "natürliche" Wahl....
Ein Wiki-Artikel würde die Möglichkeit bieten, die unterschiedlichen Behandlungen der Variablen in den Modulen mal zu sammeln. Werden die Artikel eigentlich "geprüft"? Ich kann mich natürlich hinsetzen und was dazu schreiben aber die Tatsache, dass ich diese thread hier gestartet hab, zeigt ja das ich nicht sicher bin was wann wir gehandhabt wird. Wenn da am Ende nur falsches drin steht, ist auch keinem geholfen. Ganz im Gegenteil sogar, da das FHEM-Wiki (im Gegensatz zur commandref) in der Google-Suche ziemlich weit vorn auftaucht und wahrscheinlich 90% diese weg gehen.

Gesendet von iPhone mit Tapatalk

Beta-User · 31 Dezember 2019, 16:01:20

Du kannst gerne einen Wiki-Account beantragen, im Prinzip kann jeder da schreiben, korrigieren...

Einem Developer was "vorzuschreiben" ist "na ja". Meistens ergibt sich sowas im Lauf der Entwicklung, und ich für meinen Teil habe z.B. keine große Neigung, z.B. den WeekdayTimer-Code (dessen Grundzüge vor langem jemand ganz anderes erstellt hat) anzupassen, nur weil jemand keine Lust hat, die commandref zu lesen oder zu "suchen".

Was so einen Artikel angeht, ist meine Erfahrung (ich schreibe/redigiere usw. "hin und wieder" auch was im Wiki und darf das daher sagen) die, dass solche "Sammel-Artikel" dauerhaft ein Problem darstellen, weil sie nicht gepflegt werden. Und es ist (in diesem Fall) mMn. auch nicht notwendig, da eine komplette Übersicht dazu zu erstellen, denn die steht ...? Genau: In der commandref. Grundzüge würden reichen.

Und um die commandref zu finden, bemühe ich (wie hoffentlich

99% aller user) in der Regel keine Suchmaschine, sondern weiß, dass ich da als erstes (!) nachzusehen habe und habe daher entsprechende Favoriten uä.

.

Aber nur zu: Wie gesagt, es darf jeder, also auch du; aber hinterher bitte auch die Klagen ertragen, dass "das Wiki schlecht" ist...

(Dieser Thread gehört übrigens mMn. in den Wiki-Bereich des Forums).