Notify reagiert nicht auf Log-Eintrag

Begonnen von Ralli, 23 Januar 2023, 07:55:50

Vorheriges Thema - Nächstes Thema

Ralli

Hallo zusammen,

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


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:


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?
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

OdfFhem

Ein notify wird folgendermaßen definiert:
Zitatdefine <name> notify <Suchmuster> <command>

Zum Suchmuster gilt lt. Wiki:
ZitatDas 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:

Zitat
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.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

binford6000

Moin Ralli,
probier mal:
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.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

OdfFhem

Zitat von: Ralli am 23 Januar 2023, 08:58:23
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"!
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

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,

Zitat
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.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

Zitatgerne 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. 
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

ZitatBei 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

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter