[ASC] ASC Debug-Modus und Logfile

Wolle02 · 18 März 2022, 17:17:31

Hallo Colltux, momentan habe ich das Problem, dass hin und wieder (eine Regelmäßigkeit habe ich leider noch nicht erkennen können) meine Rollläden plötzlich völlig unmotiviert rauf oder runter fahren. Da das den WAF natürlich beeinflusst will ich mich auf die Problemsuche begeben und habe daszu den ASC Debug Modus aktiviert, um sehen zu können welche Events hier ausschlaggebend für die Fahrbefehle sind.
Leider ballert der Debug Modus das reguläre Logfile ja gnadenlos zu

Auf der einen Seite natürlich gut, weil viele Informationen da sind, auf der anderen Seite finde ich das Logfile dann nicht mehr sehr händelbar. Vor allem aufgrund der produzierten Größe, da ich den Debug Modus ja u.U. längere Zeit laufen lassen muss, weil ich nicht weiß, wann das Problem das nächste Mal auftritt.

Meinst du, du könntest den Debug Modus so umstellen, dass die Ausgaben in einem separaten Logfile gespeichert werden, das auch täglich rotiert? Dann hätte man die Debug Infos alle an einer Stelle, das reguläre Logfile bleibt übersichtlich und bei längerer Laufzeit des Debug Modus könnte man die täglichen Logfiles einfach löschen, wenn die gewünschte Info nicht enthalten ist.

CoolTux · 18 März 2022, 17:42:31

Das muss ich mir anschauen ob ich sowas zeitnah hin bekomme. Da das eine zentrale Funktion sein sollte, sollte es eigentlich kein Problem darstellen.

Beta-User · 18 März 2022, 17:49:43

Hmm, das Thema mit der separaten File kam ja schon ein paar Mal, und die Argumente dagegen sind m.E. auch weiter valide: Wenn man keinen allgemeinen Zusammenhang hat, sind die reinen ASC-Daten schlecht einzusortieren.

Was mich aber auch "schon immer" stört, ist die "Lautstärke", mit der ASC-Debug ins Log "brüllt". Vielleicht ginge es etwas dezenter (und sehr evtl. auch mit zwei Leveln, damit nicht alles geschrieben wird, sondern ggf. nur auf Stufe 1 das "häufig wichtige")?

EDIT: ggf. könnte man auch in Stufe 1 die verbose-Angaben des Rollladens beachten und z.B. nur was schreiben, wenn der 4/5 ist?

Wolle02 · 18 März 2022, 18:53:56

Zitat von: Beta-User am 18 März 2022, 17:49:43
Hmm, das Thema mit der separaten File kam ja schon ein paar Mal, und die Argumente dagegen sind m.E. auch weiter valide: Wenn man keinen allgemeinen Zusammenhang hat, sind die reinen ASC-Daten schlecht einzusortieren.

Also das finde ich jetzt eigentlich nicht. In beiden Logfiles gäbe es ja Zeitstempel über die sich der allgemeine Zusammenhang wieder herstellen ließe. Und zwei Logfiles nebeneinander zu stellen, um etwas zu vergleichen ist doch jetzt nicht soooo schwierig?

Das Logfile nach mehreren Leveln befüllen zu lassen finde ich aber auch eine gute Lösung. Letztlich gehts mir ja nur darum im Debugfall keine rieeesen Logdatei zu haben.

CoolTux · 18 März 2022, 19:06:23

Naja hättest Du aber dennoch. Hieße halt nur anders die Datei

Wolle02 · 18 März 2022, 19:44:26

Zitat von: CoolTux am 18 März 2022, 19:06:23
Naja hättest Du aber dennoch. Hieße halt nur anders die Datei

Ja, sorry, da hab ich mich falsch ausgedrückt. Klar wäre die Datei natürlich auch noch immer sehr groß, nur könnte man sie halt einfach löschen, wenn dein Problem, das du debuggen möchtest nicht auftritt. Das reguläre Logfile kann ich nicht einfach löschen, weil sonst alle anderen Infos, die ich vielleicht behalten möchte, sonst auch weg sind.

CoolTux · 18 März 2022, 20:41:23

Was ich anbieten könnte wäre das sämtliche ASC Logmeldungen in eine eigene

Code Auswählen

./log/AutoShuttersControl-%Y-%m-%d.log Datei wandern.
Oder je nach dem was per Attribut konfiguriert ist. Sonst müsste ich selbst was entwickeln mit filewrite und das wäre nicht zielführend und könnte Systeme ausbremsen.

Wolle02 · 18 März 2022, 22:58:58

