If - Vergleich

Das Intervall zerlegen in

15:25-24:00 und
00:00-01:15

macht Dir die Vergleiche viel einfacher.

Beitrag "Zeitvergleich zweier "Uhrzeiten""

zeigt das Prinzip.

Beide Uhrzeiten umrechnen in Minuten. Wenn BIS < AKT oder AKT < BIS 
weiter laufen lassen. Wenn BIS == AKT -> Ziel erreicht.

Setzt natürlich voraus, dass Du in Intervallen < 1 Minute vergleichst.

W.S. schrieb:
> Im Grunde mußt du Buch führen über Ereignisse, die zu vorgebbaren Zeiten
> geschehen sollen.

Nicht nötig.

A. S. schrieb:
> Du hast nun das Problem, dass man auch bei Indizes für ringbuffer hat.

Er hat das Problem, dass man mit "Stunden und Minuten"-Vergleichen 
entweder ein Riesen-Konstrukt aufbaut oder einfach nur mit Minuten 
rechnet. Das letztere ist sinnvoll.

In der Regel prüfen Schaltuhren nur auf Gleichheit. Bei der 
Einschaltzeit wird eingeschaltet, bei der Ausschaltzeit aus. Dazwischen 
passiert nichts.

Schmeiß also die >, < einfach raus.

Peter D. schrieb:
> In der Regel prüfen Schaltuhren nur auf Gleichheit. Bei der
> Einschaltzeit wird eingeschaltet, bei der Ausschaltzeit aus. Dazwischen
> passiert nichts.
>
> Schmeiß also die >, < einfach raus.

Prima - noch einfacher :-) (stimmt, die > < Abfragen sind sinnlos und 
man kann sich die Umrechnung in Minuten sparen)

A. S. schrieb:
> Das geht aber nur, wenn die rtcc nicht separat batterieversorgt ist. Und
> weder schalt- noch Uhrzeit sich ändern.

Du kannst auch den MC puffern, der AVR zieht <1µA im Power-Down. Die RTC 
weckt ihn dann kurz für den Vergleich auf.
Wenn der MC nicht gepuffert wird, geht es aber auch so:
Beitrag "Re: Zeitvergleich zweier "Uhrzeiten""

PittyJ schrieb:
> War auch mein erster Gedanke. time_t daraus machen. Dann hat man eine
> 'handliche' Integer Zahl und braucht nur einen Vergleich.

Will man täglich schalten, muß man vor dem Vergleich noch Modulo 86400 
rechnen. Ein < oder > kann man dann aber auch nicht feststellen, nur ein 
==.

Bernd schrieb:
> Ich hab das jetzt mal bis 24:00Uhr versucht umzusetzen, funktionieren
> tut das nicht
>
> Ausgeschaltet werden soll von:
> 15:22 - 02:30
> //Ab Ausschalt Stunde
> switch_buffer[0]
> //Ab Ausschalt Minute
> switch_buffer[1]
> //Bis Ausschalt Stunde
> switch_buffer[2]
> //Bis Ausschalt Minute
> switch_buffer[3]

1

if (RTC_TimeStructure.RTC_Hours   == switch_buffer[0] &&

2

    RTC_TimeStructure.RTC_Minutes == switch_buffer[1]    )

3

  {

4

    ... Ausschalten

5

  }

6

7

if (RTC_TimeStructure.RTC_Hours   == switch_buffer[2] &&

8

    RTC_TimeStructure.RTC_Minutes == switch_buffer[3]   )

9

  {

10

    ... Einschalten

11

  }

Mindestens 1 mal pro Minute prüfen ... frei nach PeDa

Wobei dann in der "wieder Einschaltzeit" eher 02:31 stehen sollte.

Bernd schrieb:
> funktionieren
> tut das nicht

Du hast ja auch die >, < drin gelassen.
Was stört Dich an der einfachen Variante, nur auf Gleichheit zu testen?

Bernd schrieb:
> Peter D. schrieb:
>>
>> Du hast ja auch die >, < drin gelassen.
>> Was stört Dich an der einfachen Variante, nur auf Gleichheit zu testen?
>
> Ich würde gerne das in den Ausschalt Zeitraum nicht wieder eingeschaltet
> werden soll.
> Ausgeschaltet werden soll von:
> 15:22 - 02:30
>
> Das in den IF-Vergleich zu schreiben das bekomm ich nicht umgesetzt.
>

