Deaktivierung Logging Virtuelles Homematic-Device (Lacrosse>HM-CC-RT-DN)

[hmtec99]

Kann mir jemand sagen, an welcher Stelle ich die folgenden Einträge ins fhem.log unterbinden kann?

2022.02.11 03:06:24.782 3: CUL_HM set vEnv_KU_T virtTemp 18.3

Das Log besteht hauptsächlich aus diesen relativ sinnlosen Einträgen...

Gruß, Oli

[gregorv]

In welchen Abständen kommen die Einträge ?
'set' Einträge kommen, soweit ich weiß, nur bei höherem Log-Level.

[MadMax-FHEM]

set-Einträge kommen (wie dem Eintrag zu entnehmen ist) ab verbose 3 (Standard), siehe auch: https://wiki.fhem.de/wiki/Verbose

Wenn du die nicht haben willst, dann eben verbose auf 2 oder tiefer setzen...

Gruß, Joachim

[hmtec99]

die set einträge kommen 1x pro minute bei jedem lacrosse-sensor (ist so gewollt), d.h.
es sind ...moment... 14 einträge pro minute, wenn ich richtig gerechnet habe...

@joachim: das ist klar, aber verbose=3 ist ja sinnvoll. das will ich nicht generell ändern, da mir dadurch vermutlich andere, wichtige loggings
flöten gehen....

an welcher stelle werden den diese einträge mit verbose 3 gesetzt? CUL_HM.pm?

[gregorv]

der verbose level kann für einzelne devices überschrieben werden (dadurch, dass dort attr ... verbose wert vorhanden ist). Entweder im Device vEnv_KU_T oder da, wo der set Befehl herkommt (noitfy /doif...) - da bin ich nicht ganz sicher.
Außerdem kann man in dem Device, wo die Temperatur herkommt, dafür sorgen, dass nur Events losgetreten werden, wenn sich der Wert auch ändert - so verhindert man zumindest identische Nachrichten (event-on-update-reading / event-on-change-reading).
Im übrigen komme ich seit vielen Jahren mit Log-Level 1 aus, wenn viele Devices da sind ist das auch schnell unübersichtlich bei verbose =3.

[frank]

Das Log besteht hauptsächlich aus diesen relativ sinnlosen Einträgen...

der user kann dadurch sehr schön erkennen, wie "sinnvoll" das automatische cmd setting ausgeführt wird.

die set einträge kommen 1x pro minute bei jedem lacrosse-sensor (ist so gewollt), d.h.

gewollt sinnloses wiederholen identischer befehle in unnötig kurzen abständen belastet nur dein system.

und nun willst du im modul dein "sinnloses" cmd setting ausblenden, damit du wieder ruhig schlafen kannst, oder? 

[hmtec99]

hä? soll ich fhem.log deaktivieren, damit ich keine fehlermeldungen mehr vom system mitbekomme??

ich glaube wir gehen von falschen tatsachen aus...

mir ist es nicht egal ob das log 2gb groß ist und ich mich durch endlose listen scrollen muß (die hauptsächlich aus den erwähnten einträgen besteht),
aber ich würde fehler die auftreten schon gerne im log nachvollziehen können...

