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

[jp112sdl]

Aber dieser Zusammenhang wurde hier ja (wenn ich richtig gelesen habe) bereits ausgeschlossen.

Kann. Sehr wahrscheinlich. Der Wahrnehmung einzelner nach.

Für mich ist derzeit fast nichts ausgeschlossen, außer der möglicherweise auftretenden Wechselwirkung mit Addons.
Um bei solide schwammiger Ausdrucksweise zu bleiben.

Man kann natürlich beharrlich bei einer Meinung bleiben, die aufgrund der äußeren Problemdarstellung für den ein oder anderen keinen anderen Rückschluss zulässt.

Mich ärgert es ja selbst, dass auf meinem mit Addons voll gepacktem System das Problem nicht auftritt, sonst hätte ich da schon viel mehr untersuchen können.
Das Angebot steht weiterhin: Wenn jemand wieder vor dem Problem steht, schau ich gern mal mit Teamviewer o.ä. drauf

[blackhole]

Meinst du wirklich, die haben das 10 Tage getestet?

Spielt das wirklich eine Rolle?
Die bisher bekannten Fälle hatten das Problem ja auch deutlich früher, viele haben das innerhalb weniger Stunden nach dem Update gemeldet.
Dass wirklich alle innerhalb von 10,6 Tagen betroffen sein werden, mag möglich sein, bleibt aber abzuwarten.

Code: Alles auswählen

# uptime
 19:11:58 up 7 days,  1:43,  1 users,  load average: 0.02, 0.05, 0.08

[Daimler]

Hi,

Also ... hier noch 2 weitere...

Danke für die Aufklärung, die beiden waren mir wohl durchgegangen.

Meinst du wirklich, die haben das 10 Tage getestet?

Wäre ja bei der 61.6er auch schier unmöglich gewesen.
Und nebenbei liegen zwischen Meldung beim und Antwort vom Hersteller gerade mal 1 Tag.

Das Angebot steht weiterhin: Wenn jemand wieder vor dem Problem steht, schau ich gern mal mit Teamviewer o.ä. drauf

Würde ich ja gerne annehmen.
Wenn das Problem wieder auftauchen sollte - sofort.
Aber ich mache jetzt bestimmt kein Downgrade auf einer Produktiv-Büchse.

[jp112sdl]

10,6 Tage wäre der größtmögliche zeitliche Abstand beim Senden von zyklischen Meldungen alle 60min., so dass der Telegrammzähler 1x die 255 voll macht.

Eine Ursache für das Nicht-Quittieren und auch Nicht-Verarbeiten von erhaltenen Funktelegrammen wäre z.B. das Verwerfen aufgrund doppelten Messagecounters.
So wird ja verhindert, dass Mehrfachaussendungen nicht zu Mehrfachausführungen führen. (Stichwort Replay-Attack oder auch einfache Mehrfachsendungen aufgrund nicht empfangener ACKs).

Wenn nun ein interner Prozess denkt, es hätte jegliches empfangene Telegramm schon mal erhalten und verwirft es daher, kommt keine Kommunikation mehr zustande.

Fragt sich nur: Warum nur bei manchen und nicht bei allen Usern.
Könnte ein Addon sein.

Aber ich mache jetzt bestimmt kein Downgrade auf einer Produktiv-Büchse.

Würde ich auch nicht machen, wenns jetzt einmal läuft

[Roland M.]

Hallo!

Habe gerade noch einen SCo gefunden, ich kann gerne (eine) meine(r) Test-CCU ins Rennen schicken.
Um möglichst nahe am Original zu bleiben werde habe ich den SCo an einem Original-Charly angemeldet und werde beobachten.

Sollte der Fehler auch bei mir auftauchen, stehe ich gerne für weiteres Forschen zur Verfügung.

Original-Charly mit Raspi 3 und RPI-RF-MOD
Raspberrymatic 3.61.5.20111113
AddOns: CUxD, E-Mail, Neo-Server
HM-Sec-SCo, FW 1.0, S/N MEQ...
Default-Einstellungen, also auch gesicherte Übertragung
Dummy-Programm auf der CCU angelegt
Fensterkontakt auf "protokolliert"

Soll ich sonst noch was berücksichtigen?


Roland

[Tibin]

Da ist ja mal richtig toll wie sich das hier entwickelt. So stellt man sich das vor

Für mich ist derzeit fast nichts ausgeschlossen

Da muss man nix mehr zu sagen, Daumen hoch. Und die drücke ich dir auf jeden Fall, dass dich da einer der Betroffenen auf seine Kiste lässt.

Spielt das wirklich eine Rolle?
Die bisher bekannten Fälle hatten das Problem ja auch deutlich früher,

Naja, wenn ein Anwender in seine Mail schreibt, dass das Verhalten nach einer Woche auftritt, dann sollte man schon ne Woche warten bevor man ne Standartantwort schickt. Ich habe hier auch oft von mehr als einem Tag gelesen... 3-5 oder sogar 12 bei Darkbrain85.
Aber egal...

Dass wirklich alle innerhalb von 10,6 Tagen betroffen sein werden

Das glaube ich auch eher weniger, das wäre ja wie damals als die Zeitumstellung zuschlug aber irgendwas ist auf jeden Fall faul bei so vielen Meldungen.

Aber ich mache jetzt bestimmt kein Downgrade auf einer Produktiv-Büchse.

Schade

[blackhole]

Naja, wenn ein Anwender in seine Mail schreibt, dass das Verhalten nach einer Woche auftritt, dann sollte man schon ne Woche warten bevor man ne Standartantwort schickt.

Ich glaube ja immer noch ganz fest daran, dass DIE TEST-CCU3™ von eQ-3 schon ein paar Tage Uptime auf dem Buckel hat, bevor der erste Benutzer den Fehler meldet, so dass der Support umgehend mit einer treffsicheren Standardantwort reagieren kann.

Code: Alles auswählen

# uptime
 22:32:05 up 7 days,  5:03,  1 users,  load average: 0.04, 0.10, 0.08

[darkbrain85]

3-5 oder sogar 12 bei Darkbrain85.

Aktuell habe ich 8 Tage Uptime auf der Kiste... Warum hat EQ3 nicht eine passende Zeitmaschine entwickelt?
Wobei man dann lieber nicht in der Nacht einer Zeitumstellung durch die Zeit reisen sollte.

[Tibin]

Komisch, hab vorgestern erst gelesen, dass du neu gestartet hast
Wäre aber gut wenn sich einer der im Moment Betroffenen mal melden würde, damit Jėrôme evtl zum Zug kommt
Aber sind bestimmt alle wieder zur alten Version zurück.
Es bleibt spannend....
Gruß Tino

[jp112sdl]

Wenn es nicht mehr auftritt, dann ist es halt so.
Als (ehemaliger) Betroffener würde ich auch nicht drauf warten (wollen), dass der Mist von vorn los geht.

Ich warte hier noch den obligatorischen Beitrag von blachhole ab, dass auch nach 11 Tagen noch nichts passiert ist, und dann denke ich, ist das Thema hier durch. Oder auch nicht.