Question: Condition based on event trigger

I'm curious if the Rule Machine has some way to do a conditional statement on which event triggered the rule. For example, if I have three switches for a specific rule; is there any way inside the rule actions to know which one was the one that triggered the rule execution?

Thanks in advance!

%device% IDs the trigger device

1 Like

Awesome, thanks!

But you can't use that as a condition within the conditional action of the rule. You can't test for if %device% equals something. What exactly are you trying to do? it might be easier, rather than having one rule for all 3, to have 3 smaller rules. That usually makes your system run faster. 3 small rules run a lot faster than 1 big one.

@Ryan780 I was able to set a variable to the value %device% and then use variable in the conditional. Worked great for my purposes.

Great. I was just doing the same :wink:

The only way to do that is to have a different if clause in the rule for every device that is in the trigger. Wouldn't it be easier to have a separate rule?

Or a Switch statement, based on device or mode or anything else that suits you
Obviously a FR...

In a rule? You could encode that in Groovy but not in a rule.

Motion Lighting already has the construct...

Another case for

What? What are you talking about? We're talking about a contact sensor, not a motion sensor. We can't modify the code of the built-in apps.

Missing my point. When dealing with multiple devices, whether contacts/presence/ modes/etc., a switch (SW contruct), eases the logic of handling multiple events within a rule. Alternative is multiple if/else/condions/actions etc.. It's an easier paradigm to understand.....

And you're totally missing my point.

How are you going to encode a switch into Rule Machine? or Simple Lighting? We don't have access to the code!!!

We ? I'm suggesting RM, which HE devel owns, to add as another conditonal operator.

First of all, that post you keep linking to has absolutely nothing to do with adding an operator to the conditional actions of Rule Machine. What is being requested there is to know the triggering device as a condition. That has nothing to do with adding a switch function to the operators of Rule Machine.

And furthermore....if you actually spent some time reading on the forum here you'd find that folks have a hard enough time encoding If/Then/Else statements. You want them to try and use a switch? And isn't a switch just a fancy way to encode in software an if/then/else-if/else statement? You're more than welcome to suggest that Hubitat spend all that time and effort to re-do something that they already have but I suspect you won't get much movement on that.

And it's not just the operator. It's building all the logic and the functions and the interface as well. As well as all the checking to make sure that everything is entered correctly. If you actually had any idea how much effort it would take to make that change I don't think you would be making it so lightly.

You are correct, the multiple posts(all very specific to a different problem statement) were not about adding a switch statement. However as an eng I see a common use model issue. Switch statements were created to avoid convoluted ifs/elses ad nauseam, which are harder to follow more difficut to understand the logic...

I have to agree here with what @Ryan780 says. While it may feel clunky, IF-ELSEIF-ELSEIF ... is the way a switch() statement is actually implemented underneath the covers. So from an algorithmic functionality perspective, this is already implemented. RM is not a programming language. Adding higher levels of conditional functionality would have the pitfalls that Ryan describes, and would be a relatively large undertaking for no incremental functionality. Given that our development resource is limited, this can't possibly be the right place to invest effort.

Besides, there is already a super easy way to do this: Use a separate rule for each trigger, and dispense with all of the conditional code. You can easily clone rules, and then make the changes to each one. I just went through this myself: I have 5 bathroom fans in my house, each of which I want on a timer tied to occupancy of the room. I could have one rule with a giant IF-THEN superstructure to it, or 5 individual rules each with the relevant devices for that room. I didn't hesitate for an instant before choosing the latter approach. What I ended up with was a very simple rule, easy to create, modify, understand, etc. This is a better approach than combining functionality into a single rule with conditional actions.


You have more bathrooms than I have bedrooms

Maybe you could bring the hub price down and only have a 3 bathroom house

Actually, just more fans than bedrooms...

1 Like