[gelöst] ReadingsNum rechnet anders als erwartet

Begonnen von FHEMAN, 24 Oktober 2021, 20:56:06

Vorheriges Thema - Nächstes Thema

FHEMAN

Hi, ich konnte in Commandref und Wiki keine weiteren Details zu ReadingsNum finden. Ich habe festgestellt, dass ReadingsNum - ReadingsNum teils ein falsches Ergebnis liefert:
1. ReadingsNum("","", 11.2) - ReadingsNum("","", 11.1)
= 0.0999999999999996 //falsch
2. ReadingsNum("","", 1.2) - ReadingsNum("","", 1.1)
= 0.0999999999999996 //falsch
3- ReadingsNum("","", 0.2) - ReadingsNum("","", 0.1)
= 0.1 //richtig

Das Ganze natürlich auch mit echten Readings.

Könnt ihr mir sagen, ob das ein Bug ist oder ich etwas übersehe?
Als Workaround mit dem Round-Parameter zu arbeiten wäre suboptimal, zumal die Default-Werte hier nicht berücksichtigt werden (nach meinem Verständnis).

Einen schönen Abend
Ronny
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

Otto123

#1
Hallo Ronny,

versuch mal  ;){11.2 - 11.1}
Das hat nichts mit ReadingsNum zu tun, das ist die "ganz normale" Zahlendarstellung der digitalen Gleitkommaarithmetik. Wirst Du außer beim Taschenrecher sicher immer finden.
sprintf hilft Dir bei der finalen Darstellung nach Deinen Wünschen.
Beispiel:
{sprintf "%.2f", 11.2 - 11.1}


Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Christoph Morrison

Zitat von: Otto123 am 24 Oktober 2021, 21:04:16
sprintf hilft Dir bei der finalen Darstellung nach Deinen Wünschen.
Beispiel:
{sprintf "%.2f", 11.2 - 11.1}

Was identisch zum round-Parameter ist ;-)

Otto123

Naja nicht wirklich wenn man die Aufgabe vom TE nimmt :)
{ReadingsNum("","", 1.2,1) - ReadingsNum("","", 1.1,1)}
Er wollte ja das Ergebnis von ReadingsNum() - ReadingsNum() "richtig". Oder ich habe den "Round - Parameter" nicht verstanden.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEMAN

#4
Ich nutze Fhem natürlich nur als Taschenrechner  ;)

Zitat von: Otto123 am 24 Oktober 2021, 22:14:59
Naja nicht wirklich wenn man die Aufgabe vom TE nimmt :)
{ReadingsNum("","", 1.2,1) - ReadingsNum("","", 1.1,1)}
Er wollte ja das Ergebnis von ReadingsNum() - ReadingsNum() "richtig". Oder ich habe den "Round - Parameter" nicht verstanden.
Round wirkt sich nicht auf die angegebenen Default Values von ReadingsNum aus. Gänzlich sauber ist das nicht.
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

frober

Man kann auch das Fhem eigene round() benutzen, das ist analog sprintf, jedoch einfacher zu schreiben:

{round(ReadingsNum("","", 1.2) - ReadingsNum("","", 1.1),1)}
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...