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

[Bernd-Joras]

Auch nur zur Info ... auch bei mir ist nicht absehbar wann das Ereignis "HM-Sec-SCo Kommunikationsstörung" wieder Auftaucht ...
Ich habe das Gefühl so immer innerhalb einer Woche nach einem CCU reboot ...
Ich kontrolliere das nun täglich mehrmals ... Abwarten ... vielleicht habe ich Wudu-technisch alles weggezaubert und das "Ereignis" kommt nie wieder.
BG, Bernd

[MichaelN]

Ich denke das Problem kann nur EQ3 vollumfänglich analysieren und beheben.
Tritt es denn auch auf einer "sauberen" CCU mit nur einem HM-Sec-SCO auf? Dann könnte man das mit dem Backup bei EQ3 reklamieren.

[darkbrain85]

Nach einem Reboot ist alles wieder schön. Der Status der TFK wird auch wieder an die CCU gemeldet.
Logfiles zeigen nichts auffälliges.

Mal warten ob es wieder passiert...

[stan23]

Mal einen ruhigen Tag abwarten und bis dahin werden sie durch IP-TFKs ersetzt - liegen ja in der Schublade.

Da haben wir den Grund: eine Verschwörung von eQ-3 um Rebellen wie Günter dazu zu zwingen, auf HmIP umzusteigen

Bei mir laufen 19 Stück HM-Sec-SCo mit FW 1.0 unter RaspberryMatic 3.61.5.20211113 ohne Auffälligkeiten.
Keiner davon ist in eine DV eingebunden.

[Bernd-Joras]

Ich würde mich glatt dazu hinreißen lassen ein System neu und nackt mit nur einem HM-Sec-SCo aufzubauen.
ABER ... was bringt es, wenn ich dann nicht suchen kann woran es liegt ...
Hat jemand Infos, Tipps was ich dann wo, wie an welcher Stelle analysieren und oder kontrollieren sollte?
Ab gesehen davon dauert der Versuchsaufbau incl. dem Auftreten des Fehler ggf. 1-3 Wochen ... wenn überhaupt …
Bin mir echt nicht sicher ob sich die Mühe bezahlt macht ... ob es anschließend ein sinnvolles Ergebnis bringt.
BG, Bernd

[darkbrain85]

Hilft denn bei allen ein reboot um das Problem vorerst zu beseitigen?

Hier bei Daimler

Neu gebootet hatte ich zwar in der Aufstellung vergessen, aber das ist ja selbstverständlich.

scheint es ja nichts gebracht zu haben.

[blackhole]

Keiner davon ist in eine DV eingebunden.

Bei mir sind 20 von 23 HM-Sec-SCo in Heizungsgruppen eingebunden und haben somit alle DVen.
Die 3 weiteren kommen, jeweils ohne DVen, an Garagentor, Briefkastenklappe und Briefkastentüre zum Einsatz.
Ein maßgeblicher Unterschied, dürfte neben möglicher Addons, das von mir verwendete Roaming sein.
Ich vermute aber, dass das nicht weiter relevant ist. Hier spielen wöhl andere Mächte eine Rolle.

[Daimler]

Hi,

alls ich weitere Informationen von Interesse, für Vergleiche oder Tests etc. zuliefern kann, so reiche ich diese gerne nach.

Klar!

frage ich mich (wieder einmal), was ich anders mache.

Wenn du die Antwort weißt.

eine Verschwörung von eQ-3 um Rebellen wie Günter dazu zu zwingen, auf HmIP umzusteigen

Das wird es wohl sein.

Aber nun zum Thema:
Habe soeben eine der Leichen gegen das IP-Pendant getauscht.
Dazu muss man ja die Abdeckung und die Batterie entfernen.
Als das HM-Teil dann vor mir auf dem Schreibtisch lag und ich die Batterie einlegte, fiel mir auf, dass die SM 'Ist gestört' weg war, dafür aber eine Sabotage-Meldung.
Also Kommunikation OK.
Auch der TFK blinkte bei x Mal auf und zu Orange-Grün - aber der Zustand im WebUI änderte sich nicht!
Nun habe ich zuerst einmal ins Protokoll geschaut:

Auch im Log (nach dem Update):

