CCU2 Update - HomeMatic löst sich sporadisch von IPS

DaveRichter · 27. Dezember 2013 um 18:18

Hi Bruno,

wenn wir nen Ticket bei eq-3 / elv aufmachen wird da mal gar nix passieren, die werden sagen dritthersteller Software Supporten wir nicht… Wenn dann müsste schon der dritthersteller nen Ticket aufmachen !

Powerfreddy · 27. Dezember 2013 um 18:36

Moin Dave,

was eq-3 sagt, oder nicht, weiss ich erst nach deren Antwort. Vorher stehe ich mir mit Vermutungen nur selber im Weg.

Da das Problem auch darin besteht, dass es mit der CCU1 oder mit der 2.5.4 (besser) funktioniert, ist das durchaus eine Möglichkeit nachzufragen. Dazu brauche ich keinen Dritthersteller oder sonst wen.

Gruß
Bruno

jf01 · 28. Dezember 2013 um 12:36

Hallo,
könnte vielleicht jemand den nachfolgenden Test durchführen:

Abschalten des Zeitservers in der CCU2

In der CCU2 Oberfläche
Einstellungen > Systemsteuerung > Zeit-/ Positionseinstellungen
NTP Zeitserver Adressen: leer
Zeitserver übernehmen
Reboot der CCU2

Es sollte nun kein Zeitserver mehr aktiv sein. Eine Kontrolle ist im Log der CCU2 (Datei messages) möglich. Hier sollten die folgenden Meldungen nicht mehr erscheinen:

Dec 23 19:14:06 homematic-ccu2 user.debug setclock: Try to get time from ntp.homematic.com
Dec 23 19:14:26 homematic-ccu2 user.debug setclock: Mon Dec 23 19:14:26 CET 2013

Bin auf das Ergebnis gespannt – bei mir läuft es jetzt schon einige Zeit ohne Fehler.

Freundliche Grüße
Josef

DaveRichter · 28. Dezember 2013 um 12:44

Hi Josef,

Test unter den von dir genannten Bedingungen läuft

DaveRichter · 28. Dezember 2013 um 13:02

Hi Josef,

hat leider nicht geholfen…

nach 11 minuten hat die CCU2 (fw 2.7.8) „zu gemacht“
wieder die schon bekannten xmlrpc Transport error´s

jf01 · 28. Dezember 2013 um 13:14

Hallo Dave,
Schade - ich werde einmal schauen wie es bei mir weiter läuft.

Im Wireshark Log waren zwei verschiedene Fehlersituationen sichtbar.

Bei einer Situation kommt von der CCU2 ohne erkennbaren Grund ein Reset der Verbindung. Ich hatte die Hoffnung, dass es vielleicht Zeitprobleme durch die ständige Einstellung der Uhrzeit sind. Ich werde weiter schauen und testen …

Freundliche Grüße
Josef

DaveRichter · 28. Dezember 2013 um 13:18

Hi Josef,

hast du nen script aktiv was die ServiceMessages aus der CCU2 ließt ?

jf01 · 28. Dezember 2013 um 13:29

Hallo Dave,
nein - ich mache es „von Hand“.
Mit WinSCP verbinde ich mich zur CCU -> Herunterladen
Dann öffne ich die message Datei mit Notepad++
Dann einfach nochmals (manuell) auf Herunterladen und Notepad++ aktualisiert mit der neu heruntergeladenen Datei.

r4m3u5 · 28. Dezember 2013 um 17:53

Hello Ladies,

ich denke ich komme der Sache näher (dachte ich schon einige Male!)

Was mir helfen würde um Vergleichswerte zu haben (wer mag und kann…ist non-destructive, sofern man sich nicht brutal vertippt):

Auf der Konsole der CCU2 mal folgendes eingeben:

ps -ef | grep ntpclient

Dann den angezeigten ntpclient-Befehl kopieren und ausführen.

Bsp.:

ntpclient -h mein_ntp_server.dingsbums.local -l

… und den Output posten (wenn einer kommt, wenn nicht hilft das auch)

Mit + geht´s zurück auf die Konsole.

Das gleiche nochmals mit einem „-t“ am Ende:

