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

[Xel66]

Und was sollte solch ein WatchDog bitte als Bedingung nehmen um entsprechend auszulösen? Ist ja nicht so das die gesamte Kommunikation nicht mehr geht ...

Nun ja, was das zuverlässig und reproduzierbar auslösen könnte, wüsste ich auch nicht wirklich. Könnte ja sein, dass da irgendein Interrupt oder KeepAlive zu überwachen ist. Allerdings habe ich in so einem Zustand Kommunikationsstörungen quer durchs ganze System (HM und HmIP), so dass ich davon ausgehe, dass sich das ganze Funkmodul weggehängt hat.

Als erstes werden bei mir natürlich die Geräte mit zyklischer Statusmeldung durch die CCU vermisst (alle Thermostate und Thermosensoren). Wenn ich dann eine Größenordnung jenseits 50 Geräte anstehen habe, habe ich meist die CCU neu gestartet. Ist ja auch wenig sinnvoll zu warten, bis das ganze System auf der Nase liegt und sich im schlechtesten Fall noch die ganze CCU weghängt. Bisher konnte ich nämlich immer noch remote meine CCU neu starten, weil mich das Desaster jedes Mal beim Verlassen des Hauses ereilte. Also genau zu einem Zeitpunkt, zu dem ich keine Zeit für tiefergehende Recherchen habe.

Darum habe ich mir zumindest mal ein Programm zusammengestellt, welches mit die Logdateien per Mail zusendet, um wenigstens mal einen Ansatzpunkt zu finden. Als Trigger habe ich einfach die Anzahl der Servicemeldungen größer 50 genommen. Zusätzlich überlege ich, ob ich mir nicht einen automatischen Reboot einbaue. Aber im Moment ist mir die Gefahr einer Reboot-Schleife noch zu groß, so dass ich mich aussperren würde (könnte man zwar mit Verzögerungen entschärfen), darum lasse ich im Moment noch die Finger davon. So dringend ist es ja nicht.

Gruß Xel66

[Xel66]

Soooo... nun hatte ich nach längerer Zeit mal wieder einen unerklärlichen Anstieg von Servicemeldungen. Die Logfiles geben natürlich nichts her. Ich kann meiner CCU vorzüglich beim Triggern und Ausführen von Programmen zuschauen (mitlesen), aber es gibt keine Error-Meldungen. Nur Massen von "verbose"-Meldungen aber nichts Verwertbares. Die Therorie mit dem Telegrammzähler meine ich auch bestätigen zu können. Die CCU fängt auch den TFK nicht mehr ein.

Wie in meinem Screenshot ersichtlich, hat der TFK-Bad zwei Meldungen hintereinander abgesetzt, ohne auf Quittung von der CCU zu warten. Diese hat aber das erste Telegramm, mit dem nun falschen Counter bestätigt. Der TFK versucht es noch ein paar Mal, bekommt aber immer Quittungen mit dem falschen Zähler. Nach dem fünften Mal sind sich beide bezüglich des Counters einig, aber die Servicemeldung als "Kommunikation ist gestört" bleibt trotzdem anstehen. Irgendwie verwirrend das. Habe mal das Fenster auf/zu gemacht. Das direktverknüpfte Thermostat reagiert prompt, die CCU bekommt hiervon nichts mit (LED eine ganze Weile orange und dann rot). Im Analyzer ist der "verzweifelte Versuch" ein SENSOR_EVENT an die CCU abzusetzen zu sehen, aber keine Antwort von der CCU. Eine kurze Betätigung der Config-Taste des SCo lässt die CCU auch nicht wieder mit dem TFK sprechen. Auch meine Keymatic lässt sich nicht mehr von der CCU ansprechen und wird ihre Statusmeldungen an die CCU auch nicht los.

Was mir aber noch aufgefallen ist, und was ich vorher so noch nicht festgestellt hatte ist, dass die CCU manche HmIP-Geräte (BWM und TFK) mit Burst anspricht. Fällt ins Auge, weil das ja mit rotem Flag angezeigt wird. In dem Moment ist ein mächtiges Funkgewitter los (gefühlt eine Sekunde). Ich habe noch einen 868 MHz-Empfänger von ELV (SSF 868) und kann so meinem System beim Funken "zuhören". Kann auch sein, dass das am Repeating einer HmIP-PS liegt. Das wirkt sich natürlich auf den Duty Cycle aus, der in für mein System ungewöhnliche Regionen (derzeit 62) steigt. Im Normalfall bin ich einstellig, wenn mehr im Haus los ist, dann auch mal im Bereich >10 bis 20. Ich habe schon seit heute Nachmittag einen ungewöhnlichen DC. Im Moment habe ich mein System noch nicht rebootet, weil es läuft ja derzeit noch fast alles. Nur die sieben TFK wollen einfach nicht nicht. Mit den anderen hat die CCU kein Problem. Irgendjemand noch eine Idee, was man schauen könnte?

