DbLog speichert falsche Einheit

[ocin4]

Hallo

ich hab nochwas im DbLog gefunden, was nicht so ist, wie es sein soll. Heute kam ein neuer Temperatur-Sensor von Pearl. Er wird via MQTT2 ausgelesen und hat folgende readingList:

Code Auswählen Erweitern


sensors/rtl_433/P91/inFactory-TH/C1/time:.* time
sensors/rtl_433/P91/inFactory-TH/C1/protocol:.* protocol
sensors/rtl_433/P91/inFactory-TH/C1/id:.* id
sensors/rtl_433/P91/inFactory-TH/C1/channel:.* channel
sensors/rtl_433/P91/inFactory-TH/C1/battery_ok:.* battery_ok
sensors/rtl_433/P91/inFactory-TH/C1/temperature_F:.* temperature_F
sensors/rtl_433/P91/inFactory-TH/C1/humidity:.* humidity
sensors/rtl_433/P91/inFactory-TH/C1/mic:.* mic

Also leider nur die Temperatur in Fahrenheit (die Display-Anzeige zeigt °C). Ich hab mir jetzt ein userReading angelegt, welches die Temperatur in Celsius umrechnet. Einfach mal so hab ich die Fahrenheit-Temperatur zusätzlich trotzdem mit in die DB loggen lassen. Dabei wird leider die UNIT falsch mitgeloggt:

Code Auswählen Erweitern


|TIMESTAMP          |DEVICE               |TYPE        |EVENT              |READING      |VALUE|UNIT|
|-------------------|---------------------|------------|-------------------|-------------|-----|----|
|2021-12-30 23:25:26|MQTT2_inFactory_TH_C1|MQTT2_DEVICE|temperature_F: 70.1|temperature_F|70.1 |°C  |

Ich kenn das DbLog-Modul nicht genau genug, um zu wissen, wo es die UNIT beim Aufsplitten herholt. Ich brauch die °F nicht, werd sie wohl wieder aus dem DbLog entfernen, aber eventuell würde jemand anderes gern diese Temperatur mit der richtigen Einheit mitgeloggt haben wollen.

VG, ocin4

[DS_Starter]

Es gibt im DbLog eine globale Behandlung für Readings die mit "temperature" bzw. "humidity" beginnen.
Solche Readings bekommen automatisch °C bzw. % als Einheit zugewiesen.
Leider weiß ich nicht aus welcher Anforderung heraus es so gestaltet wurde.
Aber ich stimme zu, dass dieses Verfahren zumindest für "temperature" nicht  in jedem Fall passt, weil die Einheit nicht immer °C ist.

Ich werde diese Behandlung für "temperature" und "humidity" abschalten und die Version einchecken.
Falls es an anderer Stelle wieder stört, muß ich mir etwas anderes überlegen.

Grüße und einen guten Rutsch,
Heiko

[erwin]

Ich werde diese Behandlung für "temperature" und "humidity" abschalten und die Version einchecken.

Da bin ich dagegen, das ist eine Änderung, die potentiell sehr viele User betrifft!
Für solche (spezial) Fälle gibts das attribut: DbLogValueFn
l.g.erwin

[DS_Starter]

Hallo erwin,

hast du ein Beispiel wo eine Abschaltung stört ?
Wenn ein Event die Einheit mitbringt wird sie natürlich entsprechend gesplittet.
Aber DbLogValueFn ist tatsächlich eine Alternative.

LG,
Heiko

[erwin]

Naja,
in den readings (bzw. in den events die mittels readingsUpdate erzeugt werden) ist (wenn man den fhem-specs folgt) nie eine Unit enthalten.... (im Unterscheid zu state!)  Darum hat man sich in der Urzeit von DBLog vermutlich dazu entschieden, Units per keyword (=readingname) in DbLog zu setzten.
Das kann dann noch in den device-Modulen überschrieben werden...
Diese Option sehe ich bei MQTT2-MODUL als nicht sinnvoll an, weil das MQTT2-Modul zu generisch ist.
Ich sehe etliche Möglichkeiten:
1) Das reading anders nennen: z.b: F_temperatur... - eine leichte Übung im MQTT2 device
2) DbLogValueFn: da könnte man die Umrechnung zusätzlich zur richtigen Unit gleich mit erledigen...
3) Umrechnug in °C mittels userreading..
4) Den Hersteller von dem Ding auf den Unsinn hinweisen... Du versuchst einen Produkt-Fehler mit FHEM zu reparieren.
l.g. erwin
PS: ich will eigentlich nur vermeiden, dass wegen eines "spezial-falles" alle anderen dblog-user was umstellen müssen....

