FHEM Forum

Hi, kann ich im regulären Ausdruck von FileLog auch "\b" verwenden, um das Wortende des Readings zu definieren?
Sprich, ich habe 3 Readings
EM_Total_in
EM_Total_in_last
EM_Total_in_today
möchte aber nur das erste loggen.
Via
EM_Total_in\b|...
klappt es jedoch nicht anscheinend. Ich bekomme hier ein REGEXP (!) "Could not optimize the regexp".

Kann ich das so nicht umsetzen?

Danke für eure Hilfe!

ZitatIch bekomme hier ein REGEXP (!) "Could not optimize the regexp".

Das bedeutet nur, dass der relativ einfach gestrickte Optimierer den Regexp nicht verdauen konnte, und deswegen diese FileLog-Instanz bei jedem Event aufgerufen wird. Das wird zu einem Problem, wenn mehrere hundert nicht optimierte Instanzen viele Events in der Sekunde abarbeiten muessen.

Zitat von: rudolfkoenig am 30 August 2022, 10:35:48
Das bedeutet nur, dass der relativ einfach gestrickte Optimierer den Regexp nicht verdauen konnte, und deswegen diese FileLog-Instanz bei jedem Event aufgerufen wird. Das wird zu einem Problem, wenn mehrere hundert nicht optimierte Instanzen viele Events in der Sekunde abarbeiten muessen.

Alles klar, ich sehe, dass ich an anderer Stelle die gleiche Meldung habe, wo es ansonsten funktioniert. Ist mir bisher nie aufgefallen.

Ich habe inzwischen die Vermutung, dass ich mich in eine ungünstige userReadings  / setreading Trigger Konstellation manövriert habe. Denn auch ohne den "\b" Ausdruck funktioniert es nicht.
Die nicht geloggten Readings sind userReadings. Dessen Trigger wird jedoch von außen gesetzt durch ein setreading EM_Total_calc xyz eines notify.

EM_Total_in_last:EM_Total_calc.* {},
EM_Total_in_today:EM_Total_calc.* {}

Es hilft auch nicht, die userReadings einzeln kommagetrennt oder als EM_.* in event-on-change-reading und event-on-update-reading zu hinterlegen.
Im Eventlog tauchen die userReadings wie erwartet auf.

Kann ich irgendwie anders das FileLog überreden, meine userReadings zu berücksichtigen?
Ich möchte ungern im Notify auch die userReadings setzen.
Die unperformante Lösung wäre sicherlich, die userReadings grundsätzlich nur durch "echte" Device Readings triggern zu lassen?

Oder liegt der Hund hier doch noch ganz woanders begraben? ;)

// Nachtrag
Ich triggere nun auf ein "echtes" Device Reading.
attr ... event-on-change-reading EM_.* ist gesetzt
event-on-update-reading muss anscheinend auch gesetzt sein. Auch, wenn sich die Werte ändern. Dann wird das userReading geloggt.
Aber wieso dieses unnatürliche Verhalten?

Wenn die Events im Event-Log auftauchen, dann wird ein "REGEXP(!) FileLog" diese auch bekommen, und dann muss "nur" das Regexp passen.

Falls man beim Regexp unsicher ist, dann am besten im Event-Log das fragliche Event markieren, und ueber "Create/Modify device" das FileLog anlegen.
FileLog-Regexp erweitern kann man per Dropdown in der FileLog-Detailfenster mit "set addRegexpPart", dazu muss nur die eventTypes Instanz existieren, das ist aber die Voreinstellung.

Ich persoenlich setze gar keine event-on-* Attribute, und empfehle diese erst zu setzen, wenn man ein konkretes Problem hat.

Zitat von: rudolfkoenig am 30 August 2022, 14:30:08
Wenn die Events im Event-Log auftauchen, dann wird ein "REGEXP(!) FileLog" diese auch bekommen, und dann muss "nur" das Regexp passen.

Wenn das so ist, habe ich wirklich einen Regex-Fehler. Ich habe es mal reduziert auf ein Reading und auch gegengecheckt via "Create/Modify device", aber es kommt nicht im Log an:

Eventlog
2022-08-30 21:37:01.192 MQTT2_DEVICE Powermeter EM_Power_consumption_curr_ex: 0.6
FileLog
defmod FileLog_Powermeter.1 FileLog ./log/Powermeter.1-%Y%m.log Powermeter:EM_Power_consumption_curr_ex.*
oder auch
defmod FileLog_Powermeter.1 FileLog ./log/Powermeter.1-%Y%m.log Powermeter.EM_Power_consumption_curr_ex.*

