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? 
i don't pretend to know how the rule engine works, but i can't imagine that it has to interpret its own pseudo-code more than once... that would be terribly inefficient. as for bypassing the rule engine by writing my own code, i would do that if there were no other way around my problem (and there was). that said, i have been meaning to play around with creating a parent/child device relationship and seeing if i can subscribe to events from one device driver in another device driver and trigger actions based on those events... maybe someday i'll actually have time to do that, but i wouldn't bet on it.
I would definitely say 2 rules. I currently have some blinds that i'm controlling with a relay, and I control them using virtual switches. I then trigger the rules based on these virtual switches.
By having a wait, the rule will be running through the course of the day, and put unnecessary load on the hub. Just trigger it, open, done. Trigger it, close, done.
2 Likes
The wait doesnāt actually make the rule hang out in a waiting state. It simply add an event subscription for that action. (Like adding a second trigger to a rule) so one could say a second rule is more resource heavy as the second rule will fire any time that event occurs and the one rule will only fire if the first trigger has gone and the rule has progressed to the point of the wait action.
1 Like
Long, long ago when dinosaurs roamed the earth and I was a baby programmer and worked for a company that shall remain nameless, I was asked to make a change to a certain program on a mainframe. Now, this particular program processed data in a dataset that resided on magnetic tape... multiple volumes of magnetic tape. It was expensive to run and had a very long processing time because after each volume was processed, a human had to remove that tape and hang the next volume (this was reel-to-reel tape). And, you know, people miss console messages and take coffee breaks and whatever. Because there was so much data on these multiple tape volumes, and it needed to be processed serially (because tape), any function that needed that data had to be in that one program. Entire business systems resided in the program. There was one senior systems analyst whose entire job consisted of the care and feeding of that program. When I was asked to make a change, I was told, "Put this line of code right here. Don't touch anything else!"
Everyone knew that the data should be moved onto something a little more modern that could be read randomly, rather than serially. And everyone knew that the program needed to be torn apart and rewritten (probably as multiple systems composed of multiple programs). But everyone was afraid to do it because it was a mission critical thing and nobody knew what it actually did. Even the guy whose job was to support it wasn't sure of all its functions, and he'd supported it for years.
Anyway... when I consider whether a function requires one rule or two, it might be better err on the side of simplicity.
Having said that... shortly after RM4 was released, I created a rule that was so complex I couldn't even open it to edit it. At that point I decided I didn't really need the rule that ate my hub, and I split it up into around 10 rules, and I've been really much happier. So do as I say and not as I do. 
1 Like
That is really good info and changes the way I think about building some rules. Previously I thought of the "wait for" as the rule looping a waiting state for a condition to change....which is not the most efficient. Learning that "wait for" is a subscription to an event will alter how I create rules. Thanks for the tip 
What about "delayed" actions? Are those idle loops or are they subscriptions to timer events?
2 Likes
That doc describes the ability to "wait " or "delay" but it doesn't explain how they are implemented internally as you explained they are scheduled timer events versus processor loops. It does mention that "wait for" introduces another trigger-like capability but does not say that about delayed actions . It makes a difference in the context of this thread about rule best practices and efficiency
