In der Tiefe: Validierungskonzept

[salixer]

- der ntpd macht nun folgendes: er "lernt" ständig die tageslaune der RTC und baut dynamisch eine sog. "drift" ein, mit der er einfach forthin die RTC geradezieht. Die Timer der xhundert MHz-CPU ist nämlich umso präziser..

Hier noch eine kleiner Zusatz: Sobald das System gestartet ist, läuft die Systemzeit immer "auf CPU-Takt". Die RTC wird dabei nicht mehr abgefragt, es sei denn man gibt sie explizit in der ntp.conf als server an. Bringt aber im Normalfall nicht wirklich was, denn sowohl CPU-Takt als auch RTC tickern mit gewisser Abweichung in der Gegend rum.
Dass der "drift" die Gangungenauigkeit der Systemzeit speichert stimmt natürlich.

d.h.: einmal "gelernt und in sync", sofern nicht wochenlang ausgeschaltet, kann der ntpd auch die besch*** RTC ggfs. ohne Verbindung Wochen oder sogar Monatelang auf wenige ms "in der Spur" halten. Weil er seinen Pappenheimer nunmal kennt..

Vorrausgesetzt das System läuft in einer klimatisierten Umgebung ohne Temperaturschwankung, was bei einem Haus im Keller wohl noch am ehesten zutrifft. Läuft das Teil im Büro/Wohnraum, kann man am drift quasi die Temperaturschwankung mitverfolgen (natürlich mit einigem Zeitversatz).

Die billigste Möglichkeit für einen brauchbare "Unruh" im Computer ist wohl ein Ofenquarz mit per ntp generiertem drift. Man kann sich natürlich auch eine Cäsium-Frequenznormale hinstellen, dann braucht man sich keine Gedanken mehr zu machen

[makki]

Daher mal noch ein Vorschlag: Will man unbedingt eine eigene []-Sektion, reicht es aus

[ReadStartup]
GA1
GA2

zu definieren und der EibPC führt diese Reads aus, wartet eine parametrierbare Zeit aufs Eintreffen und legt dann las.

Klingt gut. Der HS machts nicht anders, das ist deterministisch und IMHO zielführend!
Danach sieht man auf Debug-Seite Scan-Fehler (im HS-Sprech, beim EibPC eher im Log) und weiss warum die Logik nicht so anlief wie man dachte.. Und das - im HS-sprech - auch noch 10 Minten früher

Makki, zieh mal aufs Land, bei den dortigen Internet-Verhältnissen bist du am Ende froh, wenn die Uhr auf eine Minute genau geht..........

Nein. Nein. Nein. Ich wohne aufm Land (für Münchner wenigstens..)
Ich hatte da bestimmt schon 1-2x darüber referiert aber gerne nochmal, diesmal vielleicht weniger technisch:

Gegeben:
- eine RTC mit Batterie (sonst Problem nach Power-cycle)
- ein ntpd der mal ein paar Tage/Stunden an pool.ntp.org war

Was passiert:
- die RTC geht per se eher nach dem Mars, ist so, eine einstellige handvoll Sekunden/Tag sind normal, dem ist auch mit vertretbarem Aufwand HW-seitig nicht beizukommen.
Die Abweichung des Quarzes ist individuell, gegeben, aber normalerweise "stabil" und innerhalb gewisser Zeitspannen deterministisch.
- der ntpd macht nun folgendes: er "lernt" ständig die tageslaune der RTC und baut dynamisch eine sog. "drift" ein, mit der er einfach forthin die RTC geradezieht. Die Timer der xhundert MHz-CPU ist nämlich umso präziser..

d.h.: einmal "gelernt und in sync", sofern nicht wochenlang ausgeschaltet, kann der ntpd auch die besch*** RTC ggfs. ohne Verbindung Wochen oder sogar Monatelang auf wenige ms "in der Spur" halten. Weil er seinen Pappenheimer nunmal kennt..

Außerdem kommt es dort auch nicht auf 5 Minuten an.

Ich glaube nicht das z.B. die Loganalyse auf zwei Geräten mit deftig & unnötig abweichenden Uhrzeiten auf dem Land lustiger als in der Stadt ist

Makki

[Uwe!]

