Lösung für DCF77 Empfangsprobleme

[tbi]

Wo liegt die obere ?

Hallo Matthias,

weißt Du wo dann da die Grenze ist ? In der Hilfe steht nichts dazu ?

Dann sollte man doch im HS beide Grenzen frei setzen können, oder ?
Die Untere (Karenzzeit) und die Obere.

Gruß Tbi

[Michel]

Das gilt nur für den Empfang von Zeit und Datum via EIB und ist in der Hilfe auch korrekt beschrieben.

[makki]

oder SW Problem der WS und hat erstmal nichts mit DCF77 zu tun.

Richtig. 100% einverstanden. Trotzdem kaputt

Wenn der HS eine falsche Zeit von einem NTP-server bekommt,

Nochmal:
Der HS verwendet kein NTP !

sondern das uralte Time-Protokoll.
Edit: (*) Stand V2.3.2

Das hat mehrere Nachteile:
1. wird nicht dauerhaft synchronisiert sondern nur 1x täglich (warum das ein Nachteil ist steht in der RFC)
2. wird, wie Du schreibst erst bei eiber Nichterreichbarkeit des ersten ein weiterer verwendet. Dem ist bei NTP nicht so
3. existiert keine Sicherungsschicht, die Paketlaufzeiten berücksichtigt oder eine Fehlerübermittlung zulässt.

Ich widersetze mich diesem hartnäckigen HS/NTP-Gerücht deshalb so vehement, weil ich mir das nahezu perfekte NTP nicht von der schlechten implementierung des HS kaputtreden lasse, wo nur die Doku behauptet es wäre NTP.

So kenne ich es jedenfalls von Linux.

Was hat NTP mit Linux zu tun, ausser das es dafür auch Software gibt ? Vielleicht hast Du ntpdate verwendet, das mag ausreichen um einen Client gelegentlich zu synchronisieren, ein Zeitgeber für andere (was WS oder HS ja darstellen) sollte das aber *immer* anders machen und unter Linux z.B. den ntpd verwenden, siehe sämtliche RFCs von Time bis SNTP.

Zum Beispiel: DCF77 der WS und zwei NTP Server im Netz.

Es ist im Detail ein ganz klein bisschen komplizierter als ein simple Mehrheitsentscheidung
Vor weiteren Detaildiskussionen, nichts für ungut, bitte die RFC1305 lesen und die Unterschiede zwischen den verschiedenen Synchronisierungsvarianten beachten.

Fazit: Deswegen behaupte ich dass ein NTP-Server immer der bessere Zeitgeber (evtl. mit DCF77 als eine Quelle) ist als ein DCF77-Empfänger alleine, weil damit so ein Mist einfach by Design nicht passieren kann.
Und dass das im HS seites Gira/Dacom dringend von Time auf NTP umgebaut werden sollte..

@jonofe: ich würde das Signal der WS einfach in den ntpd einfüttern, der sollte das Problem reparieren. Nicht dass ich jetzt auf Anhieb wüsste wie man sowas macht aber Du bist ja sehr erfinderisch

Makki

[MatthiasS]

Geduld, muss ja nicht so bleiben, gibt ja Updates ;-)

[tbi]

Hallo,

@ Makki: Danke für das Update. Ich sehe Du hast Dich da schon sehr tief mit NTP beschäftig. Mir ist die funktionierende DCF77 eigentlich aussreichend.

Wieder was gelernt .

Bei KNX muß man halt immer selbst noch mal nachdenken, was passiert eigentlich, wenn was abraucht. Steht alles, geht nur der Gadget-Kram nicht mehr, ....

Naja bei der WS geht, wenn kein DCF77 Empfang mehr da ist, gar keine Beschattungsberechnung los (wenn auf DCF77 konfiguriert). Erst wenn eine Zeit da ist (mind. einmal DCF77 Empfang) wird die Beschattungs berechnung gestartet. Dann läuft sie aber durch, die interne Uhr arbeitet ja immer.

Interessant sind dann aber die Fehlerfälle, wo eine komplett falsche Zeit da ist, ..... so wie bei Jonofe oder Swen. Bisher dachte ich, das ist doch etwas theoretisch. Aber passieren tut es doch.

Viele Grüsse Tbi

[swenga]

Hallo Makki,

vielen Dank für die umfassende Info. In meinem Setup hat der HS ja eh keinen Zugriff nach draussen sondern nur in die DMZ. Musste grade mal auf den Proxy-Sklaven schauen, ob so etwas altbackenes wie das Time-Protocol da unterstützt wird Wird es, in TCP und UDP.
BTW, welches macht denn der HS? Im Experten wird das allen Ernstes NTP genannt, schlechter Scherz! Und dann noch nur einmal am Tag, tss...
Und was lese ich in der Hilfe: Der Server muss auf GMT+1 stehen, weil der HS die Sommerzeit selber ergänzt? Hab ich das richtig verstanden? Also entweder habe ich meinen Timeserver auf UTC oder auf local, aber dauerhaft in Winterzeit ist ja wohl *würg*

