Autor Thema: [weitgehend gelöst] commandref_modular_DE.html kaputt - wie Verursacher finden?  (Gelesen 1640 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Hallo (vermutlich) @klausw, (oder @macs),

nutzt man https://fhem.de/commandref_modular_DE.html, kann man bei den Gerätemodulen keines mehr direkt anspringen, das nach I2C_SHT3x steht, es erscheint dann am Seintenanfang ein Hinweis, mit "Cannot load cref ...".
Der Abschnitt I2C_SHT3x selbst sieht ok aus, dafür ist in I2C_SHT21 sowohl dieses Modul dargestellt wie auch das 3x und danach wieder der 21-er.

Könnt ihr bitte mal nachsehen, ob da was kaputt ist bzw. die <li>-Einträge nicht ausgeglichen?
                 

EDIT: Titel geändert, da auch andere Teile betroffen sind...
« Letzte Änderung: 11 Juni 2019, 13:13:35 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline klausw

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1879
Antw:52_I2C_SHT.* macht commandref_modular_DE.html kaputt?
« Antwort #1 am: 03 Juni 2019, 15:26:40 »
Das mit dem nicht ansprechen von Modulen danach kann ich nicht reproduzieren. Jedoch das Durcheinander.
Das I2C_SHT21 habe ich gerade überprüft. Mir ist nichts aufgefallen.

Ich habe aber ein ähnliches Verhalten wenn ich HUEDevice und I2C_TSL2561 in modular aufrufe.

Eventuell hat das gar nix mit den Modulen selbst zu tun.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21615
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #2 am: 03 Juni 2019, 15:41:22 »
Um unbalanced tags zu finden

cd /opt/fhem/
/usr/bin/perl contrib/commandref_join.pm
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #3 am: 03 Juni 2019, 15:57:03 »
Hmm, Danke für die Antworten.

Hab's mal verschoben...

Irgendeinen Grund wird es haben, allerdings habe ich auch keine Idee, wo es herkommt, sondern bin halt von hinten her stichprobenweise nach vorne gegangen, und dann eben mehr oder weniger zufällig an dieser Stelle gelandet.

https://fhem.de/commandref_modular_DE.html#harmony kann man auch nicht laden, https://fhem.de/commandref_modular_DE.html#GOOGLECAST beinhaltet dafür dann wieder weitere Module in einer etwas seltsamen Reihenfolge. Ich kann daher im Moment nicht mal ausschließen, dass ich das mit Heating_Control (in dem Umfeld teilweise) selbst verursacht habe... Ist halt auch irritierend, dass das in anderen Teilen dann wieder paßt.

Dem Hinweis von CoolTux gehe ich dann mal heute abend nach. Danke vorab!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16025
  • s/fhem\.cfg/configDB/g
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #4 am: 03 Juni 2019, 17:06:40 »
Dem Hinweis von CoolTux gehe ich dann mal heute abend nach. Danke vorab!

Wenn es um commandref_modular geht, hilft Dir der Hinweis aber nicht weiter.

Interessanterweise kann man auf commandref.fhem.de alle genannten Module problemlos einzeln anspringen.
Es fällt aber auf, dass in den I2C_S... Modulen die Links zu den unterschiedlichen Sprachen doppelt vorhanden sind (jeweils in Klein- und Großbuchstaben).

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg Stammtisch am 20.09.2019

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #5 am: 03 Juni 2019, 17:31:38 »
Wie dann den Verursacher finden?

Wie gesagt, die I2C_...-Module sind nicht die einzigen, die da irgendwas in "Modular" durcheinanderbringen, dass ich an der Stelle gelandet bin, kann alle möglichen Gründe haben, und ich bin im Moment nicht mal sicher, ob das auch gilt, wenn man die lokal verwendet (also auf dem eigenen FHEM-Server aufruft).

Auch auf der Seite, auf die man aus https://fhem.de/#Documentation heraus landet, klappt das scheinbar:
https://fhem.de/commandref.html#I2C_TSL2561

(warum gibt es eigentlich so viele URL's, also https://fhem.de/commandref.html und commandref.fhem.de, die dann für die DE-Fassung wieder nach https://commandref.fhem.de/commandref_DE.html verlinkt?)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline klausw

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1879
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #6 am: 03 Juni 2019, 17:44:39 »
Wenn es um commandref_modular geht, hilft Dir der Hinweis aber nicht weiter.

Interessanterweise kann man auf commandref.fhem.de alle genannten Module problemlos einzeln anspringen.
Es fällt aber auf, dass in den I2C_S... Modulen die Links zu den unterschiedlichen Sprachen doppelt vorhanden sind (jeweils in Klein- und Großbuchstaben).

Die Zeile mit den Kleinbuchstaben ist im html Code des Moduls drinnen.
Inzwischen ist das überflüssig. Werde es aus meinen Modulen entfernen.
Die Großbuchstaben werden scheinbar automatisch eingefügt.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #7 am: 03 Juni 2019, 18:01:28 »
Hmmm, auch GHoma kennt die "Kleinbuchstabenlinks",

"lustig" ist auch https://commandref.fhem.de/commandref_DE.html#I2C_K30 (wo der cut herkommt, kann ich aber nicht sagen...)

Weitere Kandidaten mit "en | de":
LuftdatenInfo
Nmap
SYSMON
archetype
monitoring
powerMap
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline klausw

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1879
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #8 am: 03 Juni 2019, 18:05:16 »
Hmmm, auch GHoma kennt die "Kleinbuchstabenlinks",

kann dem Grund geschuldet sein, dass es auch von mir ist ;)
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Offline klausw

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1879
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #9 am: 03 Juni 2019, 18:09:16 »

"lustig" ist auch https://commandref.fhem.de/commandref_DE.html#I2C_K30 (wo der cut herkommt, kann ich aber nicht sagen...)

aus dem    I2C_HDC1008

=begin html_DE
wird da mit
=end html
abgeschlossen

Edit:
da gibt es einige Kandidaten
« Letzte Änderung: 03 Juni 2019, 18:11:59 von klausw »
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #10 am: 03 Juni 2019, 18:15:29 »
 :) dann hatte ich ja doch "zufällig" den richtigen an der Strippe... (die en | de bei den RPI-Modulen habe ich gar nicht erst aufgelistet, da war mir fast klar, dass die von dir sind, bei GHoma hätte ich nachsehen müssen :) ).

