Just curious, is their any advantage of using the motion group app over setting up one rule machine rule to turn on or off a virtual switch after 45mins ?
That is technically why I would use the motion group app, if I were to.
Just curious, is their any advantage of using the motion group app over setting up one rule machine rule to turn on or off a virtual switch after 45mins ?
That is technically why I would use the motion group app, if I were to.
I think group use group messaging for zigbee devices so they can turn all faster at same time. No popcorn effect
For me the Motion Group App is great when I have 2 or more motion sensors in an 'odd' shaped room.
So instead of them all 'firing' active/inactive messages into my rules there is only one group sensor doing it and it saves the rules being continually triggered and evaluated.
Probably not much of an extra overhead but thats my thinking.
You can also set an inactive timer to any length you want for your group sensor.
You can also add/delete/change motion sensors into the group motion sensor and not have to alter all your rules that have the individual motion sensors defined. Just alter the group app.
By "motion group app," do you mean Zone Motion Controller? If so, what you're doing sounds about like what the "aggregation" type of zone in that app does. There is probably little advantage one way or the other if you're already using Rule Machine for the other automations. If you aren't, ZMC creates a virtual motion sensor you can use in any app that looks for a motion sensor (not a switch), also something you could do with RM. It may execute a tiny bit faster, being a smaller app, and so ultimately get the active
(and inactive
) events to you faster, but I'm not sure anyone's compared, and if you're using RM for the rest anyway, that may not be a big concern (I have seen people measure Motion Lighting versus a simple rule with ML being a bit faster).
Beyond that, ZMC also supports a couple other types of zones. For example, you could have two sensors in one zone and require both to go active before the virtual sensor does to reduce false positives. Again, nothing you can't do in RM, except that in all cases it takes care of the logic for you behind the scenes and is therefore harder to mess up.