extern über Bus synchronisierte Uhr

[Ing-Dom]

Morgen,

ich spiele schoin seit einiger Zeit mit dem Gedanken ein Uhrzeit-Modul für Konnekting-Geräte zu entwicklen. Ohne Uhrenquarz etc...

Grundidee:
- über Bus und DPT19.001 bekommt das gerade eine gültige Uhrzeit (im Hochlauf müsste man ggf. abfragen, dass kann Konnekting noch nicht, oder, ReadRequests auslösen?)
- über millis() wird die interne Uhr alle 1s um eins hochgezählt
- beim nächsten empfangenen DPT 19.001 wird die Differenz ausgewertet und ein Skalieurngsfaktor berechnet und die interne Uhr entsprechende schneller oder langsamer hochgezählt.

Was haltet ihr davon? Bedenken? Vorschläge?

Verwendbar u.a. für:

- Uhrzeit an einem Info-Display, KNX-fähige Wortuhr(Qlock2) (in Planung)
- sonstige Geräte mit Tageszähler (Regenmesser)

[andi11]

In meinem Haus wüsste ich nicht so recht wofür ich das brauchen kann aber my 2cents:
Ich fürchte jede Variante ohne Uhr ist sehr schnell ungenau. Was spricht gegen einen RTC Chip und oder DCF77? Beides wäre kostengünstig zu verwenden.

[Ing-Dom]

Ich fürchte jede Variante ohne Uhr ist sehr schnell ungenau

glaube ich nicht. Wenn jede 5 Minuten ein Korrekturtelegramm kommt und die Schwankungen des Takts getrimmt werden... mal sehen. Ich nagel mal einen Prototyp zusammen.

In einem kleinen Unterputz-Info-Display z.B. wärs doch nett eine Uhr zu haben.

DCF77 alleine bringt weniger als ein sync per KNX, denn es kommt nur 3x pro Stunde.
Beides braucht Platz, kostet Geld und macht beim löten Arbeit.

[andi11]

glaube ich nicht. Wenn jede 5 Minuten ein Korrekturtelegramm kommt und die Schwankungen des Takts getrimmt werden... mal sehen. Ich nagel mal einen Prototyp zusammen.

Das mit dem Telegramm hatte ich irgendwie anders interpretiert. Ich dachte daran dass die Telegramme viel seltener kommen (ohne dass du es geschrieben hast)
Vermutlich dürfte der Korrekturfaktor dann fast eine Konstante sein oder? Zumindest eine Konstante je Baugruppe.
Bevor ich fertige KNX Chips verwendet habe, hatte ich selbst angefangen KNX Signale zu generieren. Dabei ist mir aufgefallen dass die Schwankungen von Prozessor internen Taktgebern doch recht groß ist. Atmel AVRs kann man dafür recht gut kalibrieren, und das musste ich auch nutzen.

Ist es überhaupt schlimm wenn nach dem Hochlauf mal nicht sofort die richtige Zeit kommt? Einfach gar keine Uhrzeit anzeigen und warten bis das erste Telegramm ankommt. Kommt doch im Normalfall nicht oft vor.

Ich hab mal nachgeschaut in FHEM wie konstant das Intervall ist, mit dem meine Taster senden. Über einen Tag liegt die Abweichung bei Übertragung alle 5Minuten bei ca. +-1sec. Ich verwende M644 mit externem Quarz und die Funktion millis. Da hab ich nix getrimmt auf extreme Genauigkeit.

[BadSmiley]

gibts ja schon.. https://www.theben.de/de/uhren-1878-c/

[Ing-Dom]

gibts ja schon.. https://www.theben.de/de/uhren-1878-c/

aber noch keine Qlocktwo
Außerdem gehts jetzt erstmal um ein Software-Modul, das man in allen DIY-Konnekting Devices einsetzen kann wo man eine Uhr braucht.
Entweder eine reine Wanduhr (macht dann aber nur Sinn, wenn KNX Mehrwert bietet, z.B. durch Statusinfos/Alarme etc..)
oder Displays
oder Geräte die irgendwelche Zähler drin haben, z.B. eine Wetterstation mit Historienspeicher.

Vermutlich dürfte der Korrekturfaktor dann fast eine Konstante sein oder? Zumindest eine Konstante je Baugruppe.
Bevor ich fertige KNX Chips verwendet habe, hatte ich selbst angefangen KNX Signale zu generieren. Dabei ist mir aufgefallen dass die Schwankungen von Prozessor internen Taktgebern doch recht groß ist. Atmel AVRs kann man dafür recht gut kalibrieren, und das musste ich auch nutzen.

Ist es überhaupt schlimm wenn nach dem Hochlauf mal nicht sofort die richtige Zeit kommt? Einfach gar keine Uhrzeit anzeigen und warten bis das erste Telegramm ankommt. Kommt doch im Normalfall nicht oft vor.

Genau, die internen Taktgeber der µC sind idR nicht so genau. Hat im selfbus-Projekt z.B. ja auch schon Probleme gemacht, die nehmen nun einen externen Oszilator. Wirkt sich aber bei Konnekting dank BCU nicht so aus.
Ich gehe auch davon aus, dass die internen Taktgeber maximal noch mit der Temperatur schwanken, aber beim Einsatz im Innenraum dürften sich da kaum größere Schwankungen einstellen.

[BadSmiley]

aber noch keine Qlocktwo

Ja, da würde ich auch eine nehmen.

[Eugenius]

Für Zeit waren doch DPT 10 und 11 gedacht...
andere Frage, habt ihr keine Visus zuhause? Ich bekomme die Zeit über OpenHAB. IP Router können die Zeit auch senden...

[Ing-Dom]

Für Zeit waren doch DPT 10 und 11 gedacht...

mir gefällt das nicht, DAtum und Zeit in extra Telegrammen. Und DPT19.001 hat beides im Bauch.
Zeitserver ist bei mir die MDT IP Interface.
Die Konnekting Devices wären Clients...

[Sonnengruesser]

dass kann Konnekting noch nicht, oder, ReadRequests auslösen?)

doch, einfach das "I" Flag setzen. Ist bei V4a etwas nervös (alle 500ms), bei V4b hab ichs noch nicht getestet.
Meine Jung Taster haben ein eigenes 1bit Objekt, mit dem sie die Uhrzeit anfragen. Die Antwort kommt dann als ganz normale Info von Edomi. Also kein Read request.

[Ing-Dom]

das L oder R Flag bedeutet eigentlich, dass ein KO über den Bus mit einem ReadRequest abgrufen werden kann. Dabei sendet der Anfragende einen ReadRequest, der Antwortende einen ReadResponse.

Das A oder U Flag (Aktualisieren/Update) sorgt in einem Gerät dafür, dass ein KO beim Empfang eines ReadResponse mit passender GA der Wert übernommen wird.

[Sonnengruesser]

Sorry, ich meine natürlich das I-Flag - korrigiere das gleich noch oben.

Und das fragt natürlich nur beim Init den Status an, danach kann das nicht "manuell" getriggert werden.

[Ing-Dom]

Heißt aber, die Mechanik ist in der Device Lib drin, und man könnt das wohl ohne großen Aufwand von außen nutzbar machen... muss ich mir mal anschauen.

[Sonnengruesser]

Genau, einfach im xml das Flag setzen wie hier (Zeile 213) beschrieben.

[Ing-Dom]

ne, ich meinte um ein "ReadRequest" aus der Applikation zu versenden.