Any variable device based on trigger?

I have a lot of rules that are extremely similar except for the triggered device and the device managed in the rule. for example, kitchen light turns on = delay 10m and turn off light. front door light turns on = delay 10m and turn off front door light.

can i create a single rule that has triggers = X light, Y light, Z light (any) turns on, delay 10m and turn off the particular device that caused the trigger?

I haven't done it myself, but I'm sure there are some actions that refer to the trigger device....

The only thing I'd be worried about is if it's the same rule, won't one of the other trigger devices turning on cancel the delay for the previous device?

An alternative is to export and import the same rule, replacing the device during the import.

Should be able to trigger based on several devices and then take actions based on the event %device%

i do this now. but it's a major pain with many rules. the above was just a simple-form example, the actual rules are more complex. and when I make a change to a rule, it's a big pain to make the same changes to the other rules or delete all the other rules and re-import for each one. a variable trigger device is what i need to alleviate.

You'd probably be ok in theory if there wasn't a wait or a delay involved, cos they get cancelled when the rule is triggered again

1 Like

i dont see any way to use %device%. when i select the 'control switches' action, only a predefined list of switches are shown in a dropdown menu -- and 'control switches' isn't the only thing i'd like to be able to work on with the variable trigger device (but that'd be a fine start)

So even if i figured a way to use a variable trigger device, the old rule will cancel when it's ran again? i didnt know that. i actually have special actions (setting/checking global variables) to know if a rule is still running from a previous trigger.

That's strange, neither do I now! I could have sworn I had a way to use %device% in an action once... Maybe it was the notification one.

I wonder if you write the timer delay and actions into the action for a seperate rule then just run the action from the triggered rule that might complete without cancelling, cos it wouldn't actually be a fresh trigger on the rule that contains the action, just a call to it.

Maybe we could make a feature request for non-cancelling delay types?

1 Like

This is just a built-in string variable representing the display name (device name or device label) of the last triggering device, normally. You can use it in comparisons, but you can't run actions on it since it's not a reference to a device (but you could compare the name and use it that way--messy, maybe, but do-able). The "Custom Action" action does have a "use last event device" option where you can run whatever command on the trigger device, but as mentioned above, I think this would get messy with delays and (especially) cancellations, so I probably wouldn't do it all in the same rule either way, personally.

3 Likes

indeed, i just tested this with a new simple rule. a running rule is stopped if it's triggered again. never knew that. so this particular idea isn't going to work at all. boo.

Assuming we can set the rule not to cancel (not a RM expert but believe there should be a way), then a set of

if %device% = xxxxx

could be used to trigger a specific device action…

You could do something like that with a custom app but that’s a whole different can of worms.

Hmm, as I was typing this I realized that might not be a bad thing for my setup. I have various rooms setup with some triggers that are effectively identical. I might try playing with an app that does something like that. May not be worth the effort though. /shrug

If a rule triggers during a wait then yes, everything below the wait is cancelled. You can use a delay instead and then another trigger will not stop the current rule.

I have definitely had multiple instances of rules run due to multiple triggers. Just today had to fix a rule because it was running multiple instances due to it getting multiple triggers while executing.

Another option is to have the triggered rule run another rule that does not have a trigger. Have that rule pause the calling rule and when the called rule is complete it can resume the initial rule.

1 Like

For the simple example you described in your original post, you could use something like this:

And you could probably load up the triggers with each light if you want the same timeout

EDIT: Just noticed your comment @bertabcd1234. Yes timeouts and alike could get complicated.

1 Like

Download the Hubitat app