Mir ist klar, dass Du Alex den Code von der CCU2 im wesentlichen von eQ3 übernimmst und dann den Einbau in den Container machst.
Wäre es möglich einen Bug in der CCU2 zu korrigieren?
Wenn man die zyklischen Statusmeldung der Heizungskörper oder der optischen Fensterkontakte verringert, also nur jedes 10 Mal senden lässt, wird in der CCU2 ein Kommunikationserror angezeigt, weil die CCU2 diese verringerte Sendefrequenz nicht berücksichtigt.
Das ist ein Bug, der seit mehr als 3 Jahren vorhanden ist, und den eQ3 wohl fixen will.
Fix für CCU2 Bug
Moderator: Co-Administratoren
Fix für CCU2 Bug
34 Geräte: 3x HM-LC-Sw1-Pl-2, 1x HM-OU-LED16, 9x HM-LC-Bl1PBU-FM, 1x HM-Sec-SFA-SM, 1x HM-RC-Sec3-B, 2x HM-RC-4-B, 1x HM-LC-Sw4-WM, 1x HM-Sec-RHS, 1x HM-EM-CCM, 1x HM-Sen-EP, 10x HM-Sec-SC, 1x HM-RC-19, 1x HM-Sen-MDIR-O, 1x HM-LC-Sw1PBU-FM
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 34 Mal
Re: Fix für CCU2 Bug
Hi,
das sollte aber kein "statischer" Fix sein, so das einfach nur der cyclic_timeout-Wert angepasst wird, das hätte nämlich zur Folge, das bei wahrscheinlich 95% der Installationen ein Kommunikationsfehler deutlich später auftritt, was in meinen Augen kontraproduktiv ist.
Es bräuchte eine "Intelligenz" im Schnittstellenprozess (rfd) selbst, die diesen Wert dynamisch anhand der konfigurierten Parameter berechnet, wie lange die Pause zwischen zwei Meldungen dauern kann, und dann diesen Wert plus einen gewissen Aufschlag speichert. Das ist nichts, was Alex ändern kann, das könnte nur EQ3 selbst ändern, daran glaube ich aber nicht.
Der Familienvater
das sollte aber kein "statischer" Fix sein, so das einfach nur der cyclic_timeout-Wert angepasst wird, das hätte nämlich zur Folge, das bei wahrscheinlich 95% der Installationen ein Kommunikationsfehler deutlich später auftritt, was in meinen Augen kontraproduktiv ist.
Es bräuchte eine "Intelligenz" im Schnittstellenprozess (rfd) selbst, die diesen Wert dynamisch anhand der konfigurierten Parameter berechnet, wie lange die Pause zwischen zwei Meldungen dauern kann, und dann diesen Wert plus einen gewissen Aufschlag speichert. Das ist nichts, was Alex ändern kann, das könnte nur EQ3 selbst ändern, daran glaube ich aber nicht.
Der Familienvater
- deimos
- Beiträge: 5407
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 962 Mal
- Kontaktdaten:
Re: Fix für CCU2 Bug
Hi,
wie Familienvater geschrieben hat: Wirklich fixen kann man das nur innerhalb von rfd und das kann ich nicht.
Man könnte es in den XML Dateien der rftypes anpassen, aber innerhalb von piVCCU werde ich das nicht machen, weil eine solche Änderung nur weniger Nutzer einen Vorteil bringt, vielen eher einen Nachteil (echte Störung wird später erkannt) und die Kompatibilität verrringert. Daher werde ich das in piVCCU nicht umsetzen.
Es spricht aber imho nichts dagegen, dass du diese Anpassung bei dir machst. Wenn du die Anpassung über /etc/piVCCU/pre-start.sh verankerst, kann das dann auch über Updates hinweg überleben.
Viele Grüße
Alex
wie Familienvater geschrieben hat: Wirklich fixen kann man das nur innerhalb von rfd und das kann ich nicht.
Man könnte es in den XML Dateien der rftypes anpassen, aber innerhalb von piVCCU werde ich das nicht machen, weil eine solche Änderung nur weniger Nutzer einen Vorteil bringt, vielen eher einen Nachteil (echte Störung wird später erkannt) und die Kompatibilität verrringert. Daher werde ich das in piVCCU nicht umsetzen.
Es spricht aber imho nichts dagegen, dass du diese Anpassung bei dir machst. Wenn du die Anpassung über /etc/piVCCU/pre-start.sh verankerst, kann das dann auch über Updates hinweg überleben.
Viele Grüße
Alex
Re: Fix für CCU2 Bug
Danke für die Antworten.
34 Geräte: 3x HM-LC-Sw1-Pl-2, 1x HM-OU-LED16, 9x HM-LC-Bl1PBU-FM, 1x HM-Sec-SFA-SM, 1x HM-RC-Sec3-B, 2x HM-RC-4-B, 1x HM-LC-Sw4-WM, 1x HM-Sec-RHS, 1x HM-EM-CCM, 1x HM-Sen-EP, 10x HM-Sec-SC, 1x HM-RC-19, 1x HM-Sen-MDIR-O, 1x HM-LC-Sw1PBU-FM