[Featurewunsch] EibPC Programmteile eine definierbare Zeit nach dem Neustart starten

[pio]

Es gibt immer noch Missverständnisse mit dem Validierungsschema des EibPC. Dies führt u.a. dazu, dass es nicht ohne Hilfsvariablen möglich ist, einen Code-Teil des EibPC erst nach einer gewissen Zeit nach Systemreboot zu starten, und diese "Freigabe" auch in jede IF-Anweisung zusätzlich eingebaut werden muss, die nicht sofort ausgeführt werden soll.

Beispiel:
Beim Systemstart möchte ich 100 GAs abfragen (z.B. Fekos, Heizungszustände, ...), was einige Sekunden dauert, und dann erst mein Hauptprogramm starten, wenn alle diese Zustände eingelesen und bekannt sind.

Siehe auch diesen Beitrag: https://knx-user-forum.de/eibpc/1055...stemstart.html

Vorschlag zur Umsetzung:
[EibPC1=0u64]
// wird sofort nach Neustart ausgeführt

[EibPC2=1000u64]
// wird nach einer Sek ausgeführt

[EibPC3=60000u64]
// wird nach einer Min ausgeführt

[saft6luck]

Mein Favorit ist zwar immer noch der [systemstart] Bereich, der verlassen wird, wenn man systemstart=EIN setzt, womit dann im Programm immer noch auf systemstart() abgefragt werden kann ...
aber Zeitlich konfigurierbare Bereiche haben auch ihren Scharm.

Ich bin jedenfalls für eine Lösung der leidigen Systemstart Problematik!

Ps. Pio, evtl. kannst du diese Lösung noch mit aufnehmen lassen?

[pio]

Grübel Grübel - mal sehen, ob ich die Abstimmung noch anpassen kann ...

Im nachhinein würde ich auch als Minimal-Option akzeptieren, dass es 2 Sektionen gäbe, [systemstart] und [EibPC=xxxu64],
falls das für Enertex einfacher zu implementieren wäre.

Grundsätzlich sollte natürlich systemstart() nach wie vor in allen Sektionen nutzbar sein.

Edit: äh nee, kann nicht mehr ändern. Soll ich mal nen Admin belästigen?

[SnowMaKeR]

Ich brauch das zwar (bisher) nicht.
Aber Bernds Vorschlag gefällt mir am besten.

was einige Sekunden dauert, und dann erst mein Hauptprogramm starten, wenn alle diese Zustände eingelesen und bekannt sind

Geht das nicht heute schon mit sleep?

[saft6luck]

Geht das nicht heute schon mit sleep?

Sleep() unterdrückt die Ausgabe der Telegramme und ist hierfür nicht zielführend, da ... tataaa ... dann alle Zustände so eingestellt sind, als ob die Telegramme raus gegangen sind. Die damit verbundenen Probleme sollten klar sein, oder?

[SnowMaKeR]

Jep, stimmt.
Hab ich nicht zu Ende gedacht.

[Tessi]

Ich habe jetzt auch für zusätzliche Sektionen gestimmt, weil es besser ist, als gar nichts. Aber im Grunde genommen wünsche ich mir Sektionen, deren Ausführung generell von einer Bedingung abhängig gemacht werden können, um z.B. bei Ausbleiben einer zyklischen Info davon abhängende Schritte so lange auszusetzen, bis die Info wieder aktuell ist.

Sicher, das geht auch mit einem großen if (eval(...)){...} Block, aber dann kann ich den Sonderfall einer Zeitverzögerung nach Start genau so behandeln.

Auch ist einfach nur warten auf Zeit kein Allheilmittel. Ich habe das Problem, das manche Geräte die ein oder andere Anfrage einfach mal nicht beantworten (bevorzugt dann, wenn viele davon hintereinander kommen), da hilft nicht warten sondern nur später noch einmal anzufragen.
Daher nützt obiges Feature in dem Fall nur wenig.

Ähnlich ist es mit einem Neustart wenn kein Zeitmaster verfügbar sein sollte. Da der EibPC die Systemzeit nicht puffert müssten alle uhrzeitabhängigen Aktionen dann so lange suspendiert werden, bis eine gültige Zeit vorhanden ist, egal wie lange das dauert. Auch dafür ist das gewünschte Feature zu unflexibel.

[pio]

