Begrifflichkeiten: FHEM und fhem.pl

Begonnen von Beta-User, 21 Juni 2018, 08:09:41

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

neulich hatte ich in einer Artikelbearbeitung an einer Stelle ziemlich bewußt mal "fhem.pl" geschrieben, was dann sehr schnell in das allgemeine "FHEM" geändert wurde.

Hintergedanke des wordings war, den Leser durchaus etwas zu irritieren, und ggf. dafür zu sensibilisieren, dass FHEM als Gesamtpaket eben auch aus diversen Teilen besteht, deren Kern eben genau besagte fhem.pl ist.

Vorschlag wäre, zukünftig tatsächlich auch fhem.pl als Begrifflichkeit zu verwenden, in denen es tatsächlich um diese Kerndatei geht. Dazu wäre dann ein neuer, kurzer "Glossary"-Artikel zum Verlinken in diesen Fällen sinnvoll, in dem dann nicht viel mehr drinne steht wie die Erläuterung, dass fhem.pl die zentrale Programmdatei ist ("Schleife", timer-Überwachung, wie neulich bereits mal angedacht; hier würde es m.E. ganz gut hinpassen), die entsprechend der config-Anweisungen (define) dann bei Bedarf weitere Programmkomponenten (Module) nachlädt.

Meinungen dazu?

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Ja. Das hab ich geändert.
Meine Meinung: Das verwirrt nur und ist - entschuldigt, wenn ich das so schreibe - irrelevant. FHEM ist FHEM. So wie der Windows-Taschenrechner der Rechner ist und nicht Calculator.exe. Oder Word Word und nicht winword.exe. Egal, was für ein Rattenschwanz an DLLs, etc noch dran hängt.

Beta-User

War nicht als Kritik gemeint ;) .

Sehe das etwas anders, da man bei FHEM nicht ein monolitisches Programm einsetzt, sondern eben eine Basis, die man dann nach Gusto durch "Plugins" (aka Module) erweitern kann. _Was_ man davon nimmt, ist einem selbst überlassen bzw. man steuert das über die Konfiguration - da liegt der Unterschied zu deinen Beispielen - und der Anknüpfungspunkt zu den jüngsten Überarbeitungen.

Viele Neulinge scheinen da gar keine Vorstellung von zu haben und stolpern dann genau darüber, dass sie ziemlich wahllos und ohne die Zusammenhänge zu sehen irgendwas zusammenschustern. Und am Ende dann im Forum rummaulen, wenn nicht _sofort_ jemand das spezielle Gebräu durchschaut, was da zusammengekommen ist...

Und dann gibt es noch diese seltsamen Fragen nach "Wie programmiere ich eine Schleife, um ... zu prüfen?", die in den letzten paar Wochen mind. 2x im Forum aufgeschlagen hat. Wer sowas schreibt, hat zwar eine Vorstellung, was zu tun ist, um ein bestimmtes Ergebnis zu erreichen, aber leider fhem.pl grundlegend mißverstanden (glaube ich jedenfalls).

Ist sicher kein sooo ultra wichtiger Punkt, aber ich würde es auch auf mich nehmen, die Aufgabe zu erledigen (und @Christian: notify steht auch noch auf der Liste, das update bei Event-Monitor war als Vorbereitung gedacht; da ist mir nur nicht so richtig klar, wie mit den seithierigen Beispielen usw. umzugehen sein soll. Das ist alles eigentlich ganz ok... Diskussion aber aao).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

Ich sehe das ähnlich wie drhirn,

kein Neuling wird mit der Bergiffsunterscheidung was anfangen können, muss er aber auch nicht.

Wenn man dem Neuling ein Veständnis für die Zusammensetzung des "Gebräus" geben will, so sollte man das vllt. eher auf einer grafischen ebene, auf einem etwas höheren Level (Maximal auf logischer Modulebene) anbieten.

Wie die einzelnen Modul(-Dateien -> ein Modul kann ja durchaus aus mehreren Dateien bestehen) heißen und welche wie zusammenspielen, das ist eher Wissen für Entwickler oder Fortgeschrittene User, aber sicher nicht für Neulinge.

gb#

Amenophis86

Ich denke auch nicht, dass in den Artikeln eine Unterscheidung nötig ist. Unterstützte aber sehr wohl den Vorschlag in einem Artikel fhem.pl zu erklären. Insbesondere, da es oft im Log zu fehlern kommt wo etwas mit fhem.pl steht und Anfänger sich fragen was das ist.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

marvin78

Ich halte die Unterscheidung (unabhängig vom Ort) für sehr notwendig und folge dabei der Argumentation von Beta-User. Warum man immer nur von "Neulingen" spricht, ist mir ohnehin ein Rätsel. Auch Erfahrene User erhoffen sich sicher, aus Artikeln Erkenntnisse zu ziehen. Manchmal müssen Neulinge damit leben, etwas nicht direkt zu verstehen. Ambitionierte User fragen in dem Fall clever nach.

Beta-User

So, Feuer frei, erste Version steht hier für Anregungen, Kritik, <denkt euch was> .... bereit, nachdem sich doch einige die Mühe gemacht haben, sich dazu zu äußern.

Auf umfangreiche Verlinkungen von und zu anderen Stellen habe ich erst mal verzichtet, da m.E. erst mal die technischen Inhalte einer Prüfung unterzogen werden sollten.

Und der Artikel darf am Ende gerne so werden, dass er auch für ambitionierte User nützlich ist ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files