Da faellt mir doch grad ein guter Workaround ein, der Wiregate Versendet der schon Zeit und Datum auf den Bus? Und wie gehts dem Webmin-Modul für die NTP-Konfiguration?

mfg Swen

[Michel]

BTW, welches macht denn der HS? Im Experten wird das allen Ernstes NTP genannt, schlechter Scherz! Und dann noch nur einmal am Tag, tss...
Und was lese ich in der Hilfe: Der Server muss auf GMT+1 stehen, weil der HS die Sommerzeit selber ergänzt? Hab ich das richtig verstanden? Also entweder habe ich meinen Timeserver auf UTC oder auf local, aber dauerhaft in Winterzeit ist ja wohl *würg*

Interessant, welche "ollen Kamellen" hier wieder hervorgekramt werden.
Dieser Sachverhalt ist schon lange bekannt und wer Matthias "" richtig interpretiert, weiß schon wie es weitergeht.

[swenga]

Hallo zusammen,

habe mich grade nochmal belesen: Bei NTP wird immer UTC verwendet, alle Zeitzonen sind Sache des Clients. Der wiederum kann seine lokale Systemclock dann auf UTC oder die Lokalzeit setzen.

@Michel: Für Dich mögen es alte Kamellen sein, ich schlage mich momentan mit dem Problem rum. Deine Andeutung laesst in einem gewissen Vertrauensintervall den Interpretationsspielraum, mit dem nächsten HS-Update wird ein richtiges NTP unterstützt. Ist dem so? Weiss man wann?

mfg Swen

[Michel]

Wie Matthias schon schrieb:

Geduld

Mehr darf ich dazu nicht sagen.

Wenn deine Suntrace "wilde" Zeiten in der Gegend rumschickt und das Probleme verursacht, kannst du aber den HS dazu veranlassen, seine Uhr nicht mit der Zeit der Suntracer zu syncronisieren. Dazu gibt´s im Experten eine entsprechende Einstellungsmöglichkeit, die auch in der Hilfe sauber beschrieben ist.

Es ist auch IMHO ein wenig unfair, jetzt auf dem "workaround" - Gerät rumzuhacken, obwohl der Auslöser wohl was ganz anderes ist. Auch wenn der HS das NTP noch nicht richtig beherrscht.

BTW denke ich nicht, daß es sich um ein generelles DCF Problem handelt, da sich ansonsten in der Republik so einiges nicht mehr richtig "drehen" würde.
In diesem Fall ist der Hersteller der richtige Ansprechpartner. Das ist IMHO ein Gewährleistungsfall. Schliesslich funktioniert die zugesicherte Eigenschaft nicht bzw. nicht zuverlässig.

[MatthiasS]

Auch wenn der HS das NTP noch nicht richtig beherrscht.

Was ihn im übrigen nicht davon abhält, bei entsprechender Time-Server-Auswahl die Zeit perfekt zu synchronisieren, bei mir seit 7 Jahren fehlerlos.

ntp2.fau.de

P.S: Wobei mir bei perfekt funktionierender Sync eigentlich völlig egal ist, welches Protokoll das ist

[Axel]

Für diverse Wetterstationen (u.a. Hager) gibt es ein gesondertes Bauteil, wenn der DCF Empfang Probleme bereitet. Das Bauteil wird zwischen die Leitung geklämmt.

Zudem sollte die Leitungen zwischen Außenstation und Innenstation geschirmt und der Schirm auf entsprechende Klemme gelegt werden.

Durch das Auflegen dieses Schirmes, habe ich erst kürzlich eine nicht ordentlich funktionierenden DCF Empfang wieder hergestellt.

[tbi]

Genauer bitte ?

Hallo Axel,

das will ich verstehen.

Welche Leitung soll das denn sein? Bei meiner WS gibt es nur das Buskabel mit KNX-bus und der 24V Versorgungsspannung drauf. Der Schirm ist wie immer nicht aufgelegt.

Tbi

[Axel]

Das gilt nur für Stationen mit Innen- und Außeneinheit.

[makki]

@swenga: TCP macht er, steht auch alles im NTP Lexikonartikel, mit der Zeitzone in - kurzform - musste Dir keinen Kopf machen.. (Aber ich find eben auch ärgerlich, mal sehen was die Zukunft wann bringt)
Zeitversand auf den Bus geht natürlich, musst nur die GA und Zyklus eintragen, den Rest aber ggfs. anderswo, wir sind hier schon OT genug.. Und ja, das kleine schwarze kann man natürlich als Timeserver für den HS verwenden

Makki

[swenga]

Hallo Michel,

Es ist auch IMHO ein wenig unfair, jetzt auf dem "workaround" - Gerät rumzuhacken, obwohl der Auslöser wohl was ganz anderes ist.

Das die Ursache beim Suntracer liegt, hatte ich wohl schon herausgestellt. Dennoch erwarte ich auch von bisher noch nicht genutzten Funktionen im HS eine entsprechende Nutzbarkeit. Was soll daran unfair sein?

@Makki: Danke fuer die Info, werde es dann mal mit dem Time-Update probieren, wenns nicht klappt, dann darf das kleine schwarze ran

Schoenen Abend, Swen