ich habe grundsätzlich verbose 3 global gesetzt und diese virtuellen channnel sind das einzigste, was hier ständig loggt. auslöser des set-commands ist übrigens
ein notify (dort ist das loglevel gar nicht gesetzt - sollte also evenso 3 sein...

der eintrag kommt aber nicht durch das notify sondern von einem modul in dem hier wohl das loglevel zu niedrig gewält wurde (3 statt 4)?

[hmtec99]

nachtrag: alle anderen homematic-geräte loggen ein set-command ja auch nicht...

[frank]

ich glaube wir gehen von falschen tatsachen aus...

1.

nachtrag: alle anderen homematic-geräte loggen ein set-command ja auch nicht...

falsch von dir.

Code Auswählen Erweitern

2022.02.11 13:48:06.257 3 : CUL_HM set SwitchPBU03 off noArg

2.

der eintrag kommt aber nicht durch das notify sondern von einem modul in dem hier wohl das loglevel zu niedrig gewält wurde (3 statt 4)?

falsch von dir.

verbose
Set the verbosity level. Possible values:

    0 - server start/stop
    1 - error messages or unknown packets
    2 - major events/alarms.
    3 - commands sent out will be logged.
    4 - you'll see whats received by the different devices.
    5 - debugging.

The value for the global device is a default for other devices without own verbose attribute set.

3.

ich habe grundsätzlich verbose 3 global gesetzt und diese virtuellen channnel sind das einzigste, was hier ständig loggt. auslöser des set-commands ist übrigens
ein notify (dort ist das loglevel gar nicht gesetzt - sollte also evenso 3 sein...

falsch von mir.
ein notify, das regelmässig alle 60s auf alle 14 tempsensoren gleichzeitig triggert, ist schon was ganz besonderes. 
daher war ich von einem at ausgegangen.

trotzdem ist das zu viel.
ein virtueller tempfühler gibt maximal 1x alle etwa 2,5 min die temp an den rt weiter. dabei gibt der rt den rythmus vor.
also sind mindestens 3/5 deiner set cmd überflüssig => "1,2 GB logmüll".
zusätzlich noch alle temps die wiederholt mit unveränderter temp gesezt werden.


4.
trotzdem sollte ein verbose im channel des virtuellen tempfühlers das logging einstellen.
bei mir funktioniert es dort mit verbose 2.

[hmtec99]

1. falsch von dir.

Code Auswählen Erweitern

2022.02.11 13:48:06.257 3 : CUL_HM set SwitchPBU03 off noArg

2. falsch von dir.

ok. wieso tauchen dann ALLE meinen sonstigen homematic-geräte NICHT auf. die TH's werden übrigens auch per touchdiplays gesetzt. da müßten die set-commands ja dann auch auftauchen. was sie NICHT tun!

ok. falsch von mir. taucht nur so selten auf, daß es mir nicht aufgefallen ist.

3.falsch von mir.
ein notify, das regelmässig alle 60s auf alle 14 tempsensoren gleichzeitig triggert, ist schon was ganz besonderes. 
daher war ich von einem at ausgegangen.

trotzdem ist das zu viel.
ein virtueller tempfühler gibt maximal 1x alle etwa 2,5 min die temp an den rt weiter. dabei gibt der rt den rythmus vor.
also sind mindestens 3/5 deiner set cmd überflüssig => "1,2 GB logmüll".
zusätzlich noch alle temps die wiederholt mit unveränderter temp gesezt werden.

es ist natürlich ein notify pro lacrosse-sensor und deren "geschwätzigkeit" wird vorher schon auf 1 event pro minute eingebremst...
außerdem werden die temps per burst-xmit übertragen, also tätsachlich jede minute 1 mal.

um genau zu sein: es ist ein notify pro sensor, das wiederum 2 set commands triggert. einmal temp und einmal hum (es sind also 7 sensoren).

4.
trotzdem sollte ein verbose im channel des virtuellen tempfühlers das logging einstellen.
bei mir funktioniert es dort mit verbose 2.

das muß ich ausprobieren. danke.

das hat funktioniert. danke!

ich hatte das vorher schon probiert, allerdings auf dem virtuellen device und nicht auf dem channel.

[Beta-User]

Ist das Problem jetzt eigentlich [gelöst]?

Der letzte Post ist irgendwie außergewöhnlich formatiert, es scheint aber so...?

Vielleicht noch ein paar Anmerkungen:
- nur weil ein (oder viele) notify einen Temperaturwert in einen virtuellen Kanal geschrieben wird, wird dieser nicht unmittelbar auch versendet, und falls (!) man den dazu bewegen kann, das per burst zu tun, sollte man das tunlichst wieder abschalten!
- im Wiki steht seit längerem nicht ohne Grund, dass man ggf. auch dafür sorgen muss, dass zu alte Werte wieder gelöscht werden (wenn sie falsch sind; ein "uralter" aber korrekter Wert ist kein Problem).
- Was ein RT mit einem virtuellen Humidity-Wert anfängt, erschließt sich mir nicht, per burst versenden würde ich den jedenfalls nicht wollen .

Falls jemand was zum "Nachbauen" sucht, hier mal meine aktualisierte Variante:
Benötigt wird:
a) Ein echter Sensor pro RT-DN (hier: MQTT2_DEVICE bzw. HUEDevice)
b) readingsWatcher samt entsprechender Konfiguration an den Sensoren
c) je ein virtueller Kanal von einem eigenen virtuellen Device je "Gruppe" (ein oder mehrere RT-DN in einem Raum, ich nehme einen anderen Kanal von diesem Device als virtualisierten und öffnen-verzögerten Fensterkontakt)
d) ein notify, das alle Sensoren auf einmal überwacht.

