Rule Machine: IF mode changed from A to B?

Is there a way to trigger a rule when the mode is changed from A to B?

Question..

When it changes specifically from A to B? .. So only when it was A and is now B?

or just when it becomes B?

only when it was A and is now B

:thinking:

For start .. there is always a way...

Looks like the mode trigger is only becomes and changed.. So at this point I think you will have to use a global variable to track the previous mode and compare it to the becomes B rule..

I'm going to let someone more experienced in RM to chime in on the best way to accomplish this..

Ok, yeah, that would work. A bit cumbersome but not too bad. I'll use that if noone else suggests a more efficient way to do it.

Unfortunately this doesn’t exist but something that has been brought up several times. I had asked about it here:

@bravenel mentioned he would consider it:

4 Likes

Thanks for pointing me to that post. I added my vote for the feature.

1 Like

I can't figure out how to set a global variable to the mode. I can set a global variable to a device attribute, but i don't see the option to set a global variable to the mode. Am I missing it?

I guess I could do a bunch of IF THEN statements, but then i have to hardcode in the string values for the mode. That's not only clunky but also fails to account for mode adjustments in the future. Frustrating that RM is so much less sophisticated than WebCore when it comes to this.

I was trying to find a way to access the current mode through the MakerAPI but unfortunately that returns a response in JSON format instead of plain text and RM can't parse a json response. So, the only way you can store the mode into a global variable is with a complex if/else if rule. This would allow you track the current and previous mode. You can then use that variable in a conditional action in a rule. You won't be able to have a trigger of the change from one to the other, you will have to trigger on the mode changing to B and then the conditional action of previous mode being A. If you need more detail, just let me know and I'll post an example of what you'd have to do.

I use this RM to do specific actions based on changes.

I would imagine you could also use a Virtual Switch is you only care about two modes.

E.g. Have your same rule check the switch, then move it to the next mode so you always have a record of what the last mode was, without having a global variable if that isn't working for you.

That's only the mode changing....not the previous mode was X.

Correct,
Hence my suggestion of using a virtual switch if Global variables are not an option.

How would you do that? If you set a virtual switch based on what the mode is, when the mode changes, so will the virtual switch.

That would only work if the rule was the same rule that managed mode, which wouldn't work if you were using mode manager or any other way to manage mode. I believe that the global variable is a much easier solution.

You could also use "Wait for events", you could first catch the triggering (previous) mode and then wait for the next mode based on what mode you had "first". Here's an example:

Here I just turn on a light, but it could run another rule instead, for example.

1 Like

What if you go from Mode A to Mode C then to mode b? This rule would still fire, incorrectly.

But also, you'd get a re-trigger which would cancel the wait so I'm not sure you can wait for a change that's the same as the trigger. If you had trigger of Mode becomes A, that would wipe out half the problem. but you're still left with the other problem. You'd have to have a second rule of Mode becomes Anything else that cancels all timed actions for this rule.

You'd have to have cancel wait rules added for other modes and probably also before starting the wait for events step. It can be built, this is not a complete example, but it is a way of doing it without virtual devices or global variables. Unless for some odd reason "Wait for event" would be canceled by the Trigger Event triggering again. It shouldn't, I've not done this with Modes, but with other things, it works as a way to handle transitions from one state to another.

EDIT: Here's a more "complete" rule, it would still require care and changes depending on exactly what is to be accomplished:

But your wait is automatically canceled if the rule is re-triggered, which it will be when mode switches to B. I don't think you can have a wait and trigger that match like that.

Try it, as I said, I've not used this technique with Modes, but judging from the wait for events release documentation this should work.

EDIT: It works also with Modes, next time, check before saying that it doesn't work:

I think @markus's suggestion is better than mine, but if i only cared about two modes (from A <->B) i would incorporate changing the switch AFTER the "Mode Change" event (in my conditions) from my existing RM above, so that I always have the switch in the state of the previous mode when the change is triggered.