Weiterentwicklung commandref, war: Deutsche commandref-Sektion für 99_SUNRISE_EL.pm

[rudolfkoenig]

Ich hab die commandref bei mir gebaut und sie sah gut aus. Anbei ist ein Patch damit du die Änderungen bei dir einspielen und selbst testen kannst.

Danke schoen. Habe noch die Umlaute in HTML-Notation konvertiert (da ich allergisch auf Nicht-ASCII in Programmierdateien bin), alles in <ul> eingeschlossen (damit es genauso ausschaut, wie die anderen Module), kurz bewundert und getestet (mit contrib/commandref_join.pl und contrib/commandref_modular.pl) und eingecheckt.

Ich würde dich (und die anderen) sowieso gerne mehr bei der Doku unterstützen.

Danke fuers Angebot, das freut mich.

[Christoph Morrison]

alles in <ul> eingeschlossen (damit es genauso ausschaut, wie die anderen Module),

Warum eigentlich ul (und ohne li drunter)?

[igami]

Auch wenn das jetzt OT wird:
Ich persönlich tue mich schwer mit der Commandref, da ich keine Ahnung von HTML habe. Ich gucke dann immer nach wie das in den anderen Modulen gelöst wurde.
Im Wiki gibt es ja schon die Guidlines zur Dokumentation. Wäre es nicht sinnvoll diese so zu erweitern, dass man dann für die Standard Abschnitte (Beschreibung, Define, Set, Get, Attribute, Readings, Beispiele) gut formatierte Sektionen hat, die man sich nur noch zusammen Kopieren muss um sie mit Inhalt zu füllen?

Das Aussehen von der deutschen Commandref zu SUNRISE_EL gefällt mir übrigens sehr gut, sodass ich das auch auf meine Module anwenden werde.

[Christoph Morrison]

Ich persönlich tue mich schwer mit der Commandref, da ich keine Ahnung von HTML habe. Ich gucke dann immer nach wie das in den anderen Modulen gelöst wurde.

Du (und jeder andere Maintainer) kann sich gerne an mich wenden wenn er Hilfe bei Dokumentation (und auch Übersetzung) benötigt.

Im Wiki gibt es ja schon die Guidlines zur Dokumentation. Wäre es nicht sinnvoll diese so zu erweitern, dass man dann für die Standard Abschnitte (Beschreibung, Define, Set, Get, Attribute, Readings, Beispiele) gut formatierte Sektionen hat, die man sich nur noch zusammen Kopieren muss um sie mit Inhalt zu füllen?

Gute Idee. Ich werde  gleich mal einen Zugang zum Wiki beantragen und dann einen Draft erstellen.

Das Aussehen von der deutschen Commandref zu SUNRISE_EL gefällt mir übrigens sehr gut, sodass ich das auch auf meine Module anwenden werde.

Danke. Du kannst mich gerne involvieren, wenn du Hilfe brauchst.

[rudolfkoenig]

Warum eigentlich ul (und ohne li drunter)?

Ich will den Text einruecken, damit man beim scrollen das naechste Modul einfacher erfassen kann.
Und dafuer kenne ich nur ul.

Mit deinen vielen Tags ist die Doku zwar schoener formatiert, ich habe nur Angst, dass es manche ueberfordert, und bei der nicht zweckmaessigen Verwendung (z.Bsp. "help Modulname" im Telnet) zu unerwarteten Nebeneffekten fuehrt. Ist aber nur ein Bauchgefuehl, und ich bin dafuer, es zu testen.

