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

[Thomas.Weinreich]

Hallo Zusammen,
ich hatte am Samstag ein Ticket bei EQ-3 aufgemacht, aber die erste Antwort war ein Formular. Das habe ich brav ausgefüllt und mit einer sehr ausführliche Beschreibung des Fehlers mit dem Hinweis (aus diesem Thread) auf den Paket Counter verschickt. Ich habe außerdem seit meinem letzten Reboot vor ca. 1,5 Tagen auch einen AskSin Analyser mitlaufen um den Fehler mit den falschen Zählernummer mitzuloggen. Parallel läuft das Logging auf der CCU.

Heute kam die Antwort von EQ-3, die mir nicht so wirklich gefällt
"Wir haben Ihr Anliegen geprüft und können Ihnen keine kurzfristige Lösung anbieten. Daher wurde Ihr Sachverhalt zur Prüfung und Bewertung weitergegeben. Sofern Optimierungen möglich sind, fließen diese in die Releaseplanung ein. Bitte haben Sie Verständnis, dass eine individuelle Rückmeldung in diesem Fall leider nicht erfolgen kann."

Ich sehe daraus jedenfalls nicht ob das Thema schon bekannt ist, nachgestellt wird oder gar dran gearbeitet und weitere pers. Ind. Unterstützung gibt es wohl nicht. Also scheint der Support hier für mich wohl beendet.

Ich habe jetzt noch mal nachgefragt ob der Fehler bekannt ist und ob dran gearbeitet wird, lt. EQ-3 ist es ja allenfalls eine "Optimierung" wenn mit falschen Zählerquittungen geantwortet wird PS: Um Fragen nach Funkproblemen zu vermeiden - Die Kontakte haben alle aus reichend Empfang (min. -60 dBm) einer der Kontakte sitzt direkt neben der CCU3.

Haben wir in der Community nicht Jemanden der dort bessere Kontakte hat...

Gruß
Thomas

[jp112sdl]

Dann ist der Auslöser vielleicht doch das erste Überlaufen eines Telegrammzählers (255 -> 0) eines beliebigen HM-Sec-SCo.

lt. EQ-3 ist es ja allenfalls eine "Optimierung" wenn mit falschen Zählerquittungen geantwortet wird

Momentan weiche ich von meiner 255er und Verrechnungs-Theorie ab und tendiere zu einem Timing-Problem auf der CCU in Kombination mit einem Bug in der SCo-Firmware.

Wenn ein Sender keine Quittung vom Empfänger innerhalb eine definierten Zeitspanne (~150ms) erhält, wird das Telegramm wiederholt.
Bei dieser Wiederholung darf der Telegrammzähler nicht erhöht werden, um Mehrfachauslösungen am Empfänger zu unterbinden.
Denn es kann ja auch sein, dass der Empfänger das 1. Telegramm bereits empfangen hat und lediglich die Quittung nicht beim Empfänger ankam.

Was ich jedoch sehe, sind Telegrammwiederholungen mit neuem Telegrammzähler.
Kurz nach der Sendungswiederholung kommt die Quittung von der CCU - etwas zu spät - mit der Antwort auf das vorherige Telegramm

Mir ist im AskSinAnalyzer Log aufgefallen, dass auch bei anderen Geräten mitunter mehrere Telegrammaussendungen notwendig sind, um eine vernünftige Quittung zu erhalten.

Nur fällt es dort nicht unbedingt auf, weil da auch die Sendungswiederholungen mit dem selben Telegrammzähler erfolgen!

P.S.: Im HM-Sec-SCo steckt auch immer noch ein weiterer Bug, der nicht gefixt wurde viewtopic.php?t=52992#p527566

[blackhole]

Dann ist der Auslöser vielleicht doch das erste Überlaufen eines Telegrammzählers (255 -> 0) eines beliebigen HM-Sec-SCo.

Als das Problem bei mir am 10.12.2021 auftrat, war übrigens niemand zu Hause (Türen/Fenster alle zu) und ich hatte auch keinen Posteinwurf (TFK im Briefkasten):

Um 07:09 Uhr hat das letzte Familienmitglied das Haus verlassen (Abwesenheit).
Die letzten Zustandsänderungen der Sensoren wurden kurz vorher vom TFK an der Haustüre und vom TFK am Garagentor gemeldet.

Um 08:38 Uhr trudelte dann die erste Kommunikationsstörung ein (eines der Fenster im Spielzimmer).
Bis 09:31 Uhr haben sich dann nach und nach immer mehr Sensoren gemeldet und ich habe dann aus der Ferne eingegriffen (Reboot).

