Astro binding on snapshot #1031 delayed 30s compared to #1025

Add-ons Bindings
1

My time of day rule suddenly fails to register BED time because of slower astro triggering at midnight.
Instead of BED ie after 00:00 it becomes EVENING.

Midnight event @00:00 on build #1025:

2017-09-03 00:00:00.035 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:minus90
2017-09-03 00:00:00.054 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:home
2017-09-03 00:00:01.004 [INFO ] [lipse.smarthome.model.script.weather] - It's Sunday BED

On build #1031:

2017-09-05 00:00:02.005 [INFO ] [lipse.smarthome.model.script.weather] - It's Tuesday EVENING
2017-09-05 00:00:30.063 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:minus90
2017-09-05 00:00:30.072 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:home

The rule already sleeps 2000ms for astro to finish, but sleeping 30s is not a good idea.

@gerrieg Any thoughts on why it has become slower?
Maybe just introduce a timer to trigger rule body after 60s?

Cheers

2

There was a recent change in ESH, the 30s delay was added to make really sure jobs are scheduled for the coming day and not the old one.
Not sure why this is a problem for you ( if you want things to happen right at 00:00, why not use cron).

3

It will be reverted as soon as another hickup with the cron scheduler is fixed:

4

No biggie, but it breaks @rlkoshak 's TimeOfDay ‘Design Pattern’ and even worse, my bedroom light turns on when I enter after midnight waking up the missus :open_mouth:

5

@sihui, did the issue for having multiple cron triggers on the same rule ever get fixed?

If it has, @OMR change the triggers to the “Get time period for right now” rule to:

  Channel 'astro:sun:home:rise#event' triggered START or
  Channel 'astro:sun:home:set#event' triggered START or
  Channel 'astro:sun:minus90:set#event' triggered START or
  Time cron "0 0 6,23 * * ? *" or
  Time cron "0 1 0 * * ? *"

Which will put the midnight run at 00:01 instead of midnight. You can remove the Thread::sleep from the rule in this case as well.

**EDIT: The cron trigger problem has been fixed, do not use the code below. **

If we still can’t have cron triggers then change the rules as follows:

import org.eclipse.xtext.xbase.lib.Functions

val Functions$Function0<Boolean> calcTOD = [ |
  val long morning_start = now.withTimeAtStartOfDay.plusHours(6).millis
  val long day_start = (vSunrise_Time.state as DateTimeType).calendar.timeInMillis
  val long afternoon_start = (vEvening_Time.state as DateTimeType).calendar.timeInMillis
  val long evening_start = (vSunset_Time.state as DateTimeType).calendar.timeInMillis
  val long night_start = now.withTimeAtStartOfDay.plusHours(23).millis
  val long bed_start = now.withTimeAtStartOfDay.millis

  var curr = "UNKNOWN"

  switch now {
        case now.isAfter(morning_start) && now.isBefore(day_start):       curr = "MORNING"
        case now.isAfter(day_start) && now.isBefore(afternoon_start):     curr = "DAY"
        case now.isAfter(afternoon_start) && now.isBefore(evening_start): curr = "AFTERNOON"
        case now.isAfter(evening_start) && now.isBefore(night_start):     curr = "EVENING"
        case now.isAfter(night_start):                                    curr = "NIGHT"
        case now.isAfter(bed_start) && now.isBefore(morning_start):       curr = "BED"
  }

  if(vTimeOfDay.state.toString != curr) {
    logInfo(logName, "Current time of day is now " + curr)
    vTimeOfDay.sendCommand(curr)
  }

  true
]

rule "Calculate time of day state"
when
  System started or
  Channel 'astro:sun:home:rise#event' triggered START or
  Channel 'astro:sun:home:set#event' triggered START or
  Channel 'astro:sun:minus90:set#event' triggered START or
  Time cron "0 0 6,23,0 * * ? *" // there is currently a bug where only one cron is triggered per rule so I've combined all three into one
then
    if(now.isBefore(now.withTimeAtStartOfDay.plusSeconds(1)) {
        createTimer(now.plusSeconds(45), [| calcTOD .apply() ]
    }
    else {
        calsTOD.apply()
    }
end

This is only a workaround pending the issue above being fixed at which point you can revert to the DP as written.

1 Like
6

This also did the trick, but not a lasting solution :slight_smile:

Thread::sleep(35000) // make sure we are a tad past midnight to give Astro a chance to recalculate DateTimes for today

7

Until a very recent change (merged today) makes it into the SNAPSHOT, that is a bad solution because a Thread::sleep in a System started rule will cause all other Rules to be ignored. Thus, for example, any rules you have that trigger on changes to vTimeOfDay may be missed if the System started rule doesn’t exit fast enough.

8

Yes, found it “merged” end of April:

1 Like
9

Then I will test this rule change tonight. About 3hrs to midnight my time now.

10

Worked just fine:

2017-09-07 00:00:30.056 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:minus90
2017-09-07 00:00:30.066 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:home
2017-09-07 00:01:00.005 [INFO ] [lipse.smarthome.model.script.weather] - It's Thursday BED
1 Like