RM 4.0: Best Practice for Binary Condition?

I have several 'monitoring' rules setup where I am looking for a particular sensor state to tell me an unwanted situation exists so I can react. An example of a power source rule is below.

My question revolves around the condition. In this case (and many, if not all, of the others,) I only have two choices: mains or battery (or open/closed, locked/unlocked, etc.) In these cases, is it better to have the error be the condition or the normal state be the condition? (Or does it matter at all?) One part of my brain says that the error should be the condition as that would put it at the top of the actions, as that would make it more likely to run if a bug or logic error stopped the rest of the rule from running somehow. The other side of my brain says it doesn't matter, as if you build the logic flow correctly, a binary choice will be covered either on the 'do' or the 'do other thing.'

Just curious as to what other people's approaches to these types of rules are...

Whatever you decide on, change the trigger from “changed” to what you decide on triggering on. That way you can get rid of the IF statement you have as you know what the state is as soon as the rule runs.

Whether you trigger on the desired state or the undesired state is up to you. If it was me I would trigger on the undesired state. My rule would then look like (with your battery/mains scenario):

Trigger - any device on battery.

Cancel wait
Run desired action for the undesired state
Wait for condition (all devices on mains) - cancellable
Run actions for when devices are back to desired state

The cancellable wait and the cancel wait have been put in there just in case one of the other devices goes to battery after one has already done so. That way it will run your action for the undesired state again (if that matters)

If you want to trigger on your desired state instead, you can still use the above, just shuffle the code around a little bit.

1 Like

Thanks for that. I had totally forgotten about the Hubitat Live episode a month or two ago where they discussed that very strategy. I even have a different rule (a control rule, rather than monitoring) that uses it. I feel like a schmuck.

Been there, felt that. Don't worry about it. We are all learning!


One more question...

When I was updating the various rules to the new philosophy, I had to delete one and start from scratch. The 'new' rule doesn't have any conditions listed in the conditions 'section,' but it works exactly like I would expect it to. It makes sense, but I just want to confirm that this is expected and ok. And does that mean that I can delete the existing conditions from the other rules that I'm changing over to this method? Thanks!

The conditions go in based on the ifthen statements so with a different rule structure you won't necessarily have the same conditions. So it should be fine. I had exactly the same when I changed my motion lighting over to using a wait condition instead.

1 Like