I’m starting again with OH and rewriting my v2 rules using the UI and Blockly where possible, just to experience the new v3 UI and to find out a bit of a new user experience.
So, the first question is more rule overhead related.
I’m creating a time of day rule - updating a vItem to state Dawn, Morning, Day etc. In OH2 I told it to run at the various specific times that I wanted it to, dawn, dusk etc. I was just recreating the rule and it got me thinking, I clearly can tell a cron to run the rule every minute to go and check the timeofday status rather than just at specific times of the day, but how wasteful is this really?
I can’t imagine the overhead of a tiny rule script having a significant system impact running every minute rather than just 6 specific times a day - but I bow to the superior knowledge of the community here…can it?
Yes thanks, I’ve got all my astro set up and cron expressions, I was just wondering if it was lazy and massively extra system resource to just tell the rule to run every minute or to tell the rule to run at the 6 specific times of the day I need to get it to change from ‘Night’ to ‘Morning’ to ‘Day’ etc.
This is certainly true. A quick rule running every minute shouldn’t be a significant tax on your resources. It is likely, however, that if you need to run a rules in OH every minute, you’re not really taking advantage of the event-based backbone of OH. For sure, there are some reasons to run a rule every minute (I have several that make calls to different APIs to gather information that is best when updated every minute). But something that’s only going to happen a few times a day is almost certainly going to be captured better by some sort of discrete event.
For my ToD system, I use a different rule for each change so that rule can be customized to the event that most closely matches. For some, that’s just astro daylight events (afternoon → evening), but others might be based on house activity (evening → bedtime) or even multiple different factors such as phone alarm or set time which ever comes first (night → wake up).
So the question becomes, “what do you gain by doing this?” If the answer is nothing, then don’t do it. I don’t know the specifics of your system so I can make concrete suggestions at this point, but in general you really want to try and craft a rule so that it matches actual requirements of that particular action.
Are your Time of Day events at fixed times? Then there is no reason at all to prefer a cron expression to just running the rule at those fixed times.
Do you need your Time of Day events to be accurate down to the minute? If not, then why every minute instead of every 5 minutes or 10 minutes?
If you have the astro binding set up, then why are the automatic event from that binding not sufficient for your ToD needs?
Thanks, to be honest, it’s probably just laziness!
My ToD is part Astro settings and part fixed times based on household activity. I was going to set 6 triggers based on the 6 times of day the ToD will be required to change but I just thought rather than creating 6 triggers I’d just use one cron that runs every minute.
Part laziness in me having to add one trigger rather than multiple and also part with an eye to easy future code knowing that I just need to add new if statements and not worry about the trigger if it runs every minute.
If there was no negatives then I was going to go with the every minute trigger, if it really was a system drain or totally lazy then I’ll do it properly
If you want to to have a virtual item representing time of the day, you can trigger your rule by events from the astro binding (there should be events for sunset, sundawn, noon etc) and no need at all to run a rule by cron
Thanks, I have some astro and some fixed times for the various ToD I have. The manuals are set around our family timings so I was just seeing if setting the triggers as per the various astro and fixed was the best way or if the cron every 1 minute was a lazy way around it
One advantage to the separate triggers instead of one per minute is if you add the “Schedule” tag to your rule, it will show up on the calendar on the Schedule page in MainUI showing you when the rule will run and therefore show you graphically when your times of day transition. If you run it every minute that won’t work.
One other approach which is a little more configuration but might give you more flexibility would be to use the Time Based State Machine [3.2.0;3.4.9]. Where this gives you more flexibility is:
you don’t have to write any rules code at all, all you need is a set of DateTime Items with some metadata, and a Group
you can use DateTime List Item and DateTime Standalone Widget to set your fixed times of day from MainUI. That means you and/or your family could have the option to change the schedule without needing to modify rules. The schedule is all held in Item states.
you have the option to have a different set of times set for different types of day (weekdays, weekends, hoilidays, etc.).
For static Items, you might also need To Today [3.2.0;3.4.9) to move the date times that don’t come from Astro or other sources forward at to the current day at midnight.
Don’t miss the new Time is <item> rule trigger. I suspect you might be able to apply that to your system.
Speaking of that new trigger, @MadFrankie, if your timing needs are simple and you don’t need the Time based State Machine, perhaps still using a set of DateTime Items (with the DateTime widgets for the fixed times of day) and separate super simple rules using that Time is <item> trigger to transition would be the best balance between flexibility and simplicity. I don’t know if these rules will currently show up on the Schedule but bet they will eventually. Then you can see not only when your transitions between times of day are, but what the transitions are (assuming you name your rules well).
Thanks @rlkoshak, very interesting, I’ll take a look a the time machine.
That is certainly an advantage…I might have a fiddle around with the current rule and see the differences in the calendar and have a think if it will of use in the future.
