[erledigt] Komisches Verhalten beim Subtrahieren von Werten

Begonnen von ronny332, 30 September 2015, 19:26:18

Vorheriges Thema - Nächstes Thema

ronny332

Hallo zusammen,

seit über einem Jahr nutze ich einen S0 Zähler, welcher via DbLog seine Daten aufzeichnet. Alles wird grafisch aufbereitet, bis gestern zu einem Update auch alles ok (ich hatte davor schon einige Wochen keine Updates mehr gemacht).

Seit dem Update "rechnet" FHEM "falsch".

Die Titelleiste fülle ich hiermit:


sprintf("min %.2f kW, max %.2f kW, letzter %.2f kW, summe %.2f kWh", 0.0 + $data{min1} / 1000, 0.0 + $data{max1} / 1000.0, 0.0 + $data{currval1} / 1000.0, 0.0 + ($data{max2} - $data{min2}) / 1000)


Falsch berechnet wird der letzte Wert bestehend aus 0.0 + ($data{max2} - $data{min2}) / 1000.

"data{min2}" sollte das Minimum des Tages sein, geholt wird aber "0", also den ersten Wert überhaupt. In der Vorschau der Werte ist alles korrekt, der erste Wert ist der erste des jeweiligen Tages.

Andere Graphen, welche nach dem gleichen Schema arbeiten sind weiterhin in Ordnung, so z.B. mein Wasserzähler.

Hat jemand eine Idee woher dieses Problem plötzlich kommen kann?

Vielen Dank!

Nachtrag:

2015.09.30 19:29:14 1: PERL WARNING: Argument "undef" isn't numeric in subtraction (-) at (eval 28769) line 1.

Der Eintrag im Log liess mich ein nicht vorhandes "$data{min2}" finden. Nun bin ich vollkommen verwirrt. Da der Graph die richtigen Daten hat, müsste hier doch ein Fehler intern bei der Variablen Erzeugung geschehen sein?
"$data{min1}" ist gesetzt und gültig.

Daten für den Graphen sind gekürzt für heute:


#bw_sd0:power:::
2015-09-30_00:01:58 3834260
2015-09-30_00:06:57 3834304
2015-09-30_00:11:57 3834348
2015-09-30_00:16:57 3834394
2015-09-30_00:21:57 3834435
2015-09-30_00:26:58 3834474
2015-09-30_00:31:58 3834513
...
2015-09-30_18:42:11 3844524
2015-09-30_18:47:11 3844567
2015-09-30_18:52:11 3844606
2015-09-30_18:57:11 3844652
2015-09-30_19:02:11 3844696
2015-09-30_19:07:11 3844743
2015-09-30_19:12:11 3844794
2015-09-30_19:17:11 3844845
2015-09-30_19:22:11 3844901
2015-09-30_19:27:11 3844945


"$data{min2}" müsste damit 3834260 sein und "$data{max2}" 3844945. Letzteres (3844945) ist auch der Fall, 3834260 ist allerdings "undef".
"$data{currval2} ist auch richtig gesetzt, 3844945 genauso wie "$data{max2}".
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

ronny332

Das Problem scheint in 93_DbLog.pm zu finden zu sein.

Der Autor war wohl der Meinung, dass ein Wert > 999999 nicht existiert (?). Kleiner als 999999 wird auch nicht verwendet.

Meine Werte sind von einem Counter, welcher in Watt Stunden arbeitet, allerdings ist er schon seit Monaten über dieser Schwelle, das Modul selber hat als letztes am 28.7. eine Änderung laut Datei Datum erhalten.

Angehangen an diese Antwort habe ich ein funktionierendes Patch, welches die Werte zumindest auf 99999999 und -99999999 vergrößert. In Perl kenne ich den Wert nicht, in anderen Sprachen würde ich es aber eher mit einer Konstanten wie "MAX_INT" oder "MIN_INT" lösen.
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

ronny332

Da scheinbar wieder leben in die DBLog Entwicklung kommt:

kann mir jemand sagen wen ich anschreiben muss, damit mein Patch, oder eine angepasste Version davon, in den aktuellen Code übernommen wird?

Eine Min/Max Berechnung bis maximal +/- 999.999 ist viel zu wenig, die Änderungen im Code sind recht gering.

Ich laufe jetzt auf das Problem, dass ich bei jedem Update gucken muss ob dblog Updates bekommen hat, um dann per Hand erneut zu patchen.
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

rapster

Du kannst hier nachschauen wer der jeweilige Modul-Maintainer ist und in welchem Foren Bereich er mitliest

=> http://fhem.de/MAINTAINER.txt

Zu DbLog am besten im Bereich "Automatisierung" posten. Oder du schickst dem Maintainer einen Link per PM auf diesen Thread.

P.S. => http://forum.fhem.de/index.php/topic,13092.0.html

Gruß
  Claudiu

ronny332

... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.