In der Tiefe: Validierungskonzept

[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...

[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...

[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.

[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.

[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!]

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!

[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!]

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???

[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

[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

[anlo007]

Nein. Nein. Nein. Ich wohne aufm Land (für Münchner wenigstens..)
Makki

Ich meine "auf dem Land" und nicht in einem Nobelvorort von München.
An manchen Tagen braucht mein Internet bis zu 2 Minuten, um hier diese Seite aufzubauen. (Deshalb bin ich auch nur wärend der Woche hier im Forum unterwegs!)

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

AUf dem Land wird man halt genügsamer......

Gegeben:
- eine RTC mit Batterie (sonst Problem nach Power-cycle)

Makki

Hier ist dein Fehlschluß: Der EibPC "vergißt" jegliche Zeiteinstellung, wenn das Programm neu übertragen wird. Sonst hätte ich ja kein Problem, wenn er nur etwas falsch gehen würde.
Aber dadurch werden alle Befehle. die z.B. mit !sun verbunden sind auch Nachmittags ausgeführt, da die Zeit mit 00.00 startet.

[salixer]

Hier ist dein Fehlschluß: Der EibPC "vergißt" jegliche Zeiteinstellung, wenn das Programm neu übertragen wird. Sonst hätte ich ja kein Problem, wenn er nur etwas falsch gehen würde.

Dann hast du ein Problem in deinem Programm. Schuss ins Blaue: Du fragst die Zeit irgendwie über KNX ab und da geht beim Systemstart etwas schief. Das Problem hatte ich auch schonmal.

EDIT: Ungetestet, IIRC:
[highlight=epc]
[EibPC]
if systemstart() then {
read ("Zeit-0/1/1");
gettime("Zeit-0/1/1")
} endif
[/highlight]
Funktioniert so nicht. Stattdessen müsste es so lauten:
[highlight=epc]
[EibPC]
if systemstart() then read ("Zeit-0/1/1") endif
if after(systemstart(),10000u64) then gettime("Zeit-0/1/1") endif
[/highlight]

[anlo007]

Mein Internet funktionierte auch schon mal etwas besser, da hab ich mich nicht um die Zeit kümmern müssen. Wird auch hoffendlich bald besser, da ich gerade den Anbieter wechsel, die 2 Jahre Vertragslaufzeit ist gerade abgelaufen.

Als ich jetzt die Probleme bekam, hab ich die Abfragezeilen aus dem Handbuch kopiert und frage zur Zeit die Uhrzeit aus dem wiregate ab. Ohne Telegrammraten-Begrenzung wurde dies dann 4-5 mal übertragen; mit Begrenzung nur noch 1-2 mal. Das funktioniert jetzt. Nur oft werden schon andere Befehle ausgeführt, bevor die Uhrzeit angekommen ist, deshalb der Wunsch nach der Verzögerung des Starts der Logikverknüpfungen.

[salixer]

Als ich jetzt die Probleme bekam, hab ich die Abfragezeilen aus dem Handbuch kopiert und frage zur Zeit die Uhrzeit aus dem wiregate ab.

Das würde ich nur einmal beim Systemstart machen, um die Zeit initial zu setzen (aber dann halt so, dass es klappt)
Ich bin kein Freund des periodischen Uhrzeit setzens. Dabei treten "Zeitsprünge" auf, d.h. es ist möglich das Uhrzeiten an einem Tag garnicht oder aber auch doppelt vorkommen. Nicht gerade optimal, wenn man Ereignisse an bestimmte Uhrzeiten bindet.

[makki]

Völlig richtig, Uhrzeit "setzen" ist immer suboptimal..
@anlo: Beinahe wollte ich jetzt schreiben: Trag einfach das WireGate als NTP-Server ein, aber das (NTP-Server konfigurieren) kann man ja AFAIR nicht
Jetzt hätten wir einen Grund, warum man das können sollte

Früher, mit Dialup und Minutenticker und so, hat man das ja nicht anders gemacht: einen oder zwei lokale NTP (kann ja auch der eigene Rechner sein, der regelmässig an ist, wenn der EibPC neu gestartet wird, ntpd gibts auch für Windows - meinberg.de)

Makki