a) Beispielsensoren:

Code Auswählen Erweitern

define Temperatur_Schlafzimmer HUEDevice sensor 33  IODev=phoscon
attr Temperatur_Schlafzimmer readingsWatcher 4000,0.000,temperature

Das ist per se nicht allzu gesprächig, der readingsWatcher-Eintrag führt dazu, dass nach einer guten Stunde ohne Aktualisierung ein spezieller numerischer Wert als Temperatur geschrieben wird => auf den ersten Blick im Plot (und im notify) zu erkennen, dass da ein Problem ist...

Code Auswählen Erweitern

define Raumfuehler_Buero MQTT2_DEVICE A51C386CDBCC
attr Raumfuehler_Buero event-min-interval 300
attr Raumfuehler_Buero event-on-change-reading batteryPercent,temperature:0.2,humidity:0.2,rssi:5,distance:5
attr Raumfuehler_Buero readingsWatcher 4000,0.000,temperature,humidity
Der ist etwas gesprächiger, das Intervall könnte auch noch deutlich länger sein nach meinem aktuellen Geschmack (es stört mich aber auch nicht).

c) ist klar, siehe wiki.

d) Das notify sieht so aus:

Code Auswählen Erweitern

define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.*  {\
my %tsensorsmap = (\
  Raumfuehler_Buero => 'Fake_Fenster_Buero_Temp',\
  Raumfuehler_Kind1 => 'Fake_Fenster_Kind1_Temp',\
  Temperatur_Schlafzimmer => 'Fake_Fenster_SZ_Temp',\
  Raumfuehler_Wohnzimmer => 'Fake_Tuere_WZ_Temp',\
  [ ein paar mehr ]
  );;\
  return if !defined $tsensorsmap{$NAME};;\
  return CommandDeleteReading(undef, "$tsensorsmap{$NAME} temperature") if $EVTPART1 eq '0.000';;\
  CommandSet(undef, "$tsensorsmap{$NAME} virtTemp $EVTPART1")\
}
Da readingsWatcher bereits die Sensoren überwacht, kann hier auf diesen sehr speziellen Wert dahingehend reagiert werden, dass das ganze Reading gelöscht wird (sorry für die etwas ungewohnte Schreibweise), ansonsten wird der Wert dann wie gehabt an den zugeordneten virtuellen Kanal weitergegeben; da die "Zuordnungstabelle" im notify direkt steht, sieht man auch in "probably associated with" in der Detailansicht, was wie zusammengehört bzw. welche STATE die im Einzelnen haben.

Vielleicht hilft das ja jemandem...

[hmtec99]

Ich schildere nochmal kurz meine Vorgehensweise:

Ich habe einige LaCrosse-Sensoren, die Temperatur und Feuchte messen. Die Werte werden 1x in der Minute geloggt und lösen über ein Notify 1 Set und 2 Trigger aus, wobei die Feuchte lediglich für Anzeigezwecke gespeichert wird. Sieht dann so aus:

set vEnv_BD_T virtTemp $T; trigger vEnv_BD_T $T; trigger vEnv_BD_H $H

Die Trigger dienen der Speicherung der Daten in eine Datei zur bedarfsweisen Übertragung an mehrere Touchdisplays (Nextion).

Jedes der virtuellen Devices ist wiederum mit je einem TH gepeert (Channel Weather) und überschreibt damit den internen Temperatursensor.

