RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Benutzeravatar
jmaus
Beiträge: 7213
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 181 Mal
Danksagung erhalten: 729 Mal
Kontaktdaten:

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von jmaus » 21.04.2021, 17:53

MichaelN hat geschrieben:
21.04.2021, 15:41
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()?
RaspberryMatic 3.57.5.20210424 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

jp112sdl
Beiträge: 8667
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 503 Mal
Danksagung erhalten: 1163 Mal
Kontaktdaten:

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von jp112sdl » 21.04.2021, 18:37

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 :roll: auch als String:
https://github.com/eq-3/occu/blob/8cb51 ... r.tcl#L305

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

MichaelN
Beiträge: 2178
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 172 Mal
Danksagung erhalten: 283 Mal

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von MichaelN » 21.04.2021, 20:10

jmaus hat geschrieben:
21.04.2021, 17:53
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.
jp112sdl hat geschrieben:
21.04.2021, 18:37
Ich hoffe, das passt dann so
Ich hoffe auch :lol: 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.

Benutzeravatar
jmaus
Beiträge: 7213
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 181 Mal
Danksagung erhalten: 729 Mal
Kontaktdaten:

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von jmaus » 21.04.2021, 20:28

MichaelN hat geschrieben:
21.04.2021, 20:10
jmaus hat geschrieben:
21.04.2021, 17:53
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.
RaspberryMatic 3.57.5.20210424 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

Baxxy
Beiträge: 3134
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 228 Mal
Danksagung erhalten: 524 Mal

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von Baxxy » 21.04.2021, 20:32

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

Benutzeravatar
jmaus
Beiträge: 7213
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 181 Mal
Danksagung erhalten: 729 Mal
Kontaktdaten:

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von jmaus » 21.04.2021, 20:42

Baxxy hat geschrieben:
21.04.2021, 20:32
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.
Baxxy hat geschrieben:
21.04.2021, 20:32
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.
RaspberryMatic 3.57.5.20210424 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

Baxxy
Beiträge: 3134
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 228 Mal
Danksagung erhalten: 524 Mal

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von Baxxy » 21.04.2021, 21:09

jmaus hat geschrieben:
21.04.2021, 20:42
konkretes Beispiel
Uwe's CUxD-Geräte können real mit 2 Nachkommastellen arbeiten. Eingeben darf ich nur eine.
CUxD_NK.JPG
Grenzwerte bei IP-Schalt-Messaktoren:
Die können 2 Nachkommastellen, eingeben darf ich keine.
NK_PSM.JPG
vs
NK_HM_Aktor.JPG
CUxD_NK.JPG
Und das eQ-3 auch gerne mal trickst sieht man hier... :lol:
eq_NK.JPG
jmaus hat geschrieben:
21.04.2021, 20:42
Nachkommastellen in den Aufrufen immer auf 3 oder so zu setzen
Das gibt Mecker von Thiemo. :wink:
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
Beiträge: 2178
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 172 Mal
Danksagung erhalten: 283 Mal

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von MichaelN » 21.04.2021, 21:26

Baxxy hat geschrieben:
21.04.2021, 21:09
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.

Benutzeravatar
jmaus
Beiträge: 7213
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 181 Mal
Danksagung erhalten: 729 Mal
Kontaktdaten:

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von jmaus » 21.04.2021, 23:47

Baxxy hat geschrieben:
21.04.2021, 21:09
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.
RaspberryMatic 3.57.5.20210424 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

Baxxy
Beiträge: 3134
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 228 Mal
Danksagung erhalten: 524 Mal

Re: RaspberryMatic Experimental Nightly Build Snapshot - 3.57.5.2021xxxx

Beitrag von Baxxy » 21.04.2021, 23:56

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... :wink:

Antworten

Zurück zu „RaspberryMatic“