In General Simple rules are better. This doesn't always mean smaller. I think the resource cost of the wait (whether it be a scheduled task or a event subscription) is going to be about the same.
For something like this I would do it as one rule.
1 Like
Thanks for the quick take on this - much appreciated!
Simple is good, and I wouldn't worry too much about constructing rules to benefit Hubitat's processing of them. Within reason*, Hubitat probably doesn't care which one you do. What you should care about is your ability to understand how the rule is working, and how much sense it will make to you if you need to modify the rule a year from now.
If it was me, I'd have one rule called Curtains Open and Close, which gets triggered at the two different times of day, and conditionally does the right thing. No wait involved.
- what I mean by this is as long as it isn't something really inefficient like checking every second if it is time to do something with the curtains.
2 Likes
That makes sense to me. I will try this route tonight.
I'll agree with the above, I try to be as simple as possible and normally make a rule to turn something on and rule to turn something off.
I find if you have two separate triggers (sunset, sunrise) its easier and usually more reliable to just do two rules. Also helps to find a way to organize your rules. Whether that is a leading character or emoji or whatever. I like using the emoji's to group my rules and then name the rules the action they are performing.
1 Like
Wow. I hadn't noticed. 
Yea, hehe looking at big page of words just sends me into blank stares. I need pictures! Especially on menus at restaurants.
1 Like
I also use that approach. One rule, two triggers, no wait.
2 Likes
Are you emoji in the phone app or the desktop browser?
John
I add one to each of the devices and it puts them in the rules for me. I can then edit the rule name if I want. Usually, I put one in front so it groups by type of device I am triggering. I get the emoji's from emojipedia.com and just search for what I want, then click on the copy button.
1 Like
-
I love that my first post has so much engagement after just a few hours. I am impressed by the responsiveness of this community. This alone provides the value to ditch smartthings for good!
-
Sounds like there is nothing to lose with either route. I appreciate the different perspectives, and will try a few options to see what I prefer.
-
Emojis, man.
Using a "wait for event" is effectively the same as using an additional trigger (it creates a temporary event subscription) and eliminates the need for the conditional processing. and is more in line with what ha been dubbed the KISS method.
1 Like
@lewis.heidrick ... now that's a list of rules 
I noticed on your list there are numerous icons but when I checked mine, I don't have any. Did you add the icons or did HE do it for you?
To me, "Certain Time" is the trigger, if that is a factor in any way, a new rule is likely warranted.
I have a bunch of "Certain Time" rules, they kick off whatever actions are desired at that moment, wherever possible I double, triple, etc the actions up, and they just execute. Takes a couple seconds with near zero demands placed on the hub.
I learned (the hard way) that a rule with a very long list of if-then-else conditions (think something triggered by one of many light switches, with an action being performed on whichever switch triggered the action) resulted in a remarkable processing delay that did not exist when I broke it up into one rule for each device. Not sure why that's the case (given the low computing cost of if-then-else statements), but since then I've tried to keep the rules as simple as I can to be safe.
One also needs to understand that the sudo code created by RM is not executed directly. RM is a large complex piece of groovy code that interprets the rule...So itās a bit more than just running a bit of code. If you really want it fast...learn groovy
Is that the Linux variant of pseudo code?