Gruß Xel66

[Xel66]

Ach und noch was. Siehe Screenshot. Alle TFK, mit der die CCU nicht mehr reden will haben eins gemeinsam. Sie kommunizieren sowohl verschlüsselt als auch unverschlüsselt. Alle anderen ohne Verschlüsselung haben das Problem nicht. Und jetzt ist auch klar, warum die Keymatic betroffen ist. Die kommuniziert ebenfalls verschlüsselt. Ansonsten habe ich relativ wenig Geräte, die verschlüsselt kommunizieren. Sehe bei Beleuchtung und Heizung auch nicht wirklich einen Sinn darin. Bei sicherheitsrelevanten Dingen schon eher. Aber da gab es zu den weiter entfernten TFK auch mal selten Kommunikationsstörungen, so dass eben einige ohne laufen.

Gruß Xel66

[jp112sdl]

Irgendjemand noch eine Idee, was man schauen könnte?

...mit welchem Ziel?

Da eQ-3 aktiv ein Ticket zu dem Thema bearbeitet (ich hab nicht weiter verfolgt, welcher User des Threads den Staffelstab, also das Ticket, grad in der Hand hat), sollte - sofern noch Fragen zum Beheben des Bugs offen sind, diese nur von eQ-3 gestellt werden.

Hier kann zwar immer weiter an Erkenntnissen und Beobachtungen vervollständigt werden, es wird jedoch nicht dazu führen, dass die Community es fixt.
Der einzige Fix ist momentan nur ein Workaround.

[Xel66]

...mit welchem Ziel?

Um vielleicht jmaus zuzuarbeiten, damit er das in die entsprechenden Kanäle einspeisen kann. Zumindest ist sein Kommunikationsweg etwas kürzer als wenn man über den 1st Level Support geht. Die können telefonieren und Textbausteine per Mail versenden. An die Leute mit wirklichem Einblich kommt man als User äußerst selten.

Da eQ-3 aktiv ein Ticket zu dem Thema bearbeitet...

Naja, aktiv "bearbeiten" sähe anders aus. Das Problem ist ja, dass dieses ein sporadisches Problem zu sein scheint, welches sich zudem nicht mal provozieren lässt. Damit ist ein Nachfragen auch eher sinnfrei, wenn das Problem beim entsprechenden Anwender nicht gerade im Moment besteht. Momentan sieht es für mich so aus, als ob sich die Verschlüsselung dort verabschiedet. Und zwar die des Funkmoduls und nicht die der SCo. Als das Problem heute inital bei mir auftrat, war die Keymatic nicht involviert. Ich habe nur beim Nachhausekommen festgestellt, dass ich sie nicht per Programm oder App ansprechen konnte. Glücklicherweise habe ich noch den Handsender im Auto liegen, so dass ich mir durch die Schlüsselbenutzung wenigstens keine inkonsistenten Zustände hingestellt habe.

Hier kann zwar immer weiter an Erkenntnissen und Beobachtungen vervollständigt werden, es wird jedoch nicht dazu führen, dass die Community es fixt.

Läge die Ursache in der Firmware des Funkmoduls (meine Vermutung) oder der SCo wäre sowieso die Community außen vor. Das kann nur eQ-3 fixen.

Da der Duty Cycle jetzt wieder auf Normalniveau abgesunken ist, lasse ich das erst mal weiterlaufen und werde dann morgen rebooten. Dann habe ich zumindest wieder ein paar Tage Ruhe. Vielleicht tut sich ja was. Hoffen darf man ja.

Tja, und wie ich hier so vor mich hinschreibe, stelle ich fest, dass alle Kommunikationsstörungsmeldungen gegangen sind. Das System hat sich wieder berappelt. Habe mir noch mal die Logs zusenden lassen. Glaube aber nicht, dass ich da was drin finde, denn wenn man auf "alles loggen" geht, steht einfach zu viel unwichtiger Kram drin und da der Umfang begrenzt ist, schiebt es das Wichtige raus. Mal schauen, ob der Systemlog auf der Diskstation (Loghost) was geloggt hat. Ich nehme jetzt auf alle Fälle erst mal den Loglevel zurück. Bringt ja nichts, wenn man nur ein paar Minuten drin hat.

Gruß Xel66

[Thomas.Weinreich]

