Hallo Rudi,
{ReadingsNum("bla","blub",0672.9840)}
liefert als Ergebnis 0672.9840 zurück.
Das ist an sich ein völlig korrektes Ergebnis. Aber die wenigsten FHEM user sind darauf vorbereitet, dass das Ergebnis dann plötzlich eine Oktalzahl ist.
Hast Du eine spontane Idee, wie man dieses "unerwartete" Ergebnis entschärfen könnte?
Eventuell würde schon eine Logmeldung ausreichen, dass ReadingsNum() eine Oktalzahl gefunden hat, um den Anwender darauf hinzuweisen, dass das Ergebnis nicht wirklich "falsch" ist.
Meiner Meinung nach ist das ein Fehler: die Allermeisten erwarten keine Oktahlzahl, und schon gar keine mit Nachkommastellen. Wo kommt das Input her?
ZitatWo kommt das Input her?
Von einem MQTT2-Device (Wasseruhr - AI on the Edge). Das liefert in einem Reading eine führende Null.
2023-09-27 18:13:17 raw 0672.9840
@Rudi - zum Verständnis:
Die 0672.9840 ist natürlich als Dezimalzahl zu interpretieren. Aber aufgrund der führenden 0 geht perl davon aus, dass es sich um eine Oktalzahl handelt (auch wenn da eine 9 nie vorkommen würde!) und es lässt sich mit der Zahl nicht einfach dezimal weiterrechnen.
{0672.9840 - 672.9839}
liefert ein sehr abstruses Ergebnis: 4429167.0161
THEORETISCH könnte es aber ja sein, dass ein Reading tatsächlich einen Oktalwert enthält (auch wenn mir bisher noch kein solcher Fall untergekommen ist) und deshalb ist das von ReadingsNum() gelieferte Ergebnis für mich nicht per se falsch.
perl ist mAn bei Oktalzahlen nicht konsequent: { 0672.9840 } liefert 4429840, weil 0672 oktal 442 dezimal ist, und der Rest hinter dem Punkt wird einfach drangeklebt (???)
Ab sofort entfernt ReadingsNum und OldReadingsNum fuehrende Nullen, und "konvertiert" damit oktal in dezimal.
Zitat von: rudolfkoenig am 28 September 2023, 18:09:51perl ist mAn bei Oktalzahlen nicht konsequent
perl ist nicht nur an dieser Stelle "nicht konsequent" ;D
Danke fürs Kümmern.