Fenster-Drehgriffkontakt HmIP-SRH - Zustand wird nicht erfasst

[Gladiator79]

Hallo,
ich hoffe ihr könnt mir weiter helfen.
Ich betreibe in meiner Installation insgesamt vier Fenster-Dregriffkontakte, Typ HmIP-SRH. Je nach Griffstellung sollen die Rollos dann zu gegebener Zeit runterfahren, auf Lüftungsstellung gehen oder oben bleiben.
Das hat bis jetzt tadellos funktioniert. Nun allerdings nicht mehr. Betätige ich den Fenstergriff, wird mir mit aufleuchtender grüner LED signalisiert, dass die Übertragung erfolgreich war. Schaue ich dann im Web-Interface nach, ist der Zustand des Fenstergriffes nicht aktuallisiert worden. Ein neues Anlernen des Fenster-Dregriffkontaktes hilft nicht. Was allerdings hilft ist ein Neustart der CCU2. Anschließend funktioniert das Ganze. Aber am nächsten Tag dann nicht mehr.
Der Effekt ist bei allen vier Fenster-Dregriffkontakten vorhanden.
Ich habe keine Idee, woran es liegen könnte.
Könnte es sein, dass die aktuelle Formware der CCU2 Probleme macht?
Folgende Firmware ist vorhanden:
CCU2: 2.35.16
Fenster-Drehgriffkontakt: 3x 1.0.2 / 1x 1.0.1

[Gluehwurm]

Die aktuelle SRH-Fw ist die 1.2.10, ob es damit zusammenhängt, keine Ahnung. Meine funktionieren auch nach Tagen noch.

Gruß
Bruno

[alchy]

Mal die Einstellungen angeschaut, was die melden sollen und eventuell "überschrieben" und neu übertragen?

Alchy

[Gladiator79]

Habe schon einiges ausprobiert. Alles leider ohne Erfolg. Löschen, neu anlernen und in den Programmen berücksichtigen...immer wieder das gleiche. Einen guten Tag bis zwei funktioniert es und dann nicht mehr.

Für mich ist leider nicht nachvollziehbar, was die Ursache sein könnte.
Sobald die Fensterstellung nicht mehr erkannt wird, kann ich zu den Fenster-Drehgriffkontakten auch nicht mehr die Einstellungen über das Webinterface abrufen.
Nachdem ich die CCU2 neu gestartet habe, werden mir auch wieder die Parameter. Diese sind bei allen Fenster-Drehgriffkontakten gleich eingestellt:

Zyklische Statusmeldung = aktiviert
Anzahl der auszulassenden Statusmeldungen = 0
Anzahl der auszulassenden,
unveränderten Statusmeldungen = 0
Low-Bat.-Schwelle = 1,10V
Reset per Gerätetaste sperren = deaktiviert
Routing aktiv = aktiviert

Eventverzögerung = 1Sekunde
Meldung in Position unten = geschlossen
Meldung in Position quer = offen
Meldung in Position oben = gekippt

Vielleicht eine Sache, die meiner Meinung nach aber nicht zu solch einem Verhalten führen sollte. Es ist allgemein bekannt, dass nach einem Neustart der CCU2 z.B. die Rolladensteuerung ein gewissen "Eigenleben" zeigen, sofern deren Ansteuerung über Programme mit der Verwendung von Systemvariablen statt findet. Einige verbleiben in der Position, in der sie vor dem Neustart waren, einige werden angesteuert. Um hier den unerwünschten Effekt der ungewollten Ansteuerung nach einem Neustart zu unterbinden, habe ich die Anwesenheits-Variable "missbraucht" um festzustellen, ob gegenwärtig ein "Reboot" stattfindet.
Nähere Informationen findet man hierzu auch hier: https://homematic-guru.de/homematic-pro ... verhindern

Aber da geht es eigendlich um das ungewollte ausführen von Programmen. Das Problem bei mir ist aber, dass der Status des Aktors gar nicht erfasst wird. Völlig losglöst, was anschließend mit der Information passiert (Auswertung in einem Programm oder Direktverknüpfung etc.)

[tloeffel]

Hallo Zusammen,

ich habe mal meine Firmwareversionen der SRH im Tinker unter RaspberyMatic (0826) angesehen.
Bei mir sind alle in der Version 1.0.1. Es gibt bei EQ3 auch keine anderen. Google sind nur für die HMIP-Accesspoints wohl andere verfügbar.

Deinen Fehler habe ich so nicht. Ich steuere auch (über Programme) in Abhängigkeit vom Drehgriff die Rollladen. Geht alles super.
Meine Einstellung ist mit Deinen vergleichbar.
Nur ein Unterschied:

HMIP-SRH.PNG (19.11 KiB) 2007 mal betrachtet

Hast Du mal die Protokollierung für den Kanal 1 eingeschaltet? Hat mir geholfen.

Lieben Gruß Thomas

[JRiemann]

Die Einstellungen der „Statusmeldungen“ (oberen 3) beziehen sich lediglich auf die zyklischen Statusmeldungen. Diese Optionen haben absolut keinen Einfluss auf das Meldeverhalten wenn ein neues Event durch offen/geschlossen erzeugt wird.
Hierfür ist die Option „Eventverzögerung“ zuständig.

[Gladiator79]

Ich hatte zuvor unter „Anzahl der auszulassenden Statusmeldungen“ auch die 20 drin stehen. Das ist -so meine ich- der Default-Wert. Mein Problem hatte ich aber bereits mit der Einstellung. Ich habe dann zwischenzeitlich diesen Wert auf 0 gesetzt und gehofft, dass das hilft.
Das eigenartige ist einfach, dass ich im Web-Interface unter Geräte schon nicht mehr den Zustand signalisiert bekomme. Also die einfache Zustandserkennung nicht funktioniert. Völlig losgelöst, was man anschließend überhaupt mit der Information dann macht. Und dann das komische Verhalten, dass vor Ort am Sensor selber die erfolgreiche Funkübertragung mit „grün“ aufleuchtender LED signalisiert wird....

[Gluehwurm]

Wenn das eine Zeit lang gut funktioniert hat, muss ja irgendwas passiert sein. Eine Ahnung, wann das auftrat und was davor geschehen ist?

[Gladiator79]

Korrekt, es gab genau zwei Änderungen:

1. Die Anpassung der Programme mit der "Anwesenheits"-Systemvariable, damit bei einem Reboot Programme nicht ungewollt ausgeführt werden.
2. Das Update auf die aktuelle CCU2-Firmware.

Durch die Anpassung der Programme kann ich mir diesen Effekt nicht erklären.
Durch das Update könnte ich mir den Effekt schon eher vorstellen. Allerdings spricht dagegen die Erfahrung anderer User, die keine Probleme feststellen konnten.
Wahrscheinlich werde ich ein altes Backup zurück spielen müssen um zu sehen, ob dass Problem weiter besteht. Oder kann man auch einfach eine alte Firmware über eine aktuelle überbügeln. Das würde die Fehlersuche dahingehend vereinfachen, da ich geziehlt nur einen Parameter änder würde. Beim einspielen eine Backups müsste ich noch prüfen, welche Programmänderungen zwischenzeitlich erfolgt sein könnten, da ich nicht nach jeder Programmänderung ein Backup erstellt habe...