Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)

[quickmic]

Das koennte im einen Fall an falschen ids liegen.
Vergleich bitte die /etc/config/ids in der VM mit der im Backup.

Wenn jungfreudig, sollte es aber laufen. Verwendest du einen Sicherheitsschluessel in der CCU selbst?

Noch was, wenn du die Gateways verbindest, muss die alte CCU abgeschalten sein sonst gibts Konflikte.

[Brovning]

Das koennte im einen Fall an falschen ids liegen.
Vergleich bitte die /etc/config/ids in der VM mit der im Backup.

In meiner "ids" von der CCU-X86 stand folgendes:

Code: Alles auswählen

BidCos-Address=0x123456
SerialNumber=KEQ0111111

Habe die "sbk"-Backup-Datei der CCU1 per WinRAR geöffnet und die Daten in die vorhandene ids abgetippt.
Anschließend die CCU-X86 neugestartet. Keine Änderung. Zur Sicherheit die VM neu gestartet. Ebenfalls keine Änderung.

Wenn jungfreudig, sollte es aber laufen. Verwendest du einen Sicherheitsschluessel in der CCU selbst?

Kann man in der CCU1 bereits einen Sicherheitsschlüssel setzen? Habe zumindest nie bewusst einen gesetzt.

Noch was, wenn du die Gateways verbindest, muss die alte CCU abgeschalten sein sonst gibts Konflikte.

Meine CCU1 ist seit Freitag ausgesteckt.

Das Ändern der "ids"-Datei hat leider das Problem nicht behoben.
Muss ich nachdem ich die "ids"-Datei geändert habe meine LAN-Gateways nochmals neu hinzufügen?

[quickmic]

Das Ändern der "ids"-Datei hat leider das Problem nicht behoben.
Muss ich nachdem ich die "ids"-Datei geändert habe meine LAN-Gateways nochmals neu hinzufügen?

Nein, da musst du nichts machen. Die ids koennen auch nur ein Problem sein, wenn das Backup nicht korrekt arbeitet.

Das es bei dir ja ueberhaupt nicht geht, gibts da ein anderes Problem.

Erstens, werden die Lan-GW als "verbunden" gemeldet?
Zweitens was fuer eine Firmware hast du auf den Gateways? Bei den neuen sollte glaub ich 1.1.5 drauf sein.
Falls das nicht der Fall ist, wuerde ich die als erstes mal Updaten.

Weiters spiel nochmal dein Update ein. Du hast ja gesagt dass du nichts bedienen kannst. Wie schauts umgekehrt aus. Wenn du manuell am Aktor umschaltest, wird der Status aktualisiert in der Weboberflaeche?
Wenn das der Fall ist, ist das ein starkes Indiz fuer falsche ids.
Das wurde aber noch immer nicht erklären warum das Anlernen an blanke CCU nicht geht.

[Brovning]

Erstens, werden die Lan-GW als "verbunden" gemeldet?

Ja, habe zwei Gateways verbunden und beide sind im Status=verbunden.

Zweitens was fuer eine Firmware hast du auf den Gateways? Bei den neuen sollte glaub ich 1.1.5 drauf sein.
Falls das nicht der Fall ist, wuerde ich die als erstes mal Updaten.

Die Firmware ist 1.0.6.

Update wie folgt durchgeführt: ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -s "***mySERIAL***" -k "***myPASSWD***" -console -l 1

Code: Alles auswählen

<Info> LAN Gateway Firmware Update...
<Info> Gateway ***mySERIAL***
<Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true <Info> Updating firmware....
<Info> Update performed. Waiting for gateway to get ready.

Aktuell wird immer noch die 1.0.6 angezeigt. Ich vermute das ich bis jetzt nur die LAN-Firmware aktualisiert habe und nicht die Firmware, dessen Versionsnummer angezeigt wird.
Wie kann ich die Firmware mit "coprocessor_update_hm_only.eq3" updaten?

Weiters spiel nochmal dein Update ein. Du hast ja gesagt dass du nichts bedienen kannst. Wie schauts umgekehrt aus. Wenn du manuell am Aktor umschaltest, wird der Status aktualisiert in der Weboberflaeche?
Wenn das der Fall ist, ist das ein starkes Indiz fuer falsche ids.
Das wurde aber noch immer nicht erklären warum das Anlernen an blanke CCU nicht geht.

Ich erhalte bspw. von meinem Thermostat die Temperaturwerte und wenn ich die Solltemperatur verstelle, wird diese auch in meiner GUI aktualisiert. Es funktioniert nur das Ausführen von Befehlen nicht.

[quickmic]

Ich mach die Updates manuell:
https://www.eq-3.de/service/downloads.html?id=53

Die eigentlich Firmware lade ich von FHEM runter.
https://wiki.fhem.de/wiki/HM-LGW-O-TW-W ... AN_Gateway

Checke auch bitte die /var/ids
/var/ids und /etc/config/ids sind normalerweise verlinkt. Sie muessen beide den gleichen Inhalt haben, und mit deinem Backup uebereinstimmen.

[deimos]

Hi,

Checke auch bitte die /var/ids
/var/ids und /etc/config/ids sind normalerweise verlinkt. Sie muessen beide den gleichen Inhalt haben, und mit deinem Backup uebereinstimmen.

Nicht ganz: Die /var/ids sollte die Daten des physikalisch angeschlossenen Funkmoduls enthalten und sollte bei jeden Start aktualisiert bzw. frisch erzeugt werden.
Die /etc/config/ids sollte einmalig nach einem Werksresets der CCU aus der /var/ids erzeugt werden bzw. aus einem Backup eingespielt werden. Sie enthält die Daten der Installation, welche vom rfd genutzt werden und das muss auch bei einem Wechsel der Funkhardware gleich bleiben, da ansonsten keine Kommunikation mit den Geräten möglich ist.

