Just looking for general comments on how "safe" it is to use this feature.
I find RM so much easier to create fairly complex IF statements with than my previous hub platform.
I do wonder if depending too much on matching device text runs into the risks of the text I'm matching will change with driver updates, or maybe even platform updates, and breaking rules?
It is safe if you use built-in drivers. With community drivers, you have the option of not updating. You also have the source to community drivers - so if the DescriptionText string changes, you can change it back to match what you need.
Thanks. I'm finding it really handy to use to minimize the number of rules I need. Over 7 or 8 years with my last hub I was up to almost 400 "events."
I don't see needing near that many with the way RM works, but while I love doing this, there will be long periods I want to be far closer to it humming along for months with little care and feeding...than breaking. Or, that some update I make innocently means I need to edit 30 rules before I can leave home to do something...or leave for a vacation.
Curious, what kinds things are you matching on the description %text% vs just matching to the event state?
This time in IF statements in a single rule that match the state of multiple open / close sensors.
Trying to think of a reason why to use the %text% instead of just the device state? Cannot think of a reason. Ultimately the device state would be most future proof from having to be tweaked later.
Post a screenshot of the rule if you don't mind.
Thanks…I will in a bit …but it boiled down to if the other sensor was closed it would trip those IF statements…so just be open or closed doesn’t matter in the rule.
Completely open to other approaches
Post a screenshot of the rule. Usually %text% is useful only for “events” that aren’t in the event log. Like locks being locked from the inside (or by key) vs via a button push.
Wont this achieve the same thing? Just check the device state instead of the %text%.
I guess the only thing it might not catch is which device triggered it... I think that can be fixed.
Please hold... better version coming.
Not if either contact is closed in the same rule.
I think this would do the same thing as yours, just without worrying about the exact description text, and also eliminating duplicated if blocks.
Possibly may need to make the ELSE-IF a separate IF block like how you have it, depending on what you want it to do exactly.
Thanks…I’ll give it a shot in morning. I hope to have a single rule to manage all 7 sensors. 7 rules would be easy.
Why?
Rules are free. Multiple simpler rules are less processor intensive than one complicated rule.
I think if all sensors are doing the same action this would make sense. If they are doing different actions I would make separate rules.
Right…just if the rule was triggered by a change in any of them…since anything other than the first IF statement is always true (closed) it triggered the IF statement matching their closed status and instantly turned off the lights.
That's why I changed it to save the trigger value and then check that. That %value% variable is the value that triggered the rule. Very similar to what you were doing with %text% but much less susceptible to change. The only way it would get into the "close" block is if the device that triggered the rule changed to closed.
Awesome…thanks!
I had 400 rules in Homeseer due to the limitations of their event engine. It was a burden to manage, especially before they finally added the IF ability to the actions. I often had to create another event to be called from the main event to manage that. Sometimes that would mean 6 or 7 rules to accomplish what I needed. Not only was it ugly IMHO, but it often was also hard to understand the flow 5 years later when you had to bounce between rules to follow the logic.
Anyway, personally I think having one rule to manage the actions of all my contact sensors (in this case always light to see in closets and rooms) is clean. They are free though 
.
Download the Hubitat app
