Hallo,
ich habe ständig diese Warnungen im Log,
kann ich die ignorieren?
2022.10.18 22:14:31 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_MQTT2_SERVER.pm line 140.
2022.10.18 22:14:31 1: stacktrace:
2022.10.18 22:14:31 1: main::__ANON__ called by ./FHEM/00_MQTT2_SERVER.pm (140)
2022.10.18 22:14:31 1: main::MQTT2_SERVER_Undef called by fhem.pl (3961)
2022.10.18 22:14:31 1: main::CallFn called by fhem.pl (2339)
2022.10.18 22:14:31 1: main::CommandDelete called by ./FHEM/00_MQTT2_SERVER.pm (111)
2022.10.18 22:14:31 1: main::MQTT2_SERVER_keepaliveChecker called by fhem.pl (3486)
2022.10.18 22:14:31 1: main::HandleTimeout called by fhem.pl (703)
...
2022.10.18 22:15:05 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_MQTT2_SERVER.pm line 140.
2022.10.18 22:15:05 1: stacktrace:
2022.10.18 22:15:05 1: main::__ANON__ called by ./FHEM/00_MQTT2_SERVER.pm (140)
2022.10.18 22:15:05 1: main::MQTT2_SERVER_Undef called by fhem.pl (3961)
2022.10.18 22:15:05 1: main::CallFn called by fhem.pl (2339)
2022.10.18 22:15:05 1: main::CommandDelete called by ./FHEM/00_MQTT2_SERVER.pm (329)
2022.10.18 22:15:05 1: main::MQTT2_SERVER_Read called by fhem.pl (3961)
2022.10.18 22:15:05 1: main::CallFn called by fhem.pl (782)
matze1999
Moin. Die sind jedenfalls nicht normal...
Habe jetzt eine zeitlang auf den Code von MQTT2_SERVER gestarrt und noch keine wirkliche Idee, wie das passieren kann. Hast du vielleicht mehrere Clients, die dieselbe ClientID haben? (Also z.B. mehrere ESPs, die sich als "watermeter" melden könnten?).
Zitatkann ich die ignorieren?
Koennen schon, ob es auf lange Sicht die beste Loesung ist, ist fallabhaengig :)
MQTT2_SERVER ist hier nur ueberbringer der schlechten Nachricht, nicht unbedingt der Verursacher.
In diesem Fall wurde irgendwo ein FHEM-Geraet ($defs{...}) angelegt ohne den erforderlichen TYPE Eintrag, vermutlich indem jemand per $defs{NAME}{...} auf ein bereits entferntes Geraet zugegriffen hat (reicht auch lesend!), und damit $defs{...} wieder angelegt hat.
Man kriegt den Namen des Uebeltaeters mit folgendem Einzeiler raus:
{ join(" ", grep { !$defs{$_}{TYPE} } keys %defs) }
Und hoffentlich kann man daraus schliessen, welches Modul oder eigene Routine das Problem verursacht hat.
hallo,
hab die Zeile im webui eingegeben, aber ohne Ergebnis.
oder wo muss ich den einzeiler eingeben?
matze1999
Das war schon richtig, wenn du es in FHEMWEB eingegeben hattest. Dann war halt zu dieser Zeit das Problem nicht existent.
Hast du denn grade auch wieder solche Meldungen im Log?
Wegen des parallelen Threads in https://forum.fhem.de/index.php/topic,129774.0.html:
Bist du auf der aktuellen FHEM-Version? Die Zeile kommt mir komisch vor.
Es könnte einen Zusammenhang geben (bitte bei solchen gleichzeitigen Anfragen immer darauf hinweisen, dass es noch was ähnliches gibt!).
In der aktuellen Zeile steht übrigens was von "my $m = $modules{$defs{$d}{TYPE}};", so dass wir auch inhaltlich eventuell nach derselben Sache suchen...
Hallo,
das vermute ich jetzt auch, ich werde die anderen Beiträge mal mit in diesem überführen. Mittlerweile habe ich einige DOIF gefunden, die error hatten. Das habe ich jetzt behoben. Ich werde jetzt mal den heutigen Tag das ganze im Log verfolgen und mich morgen melden (weil es wohl mit Timern in der Nacht zusammenhängt.
Einmal wöchentlich mache ich ein fhem update bzw. einen check. Noch eine Verständnisfrage: ein MQTT Device ohne "TYPE" sollte in Raum unsorted stehen und nicht mehr im MQTT Raum?
matze1999
Zitat von: matze1999 am 20 Oktober 2022, 12:31:39
Noch eine Verständnisfrage: ein MQTT Device ohne "TYPE" sollte in Raum unsorted stehen und nicht mehr im MQTT Raum?
Seit wann ist das Internal TYPE für den Raum relevant? Das richtet sich weiter nach "allgemeinen Grundsätzen", also nach dem room-Attribut, wonach auch sonst? (Mal abgesehen davon, dass es an sich keine Devices ohne TYPE geben dürfte/sollte, und es daher möglicherweise auch nicht so einfach ist, das room-Attribut zu füllen).
Ein Geraet ohne TYPE verursacht Aerger ueberall, weil FHEM nicht weiss, welches Modul dafuer zustaendig ist.
In FHEMWEB ist es nicht zu sehen, nur im Log gibts eine Zeile wie:
Zitat2022.10.20 13:21:53 1: Error: >x< has no TYPE, but following keys: ><
Das ist entstanden nach der Anweisung: { $defs{x}{y} ? "A" : "B" }
OT:
ZitatSeit wann ist das Internal TYPE für den Raum relevant?
Bei meiner fhem Installation offensichtlich schon, da werden u.a. MQTT und HUEDevice Devices automatisch in die (automatisch erstellten) Räume MQTT2 und HUEDevice einsortiert, wenn sie gefunden werden.
...und das habe ich nicht eingestellt.
matze1999
Zitat von: matze1999 am 20 Oktober 2022, 13:37:17
Bei meiner fhem Installation offensichtlich schon, da werden u.a. MQTT und HUEDevice Devices automatisch in die (automatisch erstellten) Räume MQTT2 und HUEDevice einsortiert, wenn sie gefunden werden.
...und das habe ich nicht eingestellt.
Das muss man nicht einstellen, sondern dieses Verhalten ist in den Modulen vercodet. Es wird dabei aber was gesetzt? Genau: das Attribut...
ich glaube ich habs gefunden:
Error: >OWeterDisplayEin< has no TYPE, but following keys: >READINGS<
aber, das ist, besser war, ein DOIF (Versuch), was ich schon längst gelöscht habe, wo kommt das jetzt noch her? In fhem.save ist es nicht drin. Wo könnte ich noch suchen?
Ich habs jetzt als Text in einem anderen DOIF gefunden, das ich mittels copy angelegt habe, als Reading NTFY_ORDER, kann es daher sein?
Ich hab dieses DOIF jetzt mal gelöscht und ganz neu angelegt.
matze1999
Hallo,
das wars, die Warnung taucht jetzt nicht mehr auf. Danke für die Unterstützung!
matze1999