Bug in der CCU Version 3.59.6?

[Matsch]

Elektronikbauteile, gerade Mikrochips sind derzeit aber echt mega teuer

Mußte ich auch gerade lernen. Der ATmega328P hat sich verdreifacht ...

[Baxxy]

Eigentlich hatte ich ja gehofft wir sind mit dem Thema "ProofAndSetValue" durch.

Da ich nun aber nochmal die alte Testfunktion angeworfen habe kann ich das gezeigte Verhalten nachvollziehen.

Der Aufruf erfolgt vermutlich über die /www/config/ic_deviceparameters.cgi...

Code: Alles auswählen

onblur=\"ProofAndSetValue('separate_CHANNEL_$ch\_$i\_tmp', 'separate_CHANNEL_$ch\_$i', $min, $max, $factor, event)\">"

Wird also nicht als string übergeben und wenn man sich die Limits (0.00 - 10.00) anguckt wird schnell klar das die Nachkommastellen durch ProofAndSet wegrationalisiert werden und entsprechend gerundet wird.

Das naheliegendste wäre nun die Übergabe einfach als string zu händeln (haben wir an anderen Stellen ja auch gemacht).

Davon rate ich aber ab, weil der Aufruf für viele Geräteparameter gilt und einige davon allergisch auf "nicht unterstützte" Werte reagieren.
(Man müsste an x-Stellen die Limits korrigieren)

Eine einfache Lösung wäre z.B. das obere Limit auf 10.01 zu ändern.
Ob das einfach umsetzbar ist und ob der Aktor die 10.01 auch im Ernstfall verdaut kann ich nicht sagen.
Dazu kommt dann vielleicht noch die Sache mit dem Faktor, da muss ich aber passen.

Aktuell:

Code: Alles auswählen

Testbedingung:
testProofAndSetValue("17. Lamellenposition", 2.36, 0.00, 10.00, 1, "2.36");
Ergebnis:
Fehler bei Test "17. Lamellenposition": Erwartungswert: 2.36	Neuer SRC Wert: 2	Neuer Dest Wert: 2

High-Limit auf 10.01 geändert:

Code: Alles auswählen

Testbedingung:
testProofAndSetValue("17. Lamellenposition", 2.36, 0.00, 10.01, 1, "2.36");
Ergebnis:
korrekter Test "17. Lamellenposition": Erwartungswert: 2.36	Neuer SRC Wert: 2.36	Neuer Dest Wert: 2.36

[jmaus]

Eigentlich hatte ich ja gehofft wir sind mit dem Thema "ProofAndSetValue" durch.

Also ich habe mir schon gedacht da es da sicher noch das eine oder andere Gerät geben wird das nochmal rumzicken wird. Trotzdem halte ich die vielen anpassungen bzgl. ProofAndSetValue() weiterhin für sinnvoll und zielführend - einfach weil wir so ein Stück weiter in die richtige Richtung gegangen sind.

Da ich nun aber nochmal die alte Testfunktion angeworfen habe kann ich das gezeigte Verhalten nachvollziehen.

Der Aufruf erfolgt vermutlich über die /www/config/ic_deviceparameters.cgi...

Code: Alles auswählen

onblur=\"ProofAndSetValue('separate_CHANNEL_$ch\_$i\_tmp', 'separate_CHANNEL_$ch\_$i', $min, $max, $factor, event)\">"

Wird also nicht als string übergeben und wenn man sich die Limits (0.00 - 10.00) anguckt wird schnell klar das die Nachkommastellen durch ProofAndSet wegrationalisiert werden und entsprechend gerundet wird.

Wenn mir jemand die Tools und Infos an die Hand geben könnte damit ich das hier lokal irgendwie nachgestellt bekomme und die generierten Geräteparameter irgendwie in eine meiner Testinstallation sehen kann, dann könnte ich mir das nochmal genau anschauen und hierfür ggf. einen oder mehrere Fixes erarbeiten sowie das ja in der letzten Iteration der ProofAndSetValue() fixes der Fall war und die unter'm strich schon als erfolg gewertet werden können.

Das naheliegendste wäre nun die Übergabe einfach als string zu händeln (haben wir an anderen Stellen ja auch gemacht).

Davon rate ich aber ab, weil der Aufruf für viele Geräteparameter gilt und einige davon allergisch auf "nicht unterstützte" Werte reagieren.
(Man müsste an x-Stellen die Limits korrigieren)

Da habe ich eine andere Einstellung zu: Dann muss man das eben so tun bzgl. "an x-Stellen die Limits korrigieren". Jetzt wieder irgendwie zu versuchen irgendein workaround zu finden oder gar sowas murky wie "10.01" einzuführen ist IMHO auf lange Sicht nur wieder zum Scheitern verurteilt.

