[98_monitoring] - Support Thread ab 2022

[Beta-User]

ich hab's zur Sicherheit reproduziert.

Bedeutet: svn-Version ist ok, die hier angehängte verursacht die 100%?

Dann habe ich im Moment keine Idee, vielleicht kannst du im Log schauen, was da an Einträgen ist, die damit zu tun haben könnten.
Ansonsten wären deine monitoring-Instanzen interessant (v.a. welche mit formatierter Rückgabe für die get-Anfragen).

[Gisbert]

Hallo Jörg,

nach dem

2022.04.15 08:38:38.620 0: Server shutdown
2022.04.15 08:38:38.674 1: Shutdown executed

startet FHEM sich anscheined in einer Endlosschleife immer wieder neu, ohne zu einem Ende zu kommen. Jedenfalls tauchen die typischen Einträge nach einem Neustart wiederholend immer wieder im logfile auf.

Das "reproduzierend" bedeutet, dass ich gestern die neue Version runtergeladen hatte (Besitzerrechte etc. angepasst) und Fhem neu gestartet hatte, das gleiche dann heute morgen ebenfalls. In beiden Fällen ist die Prozessorlast mit Fhem bei 100%. Es half dann nur aus dem SVN die letzte funktionierende Datei runterzuladen, den fhem.service zu stoppen und wieder zu starten.

Viele Grüße Gisbert

[Beta-User]

nach dem startet FHEM sich anscheined in einer Endlosschleife immer wieder neu, ohne zu einem Ende zu kommen. Jedenfalls tauchen die typischen Einträge nach einem Neustart wiederholend immer wieder im logfile auf.

OK, sowas war (leider) zu vermuten, wenn FHEMWEB nicht erreichbar ist bei CPU-load 100%.

Vermutlich klappt mit irgendeiner eval-Ersatz-Anweisung was nicht, ich würde auf eine "undefined subroutine" tippen. Normalerweise sollte bei so einem Fehler auch ein Eintrag im Log stehen, und zwar vor dem ersten "neuen" Eintrag vom FHEM-Start (das "Server started" ist eigentlich eher "kurz vor Schluss"). Falls bei dir "WEB" auch sehr weit vorne in der Konfiguration zu finden ist, könntest du rückwärts nach "WEB: port 8083 opened" suchen und da irgendwo in der Nähe sollte dann was zu finden sein.

Wie gesagt: Im Moment gehe ich davon aus, dass nicht das Modul an sich das Problem ist, sondern das Modul iVm. dem, was in einem der "error/warn"-etc.-Funktionen zu finden ist, von daher würde mir schon helfen, das in diese Richtung eingrenzen zu können anhand deiner Einstellungen.

[Gisbert]

Hallo Jörg,

ich musste an den PC, da das Kopieren im logfile auf dem Handy nicht gut funktioniert.
Ich hab folgendes gefunden (betrifft dein Modul aus dem 1. Beitrag):

Code Auswählen Erweitern

2022.04.15 08:39:10.455 3: monitoring (mymonitoring) set mymonitoring active
Undefined subroutine &FHEM::Automation::monitoring::time_str2num called at .//FHEM/98_monitoring.pm line 597.
2022.04.15 08:39:12.121 1: Including fhem.cfg
2022.04.15 08:39:12.484 3: WEB: port 8083 opened
Das (und vieles mehr) wiederholt sich so lange, bis man Fhem stoppt.
Kannst du damit was anfangen?

Viele Grüße Gisbert

[Beta-User]

Kannst du damit was anfangen?

Ja. Vielen Dank!

Die Funktion hat gefehlt beim Import. Leider kann ich auf die Schnelle nicht sagen, ob das schon alles war, oder ob da noch mehr fehlt (das sieht man leider erst, wenn es schiefgeht, oder wenn man alle Funktionsaufrufe vorab checkt, was aber aufwändig sein kann)...

Falls du Muße hast, kannst du ja die jetzt angehängte Fassung testen, die hat zumindest dieses Problem dann nicht mehr. Da von meiner Seite gründlicher drüber zu sehen, wird vermutlich erst übernächste Woche gehen.

[Gisbert]

Falls du Muße hast, kannst du ja die jetzt angehängte Fassung testen, die hat zumindest dieses Problem dann nicht mehr. Da von meiner Seite gründlicher drüber zu sehen, wird vermutlich erst übernächste Woche gehen.

Ich hab die neue Datei runtergeladen; Fhem startet zumindest normal.
Ich werde beobachten, was mein monitoring-Device die nächsten Tage macht.

Viele​ Grüße​ Gisbert​

[Beta-User]

Ich hab die neue Datei runtergeladen; Fhem startet zumindest normal.
Ich werde beobachten, was mein monitoring-Device die nächsten Tage macht.

Gann lieben Dank für den weiteren Test - das ist doch schon mal was .

Dann scheint das tatsächlich die einzige beim Einpacken übersehene Funktion gewesen zu sein. Kann schon sein, dass die Evaluierung von eigenen Funktionen dann noch nicht funktioniert, weil eben nicht alle FHEM-internen Funktionen jetzt im selben "lexikalischen Kontext" verfügbar sind, aber dann sollte eine Fehlermeldung zurückkommen oder "einfach nur was im Log" stehen (ohne FHEM-crash).

Frohe Ostern!

[Beta-User]

WARNUNG!

Nachdem es bisher keine weiteren negativen Rückmeldungen gegeben hat, gehe ich davon aus, dass die Testversion aus dem Anhang des ersten Posts auch bei anderen fehlerfrei läuft und werde das dann vermutlich irgendwann am kommenden WE irgendwann einchecken.