Code: Alles auswählen

Line 309604: Nov 30 09:35:55 192.168.10.208 rfd: RX for MEQ0287556: @1878816075 RSSI=-52dB 0x37AABB -> 0x000000 CONDITIONAL_SWITCH [PEQ0629144]:
	Line 309612: Nov 30 09:35:55 192.168.10.208 rfd: Event: MEQ0287556:1.LOWBAT=false
	Line 309617: Nov 30 09:35:55 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]
	Line 310077: Nov 30 09:36:08 192.168.10.208 rfd: RX for MEQ0287556: @1878828837 RSSI=-60dB 0x37AABB -> 0x000000 INFO_ACTUATOR_STATUS [PEQ0629144]:
	Line 310086: Nov 30 09:36:08 192.168.10.208 rfd: Event: MEQ0287556:1.ERROR=7
	Line 310087: Nov 30 09:36:08 192.168.10.208 rfd: Event: MEQ0287556:1.LOWBAT=false
	Line 310089: Nov 30 09:36:08 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."ERROR"=7 [execute():iseXmlRpc.cpp:321]
	Line 310117: Nov 30 09:36:08 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]
	Line 310192: Nov 30 09:36:10 192.168.10.208 rfd: RX for MEQ0287556: @1878830497 RSSI=-42dB 0x37AABB -> 0x000000 CONDITIONAL_SWITCH [PEQ0629144]:
	Line 310200: Nov 30 09:36:10 192.168.10.208 rfd: Event: MEQ0287556:1.LOWBAT=false
	Line 310204: Nov 30 09:36:10 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]
	Line 313175: Nov 30 09:37:13 192.168.10.208 rfd: RX for MEQ0287556: @1878894037 RSSI=-47dB 0x37AABB -> 0x000000 CONDITIONAL_SWITCH [PEQ0629144]:
	Line 313183: Nov 30 09:37:13 192.168.10.208 rfd: Event: MEQ0287556:1.LOWBAT=false
	Line 313187: Nov 30 09:37:13 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]
	Line 317657: Nov 30 09:40:22 192.168.10.208 rfd: RX for MEQ0287556: @1879083136 RSSI=-48dB 0x37AABB -> 0x000000 CONDITIONAL_SWITCH [PEQ0629144]:
	Line 317665: Nov 30 09:40:22 192.168.10.208 rfd: Event: MEQ0287556:1.LOWBAT=false
	Line 317669: Nov 30 09:40:22 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]

Nur noch Einträge zu Batterie und Error.
Und das bei allen HM TFKs SC und SCo, kein State mehr und auch keine Statusmeldung.

Leider lasse ich das Log wöchentlich rollieren und so entzieht es sich meiner Kenntnis, wie es vor dem Update war,

/Edith:
Übrigens mit und ohne

Ein maßgeblicher Unterschied, dürfte neben möglicher Addons, das von mir verwendete Roaming sein.

[jp112sdl]

Code: Alles auswählen

0x37AABB -> 0x000000

Komisch, wird an die Broadcastadresse gesendet.
Hab grad nix zum Verifizieren hier, aber vielleicht kann mal jemand ohne dieses Problem nachschauen, ob die Telegramme an 000000 gesendet werden statt der CCU Adresse

[Daimler]

Hi,

also zum. im Dez. 19 (k.A: welche FW das war ) sahen die Events noch so aus:

Code: Alles auswählen

	Line 210868: Dec 17 20:15:53 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."STATE"=true [execute():iseXmlRpc.cpp:321]
	Line 210869: Dec 17 20:15:53 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]
	Line 210910: Dec 17 20:15:57 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."STATE"=false [execute():iseXmlRpc.cpp:321]
	Line 210911: Dec 17 20:15:57 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]
	Line 220401: Dec 17 20:39:29 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."STATE"=false [execute():iseXmlRpc.cpp:321]
	Line 220402: Dec 17 20:39:29 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."ERROR"=0 [execute():iseXmlRpc.cpp:321]
	Line 220403: Dec 17 20:39:29 192.168.10.208 ReGaHss: Info: Event="MEQ0287556:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:321]

Und die Einträge 0x37AABB -> gab es da noch nicht.