Soweit so einfach....

Das mit Burst-Xmit war natürlich Quatsch in Bezug auf die virtuellen Devices. Ich habe wie schon erwähnt Touchdisplays im Einsatz. Wenn ich dort die
Temperatur der TH's ändere, will ich natürlich ein zuverlässiges, augenblickliches Feedback, daß die Änderung durchgeführt wurde. Damit ich das erreiche
wird die "neue" Temperatur per Burst-Xmit an den jeweiligen TH übertragen und die Antwort innerhalb von 1-2 Sekunden auf den Touchdisplays angezeigt.

Welche Vorteile hätte deine Variante?

Wie kann ein "falscher" Wert entstehen?

[Beta-User]

Ich schildere nochmal kurz meine Vorgehensweise:
[...]

Soweit es die Übertragung der gemessenen Temperatur in den virtuellen Kanal betrifft, ist das "Standard" und klar. Was das weitere Getriggere soll, werde ich in diesem Leben vermutlich nicht mehr verstehen: warum nicht das Ausgangsdevice (den LaCrosse-Sensor) zum Loggen nehmen und den Wert (bzw. Temp+Humidity) per MQTT_GENERIC_BRIDGE direkt (an die Displays oder wohin auch immer) versenden...?

Aber eben nicht alle Minute, sondern z.B. alle 10 Minuten _oder_ wenn es eine signifikante Änderung gab... Alles andere ist doch nur "Selbstbeschäftigung" des Systems, und so ein "Datengeschubse" macht es im Zweifel nur fehleranfällig und schwerer zu debuggen, wenn was nicht will, wie es soll.

Touchdisplays im Einsatz. Wenn ich dort

OK, das leuchtet halbwegs ein, wobei ich auch dort auf burst möglichst verzichten würde. Das weckt immer alle in Funkreichweite auf und verbraucht damit (mAn. unnötig) Energie... Aber wenn man das unbedingt so haben will, ist das auch legitim.

Welche Vorteile hätte deine Variante?
Wie kann ein "falscher" Wert entstehen?

Ein "falscher" Wert kann dadurch entstehen, dass die Messung nicht erfolgt und/oder nicht in FHEM landet. Batterie am Sensor leer, IO ausgefallen, "babbling idiot", whatever... Beispiele: Meine Xiaomi-ZigBee's sind in der Vergangenheit gerne mal offline gegangen, und früher hatte die Firmware des OpenMQTTGateways das Problem, dass die sich alle 2-3 Wochen mal aufgehangen hatte (ist seit längerem behoben!)
Dann steht ohne Löschmimik (im Wiki gibt es dafür ein at) halt der letzte Wert "für immer" da drin, egal, ob er jetzt grade zufällig paßt oder ob das Fenster seit Stunden offen steht...

Also ist es m.E. zwingend, dass man das überwacht - zum einen, damit dann wenigstens der interne Sensor ersatzweise herangezogen wird, zum anderen, dass man eine Info an den Administrator des FHEM-Systems sendet, wenn das passiert (das ist aber ein anderer Teil der Gesamtstory).

[hmtec99]

Soweit es die Übertragung der gemessenen Temperatur in den virtuellen Kanal betrifft, ist das "Standard" und klar. Was das weitere Getriggere soll, werde ich in diesem Leben vermutlich nicht mehr verstehen: warum nicht das Ausgangsdevice (den LaCrosse-Sensor) zum Loggen nehmen und den Wert (bzw. Temp+Humidity) per MQTT_GENERIC_BRIDGE direkt (an die Displays oder wohin auch immer) versenden...?

das kriegen wir doch hin: durch das Getriggere werden eben diese Werte in eine Datei geschrieben. Die Touchdisplays sind im Sleep-Modus wenn sie nicht aktiv bedient werden, d.h. eine Übermittlung ist nicht möglich. Erst beim Wakeup werden die Daten (aus dieser Datei) an das Display übermittelt. Was soll ich übrigens mit MQTT? Hab ich gar nicht im Einsatz...

