Fehler in ProofAndSetValue bei Gleitkommawerten

Describe the bug Wenn ein Geräteparameter als min / max Grenze einen Gleitkommawert besitzt, der nicht auf .0 endet, kommt es zu Problemen in der WebUI.

Ich habe 3 Konsolenmeldungen eingebaut.

An denen kann man gut sehen, dass die Eingabe in einem Feld, das eigentlich Float zulässt (Wertebereich 0.00 - 7.00) funktioniert - auch wenn in den “float is not allowed”-Zweig eingestiegen wird.

Die Eingabe in einem anderen Feld (0.50 - 15.50) ist kaum bis schwer möglich.

• Beim Löschen des letzten Zeichens werden sofort alle Dezimalstellen entfernt.
• Entfernt man dazu noch die Ganzzahl, erscheint “NaN”.
• Eine erneute Eingabe einer Gleitkommazahl ist nicht oder nur schwer (per Copy&Paste) möglich
  • jede Eingabe eines “.” wird sofort entfernt (sieht man in dem Screencast glaub ich nicht, weil es zu schnell passiert).

Das Problem betrifft nicht nur den Rollladenaktor

System information:

• RaspberryMatic Version: 3.55.5.20201226
• Used Hardware: Pi3b
• Used HomeMatic RF-Module: RPI RF MOD

Additional context …

[jp112sdl]

Spannend wird es mit der nächsten CCU FW (in 8-12 Wochen), wenn eQ-3 selbst (wieder) so viel daran gebastelt hat, dass dieser Patch hier

• nicht mehr passt und man (du?) wieder dran rum bauen muss
• nicht mehr notwendig ist und man für ein paar Wochen ganz schön viel (Frei)zeit investiert hat 😉

Aber grundsätzlich finde ich es toll, dass sich mal jemand der Sache (for free !) annimmt, was die bezahlten Angestellten nicht hinbekommen. 👍

[theimo1221]

Mit dem Snapshot 3.57.4.20210311 funktioniert #1058 (comment) noch nicht 😎

Es ist ganz simpel: parseFloat(-5.0), parseFloat(5.0) werden für Minimum und Maximum übergeben. Dies resultiert in -5 und 5 beides sind keine Zahlen mit Nachkommastelle, weswegen ProofandsetValue die Nachkommastellen abschneidet. ProofAndSetValue('separate_CHANNEL_1_3_temp', 'separate_CHANNEL_1_3', parseFloat(-5.0), parseFloat(5.0), parseFloat(1));" müsste zu: ProofAndSetValue('separate_CHANNEL_1_3_temp', 'separate_CHANNEL_1_3', \"-5.0\"), \"5.0\", 1);" geändert werden.

OK. Ich denke ich hab’s, auch wenn meine Ausgabe unten Deiner nicht zu 100% gleicht.

Auch hier wird ProofAndSetValue mit “falschen” Werten aufgerufen. Eben mit parseFloat(50.0) = 50 statt "50.0"

Somit sehe ich diese Punkte nicht als Fehler im ProofAndSetValue. Die Funktion erlaubt nur exakt so viele Nachkommastellen wie eben das Minimum/Maximum vorgibt. Beispiele

1. Minimum = -50, Maximum = 50 --> Erlaubte Nachkommastellen 0
2. Minimum = -50.0, Maximum = 50 --> Erlaubte Nachkommastellen 1
3. Minimum = -50.0, Maximum = 50.00 --> Erlaubte Nachkommastellen 2
4. …

Es müssten hier also entsprechend die Templates angepasst werden, um eben die korrekten Werte als Minimum/Maximum als STRING nicht als Zahl zu übergeben (Zahlen schneiden überflüssige Nullen ab, Texte nicht.)