In der Tiefe: Validierungskonzept

[Uwe!]

Grundsätzlich:

, wartet eine parametrierbare Zeit aufs Eintreffen und legt dann las.

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"

Aber Dein Vorschlag wäre auf jeden Fall eine erhebliche Verbesserung zum aktuellen Stand!

[enertegus]

Sorry, das muss ich jetzt mal kurz einwerfen: Das Wiregate hat eine battriegepufferte RTC und da läuft ein ntp - in richtig! Also die drift ist bekannt etc.pp.

Das Problem mit den Uhrneustart stellt sich für 99% der Anwender nicht, da der EibPC beim Boot sich mit dem ntp breits neu synchronisiert hat, bis er wieder "online" ist. Für die meisten hier gehts doch um das Abbild der Gruppenadressen im Zustandsspeicher. Und es geht darum, dieses Abbild geziehlt oder irgendwie gesteuert einzulesen bevor die Verarbeitung beginnt.
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.

[Uwe!]

Nach meine Verständniss wird also in einer Abfrage
if systemstart() then .... endif
der Then-Zweig genau ein einziges mal durchlaufen. Wann willst Du denn da die Bedingung "endsystemstart()=EIN" setzten?

Das ist schon richtig, aber ich kann "if systemstart()....endif" ja beliebig oft verwenden. Muss halt alles was am Anfang gemacht werden soll in ein "if systemstart()....endif" einpacken. Eine eigene Sektion [Systemstart] wäre auch aus meiner Sicht übersichtlicher, aber da sträubt sich Michael (noch)

Oder ist Dein Ansatz, das systemstart() solange EIN bleibt, bis alle read()-Anweisungen im then.zweig eine Antwort empfangen haben?

nicht "bis alle Antworten eingetroffen sind" (weil das ggf. amal auch nie passiert), sondern bis ich mit entsprechender logik den Systemstart als beendet erkläre. Dafür war mein "EndSystemstart()" gedacht.

[Uwe!]

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

[makki]

..und mit der Zeit erst mal arbeiten kann, bis der EibPC oder das wiregate wieder die genaue Zeit empfangen hat.

Sorry, das muss ich jetzt mal kurz einwerfen: Das Wiregate hat eine battriegepufferte RTC und da läuft ein ntp - in richtig! Also die drift ist bekannt etc.pp.
Falsche/kaputte Uhren lösen bei mir - egal in welchem Verbindungszustand - ab ca. 50ms Abweichung starke allergische Schockreaktionen aus
Sollte also mal halbwegs passen solange es ab und an (einmalig für ein paar Stunden&alle paar Wochen danach - sollte für die von mir geforderte Präzision von 50ms reichen) ins Netz kommt..

Makki

[Tessi]

if valid( GAWasserstand ) then {
   if GAWasserstand < 100% then write( GAPumpe, EIN ) endif;
   if GAWasserstand = 100% then write( GAPumpe, AUS) endif
} endif

Damit wären wir dann wieder bei der Lösung, eine Art if zu haben, dessen Bedingung nicht dem Validierungsschema unterliegt (sondern als eine Art Flag in jedem Durchlauf ausgewertet wird) und dessen then-Zweig wiederum nicht komplett auf invalid gesetzt wird sondern wie Code außerhalb ganz "normal" dem Validierungsschema unterliegt.
Dann könnte jeder seine eigenen "Bereiche" schaffen und freigeben oder sperren wie er will.
Das wurde aber schon mal angesprochen und von Enertex seinerzeit abgelehnt. Aber vielleicht kommt es ja doch noch einmal, so wie auch das eval()...

Ich würde es begrüßen und diese Diskussion hier wäre zuende.

[saft6luck]

@bernd:
Für das Thema der bisher 'ungültigen' GAs stimme ich zu. Hier sollte unabhängig von dem Wunsch zum Systemstartproblem etwas getan werden.

Wenn man das valid() einfach als AND anfügt, kann ja auch das Validierungsschema bleiben, wird halt alles etwas länger und unübersichtlicher, grr.

Beim Startup-Bereich oder anderer Lösungen geht es aber auch um Probleme, wie der fehlenden Zeit oder anderer Themen, die man einfach machen will, bevor die restliche Logik anfängt.

Nur den systemstart() in einem Flag zu speichern, das ich nach einer gewissen Zeit wieder lösche, könnte ich jetzt schon machen und werde ich evtl. weiterhin machen, weil eben ein Teil der Logik möglichst schnell lauffähig sein soll. Andererseits ist es ziemlich egal, ob der eibPC jetzt oder erst 3 Minuten später wieder läuft, wichtig ist, dass der mir nicht die Rollos runter fährt, weil er meint es sei der 1. Jan und da ist es um 17:00 schon dunkel.

