Trying to consolidate multiple RM 3.0 triggers into my first RM 4.0 rule and I can't quite get my head around how to handle checking and acting on the conditions in a single rule. I currently do this with multiple 3.0 triggers which is OK, but I need /want to (I think) get used to working with RM 4.0.
What I want is to do is:
At 4:00 AM turn on front west sprinkler (orbit timer)
When front west sprinkler state changes to ‘open’ turn on virtual switch 'front west sprinkler ran ok’
Sprinkler runs for set time, then closes and status changes to closed
If virtual switch 'front west sprinkler ran ok' switch is on send message to iPhone ‘front west sprinkler ran ok’
Else send message to iPhone ‘front west sprinkler did not run’
Turn off virtual switch front west sprinkler ran ok to get ready for next trigger event
My hope is once I'm able to get this set up it will help me understand better how to go about converting my other 3.0 rules and triggers.
I second the advice above to read the documentation. (If there's anything I'm known for besides telling people who have only been on the platform for a matter of seconds to consider Simple Lighting or Motion Lighting--they're almost always lighting rules--before diving headfirst into RM, it's to read the docs.)
Really, Rule 4.0 is basically what Trigger was in earlier versions, so if you have something that works there, it should work nearly as-is in Rule 4.0. The big difference is that Rule 4.0 added conditionals (actually 3.0 added those, but 4.0 allows them to be nested). You shouldn't have to re-think your Triggers too much. Your rules will have to be re-thought just a little, but not too much: in a "classic" rule, you had conditions, then any change in those caused re-evaluation of the Rule. In Rule 4.0, you only have triggers, so you just need to think about what events you want to trigger your actions (a "changed" trigger on some device is a common option with an IF/ELSE/END-IF in your actions forking according to actual device state, emulating Actions for True and Actions or False, but you can also just trigger off a specific state).
Also, don't be afraid to make things into multiple rules. Just because Rule 4.0 allows some complexity and you can doesn't mean you should. Multiple triggers in particular can be difficult to manage; you can have multiple instances of a rule running (or pending/scheduled), and sometimes it gets tricky to manage what should happen then. Minimizing this by keeping triggers to a minimum and using separate rules if necessary is not bad.
Back to your question: I don't think this should be overly complicated, so one rule is probably fine. I'm not sure what the virtual switch does for you, however. Could you just not have the rule wait until the desired condition is true rather than "storing" that in a switch? (You might have actually needed this workaround in 2.5; I can't remember.) Maybe something like this:
I made some assumptions (it if it doesn't open within 5 minutes of the open command beign issued, I consider it failed, but you can adjust that; and if it doesn't close within 23 hours I have it notify of possible failure there but you can leave that out if you don't care, or you can adjust the time if it shouldn't run for quite that long). I'm also logging instead of notifying for the sake of demonstration.
I don't have one of these devices so don't really know how they work. I am also currently un-caffeinated and may have missed something that will cause the rule to catastrophically fail, so I hope a competent adult checks my work.
Thanks. I'll play with your example, and also read the documentation and the Rule 4.0 release post cited above. I'm sure it will become more clear after I get a few properly functioning rules under my belt>