Meldeverzögerung bei Fensterkontakt HM-Sec-Sco nicht mehr einstellbar

[jp112sdl]

Müssen wir das noch jmaus melden?

Ich halte mich da raus. Bei dem Trauerspiel, was eQ-3 ausliefert habe ich absolut keine Motivation an irgendeinem Community-Patch. Es betrifft ja (auch) alle CCU3 Nutzer.

[jp112sdl]

@Baxxy
geht das mit dem SDV ?

Es reicht schon, die alte ProofAndSetValue aus der 3.53er FW zu nehmen.

[Black]

ok, dann wirds bei mir auch gehen, weil die ProofAndSetValue benutz ich bei mir gar nicht.

Black

[jp112sdl]

ProofAndSetValue

ist eine Javascript Funktion in der Webui.js, die prüft, ob die vom Benutzer eingegebenen Werte innerhalb des zulässigen Bereichs sind (Zahl wo nur Zahl darf, nicht > max. und < min. usw) und nach positiver Prüfung den Wert dann weitergibt.
Momentan kackt die Prüfung an sich schon ab.

[Baxxy]

geht das mit dem SDV ?

Ja, mit PutParamset kann man die Werte weiterhin ändern.

[jmaus]

Müssen wir das noch jmaus melden?

Ich halte mich da raus. Bei dem Trauerspiel, was eQ-3 ausliefert habe ich absolut keine Motivation an irgendeinem Community-Patch. Es betrifft ja (auch) alle CCU3 Nutzer.

So, ich hab mich mal hingesetzt und hab mir das mal angeschaut. Rausgekommen ist das hier für RaspberryMatic:

https://github.com/jens-maus/RaspberryM ... alue.patch

Damit scheint das Anpassen dieser Geräteparameter wieder zu funktionieren.

Verstehen kann ich natürlich deinen Frust und auch ich finde es frappierend das dieser Bug einfach zu durchgeschlüpft ist. Allerdings teile ich deine Auffassung nicht, das man eQ3 einfach nur den schwarzen Peter zuschieben und selber nicht hand anlegen sollte um quasi ein Zeichen zu setzen oder das man doch die Arbeit von eQ3 nicht machen sollte. Es ist zwar teilweise verständlich, allerdings hilft es unterm Strich nicht weiter. Zumindest meine Herangehensweise ist und war immer selbst Dinge in die Hand zu nehmen wenn das möglich ist. Denn hätte ich immer mir einfach gesagt das eQ3 doch besser selbst reparieren sollte, dann wären viele der von mir reparierten ReGaHss-Bugs jetzt noch nicht beseitigt und dann wäre doch auch IMHO niemanden geholfen.

Aber vielleicht kannst du wenigstens versuchen den Patch mal selbst anzuwenden um zu schauen das ich nicht selbst noch irgendwo einen weiteren Bug eingebaut habe...

[jp112sdl]

Allerdings teile ich deine Auffassung nicht, das man eQ3 einfach nur den schwarzen Peter zuschieben

Ich denke da an diejenigen, die sich gerade eine CCU3 (mit vorinstallierter oder anschließend frisch aktualisierter 3.55.5) kaufen, die nicht hier im Forum wohnen und somit schon out-of-the-box vor eine Wand rennen.

Natürlich gibt es mehr als eine Hand voll User, die sich aufgrund jahrelanger Basteleien an der CCU bei dem aktuellen Fehler selbst helfen könn(t)en.

Aber gerade bei einem solchen Fehler (der bei uns definitiv den Stempel "abnahmehindernd" bekäme) muss der Hersteller kurzfristig nachliefern.
(Vgl. "forgotten-HTML-Tag"-Bug 3.53.26 -> 3.53.30).

Aber vielleicht kannst du wenigstens versuchen den Patch mal selbst anzuwenden um zu schauen das ich nicht selbst noch irgendwo einen weiteren Bug eingebaut habe...

Ja das werde ich machen.

[jp112sdl]

Scheint alles zu passen mit dem Patch

[SciBee]

Die Firmware V2.55.5 der CCU2 scheint ebenfalls betroffen zu sein.
Ich konnte die Parameter der HB-UNI-SEN... devices nicht mehr anpassen mit identischen Symptomen. Devconfig geht z.T., per WebUi wird ignoriert bzw. verworfen. Die CCU2 sendet die Daten gar nicht erst an die Geräte.
Nach Downgrade der CCU2 auf FW2.53.34 funktioniert es wieder.

[alchy]

Wenn schon denn schon. Die Ursache und auch die Lösung ist ja in dem >Thread veröffentlicht < Ein Downgrade ist eine mögliche Lösung. Das Bearbeiten (Austausch, nur Austausch der ProofAndSetValue-Funktion, Patch..... ist eine weitere. Trauriges Beispiel für die strikte QC bei EQ-3 bleibt es aber trotzdem leider.

Alchy