neue readings per setreading ins DbLog

[nOerkH]

Hallo zusammen,

ich hab schon viel Spaß (und Frust) mit FHEM gehabt und freue mich immer wieder darauf etwas neues zu lernen. Dank dem Forum und google findet man ja fast du jedem Problem eine Idee zur Lösung, auch wenn manche Lösungswege schlichtweg veraltet und heutzutage Danke der Community schon besser zu lösen sind. Danke erstmal dafür.


Jetzt steh ich aber vor einer Kleinigkeit, die ich einfach nicht gesucht bekomme (oder die sonst niemandem Probleme bereitet)

Ich errechne mir bei vorhandenen Sensoren einen Wert, den ich per setreading auf den devices setzen und aktualisieren lasse - das funktioniert soweit ganz gut. Ich würde den Wert gerne auch per SVG Plot darstellen lassen, daher hab ich dieses Reading wie sonst auch ins DbLogInclude übernommen.

Explizit bei diesen per Setreading definierten Werten wird da aber nichts in die DB geschrieben - hab ich einen Denkfehler, ist es tatsächlich nicht so einfach? Wo zwickt's da? Wäre schön wenn ihr mich auf die richtige Fährte führen könntet

[Wzut]

verwende statt setreading das Attribut userReadings um eigene Readings in einem Device unterzubringen.
Die werden dann auch von DBLog in die DB geschrieben.

[nOerkH]

verwende statt setreading das Attribut userReadings um eigene Readings in einem Device unterzubringen.
Die werden dann auch von DBLog in die DB geschrieben.

Danke für den Tip, scheint aber so als könnte man das nicht nachträglich machen.

Die Readings sind nach einem setreading auf dem Device ganz normal sichtbar, das Setzen von dem attr userReadings hat nichts geändert

[Wzut]

Tipp : Mache dich zum Thema userReadings schlau. IMHO hast du es noch nicht verstanden, denn mit setzen eines Attributs auf was auch immer ist es leider nicht getan.
Da muß schon deine Funktion hin die heute das setreading füttert. 

[betateilchen]

Macht es doch nicht schon wieder unnötig kompliziert.

Grundsätzlich können readings, die mit setreading gesetzt werden, natürlich auch gelogged werden, denn setreading löst am Ende einen Event aus.
Voraussetzung: die regexp des Log-Devices greift auch für das neu gesetzte reading.

Gerade habe ich folgendes getestet:

Code Auswählen Erweitern

setreading global testReading 1

und das DbLog - bei mir steht die regexp auf .*:.* - tut ganz brav, was es soll.

Code Auswählen Erweitern


2020.05.19 16:36:00 4: DbLog dbLog -> ################################################################
2020.05.19 16:36:00 4: DbLog dbLog -> ###              start of new Logcycle                       ###
2020.05.19 16:36:00 4: DbLog dbLog -> ################################################################
2020.05.19 16:36:00 4: DbLog dbLog -> number of events received: 1 for device: global
2020.05.19 16:36:00 4: DbLog dbLog -> check Device: global , Event: testReading: 1
2020.05.19 16:36:00 5: DbLog dbLog -> parsed Event: global , Event: testReading: 1
2020.05.19 16:36:00 4: DbLog dbLog -> added event - Timestamp: 2020-05-19 16:36:00, Device: global, Type: GLOBAL, Event: testReading: 1, Reading: testReading, Value: 1, Unit:


[nOerkH]

Macht es doch nicht schon wieder unnötig kompliziert.

genau das denk ich mir - wenn ich mit setreading ein reading ändere/anlege, dann muss das ja auch zu einem Event führen.

Mein DbLog sieht aber sehr einsam aus

Code Auswählen Erweitern

2020-05-20 02:08:40|MQTT2_zigbee_Aqara_MotionSensor_Buero_Eingang|MQTT2_DEVICE|occupancy: true|occupancy|true|
2020-05-20 02:08:40|MQTT2_zigbee_Aqara_MotionSensor_Buero_Eingang|MQTT2_DEVICE|illuminance: 6|illuminance|6|
2020-05-20 02:08:40|MQTT2_zigbee_Aqara_MotionSensor_Buero_Eingang|MQTT2_DEVICE|illuminance: 4|illuminance|4|
2020-05-20 02:08:40|MQTT2_zigbee_Aqara_MotionSensor_Buero_Eingang|MQTT2_DEVICE|occupancy: true|occupancy|true|
2020-05-20 02:10:10|MQTT2_zigbee_Aqara_MotionSensor_Buero_Schreibtisch|MQTT2_DEVICE|illuminance: 8|illuminance|8|
2020-05-20 02:10:10|MQTT2_zigbee_Aqara_MotionSensor_Buero_Schreibtisch|MQTT2_DEVICE|occupancy: false|occupancy|false|
2020-05-20 02:10:10|MQTT2_zigbee_Aqara_MotionSensor_Buero_Eingang|MQTT2_DEVICE|occupancy: false|occupancy|false|
2020-05-20 02:10:10|MQTT2_zigbee_Aqara_MotionSensor_Buero_Eingang|MQTT2_DEVICE|illuminance: 4|illuminance|4|

