Set reaction triggering wrong z-wave device

[CatmanV2]

This ties into (possibly) nicely to something I was just wondering about, having taking note of some of this thread:

I have a security set up that we arm at night as part of our house shutdown process. When it arms it announces on all Alexas that this is happening. Likewise in the morning when we tell the house to wake up it announces on all Veras that the system is disarmed.
So far so good
However new behaviour from Mrs C's cat is to wake me up every 30 minutes from about 0130 until 0500 to be let out.
This necessitated a new control for the security system (sans everything else that the wake up does) but of course that then screams from every Alexa both the arm and disarm.

Soooo.
I have changed things. Removed the announcement from the arm and disarm and use those to trigger 4 more rules:
Armed in hours > loud Vera everywhere
Armed OOH > very quiet Vera in the kitchen only
Disarmed in hours > loud Vera everywhere
Disarmed OOH > very quiet Vera in the kitchen only.

All is well with the world but I now have 12 rules in Reactor (6 of which are unused being the 'false' sate)

Is there a better way of doing this?

Cheers

C

[Fanan]

@catmanv2 . I have solved this by the color of a Hue lamp. If the house is armed, this light goes red, otherwise it´s bright white light. Then it only needs to be 1 rule; true/false = red/white light.
The only trouble is where to put the light in the house...

[kidhasmoxy]

@catmanv2 this is the exact type of situation that I’m thinking of. Also have an automation that alerts me when the power sensor for my washer goes between different ranges so I know what stage it’s in.

@toggledbits are you thinking of making a native condition action? I don’t know about Vera, but the automation engines in Hubitat and Home Assistant both have this capability and it makes a big difference.

[CatmanV2]

@fanan said in Creating Rules with Conditional Logic:

@catmanv2 . I have solved this by the color of a Hue lamp. If the house is armed, this light goes red, otherwise it´s bright white light. Then it only needs to be 1 rule; true/false = red/white light.
The only trouble is where to put the light in the house...

Thanks Won't quite solve my issue though as armed is not the false of 'disarmed' There's some sensors to check and so on as well

C

[cw-kid]

@kidhasmoxy said in Creating Rules with Conditional Logic:

making a native condition action

Plus one here for this.

Currently I've used LUA code called in the Reaction / action to then do further conditional checks of things.

[toggledbits]

@kidhasmoxy said in Creating Rules with Conditional Logic:

@toggledbits are you thinking of making a native condition action? I don’t know about Vera, but the automation engines in Hubitat and Home Assistant both have this capability and it makes a big difference.

I don't know what this means

[kidhasmoxy]

@toggledbits The 3 graphical rules engines I've use the most are Home Assistant Automations, Hubitat Rule Machine, and webcore (supports SmartThings and Hubitat.)

All have the notion of using conditions to decide which actions execute after the rule is triggered. This allows you to reduce the number of rules you need and avoid dealing with managing rule dependencies.

Supporting this approach makes it easier to migrate from any one (or in this case, all) of those solutions.

Documentation from Hubitat:
https://docs.hubitat.com/index.php?title=Rule-4.0#Rule-4.0_Conditional_Actions_and_Logical_Expressions

Here's an example from Home Assistant:

Example from Webcore

Example from Hubitat:

[cw-kid]

For me the Rule sets Contraints are the main conditions of the rule.

If those conditions are met then the Reaction / actions should be fired.

However within those actions there are some scenarios where further conditional checks need to be made.

Only way to do this currently in MSR is to create two or more rules or have LUA code on the single rules Reaction carry out those further conditions.

[LibraSun]

This post is deleted!

[LibraSun]

I think this topic gets addressed nicely by the new CONSTRAINT GROUPS feature introduced back in rev. 21117.