Ich habe jetzt auch für zusätzliche Sektionen gestimmt, weil es besser ist, als gar nichts. Aber im Grunde genommen wünsche ich mir Sektionen, deren Ausführung generell von einer Bedingung abhängig gemacht werden können, um z.B. bei Ausbleiben einer zyklischen Info davon abhängende Schritte so lange auszusetzen, bis die Info wieder aktuell ist.

Das machst Du mit
if change(ccc) then
oder
if event(ddd) then

Sicher, das geht auch mit einem großen if (eval(...)){...} Block,

Achtung auf die Falle mit den inneren if, die dann immer ausgeführt werden ...

aber dann kann ich den Sonderfall einer Zeitverzögerung nach Start genau so behandeln.

Wie "genau so"? Meinst du mit den Sektionen?

Auch ist einfach nur warten auf Zeit kein Allheilmittel. Ich habe das Problem, das manche Geräte die ein oder andere Anfrage einfach mal nicht beantworten (bevorzugt dann, wenn viele davon hintereinander kommen), da hilft nicht warten sondern nur später noch einmal anzufragen.
Daher nützt obiges Feature in dem Fall nur wenig.

In diesem Fall sind Deine Daten sowieso nicht mehr aktuell, und du solltest bei jeder Abfrage auch noch prüfen, ob geantwortet wurde (innerhalb einer gewissen Zeit). Dann ggf. nach Zeit xxx und in Abhängigkeit einer Variablen "xxx_ist_aktuell = EIN od AUS" nochmal fragen.

Ähnlich ist es mit einem Neustart wenn kein Zeitmaster verfügbar sein sollte. Da der EibPC die Systemzeit nicht puffert müssten alle uhrzeitabhängigen Aktionen dann so lange suspendiert werden, bis eine gültige Zeit vorhanden ist, egal wie lange das dauert. Auch dafür ist das gewünschte Feature zu unflexibel.

Moment, was Du meinst ist die interne Uhrzeit, die evtl. nicht über NTP aktualisiert wurde.
Was ich in den Sektionen vorschlage hat nichts mit Uhrzeit zu tun, sondern mit einem einfachen Timer.
Wenn die Timer nicht mehr funktionieren, hast Du sowieso ein grösseres Problem.

[anlo007]

Moment, was Du meinst ist die interne Uhrzeit, die evtl. nicht über NTP aktualisiert wurde.

Das Problem mit der Uhr habe ich ach und deshalb hab ich auch mit abgestimmt für eine Verzögerung. Auf dem Lande ist mein Internet nicht sehr schnell und deshalb hole ich mir die Zeit erst vom Bus aus dem wiregate. Bis diese Zeit vorhanden ist, sind alle hTimer oder cwtimer Abfragen sinnlos bzw. führen zu falschen Schaltvorgängen. Auch muß ich erst alle Thermostaten ausgelesen haben, bevor der EibPC entscheiden kann, ob er die Heizung auf Sommer- oder Winterbetrieb stellt. Sleep ist dafür keine Lösung.

[Tessi]

Das machst Du mit
if change(ccc) then
oder
if event(ddd) then

Ja, klar, aber wenn große Blöcke von Aktionen halt von einer Bedingung abhängen wird das aufwändig und daher mit Sektionen einfacher.

Achtung auf die Falle mit den inneren if, die dann immer ausgeführt werden ...

Ich habe bislang noch nicht mit verschachtelten If-Anweisungen gearbeitet (eben wegen des Validierungsschemas) allerdings dachte ich bislang, das das Problem genau anders herum wäre, das die inneren wegen des Validierungsschemas garantiert nicht ausgewertet werden, wenn die äußere nicht ausgewertet wurde, aber wenn die äußere immer ausgewertet wird, würde auf die inneren dann dennoch wieder das Validierungschema angewendet werden. Ist das also so nicht richtig?

Wie "genau so"? Meinst du mit den Sektionen?

Nein, eigentlich meinte ich mit einem großen if (eval(...)){...} Block (statt neu zu schaffender Sektionen)...
... aber solltest Du recht haben würde das nicht wie erwartet funktionieren.

In diesem Fall sind Deine Daten sowieso nicht mehr aktuell,

Die beantworteten schon denn nachfolgende Änderungen bekommt der EPC ja mit. Bis dahin unbeantwortete Anfragen sind ja generell nicht aktuell und ich muß entscheiden, was ich daraufhin tun will (Default annehmen oder alles davon Abhängige nicht mehr laufen lassen.)

und du solltest bei jeder Abfrage auch noch prüfen, ob geantwortet wurde (innerhalb einer gewissen Zeit). Dann ggf. nach Zeit xxx und in Abhängigkeit einer Variablen "xxx_ist_aktuell = EIN od AUS" nochmal fragen.

