HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

[Xel66]

Sollte der Fehler (auch wenn unbemerkt, so wie hier von stan23 beschrieben) nicht zu einem deutlich höheren Batterieverbrauch der Sensoren führen?

Ich würde mal behaupten, ja, denn es wird deutlich mehr kommuniziert. Allerdings tritt der Fehler ja erst immer nach ein paar Tagen/Wochen Normalbetrieb ein und dann auch nur bis zum nächsten Reboot, so dass er Mehrverbrauch vermutlich noch nicht beobachtbar ins Gewicht fällt. Da man keine analoge Batteriespannungsüberwachung hat, ist eine solche Überprüfbarkeit auch nicht gegeben. Und wer bemerkt schon, dass die Batterie eines bis dato unauffälliger TFKs jetzt eine um wenige Prozent geringere Standzeit hat. Ich würde es nicht bemerken, wenn ich in einem Jahr ein/zwei Wochen füher eine Batteriewarnung bekomme. So genau zeichne ich das nicht auf. Ich denke, das verschwindet sowieso in der Streuung der Batteriekapazitäten und der ggf. unterschiedlichen Benutzung. Und grundsätzlich ist der Fehler in der TFK-Firmware ja schon immer da und es wurde ggf. vermehrt kommuniziert. Die CCU konnte nur bis dato damit umgehen.

Gruß Xel66

[blackhole]

Ich würde es nicht bemerken, wenn ich in einem Jahr ein/zwei Wochen füher eine Batteriewarnung bekomme. So genau zeichne ich das nicht auf. Ich denke, das verschwindet sowieso in der Streuung der Batteriekapazitäten und der ggf. unterschiedlichen Benutzung.

Bei mir haben sich innerhalb der letzten zwei Wochen drei (von insgesamt 23) HM-Sec-SCo mit relativ häufigen Zustandswechsel (Haustüre, Briefkastenklappe, Briefkastentüre), im Vergleich zu den letzten sechs Vorjahren, jeweils etwa ein halbes Jahr zu früh mit niedrigem Batteriestand gemeldet. Daher auch meine Fragen zum Stromverbrauch in Verbindung mit dem Fehler.

Auf Dual-Copro-Firmware 4.2.14 bin ich kurz nach jp112sdls veröffentlichten Erkenntnissen (unter CCU3-Firmware 3.61.7) umgestiegen.

[stan23]

Die Stromkurve setzt sich zusammen aus einer langen Zeit mit niedrigem Sleep-Strom und einer kurzen Zeit hohem Aktiv-Strom.
Der Energiebedarf ist das Integral mal der (konstanten) Batteriespannung.

Wenn die Aktivzeit nun rund 3 Mal so lang ist, steigt natürlich auch der Gesamtenergiebedarf. Man müsste mal messen wie hoch die Werte sind, aber vermutlich merkt man das zumindest etwas in der Gesamtlaufzeit.

Noch viel stärker merkt man aber den anderen Bug der SCo:
mit Meldeverzögerung und entsprechendem Timing beim Öffnen/Schließen fällt er in eine endlose Sendeschleife, bis sein DC überschritten ist.
Sobald das ein Mal passiert ist, fallen die dreifachen Sendungen nur noch wenig ins Gewicht.

[blackhole]

Noch viel stärker merkt man aber den anderen Bug der SCo:
mit Meldeverzögerung und entsprechendem Timing beim Öffnen/Schließen fällt er in eine endlose Sendeschleife, bis sein DC überschritten ist.

Dann hat das wohl die Batterien über die Maßen beansprucht, da ich ja anfangs über einen längeren Zeitraum hinweg die bemerkbaren Symptome (Servicemeldungen, hoher DC) zugelassen und beobachtet habe (4 "Wellen" haben meine HM-Sec-SCo abbekommen bevor ich interveniert habe).

Ich gehe daher davon aus, dass sich die anderen betroffenen HM-Sec-SCo dann auch etwa 6 Monate früher melden werden als die Jahre zuvor.

[Xel66]

HM-Sec-SCo mit relativ häufigen Zustandswechsel (Haustüre, Briefkastenklappe, Briefkastentüre)

