Unknown command rawDef und andere Fehlermeldungen

Begonnen von maltejahn, 12 Dezember 2022, 15:48:03

Vorheriges Thema - Nächstes Thema

maltejahn

Hallo,

seit dem Update wurden die "unteren" Links optimiert. Hat gedauert bis ich mit
detailLinks6 das wieder korrigieren konnte.

Unabhängig davon bekomme ich Fehlermeldungen, z.B. bei "Raw definition"
ZitatUnknown command rawDef, try help.
oder
ZitatUnknown command devSpecHelp, try help

Ein oft erwähntes neu Laden mit "STRG + F5" + "shutdown restart" (sogar den fhem service hatte ich neu gestartet) habe ich durchgeführt. Trotzdem obige Fehlermeldung.

Bei einer quasi "neuen" zweiten Fhem Installation tritt der gleiche Fehler auf

Firefox+F12 -> da erkenne ich nichts
Woran liegt es, wie kann ich dem Fehler auf den Grund gehen?

Grüße
Malte


Beta-User

Bist du sicher, dass FHEM komplett aktualisiert wurde?

Zeigt "update check" was an? Falls das nach einem update weiter der Fall sein sollte, stimmt vermutlich was mit den Berechtigungen im fhem-Verzeichnis nicht.
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

maltejahn

Sicher ist so eine Sache - "update all" bereits gemacht.
Da es bei der zweiten Installation den gleichen Fehler gibt und ansonsten keiner damit Probleme hat, muss der Fehler vor dem PC sitzen.

Ein "update check" ergibt keine Fehlermeldungen.

Einzig beim Update diese Meldung was aber nicht dafür sorgen sollte dass das gesamte Update gestoppt wird:
Zitat2022.12.12 16:11:13 1 : Downloading https://raw.githubusercontent.com/jowiemann/DBPlan-for-Fhem/master/controls_dbplan.txt
2022.12.12 16:11:13 1 : 
2022.12.12 16:11:13 1 : dbplan
2022.12.12 16:11:14 1 : PERL WARNING: Use of uninitialized value $l[0] in string ne at ./FHEM/98_update.pm line 298.
2022.12.12 16:11:14 1 : stacktrace:
2022.12.12 16:11:14 1 :     main::__ANON__                      called by ./FHEM/98_update.pm (298)
2022.12.12 16:11:14 1 :     main::doUpdate                      called by ./FHEM/98_update.pm (232)
2022.12.12 16:11:14 1 :     main::doUpdateLoop                  called by ./FHEM/98_update.pm (197)
2022.12.12 16:11:14 1 :     main::doUpdateInBackground          called by FHEM/Blocking.pm (194)
2022.12.12 16:11:14 1 :     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2022.12.12 16:11:14 1 :     main::BlockingCall                  called by ./FHEM/98_update.pm (86)
2022.12.12 16:11:14 1 :     main::CommandUpdate                 called by fhem.pl (1276)
2022.12.12 16:11:14 1 :     main::AnalyzeCommand                called by fhem.pl (1127)
2022.12.12 16:11:14 1 :     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2846)
2022.12.12 16:11:14 1 :     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (1028)
2022.12.12 16:11:14 1 :     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (609)
2022.12.12 16:11:14 1 :     main::FW_Read                       called by fhem.pl (3976)
2022.12.12 16:11:14 1 :     main::CallFn                        called by fhem.pl (784)

Mit
Zitatforeach my $l (@locList) {
    my @l = split(" ", $l, 4);
    next if($l[0] ne "UPD" && $l[0] ne "CRE"); <- Zeile 298
    $lh{$l[3]}{TS} = $l[1];
    $lh{$l[3]}{LEN} = $l[2];
  }

Beta-User

Hmm, kann auch an ff liegen (cache mal gelehrt? Andere Version getestet? Anderer Browser) oder an der besonderen Einstellung, die du da gemacht hast.
Hier klappt das jedenfalls stressfrei (ff 107.0.1 - 64-Bit unter Win, mit der default-Einstellung), und auch auf meiner Linux-Kiste habe ich bisher keine Probleme feststellen können bei der Anzeige von raw-Definitionen.

"update check" zeigt auch keine Fehlermeldungen, sondern nur, was ggf. aktualisiert werden wird. Wenn da überall "nothng to do" kommt, ist ja alles gut, aber "update all" ist eben keine Garantie, dass danach nicht doch wieder was angezeigt wird. Nur darum ging es... Aber klar, dass sowas ggf. auf zwei Systemen auftritt, dass es klemmt, wäre schon seltsam. Andererseits: An irgendwas liegt es...
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

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Icinger

Im Zweifel einfach mal in einem Anonymen Fenster testen, da wird ja kein bestehender Cache etc. genutzt, sondern wirklich alles frisch geladen.
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

frank

was steht denn im file controls_dbplan.txt?
passen owner und berechtigungen vom file?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

JoWiemann

Hallo,

in der  controls_dbplan.txt steht:

DEL FHEM/98_DBPlan.pm
UPD 2022-11-25_20:01:00 89880 FHEM/98_DBPlan.pm


Und läuft bei mir sauber durch.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

eburonen_ulrich

Zum "Raw definition" Fehler gibt es diesen Thread
https://forum.fhem.de/index.php/topic,130658.0.html

Ich habe den Fehler heute auch bemerkt und mittels der Vorschläge mit "update"  und "shutdown restart" wieder behoben.

Der Fehler trat bei mir sowohl im Ferefox  wie auch im Opera-Browser auf. Jetzt klappt es wieder - es lag also nicht am Browser.