LaCrosse: resolution Wert falsch

[dododididada]

Ich nutze das LaCrosse Modul, um Temperatur und Luftfeuchtigkeit zu messen.

Ich wollte die Einträge etwas reduzieren, indem ich die Auflösung reduziere. Dazu gibt es in dem Modul "resolution". Allerdings scheint das nicht so zu funktionieren, wie erwartet. Die Zeile im Modul lautet:

Code Auswählen Erweitern

$temperature = int($temperature * 10 / $resolution + 0.5) * $resolution / 10;

Wie man sehen kann verfälscht diese Formel den Wert teilweise sehr deutlich, je nach $resolution.
Vielleicht habe ich die Option "resolution" auch nicht richtig verstanden.

Nach meinem Dafürhalten müsste die Zeile eher etwa so aussehen, damit man eine Auflösung nach dem Muster x / 10 erreicht, ohne den Wert zu verfälschen:

Code Auswählen Erweitern

use Math::Round qw/nearest/;
$resolution = $resolution / 10;
$temperature = nearest($resolution, $temperature));


Ich habe die Zeilen zu dem Modul (Beschreibung) kompatibel gemacht. "resolution" erwartet nach Angaben der Hilfe einen Wert von (0) 1 - 10.

Gleiches müsste man bei "humidity und "doDewpoint" einfügen.

An wen müsste ich mich wenden, wenn ich einen Patch hätte?

[justme1968]

maintainer ist inzwischen HCS. siehe MAINTAINER file.

bei welchen werten wird etwas verfälscht?  ich bekomme bei allen getesteten werden die gleiche ausgabe mit beiden varianten.

inzwischen gibt es in fhem auch einen optionalen threshold bei event-on-change-reading. vielleicht ist das eher das was du suchst?

gruss
  andre

[dododididada]

Vielen Dank.

Ich hatte Tests mit real Data gemacht und die Werte weichten ab. Nach durchrechnen mit ausgedachten Werten zeigt, dass es doch richtig ist.

Allerdings sind die Rundungen nicht immer 100% Korrekt. Z.B. bei -4,5 Grad kommt bei Resolution 6 -4,3(5) und nicht -4,6. Das ist zu verkraften.
Wenn man aber -4,6 Grad und resolution 10 nimmt, kommt -4,1 raus, was nicht sein sollte, weil ein ganzzahliger Wert gewünscht ist.

Ich werde mich an den Maintainer wenden.

Bezüglich des Reduzierens der Einträge funktioniert  Dein Vorschlag leider nicht, denn die Temperatur ändert sich manchmal innerhalb einer Minute  mehrmals um 0,1 Werte. Der Wert zittert quasi zwischen zwei Kommawerten.

Mein eigentliches Ziel ist ein Filelog mit den Rohwerten des Sensors zu füllen und das DBLog mit weniger und ggf. angepassten Daten zu füllen. Leider kann man bei DBLog nur identische Werte verhindern, was aber hier nicht sehr hilft (siehe oben). Alle anderen Möglichkeiten (Modul und FHEM generell) beeinflussen aber dann auch das Filelog, was ich aber eigentlich nicht haben möchte.

[justme1968]

das stimmt. negative werte werden nach oben gerundet und nicht wie die positiven zum nächst liegenden.

dann gibt doch als threshold bei event-on-change 0.2 an.

alle log senken arbeiten auf dem gleichen event. d.h. wenn du unterschiedlich loggen willst musst du unterschiedliche events erzeugen. das geht z.b. in dem du die originale lässt wie sie sind und mit einem userReading z.b. etwas gemitteltes zusätzlich erzeugst. z.b. per event-aggregator oder mit dem gleitenden mittelwert aus dem wiki.

ins file log loggst du dann die originale und in die db die anderen.

[dododididada]

Vielen Dank für den Hinweis.

Ich arbeite jetzt mit event-on-change. Das reicht mir aus. So schreibe ich jede Minute ins FileLog und DbLog und kann dann aus dem DBLog die Werte älter als X ausdünnen und habe zur Not noch die detaillierten Werte als "Backup".

[HCS]

Jetzt fällt mir wieder ein, dass ich mich vor zwei Jahren schon mal gewundert hatte, dass negative Temperaturen (bei mir) um 0.1 °C falsch sind.
Das hatte ich irgendwie völlig verdrängt.
Und der Grund dafür steht wohl oben.

dododididada hat sich schon per PM gemeldet.
Patch wäre prima und nehme ich gerne entgegen.

[HCS]

Das mit dem Patch wurde dann wohl doch nichts, dann mache ich mich mal an die Sache.

@justme1968: Brauche mal einen Expertenrat:
Math::Round ist doch kein perl core modul und somit u.U. nicht auf allen FHEM-Servern aktuell vorhanden und ich würde damit eventuell einige bestehenden Installationen brechen, oder?

[justme1968]

ich weiss nicht ob und ab welcher perl version Math::round standard ist. habe auf die schnelle auch nichts dazu gefunden.