Hmmm... das sind auch auch alles Montageorte mit eher stark schwankenden Temperaturen bzw. potenziell niedrigen Temperaturumgebungen. Ich habe einen TFK im Türfalz eines Blechgartenhauses montiert und dieses Jahr (vermutlich wegen der wenigen richtig kalten Tage) eine deutlich längere Batteriestandzeit (ist schon sechs Wochen überfällig). Dieser TFK bzw. seine Batterie ist stark temperaturbelastet. Im Winterhalbjahr die kalten Außentemperaturen und im Sommerhalbjahr durch Sonneneinstrahlungen auch mal locker 50°C++ Oberflächentemperatur. Darum habe ich dort Standzeiten von maximal einem dreiviertel Jahr, im Gegensatz zu den Fenster- bzw. Innentüren-BWM von 1,5 bis zwei Jahren. Habe derzeit gerade eine Serie. Im Takt zwei pro Woche bekomme ich Batteriewarnungen der Innen-TFK. Die Zeit scheint rum zu sein. Da ich demnächst gern in den Urlaub gehen würde, werde ich vorher die verbleibenden prophylaktisch austauschen. Hatte da schon mal so ein unschönes Erlebnis bei aktivierter Einbruchsdetektionsfunktion (letzte Meldung vor dem Tod der Zelle: "ich bin offen").

Gruß Xel66

[blackhole]

Hmmm... das sind auch auch alles Montageorte mit eher stark schwankenden Temperaturen bzw. potenziell niedrigen Temperaturumgebungen.

Das spielt bei meiner Betrachtung keine Rolle, da ich mit den (annähernd konstanten) Zahlen der vergangenen 6 Jahre an den jeweiligen Einsatzorten vergleiche. Ich setzte auch seit Anbeginn immer die gleichen Batterietypen ein (Varta Industrial).

[darkbrain85]

Wie ist es denn nun eigentlich?

Hat EQ3 genügend Informationen und Logs, oder muss noch was geliefert werden? Oder hängt der Fix nur noch im strengen internen QM fest?

[jmaus]

Wie ist es denn nun eigentlich?

Hat EQ3 genügend Informationen und Logs, oder muss noch was geliefert werden? Oder hängt der Fix nur noch im strengen internen QM fest?

Meinen Infos nach sind genug Informationen und Logs bei eQ3 eingetroffen und die Entwickler sind dabei die Sache zu analysieren und zu beheben. Nun brauch unser eins nur noch etwas Geduld und dann sollte es hoffentlich bald einen Fix geben.

[Slice]

Hallo,

also bei mir ist dieses Problem auch wieder aufgetreten.
In meiner Installation triggert ein HM-Sec-Sc2 ein Programm zur Erfassung des Brennerverbrauchs der Heizung.
Nachdem heute morgen um 10 Uhr rum der Brenner eingeschaltet wurde das Programm lief, aber das Programm um 15 Uhr immer noch gedacht hat der Brenner läuft, bin ich durch Zufall darauf aufmerksam geworden.
Ein ändern des Status von dem Hm-Sec-Sc2 hat die Zentrale nicht mehr mitbekommen. Letzter Zeitstempel war der von 10 Uhr rum, obwohl die Led grün quittiert hat.
Weiteres Phänomen ist dann, das ich via der Fernbedienung meine Hue Lampen über ein Programm nicht mehr anschalten kann.
Und die Wandtaster (je 1x HM-PB-4Dis-WM/-2) gehen auch nicht mehr. Hier habe ich meine Rollläden mit einer Direktverknüpfung auf die virtuellen Kanäle der CCU verknüpft und der Tastendruck triggert ein Programm zum verfahren der Rollläden.
Das habe ich jetzt schon 2-3x beobachten können. Wenn der Hm-Sec-Sc2 streikt läuft der Rest auch nicht mehr.
Da hilft nur der gute Reboot. Hoffentlich fixt das eq3 zeitnah.

Schöne Ostern an alle,
Slice

[jp112sdl]

eq3 zeitnah.

https://de.wikipedia.org/wiki/Paradoxon
*badumtsss*