Grundsätzlich hab ich ein DbLogExclude auf .* (also alles) und nehme explizit die Readings mit rein, die ich loggen möchte - funktioniert auch seit je her wie gedacht.

bei den devices wo per Notify ein setreading auf ein neues reading "presenceminutes" gesetzt wird, funktioniert das jedoch nicht.

Code Auswählen Erweitern

DbLogInclude = occupancy,illuminance,presenceminutes

damit sollt das reading meiner Erwartung nach geloggt werden ... wie man ganz oben sieht ist es aber weiterhin nur occupancy und illuminance

[betateilchen]

Grundsätzlich hab ich ein DbLogExclude

daher hab ich dieses Reading wie sonst auch ins DbLogInclude übernommen.

Mit FHEM und DbLog arbeite ich ja schon ziemlich lange, aber diese beiden Attribute sind für mich so ziemlich die überflüssigsten, die ich in FHEM bisher finden konnte. Benutzt (oder "gebraucht") habe ich in all den Jahren noch keines der beiden. Vermutlich hast Du auch noch irgendwo event-on-irgendwas Attribute gesetzt?

Mehr Sinn macht es in meinen Augen, auf dieses manuelle Hinzufügen und Ausschließen zu verzichten und bei der Anlage des DbLog devices eine sinnvolle regexp zu verwenden.

[TWART016]

Mit FHEM und DbLog arbeite ich ja schon ziemlich lange, aber diese beiden Attribute sind für mich so ziemlich die überflüssigsten, die ich in FHEM bisher finden konnte. Benutzt (oder "gebraucht") habe ich in all den Jahren noch keines der beiden. Vermutlich hast Du auch noch irgendwo event-on-irgendwas Attribute gesetzt?

Mehr Sinn macht es in meinen Augen, auf dieses manuelle Hinzufügen und Ausschließen zu verzichten und bei der Anlage des DbLog devices eine sinnvolle regexp zu verwenden.

Wie sähe denn ein sinnvolles regex aus? z.B. Wenn ich in 5 Devices temperature habe, aber nur in 3 ins DBLog geschrieben werden soll?

[betateilchen]

was "sinnvoll" ist, muss jeder selbst entscheiden, aber da die regexp prinzipiell beliebig komplex sein kann, spricht nix gegen ein Konstrukt wie dieses hier:

Code Auswählen Erweitern


(st_fl_PIR_Motion.*|.*motion:.*|.*Diesel.*|.*lumi.*|.*measured.*|.*desired.*|.*actuator.*|.*valve.*|.*level.*|.*temperature.*|.*humidity.*|.*pressure.*|RM_.*|out_Regen.*|gds.*|gtag.*|owo.*|mqtt.*)


Das ist die originale regexp vom DbLog in meinem Produktivsystem. Jeder weitere Temperatursensor wird automatisch mit gelogged. Man kann an der Stelle natürlich auch device:reading Kombinationen angeben, wenn man wirklich nur 3 von 5 Sensoren loggen möchte.

Auf jeden Fall hat es den Vorteil, dass ich die gesamte Konfiguration dessen, was ich gelogged haben möchte, an einer zentralen Stelle verwalte und nicht verstreut über 300 devices.

[nOerkH]

Vermutlich hast Du auch noch irgendwo event-on-irgendwas Attribute gesetzt?

Sehr richtig, ich lasse beim Anlegen eines Gerätes automatisch event-on-change-reading .* setzen und passe, falls notwendig event-on-update-reading für meine Anwendungszwecke an.

Du hast natürlich recht, so sind die settings auf Geräteebene ggf. verstreut.
Ich verstehe deinen Ansatz, möchte ihn auch gar nicht schlecht reden. Hat ganz bestimmt seine Daseinsberechtigung.

Da ich bisher mit meiner Konfiguration noch nie in Probleme gelaufen bin, vermute ich, dass es nicht zum Ziel führt, dieses Konzept jetzt umzustellen. Die Frage bleibt offen, wie kommt man der Ursache auf die Schliche, warum der Wert per setreading brav in der GUI dargestellt wird aber nicht geloggt wird obwohl die umliegenden Parameter passen

[betateilchen]

obwohl die umliegenden Parameter passen

genau das wage ich zu bezweifeln.

[MadMax-FHEM]

der Wert per setreading brav in der GUI dargestellt wird aber nicht geloggt wird obwohl die umliegenden Parameter passen

Da glaube ich nicht, dass die "umliegenden Parameter" passen.

Weil wie schon geschrieben (und nutze ich auch mit FileLog, ist aber egal): setreading erzeugt einen Event (siehst du ja auch und die "Oberfläche ändert sich ja"   ) und JEDER Event kann geloggt werden, sofern eben "alles beim loggenden Device" bzw. "für das Loggen" passt/richtig eingestellt ist.

Daher ja der "zentrale" Ansatz von betateilchen...
...weil: eine Stelle wo zu suchen ist...

Bei dir: keine Ahnung an wievielen Stellen du da beeinflussende Settings hast...

...einige wurden ja bereits genannt...

EDIT: gut, die scheinst du zu verstehen und sollten/könnten passen...

Gruß, Joachim