[gelöst] Er ist tot, Jimmy! HM-LC-Sw4-Ba-PCB lässt sich nicht mehr steuern.

[Pfriemler]

Seit gestern abend streikt der besagte 4-fach-Batterie-Aktor - er lässt sich nicht mehr von FHEM steuern. Seinen Status übermittelt er brav, auch lokale Schaltänderungen werden vollzogen, aber in Gegenrichtung stellt er sich komplett taub.

Steuere ich meinen bauähnlichen Einfachaktor (hier on-for-timer 2):

Code Auswählen Erweitern


2014.12.07 14:09:29.204 0: HMLAN_Send:  HMLAN1 S:S24DE813B stat:  00 t:00000000 d:01 r:24DE813B m:2A B011 1411AB 2E13E5 0201C800000280
2014.12.07 14:09:29.720 0: HMLAN_Parse: HMLAN1 R:R24DE813B stat:0001 t:18758270 d:FF r:FFD4     m:2A 8002 2E13E5 1411AB 0101C8402E
2014.12.07 14:09:33.525 0: HMLAN_Parse: HMLAN1 R:E2E13E5   stat:0000 t:18759149 d:FF r:FFD4     m:2B A410 2E13E5 1411AB 06010080

ist alles schön. Der Sendebefehl ist zu sehen, sowie zwei Statusänderungen beim Ein- und Ausschalten.
Beim "kaputten" aber erscheint keine Sendezeile. Logischerweise passiert also auch rückwärts nix.
Wird die erst eingetragen, wenn der Empfänger ein ACK sendet?

Händische Zustandsänderungen werden brav gemeldet, an die Zentrale, auch das Reading "PairedTo" wird aktualisiert, die Platine weiß also an wen sie senden soll.

2014.12.07 14:05:35.333 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:1871EEB9 d:FF r:FFD0     m:33 A410 529E82 1411AB 0603C800 #eingeschaltet
2014.12.07 14:05:40.797 0: HMLAN_Parse: HMLAN1 R:E529E82   stat:0000 t:18720412 d:FF r:FFD6     m:35 A410 529E82 1411AB 06030000 # ausgeschaltet (beides von Hand)

configCheck beschwert sich nur über diverse missing register lists, aber schon die Anforderung "getConfig" wird nicht prozessiert.

Any hints, folks?

P.S.: natürlich ist FHEM aktuell, neugestartet und der Aktor stromlos gemacht worden ... Stunden zuvor hat das Ding noch gearbeitet, ohne dass ich an der Konfig dazwischen irgendwas geändert habe.

[frank]

configCheck beschwert sich nur über diverse missing register lists

du bist lustig. das ist das entscheidende. alle registerreadings und peers werden aus diesen listen generiert. ohne list0 weiss fhem nicht mal mit wem das device gepairt ist. poste mal ein list. vielleicht ist die funkstrecke io => dev ungenügend.

aber schon die Anforderung "getConfig" wird nicht prozessiert.

wie sieht der log dazu aus?

[Pfriemler]

HA!!!!

@frank: es sind mehr list1 die fehlen ... FHEM war der Aktor sehr wohl bekannt, ich schrieb ja, dass das reading "PairedTo" vom Aktor ständig aktualisiert wurde.

Vermutlich war die Sache mit diesem Aktor die Spitze des Eisbergs. Inzwischen sind nämliche sämtliche Burstaktoren bei mir ausgefallen, der gestern nachmittag noch freudig arbeitende neue 1-Kanal-Aktor verweigerte ebenso den Dienst wie das 8-Kanal-Modul. Und ein getConfig auf die Module wurde zusehends zur Glückssache. Auch das MP3-Modul streikte. Die Funkstrecken betrugen in den meisten Fällen weige Meter, die Level waren stets jenseits von böse. (Zuviel darf auch nicht, weiß ich).

Ich vermute nun eine zeitkritische Testroutine in 10_CUL_HM als Ursache. Die hatte ich im ACK-Mechanismus eingepflanzt auf vielfaches Bitten eines einzelnen Herren ... sie schreibt dort ins Log und vielleicht hat das stetig anwachsende Monatslog dem Timing an dieser Stelle den Rest gegeben... Die Testroutine ist raus, das Modul reloaded und ... alles geht wieder. Ein kompletter Neustart gestern abend hatte hingegen keine Besserung gebracht.

Und wieder was dazugelernt. Danke!