Beim Reboot wird zunächst STARTUP verarbeitet. Nach 5 Minuten oder wenn startup=AUS ist wird [EIBPC] verarbeitet.

so gefällt's mir auch!
nächste Stufe (...wünsch Dir was...): es gibt eine Funktion init(GA), die intern erst ein read(GA) auslöst und sobald eine Antwort (oder "normales" Telegramm) auf diese GA kommt auf 1 springt. Dann wäre Dein Beispiel noch einfacher:

[HIGHLIGHT=EPC]
[STARTUP=50000u64]
if (init(GA1) + init(GA2) + ......+ init(GA15))==15 then startup=AUS endif

[EIBPC]
...
[/HIGHLIGHT]



noch mal zum

Eine eigene Funktion ist natürlich elegant, muss aber nicht sein. if event() geht auch.

Aber eben ohne Unterscheidung Write/Answer!
Für das Thema Systemstart sollte es aber eigentlich egal sein, warum was auf der GA geschickt wird, da geb ich Dir schon recht.

/Leicht OT/: Wäre es evtl. generell sinnvoll ein answer(GA) zu haben? Könnte man damit prüfen, ob bestimmte Komponenten noch reagieren? Auf ein read(GA) sollte ja immer nur ein bekanntes, definiertes Gerät antworten. Wenn also auf ein Read() ein Answer() kommt, weiß ich dass diese Gerät noch "lebt". Braucht man so was???

[SnowMaKeR]

Wow, hat sich ja einiges getan seit gestern Abend.
Mal sehen ob ich das jetzt alles auf die Reihe bekomme. Die Diskussion ist ein wenig konfus geworden.

Ich frag mich:
Was muss beim Systemstart gemacht werden? Wofür ist er da?
Beim Systemstart muss ich das Schaltbild der Anlage einlesen, ein wenig die Visu aufbereiten und ein paar (oder ein paar mehr) grundlegende Stati setzen.
Genau dafür ist der Systemstart da, nicht mehr, aber auch nicht weniger.

Warum wollt ihr nicht systemstart() nutzen? ...
Das führt mich zu der Frage, ob es nicht sinnvoll ist eine Funktion valid( GA ) zu erstellen die dann EIN zurückgibt, sobald diese GA erstmalig vom Bus geliefert wurde. Natürlich müßte das Validierungsschema erweitert werden, das der Code der im then { ... } endif steht immer ausgeführt wird.

Die systemstart() Funktion kann von mir aus irgendwie genutzt werden. Aber es muss einfach und übersichtlich bleiben, dass sehe ich bei der jetzigen Funktion nur bedingt gegeben.
Das Validierungsschema zu ändern finde ich eine schlechte Idee. Warum auch. Es ist genial und verhält sich wie der BUS.
Ist wie mit den "hörenden" GAs. Dauert etwas bis man es verstanden hat, aber dann passt´s.
Wenn es geändert werden würde, muss ich meine Eventgesteuerte Denke komplett umstellen.
Ich will keine SPS haben.
Kätzerisch könnte ich jetzt sagen: Wer das verhalten einer SPS will, der soll sich eine kaufen.
(Ist natürlich nicht ganz ernst gemeint).

fehlt uns vielleicht noch so was wie "answer(GA)" mit dem man abfragen kann, ob zu einer bestimmten GA seit dem letzten read() ein Antworttelegramm eingetroffen ist?

Eine eigene Funktion ist natürlich elegant, muss aber nicht sein.
if event() geht auch.

Was mir nicht gefällt, ist der eigene Bereich. Das gibt wieder Fragen...
Ich fände besser, alles per Funktion gemacht wird:

Welche Fragen?

Daher mal noch ein Vorschlag: Will man unbedingt eine eigene []-Sektion, reicht es aus

Es muss keine eigene Sektion sein, aber es ist das logischste.
Per Funktion finde ich zu kompliziert.

Wie oben geschrieben, der Bereich ist nur dazu da generelle Stati zu setzen und GAs zu lesen.

[HIGHLIGHT=EPC]
if startup() then {
read1
read2
read3 } endif

if startup() and GA=EIN then...
[/HIGHLIGHT]
Das ist Handling irgendwie auch nicht so viel besser wie mit systemstart().
Die Erklärung ist auch nicht sonderlich elegant.
Am Anfang wird nur alles mit startup() verarbeitet bis die Zeit vorbei ist...?