Es bleibt also dabei, wenn mir jemand es irgendwie hinkriegt das ich hier in einer lokalen Testinstallation die Geräteparameter dieses Gerätes so dargestellt bekomme wie ich das bräuchte um das Problem zu reproduzieren, dann kann ich mir das gerne noch einmal anschauen und dafür ggf. einen allgemein gültigen Fix erarbeiten.

[MichaelN]

Mein Weg wäre das nicht. Ich würde max limit auf 9.99 setzten. Dann ist man auf der sicheren Seite. Wahrscheinlich wird 9.99 sogar noch auf 10 gerundet und alles ist gut.

[jmaus]

Mein Weg wäre das nicht. Ich würde max limit auf 9.99 setzten. Dann ist man auf der sicheren Seite. Wahrscheinlich wird 9.99 sogar noch auf 10 gerundet und alles ist gut.

Auch sowas würde ich vermeiden wollen wenn es irgendwie geht, denn das schreit förmlich nach murky workaround das einem später dann mal wieder auf die Füße fällt.

[Baxxy]

Ohne wirklich jedes Gerät angelernt zu haben ist das aus meiner Sicht quasi unmöglich alles zu korrigieren und auf Plausibilität zu prüfen.

Wir haben's doch fast, warum also alles ändern wenn nur einige wenige Geräte eine "Spezialbehandlung" brauchen?

Mich würde aber erstmal interessieren wie die Limits in den Geräteeinstellungen zustande kommen, bzw. wo im System ich was ändern muss um damit etwas zu experimentieren.

Grüße
Baxxy

[MichaelN]

Ich wollte mir mal den aktuellen Stand der ProofAndSetValue ansehen, scheiter aber mal wieder kläglich an Github. Im Repository der OCCU kann ich schön durch die Dateistruktur gehen und die WebUI. Js finden. Bei RM verlaufe ich mich immer und finde nichts. Kann mir jemand einen Tipp geben wie ich da den aktuellen Stand einsehen kann?

[jmaus]

Ohne wirklich jedes Gerät angelernt zu haben ist das aus meiner Sicht quasi unmöglich alles zu korrigieren und auf Plausibilität zu prüfen.

Da ist klar, aber eben wie bisher ein sukzessiver prozess getrieben von der arbeitsweise "anpassung -> release -> bug-report -> anpassung, usw.". Und wenn es kein weiteren bugreport gibt sind wir halt durch oder das gerät ist eben nicht mehr in verwendung/wichtig genug.

Wir haben's doch fast, warum also alles ändern wenn nur einige wenige Geräte eine "Spezialbehandlung" brauchen?

Genau so ist es, wir haben es fast und daher würde ich jetzt nicht nur schnell schnell was anpassen nur damit es mal wieder irgendwie passt. Das muss ein-für-allemal final gelöst werden und nicht durch weitere workaround wie eQ3 das ja anscheinend leider auch immer mal schnell probiert zu lösen. Wir können das besser!

Mich würde aber erstmal interessieren wie die Limits in den Geräteeinstellungen zustande kommen, bzw. wo im System ich was ändern muss um damit etwas zu experimentieren.

Meines wissen stecken die Gerätelimits der Parameter bei Bidcos woanders als bei HmIP. Eben bei BidCos stecken die in den xml dateien und bei HmIP stecken die in den Geräten bzw in deren firmware selbst! Und genau deshalb können wir die auch nicht einfach so ändern/anpassen und sollten stattdessen die funktion die diese interpretiert (hier eben ProofAndSetValue() soweit ertüchtigen das diese damit besser klar kommt. Und eins darfst du auch nicht vergessen: änderst du die limits der BidCos geräte jetzt nur damit die WebUi besser damit klarkommt, dann lieferst du die eigebtlich falschen min/max werte auch an externe Engines wie ioBroker&Co anders/geändert aus und das obwohl die damit klarkommen, weil eben deren Funktion da nicht solche eklatanten fehler macht wie ProofAndSetValue in der WebUI.

[jmaus]

Kann mir jemand einen Tipp geben wie ich da den aktuellen Stand einsehen kann?

Ja, installier dir den aktuellen nightly build und durchforste das Dateisystem der laufenden RM danach. Das RaspberryMatic GitHub hat eben eine reihe von WebUI patches die sukzessive die WebUI umpatchen zu dem stand der dann im FilesYstem landet

[Baxxy]

mir mal den aktuellen Stand der ProofAndSetValue ansehen

Kurz und schmerzlos...

ProofAndSetValue_RM_3.59.6.20210814.txt

(2.35 KiB) 20-mal heruntergeladen