Astro binding provides sunrise events but the rule fires hours later? Odd

Hi Rich

No, i dont use one thread sleep at all nor do I have any of those types of rules. The system has about 25 rules so far which all relate to motion for Zwave and they all use createTimer.

Re; binding, I have a thing created in the things file for local sun, but the moon is auto created

Cheers

How often do those Rules trigger, or more importantly, how many Timers do you have going at any given time? How often do you have two timers going off at the same time? Unless you are running a very recent OH you can only have 2 running at the same time and I don’t know if the Timers waiting to run are put into a FIFO (first in, first out) so if it’s particularly busy you could be seeing a starvation situation.

If not, I’ve no idea what could be going on.

Hi Rich

How would I determine that? they trigger when the motion detection is triggered but only when the lux is under 20, so really only at night. There are only 25 rules. Other rules relating to time of day run fine (for changing the time of day for example)

Im using 2.4.0 Stable on a i3 8th gen CPU.

I have about 23 of these rules:


rule "Bed 4 detection turns ON Lights when Lux is less than 40, with a 5 Minute Inactivity Timer"
when
       Item Downstairs_Bed4_Motion_Alarm changed to ON
then
      if(Bed4_Motion_Armed.state == ON){
               if (Downstairs_Bed4_Motion_Lux.state < 20) {
                if (Bed4_Timer !== null) {
                        Downstairs_Bed4_Downlights_Sw1.sendCommand("ON")
                        Bed4_Timer.reschedule(now.plusMinutes(Bed4_TimeOut))
                } else {
                        Downstairs_Bed4_Downlights_Sw1.sendCommand("ON")
                        Bed4_Timer = createTimer(now.plusMinutes(Bed4_TimeOut))
                        [ |
                                if (Downstairs_Bed4_Motion_Alarm.state == ON) {
                                        Bed4_Timer.reschedule(now.plusMinutes(Bed4_TimeOut))
                                } else {
                                        Downstairs_Bed4_Downlights_Sw1.sendCommand("OFF")
                                        Bed4_Timer = null
                                }
                        ]
                }
        }
}
end


Rules triggered by events run from a separate thread pool. So starvation caused by Timers would not impact those Rules. Only Time triggered Rules and Astro Channel Triggered rules.

You can easily see when the Timers are executing by adding logging statements to them. You could even add a logging statement to indicate when the Timer is supposed to go off and then a log statement in the Timer to see when it actually fires and you can go through the logs to see how many are running at the same time.

Fair enough, well when the rule is MEANT to execute, which is sunrise, there are no rules running because theres no motion. And even if there was, it would be 2 events TOPS.

I checked this morning when the rule was meant to run for Sunrise and disable the motion sensing and nothing was going on, I sat there and watched the karaf log
 nothing. No motion events, no other events, just items updating their temperatures.

Its clearly not a starvation issue if rules triggered by events are from a seperate thread pool and to be honest, all the motion driven lights work just fine.

Woah, you’re using xxx.things file but it’s contents are still secret? Golly, this is like pulling teeth.

Okay, a possible area for elimination. As already noted, Astro binding creates a Thing named “local” based on default system details. If you are also making a Thing called “local” there is a potential confusion.

Make a new Thing called something else - “home” say. In fact I’d make new Items and new rules to go with that. so that you can compare how they all work in parallel for now.

The content of the things file rossko was posted in post 5.

This? Is that all of the relevant Astro Things?

But that Thing is called minus90
It has nothing to do with those events and channels you are actually using, that are all referenced to a Thing called local.

Then local would have been auto created by paperui, as it clearly exists. Ill delete it all then.

If you have simple mode turned on the general advice here is to turn it off.

1 Like

rossko, ive created a new things file (simple mode off)

astro:sun:castlecove  [ geolocation="-33.788449709457765,151.22889793899816,0", interval=60 ]
astro:moon:castlecove [ geolocation="-33.788449709457765,151.22889793899816,0", interval=60 ]

