Triggerless Rules as Subroutines

I'm considering creating rules with Actions but without a Trigger to serve as subroutines that can be called from other rules using the 'Run/Cancel/Pause Rules' Action.

Is this a crazy idea? Is there a better way to implement a programmatic funcitonesque capability?

4 Likes

I have a couple of rules that are triggerless, where I want them to run only when I run the rule. In theory, your idea should work.

Can you give an example why/where you would want to do this?

I think its a perfect use case, to effectively use these as "sub-routines" that you can call from a number of other rules. I do this often and it works fine. I also have some rules with triggers, but where I still run the actions from other rules - one example is I have a rule that runs when the hub starts up, and it triggers various other rules to run (for initial lighting set-up, checking for time of day to set the correct mode etc) and these are run as "sub-routines" from the main start-up rule. They each exist with triggers and are used in other ways, but from the start-up rule I just want the actions to run without the triggers being referenced and so it works nicely as you say.

3 Likes

I have a bunch of rules that I call functions exactly as you describe without triggers.

Common routines that I want to be able to run from different rules without duplicating the code.

3 Likes

I do this quit a bit myself. In my case I do it because I have monitoring rules using waits and I don't want a trigger to be able to cancel them. So on several devices I have a startup monitor(trigger) rule, which calls a monitor runtime rule. The runtime rules pauses the startup rule and when the device shuts down it resumes the trigger rule, to wait for next startup.

1 Like

Here's one of mine:

Screenshot 2021-12-15 at 09-00-52 ⌐ Front Door lock check (when arming alarm) no trigger

This checks the front door lock. If it's unlocked, it locks it (sending "locking front door" to a speech device; if it's still unlocked a few seconds later, it sends "front door not locked" to the speech device.

I've got one like it for the side lock as well, with the delays staggered so that both rules aren't trying to "talk" at the same time. These get called during various "lock the house up" (leaving or going to bed) routines.

1 Like

I think subroutines is the more classically correct term, unless you were passing parameters to it and returning a result.

Anyway, I have a few rules that are quite lengthy and had on occasion need to recreate one from scratch due to corruption, or moving to a new version of RM, etc. So I broke them up into logical parts that exist as separate rules, and then a master to rule them all.

1 Like

oh for Pete's sake! modularity - it never occurred to me to create callable functions! some of my rules are a bit complex and would be better served if I handled them in chunks instead of if-thens!

4 Likes

These guys have all responded positively and here's me thinking...this is a "Best Practice" that should be in everyone's head as soon as they get to the level of starting to craft more than simple one off rules.

I haven't done anywhere near enough for this to matter, but it HAS crossed my mind that "hey, I wrote the very same sequence in that other rule, do I want to bother figuring out how to use that over and over, nah...KISS".

The answer should have been YES... but I didn't know how...so how to capture and encourage this from Day #1 in a Best Practices section for RM?

2 Likes

Corrected title and original post, thanks.