In der Tiefe: Validierungskonzept

[saft6luck]

Bei mir hier schon:
[highlight=epc]
// Sonnenaufgang
Rollo_Sonnenaufgang_frueher = 15s08
Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_frueher; /* -> Minuten: -15 <= m <= 44 */

if change( Rollo_Sonnenaufgang_m_s ) then {
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08;
} endif
} endif

Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 )
[/highlight]
Rollo_Sonnenaufgang_m im Debugger anschauen ...

Da wir dann ja soweit sind, evtl. kannst du dann meine anfängliche Frage ja beantworten (siehe Posting #194)?

[enertegus]

Bei mir hier schon:
Rollo_Sonnenaufgang_m im Debugger anschauen ...
Da wir dann ja soweit sind, evtl. kannst du dann meine anfängliche Frage ja beantworten (siehe Posting #194)?

Hab ich gemacht, und das Ergebnis scheint mir richtig.
Ich habe auch noch eine Ausgabe gemacht, um zu sehen, ob change triggert: es wird nicht beim Systemstart getriggert.
[highlight=epc]
Rollo_Sonnenaufgang_frueher = 15s08
Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_frueher; /* -> Minuten: -15 <= m <= 44 */

if change( Rollo_Sonnenaufgang_m_s ) then {
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08;
write('0/0/1'u08,10);
} endif
} endif

Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 )
[/highlight]

[Tessi]

Also als Studie über die Tücken im Verständnis des ach so einfachen und logische Validierungsschemas finde ich dieses Beispiel hier ja ganz gut. Aber wenn hier Rollos vor Sonnenaufgang geöffnet werden sollen, dann würde ich dafür nicht eine bestimmte Zeit vor Sonnenaufgang wählen, sondern einen bestimmten Winkel unter dem Horizont (so 3°-4° dürften im Mittel 20min dauern). Das entspricht auch eher einer bestimmten Helligkeit als eine fixe Zeitspanne vor Sonnenaufgang, und ist deutlich einfacher zu codieren. Gilt analog auch für Xmin nach Sonnenuntergang...
Rechnen im hh:mm:ss-Format ist nun einmal häßlich, wenn es dafür keine Funktionen gibt, und auf eine lineare Zeitdarstellung, wie sie die Systemuhr von Linux verwendet, hat der User ja leider keinen Zugriff!

[enertegus]

sondern einen bestimmten Winkel unter dem Horizont (so 3°-4° dürften im Mittel 20min dauern).

Das geht mit azimuth und elavation.

[saft6luck]

Aber wenn hier Rollos vor Sonnenaufgang geöffnet werden sollen, dann würde ich dafür nicht eine bestimmte Zeit vor Sonnenaufgang wählen, sondern einen bestimmten Winkel unter dem Horizont (so 3°-4° dürften im Mittel 20min dauern). Das entspricht auch eher einer bestimmten Helligkeit als eine fixe Zeitspanne vor Sonnenaufgang, und ist deutlich einfacher zu codieren. Gilt analog auch für Xmin nach Sonnenuntergang...

Ja, ungeachtet der Methode, die Helligkeit richtig abzuschätzen, wird es dynamisch geschehen. Debugging mit der Konstanten ist da aber einfacher.

[saft6luck]

Hab ich gemacht, und das Ergebnis scheint mir richtig.

Du bist ja ein toller Tester!
Die Konstante muss so gewählt werden, dass die Abfrage auch erfüllt wird (heute z.B. 30)-> musst also 2 Tests machen.

[enertegus]

Du bist ja ein toller Tester!

Klar

Die Konstante muss so gewählt werden, dass die Abfrage auch erfüllt wird (heute z.B. 30)-> musst also 2 Tests machen.

Hä, ich dachte, es geht Dir um die Initialisierung?

[Tessi]

Ja, ungeachtet der Methode, die Helligkeit richtig abzuschätzen, wird es dynamisch geschehen.

Irgendwie verstehe ich nicht, was mir das sagen soll.

Debugging mit der Konstanten ist da aber einfacher.

Klar, aber Code soll doch in erster Linie möglichst optimal das Problem lösen. Und wenn Du einfach elevation() nutzt, dann mußt Du gar nicht debuggen, denn wenn die nicht tut was sie soll kann das eh nur Enertex ändern...

[enertegus]

Klar, aber Code soll doch in erster Linie möglichst optimal das Problem lösen.

Mir ging es eher um Grundsätzliches, weniger um die Realisierung an sich.

[saft6luck]

Hä, ich dachte, es geht Dir um die Initialisierung?

