Dynamische Commandref

[jw2013]

Im Zusammenhang mit meiner Arbeit an FHEM auf OpenWrt bin ich auf 2 Probleme bezüglich der Commandref gestoßen. Die beiden Dateien commandref.html und commandref_DE.html belegen zusammen bereits über 8 MB, und sie beinhalten immer die Dokumentation aller Module, unabhängig davon, ob diese installiert sind.

Ich habe deswegen ein Modul entwickelt, das auch für andere Installationen hilfreich sein könnte: 99_Commandref.pm

Wenn dieses Modul in den FHEM/ Ordner installiert wird, setzt es FWEXT Hooks, und übernimmt die Anfragen für /docs/commandref

Die notwendigen Informationen zum dynamischen Erzeugen der Dokumentation übernimmt es dabei (wie auch 98_help.pm) aus den Dateien docs/commandref_frame.html, docs/commandref_frame_DE.html und den unter FHEM/ installierten Modulen.

Um sehr performant antworten zu können, liest Commandref_Initialize beim Start all diese Dateien ein, und erzeugt intern eine Liste der gefundenen Text-Bausteine. Um Speicher zu sparen, werden aber nur die Positionen und Größen der gefundenen Textblöcke innerhalb der Dateien im RAM behalten, nicht die Texte selbst.

Die dynamisch erzeugte commandref.html verwendet Javascript, und fordert die Daten abhängig vom angegebenen Hashtag an. Hierbei werden folgende Inhalte dynamisch generiert:

• #top ist das dynamisch generierte Inhaltsverzeichnis
• #index beinhaltet alle Texte aus den Frame Dateien, abzüglich der Befehlsdokumentation
• #modul[-zusatz] liefert die Beschreibung zum angegebenen Modul oder Befehl

Aktuell werden die beiden Sprachen EN und DE unterstützt.

[betateilchen]

Man kann doch innerhalb der FHEM Installation auch auf die commandref komplett verzichten und stattdessen auf die identische commandref im Internet verlinken. Ich behaupte, >99% aller FHEM Installationen verfügen über einen Zugang ins Internet.

In keiner meiner FHEM Installationen gibt es eine lokale commandref, und Ressourcenknappheit ist sicher nicht der Grund dafür.

[rudolfkoenig]

Die dynamisch erzeugte commandref.html verwendet Javascript, und fordert die Daten abhängig vom angegebenen Hashtag an.

Warum ist das besser, bzw. inwieweit ist es anders als "attr global commandref modular" ?

[betateilchen]

Warum ist das besser, bzw. inwieweit ist es anders als "attr global commandref modular" ?

Das hatte ich mich auch gefragt, aber ich wollte nicht die nächste Diskussion anfangen

commandref
If set to "full", then a full commandref will be generated after each update. If set to modular (default since FHEM 6.1), there is only a short description at the beginning, and the module documentation is loaded from FHEM dynamically.

[jw2013]

Man kann doch innerhalb der FHEM Installation auch auf die commandref komplett verzichten und stattdessen auf die identische commandref im Internet verlinken.

Das Ziel war hier eine Dynamische Commandref, die sich nur auf die lokal installierten Module bezieht. Diese ist eben gerade nicht identisch mit der im Internet.

Wenn ich eine FHEM Instanz aufsetzte, und Module dazu installiere, die nicht in FHEM enthalten sind, finde ich diese logischerweise auch nicht in https://fhem.de/commandref.html.

[jw2013]

Warum ist das besser, bzw. inwieweit ist es anders als "attr global commandref modular" ?

Bei meiner Lösung wird nur ein kleiner Teil vom Hauptspeicher verwendet, und es wird nichts aufs Dateisystem geschrieben.
Bei OpenWrt-Installationen auf Flash, so wie bei Routern üblich, dürfen dynamische Dateien nicht in den Flash-Speicher geschrieben werden. In der Config-Partition hat sie auch nichts verloren, und die /var-Pfade liegen im RAM.

[betateilchen]

Das Ziel war hier eine Dynamische Commandref, die sich nur auf die lokal installierten Module bezieht.

Das macht für mich überhaupt keinen Sinn.

Offenbar haben wir völlig unterschiedliche Philosophien, Deine ist eher technisch durch die Besonderheiten von OpenWRT getrieben, meine eher von "menschlichen" Anforderungen der Anwender.

Möge jeder selbst entscheiden, was wichtiger ist.

[jw2013]

Das macht für mich überhaupt keinen Sinn.

Offenbar haben wir völlig unterschiedliche Philosophien, Deine ist eher technisch durch die Besonderheiten von OpenWRT getrieben, meine eher von "menschlichen" Anforderungen der Anwender.

Ich habe im ersten Post klar geschrieben, dass das von den Besonderheiten von OpenWrt getrieben wurde.

Meine Anforderungen sind allerdings für mich ebenso "menschlich" wie die Deinen für Dich, alles weitere ergibt sich aus technischen Umsetzungen. Das Attribute "menschlich" sollte man nie exklusiv für die eigene Seite beanspruchen...

[Prof. Dr. Peter Henning]

Das Attribute "menschlich" sollte man nie exklusiv für die eigene Seite beanspruchen...

 
Das macht er auch nicht, sondern folgt den Regeln der Usability für die Mehrheit der Menschen. Und er hat auch sicher etwas mehr Erfahrung mit den FHEM-Usern, als ein "New Member" mit 49 Posts.

LG

pah

[JoWiemann]

Hallo,

zwei Sachen stören mich, so wie ich es verstanden habe.

- ich kann das Verhalten nur durch entfernen des Moduls ausschalten
- um die Hilfe für ein noch nicht genutztes Modul zu erhalten müsste ich eine Define machen und Fhem neu starten

Grüße Jörg

[jw2013]

- ich kann das Verhalten nur durch entfernen des Moduls ausschalten
- um die Hilfe für ein noch nicht genutztes Modul zu erhalten müsste ich eine Define machen und Fhem neu starten

Zum Ausschalten muss man das Modul wieder deinstallieren, das ist richtig.

Die virtuelle Commandref deckt alle unter FHEM/ installierten Module ab, unabhängig davon, ob sie aktuell verwendet werden.
D.h. wenn ein neues Modul installiert wird, ist es nach einem Neustart in der Referenz enthalten, auch wenn noch keine Instanz über define angelegt wurde.