Ok... I'll give that a try... LOL sorry, and still getting used to this "change".
1 Like
No problem. A bit of a learning curve.
You will see logs that say, after the first motion goes inactive, "Not Turning Off, motion still active"; and then when the second one goes inactive, the turning off logging.
1 Like
Thanks! This was the last lighting automation I was really struggling with and one of the most important ones in my house! LOL
So just out of curiosity, in what manner would this "Condition" be used in a lighting scenario?
I couldn't answer that. There are hundreds of potential situations one could define in Room Lights. No doubt not all of them will find use. However, use cases in Home Automation are all over the map, and nothing should be ruled out of being possible. There's always a balance to be made between app features and usability, including understandability. Room Lights pushes this to an extent I'm not 100% happy with (complex) -- but on the other hand it is pretty comprehensive.
One thing that happened with Room Lights, that I think is a good thing to a point, is that as soon as we released it people asked for additional features. Some we did, some we said no to. I'm pretty sure there were meaningful use cases behind most of those requests.
Maybe what Iām about to say isnāt the right terminology but hear me out for a second. You mention that conditions are not subscribeable or at least that how Iām understanding and because of that they have no refresh property to check again after running once. But I have a scenario in which running periodically and refreshingbwoukd be valuable.
Take this rule for an exampleā¦
In this scenario, my tv is connected to homebridge. If the tv is on, I have a virtual switch I. HomeKit turn on which is also tied into my hub. If that switch is on, and illuminance from my weather station is above 8000, keep my living room lamp turned off. If itās below, turn on and stay on until the TV is turned off. Essentially keeping the light on as long as the Tv is on, and if itās off then the light is on and off based on a motion sensor in that room. Both are on or off based on illumination.
What Iām seeking in this scenario is i turn the TV on and itās a bright sunny day, and so the lamp doesnāt come on, but while im sitting there, a huge thunderstorm rolls through, and illination drops below 8000. Ideally without having to rerun the rule by turning the tv on or off, Iād like it to recognize the change in the lighting and just turn on the light until illumination goes back above 8000. Or do I need to write the rule different then how I have it?
Make illuminance an additional Means to Activate.
So I set the rule with a single sensor means to activate but bkth sensors as means to deactivate, however only one deactivates and the lights went out. It doesnāt appear to be working as an āandā statement. Hereās my rule showing the light off and one sensor active and the other inactive. Wife started yelling at me this morning thinking I was screwing with her while she was in the shower! Lol
For Means to Turn Off use 'Motion stays inactive', not 'Motion becomes inactive'.
The 'becomes' one should turn off when any one of the motion sensors become inactive. With 'stays' they must all become inactive. 0 minutes can be selected if desired.
That's good to know and not obvious. Maybe add an any/all option? 
I've found the cleanest way to manage multiple sensors is the Zone Motion Controller app.
2 Likes
Yes that's my go-to for managing multiple sensors that I want to be an ALL.
I do wish these differences were more obvious in the UI. It takes a lot of note taking to keep up with this app.
2 Likes
Totally unnecessary.
You're just piling logic on top of logic.
Well, one offers an amount of time and says "Motion stays inactive" and the other does not offer a time input and only says "Motion inactive". Those are pretty obvious differences in the UI. Probably it should be better documented as well, although no one really reads the documentation.
I'll add the words ALL and ANY to these, and the corresponding ones for contact sensors, since we have existence proof that what it says is not obvious enough.
2 Likes
The purpose of Zone Motion Controller is to deal with False Motion Reduction. The other two options were added for completeness. However, Motion Aggregation and Triggered Activation functions of ZMC are entirely redundant to the corresponding functions in every built-in app that deals with motion sensors. Unless you need False Motion Reduction, using Zone Motion Controller makes all of your motion driven automations less efficient, adding extra time to triggers, and adds an extra unnecessary app. There's no magic here.
I should add that Zone Motion Controller came into existence for outdoor applications of motion sensors, where false positives become a distinct possibility. There's a price to be paid for eliminating false positives though. So unless you are certain that Zone Motion Controller solves a specific outdoor motion problem, it probably isn't the right choice for every day motion use in Apps.
All of the apps apply the exact same logic. If looking for the All Inactive condition, each sensor going inactive causes all of the sensors to be examined. Only when the last one goes inactive does the condition of All Inactive become true. Any sensor going active in the interim, prevents the All Inactive condition from being achieved.
1 Like
Now you tell us, as he quickly redoes his motion rules. 
2 Likes
Which was where I started using it... I was getting too many false positives out in our front yard, which it fixed.
I started using it inside as it allowed me to create groups of sensors that I could then use in multiple automations, and then over time I just feel into the habit of using it for everything. 
I've never noticed a penalty from using zones, my lights go on very promptly. But I've never compared and your info makes me interested to test without using zones.
Definitely did not know this, thanks for the details, very helpful.
1 Like
@jameslslate - FWIW I had some time to kill today waiting for my wife to be ready to head out to run some errands (which she has since cancelled and is taking a nap.
I tested motion lighting in my utility room, which uses three Iris sensors, two v2, and one v3. Tested using a zone vs the sensors added separately in RL, several tests.
TL;DR - any difference between zone vs individual sensors was in terms of ms and not noticeable in actual use. It was actually nice to see that Hubitat is robust enough to perform well even when configured incorrectly, at least in the context I was testing. 
Based on advice I did change that RL automation to individual sensors as I don't use the motion sensors in that room in any other automations any more, so there is no efficiency gained by having them in a zone together to add to multiple automations. Not expecting to see any significant difference, but I feel better about it.
2 Likes
Thanks @bravenel ā¦ I have a lot of work to do in rewriting my rules Iāve already setup. Iām sure Iāll have more questions but I have to take a break from HE for a few days to focus on bringing a new aquarium online and ripping out a shower for a new bathroom Reno upcoming. Over the next week Iāll get back to all thisā¦ I still need to take a look at my node red config for injecting my He data into influxdb and the rewriting all my grafana dashboards. Plus I have a 2nd iotawatt on its way. Iām busier then a two peckered rabbit! And my wife wonders why I never come to bed until 4am!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
