LED Display füllt unnötigerweise Log-Datei

Alcamar · 08 Juni 2015, 10:37:04

meine Statusanzeige HM-OU-LED16 ändert erwartungsgemäß von Zeit zu Zeit die Farben der LEDs.
Die Dokumentation jeder Änderungen im Log macht allerdings die Log-Datei unübersichtlich. Ich habe aber bisher nicht herausfinden können, wo ich das abstelle. Die Einträge haben keinen hohen Informationsgehalt, finde ich.

Code Auswählen

2015.06.01 22:00:07 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_14 led orange
2015.06.01 22:00:17 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_09 led green
2015.06.01 22:00:17 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led green
2015.06.01 22:00:18 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_11 led green
2015.06.01 22:00:22 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_15 led green
2015.06.01 22:00:23 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_16 led green
2015.06.01 22:00:34 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_14 led green
2015.06.01 22:00:37 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_13 led green
2015.06.01 22:00:40 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_12 led green

Hat jemand ein Tip für mich? In der Komponente selbst habe ich das Logging abgeschaltet. Es sollte Zustandänderung nicht geloggt werden.

Pfriemler · 08 Juni 2015, 16:23:31

Wie, meinst Du, hast Du in der Komponente das Logging selbst abgeschaltet? Das zugehörige FileLog deaktiviert oder den verbose-Level verändert? Letzteren würde ich mal auf 2 setzen (attr ... verbose 2) - die zitierten Meldungen haben LogLevel 3 und sollten dann nicht mehr auftauchen ...

geht nich Gips nich ...

franky08 · 08 Juni 2015, 18:13:53

Hallo, setze attr event-on-change-reading state.* und attr verbose 0 und das auf jeden Kanal (1-16) von der LED Anzeige und du solltest Ruhe haben.

P.S. gleich global verbose runterzusetzen ist nicht "das Gelbe vom Ei"

VG
Frank

Pfriemler · 08 Juni 2015, 23:36:27

0? So radikal? Ich meinte es natürlich auch im Gerät, nicht global. Bewahre...

geht nich Gips nich ...

franky08 · 09 Juni 2015, 00:15:13

Nicht im Gerät, in den einzelnen Chanels

VG
Frank

Alcamar · 09 Juni 2015, 06:57:46

Ich hatte das FileLog für das Gerät abgeschaltet. Dass verbose als attr trotzdem noch Sinn macht, war mir nicht klar. Ich habe jetzt alle 16 Kanäle auf verbose 2 gesetzt und erst danach die Posts von franky08 gelesen. Ich werde dem Vorschlag von franky08 folgen und alles auf 0 setzen und das attr Event-On-Change setzen.
Danke!

Welche Geräte-Logs sind am sinnvollesten? Außer die Thermometer-Logs nutze ich keine der vielen Logs, die stündlich entstehen. Ins fhem-Log schaue ich regelmäßig. Aber in alle anderen Geräte-Logs nicht. Laufen die bei euch?

Pfriemler · 09 Juni 2015, 13:00:23

Für die Fehleranalyse sind sie anfangs ganz nützlich. Sehr geschwätzige Logs habe ich tw. in Monatsblogs gewandelt und entsorge die alten zeitnah. Tendenziell benötigt man die meisten Logs aber nicht. Für alle Nutzdaten (Klima, Heizung) habe ich inzwischen eigene Logs (mit den allernötigsten Readings) und der Rest ist deaktiviert. Das werden die meisten ähnlich handhaben, da viele FileLogs auch Performance fressen und die Speicher stressen (DBLog auf schreibfeste Medien ist natürlich viel besser, lohnt sich aber für mich nicht).

geht nich Gips nich ...

martinp876 · 09 Juni 2015, 21:12:10

generell empfehle ich

Code Auswählen

attr TYPE=CUL_HM event-on-change-reading .*
save

Alcamar · 11 Juni 2015, 09:14:30

Hallo Martin,

habe nicht ganz kapiert, ob Dein attr für die einzelnen Aktoren/Sensoren gilt, oder für das Steuer-Device (CUL, HMUSB, etc.)
Dein Vorschlag scheint mir die globale Lösung zu sein, aber ich habe das attr nicht gefunden. Einfach nur eintippen, wollte ich Dein Vorschlag bisher nicht, weil ich es eben noch nicht verstanden habe.

Was der Bauer nicht kennt.....

Ist das so richtig, dass ich die Einstellung global vornehmen kann, und nicht jede einzelne Komponente dann mit einem gesonderten Attribut versehen muss?

Grüße
Alcamar

Pfriemler · 11 Juni 2015, 14:40:38

Martins Vorschlag setzt lokal bei allen Geräten (Aktoren und Sensoten ... btw: auch bei channels???) des Typs CUL_HM das Attribut event-on-change-reading ohne Filter, so dass diese Geräte nur dann Events generieren (und damit etwaige Notifys etc triggern), wenn sich der Wert eines Readings ändert (und nicht schon, wenn es mit dem alten Wert erneuert wurde).

geht nich Gips nich ...

LuckyDay · 11 Juni 2015, 15:05:40

Man könnte auch selber mal nachsehen

jedes define.... hat einen TYPE bei den Internals

Alcamar · 11 Juni 2015, 15:16:26

@Pfriemler: danke. Ich weiss nun bescheid.

@fhem-hm-knecht: Du hast mich auf etwas gebracht, was mich derzeit auch umtreibt. Ein Aktor meldet im Log, dass er no TYPE hat. Dass bei define auch ein TYPE vergeben wird.... weiß ich nun

Vielleicht habe ich da etwas falsch geknopft.

Alcamar · 19 Juni 2015, 23:55:48

Event-On-change-reading .* brachte für die Bewegungsmelder das Resultat, dass sie keine Bewegung mehr registrierten. Konkret sollte das Licht eingeschaltet werden, wenn eine Bewegung registriert wurde. Bei drei Bewegungsmeldern passierte aber gar nix mehr.

Pfriemler · 20 Juni 2015, 08:02:46

Ja. Stimmt leider. Bwm senden nur "motion", aber kein "lo motion". Da sich dieses reading also nie ändert, sondern nur aktualisiert, ist event-on-change-reading für Homematic Bewegungsmelder doch nicht so geeignet...

geht nich Gips nich ...

martinp876 · 20 Juni 2015, 08:03:36

Schau einmal die readings durch. Eventonchangereading funktioniert ganz einfach. Sollte der wert schon im reading stehen gibt es keinen event. Ich habe daher fast alle readings so angelegt, dass sich bei einem weiteren event eine aenderung ergibt. Aus dem kopf glaube ich es gibt ein reading beim md, das nur motion anzeigt. Das war schon aelter..... du solltest aber readings haben, welche sich aendern. Diese wuerde ich nutzen, ggf in den state mappen falls gewuenscht.
.* wuerde ich in jedem fall ueberall eintragen, ggf das system anpassen. Fuer mich ein grundsatz. Alles andere nur zum testen.