Wiederholte Global global UNDEFINED Meldung nach Update

Begonnen von sirnoname, 25 Juli 2019, 11:52:10

Vorheriges Thema - Nächstes Thema

sirnoname

Hallo,

ich hatte das Problem das meine 3 Aussensensoren mit 3 Kanälen plötzlich nacheinander in einem Plot, also zu einem Sensor wurden. Dies begann nach einem Update vor gut einem Halben Jahr. Ohne das in dieser Zeit die Konfiguration geändert wurde.
Daher habe ich heute alle Sensoren samt plots und Logs gelöscht, die fhem.cfg hat diese Sensoren nicht mehr.

Leider kommt trotzdem in der Log:
2019.07.25 11:00:27 2 : nanoCUL433: CUL_TCM97001 Unknown device CUL_TCM97001_145, please define it
2019-07-25 11:00:27 Global global UNDEFINED Prologue_145 CUL_TCM97001 CUL_TCM97001_145

Dieser Sensor steht nicht in der CFG. Keine Ahnung wo er noch stehen soll?
Ich habe im Forum einiges durchgelesen, die Posts waren aber alle offen und es wurde über zerstörte Module diskutiert. Im FHEM Verzeichnis sind die Module nun mit heutigem Datum abgelegt, da ich noch ein Update nachgeschoben habe. Sind diese bei FHEM defekt?

Wäre toll, wenn mir hier jemand weiterhelfen könnte.

Beta-User

Laß raten: du hast die cfg manuell außerhalb von FHEM editiert, und die Zeilen gehören zum FHEM-Start?