Mal sehen, ob sich die anderen beteiligten Modulautoren melden (nur noch igami und hexenmeister, soweit erkennbar), ggf. kann ich für igami's Module patches bereitstellen, der ist im Moment ziemlich beschäftigt...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20768
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #11 am: 03 Juni 2019, 22:27:27 »
Ich habe eine Pruefung zu commandref_join.pl und pre-commit hinzugefuegt.
Zitat
% perl contrib/commandref_join.pl
*** EN FHEM/52_I2C_HDC1008.pm: =end html: there are too many
*** EN FHEM/46_PW_Circle.pm: =end html: there are too many
*** EN FHEM/46_PW_Scan.pm: =end html: there are too many
*** EN FHEM/46_PW_Sense.pm: =end html: there are too many
*** EN FHEM/46_PW_Switch.pm: =end html: there are too many
*** EN FHEM/45_Plugwise.pm: =end html: there are too many
*** EN FHEM/72_TA_CMI_JSON.pm: =end html: there are too many
*** EN FHEM/10_UNIRoll.pm: =end html: missing
*** EN FHEM/22_XiaomiMQTTDevice.pm: No document text found
*** DE FHEM/52_I2C_HDC1008.pm: =end html_DE: missing
*** DE FHEM/45_Plugwise.pm: =end html_DE: missing
*** DE FHEM/44_S7_AWrite.pm: =end html_DE: missing
*** DE FHEM/72_TA_CMI_JSON.pm: =end html_DE: missing

Offline nils_

  • Hero Member
  • *****
  • Beiträge: 1125
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #12 am: 05 Juni 2019, 07:51:00 »
die auswirkungen waren mir damals nicht klar....
https://forum.fhem.de/index.php/topic,81087.msg731647.html#msg731647  :o :o :o


viele Wege in FHEM es gibt!

Offline klausw

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1879
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #13 am: 05 Juni 2019, 09:15:54 »


:) dann hatte ich ja doch "zufällig" den richtigen an der Strippe... (die en | de bei den RPI-Modulen habe ich gar nicht erst aufgelistet, da war mir fast klar, dass die von dir sind, bei GHoma hätte ich nachsehen müssen :) ).
...

