You can indeed do both of these things! Here's how.
- For "waits" (when you just want a specified period of time to elapse, then continue), the RM action you're looking for is called "Delay." Here's an extremely simple example:
There's a second way you could do this, too:
They are equivalent in this case. The difference is that the first has a "standalone" Delay action, while the second has a delay set on an action. There are two differences that matter in more complex rules: a delay on an action schedules that action for later (when the delay expires) but then continues on to the next action. A "standalone" Delay stops the actions until that delay is up, then continues with the next. Cancellations (more on those later), therefore, work differently too; everything after a "standalone" Delay will be cancelled, but RM can only cancel the future, delayed actions for delays on an action.
In the real world, you're likely to have more complicated rules. (For one thing, note that I have no triggers, so these rules will never run unless run manually or as part of another rule. But mostly: the actions are quite simple and the purpose of the delay is...not much besides demonstration.) The Rule 4.0 docs are great reading for how to do some of these things. Here's a motion lighting example with a delay, stolen from the docs:
(note that in newer versions of RM, "(cancel)" will display as "(cancelable)"; it's the same thing)
This is a very common rule pattern: trigger on some "binary" sensor changed, then do an
IF THEN ... ELSE ... END-IF in the actions to do different things depending on the current state. Here, you also get to see "Cancel Delayed Actions" (as promised!) in action. If you are familiar with webCoRE's Task Cancellation Policy (TCP--on by default), what you're doing here is basically re-creating that effect. Since we're talking about webCoRE, another difference you notice is that you need to specify triggers manually. RM does not infer like webCoRE does (again, if you're familiar: the lightning bolt in the editor indicates a subscription, effectively what triggers do here).
NOTE: Rule Machine has its own meaning for "wait," with two actions: Wait for Event and Wait for Condition. (Please ignore somebody if they come along later and berate you for using the "wrong" word as if this is the only correct interpretation...) You can set "timeouts" on these, but if you just want to wait for a specified amount of time (as opposed to waiting for something to happen or for something to become true or proceed if it already is true), a Delay is what you're after.
- For "stays," you have to approach the problem differently. Here's an example of how you can see if a contact sensor stays open for 5 seconds, for example:
The actions should be apparent now that you know about triggers, delays, cancellations, and conditionals from above.
Note that if you're coming from ST (as I can only assume), you might need RM far less than you needed webCoRE. Hubitat has a lot of built-in apps that can handle common tasks. It's certainly good to learn Rule Machine, but it does require learning. The docs above are a good start (you can also find more or less the same content on the docs wiki, but the forum can be nicer because it has in-line screenshots; but the wiki article does have the list of categories/actions at the end, which may be helpful for finding things if you have bad luck guessing. For example, my last rule above could have been handled with the built-in Notifications app, which takes a lot less effort to set up (as most apps tend to compared to rules).
Hope this helps!