Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
Moderator: Co-Administratoren
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
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.
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.
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
In meiner "ids" von der CCU-X86 stand folgendes:
Code: Alles auswählen
BidCos-Address=0x123456
SerialNumber=KEQ0111111
Anschließend die CCU-X86 neugestartet. Keine Änderung. Zur Sicherheit die VM neu gestartet. Ebenfalls keine Änderung.
Kann man in der CCU1 bereits einen Sicherheitsschlüssel setzen? Habe zumindest nie bewusst einen gesetzt.
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?
Gruß
Jürgen
Jürgen
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
Nein, da musst du nichts machen. Die ids koennen auch nur ein Problem sein, wenn das Backup nicht korrekt arbeitet.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?
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.
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
Ja, habe zwei Gateways verbunden und beide sind im Status=verbunden.
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.
Wie kann ich die Firmware mit "coprocessor_update_hm_only.eq3" updaten?
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 hat geschrieben: ↑27.05.2019, 18:14Weiters 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.
Gruß
Jürgen
Jürgen
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
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.
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
- Beiträge: 5403
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 958 Mal
- Kontaktdaten:
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
Hi,
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
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
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
UPDATE:
Habe folgenden Befehl ausgeführt:
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 ! ! !
Habe folgenden Befehl ausgeführt:
Code: Alles auswählen
./eq3configcmd update-coprocessor -lgw -u -rfdconf /etc/config/rfd.conf -l 0 -c
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 ! ! !
Gruß
Jürgen
Jürgen
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
Hi Alexdeimos hat geschrieben: ↑27.05.2019, 21:21Nicht 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?
Ps:
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.da ansonsten keine Kommunikation mit den Geräten möglich ist.
Zuletzt geändert von quickmic am 28.05.2019, 07:52, insgesamt 1-mal geändert.
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
@Juergen
Wie gesagt, versuch das Update ueber den Netfinder. Ist ein Java tool, laeuft also auch unter Linux.
Wie gesagt, versuch das Update ueber den Netfinder. Ist ein Java tool, laeuft also auch unter Linux.
- deimos
- Beiträge: 5403
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 958 Mal
- Kontaktdaten:
Re: Anleitung zur Installation der CCU auf einem x86 system (Part 3 inkl. HMIP)
Hi,
Viele Grüße
Alex
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.quickmic hat geschrieben: ↑28.05.2019, 07:24Gut zu wissen, hat aber teschnisch keinen Einfluss soweit ich feststellen konnte. Solange die ids in der config mit dem Backup zusammen stimmen, geht alles.deimos hat geschrieben: ↑27.05.2019, 21:21Nicht 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.
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?
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.quickmic hat geschrieben: ↑28.05.2019, 07:24Ich 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.da ansonsten keine Kommunikation mit den Geräten möglich ist.
Viele Grüße
Alex