CCU2: Zentrale dem Keyserver unbekannt

[JackoJ]

Ich habe aus Backupgründen seit sehr langer Zeit 2 CCU2. Beide haben den "aktuellsten" Firmwarestand, den eQ-3 zuletzt zur Verfügung gestellt hat.
Diese hatte ich über eine IP-Steckdosenleiste mit Strom versorgt.
Bei Ausfall oder Störung einer CCU2 konnte ich so auch von Ferne eine CCU vom Netz nehmen und die Backup-CCU danach wieder hochfahren.

Das bedeutete aber, dass ich bei Änderungen immer wieder das neueste Backup auf die andere CCU2 einspielen musste.

Das funktionierte auch bis vor wenigen Wochen problemlos.

Als ich das seit Jahren erfolgreiche Procedere Ende März wieder durchführen wollte, erhielt ich die Fehlermeldung
"Beim Einspielen des System-Backups ist ein Fehler aufgetreten........Zentrale dem Keyserver unbekannt"

Mit dieser Fehlermeldung konfrontierte ich ELV, bei der ich die CCU2 gekauft hatte. Die Antwort war äußerst schmallippig: "Wenden Sie sich an e-Q3".
Nachdem ich bei e-Q3 mehrfach nachgehakt hatte, um eine detaillierte Antwort zu erhalten, kam die Antwort:

"Es muss bei der Einspielung eines Backups der CCU Zentrale sichergestellt sein, dass die Zentrale folgende ausgehenden Verbindungen herstellen kann:
Zeitserver: 123
Keyserver: 8443 (secgtw.homematic.com)
Updateserver: 80
Über die Verbindung zum Keyserver werden in die Zentrale wieder die Keys der Homematic IP Komponenten eingelesen. Diese "holt" sich die Zentrale übrigens bei einer neuen Anmeldung von Homematic IP Komponenten ebenfalls über den Keyserver.
Bei einer lokalen Anmeldung von Homematic IP Komponenten (wenn die Zentrale nicht mit dem Internet in Verbindung steht) sind für die Anmeldung die SGTIN und der Key (zu finden auf dem QR-Code Etikett der Homematic IP Komponente) händisch einzutragen.
Der Key ist erforderlich um eine Kommunikation zwischen der Zentrale und der Homematic IP Komponente herstellen zu können."

Hat jemand ähnliche Probleme gehabt und wenn ja, was ist die Lösung?

[Supermario]

Hallo,

ich habe genau das gleiche Problem.
In meiner Backup CCU2 lässt sich auch nicht mehr ein Backup einspielen.
Das ging früher problemlos.
In anderen Beiträgen habe ich gelesen, dass man den Fehlercode 13 (Keyserver) im Script auf der CCU2 mit 10 (Okay) überschreiben soll.
Das habe ich aber nicht hinbekommen, da das Verzeichnis und das Script schreibgeschützt ist.
Die Verbindung zum Keyserver geht

Ich würde mich auch sehr über eine Lösung freuen.

Gruß
Mario

[cmjay]

Das habe ich aber nicht hinbekommen, da das Verzeichnis und das Script schreibgeschützt ist.

viewtopic.php?f=27&t=79996&p=783395#p783395

[Baxxy]

Mal so dahergedacht...
Es gibt eigentlich nur 3 Möglichkeiten wodurch dieser Fehler kommen kann.

• A: Keyserver nicht erreichbar weil im heimischen Netzwerk was geblockt wird
• B: Keyserver nicht erreichbar weil er gerade nen "Schluckauf" hat
• C: die eigenen Zentrale ist wirklich nicht (mehr) im Keyserver gelistet

A+B lassen sich mit meinem Scriptchen prüfen.
viewtopic.php?f=58&t=87432&p=852101&hil ... er#p852101

Ich denke C lässt sich auch prüfen, aber da weiß ich nicht wie.

Angenommen A+B sind OK und es ist wirklich C.
Wir spielen das Backup mit dem von @Supermario erwähnten "Hack" ein... Zentrale rebootet und will/muss rekeyen.
Das dürfte dann doch auch fehlschlagen, oder?

[Supermario]

Hallo

der "curl secgtw.homematic.com:8443" ist erfolgreich.
> curl secgtw.homematic.com:8443
> curl: (52) Empty reply from server