[DS_Starter]

Dieses Eventsplitting in DbLog ist m.M. nach eh so eine zwiespältige Sache.
Ich dränge immer wieder darauf, dass Modulentwickler die Funktion  https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DbLog_split einbauen. Aber leider ist die Unterstützung da nicht so wie ich es mir wünsche.

Der angesprochene Fall hat eigentlich nichts mit einem Eventsplitting zu tun, sondern ist eine Zwangszuweisung einer Einheit.
Das widerspricht de facto der Idee des Eventsplitting.

Natürlich möchte ich auch für andere User so wenig wie möglich Aufwand damit verursachen. Ich bin mir allerdings unsicher
ob die Abschaltung der Zwangszuweisung einer Einheit irgendwo Aufwand verursacht, denn die Einheit wird ja letztendlich nur abgesplittet im Feld UNIT mitgeführt was im Allgemeinen keinen weiteren Nutzen hat.

Filelog hat solche Mechanismen überhaupt nicht. Da wird geloggt was als Event kommt und fertig. Naturgemäß braucht Filelog natürlich auch kein Splitting.

Danke fürs mitdenken erwin. 

LG

[erwin]

Gebe dir absolut recht, das eventsplitting gehört NICHT ins DBLog Modul!
Die Units diskussion, die gabs schon vor etlichen Jahren: readingsUpdate mit um UNIT erweiterter Struktur...., ist damals (nach meiner Erinnerung) im Sand verlaufen...
Ad Units Zuweisung im Device Modul: Absolut richtig, könnte man (wenn man nur wollte) über die device-modul spezifische DBLogSplit function realisieren.
Allerdings: Das MQTT2 device ist so generisch, das würde es noch zusätzlich Mechanismen brauchen, weil aus dem Topic auf eine Unit zu schließen ist jedenfalls sehr gewagt... In diesem Fall finde ich das Attr: DBLogSplitFN im device (NICHT im Modul) absolut angebracht!

Ad Zwangszuweisung: Haben wir heute schon - auch im DbLogModul.... und natürlich geht's nur um die Unit in der datenbank (und die Abfragen daraus)- weil überall anders gibts das sowieso nicht!
Allerdings sind das nur zwei generische Einträge: temperature & humidity, alle anderen Modul-spezifischen Zuweisungen gehören m.M. sowieso in das jeweilige device-Modul. Beispiele: Onewire, ZWAVE,WMULTI, FS20, FHT, usw....
Die Geschichte ist über Jahre gewachsen und das ist Teil des Problems... DBLog kam später als Filelog und etliche der genannten device-module...

noch was ist mir eingefallen: das konkrete Problem lässt sich auch mit MQTT2 Readinglist lösen, in etwa so:

Code Auswählen Erweitern

attr <device> readingList topic/temperature_F:.* {F2C($EVENT)} ..ungetestet, F2C=subroutine ...rechnet F in C um und nennt es temperatur...
l.-g. erwin

[DS_Starter]

Stimmt, diese Diskussion um Units und das Splitting ist schon sehr alt und kontrovers geführt.
Die Idee (so war es sicherlich zu verstehen) mit einer Device spezifischen DBLogSplitFN, ähnlich der von mir schon impementierten DbLogValueFn, finde ich keine schlechte Idee.
Der User muß sich allerdings ein bisschen mit Perl befassen. Ich werde mir das nach den Feiertagen mal durch den Kopf gehen lassen.

Ad Zwangszuweisung: Haben wir heute schon - auch im DbLogModul.... und natürlich geht's nur um die Unit in der datenbank (und die Abfragen daraus)- weil überall anders gibts das sowieso nicht!
Allerdings sind das nur zwei generische Einträge: temperature & humidity, alle anderen Modul-spezifischen Zuweisungen gehören m.M. sowieso in das jeweilige device-Modul. Beispiele: Onewire, ZWAVE,WMULTI, FS20, FHT, usw....

Genau. Diese "Zwangsbeglückung" von  temperature & humidity mit einer Unit finde wie gesagt nicht so glücklich weil sie der ursprünglichen Idee des Eventsplitting nicht entspricht und im Fall von  temperature sogar physikalisch falsch ist. Gibt ja auch noch Kelvin. 

Ich habe jetzt erstmal die Zwangszuweisung für temperature (°C) entfernt und eingecheckt.
Mal sehen wie es angenommen wird.

Wünsche dir/euch einen schönen Abend,
Heiko