Ankündigung

Einklappen
Keine Ankündigung bisher.

Lösung für DCF77 Empfangsprobleme

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • swenga
    antwortet
    Hallo zusammen,

    ein Nachklapp dazu: Nachdem letzten Sommer ein Austauschgerät von Elsner aufs Dach gekommen ist lief es den Winter eigentlich ok. Jetzt kommt der Frühling (mit Gewalt!) und starken Sonneneinstrahlungen und soeben beginnt die Zeitmeldung der Wetterstation wieder das Spinnen:

    Gerade eben wurde "DCF synchron" gemeldet und als Uhrzeit 20:43...!

    Ich habe die GA fuer die Uhrzeit jetzt von der Wetterstation weggenommen und lasse nur noch den HS senden, der wiederum ueber TIME synchronisiert ist. Momentan macht meine Wetterstation also nur noch Temperatur-, Wind- und Strahlungssensor, alle anderen Berechnungen (Zeit, Sonnenstand, Beschattung) laeuft im HS und so wirds wohl auch bleiben

    mfg

    Einen Kommentar schreiben:


  • swenga
    antwortet
    @TBI: 100% ACK. Sehr gut aufbereitet.

    Ich hatte ursprünglich vor, die Zeit ausschliesslich vom DCF zu nehmen und auch die Berechnungen Sonnenstand "da oben" in der WS durchzuführen. Nach heutigen Erkenntnissen bin ich davon abgekommen

    Der erste Schritt ist ja interessanterweise im HS schon getan: Es gibt zwei verschiedene Objekte zum Empfang der EIB-Uhrzeit und zum Senden.

    Damit könnte die DCF-Uhrzeit auf dem BUS ein "nicht bestätigter" Wert sein, der nur zwischen WS und HS ausgetauscht wird. Das Ergebnis nach Abgleich und Synchronisierung geht dann über das andere KO vom HS an alle anderen Teilnehmer (Info-Displays, RTR etc.).

    BTW: Das *würg* bezog sich auf die Forderung, der Zeitserver müsse GMT+1 liefern, das wäre wirklich schräg. Wenn ich Makki richtig verstanden habe, dann ist dem aber nicht so und es ist noch ein weiterer Punkt, wo die Hilfe des Experten von der realen Implementierung abweicht. DACOM->Fix. Und ich streue Asche auf mein Haupt, da ich meine Worte etwas ausschweifennd gewählt habe.

    mfg Swen

    Einen Kommentar schreiben:


  • tbi
    antwortet
    Redundanz ! So könnte es gehen.

    Hallo Alle zusammen,

    ja Diskussionen gehen immer man hin und her deshalb sind sie ja auch so spannend. Fair sollte es immer bleiben. Ohne zweifel. Doch kommen wir zurück auf das Thema: DCF77 und was passiert wenn es nicht geht.

    Ich fasse nochmal zusammen: Es kann also passieren, das ein falsche Zeit von einer Quelle kommt. Das geht auch bei NTP. Ist aber schon sehr unwarscheinlich. Eher würde ich es hier aus Sicherheitsgründen mal annehmen. Jemand schiebt über einen getürkten NTP-Server falsche Zeiten rüber. Das geht übrigens auch bei DCF77 (siehe TSG100 C-MAX im Umkreis von 6 Metern)

    Was ich mir also im HS wünschen würde:



    Die Möglichkeit im HS drei Zeit-Quellen gleichzeit empfangen zu können.
    1. DCF77 Uhr über KNX-BUS
    2. Erster NTP Server
    3. Zweiter NTP Server
    Über eine Mehrheitsentscheidung mit Prioritäten (so wie oben ?) die empfangenen Zeiten immer auf Plausibilität zu prüfen.

    Sollte ein Zeit abweichen (Schwelle Konfigurierbar), ist ein Alarm auf den KNX-Bus zu senden.

    @Michel: Wir dürfen aber reden .

    Bleibt dann aber noch das Problem der WS, dass die Beschattungsberechnung nur entweder AUSSCHLIESSLICH über DCF77 Uhr ODER vom KNX-BUS betrieben werden kann.

    Will ich also die DCF77 Uhr nutzen, aber die Zeit von der Mehrheitsentscheidung vom HS haben. Geht das nicht.

    Will ich die Mehrheitsentscheidung vom HS nutzen, muß ich die WS so konfigurieren, dass die Zeit vom KNX-Bus kommt. Dann ist die DCF77 Uhr in der WS aber stillgelegt. Wenn ich also die DCF77 der Ws trotzdem nutzen will (mit Abgleich mit NTP), muß muss ich die Beschattung also in den HS verlegen.

    Forderung an Elsner: Die DCF77 Uhr muß Unabhängig von der Konfiguration "welche Zeitquelle verwendet werden soll" laufen können. Das heißt auch wenn die Master-Zeit der WS vom KNX-Bus empfangen werden soll, muß die DCF77-Uhr konfigurierbar sein, also über eine anderes (2 neue) Objekt (Zeit und Datum) auf den Bus senden können.

    Das ist auch eine wichtige Erkenntnis. Für DACOM wie für Elsner.

    Wenn das geht, wäre das eine echt zeitgemäße redundante Zeit Bereitstellung. Da kann Elsner und der HS gut punkten.

    Die Zeit ist bei einem "Intelligenten Haus" nämlich ein sehr wichtiges Gut.

    Gruß Tbi

    Einen Kommentar schreiben:


  • Michel
    antwortet
    "unfair" deshalb, weil es um die Lösung des DCF-Problems bei der Suntracer ging und der funktionierende Workaround via HS jetzt deshalb "verrissen" wird, weil der HS das NTP z.Zt. nicht beherrscht bzw. der Abgleich 1* am Tag jetzt mit "würg" kommentiert wird.

    Das hat mit dem Ursprungs-Post nichts mehr zu tun und gehört dann in einen eigenen Thread.

    Ansonsten stimme ich Matthias zu: wie und womit der HS abgleicht ist mir relativ egal, solange es funktioniert. Und das tut es mit dem richtigen Server einwandfrei.

    Nebenbei beträgt die tägliche Abweichung bei meinen 4 HS ~ 2 Sekunden pro Tag. Für die Möglichkeiten des KNX ist das mehr als ausreichend. Für zeitkritische Anwendungen würde ich auf andere Lösungen setzen.

    Einen Kommentar schreiben:


  • swenga
    antwortet
    Hallo Michel,

    Zitat von Michel Beitrag anzeigen
    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

    Einen Kommentar schreiben:


  • makki
    antwortet
    @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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • tbi
    antwortet
    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

    Einen Kommentar schreiben:


  • Axel
    antwortet
    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.

    Einen Kommentar schreiben:


  • MatthiasS
    antwortet
    Zitat von Michel Beitrag anzeigen
    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

    Einen Kommentar schreiben:


  • Michel
    antwortet
    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.

    Einen Kommentar schreiben:


  • swenga
    antwortet
    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

    Einen Kommentar schreiben:


  • Michel
    antwortet
    Zitat von swenga Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • swenga
    antwortet
    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

    Einen Kommentar schreiben:


  • tbi
    antwortet
    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

    Einen Kommentar schreiben:

Lädt...
X