[Thomas.Weinreich]

Momentan weiche ich von meiner 255er und Verrechnungs-Theorie ab und tendiere zu einem Timing-Problem auf der CCU in Kombination mit einem Bug in der SCo-Firmware.
....

Mir ist im AskSinAnalyzer Log aufgefallen, dass auch bei anderen Geräten mitunter mehrere Telegrammaussendungen notwendig sind, um eine vernünftige Quittung zu erhalten.

Im Zusammenhang mit dem Sreenshot ist das für mich nachvollziehbar. Es ist hoffentlich auch für EQ-3 ein Anlass zumindest am Timing Problem zu arbeiten. Wenn sie noch mal reagieren sollten kann ich das gerne als Antwort zu meinem Ticket beifügen...

[blackhole]

Heute kam die Antwort von EQ-3, die mir nicht so wirklich gefällt (...)

Die vorgefertigte Standardantwort ist die, die gesendet wird, wenn das Problem nicht als bedauernswerter Einzelfall eingestuft wird. Das passt schon und du kannst die Antwort somit als persönlichen Erfolg werten. Da du nicht alleine bis, wird das jetzt seinen Weg gehen und im Idealfall zeitnah in einer korrigierten Firmware enden. Eine persönliche Unterstützung wirst du natürlich nicht bekommen. Das ist aber auch nicht nötig.

Ich habe hierbei auch nichts anderes bekommen.

[Roland M.]

Hallo!

Mach doch mal ein Fenster 128x auf und zu

Mach ich doch glatt!

Eines ist mir dabei schon aufgefallen:
Wenn ich "das Fenster aufmache" (am Schreibtisch...) und sofort wieder "schließe", solange die gelbe LED noch das Öffnen meldet, ist die LED-Folge fonlgendes:
gelb (öffen)
grün (Bestätigung öffnen)
gelb (schließen)
rot (???)
gelb (Wiederholung schließen?)
grün (Bestätigung schließen)

AskSinAnalyser hab ich leider keinen...


Roland

[Matsch]

Heute kam die Antwort von EQ-3, die mir nicht so wirklich gefällt

Also gemäß Sprachgebrauch eQ-3 (und diverser anderer Firmen) Ist die Antwort eher ein Erfolg. Ich interpretiere das so, dass man den Fehler entweder nachvollziehen konnte oder bereits kannte, sonst hätte man dich abgewimmelt. Anscheinend werden sich nun doch Entwickler damit befassen.

Dass man in der Öffentlichkeit statt "bug fixing" von "Optimierungen" redet, ist eher lächerlich, aber sattsam bekannt von anderen Firmen.
Wenn allein schon von Optimierungen gesprochen wird, heißt das so viel wie "wir bemühen uns, den Bug zu beseitigen".

Du kannst also damit zufrieden sein, du hast das maximal Mögliche erreicht.

[Baxxy]

Frage an die Protokollführer:
Betrifft das ausschließlich Systeme mit RPI-RF-MOD?

Wenn ja könnte ich mal ein Testsetup mit HM-MOD-RPI-PCB aufsetzen.
Dann könnte man die Ursache eventuell weiter eingrenzen.
(Funkmodul-Firmware / HmIP-Server)

Grüße, Baxxy

[Thomas.Weinreich]

Heute kam die Antwort von EQ-3, die mir nicht so wirklich gefällt

Also gemäß Sprachgebrauch eQ-3 (und diverser anderer Firmen) Ist die Antwort eher ein Erfolg.

...heißt das so viel wie "wir bemühen uns, den Bug zu beseitigen".

WIe war das mit dem Zeugnis, "Er war stets bemüht" ...

Du kannst also damit zufrieden sein, du hast das maximal Mögliche erreicht.

Dann drücke ich mal für uns alle das es weiter geht: Im Moment darf ich jedenfalls nicht in den Urlaub fahren, da die Alarmanlage nach ein paar Tagen eher nicht mehr "optimiert" funktioniert

[Thomas.Weinreich]

Frage an die Protokollführer:
Betrifft das ausschließlich Systeme mit RPI-RF-MOD?

Wenn ja könnte ich mal ein Testsetup mit HM-MOD-RPI-PCB aufsetzen.
Dann könnte man die Ursache eventuell weiter eingrenzen.
(Funkmodul-Firmware / HmIP-Server)

Grüße, Baxxy

Also bei mir scheint es so zu sein: Funkmodul Typ: RPI-RF-MOD mit Funkmodul Firmware: 4.4.12