I want to use a change in mode to trigger the actions of my rule. I go to select the trigger event and all of my modes are listed as well as changed.
The prompt says:
Select capability for new Trigger Event
Upon selection of a specified mode it states:
Mode becomes 'specified mode'
So that isn't what I need because I need a NOT of "Mode becomes 'specified mode'".
I have used changed countless other times to create rules but in my currently contemplated scenario it doesn't seem to be efficient to trigger the rule for any mode change (similarly it seems inefficient to select every mode other than my intended specified mode to become the trigger).
Is this where I should use this new Predicate option and if so, how would I do that to effectuate the trigger I need?
If I choose the seemingly inefficient mode changed I would then need to create a conditional action with a newly created condition "NOT mode is 'specified mode'". But that is definitely not what I want as the rule would get triggered by any mode change and the condition of NOT mode is 'specified mode' would be true most of the time.
I'm sure I'm making this too hard for myself. Maybe there is an app other than Rule Machine that would work better these days to accomplish this task? I honestly don't know if I should be banging my head against the wall to figure out how to do this in RM5 or if there is some other app like Mode Manager that would do this easier. I haven't used Mode Manager in a while so I don't even know if it works the same way it used to.
Could someone let me know if this is a task for RM5 or if something else like Mode Manager is a more appropriate tool and perhaps be a saint and show me how to accomplish this seemingly easy task? Thanks in advance for your insight!
I mean, if your actions do what you want, the fact that the rule gets triggered isn't a problem: conditional actions are designed precisely to control what, if any, actions run. And while it's not a bad idea to avoid "overly triggering" a rule, I'm guessing your mode changes happen maybe a few times a day (not, say, a few times a minute), so any overhead from doing it this way is likely to be insignificant.
Side note: at the app level (and Rule Machine is an app, but you'd have the same issue with something custom), for an event where you want "any value except this one," the app would still have to subscribe to every event for the attribute in question because there is no subscription for "any event value except this one" (just everything or a specific value). With modes, I'm not even sure there's a way to subscribe to specific mode change (I've never tried), but again, that wouldn't help here anyway. This is just how event subscriptions at the platform level work.
Back to the issue at hand: you might be able to use a predicate condition, as @neonturbo mentioned and linked to in the other post I wrote, but I can't think of an intuitive way to use that feature in this case. (It's a condition that must be true for your rule to trigger, but the predicate itself becoming true or false doesn't cause anything to actually happen on its own; you need an actual trigger for that, and I just don't see a way to combine all of these to make it happen here. I could be missing something. But again, I don't think mode subscriptions work this way, so there's nothing to gain unless you think it's easier to write or maintain.)
Okay, I think I sort of understand that (and thanks @neonturbo for recognizing the similar issue). Maybe there is another way to skin this cat. Another sanity check would be appreciated.
So I'd like for an alarm to be broadcast (the action) when my basement water sensor becomes wet (the trigger); however if the mode is 'Baby Napping' then I don't want that alarm to be broadcast until NOT Baby Napping.
I am approaching this question from an angle that just seemed like the right way to go but your feedback makes me think I should turn this question on its head. Perhaps one solution could be to use one of the 'Wait for' action types to hold the alarm in abeyance until the mode is NOT Baby Napping at which time the rule would continue running and broadcast the alarm.
This approach doesn't seem crazy to me but I'm not sure which, if either, 'Wait for Events' or 'Wait for Conditions' would cause what I want (e.g., my alarm rule is triggered when the water sensor becomes wet resulting in an alarm action occurring currently in all modes except 'Baby Napping' mode in which case the rule would pause as it waited for the mode to change away from Baby Napping and such change would cause the alarm rule to continue running and broadcast the alarm at that point in time).
Am I crazy or does this path seem more logical / a road more often travelled?
Ah, so I don't really think you want mode to trigger this at all. I would do something like this:
Trigger:Water sensor becomes wet
Actions:
Wait for condition: Mode is NOT Baby Napping
Speak: "%device% wet at %time"
You can make this more complicated if you need to, but that's the basic idea. The difference between "Wait for event" and "Wait for condition" is that the former waits for an actual event, like the mode becoming something (not just being something), so had I used it here, it wouldn't have continued if the mode was already something else--it would wait until an actual mode change took place. "Wait for condition" checks the device state and continues if it's already in that state, otherwise it basically waits for an event that puts it in that state to happen. Since you wanted it to proceed if the condition was already met, that is why I used it here. ("Wait for event" is generally my preference--say, a rule that triggers on motion active, does something, then starts a wait for motion inactive. But that won't work here.)
This doesn't handle what would happen if the sensor becomes wet and then dry while it's waiting for the mode to change. There are ways you could handle that if you need to, though perhaps you want to get notified regardless. The %time% variable I'm using in the notification text above will show you the time of the last trigger event, so it might be a useful addition to your notification.
I would do something like this. Not actual code here, just the idea what I think would work.
Trigger: water sensor wet
Action:
If water sensor wet, and mode is Baby Napping (is that like kidnapping? ), turn on bulb XYZ red and send message to phone smartishhome.
Else If mode is not Baby Napping, activate siren and all that other stuff you want to happen.
My logic here is you probably still want some alert there is water? So wouldn't you want a push notification or flashing a light bulb or something to alert you of problems? Again, this isn't really the code, but just trying to work through some scenarios here.
Or for your original question, I'm wondering if you had 1 rule where you set a boolean variable whenever your specified mode becomes active. That variable is a predicate for the 2nd rule whose trigger is mode changed - it only would be active if your specified mode had changed to something or anything else. The actions would do whatever you want as long as it also flips that boolean. I haven't tried it sorry...
Thank you all. These are great ideas and make sense to me so hopefully I can implement one or a combination of them to meet my intended goals. I've just been too busy trying to make things more complicated for myself to nail this one down.
And while it's not a bad idea to avoid "overly triggering" a rule, I'm guessing your mode changes happen maybe a few times a day (not, say, a few times a minute), so any overhead from doing it this way is likely to be insignificant.
), turn on bulb XYZ red and send message to phone smartishhome.