[pio]

Das wäre mir eine große Hilfe, denn es würde meine Probleme beim Systemstart vollständig lösen!

Hab ich doch vorgeschlagen:

[EibPC=0u64] oder meinetwegen [Systemstart]
bla
blubb

wird genau einmal beim Systemstart abgearbeitet, so wie ein
if systemstart then ... endif

[EibPC=1000u64]
wird eine Sekunde nach systemstart regelmässig abgearbeitet.

[pio]

Also ich parametriere (wo und wie auch immer) 20 Sek. und dann legt die Kiste erst 20 Sek. nach Systemstart() mit dem allem los, was nicht ausdrücklich als

if systemstart() then ....

definiert ist.

So hab ich jedenfalls Matthias verstanden.

Meine Idee war es nun eben nicht irgend wo nur eine Zahl (die 20 Sek.) hinterlegen zu können, sondern während der Systemstarttätigkeiten selbst mit Logik den Schalter umlegen zu können. Das kann dann der eine trotzdem einfach mit einer festen Zeit machen, der andere übrprüft, ob bestimmte Antworten eingetroffen sind und der dritte lässt sich ganz was anderes einfallen (vielleicht einen Taster, den er manuell bedient)

Systemstart ist doch genau während dem allerersten Schleifendurchlauf auf EINS, beim zweiten, also schon 1 ms später, ist systemstart() wieder auf AUS. Nach meine Verständniss wird also in einer Abfrage
if systemstart() then .... endif
der Then-Zweig genau ein einziges mal durchlaufen. Wann willst Du denn da die Bedingung "endsystemstart()=EIN" setzten?

Oder ist Dein Ansatz, das systemstart() solange EIN bleibt, bis alle read()-Anweisungen im then.zweig eine Antwort empfangen haben?

[bmx]

Also ganz ehrlich, das ist eigentlich IMHO noch nix halbes und nix ganzes.

Warum wollt ihr nicht systemstart() nutzen? Ich denke weil ihr nicht wißt, ob nun alle Telegramme die ihr für die Logik braucht auch eingetroffen sind.

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.

So würde dann der Code

if valid( GAWasserstand ) then {
   if GAWasserstand < 100% then write( GAPumpe, EIN ) endif;
   if GAWasserstand = 100% then write( GAPumpe, AUS) endif
} endif

dazu führen, das erst dann was mit der Pumpe geschaltet wird, wenn auch klar ist, wie der Wasserstand wirklich ist.

Zusätzlich könnte man auch mit setinvalid( GA) eine Funktion einführen, die das Gültigkeitsbit zurücksetzt (zum debuggen zum Beispiel)

Nur meine 2 cent ...

Gruß,
Bernd

[pio]

Stimmt schon, aber es wird kompliziert, wenn Antworten nicht kommen. Ewig warten geht nicht, unendlich oft nachfragen auch nicht. Wie bestimme ich also, wann ich den Systemstart als abgeschlossen betrachte und ab wann der Logikteil loslaufen soll? Was ist mit teilweisem Start?

Das ist ja mein Ansatz mit der Vorgabe von Zeitverzögerungen ab Systemstart in den Sektions-Headern:
[EibPC=50000u64]
xxx
yyy

Die regelmässige Abarbeitung startet erst 50 Sek nach Systemstart.

Damit, dass man nicht sicher sein kann, dass z.B. 10 read() - Befehle nach spätestens 2 Sekunden abgearbeitet sind, muss man leben. KNX ist nicht deterministisch und arbeitet erst recht nicht nach harten Echtzeit-Anforderungen.
Man kann aber überschlagen, wie lange man für 10 read()-Anforderungen ungefähr brauchen sollte, und wenn man dann nochmal 10 Sekunden Sicherheit aufschlägt, bringt einen das nicht um (mich zumindest nicht).

[saft6luck]

Was mir nicht gefällt, ist der eigene Bereich. Das gibt wieder Fragen...

Ich kann das schwer beurteilen! Wenn du sagst: "Das gibt wieder Fragen", sind dann wirklich die Nutzer das Problem oder geht es eigentlich um die Umsetzung, die zu aufwändig ist?

Ich fände besser, alles per Funktion gemacht wird:

[highlight=epc]
// Nur was in dieser if-Anfrage steht, wird gemacht
if startup() then {
FixSystemStart();
tuwas()
} endif
// Und nun gehts erst los...
if after(startup() ) then ReleaseSystemstart () endif
[/highlight]

Das bedeutet, dass durch FixSystemStart() alle Abfragen im Code ohne startup() als Bedingung ignoriert werden?

