Mußte ich auch gerade lernen. Der ATmega328P hat sich verdreifacht ...
Bug in der CCU Version 3.59.6?
Moderatoren: jmaus, Co-Administratoren
- Baxxy
- Beiträge: 10769
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 602 Mal
- Danksagung erhalten: 2201 Mal
Re: Bug in der CCU Version 3.59.6?
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...
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:
High-Limit auf 10.01 geändert:
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)\">"
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
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
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- jmaus
- Beiträge: 9844
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 462 Mal
- Danksagung erhalten: 1863 Mal
- Kontaktdaten:
Re: Bug in der CCU Version 3.59.6?
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)
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.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 9649
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 697 Mal
- Danksagung erhalten: 1617 Mal
Re: Bug in der CCU Version 3.59.6?
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.
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
- jmaus
- Beiträge: 9844
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 462 Mal
- Danksagung erhalten: 1863 Mal
- Kontaktdaten:
Re: Bug in der CCU Version 3.59.6?
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.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- Baxxy
- Beiträge: 10769
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 602 Mal
- Danksagung erhalten: 2201 Mal
Re: Bug in der CCU Version 3.59.6?
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
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
-
- Beiträge: 9649
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 697 Mal
- Danksagung erhalten: 1617 Mal
Re: Bug in der CCU Version 3.59.6?
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?
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
- jmaus
- Beiträge: 9844
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 462 Mal
- Danksagung erhalten: 1863 Mal
- Kontaktdaten:
Re: Bug in der CCU Version 3.59.6?
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.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- jmaus
- Beiträge: 9844
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 462 Mal
- Danksagung erhalten: 1863 Mal
- Kontaktdaten:
Re: Bug in der CCU Version 3.59.6?
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
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- Baxxy
- Beiträge: 10769
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 602 Mal
- Danksagung erhalten: 2201 Mal