Den Status (13) hart auf 10 im Script (/www/config/cp_security.cgi) ändert nur die Abbruch-Fehlermeldung. Der Restore geht trotzdem nicht durch.
return $code(10)

Also was kann man tun um die Zentrale im Keyserver aufzunehmen oder den Keyserver-Test zu überspringen?

Gruß
Mario

[Supermario]

Hallo
ich habe mal versucht bei eQ3 Unterstützung zu bekommen.
Leider nicht erfolgreich.
Wahrscheinlich müssen wir zufrieden sein, dass eine CCU2 überhaupt noch geht.


Der von Ihnen genannte CCU2 ist bereits seit mehreren Jahren nicht mehr im Handel erhältlich und wurde von uns offiziell abgekündigt. Leider ist es uns nicht möglich, den Support für solche Produkte dauerhaft aufrecht zu erhalten. Bitte haben Sie daher Verständnis dafür, dass wir Ihnen zu diesem Produkt keine technische Unterstützung, Zubehör und Ersatzteile oder Dokumentationen mehr anbieten können.
Wir bedauern, Ihnen in diesem Fall keine andere Mitteilung machen zu können.

[Roland M.]

Hallo!

ich habe mal versucht bei eQ3 Unterstützung zu bekommen.
Leider nicht erfolgreich.

Bei einem schon lange abgekündigten Produkt wohl auch nicht sehr verwunderlich...


Roland

[Baxxy]

Eigentlich sollte doch jede HmIP-fähige CCU und jedes verkaufte HmIP-fähige Funkmodul in der Keyserver-Datenbank gelistet sein.
Oder fangen die jetzt an alte Geräte die schon ewig offline sind aus der Datenbank auszusortieren?

Das der Keyserver zum großen Problem werden kann ist war ja schon lange klar, das zeigt sich hier mal wieder besonders.

Ich würde bei eQ-3 nicht um Support bitten sondern klar ansagen das sie prüfen sollen ob die entsprechende Zentrale in der Datenbank ist.
Und wenn nicht dann halt darum bitten diese Zentrale aufzunehmen.

Ich meine das Thema gab's schon mal (mit dem RPI-RF-MOD oder HmIP-RFUSB) wo das Funkmodul am Ende von eQ-3 in die DB eingepflegt wurde.
Finde es aber nicht mehr.

Ansonsten taugt das alte Eisen ja noch als HM-LGW.

[jp112sdl]

Was kommt denn bei

Code: Alles auswählen

/etc/init.d/S62HMServer stop
 
/bin/checkUsrBackup.sh /etc/crRFD.conf /tmp/backup

[Supermario]

Hallo jp112sdl,

ich habe deine beiden Befehle ausgeführt.
Hier das Ergebnis:

Code: Alles auswählen

/etc/init.d/S62HMServer stop
Stopping HMServer: OK

