Nach Update / Homematic Funk Anlernmodus konnte nicht aktiviert werden

[Gluehwurm]

... Ohne unhöflich zu wirken, du hast dir aber schon durchgelesen worum es in diesem Thread geht? ...

Habe ich gelesen, ja. Da solche Sachen meist eine Ursache haben, ich aber nicht von drei defekten Modulen ausgehe, wollte ich halt irgendwo anfangen.

Aber, Du hast recht. Dann warten wir einfach auf eine Lösung/Idee. Meine Raspis laufen schliesslich.

Bin raus

[Mortak]

^^

Ich befürchte nur langsam das da keiner mehr ne Idee hat. Das neue Modul müsste morgen da sein, mal 'schaun was das wird.

Wenn mir wer ein Modul sponsored, mache ich gerne noch mal genau das gleich wie vorher.

[grafikpower]

Also ich habe lediglich die neue Software in der Software hochgeladen und installiert. Nun wird das Funkmodul nicht mehr erkannt.

Habe gestern ein neues geordert und Mal sehen, ob alles wieder läuft.

Seltsamerweise werden mir meine Geräte nun auch nur noch in den einzelnen Räumen angezeigt. Wenn ich auf "Geräte" klicke, werden keine Einträge angezeigt.

[jmaus]

Es gibt mindestens drei Leute bei denen das "HM-MOD-RPI-PCB" nach Update/Upgrade auf die letzte Version den Geist aufgegeben hat. Ich für meinen Teil würde gerne wissen ob das was mit dem Update zu tun hat und/oder ob das Modul wirklich defekt ist. Möchte ungerne das nächste Modul zerschießen.

Sind dir denn je Fälle untergekommen bei dem eine Software in der Lage war einen Hardwaredefekt zu erzeugen? Mir noch nicht wirklich - also unter normalen Hardwareanwendungen wie die einer CCU und dem passenden Funkmodul.

Und im Bezug zur vorherigen RaspberryMatic Version hatvsich selbst an der Firmware nicht geändert. Ich würde also einfach mal sagen das entweder das Funkmodul zufälligerweise durch spannungspitzen beim ein/ausschalten defekt gegangen ist oder aber - und das halte uch für warscheinlicher - befindet sich das Funkmodul in einem undefinierten Modus sodass eine kormale Kommunikation damit nicht möglich ist. Ggf. Befindet es sich im bootloader modus oder irgendwo dazwischen. Ich würde daher einfach mal versuchen das funkmodul kompletz vom GPIO abzunehmennund damit definitiv stromlos zu machen. Einige sekunden zu warten (damit alle kondensatoren definitiv leer sind) und dann das funkmodul wieder am GPIO in betrieb zu nehmen. Und wenn auch das nicht hilft dann ein konplett frisches RaspberryMatic auf eine frische SD Karte machen und ggf. sogar vorversionen von RaspberryMatic zum testen zu nutzen.

[deimos]

Hi,

Sind dir denn je Fälle untergekommen bei dem eine Software in der Lage war einen Hardwaredefekt zu erzeugen?

Ja, mehrfach. Bekanntester Vertreter dürfte bei der jüngeren Generation Stuxnet sein.

Ich hätte noch eine Idee: Ich habe letztens davon mitbekommen, das in einen Funkmodul die Firmware im Eimer war, das Modul hat sich nicht mehr wirklich gemeldet, also ähnliches bis identisches Fehlerbild wie hier. Ein forciertes Firmware Update des Funkmoduls hat das Problem behoben. Ich hab den genauen Befehl dafür aber grade nicht mehr im Kopf, war ein zusätzlicher Parameter beim normalen Update Befehl.

Viele Grüße
Alex

[jmaus]

Sind dir denn je Fälle untergekommen bei dem eine Software in der Lage war einen Hardwaredefekt zu erzeugen?

Ja, mehrfach. Bekanntester Vertreter dürfte bei der jüngeren Generation Stuxnet sein.

Ich redete hier von Fälle von normal Sterblichen und nicht von akademischen Fällen die Otto-Normal-Verbraucher nie zu Gesicht bekommen wird.

Ich hätte noch eine Idee: Ich habe letztens davon mitbekommen, das in einen Funkmodul die Firmware im Eimer war, das Modul hat sich nicht mehr wirklich gemeldet, also ähnliches bis identisches Fehlerbild wie hier. Ein forciertes Firmware Update des Funkmoduls hat das Problem behoben. Ich hab den genauen Befehl dafür aber grade nicht mehr im Kopf, war ein zusätzlicher Parameter beim normalen Update Befehl.

Genau das meinte ich ja mit meinen Ausführungen bzgl. komischer Zustand des Funkmoduls. Und man könnte in der Tat probieren ein Firmware-Update zu forcieren. Dafür müsste einfach AFAIR the "-f" parameter dem eq3configcmd Kommando hinzugefügt werden müssen. Wenn man also ein HM-MOD-RPI-PCB hat könnte folgende Befehlsequenz ggf. zum erfolg führen:

Code: Alles auswählen

