Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[romestylez]

@oliverio hat perfekt funktioniert vielen vielen Dank ! Daraus kann ich noch Wege für andere Werte ableiten mega hilfreich :)

[MartinP]

Ich finde ja das Rundungs-Verhalten von toFixed() etwas merkwürdig ...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed

Ist aber wahrscheinlich ein Fehler in der Dokumentation (in Zeile 10 müsste meiner Meinung nach auf 2.6 aufgerundet werden):

const numObj = 12345.6789;

numObj.toFixed(); // '12346'; rounding, no fractional part
numObj.toFixed(1); // '12345.7'; it rounds up
numObj.toFixed(6); // '12345.678900'; additional zeros
(1.23e20).toFixed(2); // '123000000000000000000.00'
(1.23e-10).toFixed(2); // '0.00'
(2.34).toFixed(1); // '2.3'
(2.35).toFixed(1); // '2.4'; it rounds up
(2.55).toFixed(1); // '2.5'
// it rounds down as it can't be represented exactly by a float and the
// closest representable float is lower
(2.449999999999999999).toFixed(1); // '2.5'
// it rounds up as it's less than Number.EPSILON away from 2.45.
// This literal actually encodes the same number value as 2.45

(6.02 * 10 ** 23).toFixed(50); // 6.019999999999999e+23; large numbers still use exponential notation

EDIT: Hab es getestet, funktioniert wie dokumentiert:

javascript.0
	2024-07-05 11:36:40.375	info	script.js.Fritzbox.Tester: Rundung 2.55 auf 1 Nachkommastelle:2.5
javascript.0
	2024-07-05 11:36:40.375	info	script.js.Fritzbox.Tester: Rundung 2.551 auf 1 Nachkommastelle:2.6
javascript.0
	2024-07-05 11:36:40.375	info	script.js.Fritzbox.Tester: Rundung 2.65 auf 1 Nachkommastelle:2.6

Hier noch der Code:

log('Rundung 2.55 auf 1 Nachkommastelle:' + (2.55).toFixed(1));
log('Rundung 2.551 auf 1 Nachkommastelle:' + (2.551).toFixed(1));
log('Rundung 2.65 auf 1 Nachkommastelle:' + (2.65).toFixed(1));

Hier wird wohl symmetrisch und nicht kaufmännisch gerundet:
https://de.wikipedia.org/wiki/Rundung#Symmetrisches_Runden

[OliverIO]

@martinp

dann so

{val:0_userdata.0.watt;parseInt(val)<1000 ? parseInt(val)+" w " : Math.round(parseInt(val)/100)/10+" kW"}

[MartinP]

@oliverio oder so (bei der Einheit Watt gab es auch noch einen Tippfehler)

{val:0_userdata.0.watt;parseInt(val)<1000 ? parseInt(val)+" W" : (parseInt(val+10)/1000).toFixed(1)+" kW"} 

[romestylez]

@martinp damit zeigt er aber nicht 1.X kW an sondern 100.6 etc.

[legro]

@romestylez

Losgelöst von deinem konkreten Beispiel eine eine weitere Lösung, die rein im Browser läuft, wenn die View angezeigt wird. Sie mag dir weitere Ideen liefern, wie du derartige Vorhaben in die Tat umsetzen kannst.

{a:e3oncan.0.Vitocal.tree.0565_EnergyConsumptionDomesticHotWater.CurrentYear;b:e3oncan.0.Vitocal.tree.0548_EnergyConsumptionCentralHeating.CurrentYear;parseFloat((a*1+b*1)/1000).toFixed(1).replace(".", ",")} KWh

Erläuterungen ..

Es wird die Summe für den Energieverbrauch für Warmwasser und Heizen gebildet und angzeigt.

• Zunächst werden diese beiden Werte, welche die verbrauchten Wh enthalten, in den Variablen a und b abgelegt
• Anschließend erfolgt die Addition a * 1 + b * 1 und die Division durch 1000 dividiert, um Wh in KWh umzurechnen; hierbei ist die Multiplikation mit 1 erforderlich, weil die Wert in a und b als Strings - warum auch immer - abgelegt wurden. (Alternativ wäre auch eine sog. Typumwandlung mittels eines sog. Cast möglich.)
• Mittels der Methoden von parseFloat (bzw. String) werden die Nachkommastellen definiert (toFixed) und der in JavaScript üblicherweise vorhandene Dezimalpunkt durch ein Komma ersetzt (replace).

