Re: Bug in der CCU Version 3.59.6?
Verfasst: 16.08.2021, 11:21
Heimautomation mit ELV HomeMatic und FHZ Funk-Hauszentralen
https://homematic-forum.de/forum/
Code: Alles auswählen
onblur=\"ProofAndSetValue('separate_CHANNEL_$ch\_$i\_tmp', 'separate_CHANNEL_$ch\_$i', $min, $max, $factor, event)\">"
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
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
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.
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.Baxxy hat geschrieben: ↑16.08.2021, 11:24Da 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...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.Code: Alles auswählen
onblur=\"ProofAndSetValue('separate_CHANNEL_$ch\_$i\_tmp', 'separate_CHANNEL_$ch\_$i', $min, $max, $factor, event)\">"
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.Baxxy hat geschrieben: ↑16.08.2021, 11:24Das 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)
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.
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.
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!Wir haben's doch fast, warum also alles ändern wenn nur einige wenige Geräte eine "Spezialbehandlung" brauchen?
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.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.
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