I have checked the date and also the lat/long which the Astro binding uses to provide sunset/sunrise times.
It appears something is wrong though as I have a rule which sets a proxy item for sunrise and sunset.
In this case, the proxy for sunrise is happening hours after the event start of the Astro binding
Rule:
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
The binding shows sunrise today was 6:09AM which is correct
However the log indicates that the rule fired hours later despite the system clock being correct also
2019-10-21 09:38:39.026 [ome.event.ItemCommandEvent] - Item 'Sunrise' received command ON
2019-10-21 09:38:39.026 [vent.ItemStateChangedEvent] - Sunrise changed from OFF to ON
The machine is extremely grunty so it’s not relating to CPU load etc.
rule "Calculate time of day state"
when
System started or
Channel 'astro:sun:local:rise#event' triggered START or
Channel 'astro:sun:local:set#event' triggered START or
Channel 'astro:sun:minus90: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
This Thing has absolutely nothing to do with the one you are complaining about.
This Thing essentially has the name “minus90”.
The Thing that you are looking at events for is “local”
We have no idea which Thing is associated with your vSunrise_Time Item
All this shows, is that you have a vSunrise_Time item and a vSunset_Time item, neither are related to the channel that should trigger your rules.
If you have defined this via Habmin, we can’t tell from this picture if the name of the channel you are using, is the correct one. If you open the Local sun thing in PaperUI, does it show “astro:sun:local:rise#event” as the name for the range event of the Sunrise section?
And if you check the settings of that channel (click the pencil), what does it show there?
Then it’s the configuration of “local” you need to be checking.
The configuration of “minus90” is irrelevant to “local” events.
“local” is generally auto created by Astro binding, based on system defaults. Hence the advice to check your system locale etc.
As you probably did not set that up via a xxx.things file, you should check in PaperUI for unexpected location or offsets.
This morning, it got sunrise at 6.37am, better and no changes compared to yesterday which was well past 8am
@ihp:/etc/openhab2/rules$ cat /var/log/openhab2/events.log | grep Sunrise
2019-10-22 06:37:00.445 [ome.event.ItemCommandEvent] - Item 'Sunrise' received command ON
2019-10-22 06:37:00.449 [vent.ItemStateChangedEvent] - Sunrise changed from OFF to ON
2019-10-22 06:37:00.463 [vent.ItemStateChangedEvent] - Sunrise changed from ON to OFF
@ihp:/etc/openhab2/rules$
Anyone know why the sunrise proxy switch is being turned on like 40minutes past when sunrise actually occurs as per the Astro binding?
Makes no sense. You can see the Astro binding sets sunrise to 6.06AM, yet the proxy gets set to ON at 6.44AM
Is the use of the " as opposed to ’ correct for the CHANNEL trigger? I notice the timeofday.rules uses ', rather than "
2019-10-23 00:00:30.010 [vent.ItemStateChangedEvent] - vSunrise_Time changed from 2019-10-22T06:07:00.000+1100 to 2019-10-23T06:06:00.000+1100
2019-10-23 06:44:09.631 [ome.event.ItemCommandEvent] - Item 'Sunrise' received command ON
2019-10-23 06:44:09.644 [vent.ItemStateChangedEvent] - Sunrise changed from OFF to ON
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
Looking at your HABmin screenshot, the Item that you happen to have called vSunriseTime is linked to the “Day” channel of the Astro binding - not sunrise.
I’ve no idea what the Astro binding considers as daybreak, civil dawn perhaps. It gets light before sunrise.
Or perhaps full sunlight, after sunrise is complete.
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
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 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 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).