ntpclient -h mein_ntp_server.dingsbums.local -l -t

Danach, je nachdem wie das bei Euch aussieht, den Hostnamen/die IP-Adresse mal durch „ptbtime1.ptb.de“ ersetzen:

ntpclient -h ptbtime1.ptb.de -l

und

ntpclient -h ptbtime1.ptb.de -l -t

… und wieder den Output posten.

Danke schon jetzt!

/Jens

exchange · 28. Dezember 2013 um 18:35

Hallo,
hattet ihr eigentlich auch die Probleme mit der 2.5.4? Ich nutze die CCU2 seit einem halben Jahr und einmal hat die sich verabschiedet. Ich habe das Update noch nicht gemacht und würde es ggf. auch nicht machen. In den Release Notes habe ich nichts ansprechendes für mich gefunden.
Als NTP Server nutze ich übrigens schon seit Anbeginn der Zeit ptbtime1.ptb.de und das Teil läuft auch keine Sekunde falsch (gerade noch nachgesehen).

DaveRichter · 28. Dezember 2013 um 20:53

Hi Jens,

was hast du denn konkret in verdacht ?..

BTW:

r4m3u5 · 28. Dezember 2013 um 23:13

Das mit dem ntpclient-Test hat sich erledigt. Ich konnte es hinreichend nachstellen.

Die „falsche“ Zeit ist nicht das eigentliche Problem, wenn aber die CCU2 sich bereits auch nur wenige Sekunden in der Vergangenheit oder schlimmer noch, in der Zukunft befindet, beschleunigt es das Auftreten der „XmlRpc transport errors“ ganz erheblich. Wie wir ja gelernt haben ist nach 10 dieser Tierchen dann Schluß -> IPS raus aus der RFD.handlers.

Der besagte auf der CCU2 verwendete „ntpclient“ ist der Schmiede eines schlauen Kopfes namens Larry Doolittle entstanden. Das Teil ist schlank, tut was es soll, hat nur den „Schönheitsfehler“, dass es extremen Wert auf RFC4330-Konformität legt. Ich unterstelle eq-3 an der Stelle mal einen gut gemeinten „Sicherheitsgedanken“. Auf Hessisch: wenn nicht mit „-t“ gestartet, dann bekommt man beim Versuch die Zeit zu holen von vielen NTP-Servern einfach ´nen Stinkefinger gezeigt statt der aktuellen Zeit (… jedes andere Gerät in meinem Zoo macht das völlig ohne Murren!). Der „ntpclient“ quittiert das mit z.B.

41634 72949.176  rejected packet

Wenn ich mal wieder viel Zeit habe mache ich meinen NTP mal RFC4330-konform. Wer das auch unbedingt auf dem eigenen NTP extra für die CCU2 haben muss, hier der Teil Source-Code, der die Überprüfung im „ntpclient“ macht:

if (ntpc->cross_check) {
if (li == 3) FAIL("LI==3");  /* unsynchronized */
        if (vn < 3) FAIL("VN<3");   /* RFC-4330 documents SNTP v4, but we interoperate with NTP v3 */
        if (mode != 4) FAIL("MODE!=3");
        if (orgtime.coarse != ntpc->time_of_send[0] ||
            orgtime.fine   != ntpc->time_of_send[1] ) FAIL("ORG!=sent");
        if (xmttime.coarse == 0 && xmttime.fine == 0) FAIL("XMT==0");
        if (delay > 65536 || delay < -65536) FAIL("abs(DELAY)>65536");
        if (disp  > 65536 || disp  < -65536) FAIL("abs(DISP)>65536");
        if (stratum == 0) FAIL("STRATUM==0");  /* kiss o' death */

Dumm nur, dass keiner mal Bescheid sagt, wenn man den Befehl nicht selbst manuell ausprobiert oder einen Uhrenvergleich WebUI <> IPS-Server o.ä. anstellt. Die Uhrzeit ist dann halt irgendeine Uhrzeit … wer braucht schon die „wirkliche“
PTBTIME1.PTB.DE oder der HM-NTP funktionieren hier einwandfrei, man sollte sich nur fragen inwieweit das hilft wenn mal die Verbindung ins INet weg, ausgelastet oder … was auch immer ist?! Die Meldung „NTP Server wurden gespeichert“ in der WebUI ist somit nicht gelogen, dass der oder die dann auch funktionieren hat ja keiner behauptet … :rolleyes: Da relativ oft die Zeit gezogen wird traut man in Leer wohl der internen Uhr auch nicht wirklich. Vielleicht wurde der Quarz für den Zeitgeber in der Ausbildungswerkstatt gefeilt!!! Aber das ist alles nur Beiwerk um Euch zu unterhalten :D:D:D

Der Wurzel allen Übels bin ich auch nah auf den Fersen. Zumindest kann ich den Fehler super reproduzieren. Man nehme: einen HM-Dimmer (reicht!), stelle eine Dimmzeit von 5-10 Sek. ein und dann immer lustig hoch und runter dimmen lassen (funktioniert klasse mit CCU-Programm „Fensterkontakt <> Dimmer“ … Tür auf - Tür zu - Tür auf …) … nur eine Frage der Zeit, meist klappt´s nach wenigen Versuchen wenn gerade noch andere Gerätschaften Daten in Richtung IPS abladen.
In IPS sieht es so aus wenn es noch funktioniert:

28.12.2013 20:41:19.286 | 24202 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Anwesenheit\Bewegungsmelder2\MOTION_DETECTOR\BRIGHTNESS] = 48
28.12.2013 20:41:19.286 | 48107 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Anwesenheit\Bewegungsmelder2\MOTION_DETECTOR\MOTION] = True
28.12.2013 20:41:19.302 | 45929 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Anwesenheit\Bewegungsmelder2\MOTION_DETECTOR\INSTALL_TEST] = True
28.12.2013 20:41:20.145 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,005
28.12.2013 20:41:20.161 | 44705 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\WORKING] = True
28.12.2013 20:41:20.177 | 52465 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\DIRECTION] = 1
28.12.2013 20:41:20.177 | 10728 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_REDUCED] = False
28.12.2013 20:41:20.192 | 28014 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERLOAD] = False
28.12.2013 20:41:20.208 | 48803 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERHEAT] = False
28.12.2013 20:41:20.224 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,08
28.12.2013 20:41:20.224 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,14
28.12.2013 20:41:20.270 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,195
28.12.2013 20:41:20.489 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,245
28.12.2013 20:41:20.770 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,285
28.12.2013 20:41:21.552 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,32
28.12.2013 20:41:21.552 | 44705 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\WORKING] = True
28.12.2013 20:41:21.567 | 52465 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\DIRECTION] = 1
28.12.2013 20:41:21.583 | 10728 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_REDUCED] = False
28.12.2013 20:41:21.599 | 28014 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERLOAD] = False
28.12.2013 20:41:21.614 | 48803 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERHEAT] = False
28.12.2013 20:41:21.645 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,355
28.12.2013 20:41:21.645 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,38
28.12.2013 20:41:21.833 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,405
28.12.2013 20:41:22.114 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,425
28.12.2013 20:41:22.380 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,44
28.12.2013 20:41:22.630 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,455
28.12.2013 20:41:22.645 | 44705 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\WORKING] = True
28.12.2013 20:41:22.661 | 52465 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\DIRECTION] = 1
28.12.2013 20:41:22.661 | 10728 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_REDUCED] = False
28.12.2013 20:41:22.739 | 28014 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERLOAD] = False
28.12.2013 20:41:22.755 | 48803 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERHEAT] = False
28.12.2013 20:41:22.911 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,47
28.12.2013 20:41:22.927 | 40982 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Kellergeschoss\Waschküche\Wäschetrockner\POWERMETER\BOOT] = True
28.12.2013 20:41:22.958 | 57022 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Kellergeschoss\Waschküche\Wäschetrockner\POWERMETER\ENERGY_COUNTER] = 9,5
28.12.2013 20:41:23.020 | 18012 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Kellergeschoss\Waschküche\Wäschetrockner\POWERMETER\POWER] = 0,06
28.12.2013 20:41:23.067 | 36298 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Kellergeschoss\Waschküche\Wäschetrockner\POWERMETER\CURRENT] = 19
28.12.2013 20:41:23.083 | 12786 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Kellergeschoss\Waschküche\Wäschetrockner\POWERMETER\VOLTAGE] = 235,8
28.12.2013 20:41:23.083 | 34600 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Kellergeschoss\Waschküche\Wäschetrockner\POWERMETER\FREQUENCY] = 50,01
28.12.2013 20:41:23.177 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,48
28.12.2013 20:41:23.489 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,49
28.12.2013 20:41:23.770 | 13835 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,5
28.12.2013 20:41:23.786 | 44705 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\WORKING] = False
28.12.2013 20:41:23.802 | 52465 | MESSAGE | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\DIRECTION] = 0
28.12.2013 20:41:28.380 | 13835 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,5
28.12.2013 20:41:28.395 | 44705 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\WORKING] = False
28.12.2013 20:41:28.458 | 52465 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\DIRECTION] = 0
28.12.2013 20:41:28.458 | 10728 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_REDUCED] = False
28.12.2013 20:41:28.474 | 28014 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERLOAD] = False
28.12.2013 20:41:28.489 | 48803 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERHEAT] = False
28.12.2013 20:41:33.802 | 13835 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\LEVEL] = 0,5
28.12.2013 20:41:33.817 | 44705 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\WORKING] = False
28.12.2013 20:41:33.833 | 52465 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\DIRECTION] = 0
28.12.2013 20:41:33.833 | 10728 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_REDUCED] = False
28.12.2013 20:41:33.848 | 28014 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERLOAD] = False
28.12.2013 20:41:33.848 | 48803 | DEBUG   | VariableManager      | [IPS LABOR\Stockwerke\Obergeschoss\Flur\Licht\DIMMER\ERROR_OVERHEAT] = False

