Logging Einschränken ohne Nebenwirkungen

[hopgeq]

Hallo,
ich habe ein DOIF, das eine Kellerlüftung steuert. Funktioniert auch schon einigermaßen.
Jetzt will ich das plotten, um meine Steuerung in Aktion zu sehen.

Dazu muss ich die zugrundeliegenden Devices loggen. Sie erzeugen allerdings recht viele Log-Einträge.
Wenn ich jetzt event-on-change-reading verwende, um die Anzahl der irrelevanten Logeinträge zu reduzieren, funktioniert das DOIF nicht mehr zuverlässig. Weil die Events unterdrückt werden, die das DOIF braucht.

Ich hätte gerne ein Logging, das ich einstellen kann wie ich es für meine Plots brauche, ohne dass das Nebenwirkungen auf meine Steuerung hat. Ich hatte ähnliche Probleme schon an zahlreichen Stellen,vor allem im Zusammenhang mit UserReadings.

Wenn ich es richtig sehe, ist der einzige Weg, eine Kopie des Devices zu erzeugen, diese Kopie dann mit event-on-change-reading zu bestücken und dann zu loggen -- oder gibt es auch einen eleganteren Weg? Kann ich dafür cloneDummy (mit gesetztem event-on-change-reading) verwenden?

[marvin78]

Einfach das Log per Regex einschränken. Beispiel aus der Doku:

Code Auswählen Erweitern

define wzlog FileLog ./log/wz-%Y-%U.log wz:(measured-temp|actuator).*


Oder eben analog mit DBlog. Da gibt es dann noch Tools, wie DblogExlude etc.

[herrmannj]

('event-on-...' ist imho das am meisten missbrauchte Attribut ever!!!).

Dein Weg ist richtig. CloneDummy lass ich jetzt mal dahingestellt, hängt vom device ab. Ansonsten so wie Du sagst: dummy erstellen, mit notify/userReading etc updaten, dann dort das event-on-.. und loggen ...

[hopgeq]

> ('event-on-...' ist imho das am meisten missbrauchte Attribut ever!!!)

Nun, es es gibt ja sogar eine extra Wiki-Seite, die das Attribut für das Logging empfiehlt. Vor allem durch die Angabe der Schwelle kann man ja extrem viele Logeinträge sparen.
Und mit createlog gibt es ja auch einen extra Befehl zum Anlegen eines Logs ohne dummy dazwischen. Das sieht auf den ersten Blick jetzt erst mal nach Standardvorgehen aus, nicht nach Missbrauch.

Ich würde sagen, da fehlt ein Feature. Der Weg über den Dummy wirkt etwas mühsam, es sind ja eh schon recht viele Stationen bis man einen Plot hat (SpannendesDevice -> Filterdummy -> LogDevice -> PlotDevice).

Es wäre vielleicht sinnvoll, wenn FileLog selbst Attribute zum Filtern hätte. Also ich meine damit: Nur loggen, wenn der Wert w um mindestens d abweicht.

[marvin78]

Es ist nicht unbedingt ein dummy notwendig. Ein userReading, welches nur mit den gewünschten Einschränkungen aktualisiert wird und dann das loggen, statt des original Readings.