Ja, da ist eine Abfrage drinnen und wenn du die Konstante nicht größer als die Minuten des Sonnenaufganges wählst, wird es auch keine Änderung geben.
Du solltest dir dann auch noch den tatsächlichen Sonnenaufgang ausgeben.

[highlight=epc]
Rollo_Sonnenaufgang_frueher = 30s08
Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_frueher; /* -> Minuten: -15 <= m <= 44 */

if change( Rollo_Sonnenaufgang_m_s ) then {
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08;
write('0/0/1'u08,10);
} endif
} endif

Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 )
[/highlight]

[saft6luck]

Irgendwie verstehe ich nicht, was mir das sagen soll.

Du hast recht damit, dass man die Helligkeit auch mit dem Sonnenstand direkt abschätzen kann.

Klar, aber Code soll doch in erster Linie möglichst optimal das Problem lösen. Und wenn Du einfach elevation() nutzt, dann mußt Du gar nicht debuggen, denn wenn die nicht tut was sie soll kann das eh nur Enertex ändern...

Das Problem habe ich ja nicht beschrieben.

Bei mir sollen die Rollos automatisch auf und zu gehen. Möglichst nicht vor 7:00 im Schlafzimmer, im restlichen Haus nicht vor 6:00, schließen sollen sie helligkeitsabhängig, die Terrassen- und Balkontür wird ausgeschlossen, wenn die Tür offen ist und insgesamt nicht später als 22:00.

In der Visu soll die entsprechende Zeit angezeigt werden (möglichst schon für die ganze Woche, aber das ist eher ein Wunsch).

Der Code-Schnipsel ist reduziert auf das Problem, auf das ich gestoßen bin.

[enertegus]

Ja, da ist eine Abfrage drinnen und wenn du die Konstante nicht größer als die Minuten des Sonnenaufganges wählst, wird es auch keine Änderung geben.

Also nochmal: Beim Initialisieren wird die Konstante gesetzt, das sollte da keine change()-Funktion triggern, so war das vorausgesagt und das stimmt. Darum gings mir. Wenn der Sonnenstand sich später ändert, wird dann aber change() getriggert.
[highlight=epc]
if change( Rollo_Sonnenaufgang_m_s ) then {
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08;
} endif;
write('0/0/1'u08,10);
} endif
[/highlight]
Hier sieht man, dass dem auch so ist: In meinem Beispiel wird change() beim Systemstart nicht getriggert. So soll es sein.
Nun habe ich aber die Startvariable geändert, so dass ein Überlauf autritt (also z.B. 55). Das sollte eigentlich wie zuvor sein, also change() beim Initialisieren nicht triggern. Tut es aber doch, also hier ist er, der BUG, wenngleich hier das Ergebnis eigentlich sogar gewünscht wäre.

Naja, schwere Geburt, aber immerhin habe ich nun vielleicht verstanden, was Dir nicht klar war (und auch es nicht sein konnte). . Ich vermute dass der Überlauf die change-Variable irgendwie triggert. Werde das morgen in den Bugreport einreihen...

[saft6luck]

Nun habe ich aber die Startvariable geändert, so dass ein Überlauf autritt (also z.B. 55). Das sollte eigentlich wie zuvor sein, also change() beim Initialisieren nicht triggern.

Tut es aber doch, also hier ist er, der BUG, wenngleich hier das Ergebnis eigentlich sogar gewünscht wäre.

Naja, schwere Geburt, aber immerhin habe ich nun vielleicht verstanden, was Dir nicht klar war (und auch es nicht sein konnte). . Ich vermute dass der Überlauf die change-Variable irgendwie triggert. Werde das morgen in den Bugreport einreihen...

Ja, das hatte ich gemeint
Zur Info: Schau dir das Beispiel in #194 an, da gibt es keinen Überlauf (meinst du überhaupt einen Überlauf oder sprichst du von der Überlauf-Abfrage) und es wird trotzdem getriggert.

Und wirklich, ich dachte inzwischen, dass der change richtig sei und der 2. Fall einen Fehler hat. Gut, dass es nicht so ist. Dann mache ich noch den Systemstart() rein und es passt wieder.

Immerhin weiß ich jetzt auch, dass Änderungen von Variablen im nächsten Zyklus erscheinen.

[saft6luck]

Habt ihr den Fehler denn schon eingrenzen können?

[enertegus]

Habt ihr den Fehler denn schon eingrenzen können?

Ich hab das nur reportet- wir arbeiten ja noch an anderen Dingen.
Meine Vermutung: Zunächst wird initialisiert und change triggert nicht. Beim Überlauf (intern ist das sicher 32 Bit) wird ggf. versehentlich change getriggert. Ich hoffe mal nix großes - wir wollen ja bald nun eine neue Version freigeben.