Ob man jetzt Werte mit Nachkommastelle braucht … ich lass es mal an der Stelle :rolleyes: Irgendwann gibt es einen „Stau“ aufgrund zu vieler Meldungen, 10 x Transport Error … und TSCHÜSS! Ob jetzt die CCU den Kram nicht los wird, es im Socket hängen bleibt, der Socket noch auf etwas wartet … ich versuch´s noch weiter einzugrenzen. Vielleicht gibt´s ja noch Hilfe von „oben“???

Ein alter Bekannter ist auch wieder oder immer noch da - der IPS-Service-Stop-Hänger. Letzte Zuckungen im Log bevor man den Dienst dann nur noch abschießen kann:

28.12.2013 18:24:25.513 | 10212 | MESSAGE | InstanceManager      | Trenne Instanz [IPS LABOR\Stockwerke\Erdgeschoss\Garderobe\Haustür\Keymatic\FB (Ersatz)\MAINTENANCE]28.12.2013 18:24:25.513 | 10212 | MESSAGE | HomeMatic Device     | Lösche...
28.12.2013 18:24:25.513 | 10163 | MESSAGE | InstanceManager      | Trenne Instanz [IPS LABOR\Stockwerke\Erdgeschoss\Wohnzimmer\Terrassentür (rechts)\MAINTENANCE]
28.12.2013 18:24:25.513 | 10163 | MESSAGE | HomeMatic Device     | Lösche...
28.12.2013 18:24:25.513 | 10076 | MESSAGE | InstanceManager      | Trenne Instanz [System\HM_FB19_1\KEY]
28.12.2013 18:24:25.513 | 10076 | MESSAGE | HomeMatic Device     | Lösche...
28.12.2013 18:24:25.513 | 10052 | MESSAGE | InstanceManager      | Trenne Instanz [IPS LABOR\Stockwerke\Erdgeschoss\Garderobe\Haustür\Keymatic\FB (xxxxx)\KEY]
28.12.2013 18:24:25.513 | 10052 | MESSAGE | HomeMatic Device     | Lösche...
28.12.2013 18:24:25.513 |     0 | MESSAGE | ModuleLoader         | #Modul entladen: HomeMatic Device
28.12.2013 18:24:25.513 | 42346 | MESSAGE | InstanceManager      | Trenne Instanz [HomeMatic Socket -CCU2-1-]