Die Links zur jeweils anderen Sprache habe ich aus meinen Modulen entfernt.
Das ist zwar nicht der Grund für die Formattierungsprobleme aber trotzdem überflüssig.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #14 am: 05 Juni 2019, 11:39:20 »
Trotzdem Danke!

Ich habe mir jetzt auch mal die cref bei Heating_Control nochmal etwas intensiver angesehen. Die war/ist auch nicht (mehr) besonders schön gewesen und das Modul zwar deprecated, aber trotzdem... Da kommt (hoffentlich vor der nächsten update-Runde) auch nochmal ein update, mal sehen, ob das etwas ändert, denn:

Da waren recht viele <p>-Tags drin ohne </p>. Das sollte eigentlich unschädlich sein (jedenfalls laut https://wiki.selfhtml.org/wiki/P), aber notepad++ konnte damit nicht recht umgehen, bei dem Versuch, da die zusammengehörenden <ul>-Tags zu finden. Vielleicht ist ja sowas der Grund?

igami hatte ich einen patch-Vorschlag zugeschickt. Selbst wenn es nichts bringt, ist es auch nicht übel, das einheitlich zu haben...
Wenn es sonst nicht zu Fehlern führt, würde ich da jetzt erst mal keine weiteren Schritte unternehmen.



Sollte eigentlich noch was wegen der "too many"-Sache angeschoben werden, oder ist das nur ein low prio Schönheitsfehler, der irgendwann rauswächst?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20768
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #15 am: 05 Juni 2019, 20:44:47 »
Ich meine es ist ein "low prio Schönheitsfehler", aber bei bestimmten Modulen kann es verdammt lange dauern, bis es "rauswächst".

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #16 am: 06 Juni 2019, 13:17:42 »
Na ja, wenn wir hier noch eine Weile diskutieren, geht es ggf. auch schneller ;D .

Nachdem das heutige update von Heating_Control auch noch nicht den gewünschten Erfolg gezeitigt hat (da bestehen weitere Optimierungsmöglichkeiten) noch etwas Merkwürdiges, vielleicht hilft das jemandem weiter:

In der heutigen https://fhem.de/commandref_DE.html (bzw. auch der engl. Fassung) sind sowohl Heating_Control wie auch WeekdayTimer als "helper modules" gelistet; bisher dachte ich, das sei normal und richtig. In https://fhem.de/commandref_modular_DE.html finden sich beide aber unter Gerätemodul?!?

Letzteres ist eigentlich logisch, denn das entspricht der header-Info (die m.E. falsch ist und helper sein sollte, weswegen es dann gelegentlich nochmal ein update geben wird).

Hier auf dem Testsystem führt eine Korrektur richtung "helper" aber leider nicht dazu, dass alle Modul-Links dann plötzlich funktionieren würden (und nicht "fremde" Infos dazugenommen werden (besonders gerne Heating_Control, weswegen ich annehme, das das (mit) der Verursacher ist)), es muß also noch irgendwas anderes faul sein, wo auch immer. Um das zu verifizieren, habe ich dann testweise beide Dateien (und GHoma, das mir in der Hinsicht auch suspekt vorkam) mal umbenannt und commandref_modular.pl angeworfen. Die Bereiche waren weg, aber bei http://localhost:8083/fhem/docs/commandref_DE.html#HEATRONIC war dann folgendes zu sehen (danach kam erst die Heatronic-cref, anschließend die von harmony, zuletzt die perl Specials):

Ergo: Da läuft noch irgendwas anderes ziemlich schräg...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline nils_

  • Hero Member
  • *****
  • Beiträge: 1125
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #17 am: 07 Juni 2019, 09:10:42 »
In der heutigen https://fhem.de/commandref_DE.html (bzw. auch der engl. Fassung) sind sowohl Heating_Control wie auch WeekdayTimer als "helper modules" gelistet; bisher dachte ich, das sei normal und richtig. In https://fhem.de/commandref_modular_DE.html finden sich beide aber unter Gerätemodul?!?
HourCounter hat das gleiche "Problem"
viele Wege in FHEM es gibt!

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #18 am: 07 Juni 2019, 12:38:23 »
So, neueste Erkenntnisse:

Auf dem Testsystem mal alle "=end html..." (usw.)-Einträge korrigiert, dann commandref_join.pl (da gab es ein Modul mit unbalanced tags, das wurde umbenannt) und commandref_modular.pl drüberlaufen lassen.

Dann gab's zunächst mal keine Fehlermeldungen mehr aus diesen beiden pl-Durchläufen.

Aber:
läd man dann aus der modularen commandref nacheinander mehrere Detailseiten (@aktuellem firefox unter Linux, gestern war ebenfalls ff, aber unter win7), hat man den Effekt, dass die jeweils neueste zwischen die bereits geladenen Detailinfos geladen werden (also genau der Effekt auftritt, den der screenshot von gestern zeigt, bei 3 Stufen habe ich aufgehört...). Kann man mit einem vollen Reload der Seite wieder beheben (ff: strg+F5). Das scheint also am HTML-Code des Rahmens zu liegen.

Was bei mir auch nicht optimal aussieht, sind die abschließenden Perl-Specials; da gehört m.E. eigentlich mind. ein Zeilenumbruch rein und die Punkte sind zu weit rechts (kann aber auch an ff liegen, aber da der Rest anders angezeigt wird, ist das vermutlich allg. ein Thema).
 
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20768
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #19 am: 08 Juni 2019, 12:18:04 »
@Beta-User: kannst Du mir bitte eine Schritt-fuer-Schritt Anleitung fuers Reproduzieren des Problems geben?
Ich habe jetzt eine Weile herumgesucht/experimentiert, aber ich sehe das Problem nicht.
Vermutlich lade ich die Dateien anders, mache sonstwas falsch, oder erkenne das Problem nicht.

Zitat
Was bei mir auch nicht optimal aussieht, sind die abschließenden Perl-Specials
Das ist eine Folge der commandref (ohne modular) Optimierung der Sprach-Links gewesen, das ist da ganz anders geloest, als bei modular.
Ich habe versucht das zu korriegieren.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #20 am: 10 Juni 2019, 08:40:15 »
100% kann ich das nicht aus allgemeinen Quellen nachstellen, da in https://fhem.de/commandref_modular.html die Infozeile zum Maintainer usw. nicht angezeigt wird. Aber lade diese Seite mal mit einem aktuellen firefox (hier: 67.0.1 (64-Bit) unter einem aktuellen Ubuntu, kein Addblocker oder noscript aktiv).

Klicke auf HTTPMOD (gemeint ist auch im Folgenden jeweils in der Übersichtsliste).

Fehler 1:
Am linken Rand erscheint ein "Load german doc for...". Der Link funktioniert nicht.

Zurück zur Übersicht mit Strg+Pos 1, dann klick auf "IT".
"Fehler 2a" (?): Die Doku von HTTPMOD bleibt geladen und befindet sich oberhalb von der IT-Sektion.

Zurück zur Übersicht mit Strg+Pos 1, dann klick auf "template"."Fehler 2a" (?): Die Doku von HTTPMOD und IT bleibt geladen und befindet sich oberhalb von der template-Sektion.

Zurück zur Übersicht mit Strg+Pos 1, dann klick auf "allergy".Fehler 2b: allergy wird geladen, und zwar zwischen IT und template.

Läd man die Seite dann mir Strg+F5 neu, erscheint nur die jeweilige Sektion (und natürlich der allgemeine Rahmen), die anderen sind verschwunden (was m.E. eigentlich die Darstellung sein sollte, die nach Klick auf einen der genannten Punkte erfolgen sollte).

Ist das so nachvollziehbar?



Die Deutsche Fassung verhält sich da irgendwie anders, aber da kurz weitere Dinge:
Lade mal https://fhem.de/commandref_modular_DE.html#count oder
https://fhem.de/commandref_modular_DE.html#Aurora....

Nach Klick auf Aurora, Strg+Pos 1 und Broadlink sind ebenfalls beide Sektionen geladen, aber dieses Mal in der richtigen Reihenfolge.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20768
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #21 am: 10 Juni 2019, 20:26:11 »
Zitat
Am linken Rand erscheint ein "Load german doc for...". Der Link funktioniert nicht.
Stimmt, aber HTTPMOD hat auch keine deutsche Doku.
Man koennte irgendwo abspeichern, dass sie fehlt, und eine Ausnahme machen, ich fand das aber der Muehe nicht Wert.

Zitat
"Fehler 2a" (?): Die Doku von HTTPMOD bleibt geladen und befindet sich oberhalb von der IT-Sektion.
Das ist Absicht.

Zitat
Zurück zur Übersicht mit Strg+Pos 1, dann klick auf "allergy".Fehler 2b: allergy wird geladen, und zwar zwischen IT und template.
In meinem Browser wird sie nach IT geladen, vmtl. weil a nach I kommt.

Zitat
Läd man die Seite dann mir Strg+F5 neu, erscheint nur die jeweilige Sektion (und natürlich der allgemeine Rahmen), die anderen sind verschwunden
Es wird nicht gemerkt, was bereits geladen wurde, aber der zuletzt geladene Modulname ist beim Reload noch im URL.
Deswegen wird nach dem Reload dieses Modul zum Grundgeruest dazugeladen.
Mit dieser Loesung werden Links ermoeglicht, die nur diese Moduldokumentation (+ Grundgeruest) anzeigen, was ich dem Laden der kompletten commandref vorziehe.

Ich will jetzt nicht sagen, dass man es nicht auch anders loesen kann, aber ich finde keine offensichtliche Fehlfunktion.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7325
  • eigentlich eher user wie "developer"
Antw:commandref_modular_DE.html kaputt - wie Verursacher finden?
« Antwort #22 am: 11 Juni 2019, 12:57:18 »
Zitat
Ich will jetzt nicht sagen, dass man es nicht auch anders loesen kann, aber ich finde keine offensichtliche Fehlfunktion.
Vorneweg: es geht tatsächlich (nur noch) um "Kleinkram" und optische Fragen, das Ausgangsproblem scheint soweit gelöst zu sein.

Das ist eine Folge der commandref (ohne modular) Optimierung der Sprach-Links gewesen, das ist da ganz anders geloest, als bei modular.
Ich habe versucht das zu korriegieren.
Der Versuch scheint erfolglos geblieben zu sein (ich hoffe, das liegt nicht an irgendeiner cache-Funktion; nur getestet mir Strg+F5@ff).

Stimmt, aber HTTPMOD hat auch keine deutsche Doku.
Man koennte irgendwo abspeichern, dass sie fehlt, und eine Ausnahme machen, ich fand das aber der Muehe nicht Wert.
Ah, das ist nachvollziehbar, ich hatte den Mechanismus nicht wahrgenommen, sondern schlicht "irgendwas" gewählt - prompt hatte es nicht funktioniert... ::)
Zitat
Das ist Absicht.
Auch ok, stört ja im Prinzip nicht, mir war das nur etwas seltsam vorgekommen iVm. den Headerzeilen, die in den neulich geposteten screenshots zu sehen waren (das war aber ein lokales System)
Zitat
In meinem Browser wird sie nach IT geladen, vmtl. weil a nach I kommt.
...auch eine Erklärung... Irritiert halt etwas, weil die Sortierung in der Übersicht "anders tickt" und Klein- und Großbuchstaben dort (nach D-Maßstäben korrekt ein-) sortiert werden.