(Gleich abgewöhnen, gibt bessere Wege, z.B. https://wiki.fhem.de/wiki/Import_von_Code_Snippets...)
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

sirnoname

Ja, ich habe durchaus manuell editiert.
Das mit dem FHEM Start verstehe ich nicht. Das sind LOG Zeilen und die kommen durchgehend wiederholt zur Laufzeit, nicht nur beim Start.
in der CFG sind diese Geräte nicht mehr.

Beta-User

Zitat von: sirnoname am 25 Juli 2019, 13:20:54
Ja, ich habe durchaus manuell editiert.
Wie man hier einmal mehr sieht, ist das nebenwirkungsträchtig. Die allgemeine Empfehlung lautet daher: lassen...
Und du brauchst auch keinen weiteren support (auch durch andere) zu erwarten bei der Aufklärung solcher "Seiteneffekte".

(Wenn du eine Versionierung haben willst: nimm configDB).

Zitat
Das mit dem FHEM Start verstehe ich nicht. Das sind LOG Zeilen und die kommen durchgehend wiederholt zur Laufzeit, nicht nur beim Start.
in der CFG sind diese Geräte nicht mehr.
Klar ist, dass beim Neustart nicht nur fhem.cfg gelesen wird, sonder auch die fhem.save, die ua. die aktuellsten Readingwerte beinhaltet (es soll ja möglichst alles gleich wieder richtig laufen...). Die hierzu gehörenden setReading-Befehle gehen daher ins Leere. Editiert man via FHEMWEB, werden auch die zugehörigen Reading gelöscht, und das Problem sollte nicht existent sein.

Warum es ggf. auch später noch auftritt: keine Ahnung...

Mach mal ein save und starte dann neu. Dann sollte es eigentlich weg sein.
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

sirnoname

./log/fhem.save
./demolog/fhem.save
./restoreDir/2017-06-11/log/fhem.save
./restoreDir/update/2019-05-19/log/fhem.save
./restoreDir/update/2019-05-19/demolog/fhem.save
./restoreDir/update/2019-07-25/log/fhem.save
./restoreDir/update/2019-07-25/demolog/fhem.save
./restoreDir/2017-04-08/log/fhem.save
./restoreDir/save/2019-06-15/log/fhem.save
./restoreDir/save/2019-06-14/log/fhem.save
./restoreDir/save/2019-07-25/log/fhem.save
./restoreDir/2018-12-27/log/fhem.save
./restoreDir/2018-12-27/demolog/fhem.save

Welches wäre die Richtige?
Die unter /log hat keine Geräte die der Fehlermeldung entsprechen. Die demolog ist mir noch ein Rätsel, da ich kein Demo fahre.

Beta-User

./log/fhem.save

ABER: Die ist schon gleich gar nicht dafür gedacht, editiert zu werden.... Finger weg, würde ich mal sagen.
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

sirnoname

Geht leider nicht weg und es ist auch kein Eintrag mehr in den cfg Dateien.

Ich kann die Zeile mit den Fehlern in der Event Ansicht markieren, dann kommt eine übrig gebliebene initialusbcheck Verknüpfung:

set initialUsbCheck addRegexpPart global UNDEFINED.Prologue_145.CUL_TCM97001.CUL_TCM97001_145

Wie kann man diesen Eintrag löschen? Ich finde ihn nicht in der Oberfläche.

Beta-User

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

sirnoname

#8
Da gibt es einen Knopf removeregexpart. Bei Drücken kommt eine andere Seite, der Wert verschwindet aber nicht. Auch nicht nach Save und Restart.
Ich könnte noch das Device initialusbcheck löschen, klingt aber aufs Erste gefährlich.

Die DEF von initialusbcheck sieht so aus:
global:INITIALIZED|global:UNDEFINED.Prologue_145.CUL_TCM97001.CUL_TCM97001_145 set Heizung.Schlafzimmer desiredTemperature 4.5

Wenn ich den 145 Part lösche und modify drücke, dann wird nichts geändert.
Wo wird diese Configuration gespeichert?

Otto123

Wohl doch zuviel manuell editiert. :-X
So sieht das normalerweise( bei mir )aus:
defmod initialUsbCheck notify global:INITIALIZED usb create
attr initialUsbCheck disable 1

Wenn das nicht "weg geht" dann über neu Anfang nachdenken.

Berechtigung an der fhem.cfg verbogen?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Wenn es nach mir ginge, würde das decice gar nicht per default ausgeliefert. Kannst du gefahrlos löschen...
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

sirnoname

Alles beim initialUsbCheck nach | scheint dynamisch erzeugt zu werden und ist nicht in den globals. So findet sich auch in der eventTypes Datei:
log/eventTypes.txt:216:7 initialUsbCheck addRegexpPart global UNDEFINED.Prologue_145.CUL_TCM97001.CUL_TCM97001_145
log/eventTypes.txt:217:1 initialUsbCheck addRegexpPart global UNDEFINED.W044_145.CUL_TCM97001.CUL_TCM97001_145
log/eventTypes.txt:218:4 initialUsbCheck removeRegexpPart global:UNDEFINED.Prologue_145.CUL_TCM97001.CUL_TCM97001_145
log/eventTypes.txt:219:1 initialUsbCheck removeRegexpPart global:UNDEFINED.W044_145.CUL_TCM97001.CUL_TCM97001_145

Alle Sensoren des Typs TCM97001 loggen irgendwie in 145.

Beta-User

Zitat von: Otto123 am 25 Juli 2019, 19:03:24
Wenn das nicht "weg geht" dann über neu Anfang nachdenken.
Kann mich dem nur anschließen.

Das ganze sieht so aus, als hättest du irgendwas irgendwie ziemlich verbogen.

Aber wie bereits geschrieben: Um "toteditierte" Systeme mag sich keiner kümmern. Also besser "leer" starten (genauer: leer ohne das "initialUsbCheck", das sowieso häufig mehr hindert als es hilft), und dann (via RAW-Editor) die Geräte nach und nach einfügen (da gehen auch mehrere/alle auf einen Rutsch). Dann hast du ggf. gleich eine Rückmeldung, was alles nicht geht. Dabei immer auch im log nachsehen, was ggf. an Perl-Modulen fehlt...

Am besten dabei gleich drauf achten, dass erst die IO-Definitionen kommen.

Viel Spaß!
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

sirnoname

Das Löschen und eine Neuinstallation haben keine Änderung gebracht. Die Sensoren kommen weiterhin auf ein Gerät und die Fehlermeldungen in den Logs bleiben.

Otto123

Moin,

Zitat von: Otto123 am 25 Juli 2019, 19:03:24
... dann über neu Anfang nachdenken.
Damit war nicht zwingend "Löschen und Neuinstallation" gemeint. Zumindest assoziiert sich bei den Begriffen bei mir kein sinnvolles Vorgehen.

1. Schauen ob mit den Berechtigungen und Besitzverhältnissen im FHEM Pfad alles stimmt, insbesondere mit fhem.cfg. Geht in der FHEM Kommandozeile
{qx(ls -lha)}
2. fhem.cfg sicherstellen (unter anderem Namen weg kopieren) und eine leere fhem.cfg holen. Kann man wieder in der FHEM Kommandozeile machen, da stimmen die Berechtigungen
"wget -qO fhem.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg"
state File löschen, geht auch in der FHEM Kommandozeile
"rm log/fhem.save"
Dann ein shutdown restart und danach:
3. ... kannst Du Schritt für Schritt die Geräte in der Raw Definition neu anlegen, dabei würde ich mit den "Problemen" zeitnah beginnen und schauen wie sich ein relativ leeres System verhält.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz