Mit dem Modul als solchem bin ich sehr zufrieden, aber bei der Umstellung von FileLog auf DbLog bin ich in
dasselbe Messer gelaufen wie andere User vorher schon: https://forum.fhem.de/index.php/topic,51023.0.html
Ob ich in dieser Ecke richtig bin, weiss ich nicht, fange aber hier an, weil es mit dem Modul nun mal beginnt.
Meine FileLog-Definition war:
defmod FileLog_weather_wstk FileLog ./log/weather_wstk-%Y-%m.log weather_wstk:(wind_s|wind_d|wind_ch|temperature|humidity|dewpoint|pressure).*
und hat funktioniert wie erwartet.
Bei DbLog habe ich Aehnliches versucht
attr weather_wstk DbLogInclude temperature,dewpoint,wind_speed,wind_chill,wind_direction,humidity,pressure
mit dem Erfolg, dass ich fuer wind_direction nun zwei Eintraege gleichen Reading-Namens mit unterschiedlichen Inhalten erhalte:
+---------------------+--------------+---------+----------------------------------+----------------+-------+------------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
+---------------------+--------------+---------+----------------------------------+----------------+-------+------------+
| 2018-04-01 19:12:19 | weather_wstk | WEATHER | wind_direction: 320 | wind_direction | 320 | |
| 2018-04-01 19:12:19 | weather_wstk | WEATHER | wind_condition: Wind: NW 18 km/h | wind_direction | NW | NW 18 km/h |
Die mit diesen Daten erzeugten Plots sehen entsprechend aus.
Im Weather-Modul sehen die Readings gut und richtig aus, allein bei der Uebergabe an DbLog wechselt der Reading-Name
wind_condition unvermittelt zu wind_direction:
2018.04.01 19:10:01.970 5: DbLog bath45DbLog -> processing event Timestamp: 2018-04-01 19:09:49, Device: weather_wstk, Type: WEATHER, Event: wind_direction: 320, Reading: wind_direction, Value: 320, Unit:
2018.04.01 19:10:01.970 5: DbLog bath45DbLog -> processing event Timestamp: 2018-04-01 19:09:49, Device: weather_wstk, Type: WEATHER, Event: wind_condition: Wind: NW 18 km/h, Reading: wind_direction, Value: NW, Unit: NW 18 km/h.
Wenn hier niemand eine Idee hat, verschiebe ich das Thema versuchsweise nach Automatisierung.
Gruss Helmut
Ich habe mir das Ganze in 93_DbLog.pm mal genauer angesehen und war ueberrascht, wie detailliert hier die
einzelnen Module beruecksichtigt werden.
In der Abteilung "Weather" habe ich die problematische Stelle gefunden.
# Weather
elsif($type eq "WEATHER") {
if($event =~ m(^wind_condition)) {
@parts= split(/ /,$event); # extract wind direction from event
if(defined $parts[0]) {
$reading = "wind_direction";
$value= $parts[2];
}
}
elsif($reading eq "wind_chill") { $unit= "°C"; }
elsif($reading eq "wind_direction") { $unit= ""; }
elsif($reading =~ m(^wind)) { $unit= "km/h"; } # wind, wind_speed
elsif($reading =~ m(^temperature)) { $unit= "°C"; } # wenn reading mit temperature beginnt
elsif($reading =~ m(^humidity)) { $unit= "%"; }
elsif($reading =~ m(^pressure)) { $unit= "hPa"; }
elsif($reading =~ m(^pressure_trend)) { $unit= ""; }
}
Kann sich noch jemand daran erinnern, warum aus dem Reading "wind_condition" die Windrichtung
extrahiert und das Ergebnis (sicher gut gemeint) dann "wind_direction" genannt wurde? Lieferte das
Weather-Modul zu diesem Zeitpunkt die Richtung noch nicht separat ab?
Wie auch immer - ich schlage vor, diese Sonderbehandlung zu entfernen oder wenigstens das neue
Reading anders zu nennen.
Gruss Helmut
Hallo helmut,
ja, hier bist du (zum Teil) richtig. ;)
Woher, bzw. aus welcher Zeit diese Behandlung stammt kann ich dir leider nicht sagen.
Dieses ganze Event-Parsing in Dblog wird wahrscheinlich immer eine Notlösung bleiben.
Bei jeder Gelegenheit, so auch hier, versuche ich immer darauf Einfluss zu nehmen dass die jeweiligen Modulautoren doch besser die Funktion DbLog_splitFn in ihre Module einbauen -> https://wiki.fhem.de/wiki/DbLog#Integration_von_DBLog_in_eigene_Module.
dann wäre die ganze Behandlung im DbLog obsolet und es könnte so auch auf eventuelle Änderungen im Modul adäquat reagiert werden ohne jedesmal DbLog zu ändern.
Es wäre also sehr schön wenn das Weather-Modul dies integrieren würde.
Wenn ich diese angesprochene Passage nun entferne, kommt mit hoher Wahrscheinlichkeit ein anderer Nutzer der genau diese Änderung dann nicht so gutheißen wird.
Wenn sich noch mehr Weather-Nutzer mit DbLog diesem Änderungswunsch anschließen habe ich absolut nichts dagegen das zu ändern. Besser wäre, wie schon beschrieben, die generelle Ablösung durch DbLog_splitFn.
Vielleicht kannst du noch mehr Meinungen dazu einsammeln.
LG,
Heiko
Hallo Heiko,
Deine Argumente kann ich nachvollziehen. Folgerichtig habe ich einen neuen Thread im Bereich "Unterstuetzende Dienste/
Wettermodule" geoeffnet. https://forum.fhem.de/index.php/topic,86528.msg789512.html#msg789512
Gruss Helmut
Hallo,
man muss doch nur die Verarbeitung in 93_DBLog wie folgt ändern:
# Weather
elsif($type eq "WEATHER") {
if($reading eq "wind_condition") { $unit= ""; }
elsif($reading eq "wind_chill") { $unit= "°C"; }
elsif($reading eq "wind_direction") { $unit= ""; }
elsif($reading =~ m(^wind)) { $unit= "km/h"; } # wind, wind_speed
elsif($reading =~ m(^temperature)) { $unit= "°C"; } # wenn reading mit temperature beginnt
elsif($reading =~ m(^humidity)) { $unit= "%"; }
elsif($reading =~ m(^pressure)) { $unit= "hPa"; }
elsif($reading =~ m(^pressure_trend)) { $unit= ""; }
}
Viele Grüße
Boris
Hallo Boris,
Zitatman muss doch nur die Verarbeitung in 93_DBLog wie folgt ändern:
Das ist schon klar ;)
Nur aus irgendeinem Grund wurde es ja in einer mir nicht bekannten Vergangenheit mal so eingebaut.
Weißt du aus welchem Grund ?
Außerdem würde ich persönlich mir wünschen wenn die spezifische Behandlung der Events in den Quelldevices vorgenommen werden würde
damit nicht jedesmal, wenn in den Quelldevices etwas geändert wird, der Eventparser im DbLog angepasst werden müsste. (DbLog_splitFn)
LG,
Heiko