Ja, genau. Und weitere Befehle sollten so lange verzögert werden können, bis dieser Vorgang abgeschlossen ist.
OK, grundsätzlich kann ich das mit Timeouts versehen (muß ich wahrscheinlich sogar) und dann den Rest erst nach Ablauf der längstmöglichen Zeit bis dahin starten, aber schöner wäres es halt, wenn der Start erfolgen kann, wenn alle geantwortet haben oder mehrere Abfragen inklusive Timeout fehlgeschlagen sind und nicht erst nach Ablauf der Worst-Case-Zeit.

Moment, was Du meinst ist die interne Uhrzeit, die evtl. nicht über NTP aktualisiert wurde.
Was ich in den Sektionen vorschlage hat nichts mit Uhrzeit zu tun, sondern mit einem einfachen Timer.
Wenn die Timer nicht mehr funktionieren, hast Du sowieso ein grösseres Problem.

Richtig, Dein spezielles Problem läßt sich einfach mit einer festen Wartezeit lösen. Aber wenn schon geändert werden sollte fände ich einen flexibleren Ansatz wünschenswerter.
Grundsätzlich kann ja auch Dein Anliegen schon mit vorhandenen Möglichkeiten (vor allen Statements kommt ein if, so wie Du das zur Lösung meines Anliegens oben vorgeschlagen hast) gelöst werden.
Die neuen Sektionen würden nur eine Erleichterung/Vereinfachung darstellen und wenn das kommen sollte würde ich es mir halt noch flexibler wünschen.

[enertegus]

Ich habe bislang noch nicht mit verschachtelten If-Anweisungen gearbeitet (eben wegen des Validierungsschemas) allerdings dachte ich bislang, das das Problem genau anders herum wäre, das die inneren wegen des Validierungsschemas garantiert nicht ausgewertet werden, wenn die äußere nicht ausgewertet wurde, aber wenn die äußere immer ausgewertet wird, würde auf die inneren dann dennoch wieder das Validierungschema angewendet werden. Ist das also so nicht richtig?

Also es ist so, dass alles was im then Zweig steht, von der if-Abfrage ungültig gemacht wird. Wenn dann eine weitere If-Abfrage in der Schleife steht, so wird diese auch ungültig und daher in jedem Fall neu ausgewertet.
Beispiel:
[highlight=epc]
A=EIN
B=AUS
z=0
if after(systemstart(1000u64)) then {
if A then B=AUS endif ;
read('1/2/3'b01);
write('3/3/74'b01,AUS);
if ('3/3/3'b01) then write('3/3/4'b01,AUS) endif;
if !('3/3/3'b01) then write('3/3/4'b01,EIN) endif
}endif
if after(systemstart(2000u64)) then {
if ('3/3/3'b01) then write('3/3/4'b01,AUS) endif;
if !('3/3/3'b01) then write('3/3/4'b01,EIN) endif
}endif

[/highlight]
Wenn also '3/3/3'b01 auf EIN steht (1 Sekunde nach Programmeinspielen), so wird '3/3/4'b01 auf AUS geschrieben. 2 Sekunden nach Programmeinspielen wird '3/3/4'b01 dann erneut auf AUS geschrieben , egal ob bereits nach einer Sekunde geschrieben wurde.

[pio]

Ja, klar, aber wenn große Blöcke von Aktionen halt von einer Bedingung abhängen wird das aufwändig und daher mit Sektionen einfacher.

Genau meine Ueberlegung.

Ich habe bislang noch nicht mit verschachtelten If-Anweisungen gearbeitet ..... würde auf die inneren dann dennoch wieder das Validierungschema angewendet werden. Ist das also so nicht richtig?

Das ValSchema wird zwar angewendet, aber, wie Enertegus erklärt hat, dadurch ausgehebelt, dass bei Eintritt in den Then-Zweig alle Zustände von Variablen innerhalb dieses Then-Zweiges für ungültig erklärt werden, und deshalb neu ausgewertet werden.

Einfacheres Bspl als oben:

Annahme: A, B und C alle gleich EIN (1b01)

if A == 1 then {
                 if B then write (xxxxx) endif;
                 if C then write (yyy) endif
} endif

