In der Tiefe: Validierungskonzept

[saft6luck]

Da kann ich nix helfen. Es ist schon so wie im pdf beschrieben. Wir hatten noch überlegt, else gar nicht erst zuzulassen, weil uns diese Problematik bewusst war. Allerdings gibt es da eben manchmal doch eine gewisse Eleganz beim Coden...

Schreibst du das entsprechend ausführlich ins Handbuch?

Bleibt die Frage, warum das Verhalten so gewählt wurde, wie es nun implementiert ist, bzw. ob das wirklich so bleiben muss/soll? Nach meinem Verständnis erwartet ja auch kein Profi-Elektriker solch ein Verhalten, oder?

Wie sind in diesem Zusammenhang GAs zu bewerten? Der Inhalt ändert sich doch erst beim Schreiben auf den Bus. Ist das dann also kein Problem für das else, da alles erst am Ende des Zykluses in die Warteschlange kommt (und damit auf den Bus)?

[enertegus]

Schreibst du das entsprechend ausführlich ins Handbuch?

Was fehlt da denn nun noch? Im Abschnitt zum Validierungskonzept sind dazu Beispiele ist erläutert.

Bleibt die Frage, warum das Verhalten so gewählt wurde, wie es nun implementiert ist, bzw. ob das wirklich so bleiben muss/soll? Nach meinem Verständnis erwartet ja auch kein Profi-Elektriker solch ein Verhalten, oder?

Die Probleme enstehen bei der Verwendung von der Form
if Ausdruck then verändere(Ausdruck) endif
Dies kommt aus KNX Sicht m.W. nicht vor. Es ensteht erst durch die Verwendung von Variablen etc.

Wie sind in diesem Zusammenhang GAs zu bewerten? Der Inhalt ändert sich doch erst beim Schreiben auf den Bus. Ist das dann also kein Problem für das else, da alles erst am Ende des Zykluses in die Warteschlange kommt ?

Ja. Außerdem wird das Abbild erst wieder beim Entreffen des Telegramms neu gesetzt.

[saft6luck]

Was fehlt da denn nun noch? Im Abschnitt zum Validierungskonzept sind dazu Beispiele ist erläutert.

Klar, ich habe es nun ja auch verstanden aber man muss da erst drauf kommen. Das sollte keine Eigenleistung sein, sondern ein klarer Hinweis sollte auf den Sachverhalt hinweisen und eben das Beispiel genau erklärt werden.

Wenn es dann auch noch Unterschiede bei Variablen und GAs gibt ...

Die Probleme enstehen bei der Verwendung von der Form
if Ausdruck then verändere(Ausdruck) endif
Dies kommt aus KNX Sicht m.W. nicht vor. Es ensteht erst durch die Verwendung von Variablen etc.

Aus KNX Sicht kommt das sehr wohl vor, nur hat es dort keinen Einfluss, da GAs ja frühestens im nächsten Zyklus, so wie ich dich verstehe aber erst mit dem eigentlichen Empfang der Aussendung, einen neuen Wert annehmen.

Und das macht es so undurchsichtig. Selbst wenn ich Variablen verwende, muss eine 'direkte' Änderung nicht gegeben sein. Und im 2. Durchlauf wird z.B. systemstart() ja nicht mehr TRUE sein.

NB. bei GAs ist dann u.U. der Zeitpunkt wichtig, zu dem man das write() im Code platziert

[enertegus]

Aus KNX Sicht kommt das sehr wohl vor, nur hat es dort keinen Einfluss, da GAs ja frühestens im nächsten Zyklus, so wie ich dich verstehe aber erst mit dem eigentlichen Empfang der Aussendung, einen neuen Wert annehmen.

Bitte ein Beispiel.

[saft6luck]

Bitte ein Beispiel.

IF GA1 and GA2 == AUS then write( GA2, EIN ) endif

[enertegus]

IF GA1 and GA2 == AUS then GA2 == EIN endif

Aber da gibt es kein Problem. Oder wo versteh ich Dich nicht?

[saft6luck]

Die Probleme enstehen bei der Verwendung von der Form
if Ausdruck then verändere(Ausdruck) endif
Dies kommt aus KNX Sicht m.W. nicht vor. Es ensteht erst durch die Verwendung von Variablen etc.

IF GA1 and GA2 == AUS then write( GA2, EIN ) endif

Aber da gibt es kein Problem. Oder wo versteh ich Dich nicht?

