This is fixed in Release 2.5 (RC1)

 

-------------------------------------------------------------------------

 

 

A bug was introduced in 2.4.15 and unfortunately affects most schedules.

 

The bug is that at the time the schedule is being compared, the 'Time is' time must exactly match the current time, instead of allowing for a 15 minute buffer. This buffer is needed if the comparison is delayed for any reason (system busy, etc).

 

eg.

If your 'Time is' time is 9:00:00AM, but the schedule is compared at 9:00:01AM, the program will not run. Had the 15 minute buffer been working, if it was compared between 9:00:00AM and 9:15:00AM it would have run.

 

All 'Time is' schedule entries may be affected, and this will likely be intermittent.

 

Note: Although we chose a buffer of 15 minutes, in all practical cases a schedule will always run within a couple of seconds of its specified time.

 

The bug is now fixed, and will be in the next drop.[/b]

Hello Chris & Michel:

 

Thanks so much for taking the issues that we see seriously, and acting on them so quickly!

 

In the meantime, should we go back to 2.4.13, or is the next revision drop imminent?

 

 

Best wishes,

Would this be a valid workaround?

 

If
         From     Sunset
         For       2 minutes

Then
         Set    Scene 'Exterior Scene' On

Yes, your workaround will work.

Hello Chris:

 

Just another data point: this morning my "outside lights off" program did not run (for the first time) under 2.4.15.

 

It did not run even though I use the "random" feature as follows"

 

****************************

 

If

Time is Sunrise - 10 minutes

 

Then

Wait 20 minutes (Random)

Set 'Hall KPL A - Porch Light' Off

etc, etc......

 

****************************

 

Is this the same bug? I didn't think that it would effect schedules where the "random" setting was used. But maybe it already has the "random" start time calculated, and if it's busy at that "randomly" selectetd time then the same bug occurs.

 

If so, how do I write the random programs to make certain that they are reliable until you produce the next beta drop?

 

 

 

Thanks

I would try something like this:

 

If
       Time is Sunrise - 10 minutes

Then
       Wait  20 minutes  (Random)
       Repeat 4 times
          Set 'Backyard' Off
          Wait  10 seconds

Else
  - No Actions - (To add one, press 'Action')

Hello Chris:

 

Is this the same bug? I didn't think that it would effect schedules where the "random" setting was used. But maybe it already has the "random" start time calculated, and if it's busy at that "randomly" selectetd time then the same bug occurs.

 

If so, how do I write the random programs to make certain that they are reliable until you produce the next beta drop?

 

Thanks

 

This is the same bug, basically it affects any schedule using 'Time is' (regardless of the actions in Then/Else).

 

The work-around until the next drop is to change your 'Time is' to 'From'/'For', making the 'For' 5 minutes.

The work-around until the next drop is to change your 'Time is' to 'From'/'For', making the 'For' 5 minutes.

 

This isn't always an appropriate fix...

 

If for example you have something like this:

 

Pseudo code ahead....

 

IF

8:00AM M-F

THEN

Turn on bedroom lights

wait 1 hour

turn off bedroom lights

 

I guess the 'wait 1 hour' is the killer... I'm not exactly sure why, but when I put in that fix indicated above (until/for 1 minute) the turn-off command was never fired.

 

Dave

Release candidate for 2.5 is out now anyway... this issue should be fixed.

DaveGee,

 

You are absolutely right, the 'For' should have been at least as long as the actions would take. What happens is when a schedule begins, the condition becomes true (in this case, causing 'Then' path to run), and when it ends the condition becomes false (causing the 'Else' path to run).

 

 

Anyway, 2.5 (RC1) is now available and it contains a fix for the base problem base problem.

 

 

The work-around until the next drop is to change your 'Time is' to 'From'/'For', making the 'For' 5 minutes.

 

This isn't always an appropriate fix...

 

If for example you have something like this:

 

Pseudo code ahead....

 

IF

8:00AM M-F

THEN

Turn on bedroom lights

wait 1 hour

turn off bedroom lights

 

I guess the 'wait 1 hour' is the killer... I'm not exactly sure why, but when I put in that fix indicated above (until/for 1 minute) the turn-off command was never fired.

 

Dave