Da die Testerbasis bisher gering war, die Eingriffe aber nicht ganz unerheblich, kann ich leider nicht garantieren, dass das stressfrei wird und empfehle daher allen, die auf gar keinen Fall Probleme bekommen wollen, vorsichtshalber das Modul vom update auszunehmen .

Grüße, Beta-User

[eisman]

Hi,

habe die Version auch mal getestet.
und bekomme die Fehlermeldung im Log:

Undefined subroutine &FHEM::Automation::monitoring::Delete called at fhem.pl line 3948.
Undefined subroutine &FHEM::Automation::monitoring::Delete called at fhem.pl line 3948.

usw..

Fhem hängt sich auf und startet neu.

mfg

[Beta-User]

Moin, Danke für die Rückmeldung.

Das Problem sollte zu lösen sein, indem Zeile 74 deaktiviert (# vorne dran) oder gelöscht wird.
Du scheinst in der Konfiguration eine "delete"-Anweisung drin zu haben, sonst dürfte das mit der Dauerschleife nicht auftauchen. Ist etwas ungewohnt...

Update im svn schiebe ich bei Gelegenheit nach.

[Gisbert]

Hallo Jörg,

das Modul funktioniert.

In letzter Zeit hatte (wichtig Vergangenheitsform) ich das Problem, dass bei ReadingsVal, die ich in stateFormat und/oder userReadings definiert wurden, im logfile die Meldung kam "Perl warning ... is not numeric ...". Ich kann den konkreten Text nicht mehr posten, da das logfile nicht mehr existiert; bei Interesse ist es aber reproduzierbar. Inhaltlich hat das Modul immer funktioniert, bis auf die heftig vielen Einträge im logfile.

Als erstes habe ich verbose runtergesetzt, selbst bei verbose 0 kamen viele Einträge.

Dann habe ich mich dem ReadingsVal angenommen; bei mir sehen die in fast allen Devises so aus:

Code Auswählen Erweitern

ReadingsVal($name,'reading','')
Wie gesagt funktioniert das bei sehr vielen anderen Modulen, nicht aber bei dem monitoring-Modul.
Es hat dann etwas gedauert, bis ich auch den Ersatzwert wie folgt definiert hatte:

Code Auswählen Erweitern

ReadingsVal($name,'reading','0')
Danach waren die Einträge aus dem logfile verschwunden.

Anscheinend wird im monitoring-Modul der Ersatzwert anders behandelt als in anderen Modulen.

Viele​ Grüße​ Gisbert​

[Beta-User]

Vorab: der "Delete-Fix" ist per update verfügbar.

Anscheinend wird im monitoring-Modul der Ersatzwert anders behandelt als in anderen Modulen.

Das sicher nicht, wenn, ist eher die Frage, ob der Reading-Wert vorhanden ist. Ganz allgemein sollte man für numerische Vergleiche ReadingsVal() nur verwenden, wenn man sicher ist, dass ein numerischer Wert geliefert wird (und den Ersatzwert auch numerisch wählen), sonst besser ReadingsNum().

Wenn "falsch" verglichen wird, gibt es auch ein Perl-Warning, das hat mit dem Verbose-Level mehr oder weniger nichts zu tun, weil diese Art log-Einträge aus einer anderen "Schicht" kommen.

Ansonsten freut mich, dass das Problem nicht mehr existiert. Es kann durchaus sein, dass das auch mit den Überarbeitungen der jüngeren Vergangenheit zu tun hat, manches erschien mir nicht ganz stringent, und diese Teile habe ich dann auch geändert (was nicht bedeuten muss, dass es unbedingt fehlerfrei ist!). Von daher: Bitte weiter melden, wenn euch was "komisch" vorkommt...

[eisman]

Hi,

habe die Version auch mal getestet.
und bekomme die Fehlermeldung im Log:

Undefined subroutine &FHEM::Automation::monitoring::Delete called at fhem.pl line 3948.
Undefined subroutine &FHEM::Automation::monitoring::Delete called at fhem.pl line 3948.

usw..

Fhem hängt sich auf und startet neu.

mfg

danke

jetzt geht auch das löschen ohne Probleme

mfg

[Beta-User]

danke

jetzt geht auch das löschen ohne Probleme

Gerne!

Danke für's Melden und Testen!!!

[mdescher]

Hallo!

Ich habe versucht das Attribut "blacklist" im monitoring Modul zu nutzen und stolpere darüber, dass die Devspecs zu viel ausfiltern. Das ganze lässt sich leicht reproduzieren.

Gebe ich z.B. "x_test_dummy_x" in der Blacklist an, dann werden auch Events des Device "test_dummy" ausgefiltert. Das ist doch vermutlich ein Bug und nicht so gedacht oder?

Gruß
Michael

Neuer support-Thread für das Modul wäre hier zu finden (siehe MAINTAINER.txt): https://forum.fhem.de/index.php/topic,126515.0.html.

Soweit erkennbar, war das schon immer so, ich würde es aber auch als bug ansehen...

Kannst du zum Testen bitte mal #325 so ändern:

Code Auswählen Erweitern

return if @blacklist && grep { m{\A${name}\z}x } @blacklist;
(in #332 gibt es dann zumindest auf den ersten Blick nochmal was vergleichbares).

Feedback bitte möglichst im neuen Thread.

Sorry für das späte Feedback. Mit der vorgeschlagenen Änderung funktioniert die Blacklist wie erwartet.

Danke + Gruß
Michael