Es soll eher um 15:22 ausgeschaltet werden und um 02:30 (nächster Tag) 
wieder eingeschaltet werden. Das sind separate Aktionen mit einfacher 
Identität als Bedingung.
So machen das auch "echte" elektronische Schaltuhren, allerdings nicht 
die mechanischen, die tatsächlich zwischen 15:33 und 02:30 den Schalter 
auf "aus" halten. Die elektronischen würden, hätte man das nach 15:21 
aktiviert, erst am Folgetag wie gewünscht funktionieren.

Sowas wird viel einfacher, wenn man modulo verwendet. Einfach alles mod 
24*60 rechnen, und start zum Nullpunkt machen, dann kann man schauen, ob 
mehr Zeit vergangen ist, als das Interval lang ist.

1

// For numbers 0 to 1440 (=24*60), 16 bits would have been enough, but I've used 32 here for the people who are going to forget to increase it later when they add seconds, or upgread to yearly intervals, or do similar things. 

2

uint_least32_t now   = (  now_h*60 +   now_m) %(24*60);

3

uint_least32_t start = (start_h*60 + start_m) %(24*60);

4

uint_least32_t end   = (  end_h*60 +   end_m) %(24*60);

5

6

// check if now is in interval [start, end), with now, start and end being in (mod 24*60)

7

// 24*60 was added to prevent underflows, uint_least32_t has a moduli for underflows which is not a multiple of 24*60, which would otherwise lead to wrong results in that case.

8

bool is_in_range = (uint_least32_t)(24*60 + now - start) %(24*60) < (uint_least32_t)(24*60 + end - start) %(24*60);

PS: Der Code reagiert so, wie das was Carl D. als typisch für 
mechanische Schaltuhren bezeichnet.

Ich finde das Auswerten in Minuten auch am übersichtlichsten.

1

uint8_t  state;

2

uint16_t minutes_off;

3

uint16_t minutes_on;

4

uint16_t minutes_now;

5

6

minutes_off = switch_buffer[0] * 60 + switch_buffer[1];

7

minutes_on  = switch_buffer[2] * 60 + switch_buffer[3];

8

minutes_now = RTC_TimeStructure.RTC_Hours * 60 + RTC_TimeStructure.RTC_Minutes;

9

10

if (minutes_off < minutes_on) // on over midnight

11

  state = (minutes_now >= minutes_on || minutes_now < minutes_off);

12

else

13

  state = (minutes_now >= minutes_on && minutes_now < minutes_off);

14

15

// state == 1: ON

16

// state == 0: OFF

Vorteil von Auswertung mit >= und < ist, dass man die Uhr (das Programm) 
auch innerhalb eines Intervals starten kann und der Ausgang hat sofort 
den korrekten Schaltzustand.
Bei "==" muss man unter Umständen warten bis entweder Ein- oder 
Ausschaltpunkt erreicht wird, damit der Ausgang mit Sicherheit den 
korrekten Zustand hat.

Z.B. die ZUD 132 von meiner Gasheizung schaltet nur bei Gleichheit um. 
Je Ausgang sind bis zu 8 Ein-und Ausschaltzeiten programmierbar, die mit 
Wochentagen verknüpft werden können.
Hat man die Uhrzeit oder Schaltzeiten geändert, kann man manuell 
zwischen ein und aus umschalten.
Schaltuhren mit Bereichstest sind mir nicht bekannt.

Bernd schrieb:
> So wie von Hugo vorgeschlagen auf Gleichheit zu testen funktioniert,
> aber danach kann ich ja wieder einschalten.

Ich denke, das Programm soll das machen - was erzählst Du denn von "aber 
danach kann ich ja wieder einschalten" ?

Bernd schrieb:
> So wie von Hugo vorgeschlagen auf Gleichheit zu testen funktioniert,
> aber danach kann ich ja wieder einschalten.

In der Regel ist es erwünscht, daß man die Uhr überstimmen kann und sei 
es nur zu Testzwecken. Z.B. wenn der Schornsteinfeger die Abgasprüfungen 
macht.

Peter D. schrieb:
> In der Regel ist es erwünscht, daß man die Uhr überstimmen kann und sei
> es nur zu Testzwecken.

Ja, also Ein/Aus/Auto, sollte schon zur Verfügung stehen.

Hugo H. schrieb:
> Bernd schrieb:
>> So wie von Hugo vorgeschlagen auf Gleichheit zu testen funktioniert,
>> aber danach kann ich ja wieder einschalten.
>
> Ich denke, das Programm soll das machen - was erzählst Du denn von "aber
> danach kann ich ja wieder einschalten" ?

Da geht dann auch mit "Ein/Aus/Auto", den gewünschten Zustand 
herzustellen und sofort wieder auf Auto zu stellen. Dann vergisst man 
das nicht und merkt es evtl. erst, wenn's bereits zu spät ist.