[Gelöst] FileLog seit heute mit Fehler in der Regex?

[Pfriemler]

Moin,
wie schon in Anfängerfragen http://forum.fhem.de/index.php/topic,36701.0.html beweint, gibt es ein Problem mit FileLogs zumindest seit dem heutigen Update.

Da Rudolf keine PMs von mir empfangen möchte, eben hier:
In der Regexbeschreibung wird (vermutlich bei mehr als zwei Items) offenbar nur noch das erste berücksichtigt.
Details unter dem Link oben.
Workaround: das ganze Regex einklammern, dann geht's. Wird aber vom Web-GUI so nicht unterstützt.

GRÜSSE
vom
Priemler

P.S.: Das Update lief soweit fehlerfrei (die Sachen mit 11_OWX habe ich derweil gefixt):

Code Auswählen Erweitern

2015.04.27 12:52:14 1: RMDIR: ./restoreDir/2015-04-20
2015.04.27 12:52:14 1: UPD ./CHANGED
2015.04.27 12:52:15 1: UPD ./fhem.pl
2015.04.27 12:52:15 1: UPD FHEM/42_SYSMON.pm
2015.04.27 12:52:16 1: UPD FHEM/WMBus.pm
2015.04.27 12:52:16 1:
2015.04.27 12:52:16 1: New entries in the CHANGED file:
2015.04.27 12:52:16 1:   - fixed:  SYSMON: some warnings
2015.04.27 12:52:16 1:   - added:  SYSMON: new readings <network>_speed, cpuX_freq_stat, cpuX_idle_stat, cpu_temp_stat
2015.04.27 12:52:16 1:   - improved:  SYSMON: documentation
2015.04.27 12:52:17 1:   - change:  WMBus: support for Easymeter
2015.04.27 12:52:17 1: Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015.04.27 12:52:40 1: *** EN FHEM/11_OWX_DS2480.pm: No document text found *** EN FHEM/11_OWX_Executor.pm: No document text found *** EN FHEM/11_OWX_FRM.pm: No document text found *** EN FHEM/11_OWX_SER.pm: No document text found *** EN FHEM/95_WebViewControl.pm: No document text found
2015.04.27 12:52:40 1:
2015.04.27 12:52:40 1: update finished, "shutdown restart" is needed to activate the changes.
2015.04.27 12:52:40 1:
2015.04.27 12:52:43 1: fheminfo server response: ==> ok
2015.04.27 13:27:42 0: Server shutdown

[Pfriemler]

Das Problem betrifft seltsamerweise doch nicht die Anzahl der Teile im Regex. Heute morgen bin ich mal meine FileLogs anhand der fehlerhaften Plots durchgegangen:

Bei diesen Regex kommen nur die ersten ins FileLog:

Code Auswählen Erweitern

DGZimmerfenster1:Window:.*|EGHaustuer:contact:.*|EGWzTerassentuer:contact:.*|GaragentorSensor:contact:.*)
StateGretke:.*|StateRobert:.*|StateVolkBT:.*|StateVolkWL:.*|StateVolker:.*


Dieser hingegen funktionierte auch heute noch einwandfrei:

Code Auswählen Erweitern

FHT_4711:measured-temp:.*|HKThermostat1_Weather:measured-temp:.*|HKThermostat2_Weather:measured-temp:.*|KS300:T:.*|TDiffSens1_T1:T:.*|TDiffSens1_T2:T:.*

Muss ich das jetzt verstehen?

[rudolfkoenig]

Die Ursache war dieser Patch, den ich gerade zurueckgedreht habe.

[Pfriemler]

Den verlinkten Beitrag las ich wohl, aber mir fehlt (noch) komplett das Verständnis. Zum fließend Perl fehlt noch ein bisschen. Ich kann nach wie vor keinen möglicherweise relevanten Unterschied in den zitierten Regex erkennen.
Ich habe alle Workarounds wieder entfernt und beobachte.

Danke!

[stromer-12]

Ich habe bei mir auch gesehen, das dieses NOTIFYDEV bei mir auch nicht erscheint, wenn mein Regex mit einen "^" anfängt.

[rudolfkoenig]