Da eQ-3 aktiv ein Ticket zu dem Thema bearbeitet (ich hab nicht weiter verfolgt, welcher User des Threads den Staffelstab, also das Ticket, grad in der Hand hat), sollte - sofern noch Fragen zum Beheben des Bugs offen sind, diese nur von eQ-3 gestellt werden.

Moin,
das Ticket hatte ich eingestellt und nach langer Zeit hatte sich dan EQ-3 ja mal gemeldet das sie entgegen ersten Antworten doch noch ein paar Log's haben wollten. Da ich inzwischen einen Downgrad gemacht hatte und das halt nicht mehr machen konnte - hatte sich Bernd-Joras bereit erklärt die geforderten Log's unter meiner Ticketnummer an EQ-3 zu senden *).

Wir könnten das hier auch so machen, dann würde ich als PN meine Ticketnummer weiter geben oder ihr geht den Weg über jmaus.

Gruß
Thomas

*) seit dem (13.01. !!!) habe ich von EQ-3 nichts mehr gehört und mir ist nicht klar ob wirklich aktiv dran gearbeitet wird...

[webkeeper]

Bei mir hat nach 3 Wochen nun auch der Fehler wieder zugeschlagen. 7 optische Kontakte meldeten eine Störung. Ich bin jetzt wieder auf 3.59.6 retour.

Grüße
webkeeper

[Gluehwurm]

Drüberlernen und schon sollte es wieder gehen. Kann auch sein, daß eine Gruppe/evtl. DV erneuert werden muss.

Ich bin jetzt wieder auf 3.59.6 retour.

Hilft immerhin gegen Langeweile.

Gruß
Bruno

[jp112sdl]

Downgrade der RPI RF MOD Firmware würde reichen.

Ich kann ja morgen nachher mal ein Skript reinstellen

[jp112sdl]

Das hier mittels "Skript testen" ausführen:

Code: Alles auswählen

string out;
string err;

system.Exec("mount -o remount,rw /");
system.Exec("rm /firmware/RPI-RF-MOD/*");

system.Exec("wget -O /firmware/RPI-RF-MOD/dualcopro_update_blhmip-4.2.14.eq3 https://raw.githubusercontent.com/eq-3/occu/f88d81a54e004fb895efbe7ec829c4d1ef28dd47/firmware/RPI-RF-MOD/dualcopro_update_blhmip-4.2.14.eq3", &out, &err);
WriteLine(out#err);

system.Exec("wget -O /firmware/RPI-RF-MOD/fwmap https://raw.githubusercontent.com/eq-3/occu/f88d81a54e004fb895efbe7ec829c4d1ef28dd47/firmware/RPI-RF-MOD/fwmap", &out, &err);
WriteLine(out#err);

WriteLine("Ende - Jetzt Reboot durchführen.");

Sollte sowas im Ausagbefenster ergeben:

Code: Alles auswählen

--2022-02-01 22:12:09--  https://raw.githubusercontent.com/eq-3/occu/f88d81a54e004fb895efbe7ec829c4d1ef28dd47/firmware/RPI-RF-MOD/dualcopro_update_blhmip-4.2.14.eq3
Resolving raw.githubusercontent.com... 185.199.111.133, 185.199.110.133, 185.199.109.133, ...
Connecting to raw.githubusercontent.com|185.199.111.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 135296 (132K) [text/plain]
Saving to: '/firmware/RPI-RF-MOD/dualcopro_update_blhmip-4.2.14.eq3'

     0K .......... .......... .......... .......... .......... 37% 1.11M 0s
    50K .......... .......... .......... .......... .......... 75% 1.33M 0s
   100K .......... .......... .......... ..                   100% 2.68M=0.09s

2022-02-01 22:12:13 (1.39 MB/s) - '/firmware/RPI-RF-MOD/dualcopro_update_blhmip-4.2.14.eq3' saved [135296/135296]


--2022-02-01 22:12:13--  https://raw.githubusercontent.com/eq-3/occu/f88d81a54e004fb895efbe7ec829c4d1ef28dd47/firmware/RPI-RF-MOD/fwmap
Resolving raw.githubusercontent.com... 185.199.111.133, 185.199.110.133, 185.199.109.133, ...
Connecting to raw.githubusercontent.com|185.199.111.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 146 [text/plain]
Saving to: '/firmware/RPI-RF-MOD/fwmap'

     0K                                                       100% 1.39M=0s

2022-02-01 22:12:16 (1.39 MB/s) - '/firmware/RPI-RF-MOD/fwmap' saved [146/146]


Ende - Jetzt Reboot durchführen

Anschließend wie dort geschrieben steht -> RaspberryMatic/CCU3 neustarten.
Beim Hochfahren wird dann die neue alte Firmware auf das RPI-RF-MOD geschoben.