aber ich habe eine warnung gefunden das ab perl 5.22 das POSIX modul auch eine round routine exportiert. d.h. hier könnte es auch konflikte geben.

statt Math::round zu verwenden kann man die bestehende formel auch so erweitern das bei zahlen < 0 -0.5 statt +0.5 verwendet wird. dann sollte es auch passen.

gruss
  andre

[HCS]

ich weiss nicht ob und ab welcher perl version Math::round standard ist. habe auf die schnelle auch nichts dazu gefunden.

aber ich habe eine warnung gefunden das ab perl 5.22 das POSIX modul auch eine round routine exportiert. d.h. hier könnte es auch konflikte geben.

Ja, ich lasse sie lieber raus.

statt Math::round zu verwenden kann man die bestehende formel auch so erweitern das bei zahlen < 0 -0.5 statt +0.5 verwendet wird. dann sollte es auch passen.

Ja.

Ich überlege gerade, was man eigentlich erwartet, was bei z.B. Resolution 6 passiert.

Allerdings sind die Rundungen nicht immer 100% Korrekt. Z.B. bei -4,5 Grad kommt bei Resolution 6 -4,3(5) und nicht -4,6. Das ist zu verkraften.

Mit der "-0.5 bei kleiner Null" angepassten Version kommt dann bei -4.5° und Resolution 6 als Ergebnis -4.8° raus und nicht wie oben angemerkt -4.6. -4.8 ist meiner Meinung nach aber auch richtig und übrigens auch das, was nearest liefert.

Wenn man aber -4,6 Grad und resolution 10 nimmt, kommt -4,1 raus, was nicht sein sollte, weil ein ganzzahliger Wert gewünscht ist

Bei mir kommt da -4 raus, was aber auch falsch ist, -5 wäre richtig.

Ich glaube auch, dass mit der hier:

Code Auswählen Erweitern

int($temperature * 10 / $resolution + ($temperature < 0 ? -0.5 : 0.5)) * $resolution / 10)
es in allen Fällen passt.

[dododididada]

Hi,

Entschuldigung für die Verzögerung. Zum einen bin ich arbeitstechnisch sehr eingespannt, zum anderen habe ich keine Nachrichten erhalten, dass hier weiter diskutiert wird.

Als ich meinen Vorschlag machte, hatte ich schon geschaut, ob Math::round schon irgendwo genutzt wird in FHEM. Dem ist so. Es wäre also kein prinzipielles Problem, es auch in diesem Modul einzusetzen. Ich  wollte mich einen dieser Abende nun hinsetzen und einen Patch schreiben, nachdem ich aber hier die letze Nachricht gelesen habe, muss ich fragen, ob das noch notwendig ist, wenn

Ich glaube auch, dass mit der hier:

Code Auswählen Erweitern

int($temperature * 10 / $resolution + ($temperature < 0 ? -0.5 : 0.5)) * $resolution / 10)
es in allen Fällen passt.

das wirklich funktioniert.

Dann würde ich nur noch in den Raum stellen, dass man $resolution auch für den Taupunkt anwenden sollte.

Ich überlege gerade, was man eigentlich erwartet, was bei z.B. Resolution 6 passiert.

Nutzt man 0.6 bei Round oder nearest, so ist das das selbe als wenn man 0.3 schreibt. Gleiches gilt auch für vielfache von 0.2.

[HCS]

Als ich meinen Vorschlag machte, hatte ich schon geschaut, ob Math::round schon irgendwo genutzt wird in FHEM. Dem ist so.

Ja, habe ich auch gesehen, aber manche Modul-Autoren nehmen in Kauf, dass man Perl-Module nachinstallieren muss, was bei einem neuen FHEM-Modul nicht so schlimm ist, aber bei einem Bestehenden das weit über 800 Installationen hat, viele bestehende Anwender völlig unvermittelt treffen könnte. Da will ich lieber nichts riskieren.

Ich  wollte mich einen dieser Abende nun hinsetzen und einen Patch schreiben, nachdem ich aber hier die letze Nachricht gelesen habe, muss ich fragen, ob das noch notwendig ist, ...

Nö, danke, ich bin eh schon am Umbauen, brauchst keinen Patch machen.

wenn das wirklich funktioniert.

Ich habe recht umfangreiche Tests mit
int($temperature * 10 / $resolution + ($temperature < 0 ? -0.5 : 0.5)) * $resolution / 10)
und
nearest
gemacht und ein allen Fällen (verschiedene positive und negative Temperaturen und verschiedene resolutions zwischen 1 und 10) bekomme ich die selben Ergebnisse.

Dann würde ich nur noch in den Raum stellen, dass man $resolution auch für den Taupunkt anwenden sollte.

Ja. Werde ich berücksichtigen.
Und temperature2 bei zweikanaligen Sensoren auch.

Und für windGust und windSpeed eventuell auch.

[HCS]

Geändert und eingecheckt.