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.
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.
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 ...
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
0? So radikal? Ich meinte es natürlich auch im Gerät, nicht global. Bewahre...
geht nich Gips nich ...
Nicht im Gerät, in den einzelnen Chanels ;)
VG
Frank
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?
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 ...
generell empfehle ich
attr TYPE=CUL_HM event-on-change-reading .*
save
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
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 ...
Man könnte auch selber mal nachsehen :)
jedes define.... hat einen TYPE bei den Internals
@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.
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.
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 ...
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.
Auf dem ersten Blick sehe ich keine Readings, die sich ändern. Wie ein Mapping von Readings geht, weiß ich auch noch nicht. Das kenne ich nur bei attr. Ich werde das mal in einer ruhigeren Minuten angehen.
Macht das eventonchengereading .* so viel aus? Ich habe das überall geändert, außer bei den md, weil dort danach gar nix mehr ging. Das Problem mit der Log-Datei habe ich mit einem 'disable' gelöst. Sollte ich mal auf der Fehlersuche sein, kann ich die relevante Logdatei wieder aktivieren.
Verbose 3 habe ich auch eingestellt. In fhem.log habe ich auch keine unnützliche Einträge mehr.
Der md sollte zumindest ein reading mit zeahler haben. Koennte sein, das er unterschiedlicht messages sendet, wenn oder nicht er gepeert ist.
Den Zähler sendet er. Das war das einzige, was sich ändert. Du würdest also vorschlagen den Zähler zu prüfen und diese Änderung als Auslöser für das schalten des Lichts zu verwenden und nicht Motion?
Was genau wäre die Konsequenz daraus? Reduziere ich damit Funklast? Logeinträge generiere ich nicht mehr, denke ich. Ich werde am Ende wohl 5-6 Bewegungsmelder im Einsatz haben.
motioncount sollte passen.
reduziert wird die CPU Last