[gelöst]kein Bug bei attr addLog in 92_FileLog, sondern nur meine Unwissenheit

Begonnen von KölnSolar, 25 Januar 2024, 17:59:49

Vorheriges Thema - Nächstes Thema

KölnSolar

Hi Rudi,

ich habe zur Verbesserung meiner Plots heute ein addLog eingefügt
attr MHIlog addLog MHI:power:300,MHI:OpData_IU-FANSPEED:900,MHI:OpData_OU-FANSPEED:900,MHI:OpData_COMP:900Nun bekomme ich aber auch Logzeilen, die aber gar nicht passen, nämlich von z.B. reading ErrOpData_IU-FANSPEED, also ob auf *.readingname selektiert würde.
2024-01-25_17:26:19 MHI OpData_IU-FANSPEED: 1
2024-01-25_17:26:19 MHI ErrOpData_COMP: 0.00
2024-01-25_17:26:19 MHI ErrOpData_OU-FANSPEED: 0
2024-01-25_17:26:19 MHI OpData_COMP: 0.00
2024-01-25_17:26:19 MHI OpData_OU-FANSPEED: 0
2024-01-25_17:26:19 MHI power: 0
2024-01-25_17:26:19 MHI ErrOpData_IU-FANSPEED: 1
2024-01-25_17:31:19 MHI power: 0
2024-01-25_17:36:19 MHI power: 0
2024-01-25_17:41:19 MHI OpData_IU-FANSPEED: 1
2024-01-25_17:41:19 MHI ErrOpData_COMP: 0.00
2024-01-25_17:41:19 MHI ErrOpData_OU-FANSPEED: 0
2024-01-25_17:41:19 MHI OpData_COMP: 0.00
2024-01-25_17:41:19 MHI OpData_OU-FANSPEED: 0
2024-01-25_17:41:19 MHI power: 0
2024-01-25_17:41:19 MHI ErrOpData_IU-FANSPEED: 1
2024-01-25_17:46:19 MHI power: 0
2024-01-25_17:51:19 MHI power: 0
Zu den falschen Logzeilen gab es die letzten events am 3.1.24.

Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

betateilchen

Naja, ich sag mal so... in der commandref zum Attribut steht ausdrücklich

ZitatYou may use regular expressions for reading.

Wenn also die regex

OpData_IU-FANSPEED

lautet und dann kommt ein Wert

ErrOpData_IU-FANSPEED

dann ist das, was Du jetzt als Fehler betrachtest, für mich ein völlig logisches Verhalten, weil die regex darauf passt.

Du könntest probieren, ob die Angabe der regex in der Form

^OpData_IU-FANSPEED$

das Verhalten zu Deinen Gunsten verändert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

KölnSolar

Da bin ich etwas sprachlos.  :o
In Perl stimme ich Dir sofort zu. Aber in FHEM dachte ich, dass ^ quasi implizit ist.
Warum hab ich dann an so vielen Stellen .* am Ende, wenn bereits das Wort matched ? :o
Dein Lösungsvorschlag funktioniert.  8)

Danke&Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

betateilchen

Zitat von: KölnSolar am 25 Januar 2024, 20:16:04Aber in FHEM dachte ich, dass ^ quasi implizit ist.

In FHEM ist halt nix einheitlich, jeder Entwickler macht, wie er es gut findet.
Wenn es aber zumindest - wie hier - in der commandref drinsteht, kann man die Lösung noch relativ schnell finden, wenn man den Stolperstein nicht ohnehin im Hinterkopf abgespeichert hat.

Zitat von: KölnSolar am 25 Januar 2024, 20:16:04Warum hab ich dann an so vielen Stellen .* am Ende, wenn bereits das Wort matched

Weil es an vielen Stellen ohne das .* am Ende nicht funktionieren würde.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Man könnte vielleicht an der Stelle die commandref klarer formulieren.

Anstatt

ZitatYou may use regular expressions for reading

zum Beispiel klarstellen, dass der Wert als regular expression behandelt wird.

ZitatThe value for reading is treated as a regular expression.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Habe die Doku angepasst.
Und vielen Dank fuer die Support-Hilfe :)