RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

[jmaus]

Ich kann nur mit Gewissheit sagen, DDas parseFloat falsch ist und Komma zahlen mit parseInt auch keinen Sinn ergeben.

Was hindert uns dann daran einfach alle ProofAndSetValue() aufrufen in der gesamten WebUI die immer noch mit parseInt/parseFloat stattfinden abzuändern das diese direkte Strings übergeben dann an die neue ProofAndSetValue()?

[jp112sdl]

Ich hoffe, das passt dann so
https://github.com/jp112sdl/JP-HB-Devic ... 1dfe032dcb

Sollte auch mit der orig. CCU FW kompatibel sein, denn eQ-3 übergibt diese Werte teilweise auch als String:
https://github.com/eq-3/occu/blob/8cb51 ... r.tcl#L305

[MichaelN]

Was hindert uns dann daran einfach alle ProofAndSetValue() aufrufen in der gesamten WebUI die immer noch mit parseInt/parseFloat stattfinden abzuändern

Deine Ansage war mal möglichst wenig zu ändern.
Und zumindest ich kann nicht überblicken ob es Seiteneffekte gibt.

Ich hoffe, das passt dann so

Ich hoffe auch s.o. Da du Kontrolle über Abfrage und Aktor hast, kannst du ja vermutlich kritische Fälle testen. Wobei das immer noch keine Aussagekraft für HM Aktoren hat.

[jmaus]

Was hindert uns dann daran einfach alle ProofAndSetValue() aufrufen in der gesamten WebUI die immer noch mit parseInt/parseFloat stattfinden abzuändern

Deine Ansage war mal möglichst wenig zu ändern.
Und zumindest ich kann nicht überblicken ob es Seiteneffekte gibt.

Das bezog sich eigentlich darauf das man bitte nicht hingehen sollte und z.b. die ProofAndSetValue() Funktion z.b. gänzlich und vollumfänglich zu ändern oder so. Aber wenn jetzt klar ist, das eigentlich sämtliche ProofAndSetValue aufrufe immer strings statt parseFloat, etc. Übergeben sollten dann sollte man das IMHO auch so umsetzen. Irgendwelche Seiteneffekte können wir ja dann im Nachgang klären.

[Baxxy]

Das korrigieren der Aufrufe ist ja leider (teilweise) nur die halbe Miete.
Zusätzlich müssten auch die zugehörigen Limits hinter den Eingabefeldern in der WebUI kontrolliert und auf die maximal möglichen Nachkommastellen korrigiert werden.

Oder wir nehmen die eQ-3 ProofAndSetValue, die schert sich nicht um Nachkommastellen oder irgendwelche Rundungsaktionen.
Da könnte man dem Beispielsensor einen Wert von 10.123456789 (egal ob als String oder Float) übergeben und das Gerät muss dann selber schauen was es davon wie verdaut.

Grüße
Baxxy

[jmaus]

Das korrigieren der Aufrufe ist ja leider (teilweise) nur die halbe Miete.
Zusätzlich müssten auch die zugehörigen Limits hinter den Eingabefeldern in der WebUI kontrolliert und auf die maximal möglichen Nachkommastellen korrigiert werden.

Hast du mal ein konkretes Beispiel wo das der Fall ist?

Und wenn, dann wäre es ja zumindest ein erster Anfang einfach die Anzahl max. Nachkommastellen in den Aufrufen immer auf 3 oder so zu setzen (mehr muss sicherlich fast nie sein) und dann nach und nach das weiter zu optimieren. Denn dann wäre zumindest wieder eine Eingabe hier+da überhaupt möglich und wird nicht einfach ignoriert oder als falsch angemeckert.

Oder wir nehmen die eQ-3 ProofAndSetValue, die schert sich nicht um Nachkommastellen oder irgendwelche Rundungsaktionen.
Da könnte man dem Beispielsensor einen Wert von 10.123456789 (egal ob als String oder Float) übergeben und das Gerät muss dann selber schauen was es davon wie verdaut.

Einfach die alte ProofAndSetValue() zu nehmen würde ich jetzt nicht machen, sondern wenn dann eben für die Aufrufe wo man die Anzahl der Nachkommastellen nicht gleich/unmittelbar ermitteln kann diese halt dann auf 3 stellen oder so um auf Nummer sicher zu gehen und dann muss das Gerät eben das beste draus machen.

[Baxxy]

konkretes Beispiel

