This is for the case where you have more that one if-then-else functions and you want to cancel on one particular if condition truth set but not another
I understand the case, but it's not supported.
I would love this feature as well. I could also really use a case/switch sort of mechanism to build things like a mode manager without requiring multiple rules:
- Trigger on presence changed
if [ $presence_sensor == "present"
then
case in $global.mode
"away morning") set mode to home morning;;
"away day") set mode to home day;;
"away afternoon") set mode to home afternoon;
"away evening") set mode to home evening;
"away night") set mode to home night;
"away sleep") set mode to home sleep;
esac
else
case in $global.mode
"home morning") set mode to away morning;;
"home day") set mode to away day;;
"home afternoon") set mode to away afternoon;;
"home evening") set mode to away evening;;
"home night") set mode to away night;;
"home sleep") set mode to away sleep;;
etc...
esac
end-if
or perhaps if there was a "set mode per mode" action, like there's an "activate scene based on mode."
Having the ability to validate/view the trigger values from inside the rule would be great... like a device variable, and then the action variable, so I could run logic against it. I realize that could be seen as going against the grain on how RM was originally intended, but I really like combining similar actions/logic into the fewest number of rules possible.
rammbbbllling
Rebuilt in 4.0 -- hell of a lot cleaner than in previous versions.
I might have to adjust the triggers if technically-speaking there is a logical error on my part on trigger-at-x-time, and that also falling between x-and-y time. Not sure if 'between' also includes the endpoints.
That being said, I keep running into a bug where one of my previously-defined conditions keeps auto-filling when I am adding a nested conditional action. I just have to cancel that action and start over and bam, I can build my new one.
This feature is in the next release. There is a new "capability" for conditions called Last Event Device. This allows any attribute of the triggering device to be tested in conditional actions.
3 Likes
whoohoo! Now if I could get lock code set/delete in RM, I'd be happy for at least 10 minutes 
That's the only thing I still use from WC.
Is there a reason that when choosing temperature changed for a trigger, that it is not auto populated when choosing your conditions? Not a big deal because I can create a new condition, but not sure if this is a bug.
It doesn't auto-populate triggers that have range value comparisons available because it wouldn't have a clue what to put in the condition.
Ah, makes sense. Thanks.
Hey @bravenel I have not been able to put the current mode into a global variable, I just can´t find the option, could you guide me ? the available operations do not include something like "current mode"
hey @bravenel I have tried the way you suggested but is not working. I want that if my water sensor is wet and my door (Pta-Pruebas) is open then a TTS to say a message but to stop it speaking the message once the water sensor is dry or the door is closed. I have tried below ways but the repeat will just not stop. Can you guide me?
way1:
Way2:
You need to remove the 2nd IF and put else. This only runs to that IF, if the 1st IF is true. Think of it like gates with keys (conditions) so you must get though the 1st gate with the correct key (condition) to get to the other. But a else is a alternative gate (in this case without a key) but the 2nd gate has a key (IF pta-pruebas closed) then stop repeating actions.
2 Likes
omgosh im not looking forward to getting further into 4.0 with all the gates and keys, ifs and buts.. lol
Why do you need to save the mode in a variable? You can already use the mode as a condition just the way it is.
I'm not sure why Aldo was trying to save it, but I can see where it might be advantageous - for example, to save the current mode, change it to something else (to trigger other rules), and then restore it to its previous value.
I wouldn't use mode like that. If you needed to do something like that, just use the variable in the first place. Why screw around with mode?
It depends on what you're using modes for, I suppose. For one thing, modes are very easy to use as Rule Restrictions.
To me, the flexibility to use modes in any way one likes is one of the big pluses of Hubitat.
I didn't say you couldn't do it, I just said that I couldn't think of a good reason to. Everything everyone has mentioned is much easier done with the variable itself rather than a mode. I think of modes like big overarching control policies. They get changed like 3 times a day. Not 3 times an hour. But like I said, do whatever you want. I was just asking what you would use it for.
awesome, it worked, thanks a lot!!
