Nachkommastellen beim event-aggregator begrenzen?

Begonnen von macmattes, 30 April 2015, 11:46:23

Vorheriges Thema - Nächstes Thema

macmattes

versuche mich gerade am event-aggregator, und stelle mit erschrecken fest, dass ich 11 nachkommastellen geloggt bekomme.
kann man dass irgendwo begrenzen?

mein Atributes sieht so aus
event-aggregator volume_measured:900:linear:mean

das Reading entsprechned so:
volume_measured  1753.03757484938

ich will jetzt nicht unbedingt ein zusätzliches Userreading aufmachen

Dr. Boris Neubert

Hallo macmattes,

wozu möchtest Du die Werte mit geringerer Stellenanzahl loggen?

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

macmattes

habe mir mit Ethersex eine Tanklevelmessung gebaut und die schwankt ziemlich, daher dachte ich, wäre sinnvoll die Werte über eine gewisse zeit zu mitteln, hab für mittelwerte immer average bzw in letzter zeit statistics benutzt, bin dann aber auf den event-aggregator gestossen. funktioniert auch soweit, bis eben auf die vielen Stellen nach dem Komma.
beim richtigen überlegen hat es sich jetzt eigentlich erledigt, sieht nur komisch aus mit so vielen Stellen nach dem Komma im Log.
im FHEMWEB ist es eigentlich nur ein rein optisches problem wenn ich mir den Wert als stateFormat anzeigen lasse, dann kommen auch die ganzen kommastellen, dachte ich könnte es umgehen Stateformat zu formatieren oder ein zusätzliches userreading anzulegen.
Ich nehme aber mal an event-aggregator benutzt die vielen stellen zum weiterrechnen, richtig?
sorry musste warscheinlich nur mal nachfragen, damit ich selber nachdenke :-)

Dr. Boris Neubert

Hallo,

das hinter event-aggregator liegende Modul TimeSeries.pm weiß ja nicht, was der Anwender will, und rechnet daher natürlich immer mit maximaler Fließkommagenauigkeit.

Für die Anzeige kannst Du stateFormat verwenden.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

vbs

Ich finde das auch etwas unschön, dort diese maximale Anzahl an Nachkommastellen zu sehen. Außerdem vermute ich, dass in den meisten Anwendungsfällen die zugrunde liegenden Daten gar nicht so genau sind, dass diese Anzahl an Nachkommastellen gerechtfertigt wäre (bzw. für den Nutzer einfach keinen Mehrwert bietet). Suggeriert dann mMn nur eine Genauigkeit, die nicht gegeben ist.
Bin natürlich voll bei dir, dass das darunter liegende TimeSeries-Modul von all dem nichts wissen muss und einfach mathematisch beste Werte ermitteln sollte.

Ich hab mir erstmal damit beholfen, dass ich Zeile 3830 der fhem.pl wie folgt geändert habe, so dass auf zwei Nachkommastellen gerundet wird:
$value = eval sprintf("%.2f", $ts->{$function}) if($changed);
(Mag dafür noch schönere Wege geben)

vbs

Darf ich einen Patch vorschlagen zu dem Thema? Man kann optional dem Attribut einen fünften Parameter mitgeben, der die Anzahl der Nachkommastellen angibt, die man haben möchte. Beispiel:
airQuality:120:linear:mean:2

Wenn man nichts angibt, bleibt alles wie vorher.

Markus Bloch

Finde ich einen guten Vorschlag. Mich stören diese ellenlangen Nachkommastellen auch schon seit längerem.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Dr. Boris Neubert

Hallo,

ich habe immer noch nicht verstanden, welches Problem mit der Begrenzung der Nachkommastellen gelöst werden soll. Wer kann es mir bitte erklären?

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

vbs

Ich fürchte, ich kann da nicht mehr zu sagen als weiter oben schon schon geschrieben wurde: ich würde es nicht als "Problem" bezeichnen, aber ich finde es mindestens unschön. Ich denke, dass es einfach keinen Mehrwert hat, diese vielen Nachkommastellen zu sehen. Impliziert ja auch, dass die Eingangsdaten eine dermaßen hohe Genauigkeit haben, dass diese Anzahl an Nachkommastellen überhaupt gerechtfertigt wäre.

Mit dem Patch hätte der User einfach die freie Wahl, wieviel er sehen möchte. D.h. es geht ja niemandem etwas verloren durch die Option.

Markus Bloch