new Items file, with the new name:

/* Astro Binding Items*/

Switch Sunset
Switch Sunrise

String vTimeOfDay "Current Time of Day [%s]" <tod>

DateTime vMorning_Time "Morning [%1$tH:%1$tM]" <sunrise>

DateTime vSunrise_Time "Day [%1$tH:%1$tM]" <sun> { channel="astro:sun:castlecove:rise#start" }

DateTime vSunset_Time "Evening [%1$tH:%1$tM]" <sunset> { channel="astro:sun:castlecove:set#start" }

DateTime vNight_Time "Night [%1$tH:%1$tM]" <moon>

DateTime vBed_Time "Bed [%1$tH:%1$tM]" <bedroom_blue>

DateTime vEvening_Time "Afternoon [ %1$tH:%1$tM]" <sunset> { channel="astro:sun:castlecove:set#start" }

String vDaylight_Duration { channel="astro:sun:castlecove:daylight#duration" }

Number:Angle vSun_Azimuth { channel="astro:sun:castlecove:position#azimuth" }

Number:Angle vSun_Elevation { channel="astro:sun:castlecove:position#elevation" }

Number vMoon_Percent { channel="astro:moon:castlecove:phase#name" }

And updated the rules


rule "Turn on Sunset Flag"
when
    Channel 'astro:sun:castlecove:set#event' triggered START
then
    Sunset.sendCommand(ON)
    logInfo("Sunset", "Sunset occuring")
end

rule "Turn on Sunrise Flag"
when
        Channel 'astro:sun:catlecove:rise#event' triggered START
then
    Sunrise.sendCommand(ON)
    logInfo("Sunrise", "Sunrise occuring")
end


rule "Calculate time of day state"
when
  System started or
  Channel 'astro:sun:castlecove:rise#event'    triggered START or
  Channel 'astro:sun:castlecove:set#event'     triggered START or
  Time cron "0 1 0 * * ? *" or
  Time cron "0 0 6 * * ? *" or
  Time cron "0 0 23 * * ? *"

then

  logInfo("Time Of Day", "Calculating time of day...")

  // Calculate the times for the static tods and populate the associated Items
  // Update when changing static times
  // Jump to tomorrow and subtract to avoid problems at the change over to/from DST
  val morning_start = now.withTimeAtStartOfDay.plusDays(1).minusHours(18)
  vMorning_Time.postUpdate(morning_start.toString)

  val night_start = now.withTimeAtStartOfDay.plusDays(1).minusHours(1)
  vNight_Time.postUpdate(night_start.toString)

  val bed_start = now.withTimeAtStartOfDay
  vBed_Time.postUpdate(bed_start.toString)

  // Convert the Astro Items to Joda DateTime
  val day_start = new DateTime(vSunrise_Time.state.toString)
  val evening_start = new DateTime(vSunset_Time.state.toString)
  val afternoon_start = new DateTime(vEvening_Time.state.toString)

  // Calculate the current time of day
  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"
  }

  // Publish the current state
  logInfo("Time of Day", "Calculated time of day is " + curr)
  vTimeOfDay.sendCommand(curr)
end

I guess now I wait!

Just five decimal places in a lat/long locates to within a metre :wink:

:rofl: ok ill shorten it a little :stuck_out_tongue:

Why not put the lat/long entries ( & Time Zone) in the Paper UI system where they belong? The Astro Things get auto discovered.

Hi Bruce, I had that originally. PaperUI does indeed have the correct Lat/long, locations etc etc. But that wasn’t working 
well, when I say wasnt working, the rules werent firing but the times from the astro binding were (as the items had the correct sunrise time etc)

Simple mode doesn’t create Things, only Items. However, there is a setting under System Inbox to auto approve Things from the Inbox. If this is turned off, you must manually approve any discovered Thing from the Inbox.

