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
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.
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.
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.
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
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.
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.
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.
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.