Uwe's CUxD-Geräte können real mit 2 Nachkommastellen arbeiten. Eingeben darf ich nur eine.

Grenzwerte bei IP-Schalt-Messaktoren:
Die können 2 Nachkommastellen, eingeben darf ich keine.

vs

Und das eQ-3 auch gerne mal trickst sieht man hier...

Nachkommastellen in den Aufrufen immer auf 3 oder so zu setzen

Das gibt Mecker von Thiemo.
Solange die Werte korrekt als String übergeben werden könnte man auch erstmal pauschal 1 oder 2 Nachkommestellen mittels der ProofAndSetValue "dazumogeln". Sehe gerade das habe ich schon testweise drin...

Code: Alles auswählen

digits = digits + 1; 

[MichaelN]

Und das eQ-3 auch gerne mal trickst sieht man hier..

Das zeigt das eQ-3 die Funktion selber nicht verstanden hat. Die ganzen Nullen kommen (auch in occu) eh nicht rüber. Oder das Konstrukt mit +0.001 in der ic_common.tcl. Totaler Schwachsinn.

Alles mit 2 Nachkommastellen zu behandeln, was nicht als string übergeben wird, könnte eine Lösung sein, die nicht viel kaputt macht. Wenn die Übergabe als string stattfindet, hat man ja die korrekte Anzahl digits.

Und dann bleibt vielleicht ein kleiner Rest, der optimiert werden muss.

[jmaus]

Solange die Werte korrekt als String übergeben werden könnte man auch erstmal pauschal 1 oder 2 Nachkommestellen mittels der ProofAndSetValue "dazumogeln". Sehe gerade das habe ich schon testweise drin...

Code: Alles auswählen

digits = digits + 1; 

Nee, das ist dann auch nur wieder rumgepatche IMHO. Ich denke ich werde mal zeitnah über die WebUI Quellen fräsen und schauen das alle ProofAndSetValue() aufrufe konsistent sind. D.h. immer Strings übergeben werden und dann halt bei denen wo man nicht offensichtlich sieht wieviel nachkommastellen das gerät braucht das ganze auf 3 Nachkommastellen in der übergabe an die ProofAndSetValue() setzen. Dann sollten die ProofAndSetValue aufrufe wenigstens konsistent sein und dann kann man die hier/da nochmal nachpatchen wenn man da drüberstolpert. Aber es sollte dann nicht mehr dazu kommen das man gar keine Werte mehr eingeben kann wie das in der Vergangenheit ja passiert ist.

[Baxxy]

Ich würde sagen wir legen uns erstmal weiter auf die Lauer und warten ob noch weitere Probleme auftauchen.

• Die Sache mit den teilweise inkorrekten Nachkommastellen ist zwar nicht schön, aber auch nicht funktionskritisch solange nicht zwingend benötigte Nachkommastellen "entfernt" werden. Die CUxD-Geräte z.B. arbeiten ja auch mit einer statt 2 Nachkommastellen, nur halt minimal ungenauer.
  Das kann man bei Bedarf immer noch optimieren.
• Die Aufrufe mit parseInt muss man auch erstmal nicht anfassen. Solange der Aufruf korrekt ist und nur Integer gültig ist hat die Funktion keine Probleme.
• parseFloat wird immer nur dann zum Problem wenn die Limits auf xx.0 ; xx.00 usw. enden. Endet mindestens ein Limit auf z.B. xx.5 hat man zumindest eine Nachkommastelle und die Funktion arbeitet einigermaßen korrekt (Rundung auf eine Nachkommastelle auch wenn z.B. 10.55 eingegeben wird).
• Schwieriger wird es bei Aufrufen wie z.B.

  Code: Alles auswählen

  " onblur=\"ProofAndSetValue('separate_CHANNEL_$chn\_$prn','separate_CHANNEL_$chn\_$prn', $min, $max, parseFloat(1));\"> </td>"

  (hier mal exemplarisch aus Jérôme's HB-UNI-Sen-PC-WM_ch_master.tcl)
  Hier ist nicht ersichtlich ob die Limits Float oder Integer sind. Sind sie Integer ist alles gut. Sind sie Float sollten sie als String übergeben werden.

Als groben Richtlinie kann man sagen...
Alle Float-Werte sollten als String übergeben werden. Die Limits sollten die korrekte Anzahl an Nachkommastellen, passend zu den "Fähigkeiten" des Aktors / Sensors haben.

Und ja, irgendwann haben wir's...