98_statistics - wie Werte in Darstellung runden?

[fichtennadel]

Hallo,

ich habe für meine Temperatur/Feuchtesensoren ein statistics Device definiert, das funktioniert auch soweit.
Allerdings werden alle berechneten Statistiken mit unsinnig vielen Nachkommastellen angezeigt, das gibt die Messgenauigkeit der Geräte ja gar nicht her:

statTemperatureDay Min: 19.2000000000000 Avg: 21.1836961488110 Max: 26.3233607885763

Da Min/Avg/Max alle in einem Reading stehen, komme ich da mit den bekannten Formatierungsmethoden nicht weiter.

Wie kann man die Werte der Readings in der Darstellung runden?

[vbs]

Vielleicht magst du hier mal gucken:
http://forum.fhem.de/index.php/topic,36771.msg290936.html#msg290936

Ich hatte dort schonmal einen Patch vorgeschlagen. Leider ist seither nichts mehr passiert.

[fichtennadel]

Vielleicht magst du hier mal gucken:
http://forum.fhem.de/index.php/topic,36771.msg290936.html#msg290936

Ja, das ist ein sehr ähnliches Problem bzw. dessen technischer Ursprung.
Wobei ich mir bei einem Reading direkt aus dem event-aggregator noch mit stateFormat helfen konnte, bei den statistics ist es noch eine Ecke umständlicher, da ja drei unterschiedliche Werte noch dazu mit Text in ein reading gepackt wurden. Da passt auch das (verständliche) Argument im verlinkten Thread nicht mehr ganz, da hier ja keine "Formatierung" eines Readings im eigentlichen Sinn mehr möglich ist.

Ich denke in diesem Fall sollte das tatsächlich im 98_statistics Modul implementiert werden, da dort ja auch der Text "Min: <x> Avg: ...." aufgebaut wird und dort wäre mMn die Stelle die Nachkommastellen für die Ausgabe definieren zu können.

Mein zugegeben etwas grober Workaround ist derzeit in 98_statistics.pm in der Funktion statistics_maxDecPlaces() fix den Wert 1 zurückzugeben.

[tupol]

die Anzahl der Dezimalstellen sollten bei statistics-Werten nie mehr sein als bei dem beobachteten Wert.
Mach mal bitte ein resetStatistics für das Gerät und schau, wieviel Dezimalstellen es danach hat.

[fichtennadel]

die Anzahl der Dezimalstellen sollten bei statistics-Werten nie mehr sein als bei dem beobachteten Wert.

Wie vbs schom bemerkt hat, ist die Ursache, dass die beobachteten Werte über den event-aggregator zu Durchschittswerten je 10 Minuten berechnet werden, und von dort stammen auch die vielen Dezimalstellen.

Beim event-aggregator war das Argument "die Anzeige" soll runden, nur an dieser Stelle gibt es eben die statistics als Zwischenschritt, weshalb hier ein "Rundungs attribute" für die Anzeige hilfreich wäre.

[tupol]

Das verstehe ich nicht. Warum kann man nicht einfach den normalen Werte nehmen? Warum hat er so viele Dezimalstellen anstatt sie zu runden?

[fichtennadel]

Das verstehe ich nicht. Warum kann man nicht einfach den normalen Werte nehmen? Warum hat er so viele Dezimalstellen anstatt sie zu runden?

siehe den von vbs verlinkten thread http://forum.fhem.de/index.php/topic,36771.msg290936.html#msg290936

Ein konkretes Beispiel: mein Sensor misst die Temperatur mit einer Nachkommastelle alle 4 Sekunden, da mir aber ein Wert alle 10 Minuten reicht, verwende ich den event-aggregator um den Durchschnitt zu bilden und nur diesen als Reading:
Rohdaten:

Code Auswählen Erweitern

20,1
20,5
20
21,5
20,7
20,6


Temperature Reading des Sensors daher intern: 20,5666666667 , der Durchschnitt über die Werte.

Event-aggregator nimmt die volle Fließkommagenauigkeit und rundet nicht, mit dem Argument, dass das Aufgabge der Anzeige ist. Freundlicherweise rundet fhem schon in der Darstellung, die vielen internen Nachkommastellen fallen nur in den Logs, SVGs, beim longpoll im Browser und eben 98_statistics auf.

Jetzt wollte ich eben auch min/max/avg je Tag/Monat/Jahr und verwende dazu 98_statistics, das aber die Nachkommastellen des Eingangswertes verwendet, was in diesem Fall aber schon das Ergebnis des event-aggregators ist.

[tupol]

Es macht meines Erachtens keinen Sinn, auch noch dieses Problem über statistics zu lösen. Jeder Wert hat eventuell eine andere Anzahl von Dezimalstellen und die Attribute sind schon jetzt sehr unübersichtlich.
statistics fügt auch keine Dezimalstellen hinzu und täuscht deshalb auch nix vor. Nach Deiner Argumentation ist ja eigentlich schon der Eingangswert falsch.
Falls Du die Werte tatsächlich gerundet brauchst, würde ich vorschlagen, den Orginalwert für statistics zu nehmen oder über ein userreading den Eingangswert oder auch den stat-Wert zu runden.

[fichtennadel]

Weder der Eingangs- noch der Ausgangswert sind "falsch", sondern die Darstellung unpraktisch. Ein neues Attribut - zB "decimalPlaces" oder "formatMask" für den sprintf String - fände ich persönlich jetzt nicht so rasend unübersichtlich.