@Boris: Ich würde es nicht als technisches Problem darstellen sondern eher als "optisch kontraproduktiv". Wenn ich Werte mit 1 Nachkommastelle in den event-aggregator laufen lasse, dann ist es ja klar, dass der Mittelwert höchstens 2-3 Nachkommastellen brauch und nicht 11. Wenn ich die Werte so direkt als STATE in der Raumübersicht anzeige, ist immer alles verschoben weil dort wieder solche monströssen Nachkommastellen aus dem Gebüsch gesprungen sind. Ich persönlich brauche die nicht und finde daher den Patch von vbs optimal, so kann jeder seine eigenen Vorstellungen setzen und wir müssen uns nicht streiten ob man jetzt 2 oder 3 Nachkommastellen dafür nehmen müsste.

Ich hatte dir dazu schonmal ein Ticket im Bugzilla aufgemacht: https://git.fhem.de/bugzilla/show_bug.cgi?id=10 . Dein Vorschlag war ein globales readingsFormat Attribut, was ich aber für den falschen Weg halte (da wir schon genug solcher globalen Attribute haben).

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Dr. Boris Neubert

Hallo,

es geht also um die Anzeige. Es ist richtig, dass es nicht sinnvoll ist, mehr Nachkommastellen anzuzeigen, als der ursprüngliche Messwert an Genauigkeit hat.

Meiner Meinung nach ist die Vorgabe einer Nachkommastellenzahl beim event-aggregator eine Funktionalität, die da nicht so recht hingehört.

Das Argument, dass ein weiteres Attribut dafür auch eine sehr spezielle Lösung ist, teile ich mittlerweile auch.

Richtig wäre m.E. der in dem Ticket gemachte Vorschlag, dies über Metainformationen am Reading zu lösen. Seit einer gefühlten Ewigkeit habe ich die RTypes.pm als leere Hülle für so was im fhem.pl inkludiert. Leider hat die Zeit und der Mut bisher nicht gereicht, daraus etwas entstehen zu lassen, was zukunftsfähig ist.

Gedacht war hier, hierarchisch Metainformationen zu Readings abzulegen. Der Benutzer würde dann u.a. konfigurieren können, dass das Reading namens foo am Gerät bar im Format %4.1f ausgegeben wird. Muss da nochmal drüber nachdenken. Vielleicht fällt mir ein einfacher Weg ein, dass schlicht aber erweiterbar zu implementieren.

Viele Grüße
Boris



Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Markus Bloch

Hallo Boris,

auf deine Implementation der RTypes.pm bin ich auch schon die ganze Zeit gespannt, da man hier eine tatsächliche Entkoppelung von Modulen, Frontends und den Nutzerwünschen schafft, sowie einen festen Platz für Einheiten (°C, %, ...) inkl. Umrechnungen.

Momentan gibt es aber eine solche strikte Trennung nicht. Ich gebe dir Recht, dass die Angabe der Nachkommastellen direkt im event-aggregator reinweg von der eigentlichen Funktion dort nicht hingehört. Leider hat der User aber aktuell nur begrenzt einfache Möglichkeiten die eigenen Wünsche der Nachkommastellen abzubilden. Dies führt in den meisten Fällen zu Perl-Ausdrücken, die nicht unbedingt jedem User sofort geläufig sind. Man kann jetzt viel mit stateFormat oder userReadings rumwurschteln um sich eigene Formatierungen zu bauen. Letzten Endes bleibt der Zahlenwert aber unverändert (z.B. bei FileLog).

Aufgrund der aktuellen Möglichkeiten finde ich einen optionalen Zusatzparameter bei event-aggregator für die Nachkommastellen als die einfachste Möglichkeit, sowohl für den User, als auch für Developer, um diesem Wunsch gerecht zu werden.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

JoeALLb

Wie sieht es hier aus? Ich finde den Patch äußerst sinnvoll und nützlich! Überigens nicht nur zur Anzeige, sondern auch zum Ausdünnen der Werte. Mit so vielen Nachkommastellen gibt es einfach mehr scheinbar unterschiedliche Werte, die gerundet die selben wären! Von daher fürde ich die Einbindung davon stakr befürworten!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Dr. Boris Neubert

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

JoeALLb

werde das weiter verfolgen,  bis sich da aber was tut,  nutze ich den Patch weiter. Würde daher dennoch seine Übernahme vorschlagen, da er an der Kompatibilität nicht rüttelt.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270