Feature Request: make Efficiency, Irraditiation, Sunrise/Sunset, Frequency Numbers more senseful (round with correct precision)

[DB1BMN]

To quote C. F. Gauss (rumor has it that he didn't say it):

Der Mangel an mathematischer Bildung gibt sich durch nichts so auffallend zu erkennen als durch die maßlose Schärfe im Zahlenrechnen

I propose to shorten some of the values to a sensefull number of decimals.

Examples are:

• Efficiency and Irradiation are printed with 0.01 percent resolution (These are 100 ppm! Hey, has anybody an 3458A at home to confirm this?)
  • A resolution of 1% oder 0.1% should be sufficient
• Calculation of Sunrise/Sunset time is done with 1 Second resolution. Btw. which model is used? - Civil, nautic or astronomic?
  • NOAA NOAA calculates with 1 Minute resolution. I think, we should stick to this.
• The numbers should always be displayed as a fixed point, e.g. there should be no "jump" between 49.99 Hz -> 50 Hz -> 50.01 Hz, but also 50.00 Hz should be printed so.

In general no value shall be better displayed than the resolution of the raw inverter data. Rounding is fine, it is a kind of low-pass-filtering but adding fictive decimal places increases error noise like high-pass-filter.

I think, the resolution for Temperature, Voltages and Powers with 0.1 and currents with 0.01 is fine so far.
Efficiency and Irradiation with 0.1 % as said before.
Frequency with 0.01 should also be fine although Netzfrequenzmessung prints it with 3 decimals (20 ppm). I dont't think the inverter's time base would be that stable.
Power Factor with 0.01 seems also OK in my eyes.

Best Regards, Mark

[Mart-Muc]

Da stimme ich Mark VOLLLLLLL zu! :-) Danke, dass das jemand erwähnt.

Ich habe 3 Jahre die Anfänger Vorlesung Physik an der TUM gehalten und es war jedes Jahr auf Neue schwierig den STudenten ein Gefühl für Zahlen, Stellen, Runden und Nullen beizubringen...

Ein Programm schaut einfach professioneller aus, wenn die Mathematik stimmt!

Nochmal als Wh in deutsch:
a) Genauigkeit:
Kein Ergebnis kann genauer sein als die eingehenden Größen:
Sprich hat die "ungenaueste" Ursprungsgrößen 2 gültige Stellen, hat das Ergebnis 2 gültige Stellen (dabei ist es wurscht, ob oder wo der Dezimalpunkt ist)
((Detail: eine führende 1 zählt nicht))
-> Efficiency and Irradiation bitte kürzen

b) "Füllnullen"
Nullen am Ende einer Zahl geben zwar keine zusätzliche Info über den Wert an sich, aber eine Info über die Genauigkeit eines Wertes.
Deshalb sollen sie IMMER mit ausgegeben werden.
Beispiel Frequenz:
49.99 50 50.01 Hz
Lese ich den Wert 50, bedeutet dies, dass dieser im Bereich 49,5 und 50,5 ist.
Somit muss es richtigerweise auch 50.00 heißen, damit die Genauigkeit auf 49.995 und 50.005 erkennbar ist analog der beiden anderen Beispielwerte

Diese Ausgabe-Formatierungen sollte eigentlich easy implementierbar sein und würden meinen inneren Monk glücklich machen.

Danke, Mart

[lumapu]

bin voll bei euch was die Anzahl der Stellen angeht. Bisher ist es der Einfachheit geschuldet, dass überall die gleiche Anzahl an Stellen ausgegeben wird.
Bin auf jeden Fall bereit das zu Korrigieren und kann das aus meiner Schul- bzw. Studienzeit auch bestätigen:

Kein Ergebnis kann genauer sein als die eingehenden Größen

und

Nullen am Ende einer Zahl geben zwar keine zusätzliche Info über den Wert an sich, aber eine Info über die Genauigkeit eines Wertes

Ich denke man muss das an mehreren Stellen korrigieren: WebIf und API, bei MqTT bin ich mir nicht sicher, wie es der Broker speichert / weiterverarbeitet.

[stefan123t]

@lumapu das ist auch bei den FW Versions Nummer so, selbst die werden trotz Integer mit zwei Nachkommastellen angegeben. Siehe z.B. hier #896 (comment)