Viele Grüße
Alex

[Brovning]

UPDATE:
Habe folgenden Befehl ausgeführt:

Code: Alles auswählen

./eq3configcmd update-coprocessor -lgw -u -rfdconf /etc/config/rfd.conf -l 0 -c

Daraufhin habe ich eine Fehlermeldung für das LAN-Gateway im EG erhalten, bei dem ich zuvor "update-lgw-firmware" ausgeführt habe, jedoch wurde das andere Gateway im OG gefunden und aktualisiert.
Im Anschluss habe ich auch für das zweite Gateway im OG den Befehl "update-lgw-firmware" ausgeführt. Ebenfalls erfolgreich.
Nun habe ich die Version 1.4.1 auf dem zweiten Gateway im OG und immer noch 1.0.6 auf dem ersten Gateway im EG.

Anschließend habe ich den Befehl "update-coprocessor" nochmals ausgeführt. Nun werden beide Gateways nicht mehr gefunden. Ich vermute es liegt am "update-lgw-firmware".

Konnte nun meinen Schalter wieder anlernen und auch das aktivieren des Lichts per GUI funktioniert wieder!
Habe vorübergehend alle HomeMatic Geräte dem aktualisierten Gateway im OG mit 1.4.1 zugewiesen, da es mit dem funktioniert.

Wie kann ich nun mein Gateway im EG updaten, bei welchem schon "update-lgw-firmware" ausgeführt wurde und "update-coprocessor" mit einem Verbindungsfehler scheitert?

Vielen vielen Dank für deine Unterstützung ! ! !

[quickmic]

Nicht ganz: Die /var/ids sollte die Daten des physikalisch angeschlossenen Funkmoduls enthalten und sollte bei jeden Start aktualisiert bzw. frisch erzeugt werden.
Die /etc/config/ids sollte einmalig nach einem Werksresets der CCU aus der /var/ids erzeugt werden bzw. aus einem Backup eingespielt werden. Sie enthält die Daten der Installation, welche vom rfd genutzt werden und das muss auch bei einem Wechsel der Funkhardware gleich bleiben, da ansonsten keine Kommunikation mit den Geräten möglich ist.

Hi Alex

Gut zu wissen, hat aber teschnisch keinen Einfluss soweit ich feststellen konnte. Solange die ids in der config mit dem Backup zusammen stimmen, geht alles.
Bei der var/ids gehts vermutlich nur darum, dass man eine einmalige eindeutige ID generiert .Vielleicht auch wichtig fuer die Stock-Updates zur Identifikation oder gibts einen weiteren Grund?


Ps:

da ansonsten keine Kommunikation mit den Geräten möglich ist.

Ich habe verstgestellt, dass in dem Fall eine one way Kommunikation moeglich ist. Vom Aktor zur CCU, also Status korrekt, Bedienung nicht moeglich. Darum ist bei solch einem Verhalten immer meine erste Idee. ids falsch.

[quickmic]

@Juergen

Wie gesagt, versuch das Update ueber den Netfinder. Ist ein Java tool, laeuft also auch unter Linux.

[deimos]

Hi,

Nicht ganz: Die /var/ids sollte die Daten des physikalisch angeschlossenen Funkmoduls enthalten und sollte bei jeden Start aktualisiert bzw. frisch erzeugt werden.
Die /etc/config/ids sollte einmalig nach einem Werksresets der CCU aus der /var/ids erzeugt werden bzw. aus einem Backup eingespielt werden. Sie enthält die Daten der Installation, welche vom rfd genutzt werden und das muss auch bei einem Wechsel der Funkhardware gleich bleiben, da ansonsten keine Kommunikation mit den Geräten möglich ist.

Gut zu wissen, hat aber teschnisch keinen Einfluss soweit ich feststellen konnte. Solange die ids in der config mit dem Backup zusammen stimmen, geht alles.
Bei der var/ids gehts vermutlich nur darum, dass man eine einmalige eindeutige ID generiert .Vielleicht auch wichtig fuer die Stock-Updates zur Identifikation oder gibts einen weiteren Grund?

Zumindest eine zeitlang wurde daraus die Seriennummer der CCU ausgelesen, z.B. für den Hilfedialog und für die Updateprüfung. Ich bin aber aus dem Stehgreif überfragt, ob das noch der Fall ist oder ob das mittlerweil umgestellt wurde auf die Dateien unter /var/status.

da ansonsten keine Kommunikation mit den Geräten möglich ist.

Ich habe verstgestellt, dass in dem Fall eine one way Kommunikation moeglich ist. Vom Aktor zur CCU, also Status korrekt, Bedienung nicht moeglich. Darum ist bei solch einem Verhalten immer meine erste Idee. ids falsch.

Jein, das kommt etwas drauf an, ob das (un-)gesicherte Kommunikation ist und ob ein eigener Sicherheitsschlüssel vergeben wurde und ob es Broadcast Telegramme sind oder Unicast. Eine genaue Matrix habe ich jetzt leider nicht, aber es gibt auch Fälle, bei denen der Weg von Aktor zu CCU dann auch nicht klappt. Was auf jeden Fall nicht geht, ist die Rückantwort an den Aktor bei quittungspflichtigen Nachrichten, in dem Fall würde der Aktor davon ausgehen, dass die Nachricht nicht ankam und erneut senden, was ggf. die Batterielaufzeit verringern wird.

Viele Grüße
Alex