Ja, so eine eigene Logdatei war eigentlich das was ich mir auch vorgestellt hatte.
Würdest du dann da nur die Debuglogs reinschreiben lassen? Weil die regulären Logeinträge dürften ja durchaus auch weiterhin im regulären Logfile stehen.

CoolTux · 19 März 2022, 06:10:07

Zitat von: Wolle02 am 18 März 2022, 22:58:58
Ja, so eine eigene Logdatei war eigentlich das was ich mir auch vorgestellt hatte.
Würdest du dann da nur die Debuglogs reinschreiben lassen? Weil die regulären Logeinträge dürften ja durchaus auch weiterhin im regulären Logfile stehen.

Nein, wie ich schrieb geht es nur wenn alle Meldungen in dieses Log gehen. Nur dann kann ich die Routinen von FHEM verwenden.

Wolle02 · 19 März 2022, 07:08:15

Ah ok. Da meinem Empfinden nach ASC sowieso nur im Debugmodus ins Logfile schreibt, käme das ja auch dem gleich.
Ich kenne das halt z.B. von MSwitch her, dass bei einem bestimmten Debuglevel ein separates Logfile geschrieben wird, aber alles übrige im regulären Logfile landet. Deshalb dachte ich, sowas wäre kein Problem. Dass das bei mir das System ausbremsen würde, habe ich auch noch nicht festgestellt.

Also von meiner Seite fände ich das ok, wenn ASC sein eigenes Logfile schreibt (machen andere Module ja auch). Damit könnte ich in meinem Problemsuchfall auch gut umgehen.

Romoker · 19 März 2022, 08:33:47

Ich bin gerade dabei meine eigene Rollladensteuerung auf ASC umzustellen, da ASC (fast) alle Funktionen meiner eigenen Steuerung erfüllt - und natürlich noch viel mehr Optionen bietet.
Ich möchte mich der Anforderung anschließen, die Debug-Ausgabe reduzieren zu können. Mir würde es schon reichen, wenn ich Debug auf ein Rollo-Device beschränken kann (attr ASC_debug <device name> 1).
Da wir schon beim Wünschen sind:
Ich habe immer wieder Probleme den Grund für das Nicht-Fahren bei Beschattung herauszufinden. Das liegt hauptsächlich an der Fülle der Möglichkeiten und vielen Default-Parametern, die ich nicht immer im Blick habe, wenn sie nicht explizit gesetzt wurden. Ich rätsele immer wieder über die Debug-Meldung "Einer der Beschattungsbedingungen wird nicht mehr erfüllt und somit wird der Beschattungsstatus um eine Stufe reduziert." Es wäre hilfreich, wenn zumindest eine Nicht-erfüllende Bedingung in Debug benannt wird.

Ansonsten, ein starkes Modul - vielen Dank dafür.

Viele Grüße

CoolTux · 19 März 2022, 08:40:11

Zitat von: Romoker am 19 März 2022, 08:33:47
Ich rätsele immer wieder über die Debug-Meldung "Einer der Beschattungsbedingungen wird nicht mehr erfüllt und somit wird der Beschattungsstatus um eine Stufe reduziert." Es wäre hilfreich, wenn zumindest eine Nicht-erfüllende Bedingung in Debug benannt wird.

Natürlich macht es, gerade für User, Sinn zu sehen was nicht mehr erfüllt wird. Ich muss aber gestehen das dies ein enormer Zeit- und Codeaufwand bedeuten würde und ich daher diese Art des debug bisher gescheut habe.

CoolTux · 19 März 2022, 08:42:19

https://git.cooltux.net/FHEM/mod-AutoShuttersControl/issues/103

Wolle02 · 19 März 2022, 08:44:23

In diesem Thread -> https://forum.fhem.de/index.php/topic,110396.msg1045745.html#msg1045745 gibt es einen Codeschnipsel wie man für die Beschattungsbedingungen ein Ampelsystem einbauen kann. Mir hilft das ganz gut den Überblick zu behalten welche Bedingung gerade wann wo erfüllt ist oder auch nicht.

Beta-User · 20 März 2022, 17:45:46

Zitat von: CoolTux am 20 März 2022, 09:13:04
Danke für Deine Sicht welche sehr gerne im ASC Thread weiter diskutiert werden darf da die ASC User nicht dieser Ansicht sind.

Nur zur Klarstellung: Falls du mich als "positive vote" gezählt hattest, war das ein Mißverständnis. Ich fände zwar die Option eine selektiveren loggings gut, aber innerhalb der allgemeinen Logfile.

Damit würde ich hier auf 1:2 kommen (pro separat/dagegen).