/etc/init.d/S62HMServer stop
/etc/init.d/S61rfd stop
/etc/init.d/S60multimacd stop
/bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t HM-MOD-UART -u -f -d /firmware/HM-MOD-UART
/bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t HM-MOD-UART -c -v

Das letzte Kommando sollte dann hoffentlich die Version 2.8.6 ausgeben was dann auf eine aktuelle Firmware für das Funkmodul hindeuten sollte.

[deimos]

Sind dir denn je Fälle untergekommen bei dem eine Software in der Lage war einen Hardwaredefekt zu erzeugen?

Ja, mehrfach. Bekanntester Vertreter dürfte bei der jüngeren Generation Stuxnet sein.

Ich redete hier von Fälle von normal Sterblichen und nicht von akademischen Fällen die Otto-Normal-Verbraucher nie zu Gesicht bekommen wird.

Ok, gerne ein anderes recht aktuelles Beispiel: Ubuntu 17.10 zerstört BIOS u.A. von Lenovo Laptops

Viele Grüße
Alex

[Mortak]

Es gibt mindestens drei Leute bei denen das "HM-MOD-RPI-PCB" nach Update/Upgrade auf die letzte Version den Geist aufgegeben hat. Ich für meinen Teil würde gerne wissen ob das was mit dem Update zu tun hat und/oder ob das Modul wirklich defekt ist. Möchte ungerne das nächste Modul zerschießen.

Sind dir denn je Fälle untergekommen bei dem eine Software in der Lage war einen Hardwaredefekt zu erzeugen? Mir noch nicht wirklich - also unter normalen Hardwareanwendungen wie die einer CCU und dem passenden Funkmodul.

Und im Bezug zur vorherigen RaspberryMatic Version hatvsich selbst an der Firmware nicht geändert. Ich würde also einfach mal sagen das entweder das Funkmodul zufälligerweise durch spannungspitzen beim ein/ausschalten defekt gegangen ist oder aber - und das halte uch für warscheinlicher - befindet sich das Funkmodul in einem undefinierten Modus sodass eine kormale Kommunikation damit nicht möglich ist. Ggf. Befindet es sich im bootloader modus oder irgendwo dazwischen. Ich würde daher einfach mal versuchen das funkmodul kompletz vom GPIO abzunehmennund damit definitiv stromlos zu machen. Einige sekunden zu warten (damit alle kondensatoren definitiv leer sind) und dann das funkmodul wieder am GPIO in betrieb zu nehmen. Und wenn auch das nicht hilft dann ein konplett frisches RaspberryMatic auf eine frische SD Karte machen und ggf. sogar vorversionen von RaspberryMatic zum testen zu nutzen.

Hab ja nicht gesagt das Du schuld bist, aber ja, kaputte Firmware kann Hardware "unbrauchbar" machen.

Ich denke ja auch schon eine Weile das das irgendeine Firmware Problematik ist. (FHEM o.ä. macht afaik irgend welche FW Updates)

Getestet hab ich:

Code: Alles auswählen

# /etc/init.d/S62HMServer stop
Stopping HMServer: OK
# /etc/init.d/S61rfd stop
Stopping rfd: OK
# /etc/init.d/S60multimacd stop
Stopping multimacd: OK
# /bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t HM-MOD-UART -c -v
2018/10/16 18:32:12.786 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2018/10/16 18:32:12.786 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2018/10/16 18:32:14.787 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2018/10/16 18:32:14.787 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2018/10/16 18:32:16.787 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2018/10/16 18:32:16.787 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2018/10/16 18:32:17.788 <Error> CoprocessorUpdate::startApplication():Could not start Coprocessor application.

2018/10/16 18:32:17.788 <Error> Could not start Application, maybe no application on device, do update with dummy Version: 0.0.0

# /bin/eq3configcmd read-default-rf-address -f /dev/raw-uart -h
2018/10/16 18:32:33.866 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
Did not get an answer from coprocessor

Stromlos war das Ding auch schon eine Weile.

[blackhole]

Sind dir denn je Fälle untergekommen bei dem eine Software in der Lage war einen Hardwaredefekt zu erzeugen?

Ja, mehrfach. Bekanntester Vertreter dürfte bei der jüngeren Generation Stuxnet sein.

Ich redete hier von Fälle von normal Sterblichen und nicht von akademischen Fällen die Otto-Normal-Verbraucher nie zu Gesicht bekommen wird.

Ok, gerne ein anderes recht aktuelles Beispiel: Ubuntu 17.10 zerstört BIOS u.A. von Lenovo Laptops

Es geht noch naheliegender: RRDs zerstören Datenträger durch fahrlässige Implementierung.

[jmaus]

Ich denke ja auch schon eine Weile das das irgendeine Firmware Problematik ist. (FHEM o.ä. macht afaik irgend welche FW Updates)

Getestet hab ich:
[...]
Stromlos war das Ding auch schon eine Weile.

So, und dann probier nun eben wie ich oben geschrieben habe noch folgendes Kommando:

Code: Alles auswählen

/bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t HM-MOD-UART -u -f -d /firmware/HM-MOD-UART

Das sollte ein Firmware-Update erzwingen und hoffentlich das Modul wieder zum leben erwecken (im optimalen Fall).