[weitgehend gelöst] commandref_modular_DE.html kaputt - wie Verursacher finden?

Begonnen von Beta-User, 03 Juni 2019, 13:19:47

Vorheriges Thema - Nächstes Thema

Beta-User

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...
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

klausw

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

CoolTux

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://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

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-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

betateilchen

Zitat von: Beta-User am 03 Juni 2019, 15:57:03
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).

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

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-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

klausw

Zitat von: betateilchen am 03 Juni 2019, 17:06:40
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

Beta-User

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-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

klausw

Zitat von: Beta-User am 03 Juni 2019, 18:01:28
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

klausw

#9
Zitat von: Beta-User am 03 Juni 2019, 18:01:28

"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
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

Beta-User

 :) 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-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

rudolfkoenig

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

nils_

viele Wege in FHEM es gibt!

klausw



Zitat von: Beta-User 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 :) ).
...

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

Beta-User

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-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