This setting isn’t a problem because it doesn’t hide anything from you.

More success now @rossko57

Is this the correct definition to define a sunrise event 1hr before actual sunrise as I see it at the same time as sunrise. Certainly comparing it to the OH2.4 doco it appears correct but it also appears to be failing.

Sunrise/Sunset are working correct but the offset is not.

astro:sun:castlecove  [ geolocation="-33.78844,151.22889,0", interval=60 ]
astro:moon:castlecove [ geolocation="-33.78844,151.22889,0", interval=60 ]
astro:sun:timed       "1hr Before Offset" [ geolocation="-33.78844,151.22889,0", interval=60 ]{
  Channels:
    Type rangeEvent : rise#event [
      offset=-60]
}

2019-11-01 05:57:00.016 [vent.ChannelTriggeredEvent] - astro:sun:timed:rise#event triggered START
2019-11-01 05:59:00.004 [vent.ChannelTriggeredEvent] - astro:sun:timed:daylight#event triggered START
2019-11-01 05:59:00.008 [vent.ChannelTriggeredEvent] - astro:sun:timed:rise#event triggered END
2019-11-01 05:57:00.010 [vent.ChannelTriggeredEvent] - astro:sun:castlecove:rise#event triggered START
2019-11-01 05:59:00.001 [vent.ChannelTriggeredEvent] - astro:sun:castlecove:daylight#event triggered START
2019-11-01 05:59:00.006 [vent.ChannelTriggeredEvent] - astro:sun:castlecove:rise#event triggered END

AND

2019-11-01 05:57:00.014 [ome.event.ItemCommandEvent] - Item 'Sunrise' received command ON
2019-11-01 05:57:00.018 [vent.ItemStateChangedEvent] - Sunrise changed from OFF to ON

Your astro:sun:timed setup looks good to me.
I don’t know why the offset didn’t work, but would not be surprised if editing it in after the astro binding has initialized is ineffective in altering scheduling. Trust nothing without a system reboot.

No idea what your Item based events are related to.

Hmmm. Ok, ill try a reboot.

There are no items that relate to this new offset channel. I’m using a trigger channel in a rule

/* Astro Binding Items*/

Switch Sunset
Switch Sunrise
Switch Summer

String vTimeOfDay "Current Time of Day [%s]" <tod>

DateTime vMorning_Time "Morning [%1$tH:%1$tM]" <sunrise>

DateTime vSunrise_Time "Day [%1$tH:%1$tM]" <sun> { channel="astro:sun:castlecove:rise#start" }

DateTime vSunset_Time "Evening [%1$tH:%1$tM]" <sunset> { channel="astro:sun:castlecove:set#start" }

DateTime vNight_Time "Night [%1$tH:%1$tM]" <moon>

DateTime vBed_Time "Bed [%1$tH:%1$tM]" <bedroom_blue>

DateTime vEvening_Time "Afternoon [ %1$tH:%1$tM]" <sunset> { channel="astro:sun:castlecove:set#start" }

String vDaylight_Duration { channel="astro:sun:castlecove:daylight#duration" }

Number:Angle vSun_Azimuth { channel="astro:sun:castlecove:position#azimuth" }

Number:Angle vSun_Elevation { channel="astro:sun:castlecove:position#elevation" }

Number vMoon_Percent { channel="astro:moon:castlecove:phase#name" }

Rule being used with the offset


rule "Lower shutters in Summer months 1hr prior to Sunrise"
when
        Channel 'astro:sun:timed:rise#event' triggered START
then
    val month = now.getMonthOfYear
    if(month < 5 || month >10) {
          gAllSummerShutters.sendCommand(0)
    }
    logInfo("Shutters","Closing Shutters as its Summer")
end

You posted an events.log excerpt related to changes in your Sunrise switch Item. We don’t know what activates that switch, or what you wanted us to notice about it, good or bad. If it doesn’t matter, that’s fine.