Performing "Triggering Actions" without actually triggering other rules

[rob9]

I thought I had things figured out--but maybe not.

I have a couple virtual switches that act as "state" variables for collections of settings.

E.g., "In the Office" On-> I'm working in the office for a while, Off->I'm done working there

Using a rule like "When 'In the Office' changes" do xxx, several actions would happen when it is turned "ON" and several other things when it is turned "OFF".

HOWEVER, if I have "In the Office"=ON and then I "arm" HSM, rules related to HSM Status will turn all kinds of things off and on. At this point, I want (need) to set "In the Office"==OFF WITHOUT the "When 'In the Office' changes" rule triggering and doing things that conflict with actions performed due to the HSM status change.

I thought the way to do this was to have the HSM rule "Pause" the "When 'In the Office' changes" rule, set "In the Office"=OFF, then "Resume" that rule.

However, my logs just seemed to show me a situation where my rule triggered anyway--right after the "Resume".

My concern is that either 1) Pause isn't stopping rules or, more likely, 2) There are asynchronous things happening and the rule can get triggered AFTER the "Resume" has taken effect if there's a slight delay in when the rule fires.

There really needs to be some fail-safe way to perform a (normally) "triggering action" without actually triggering anything. Without that type of capability, it's impossible to perform "reset state" type actions that don't generate all kinds of spurious and conflicting actions.

As for the "asynchronous events" scenario, a (terrible) workaround might be to delay the "Resume" a bit--but how long "a bit" needs to be is an unknown time period (depends how slow the RM is acting at any moment) and, if it is too long, it could easily stop the rule from firing for subsequent legitimate triggers.

That's why I'm seeking a "fail-safe" way to keep events from being triggered.

Thoughts? Thanks!

[at9]

Would it not be better to have HSM being armed the first condition of your off rule.
If could then be:

IF HSM armed then
exit rule
else 
do actions

This should allow you to rest the virtual switch.

[rob9]

HSM does things in every HSM status that conflict with the "special" settings.

The special settings are intended to trigger (often manually) after the "base" things are done.

That's why I want to "clean the slate" when HSM resets things.

[johnwick]

You could also use Hubitat modes as a restriction for rules as well rather than use HSM status.

[rob9]

I'm actually only using HSM to flip between alarming modes and to sync with Ring. It just happens that some of these modes dictate a "reset" to a variety of these other "states".

Tracking state is over and above what modes offers. I can be "working in the office" while HSM (or Ring) are in any of their states. I might even have several other, simultaneous and independent states.

Thanks!

[lewis.heidrick]

I agree with Rob9. Use automation rules for automation, some based on modes and some not, and HSM states as monitoring profiles. This way you can arm or disarm whatever in any mode. You can then use virtual switches to trigger the automations and hsm when you intend for it to trigger.