Logeinträge unterdrücken

Begonnen von Superposchi, 03 November 2020, 10:33:47

Vorheriges Thema - Nächstes Thema

Otto123

#15
Zitat von: Superposchi am 04 November 2020, 10:58:10
Gibt es eine globale Möglichkeit das Verbose-Attribut für alle Devices auf 0 zu stellen und dann einzeln gezielt wieder hochzudrehen?
Ich weiß, dass es ein globales Verbose-Attribut gibt, aber das wäre ja in dem Moment nicht zielführend da ich dann ja nicht einzelne Devices separat wieder höherstellen könnte, oder hab ich da einen Denkfehler?
Nachdem ich über diese beiden Fragen fast heulend zusammengebrochen wäre - habe ich dann doch noch eine pragmatische Antwort: Ja. So:
attr .* verbose 0

Es macht nur im Ausnahmefall Sinn den verbose Level auf 0 zu stellen, die Standardeinstellung 3 ist im Normalfall richtig und sinnvoll. Bei manchen Geräten macht 1 oder 2 Sinn.

Sorry das war jetzt doppelt, betateilchens Antwort war auf der anderen Seite  :-[
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Superposchi

Nein, ich habe noch lange nicht alles gelesen.
Kann man meines Erachtens auch gar nicht.

Außerdem kann man unmöglich alles behalten was man liest.

Otto123

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

betateilchen

Zitat von: Superposchi am 04 November 2020, 12:10:32
Außerdem kann man unmöglich alles behalten was man liest.

Muss man auch nicht, aber es machte durchaus Sinn, ein paar grundlegende Konzepte durch und beim Lesen zumindest zu verstehen
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Superposchi

Ja das stimmt natürlich, doch die Frage ist dabei, was ist grundlegend und was nicht.
Du merkst doch erst was du brauchst wenn du es verwenden willst und machst dir nicht im Vorfeld unendlich Gedanken was du alles lesen sollst weil du es vielleicht irgendwann mal in ferner Zukunft verwenden willst. Mal ehrlich, das ist doch unrealistisch.
Dazu kommt einfach das Problem, dass ich vieles gelesen habe, es aber nicht dauerhaft behalte, weil es eben viel zu viel ist.

Aber das Problem ist ja erstmal gelöst dank eurer kompetenten Hilfe und damit soll es dann auch gut sein, oder?

frank

ein grundsätzliches verständnis von "EVENT" in fhem ist unerlässlich.

nicht nur lesen, sondern anwenden und probieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

betateilchen

Zitat von: Superposchi am 05 November 2020, 09:55:08
Aber das Problem ist ja erstmal gelöst dank eurer kompetenten Hilfe und damit soll es dann auch gut sein, oder?

Du meinst, so lange gut, bis Du mit Deiner nächsten Frage, die auf mangelndem grundlegenden Verständnis von FHEM-Mechanismen beruht, hier auftauchst?

Kennst Du eigentlich den Unterschied zwischen "jemanden um Hilfe bitten" und "die Gutmütigkeit von hilfsbereiten Forummitgliedern ausnutzen"? Im Moment bewegst Du Dich - auch aus Deinen Antworten ablesbar -  sehr tief in der zweiten genannten Option.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Superposchi

Also nach meinem Kenntnisstand haben Foren den Sinn sich gegenseitig auszutauschen und zu helfen.
Dazu zählt in meinen Augen auch sich gegenseitig Fragen zu beantworten oder bei Unwissenheit Informationen weiterzugeben. Das ist doch kein ausnutzen. Das nenne ich einen Dialog führen.

Wenn das hier nicht so ist, bitte ich um den entsprechenden Hinweis wo das steht. Und vorallem eine Erklärung wofür dieses Forum dann da ist.

Superposchi

Schade das niemand eine Erklärung liefern kann/will.

Wenn ihr so ein unübliches Verhalten leben wollt, müsst ihr schon klare Regeln nennen und deutlich sagen was erlaub und was unerwünscht ist.

Beta-User

Die "Erklärung" ist (u.a.) hier zu finden: Unbedingt vor dem ersten Post lesen
(und den anderen hier angepinnten Beiträgen)

Es wird von jedem FHEM-User erwartet, dass er sich einarbeitet, und eine bessere Hilfe als die (auf deine Verständlinlücken recht gut zugeschnittene) Liste, die Otto123 dir zusammengestellt hatte, wirst du kaum bekommen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Superposchi

Ja und diese Liste bin ich ja auch durchgegangen.
Doch wenn ich dann Rückfragen zum Inhalt habe - weil ich es nicht verstanden habe - wird dies direkt als Faulheit bezeichnet bzw. fehlendes Grundwissen.

Erklär mir bitte die Logik dahinter.

Ich lese alles was ich in die Finge bekomme, aber aufgrund von Sprachproblemen - mein Englisch ist nicht das beste - und der Menge ist es für mich unmöglich mit diesem System etwas vernünftig zu lernen.
Das ganze Lesen bringt mir rein gar nichts. Ich bin der praktisch orientierte Mensch und lerne bevorzugt an praktischen Beispielen, die ich auf meine Bedürfnisse umarbeiten kann.
Doch wie gesagt wird dies ja gleich als Faulheit und Unwillen zum lernen ausgelegt.

Beta-User

Zum einen ist die Doku für FHEM (leider) zumeist in deutsch geschrieben, das ist also nur eine Ausrede für die wenigen Fälle, in denen es nur die offizielle Doku (=cref in englisch) gibt - und wenn du da eine KONKRETE Frage dazu gehabt hättest, wäre die vermutlich auch beantwortet worden.

Falls du sowas wie eine Zusammenfassung einer Einstiegshilfe zu FHEM suchst, wäre ggf. der Quick-Start zu empfehlen, ist über die Wiki-Einstiegsseite verlinkt.

Und zum konkreten Anlaß deines Ausgangsposts nochmal: Das Drehen an den verbose-Attributen ist unsinnig!

Daher wird dir auch keiner erklären wollen, wie es geht, höchstens, wie man es über die FHEM-Kommandozeile - insgesamt - wieder auf den default stellt:
deleteattr .* verbose
Auf welche Geräte sich das überhaupt auswirkt, kannst du vorab mit "list" erfahren:
list .* verbose
Das wäre ein konkretes Beispiel für "devspec".

Dann schaust du im Wiki nach "event-on-change-reading" und testest damit (und seinen "Verwandten) rum. Aber auch das hatte Otto123 bereits versucht, dir zu vermitteln.

Ansonsten will hier keiner "allgemeines Gemaule" hören, such' dir dafür ein anderes Forum!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Superposchi

Jetzt mal Butter bei den Fischen, warum macht es keinen Sinn am Verbose Attribut rumzuschrauben?
Wenn ich im Log vor lauter Einträgen die nicht wiederfinde die für mich relevant sind, macht es für mich durchaus Sinn damit das Aufkommen im Log zu reduzieren.
Und wie und warum ich etwas machen möchte oder versuchen möchte ist doch meine Sache, oder nicht. Muss ich jedes Detail, jeden Hintergedanken den ich habe erklären?

Und soweit ich mich entsinne habe ich bisher sehr konkrete Fragen gestellt, nur weil diese für euch vielleicht nicht nachvollziehbar sind/waren, sind sie schließlich nicht weniger konkret.
Aber natürlich kann es immer mal vorkommen, dass man etwas aufschnappt und dann mehr darüber erfahren will, weil man sich erhofft, das vielleicht irgendwie nutzen zu können

Beta-User

Für Einträge im Log (@defaults und bezogen auf das allgemeine FHEM-log) gibt es zwei Gründe:

Entweder eine Anweisung wird von FHEM ausgeführt, oder es liegt ein Fehler vor. Wenn das Log also unübersichtlich ist, solltest du überlegen, ob nicht "zu viel passiert" (Events (!) reduzieren) und/oder die Ursachen für Perl-Fehler etc. aufspüren und an denen arbeiten. So kann man log-Einträge dazu nutzen, ein allgemeines Verständnis dafür zu entwickeln, was man da eigentlich tut.

Aber ja, das ist deine Sache, das ist nur eine allgemeine und gut gemeinte Richtschnur, an den defaults als Anfänger NICHT zu schrauben.

Da du "selber groß" bist, gilt halt, was betateilchen schon geschrieben hatte:
Zitat von: betateilchen am 04 November 2020, 11:28:26
Aber komm nicht hinterher hier ins Forum und jammere rum, weil Du offenbar gar nicht verstehst, was Du da tust...
Damit bin ich hier raus.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Superposchi

ZitatEntweder eine Anweisung wird von FHEM ausgeführt, oder es liegt ein Fehler vor. Wenn das Log also unübersichtlich ist, solltest du überlegen, ob nicht "zu viel passiert" (Events (!) reduzieren) und/oder die Ursachen für Perl-Fehler etc. aufspüren und an denen arbeiten. So kann man log-Einträge dazu nutzen, ein allgemeines Verständnis dafür zu entwickeln, was man da eigentlich tut.
Im grunde ist genau das was ich vorhabe, nur das ich halt eben den anderen Weg gehe und alles was in ordnung ist eliminieren will um so nur noch das angezeigt zu bekommen was Fehler sind.