Eine eigene Sektion mit Maximallaufzeit und Endebedingung wäre das Optimum, das gerne auf Etaben realisiert werden darf.
In etwas so
[HIGHLIGHT=EPC]
[STARTUP=50000u64]
if startup {
read1
read2... } endif
...
if event(GA1) Or event(GA2) OR... event(GA15) then {
icount=icount+1 }endif
if icount=15 then startup=AUS endif

[EIBPC]
...
[/HIGHLIGHT]

Erklärung ist ganz einfach.
Beim Reboot wird zunächst STARTUP verarbeitet. Nach 5 Minuten oder wenn startup=AUS ist wird [EIBPC] verarbeitet.
[STARTUP] kann dann für den rest des Jahres ignoriert werden.

[Uwe!]

Umkehrschluß: Wer keinen hat oder zumindest dem EPC keinen geben kann oder will sollte das Gerät gar nicht erst verwenden?

Ich würde eher sagen: wer in seinem KNX-Bus die genaue Zeit braucht muss dafür halt auch sorgen. Der EibPC kann eine Möglichkeit sein (wenn die Voraussetzungen stimmen) ansonsten eben eine KNX-DCF-Uhr (wie es z. B. viele Wetterstationen drin haben. BTW: meine DCF-Uhr ging lange Zeit auch falsch....)

Im Prinzip ja, aber auch hier kannst Du ja ein eigenes Flag anlegen, beim Start auf 0 setzen und beim Empfang der GA auf 1 setzen.

na ja. Irgendwie kann man sich fast immer behelfen, aber es ging ja drum, wie man es besser/einfacher lösen kann. Wenn ich 30 GA abfrage müsste ich auch 30 eigene Flags hantieren. Ein answer(GA) fände ich da übersichtlicher. Außerde kannst du mit Deinem Vorschlag ein write-Telegramm nciht von einem answer-Telegramm unterscheiden, wobei ich jetzt kein Beispiel hätte, wo man diese Unterscheidung braucht.
Und es belint halt das Problem mit de "Vorbelegung". Einfach auf 0 setzen passt halt oft nicht! Was machst Du, wenn Du den Zustand eines Schaltaktors abfragen willst? Da kannst Du dann anfangen ein Flag auf "2" zu setzen und das Ergebnis der GA über convert() dann mit dem Flag vergleichen. Weil weder das setzen des Flags auf 0 noch auf 1 zu eindeutigen Ergebnissen führt. Es muss ja imnmer was sein, was nciht als echtes Ergebnsi zurück kommen kann!

Welches? Das die Zeit etwas driftet und Du alle paar Wochen vielleich mal nachstellen mußt?

Nein, das Ziel zum Systemstart definierte GA-Zustände zu haben.

Sind alle Deine Uhren (auch die am Arm oder in der Tasche) entweder mit dem Internet verbunden oder GPS/DCF-synchronisiert? Super, 100 Punkte.

Fast....Soweit ich Einfluss drauf habe: JA. Die Mikrowelle z. B. gab's aber weder mit GPS, DCF noch Internetanschluss. Für Handgelenk, Fernseher, Receiver, Wanduhr, Heizung hab ich aber genau Zeit. (@Makki: Nein bitte nicht die Diskussion was genau ist. Genau genug für meine Zwecke!)

Richtig, ist auch meine Erfahrung, siehe oben. Und das Problem löst kein schnödes Warten, da ist mehr gefordert. Daher wohl auch die Anfragen nach einer Möglichkeit, dies von einer logischen Bedingung abhängig zu machen - die dann ja auch eine Wartezeit sein könnte - oder eben auch etwas anderes.

Genau!

[Tessi]

wobei auch eine perfekte RTC im EibPC nur eines der vielen Probleme beim Startup lösen würde.

Ja, aber das wäre dann wenigstens gelöst und für micht ist dieses Problem derzeit das größte Ärgerniss...

Das Problem mit den Uhrneustart stellt sich für 99% der Anwender nicht

Und für die 1%, die keinen Internetzugang für den EPC haben (wollen) lohnt sich kein Aufwand...
Schade...