Es ist zum Haare raufen..

//Nachtrag:
Wenn ich FileLog folgendermaßen definiere, kommen Readings rein
defmod FileLog_Powermeter.1 FileLog ./log/Powermeter.1-%Y%m.log Powermeter:.*

Allerdings erhalte ich dann alle auch unerwünschten Readings, und das im 10 Sekunden Takt. Ich möchte daher
defmod FileLog_Powermeter.1 FileLog ./log/Powermeter.1-%Y%m.log Powermeter:(EM_Power_consumption_curr_ex|EM_Total_in_last|EM_Total_in_today).*

Ich habe das Gefühl, ich übersehe etwas...?

Ich habe jetzt ein MQTT2_DEVICE mit dem Namen Powermeter definiert, und ein Event erzeugt mit
fhem> trigger Powermeter EM_Power_consumption_curr_ex: 0.6

Im Event-Monitor erscheint:

Zitat2022-08-31 11:02:16.489 MQTT2_DEVICE Powermeter EM_Power_consumption_curr_ex: 0.6

Ich habe die Zeile markiert, und per "Create/Modify Device" ein FileLog angelegt. list -r zeigt:
define Powermeter_FileLog_1 FileLog ./log/Powermeter_FileLog_1.log Powermeter:EM_Power_consumption_curr_ex:.*


Ich habe dann das o.g. trigger erneut ausgefuehrt, die Zeile erscheint in der Datei.

=> Das Verfahren an sich funktioniert.

Womoeglich sind im Namen des Readings irgendwelche Zeichen, die nicht dargestellt werden, z.Bsp. Leerzeichen werden vom Browser gerne verschluckt.

Endlich, kurz vor der ultimativen Verzweiflung ;), konnte ich das Problem reproduzieren. Ich habe die Devices nochmal reduziert nachgebaut:

defmod Powermeterle MQTT2_DEVICE ABC12345
attr Powermeterle event-on-change-reading EM_.*
attr Powermeterle userReadings EM_Power_curr_ex:EM_Power_curr\b.* {ReadingsNum("$name","EM_Power_curr",0,1)},EM_Power_consumption_curr_ex:EM_Power_consumption_curr\b.* {ReadingsNum("$name","EM_Power_consumption_curr",0,1)}

defmod FileLog_Powermeterle.1 FileLog ./log/Powermeterle.1-%Y%m.log Powermeterle.(EM\_Power\_curr\_ex|EM\_Power\_consumption\_curr\_ex).*
attr FileLog_Powermeterle.1 logtype text

defmod notify.Powermeterle notify Powermeterle.EM_Power_curr:.* {\
fhem("setreading Powermeterle EM_Power_consumption_curr " . int(rand(300)+1));\
}\


Ein setreading Powermeterle EM_Power_curr 0.13579 in der CMD funktioniert. Gleiches setreading innerhalb des Notify führt zur Änderung des Wertes, einem Event im Eventlog, aber NICHT im FileLog.

Der Knackpunkt ist das setreading aus dem notify heraus.

Bestimmt sagst Du mir ad hoc, warum das so ist und dass das seine Richtigkeit hat. Ich bin gespannt.

Zitat von: FHEMAN am 31 August 2022, 22:00:21
Der Knackpunkt ist das setreading aus dem notify heraus.

Der Knackpunkt dürfte sein, dass Du das setreading für das gleiche device ausführst, das auch das notify triggert.

Probier mal, ein "sleep 0.1;" vor das setreading zu setzen.

ZitatBestimmt sagst Du mir ad hoc, warum das so ist [...]

Um eine versehentliche endlose Rekursion zu vermeiden.
D.h. wenn man ein Event fuer Geraet X aus einem DOIF/Notify/etc fuer das gleiche Geraet X ausloest (z.Bsp. per trigger oder setreading), dann findet keine erneute Benachrichtigung (vulgo notify) statt.

Dieses Problem kann man entweder mit einem userReading loesen, oder indem man die Benachrichtigung entkoppelt, z.Bsp. per sleep (wie von betateilchen vorgeschlagen).

Ok, daher weht der Wind, ein alter Bekannter! Gab es dann nicht aber im Logfile einen Hinweistext a la endlos-Loop?
Und sollte dann nicht das Event auch im Eventlog ausbleiben?

Mit dem vorangestellten sleep funktioniert es jetzt.

Von diesem Verhalten werde ich kein Fan.

Danke, rudolfkoenig und betateilchen für die Aufklärung!