In diesem Fall hing der Socket für die 1. CCU2. Zum 2. kam es offensichtlich nicht mehr.
Mit Sicherheit gibt es da noch Verbesserungsbedarf. Ob allerdings vorhandene Fehler auf CCU-Seite (… ich arbeite noch an den Details) durch Änderungen in IPS beseitigt werden können ist fragwürdig.

Ich verspreche auch die Posts in Zukunft kürzer, prägnanter und evtl. mit weniger Sarkasmus zu gestalten! :o

Schönen Abend!

/Jens

Powerfreddy · 28. Dezember 2013 um 23:35

Der war nicht gemeint. Gegen Lösungsansätze oder Überlegungen, … habe ich nichts, bitte daher nicht falsch zitieren oder aus dem Zusammenhang reissen. :rolleyes:

Habe auf die Schnelle noch nicht wirklich verstanden um was es geht. Bedeutet es dass die CCU2 alle x Zeiteinheiten die Serverzeit vom Internet lädt und die Probleme dann losgehen, wenn das nicht geht bzw. die Verbindung überlastet ist ? Wäre zumindest eine Erklärung dass es während eines Backups bei mir zu dem Fehler kommt.

Gruß
Bruno

DaveRichter · 28. Dezember 2013 um 23:50

ich denke das ich weder falsch zitiert habe oder irgendetwas aus dem Zusammenhang gerissen habe…
ist ja nen forum, kann ja jeder lesen…

aber keine Panik ich halte mich in zukunft zurück

egonkernien · 29. Dezember 2013 um 00:08

Hallo!
Ich schreib auch nichts mehr.
Egon

r4m3u5 · 29. Dezember 2013 um 00:16

Yep! So ist es! Bzw. vom über die WebUI konfigurierten NTP Server.
Es war auch mehr als Hinweis gedacht mal zu checken ob die Zeit auch wirklich per NTP bei der CCU ankommt (für diejenigen die eben z.B. einen NTP Server im LAN nutzen; FritzBoxen, viele Switches, APs, usw. bieten es ja sinnvollerweise an für die internen Clients NTP-Server zu spielen).
Ich konnte definitiv einen Zusammenhang „falsche Zeit“ <> „kürzere Zeit bis Einstellen der Kommunikation“ feststellen. Ganz bescheiden ist es im Zusammenspiel mit IPS-Versionen vor paresy’s KeepAlive-Implementation. Zeitweise hielt es nur Minuten nach einem Neustart des Servers und/oder der CCU2.

Nall-chan · 29. Dezember 2013 um 00:26

Habe auch mal schnell nachgesehen:
Der ntpclient der CCU2 und die FritzBox vertragen sich bei mir. Keine ntpclient Fehler im Log.
Michael

r4m3u5 · 29. Dezember 2013 um 01:51

Meinst Du mit Log die „/var/log/messages“? Da laufen die Fehler nicht rein, da es offensichtlich von der CCU nicht als Fehler behandelt wird.

Wenn ich es gegen meine FB mache kommt das hier:

# ntpclient -h <IP_der_FBox> -l
41635 02656.308  [b]rejected packet[/b]

Im Gegensatz zu:

 ntpclient -h <IP_der_FBox> -l [b]-t
[/b]41635 02902.539    1375.0    396.0  276455.4 10165847.8   -520166

AEAlexander · 29. Dezember 2013 um 06:39

Begleitende Erkenntnis: Verschiedene Fritboxversionen verhalten sich unterschiedlich.

Konkret: mit OS 6.01 wurde seitens AVM scheinbar der Fehler HINZUgefügt

FB 7390 Fritz!OS 05.53: 41635 19564.043 28187.0 413.0 12687.0 19363.4 -1275592
FB 7390 Fritz!OS 06.00: 41635 19576.516 1343.0 0.0 94284.5 42739.9 -1275592
FB 7390 Fritz!OS 06.01: 41635 20086.170 rejected packet

r4m3u5 · 29. Dezember 2013 um 13:29

Ah! Danke! Das erklärt´s!