Wenn du schon auf diesem Gebiet taetig bist
- mittel/langfristig will ich auf das Format "modular" umsteigen (siehe contrib/commandref_modular.pl bzw. attr global commandref modular), weil commandref inzwischen zu gross ist. Leider funktioniert das noch nicht im standalone mode (d.h. wenn die Seite von http://fhem.de/commandref.html) geladen wird.
- da inzwischen normal ist, telefone fuer alles zu verwenden, sollten wir die Doku auch dafuer optimieren.
- jeder Eintrag sollte einen direkten Link zum Text der anderen Sprache haben (manche Module machen das selbst, das ist doof, da es generisch sein sollte).

Alle Aufgaben sind eigentlich TODO fuer mich, ich wehre mich aber nicht, wenn man mir helfen will.

[Ellert]

...
- mittel/langfristig will ich auf das Format "modular" umsteigen (siehe contrib/commandref_modular.pl bzw. attr global commandref modular), weil commandref inzwischen zu gross ist. Leider funktioniert das noch nicht im standalone mode (d.h. wenn die Seite von http://fhem.de/commandref.html) geladen wird.
...

Ich würde mir wünschen, dass nicht jedes Modul oder jeder Befehl eine Zeile im Inhaltsverzeichnis erhält, das macht die Navigation sehr umständlich (13 Browserseiten)
Könnte die Nutzung des "titel" Attributes eine Lösung sein? Damit könnte die Kurzbeschreibung zu jedem Eintrag bei mouseover angezeigt werden und das Inhaltsverzeichnis wäre trotzdem kompakt. 

[Damian]

Zusätzlich würde ich mir wünschen, wenn es "modular" sein soll, dass ich nach der Auswahl nur die Doku dieses Moduls zu sehen bekomme  inkl. zurück-zum-Menü-Knopf und nicht noch andere Dinge, die mich an dieser Stelle nicht interessieren.

[marvin78]

Dann muss die commandref durchsuchbar werden. Die Browsersuche hilft aktuell sehr, die relevanten Abschnitte zu finden. Mir hilft das sogar deutlich mehr, als ein Inhaltsverzeichnis, welches für mich persönlich fast überflüssig ist.

[Christoph Morrison]

Ich will den Text einruecken, damit man beim scrollen das naechste Modul einfacher erfassen kann.
Und dafuer kenne ich nur ul.

Ich würde einen globalen Style definieren, der - ausschließlich bei Ausgabe auf dem Bildschirm, also nicht beim Druck oder so - section-Blöcke entsprechend ein wenig einrückt und als Container für jeweils ein Modul dient (auf der Einzelseitenausgabe). Ich bin kein Designer, komme eher aus der Strukturierter-Text-im-Verlagswesen-Ecke und möchte auch sicher keine knallbunte CommandRef haben.

Mit deinen vielen Tags ist die Doku zwar schoener formatiert, ich habe nur Angst, dass es manche ueberfordert, und bei der nicht zweckmaessigen Verwendung (z.Bsp. "help Modulname" im Telnet) zu unerwarteten Nebeneffekten fuehrt. Ist aber nur ein Bauchgefuehl, und ich bin dafuer, es zu testen.

Da hast du einen guten Punkt angebracht, den ich ehrlich gesagt gesagt noch gar nicht adäquat bedacht hatte.

- mittel/langfristig will ich auf das Format "modular" umsteigen (siehe contrib/commandref_modular.pl bzw. attr global commandref modular), weil commandref inzwischen zu gross ist. Leider funktioniert das noch nicht im standalone mode (d.h. wenn die Seite von http://fhem.de/commandref.html) geladen wird.

Das hat so seine Nachteile, wie du ja hier im Thread lesen kannst. Mein grober Plan sieht eigentlich vor, POD mehr zu nutzen um z.B. verschiedene Versionen der CommandRef zu erzeugen (Auf einer Seite, jedes Modul auf einer eigenen Seite mit Suchfunktion, etc.), aber auch die Struktur der Ref zu erneuern ohne den Modulmaintainern das Leben schwer zu machen.

- da inzwischen normal ist, telefone fuer alles zu verwenden, sollten wir die Doku auch dafuer optimieren.

Explizit für Telefone würde ich das nicht tun. Ich glaube wir gewinnen aber alle, wenn wir eine zugänglichere Version der CommandRef haben können.

- jeder Eintrag sollte einen direkten Link zum Text der anderen Sprache haben (manche Module machen das selbst, das ist doof, da es generisch sein sollte).

Ja, das ist auf jeden Fall sinnvoll.

Alle Aufgaben sind eigentlich TODO fuer mich, ich wehre mich aber nicht, wenn man mir helfen will.

Ich benutze FHEM nun seit über zwei Jahren sehr intensiv und freue mich mal etwas zurück geben zu können.

[nils_]

- jeder Eintrag sollte einen direkten Link zum Text der anderen Sprache haben (manche Module machen das selbst, das ist doof, da es generisch sein sollte).

gerade was entdeckt:
https://fhem.de/commandref_DE.html#Astro
der link auf die englische version funktioniert in der online cref nicht...


(ich poste auch noch einen hinweis im astro thread!!)

[nils_]

- jeder Eintrag sollte einen direkten Link zum Text der anderen Sprache haben (manche Module machen das selbst, das ist doof, da es generisch sein sollte).

Alle Aufgaben sind eigentlich TODO fuer mich, ich wehre mich aber nicht, wenn man mir helfen will.

ich hab da mal was versucht....
siehe anhang


ob die formatierung passt, weiß ich nicht, hier beim testen fehlen mir glaube ich ein paar hintergründe/css/o.ä. (hatte mir nur die commandref_join.pl runtergeladen und dann darin gebastelt, zum testen noch ein paar *.pm's)

unschön finde dabei, das es über der Überschrift steht. also über dem Modulnamen.
mir ist nicht klar, ob alle module _immer_ ein <h3>-Tag (als Einstiegspunkt) haben. Falls ja, könnte man daran unterscheiden bzw. dann die Links danach generieren. in einer neuen Zeile, oder aber in der gleichen Zeile (in kleiner schrift). letzteres wäre meine bevorzugte variante (persönliche Meinung )


ach so: ich übe noch mit perl, also immer her mit den verbesserungen

btw.: ist das noch der richtige thread dafür??



//edit:
versuch für Sprachlinks nach der Überschrift (auch im anhang!)

[rudolfkoenig]

Danke, habs etwas umformatiert, und die Links in einem div zwecks besserer Styling gepackt.
Dann etwas getestet und eingecheckt.
Wenn bei einem Modul die Links nicht auftauchen, dann fehlt es an <h3>Modulname</h3>, und dann hat man die Ehre es in der Doku zu fixen. Und die Module, die es selbst eingebaut haben, sollten es jetzt natuerlich ausbauen.

[nils_]

Danke, habs etwas umformatiert, und die Links in einem div zwecks besserer Styling gepackt.

dachte mir schon das es ein perl-profi etwas anders zusammenbaut

Wenn bei einem Modul die Links nicht auftauchen, dann fehlt es an <h3>Modulname</h3>, und dann hat man die Ehre es in der Doku zu fixen. Und die Module, die es selbst eingebaut haben, sollten es jetzt natuerlich ausbauen.

evtl. sollte man das mit dem <h3>-Tag noch irgendwo erwähnen (habe auf die schnelle dazu nix gefunden!).
auch das es "am besten" nur für den Modulnamen verwendet wird.

[nils_]

@rudi:
was mir gerade noch aufgefallen ist, ist das die links momentan nur für Module erzeugt werden. (vmtl. die aus dem SubFolder /FHEM)
aber keine Links zB. bei global und den FHEM-Befehlen (zB. define )

//edit:
müsste da eine änderung in commandref_frame.html / commandref_frame_DE.html vorgenommen werden?
wird die auch erzeugt?? oder manuell bearbeitet??

[rudolfkoenig]

Leider waere das eine manuelle Arbeit.

[nils_]

Leider waere das eine manuelle Arbeit.

ich hab da nochmal was versucht
weil manuell mag ich nicht 

zur Info:
dabei wird jetzt nach <a  name="..."> gesucht, und dann nach der nächsten Überschrift <h3> ein Link auf die andere(n) Sprache(n) erzeugt.
(nicht für den Teil der aus den Modulen kommt. sprich die Änderung vom letzten Mal...)
Hoffe das passt so erstmal an den Stellen...


/edit:
und ich glaube die abfrage für die Device modules passte nicht (bitte nochmal anschauen, evtl. hab ich da auch was falsch verstanden)

[rudolfkoenig]

ich hab da nochmal was versucht

Habe das Ergebnis angeschaut, und ich bin nicht begeistert: es sind sehr viele kurze Abschnitte, und da stoert das "penetrante" "EN DE" Text. Wenn wir das dezenter hinkriegen, dann vielleicht. Wirklich noetig finde ich es nicht.

und ich glaube die abfrage für die Device modules passte nicht (bitte nochmal anschauen, evtl. hab ich da auch was falsch verstanden)

Danke, habs gefixt.

Fuer zukuenftige Patches:
- bitte Patch mit "diff -u" (oder Vergleichbares) bauen.
- bitte darauf achten, dass keine unmotivierte Leerzeichen am Ende der Zeile auftauchen
- bitte keine Zeilen mit Dos-Line-Ending einschmuggeln.
- bitte auf 80 Zeichen/Zeile achten.

[nils_]

Habe das Ergebnis angeschaut, und ich bin nicht begeistert: es sind sehr viele kurze Abschnitte, und da stoert das "penetrante" "EN DE" Text. Wenn wir das dezenter hinkriegen, dann vielleicht. Wirklich noetig finde ich es nicht.

das seh ich allerdings genauso... für ein "dezenter" fehlt mir momentan die idee.... (zeilen zwischen den <h3>-Tags zählen, und wenn größer als X dann wieder ein link.... irgendwie auch unschön  )
kleinere schriftart wäre noch eine idee.
oder aber den "EN DE" Text in die selbe Zeile wie die Überschrift. (dafür müsste der zeilenumbruch durch <h3> umgangen werden?)

Danke, habs gefixt.

gerne.

Fuer zukuenftige Patches:
- bitte Patch mit "diff -u" (oder Vergleichbares) bauen.
- bitte darauf achten, dass keine unmotivierte Leerzeichen am Ende der Zeile auftauchen
- bitte keine Zeilen mit Dos-Line-Ending einschmuggeln.
- bitte auf 80 Zeichen/Zeile achten.

ok, werd ich versuchen.
leider kämpfe ich hier an dem rechner etwas mit der infrastruktur. ich hab leider keinen zugriff von hier auf das fhem-svn.
ich habe mir die dateien einzeln runtergeladen (runterladen müssen). die dann lokal bei mir in git "eingecheckt", und daraus dann die diff erzeugt.
vermutlich kommen da die Formatierungsprobleme her. (notepadd++ müsste ich auch nochmal die einstellungen durchgucken -.- )

[rudolfkoenig]

ich habe mir die dateien einzeln runtergeladen (runterladen müssen).

Was spricht gegen das FHEM update?

[nils_]

Was spricht gegen das FHEM update?

gar nix
ich hab nur hier kein fhem laufen und hocke hinter firewalls und proxys. das schränkt die möglichkeiten etwas ein

[rudolfkoenig]

Update kennt seit ein paar Monaten Proxy..

[nils_]

Update kennt seit ein paar Monaten Proxy..

i know, i know



hab gerade nochmal ein bisschen mit der schriftgröße gespielt...
ich erstelle mal 2 varianten, einmal mit links in der gleichen zeile wie die überschrift und einmal in der nächsten, nur etwas kleiner.


//edit:
anderer rechner, anderer weg ins inet. und schon komme ich zumindest an das svn

[nils_]

hab gerade nochmal ein bisschen mit der schriftgröße gespielt...
ich erstelle mal 2 varianten, einmal mit links in der gleichen zeile wie die überschrift und einmal in der nächsten, nur etwas kleiner.

beides im anhang zu finden....
die links sind nicht mehr so prominent, die Anzahl der Stellen an denen sie auftauchen ist natürlich identisch zur vorherigen variante.

dazu musste ich auch in einer css-datei was ändern. (<h3>-Tag ohne Zeilenumbrüche)
ob das die richtige stelle ist, weiß ich nicht, kenne mich mit css überhaupt nicht aus.

anderer rechner, anderer weg ins inet. und schon komme ich zumindest an das svn

ich hoffe die von dir erwähnten Dinge passen jetzt.

[nils_]

so ich glaube das ist die schönere variante....

musste auch noch etwas umbauen, da für einige module der regex nicht geklappt hat.
- hinter <a name="..." ging es noch weiter
- der modulname ist nicht immer im format <h3>xyz</h3> gewesen (mehrzeilig)
- das zusätzliche <p> nach =end html hab ich als workaround reingebaut, da ja <h3> keinen umbruch mehr macht, und daduch manche überschriften ans Ende des vorherigen Moduls gewandert ist


aufgefallen ist mir auch noch bei einigen modulen, das nach =begin html_DE  nicht das korrekte =end html_DE kommt. einfach mit der Browsersuche mal nach =end html in der commandref suchen.

ich lasse die anderen beiden dateien aus dem post vorher auch noch drin. (auch wenn sie im Grunde nutzlos sind )

[Prof. Dr. Peter Henning]

Der bessere Weg wäre:

- Saubere XML Tags aus einem etablierten Dokumentationsformat verwenden, z.B. aus docbook
- Je nach gewünschtem Anwendungszweck per XSLT/docbook Prozessor daraus entweder eine große HTML-Datei, oder eine PDF-Datei, oder viele kleine HTML-Dateien oder, oder oder erstellen.


LG

pah

[Christoph Morrison]

- Saubere XML Tags aus einem etablierten Dokumentationsformat verwenden, z.B. aus docbook
- Je nach gewünschtem Anwendungszweck per XSLT/docbook Prozessor daraus entweder eine große HTML-Datei, oder eine PDF-Datei, oder viele kleine HTML-Dateien oder, oder oder erstellen.

Full ack. Es gibt bessere Lösungen für das Thema als manuell alle möglichen Elemente auszuzeichnen und eine Krücke an die nächste zu bauen. Es gibt mit Pod::DocBook auch einen etablierten Legacy-Konnektor für die POD.

Aber hier sind wir damit ziemlich off topic - es ging nur um die Doku des 99_SUNRISE_EL.pm.

[Prof. Dr. Peter Henning]

Nein, eigentlich nicht. Es geht schon auch um die generelle Frage, denn die Dokumentation wird immer umfangreicher. Und manche Module liefern so viel Daten für die Commandref, dass das kaum noch beherrschbar ist (z.B. DOIF).

LG

pah

[Christoph Morrison]

Nein, eigentlich nicht.

Doch.

In diesem Thread werden nun mindestens drei Themen behandelt und zwei davon wären in einem eigenen Thread sinnvoller, u.a. die Frage wie man allgemein künftig mit der Generierung der Commandref umgehen möchte. Das ist ein so wichtiges Thema, dass es nicht hier unter falscher Flagge segeln sollte. Nicht jeder, u.a. ich, liest jeden Beitrag, aber es betrifft hier so ziemlich jeden.

Deswegen würde es mich glücklich machen, wenn ein Mod diesen Thread auftrennen und alles was allgemein zum Thema CommandRef geschrieben wurde, in einen eigenen Thread forkt in dem wir gerne weiter brainstormen können. Hier finden das aber zu wenig Leute.

Es geht schon auch um die generelle Frage, denn die Dokumentation wird immer umfangreicher. Und manche Module liefern so viel Daten für die Commandref, dass das kaum noch beherrschbar ist (z.B. DOIF).

Wir müssen uns z.B. mal Gedanken darüber machen, wo die Grenze zwischen Wiki-Beiträgen und CommandRef liegt. DOIF ist ein gutes Beispiel, wo ich finde, dass die ganzen Beispiele besser im Wiki aufgehoben sind und die CommandRef lediglich als Befehlsreferenz mit wenigen Beispielen und dafür gerne einem Link aufs Wiki dienen sollte. Ich finde die Anzahl der Beispiele bei SUNRISE_EL z.B. im Gegensatz wieder zu wenige, da durch das Design des Moduls (und die aktuell noch mangelhafte englische Doku) die Syntax deutlich besser erklärt werden kann als durch eine reine Beschreibung.

[Prof. Dr. Peter Henning]

Ich bleibe bei Nein.

pah

[nils_]

aufgefallen ist mir auch noch bei einigen modulen, das nach =begin html_DE  nicht das korrekte =end html_DE kommt. einfach mit der Browsersuche mal nach =end html in der commandref suchen.

ich liste die module mal hier auf

Code Auswählen Erweitern


44_S7_AWrite.pm
=end html_DE in neue Zeile

45_Plugwise.pm
46_PW_Circle.pm
46_PW_Scan.pm
46_PW_Sense.pm
46_PW_Switch.pm
52_I2C_HDC1008.pm
=end html muss in =end html_DE geändert werden


bei

Code Auswählen Erweitern

57_Calendar.pm
Calender -> Calendar (Zeile 3183, Titel...)
ist es nur ein Schreibfehler CalendAr != Calender (ist mir nur aufgefallen, weil bei den ersten varianten der Anchor-Name zur Überschrift passen musste)

im Grunde ist das alles nur kosmetischer Natur, weil die "=end html" Tags in der cref auftauchen, deshalb wollte ich jetzt nicht direkt die Maintainer kontaktieren.


btw. Maintainer für 52_I2C_HDC1008.pm steht keiner in der Maintainer.txt ?!

[Christoph Morrison]

Da hier alles zum Thema "Deutsche commandref-Sektion für 99_SUNRISE_EL.pm" gesagt ist, habe ich einen Moderator geben die Off-Topic-Beiträge abzutrennen und den Thread geschlossen.

[Dr. Boris Neubert]

[verschoben]

[Dr. Boris Neubert]

bei

Code Auswählen Erweitern

57_Calendar.pm
Calender -> Calendar (Zeile 3183, Titel...)
ist es nur ein Schreibfehler CalendAr != Calender (ist mir nur aufgefallen, weil bei den ersten varianten der Anchor-Name zur Überschrift passen musste)

gefixt

[Dr. Boris Neubert]

Wir müssen uns z.B. mal Gedanken darüber machen, wo die Grenze zwischen Wiki-Beiträgen und CommandRef liegt. DOIF ist ein gutes Beispiel, wo ich finde, dass die ganzen Beispiele besser im Wiki aufgehoben sind und die CommandRef lediglich als Befehlsreferenz mit wenigen Beispielen und dafür gerne einem Link aufs Wiki dienen sollte. Ich finde die Anzahl der Beispiele bei SUNRISE_EL z.B. im Gegensatz wieder zu wenige, da durch das Design des Moduls (und die aktuell noch mangelhafte englische Doku) die Syntax deutlich besser erklärt werden kann als durch eine reine Beschreibung.

Ja, es ist sinnvoll, sich darüber Gedanken zu machen, wo die Grenze zwischen CommandRef und Wiki-Beitrag liegt.

Meiner Meinung nach muss die CommandRef den durchschnittlich versierten Anwender in die Lage versetzen, das Modul in Betrieb zu nehmen, und einfache Beispiele liefern, wie es benutzt wird. Trickreiche Verwendungen, ausgearbeitete Beispiele für praktische Anwendungen, und ausführliche Anleitungen gehören ins Wiki.

[Dr. Boris Neubert]

Ich bleibe bei Nein.

In welchem Kontext steht das Nein-Doch-Nein? Mir fehlt der Bezug im ersten Nein.

[betateilchen]

Meiner Meinung nach muss die CommandRef den durchschnittlich versierten Anwender in die Lage versetzen, das Modul in Betrieb zu nehmen, und einfache Beispiele liefern, wie es benutzt wird.

Genau so nutze ich auch die commandref (genauer: die device secific help, die daraus generiert wird) wenn ich ein neues Modul erstmalig in Betrieb nehme "help modulName" und dann erwarte ich, dass ich alle Informationen bekomme, um ein grundsätzlich funktionsfähiges device dieses Typs anlegen zu können. Dass dieses neue device dann sofort 100% all meiner Wünsche erfüllt, erwarte ich nicht, und das ist auch nicht meine Erwartungshaltung an die commandref.

Meine Erwartung an die commandref jedes Moduls:

• alle set sollten aufgeführt und in ihren Grundzügen beschrieben sein
• alle get sollten ... (siehe oben)
• alle attr sollten ... (siehe oben)

Leider werden dieser Erwartungen selbst von zentralen Modulen nicht immer erfüllt (was in vielen Fällen daran liegt, dass Attribute kreuz und quer zwischen Modulen verlinkt sind)

[igami]

Die readings sollten auch Beschrieben werden

[betateilchen]

Besser: readingNames, die keiner Beschreibung/Erklärung bedürfen

Und wenn ein Reading wirklich einen so komplzierten Namen hat wie das teilweise bei Homematic der Fall ist, dann gehört die Erklärung ins Wiki.

[herrmannj]

Nix da. Muss ja auch möglich sein mit einem Modul allein mit der amtlichen Anleitung, aka commandref, zu arbeiten.

[betateilchen]

Da hättest Du aber als Homematic Neueinsteiger schlechte Karten...

[rudolfkoenig]

so ich glaube das ist die schönere variante....

Habs eingecheckt, und auf fhem.de ausgerollt. Theoretisch fehlt noch die Anpassung fuer die anderen Styles, aber da wird es kompliziert, weil manche nicht mehr aktiv betreut werden.

P.S.: eigentlich gehoert dieser Beitrag in das geteilte Thema https://forum.fhem.de/index.php/topic,81087.msg730869.html#msg730869 aber wenn man da Antwortet, dann landet die Antwort in diesem Thema. Und keine Ahnung, wie ich das dahin verschieben soll. Kann jemand helfen?

[igami]

Besser: readingNames, die keiner Beschreibung/Erklärung bedürfen

Und wenn ein Reading wirklich einen so komplzierten Namen hat wie das teilweise bei Homematic der Fall ist, dann gehört die Erklärung ins Wiki.

Ich möchte schon wissen welche readings erzeugt werden.

[nils_]

Habs eingecheckt, und auf fhem.de ausgerollt. Theoretisch fehlt noch die Anpassung fuer die anderen Styles, aber da wird es kompliziert, weil manche nicht mehr aktiv betreut werden.

irgendwie wurde das css nicht Übernommen??
lokal sieht das bei mir so aus wie im anhang.
also etwas kleiner und ohne zeilenumbruch.

P.S.: eigentlich gehoert dieser Beitrag in das geteilte Thema https://forum.fhem.de/index.php/topic,81087.msg730869.html#msg730869 aber wenn man da Antwortet, dann landet die Antwort in diesem Thema. Und keine Ahnung, wie ich das dahin verschieben soll. Kann jemand helfen?

sollen wir dafür ein neues thema eröffnen??
es geht ja eher um den grundsätzlichen inhalt der commanref (und was ins wiki sollte).
aber wir posten hier was dazwischen was eher mit dem parsen zu tun hat

[rudolfkoenig]

irgendwie wurde das css nicht Übernommen??

Doch, vtml. brauchst du einen ordentlichen Reload.

sollen wir dafür ein neues thema eröffnen??

Gerne.

[nils_]

Gerne.

für die Anpassungen am "Parser" usw. -> https://forum.fhem.de/index.php/topic,81238.0.html

[dev0]

Ich bin mir nicht ganz sicher, ob es an den Anpassungen aus diesem Thread liegt, aber seit ein paar Tagen sieht fhem.de/commandref.html#ESPEasy anders aus als meine lokale Version, die ich noch nicht aktualisierte Verison habe.
Ich füge gerne 1-2 <BR> vor/nach <H3> ein, ich wäre mir aber gerne sicher, dass die Formatierung, dann auch erst einmal so bleibt

[rudolfkoenig]

Eigentlich sollte pro Modul nur ein <h3> geben, "ESPEasy Device" und "ESPEasy Bridge" wuerde ich mit <h4> formatieren.

[dev0]

Danke für den Hinweis, habe es so eingecheckt.