Das ist aber nicht neu. Und bedeutet nur, dass das betreffende FileLog/notify fuer alle Events aufgerufen wird, genauso wie frueher. Damit ist das zwar etwas ineffizienter, aber nicht falsch.

[Pfriemler]

Womit wir weg vom Fehler im FileLog (was wieder tadellos funzt) zur Frage des korrekten NOTIFYDEV kämen. Aber das hier weiterdiskutieren? Handlungsbedarf sähe ich, nach einer testweisen Auflistung meiner Geräte/Notifys/Doifs etc. langfristig schon. 

geht nich Gips nich ...

[Markus Bloch]

Da die Änderung ja auf meinen Mist gewachsen ist, hier mal eine Erklärung dazu. Der Wert NOTIFYDEV in den Internals dient dazu bei Events die Verarbeitung zu verkürzen indem ein Event nicht gegen sämtliche Regex-Ausdrücke aller notfiy,FileLog,...  geprüft werden, sondern durch das NOTIFYDEV bereits gesagt wird, dass die entsprechende Definition nur Events von dem in NOTIFYDEV hinterlegten Device entgegennimmt. Ein String-Vergleich auf den Devicenamen ist dabei schneller als das gesamte Event gegen die Regexp zu testen ob sie matcht.

Nun habe ich bei mir beispielhaft öfters eine Regexp nach folgendem Schema:

Code Auswählen Erweitern

Device_A:(on|off)

Und hier wäre ein gesetztes NOTIFYDEV durchaus sinnvoll, da es sich eh nur um Device_A dreht. Das ist aber aktuell nicht möglich weil ein NOTIFYDEV nur dann gesetzt wird, wenn in der Regexp keine Pipe (|) vorkommt. Nun ist es in deinem Fall aber so, dass du mehrere unterschiedliche Devices/Readings mit einer Pipe ver-ODER'st (ja ich weis, beschissenes Deutsch) und damit ein NOTIFYDEV ja nicht gebrauchen kannst, weil dir sonst die Hälfte an Events fehlt, wenn NOTIFYDEV nun auf das erste Device in deiner Regexp gesetzt ist und du damit nur die Events dieses Devices erhälst, aber nicht den Rest.

Eine wirkliche Lösung dafür fällt mir auch nicht ein, da man ein solches Konstrukt mangels Klammern nicht wirklich gut erkennen kann und NOTIFYDEV nur einen Device-Namen enthalten darf.

Viele Grüße

Markus

[Pfriemler]

Danke, Markus, den Sinn des NOTIFYDEV hatte ich schon verstanden ...  aber auch für die SUFU des Forums ist es sicher gut, dass es mal anschaulich erklärt wurde.
Angesichts ca 25% globaler zu adressierender NOTIFYS bei mir (weil NOTIFYDEV nicht gesetzt ist oder im Falle von 1-wire-Sensoren via OWX sicher nicht "global" sein müsste), wo es höchstens 5 zu sein bräuchten, finde ich eine Diskussion, wie es besser laufen könnte,  zumindest für sinnvoll, wenngleich die Rechenleistung aktueller Kleincomputer den (derzeitigen, aber eher sinnlosen) Mehraufwand immer besser stemmen sollte.

Ich habe bspw. ein Filelog für Readings eines Devices wie

Code Auswählen Erweitern

MWS:I7.*|MWS:L7.*|MWS:R7.*|MWS:T.*|MWS:W7.*, wo durchaus "MWS" als NOTIFYDEV im FileLog stehen dürfte.

Das ist aber aktuell nicht möglich weil ein NOTIFYDEV nur dann gesetzt wird, wenn in der Regexp keine Pipe (|) vorkommt.

Hier würde etwas interpretatorische Intelligenz helfen, wie eine Analyse des Teils vor einem Doppelpunkt. Generell ist das aber ein heißes Eisen, denn die Gefahr einer Fehlinterpretation ist doch sehr hoch. Ist aber schon mal darüber nachgedacht worden, ersatzweise eine manuelle Definition zu erlauben, etwa über ein Attribut? So könnte jeder, der sein FHEM entlasten möchte, auf eigenes Risiko hin die Notifybearbeitung optimieren. Und dass

NOTIFYDEV nur einen Device-Namen enthalten darf

, könnte man vielleicht auch mal überdenken ...

Jm2c.