@rlkoshak you’re an expert in this field , any tips? Sunset just elapsed and nada. No proxy set, nothing in the logs
Sunrise/Sunset not working with the Astro binding and the Time of Day rules 
As a workaround I believe some weather bindings such as darksky provide sunrise and sunset times.
Id rather get this working - because it should.
Install the astro binding, create the items and set the long/lat, as far as I know thats ALL thats needed
my items;
/* 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:local:rise#start" }
DateTime vSunset_Time "Evening [%1$tH:%1$tM]" <sunset> { channel="astro:sun:local: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:minus90:set#start" }
String vDaylight_Duration { channel="astro:sun:local:daylight#duration" }
Number:Angle vSun_Azimuth { channel="astro:sun:local:position#azimuth" }
Number:Angle vSun_Elevation { channel="astro:sun:local:position#elevation" }
Number vMoon_Percent { channel="astro:moon:local:phase#name" }
Just curious. For rise and set what happens if you use event instead of start?
Id have to wait till tomorrow to tell you Bruce…but ill try it because it sure as hell isnt working as it is 
EDIT: I do use the events to set sunrise/sunset though for my proxies, but they dont work either. The documentation states if your location is set thats all you need to do for lat/long and that Ive checked is correct
rule "Turn on Sunset Flag"
when
Channel 'astro:sun:local:set#event' triggered START
then
Sunset.sendCommand(ON)
end
rule "Turn on Sunrise Flag"
when
Channel 'astro:sun:local:rise#event' triggered START
then
Sunrise.sendCommand(ON)
end
1 Like
You could be in a situation where you’ve run out of Rule Threads. Do you have long running Rules, e.g. Rules with Thread::sleep, while loops, locks, calls to executeCommandLine or sendHttpXRequest? If you have five Rules waiting around for one of these calls to complete than no other Rule will be allowed to run until one of those file exits. See (OH 1.x and OH 2.x Rules DSL only] Why have my Rules stopped running? Why Thread::sleep is a bad idea.
And this can be even worse for Astro Events because I think those come out of the timer thread pool which, until pretty recently, only had two threads available. So if you have any Rules with the above long running calls that are triggered by Astro events and cron triggered Rules, you only need 2 running before you starve out the others from being able to run. As of 2.5 M3 I think the thread pool size for timers was increased to 10.
I’m really not so much an expert in Astro. And I’ve moved from Rules DSL now and don’t even use the Channel Triggers to drive Time of Day (see updates to [Deprecated] Design Pattern: Time Of Day which provide a Python version which I will be submitting to the Helper Library once I figure out Ephemeris so you can have different times of day based on the type of day).
1 Like
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 
ok ill shorten it a little 
Why not put the lat/long entries ( & Time Zone) in the Paper UI system where they belong? The Astro Things get auto discovered.