Also wird jetzt das Programm zyklisch abgearbeitet und nur die Bedingungen mit der zusätzlichen Abfrage startup() werden beachtet, oder? Ansonsten kann ich ja nicht auf das Eintreffen bestimmter Ereignisse warten, bevor ich den restlichen Code ausführen will.
Wenn es allerdings nur das eine if gibt, ist es problematisch. Leider ist man dann bei der Programmierung nicht mehr frei, denn das Validierungsschema schränkt einen bei der Verschachtelten if-Anweisung sehr stark ein.

Im Beispiel wird dann nach einer gewissen Zeit das startup() durch ReleaseSystemstart() wieder AUS gesetzt und der eigentliche Code abgearbeitet.

Wenn ich das so richtig verstanden habe, verwirrt das ja nicht ganz unerheblich -> mir persönlich gefällt das nicht.

Evtl. meinst du aber, dass startup() einfach ein Flag ist, das über Befehle kontrolliert wird und man in allen Abfragen bzw. Zuweisungen, die verzögert werden sollten, einbauen muss, entweder startup() oder als !startup()?
Dann gibt es diese Lösung eigentlich schon -> Ist nicht mein Ding.

Oder ich liege einfach falsch und brauche mehr Input

[enertegus]

Flexibel finde ich die Lösung:

Was mir nicht gefällt, ist der eigene Bereich. Das gibt wieder Fragen...

Ich fände besser, alles per Funktion gemacht wird:

[highlight=epc]
// Nur was in dieser if-Anfrage steht, wird gemacht
if startup() then {
FixSystemStart();
tuwas()
} endif
// Und nun gehts erst los...
if after(startup() ) then ReleaseSystemstart () endif
[/highlight]

[saft6luck]

Eine neue Funktion braucht es dann wegen dem Validierungsschema trotzdem, oder?
Ein READ braucht ja immer einen Auslöser.
Oder wird das genau einmal ausgeführt?
[HIGHLIGHT=EPC]
read (GA)
[/HIGHLIGHT]

Wenn nicht:
Nachdem systemstart() unverändert bleibt, benötigen wir noch sowas wie startup()

Dann würde es so aussehen
[HIGHLIGHT=EPC]
[SYSTEMSTART]
if startup() then read(); .... endif

if a=b then systemstart=EIN endif

[EIBPC]
if systemstart() then .... endif
[/HIGHLIGHT]

Ja, genau! Ich dachte ja zuerst noch an:
[HIGHLIGHT=EPC][SYSTEMSTART]
if !systemstart() then
{..}
[/HIGHLIGHT]
oder
[HIGHLIGHT=EPC][SYSTEMSTART]
if after( X, 1u64 ) then
{..}
[/HIGHLIGHT]
aber dein Vorschlag ist deutlich verständlicher.

Schade eigentlich, das ausgerechnet systemstart() schon belegt ist, sonst hätte ich es im systemstart-Bereich verwendet.

Wie wäre es dann, den Bereich Startup-Bereich zu nennen?

[HIGHLIGHT=EPC]
[STARTUP]
if startup() then read(); .... endif

if a==b then systemstart=EIN endif

[EIBPC]
if systemstart() then .... endif
[/HIGHLIGHT]

[SnowMaKeR]

Jetzt hab ich es auch verstanden.
Bis SYSTEMSTARTEND=EIN verarbeite alles wo systemstart() drin vorkommt.
Danke für die Sondererklärung

Mir gefällt diese Lösung aber nicht so recht.
Zu unübersichtlich. Da muss man zu viel überlegen.
Denk doch mal an die armen Elektriker.

Marc´s Lösung find ich Spitze.
Klar strukturiert, einfach zu verstehen. Passt.
Auch wenn ich schon die ersten schreie höre: Mein EIBPC verarbeitet mein Programm nicht, weil in der Sektion [SYSTEMSTART] vergessen wurde systemstart=EIN zu setzen

Eine neue Funktion braucht es dann wegen dem Validierungsschema trotzdem, oder?
Ein READ braucht ja immer einen Auslöser.
Oder wird das genau einmal ausgeführt?
[HIGHLIGHT=EPC]
read (GA)
[/HIGHLIGHT]

Wenn nicht:
Nachdem systemstart() unverändert bleibt, benötigen wir noch sowas wie startup()

Dann würde es so aussehen
[HIGHLIGHT=EPC]
[SYSTEMSTART]
if startup() then read(); .... endif

if a=b then systemstart=EIN endif

[EIBPC]
if systemstart() then .... endif
[/HIGHLIGHT]

Gefällt mir...