Ne perfekte RTC gibt's nicht. Die laufen alle mehr oder weniger krum Aber das bringt alles nichts: Der EibPC hat keine RTC und braucht eben beim Start eine Internetverbindung zum Uhrenabgleich oder ein KNX-Gerät zum Abfragen.

Umkehrschluß: Wer keinen hat oder zumindest dem EPC keinen geben kann oder will sollte das Gerät gar nicht erst verwenden?

fehlt uns vielleicht noch so was wie "answer(GA)" mit dem man abfragen kann, ob zu einer bestimmten GA seit dem letzten read() ein Antworttelegramm eingetroffen ist?

Im Prinzip ja, aber auch hier kannst Du ja ein eigenes Flag anlegen, beim Start auf 0 setzen und beim Empfang der GA auf 1 setzen. Das Flag kannst Du dann immer abfragen. Muß ich derzeit bei vielen GAs (auch für die Zeit) so machen weil die hier diskutierten Funktionen eben fehlen.

Eben! Drum meinte ich auch, dass sich die Diskussion darüber nicht lohnt. Denn selbt wenn er eine perfekte hätte, würde das da eigentliche Problem nicht lösen.

Welches? Das die Zeit etwas driftet und Du alle paar Wochen vielleich mal nachstellen mußt?
Sind alle Deine Uhren (auch die am Arm oder in der Tasche) entweder mit dem Internet verbunden oder GPS/DCF-synchronisiert? Super, 100 Punkte. Aber viele Menschen haben noch ganz "normale" Quarz- oder gar mechanische Uhren am Handgelenk, und die müssen auch gelegentlich korrigiert werden. Das deshalb jemand diese Uhren für überflüssig und nutzlos hält und nur deshalb auf sie verzichten will ist mir noch nicht zu Ohren gekommen.

Warum? Wenn ich Reads auf ne GA mache, dann weiss ich doch, das diese z.B. in 30 Sekunden alle da sind. (plus minus 3 Sekunden) und kann mich danach richten...

Was macht Dich da so sicher? Ich hatte Fälle, in denen Antworten eben nicht immer kamen, das hing offenbar von der aktuellen Auslastung der befragten Geräte ab - für den EPC ist das nicht vorhersehbar.

Alles ab ISDN reicht völlig aus um über NTP auf 50 ms genau zu synchronisieren. Falls du natürlich kein Internet für NTP hast, dann wirst du mit einer RTC allein auch nicht glücklich werden. Die Genauigkeit der üblichen Uhrenquarze, die auf Mainboards verwendet werden ist da einfach jenseits von gut und böse. Da hilft dann nur Synchronisation über DCF oder GPS.
Aber das ist ein anderes Thema...

Ja, aber schlechter als viele Billig-Armbanduhren wäre der EPC sicher auch nicht. Für die meisten Fälle sind selbst mehrere Sekunden Abweichung kein Problem und für viele gehört regelmäßiges Korrigieren diverser Uhren zum Alltag.
Klar ist eine automatische Korrektur eine Erleichterung - aber deshalb verteufeln wir ja wohl nicht alle Uhren ohne eine solche?

Ja? Woher?
Ich hatte z. B. lange ein Problem mit dem InfoTerminalTouch. Das ließt zu beginn ja auch alle so definierten GA erst mal ein um einen aktuellen Stand zu haben. Bei den Ventilstellungen haben regelmäßig Werte gefehlt. Lösugn war dann letztlich die Geschwindigkeit zu drosseln, weil der Heizungsaktor nciht schnell genug genatwortet hat.
Gut, die grundsätzliche Abfragegeschwindigkeit kann ich natürlich im EibStudio auch definieren, aber es gibt eben erst mal keinerlei Garantie, das auf ein Read auch ein Answer-Telegramm folgt.

Richtig, ist auch meine Erfahrung, siehe oben. Und das Problem löst kein schnödes Warten, da ist mehr gefordert. Daher wohl auch die Anfragen nach einer Möglichkeit, dies von einer logischen Bedingung abhängig zu machen - die dann ja auch eine Wartezeit sein könnte - oder eben auch etwas anderes.
Auf jeden Fall flexibler als nur warten. Klar, egal wie kompliziert wir jetzt auch denken, es wird immer ein Szenario geben, das auch durch die komplexeste Lösung nicht abgedeckt wird, aber deswegen gleich nur die primitivste und eingeschränkteste Lösung favorisieren?