Aber eben nicht alle Minute, sondern z.B. alle 10 Minuten _oder_ wenn es eine signifikante Änderung gab... Alles andere ist doch nur "Selbstbeschäftigung" des Systems, und so ein "Datengeschubse" macht es im Zweifel nur fehleranfällig und schwerer zu debuggen, wenn was nicht will, wie es soll.
OK, das leuchtet halbwegs ein, wobei ich auch dort auf burst möglichst verzichten würde. Das weckt immer alle in Funkreichweite auf und verbraucht damit (mAn. unnötig) Energie... Aber wenn man das unbedingt so haben will, ist das auch legitim.

Ja, aber einmal pro Minute ist doch legitim. Ich will doch möglichst den Verlauf der Temperaturmessung sehen und nicht nur ein Wert alle 10 Minuten. Das kann ich meinem System schon zumuten. Sonst würde es ja den ganzen Tag leer laufen...

Ein "falscher" Wert kann dadurch entstehen, dass die Messung nicht erfolgt und/oder nicht in FHEM landet. Batterie am Sensor leer, IO ausgefallen, "babbling idiot", whatever... Beispiele: Meine Xiaomi-ZigBee's sind in der Vergangenheit gerne mal offline gegangen, und früher hatte die Firmware des OpenMQTTGateways das Problem, dass die sich alle 2-3 Wochen mal aufgehangen hatte (ist seit längerem behoben!)
Dann steht ohne Löschmimik (im Wiki gibt es dafür ein at) halt der letzte Wert "für immer" da drin, egal, ob er jetzt grade zufällig paßt oder ob das Fenster seit Stunden offen steht...

Also ist es m.E. zwingend, dass man das überwacht - zum einen, damit dann wenigstens der interne Sensor ersatzweise herangezogen wird, zum anderen, dass man eine Info an den Administrator des FHEM-Systems sendet, wenn das passiert (das ist aber ein anderer Teil der Gesamtstory).

Aber das wäre ja kein falscher Wert. Höchstens ein veralteter... Und die Sensoren werden auf eine andere Art überwacht, d.h. ich bekomme es schon mit wenn die Messung ausfällt. Aber du meinst wenn man den Wert dann löscht, springt er sofort auf den internen Sensor des TH?

[Beta-User]

OT: Deine Formatierungen sind grausam!

durch das Getriggere werden eben diese Werte in eine Datei geschrieben. Die Touchdisplays sind im Sleep-Modus wenn sie nicht aktiv bedient werden, d.h. eine Übermittlung ist nicht möglich. Erst beim Wakeup werden die Daten (aus dieser Datei) an das Display übermittelt. Was soll ich übrigens mit MQTT? Hab ich gar nicht im Einsatz..

Aha. Anscheinend braucht man eine Datei. OK. Vermute immer noch, dass es zur Abfragezeit einfacher wäre, kurz die Istwerte zusammenzutragen, aber darum ging es hier ja nicht.

Ja, aber einmal pro Minute ist doch legitim. Ich will doch möglichst den Verlauf der Temperaturmessung sehen und nicht nur ein Wert alle 10 Minuten. Das kann ich meinem System schon zumuten. Sonst würde es ja den ganzen Tag leer laufen...

Nun ja, jeder wie er es braucht. Wenn es Sprünge gibt, wird auch bei mir schneller geloggt, aber das ist die Ausnahme (und Sinn des Hysterese-Wertes bei eocr).

Aber das wäre ja kein falscher Wert. Höchstens ein veralteter... Und die Sensoren werden auf eine andere Art überwacht, d.h. ich bekomme es schon mit wenn die Messung ausfällt. Aber du meinst wenn man den Wert dann löscht, springt er sofort auf den internen Sensor des TH?

Nach meiner Auffassung ist ein ungeprüfter veralteter Wert ein falscher Wert, selbst wenn er zufällig grade wieder stimmen sollte.

Und ich meine nicht nur, sondern WEISS, dass die RT auf die internen Sensoren zurückfallen, wenn sie zu lange keine Infos vom Peer übermittelt bekommen. Dann fängt übrigens das Funk-Symbol an zu blinken...