Notify reagiert nicht auf Log-Eintrag

[Ralli]

Hallo zusammen,

ich habe immer mal wieder folgenden Log-Eintrag, den ich mit einem Notify zu erschlagen versuche:

Code: [Auswählen]

2023.01.20 04:34:55.055 2: UnifiProtect: json error: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Unauthorized") at ./FHEM/74_UnifiProtect.pm line 833

Wenn dieser Fehler auftritt bzw. aufgetreten ist, hilft nur ein Reconnect vom UnifiProtect-Device, daher habe ich folgendes Notify definiert:

Code: [Auswählen]

defmod n_RestartUnifiProtect notify n_RestartUnifiProtect:UnifiProtect..?json.error..?malformed.JSON.string.* set UnifiProtect reconnect
attr n_RestartUnifiProtect readLog 1

Wahrscheinlich passt meine (sehr einfache) RegeEx-Definition nicht, denn das Notify wird nicht getriggert bzw. löst nicht aus.

Kann mir jemand meinen Fehler aufzeigen?

[OdfFhem]

Ein notify wird folgendermaßen definiert:

define <name> notify <Suchmuster> <command>

Zum Suchmuster gilt lt. Wiki:

Das Suchmuster (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) Gerätename:Event. Die Events kann man dem Event-Monitor entnehmen.

Der Fehlereintrag im FHEM-Log löst selbst keinerlei Event aus ... Gibt es tatsächlich ein Reading, dass diesen Fehlertext bereitstellt ?

[Ralli]

Danke, mir ist die Syntax bekannt.

In der Commandref steht Folgendes:

Attribut readLog
Das notify wird für Meldungen, die im FHEM-Log erscheinen, ausgegeführt. Das "Event-Generierende-Gerät" wird auf dem notify selbst gesetzt. Z.Bsp. kann man mit folgendem notify auf die Startup Meldung reagieren:
define n notify n:.*Server.started.* { Log 1, "Wirklich" }
attr n readLog

Sollte also nach meinem Verständnis auf genau diesen Anwendungsfall passen.

Nein, es gibt kein Reading, nur einen Log-Eintrag.

[binford6000]

Moin Ralli,
probier mal:

Code: [Auswählen]

defmod n_RestartUnifiProtect notify n_RestartUnifiProtect:.*UnifiProtect..?json.error..?malformed.JSON.string.* set UnifiProtect reconnect
VG Sebastian

[Ralli]

Danke, ich hab's mal übernommen. Nun heißt es warten, bis der Fehler wieder zuschlägt.

[OdfFhem]

Danke, mir ist die Syntax bekannt.

Tut mir leid für die "Belehrung"; da hat scheinbar mein Mobilgerät das entscheidende Attribut "verheimlicht" ...

[Ralli]

Alles gut  Auch ich darf und möchte mich gerne belehren lassen, suche ja nach Rat.

Um es mit dem Sprichwort meiner verstorbenen Großmutter zu sagen: "Dau kanns aaal werden wie ne Kuh, dau lernst immer noch dazu"!

[rudolfkoenig]

Nach Studium der Programmzeilen in fhem.pl faellt mir auf, dass notify mit readLog die Daten leicht anders formatiert bekommt, als das, was ins Logfile geschrieben wird.
Geschrieben wird "$tim $loglevel: $text\n", benachrichtigt wird mit "$tim $loglevel : $text", d.h. bei notify ist ein zusaetzliches Leerzeichen vor dem Doppelpunkt, und Newline fehlt.

Warum das zusaetzliche Leerzeichen da ist, konnte ich selbst nach Studium der Geschichte (svn blame fhem.pl / svn log fhem.pl / Forumsbeitraege studieren) nicht nachvollziehen.
Ein Fix wuerde das Log2Syslog Modul unbrauchbar machen, und womoeglich einige Benutzer dieses Features veraergern.

An dem Log2Syslog Maintainer (falls Du mitliest): ich wuerde gerne die Unterschiede beheben, es sei denn, jemand begruendet, warum das nicht sinnvoll ist.

[DS_Starter]

Hallo Rudi,

An dem Log2Syslog Maintainer (falls Du mitliest): ich wuerde gerne die Unterschiede beheben, es sei denn, jemand begruendet, warum das nicht sinnvoll ist.

Bin gerade auf den Thread aufmerksam geworden ... gerne können wir das anpassen, ich habe nichts einzuwenden.
Wenn du zu gegebener Zeit die Änderungen postest, kann ich es in  Log2Syslog  nachziehen und im Idealfall zusammen im Update ausliefern lassen.

[rudolfkoenig]

gerne können wir das anpassen, ich habe nichts einzuwenden.

Angebot angenommen, habe die geaenderte Version von fhem.pl eingecheckt.

[DS_Starter]

Log2Syslog habe ich auch angepasst, getestet und eingecheckt.

Bei der Gelegenheit habe ich bemerkt, dass Log-Einträge die ich im neuen DbLog aus dem SubProzess heraus ausgebe, nicht an Log2Syslog weitergegeben werden.
Ich habe eine Weile gebraucht um zu verstehen wieso es so ist.
Der Grund liegt m.M. nach darin begründet, dass sich das Log2Syslog-Device erst relativ spät definiert und somit sich erst nach dem fork in den Hash %logInform einträgt. Somit ist im "geforkten" %logInform das Log2Syslog-Device nicht vorhanden.

Für dieses Problem habe ich noch keine Lösung und muss noch darüber nachdenken.
Das hat auch jetzt nicht direkt etwas mit dem Thread-Thema zu tun, wollte die Sache aber mitteilen weil evtl. auch andere Module die Logausgaben im SubProzess verwenden evtl. auf ähnliche Verhalten stoßen je nachdem wann der fork erfolgt. 

[rudolfkoenig]

Bei der Gelegenheit habe ich bemerkt, dass Log-Einträge die ich im neuen DbLog aus dem SubProzess heraus ausgebe, nicht an Log2Syslog weitergegeben werden.

Wir sollten dieses Problem separat diskutieren, ich fuerchte die Loesung ist nicht trivial, und ich will dieses Thema nicht entfuehren.

[DS_Starter]

Ja, gerne.