I want to set up a rule that only fires when it’s dark out. I’m currently using the Astro binding with rules that fire on channel triggers for sunset and dawn, but I don’t think there’s a way to directly apply them in the “only if” clause of a main UI rule.
My current thinking is to set a switch item status, on at sunset, off at dawn, and use that in my other rules. This seems just a little janky, are there other approaches I should consider?
I’m currently on 3.3.0, will be upgrading to 3.4 next month.
I use a string item called Time_of_day for stuff like this. Sunset triggers it to change to Night, and sunrise changes it to Day. Then my other rules just check the state.
I have a Daylight switch, for exactly this purpose, it’s set by a rule triggering on the Astro binding daylight#event channel.
As an alternative you could use the sun elevation, also from the Astro binding, then you wouldn’t need a rule to set it, just connect it to the correct channel. (Only if Astro_Sun_Elevation < 0)
On the contrary, this is really the core concept of home automation. The system has access to an array of different status indicators and makes decisions based on those indicators. In this case you are using one quick rule to establish the status of daylight and then that status indicator informs other automation decisions. That’s no different than my rule that calls my router API to establish which family phones are currently connected to the WiFi and sets presence status switches which then determine various presence based automations.
In this particular instance there are dozens of slight variations, which astro channels you use, the type and granularity of the time of day information you want, but just about every system out there that automates something is going to have some variation on this exact pattern.
As Justin stated, it’s about making information we need regularly available for other automation decisions. Similar to the Time_of_day string item, I also have a System_mode string item with states like Home, Away, and Sleeping, which is used as a condition in most of my rules.
These proxy items also simplify how I think of my home/system. Should this rule run if it’s day time or night time? When I’m home or away? It’s just a little easier to wrap my head around than “only run if it’s after this time and before this time”.
This is the reason I’m not totally comfortable with it – I could see several different switches for one-off rules; the one thing that. I want to stay on until sunrise instead of dawn, etc. The extra switch creates a layer of abstraction that I’m not really looking for, but may have some benefits also.
I already have a home/away switch and will probably be adding more.
If it’s really a one off rule, then that’s what the astro trigger events are for. Each of the astro periods has START and END trigger events, and those (as the name implies) can trigger rules just like items can. I can tell you from experience, however, that the majority of my rules that started out that way, over time, moved to an item-based trigger of one form or another because for me that “extra layer of abstraction” is useful, easier to work with in scripts, and just a little easier conceptually.
I can’t use the astro tiggers directly this is a "if this changes, do that, but only if it’s dark.
I’m already using astro triggers for “turn this on a sunset” type of rules.
I’ve just created the item and the rules to manage it.
create a time based state machine (lucky you, you don’t even need to code it, there’s one on the marketplace) which sets a state Item like @rpwong’s time_of_day Item which you can check in the conditions of the rule
Astro has some actions that let you query it for some stuff like when a certain event occurred (e.g. dawn), sun elevation and sun angle. So you could create a condition script that calls these actions to determine whether or not the rule should run at that time. Though if you have more than one such rule, it’s better to set that in an Item and have only one rule do the calculation for you (hence that recommendation above from everyone).
You can create a rule that enables/disables other rules. So you could have one rule that triggers at dusk to disable the rules that should not run at that time and another at dawn to reenable them (or with a bit of cleverness write a script and merge this into one rule).
You could add an if statement to each rule that cares and check an Item linked to the Astro Channel, or use the Actions like discussed above.
These are all not mutually exclusive. You could have a time based state machine that triggers rules that enable/disable rules based on the general time of day period.
And these approaches are not limited to time. I have an IsCloudy Item that causes some rules to do different things without needing to each run the calculation that determines if it’s cloudy in each rule. I’ve a pair of rules that enable and disable some rules that only are valid at Christmas time, driven by a Switch Item. I’ve a rule template in the Marketplace (OH 4 and later only unfortunately) that triggers at runlevel 40 and disables a bunch of rules and then at a configured time after runlevel 100 is reached reenables them to suppress some rules that go nuts during system startup.
Thanks Rich. If this project ever has an award for project educator, it should go to you. Appreciate all the time you take for your thorough answers.
As an aside, I used the isy99/isy499 with Insteon for many years, one of its features was folders for rules; you could disable a folder to implicitly disable all the rules inside that folder. I found that very useful for “away” and “holiday” rules.
Thanks! I could contribute through code but early on I decided that I’d be more useful and learn more if I was a forum helper than coding add-ons and features. Though some day I might dip my toes into creating an add-on or something.
For an example of enabling/disabling rules you can look at my Delayed Startup rule template on the Marketplace. That shows how to do it in GraalVM JS Scripting (it’s just a one liner really). It can also be done in Blockly or even just UI rules without any code at all. That and rule conditions are two very powerful capabilities that I think are underused, especially by old timers who grew up without UI rules as an option so I like to be sure to bring them up.
One simple case, as you allude to, could be to enable a rule such as Presence Simulation which plays back the states of Items (e.g. lights) from a number of days ago to simulate presence (see Generic Presence Detection which uses the Debounce Rule Template) when a Switch representing presence switches to OFF and then disables it when someone returns.
A long time ago I noticed that there really are just a few problems that pop up over and over again in home automation. I started out by writing Design Pattern Tutorials but as soon as rule templates became a thing I’ve moved most of them, at least the ones that make sense, to rule templates. Why show how to code it when I can offer a full implementation that you can just install and configure.