/bin/checkUsrBackup.sh /etc/crRFD.conf /tmp/backup
20:03:51,331 DEBUG [io.netty.util.internal.logging.InternalLoggerFactory:debug] () Using SLF4J as the default logging framework
20:03:51,528 DEBUG [io.netty.util.ResourceLeakDetector:debug] () -Dio.netty.leakDetection.level: simple
20:03:51,634 DEBUG [io.netty.util.ResourceLeakDetector:debug] () -Dio.netty.leakDetection.maxRecords: 4
20:03:52,253 DEBUG [io.netty.channel.MultithreadEventLoopGroup:debug] () -Dio.netty.eventLoopThreads: 2
20:03:52,907 DEBUG [io.netty.util.internal.PlatformDependent:debug] () -Dio.netty.noUnsafe: false
20:03:53,045 DEBUG [io.netty.util.internal.PlatformDependent0:debug] () java.nio.Buffer.address: available
20:03:53,199 DEBUG [io.netty.util.internal.PlatformDependent0:debug] () sun.misc.Unsafe.theUnsafe: available
20:03:53,234 DEBUG [io.netty.util.internal.PlatformDependent0:debug] () sun.misc.Unsafe.copyMemory: available
20:03:53,258 DEBUG [io.netty.util.internal.PlatformDependent0:debug] () direct buffer constructor: available
20:03:53,294 DEBUG [io.netty.util.internal.PlatformDependent0:debug] () java.nio.Bits.unaligned: available, false
20:03:53,303 DEBUG [io.netty.util.internal.PlatformDependent0:debug] () java.nio.DirectByteBuffer.<init>(long, int): available
20:03:53,348 DEBUG [io.netty.util.internal.Cleaner0:debug] () java.nio.ByteBuffer.cleaner(): available
20:03:53,378 DEBUG [io.netty.util.internal.PlatformDependent:debug] () Java version: 8
20:03:53,388 DEBUG [io.netty.util.internal.PlatformDependent:debug] () sun.misc.Unsafe: available
20:03:53,406 DEBUG [io.netty.util.internal.PlatformDependent:debug] () -Dio.netty.noJavassist: false
20:03:53,456 DEBUG [io.netty.util.internal.PlatformDependent:debug] () Javassist: unavailable
20:03:53,596 DEBUG [io.netty.util.internal.PlatformDependent:debug] () You don't have Javassist in your class path or you don't have enough permission to load dynamically generated classes.  Please check the configuration for better performance.
20:03:53,607 DEBUG [io.netty.util.internal.PlatformDependent:debug] () -Dio.netty.tmpdir: /tmp (java.io.tmpdir)
20:03:53,626 DEBUG [io.netty.util.internal.PlatformDependent:debug] () -Dio.netty.bitMode: 32 (sun.arch.data.model)
20:03:53,639 DEBUG [io.netty.util.internal.PlatformDependent:debug] () -Dio.netty.noPreferDirect: false
20:03:53,661 DEBUG [io.netty.util.internal.PlatformDependent:debug] () io.netty.maxDirectMemory: 97386496 bytes
20:03:54,432 DEBUG [io.netty.channel.nio.NioEventLoop:debug] () -Dio.netty.noKeySetOptimization: false
20:03:54,440 DEBUG [io.netty.channel.nio.NioEventLoop:debug] () -Dio.netty.selectorAutoRebuildThreshold: 512
20:03:54,529 DEBUG [io.netty.util.internal.PlatformDependent:debug] () org.jctools-core.MpscChunkedArrayQueue: available
20:03:56,131 DEBUG [io.netty.resolver.dns.DnsServerAddresses:debug] () Default DNS servers: [/192.168.178.1:53] (sun.net.dns.ResolverConfiguration)
20:03:56,245 DEBUG [io.netty.util.NetUtil:debug] () -Djava.net.preferIPv4Stack: false
20:03:56,253 DEBUG [io.netty.util.NetUtil:debug] () -Djava.net.preferIPv6Addresses: false
20:03:56,311 DEBUG [io.netty.util.NetUtil:debug] () Loopback interface: lo (lo, 127.0.0.1)
20:03:56,336 DEBUG [io.netty.util.NetUtil:debug] () /proc/sys/net/core/somaxconn: 128
20:03:57,067 DEBUG [de.eq3.cbcs.vertx.management.VertxManager:debug] () State changed from NONE to INITIALIZED
20:03:57,111 INFO  [de.eq3.ccu.server.ip.validation.ValidateHmIPBackup:info] () VALIDATION Step 2: initialize device descriptions Base path: /etc/crRFD.conf
20:05:02,493 INFO  [de.eq3.ccu.server.ip.validation.ValidateHmIPBackup:info] () VALIDATION Step 3: initialize kryo persistence persistence home: /etc/config/crRFD/data Base path: /etc/crRFD.conf
20:05:03,946 INFO  [de.eq3.ccu.server.ip.validation.ValidateHmIPBackup:info] () VALIDATION Step 3.1: kryo persistence directory /etc/crRFD.conf/etc/config/crRFD/data
20:05:03,976 ERROR [de.eq3.ccu.server.ip.validation.ValidateHmIPBackup:error] () The persistence directory /etc/crRFD.conf/etc/config/crRFD/data doesn't exist

Ich würde sagen, dass bei mir der VALIDATION Step 2 nicht einen Pfad liefert.
Es sollte das angezeigt werden:

Code: Alles auswählen

VALIDATION Step 2: initialize device descriptions Base path: /tmp/backup/usr/local 

und nicht wie bei mir die config-Datei

Code: Alles auswählen

VALIDATION Step 2: initialize device descriptions Base path: /etc/crRFD.conf