Hier werden bei Eintritt in den Then-Teil der A==1 Abfrage
beide innen benutzen Variablen B und C für ungültig erklärt, auch wenn sie vorher schon beide EIN waren.
Sie werden dann von den inneren IFs erneut ausgewertet, und es werden schlussendlich zwei Telegramme auf den Bus gesendet.
Geht A dann auf 0, wird das äussere if neu ausgewertet (Änderung von A), und der Then-Teil nicht ausgeführt.
Geht A dann wieder auf 1, gehts wieder in den Then-Teil rein und es werden wieder 2 Telegramme gesendet, obwohl sich B und C immer noch nicht geändert haben.

Nein, eigentlich meinte ich mit einem großen if (eval(...)){...} Block (statt neu zu schaffender Sektionen)...
... aber solltest Du recht haben würde das nicht wie erwartet funktionieren.

Das hat bei mir zur Katastrophe (=blockierter EibPC) geführt.

[Tessi]

Das hat bei mir zur Katastrophe (=blockierter EibPC) geführt.

Danke für die Warnung.
bleibt also wirklich derzeit nur, die Bedingung A in jede abhängige Bedingung (hier B und C) einzeln mit aufzunehmen. Was für ein Aufwand, dabei sollte das Validierungsschema doch alles vereinfachen...
So gut es gemeint ist, manchmal habe ich das Gefühl, das Validierungsschema torpediert meine Versuche strukturiert zu arbeiten...

Ist es wirklich notwendig, bei Eintritt in einen then-zweig alles darin invalid zu machen? In welchen Fällen ist das nützlich/sinnvoll?
Wie wäre es mit einer Option, genau dieses eben nicht zu tun?

[enertegus]

Ist es wirklich notwendig, bei Eintritt in einen then-zweig alles darin invalid zu machen? In welchen Fällen ist das nützlich/sinnvoll?
Wie wäre es mit einer Option, genau dieses eben nicht zu tun?

Mal etwas ausführlicher zum Hintergrund - nicht dass man uns hier reine Dummheit unterstellt.

[highlight=epc]
// Ansatz 1
if TasteA then {
if TasteB then write() endif
} endif
[/highlight]
ist halt was anderes als
[highlight=epc]
// Ansatz 2
if TasteA and TasteB then write() endif
[/highlight]
was Du wohl meinst. Wir hatten die Überlegung, dass das "Innere" einer if-Schleife durch "Äußere" nur unterdrückt wird, bis die äußere Abfrage auf 1b01 geht (Quasi eine Art Sperrobjekt). Dies lässt sich aber durch den Ansatz 2 realisieren und wir wären auch nicht glücklich damit, weil man dann den Ansatz 1 nicht mehr realisieren kann. Eine Alternative wäre eine Alternative if-Abfrage zu bauen, z.B.

[highlight=epc]
// Ansatz 3
condition TasteA then {
if TasteB then write() endif
} endif
[/highlight]
Dann muss aber das auch noch erklärt werden... Ich weiss, jetzt kommt gleich "Das ist aber kein Argument", wohl aber doch: Man kommt sonst schnell in die Ecke "Alles zu kompliziert". Außerdem sind ja Ansatz 2 und Ansatz 3 exakt gleichwertig.

Ich denke Ansatz 2 versteht jeder sofort und daher wurde im Handbuch auch darauf verwiesen, so zu coden ("Vermeiden von Verschachtelungen"), wohl bewusst, dass eine if-Abfrage wie Ansatz 3 arbeiten könnte.

Wenn man nun mal vom if-Verschachteln absieht, will man ja eigentlich die Auswertung der Objekte im then-Zweig anstoßen.
[highlight=epc]
// Validierung der if-Abfrage
if TasteA then {
write();
read();
connecttcp();
....
endif
[/highlight]
Nun muss jedes Objekt von if auf invalid gesetzt werden, damit es ausgeführt wird. Damit erklärt sich, warum die innere if-Abfrage ungültig wird und warum Ansatz 1 das eigentliche Verhalten der Verschachtelung darstellt.

[saft6luck]

Also ich brauche noch etwas, bis ich aus dieser Erklärung schlau werde!

Warum ist Ansatz 1 nicht gleich Ansatz2????? Später aber doch wieder??????????????

Warum beschreibt Ihr das ominöse Verhalten bei Verschachtelungen nicht?
Warum muss ein write(), read() oder connecttcp() im then Zweig auf invalid gesetzt werden????????

Mir schwant allmählich was es mit diesem sonderbaren "das Programm ist als Binärbaum abgespeichert" auf sich hat, alleine mir ist nicht klar, warum die ganzen Erklärungen im Handbuch fehlen!