Zitat
Es wird nicht gemerkt, was bereits geladen wurde, aber der zuletzt geladene Modulname ist beim Reload noch im URL.Deswegen wird nach dem Reload dieses Modul zum Grundgeruest dazugeladen.
Mit dieser Loesung werden Links ermoeglicht, die nur diese Moduldokumentation (+ Grundgeruest) anzeigen, was ich dem Laden der kompletten commandref vorziehe.
Hatte schon vermutet, dass der Nachlademechanismus an der Stelle zur Vermeidung von - im Prinzip - unnütigen Datentransfers einfach gehalten ist; das ist m.E. auch nicht weiter schlimm.

Kurz noch zu
Zitat
https://fhem.de/commandref_modular_DE.html#count oder
https://fhem.de/commandref_modular_DE.html#Aurora....
Bei Aurora ist vermutlich der Modulautor schuld, und auch count scheint nicht aus fhem.pl, zu kommen. Aber zumindest count wird durch irgendeinen Mechanismus bei den fhem-Commands einsortiert, da ist es (für mich) irritierend, dass das (in der DE-Fassung) nicht funktionieren will. Schaut man sich https://fhem.de/commandref_DE.html an, ist es ebenfalls bei FHEM-Befehle zu finden, https://fhem.de/commandref_DE.html#count leitet einen dann aber zwischen die Gerätemodule...
Aber auch hier: nix dramatisches, nur Optik...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW | SIGNALduino | MapleCUN | ZWave | HUE@deCONZ@docker
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}