[Uwe!]

Warum? Wenn ich Reads auf ne GA mache, dann weiss ich doch, das diese z.B. in 30 Sekunden alle da sind.

Ja? Woher?
Ich hatte z. B. lange ein Problem mit dem InfoTerminalTouch. Das ließt zu beginn ja auch alle so definierten GA erst mal ein um einen aktuellen Stand zu haben. Bei den Ventilstellungen haben regelmäßig Werte gefehlt. Lösugn war dann letztlich die Geschwindigkeit zu drosseln, weil der Heizungsaktor nciht schnell genug genatwortet hat.
Gut, die grundsätzliche Abfragegeschwindigkeit kann ich natürlich im EibStudio auch definieren, aber es gibt eben erst mal keinerlei Garantie, das auf ein Read auch ein Answer-Telegramm folgt.

[Uwe!]

Man kann ja auch als letztes einen Temperaturwert abfragen .....

Dann weißt Du aber nur, ob der Temperaturwert da ist, nicht was mit den anderen reads passiert ist!
Von dem unwahrscheinlichen Fall, dass es zum Abfragezeitpunkt gerade 0,00° hat mal abgesehen, aber das wäre auch lösbar.

[salixer]

Makki, zieh mal aufs Land, bei den dortigen Internet-Verhältnissen bist du am Ende froh, wenn die Uhr auf eine Minute genau geht..........

Alles ab ISDN reicht völlig aus um über NTP auf 50 ms genau zu synchronisieren. Falls du natürlich kein Internet für NTP hast, dann wirst du mit einer RTC allein auch nicht glücklich werden. Die Genauigkeit der üblichen Uhrenquarze, die auf Mainboards verwendet werden ist da einfach jenseits von gut und böse. Da hilft dann nur Synchronisation über DCF oder GPS.
Aber das ist ein anderes Thema...

[enertegus]

Genau da bin ich halt der Meinung dass man dem Anwender die Flexibilität lassen sollte, nicht nur zeitabhängig zu entscheiden, wann der EibPC "los legt"

Warum? Wenn ich Reads auf ne GA mache, dann weiss ich doch, das diese z.B. in 30 Sekunden alle da sind. (plus minus 3 Sekunden) und kann mich danach richten...

[anlo007]

fehlt uns vielleicht noch so was wie "answer(GA)" mit dem man abfragen kann, ob zu einer bestimmten GA seit dem letzten read() ein Antworttelegramm eingetroffen ist?

Man kann ja auch als letztes einen Temperaturwert abfragen mit if after (systemstart(), 20000) und diesen auf <>0 kontrollieren, dann weiß man das die letzte Abfrage beantwortet ist und damit den Startbereich verlassen. omit entweder Zeitlich gesteuert oder über eine definierte Abfrage.

[Uwe!]

Ne perfekte RTC gibt's nicht. Die laufen alle mehr oder weniger krum.

Eben! Drum meinte ich auch, dass sich die Diskussion darüber nicht lohnt. Denn selbt wenn er eine perfekte hätte, würde das da eigentliche Problem nicht lösen.

[anlo007]

Falsche/kaputte Uhren lösen bei mir - egal in welchem Verbindungszustand - ab ca. 50ms Abweichung starke allergische Schockreaktionen aus
Makki

Makki, zieh mal aufs Land, bei den dortigen Internet-Verhältnissen bist du am Ende froh, wenn die Uhr auf eine Minute genau geht..........

Außerdem kommt es dort auch nicht auf 5 Minuten an.

[Uwe!]

fehlt uns vielleicht noch so was wie "answer(GA)" mit dem man abfragen kann, ob zu einer bestimmten GA seit dem letzten read() ein Antworttelegramm eingetroffen ist?

[salixer]

wobei auch eine perfekte RTC im EibPC nur eines der vielen Probleme beim Startup lösen würde.

Ne perfekte RTC gibt's nicht. Die laufen alle mehr oder weniger krum Aber das bringt alles nichts: Der EibPC hat keine RTC und braucht eben beim Start eine Internetverbindung zum Uhrenabgleich oder ein KNX-Gerät zum Abfragen.