Stimmt, nur kommt genau der Ausdruck, den du da ansprichst häufig vor. Ich hatte dich schon verstanden.

Ein Beispiel für if then else endif könnte das Weiterschalten von Lichtszenen sein, mit Abfrage auf Überlauf, aber wie bekannt gibt es mit GAs
ja eh keine Probleme dieser Weise.


Ps. hatte oben die Zuweisung als Vergleich, hattest du aber als write() verstanden, oder?

[enertegus]

Ps. hatte oben die Zuweisung als Vergleich, hattest du aber als write() verstanden, oder?

so isses.

[anlo007]

Wenn ich meine Umfrage anschaue, ist die deutliche Mehrheit der Teilnehmer für meinen Vorschlag, und der ist Zielgruppenunabhängig. (Es sei denn, Du betrachtest Installationen, bei denen keine GA durch die Abfrage des Systemstarts eingelesen werden soll, als eine eigene Zielgruppe, die sich gravierend von dem Rest unterscheidet.)

Hier ist ein Mißverständnis, auch ich habe für die Verzögerung des Starts gestimmt. Der EibPC sollte nach meiner Meinung erst den Logikteil abarbeiten, wenn er die Systemstart-Abfragen erledigt hat und die Antworten eingetroffen sind, denn erst dann macht die Auswertung Sinn.

Gerade der Teil der Forderung fällt in den Bereich, den ich mit "für jeden Häuslebauer geeignet" fällt und der unbedingt verbessert werden sollte.

[Tessi]

Der EibPC sollte nach meiner Meinung erst den Logikteil abarbeiten, wenn er die Systemstart-Abfragen erledigt hat und die Antworten eingetroffen sind, denn erst dann macht die Auswertung Sinn.

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? Z.B. ich habe noch keine aktuelle Uhrzeit (und das könnte noch länger so bleiben) und kann daher alle uhrzeitgesteuerten Teile nicht starten, alles andere ist aber initialisiert und soll nicht mehr länger warten.

Gerade der Teil der Forderung fällt in den Bereich, den ich mit "für jeden Häuslebauer geeignet" fällt und der unbedingt verbessert werden sollte.

Ja, nur über das wie sollte man gut nachdenken, sonst treiben wir Teufel mit Belzebub aus...

[enertegus]

Hier ist ein Mißverständnis, auch ich habe für die Verzögerung des Starts gestimmt. Der EibPC sollte nach meiner Meinung erst den Logikteil abarbeiten, wenn er die Systemstart-Abfragen erledigt hat und die Antworten eingetroffen sind, denn erst dann macht die Auswertung Sinn.

Wie wärs denn mit einer paramertierbaren Zeit bis zum Erstabarbeiten nach dem Systemstart()-Aufruf? Das wäre wohl am einfachsten zu realisieren!

[SnowMaKeR]

Hi Michael,

die Frage versteh ich nicht.
Erst alles mit systemstart(), nach Ablauf der Zeit alles andere?


Wenn Ihr zu viel umbauen müsstet, könntet Ihr auch statt systemstart() was neues nehmen.

[anlo007]

Z.B. ich habe noch keine aktuelle Uhrzeit (und das könnte noch länger so bleiben) und kann daher alle uhrzeitgesteuerten Teile nicht starten, alles andere ist aber initialisiert und soll nicht mehr länger warten.

Das Problem mit der Uhrzeit habe ich auch, da mein Internet nicht gut funktioniert auf dem Land. Ich mache es zur Zeit so, das ich die Zeit aus einer anderen Komponente (LOGO!) auslese und mit der Zeit erst mal arbeiten kann, bis der EibPC oder das wiregate wieder die genaue Zeit empfangen hat.

Wie wärs denn mit einer paramertierbaren Zeit bis zum Erstabarbeiten nach dem Systemstart()-Aufruf? Das wäre wohl am einfachsten zu realisieren!

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

[Uwe!]

Wie wärs denn mit einer paramertierbaren Zeit bis zum Erstabarbeiten nach dem Systemstart()-Aufruf? Das wäre wohl am einfachsten zu realisieren!

Dann lieber eine eigene Funktion "EndSystemstart". Die kann ich dann wahlweise mit einem after() ö.ä. als fixe Zeit oder über Logik an bestimmte Ereignisse knüpfen (z. B. das Eintreffen von gewissen Antworten)

[enertegus]

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

Wie sieht denn das der Rest hier so?