Wie du siehst, kann man ein an sich einfaches Problem beliebig (kompliziert) lösen, wobei es so manchen Stolperstein aus dem Weg zu räumen gilt.

Viele Spaß beim Basteln.

[OliverIO]

@martinp sagte in W in Kw umrechnen:

{val:0_userdata.0.watt;parseInt(val)<1000 ? parseInt(val)+" W" : (parseInt(val+10)/1000).toFixed(1)+" kW"}

sehr gut du hast meinen testfehler gefunden
warum +10?
das ist nicht das gleiche wie ich gepostet habe.
da ist noch toFixed drin.
Im 2. Beispiel habe ich toFixed nicht mehr verwendet.

[MartinP]

@oliverio said in W in Kw umrechnen:

sehr gut du hast meinen testfehler gefunden
warum +10?
das ist nicht das gleiche wie ich gepostet habe.
da ist noch toFixed drin.
Im 2. Beispiel habe ich toFixed nicht mehr verwendet.

Das war etwas aus dem Ärmel geschüttelt

Das ist der Rechenweg

(parseInt(val+10)/1000).toFixed(1)

Knackpunkt ist das Verhalten auf der "Hälfte" zwischen zwei Zahlenwerten

1550 Watt wird beim "mathematischen Runden" abgerundet, beim "Kaufmännischen Runden" aufgerundet.

Wenn man auf den Wert 10 Watt draufschlägt (die zweite Nachkommastelle soll bei der Umrechnung auf kWh gerundet werden) sollte das für ein Ergebnis entsprechend "kaufmännischem Runden" sorgen...

Interessant wird das Verhalten sicherlich bei negativen Werten ... Habe das nicht getestet ...

[OliverIO]

@martinp

warum hälst du dich noch mit toFixed auf?
Nach dem prüfen in der Dokumentation ist mir die Existenzberechtigung von toFixed nicht mehr so ganz klar, da nach ECMA-Spezifikation immer in Richtung der nächstgelegenen Dezimalstelle gerundet wird. Also 1.0-1.5 auf 1 und 1.6-1.9 auf 2.
Math.round (was ich in der 2. Lösung verwendet habe, rundet richtig kaufmännisch.
Nachteil ist, dass man die Anzahl der gewünschten Nachkommastellen nicht angeben kann.
Das kann man dann aber über 2-stufige teilen wieder ausgleichen, also

1240 / 100 = 12,40, nach runden mit Math.round = 12
1250 / 100 = 12,50 nach runden mit Math.round = 13

12/10 = 1,2
13/10 = 1,3

kleiner edge case, wenn als gerundetes ergebnis ein ?.0 rauskommt, also 1.0, 2.0 etc,
dann wird dir das .0 nicht angezeigt. wenn du auch da eine konsistente anzeige haben willst, dann kannst du dort wieder das toFixed einsetzen. Da die Zahl ja schon gerundet ist, verursacht das kein Problem mehr.

{val:0_userdata.0.testFolder.test;parseInt(val)<1000 ? parseInt(val)+" w " : (Math.round(parseInt(val)/100)/10).toFixed(1)+" kW"}

[MartinP]

@oliverio said in W in Kw umrechnen:

@martinp
warum hälst du dich noch mit toFixed auf?

Ist vielleicht eine Berufskrankheit: Meine Programmiertätigkeit begann im Embedded Bereich, und mit Assembler und C/C++.

Da hat man sich angewöhnt, für jede Zeile Code zu bewertet, was sie für Ressourcen verbrauchen wird ...

Bei Deiner Lösung, sind es zwei Divisionen, bei mir eine Addition und eine Division.
Ist aber zugegeben ziemlich albern, da man gar nicht weiß, was da in den Aufrufen von toFixed() bzw. Round() so passiert .

Bei Javascript im Browser gäbe es da eher zu beachten, dass man nicht zu viele Bibliotheken nachlädt, damit das Laden der Webseite nicht zu lange dauert.

Das ist hier aber sicherlich kein Aspekt, der bei node.JS Code ernsthaft berücksichtigt werden muss.