Just want to make sure I’m doing something right, I have a reactor sensor that turns some lights on and off at a various schedule, based on the sensors trip state (it’s working fine with all my conditions and sub groups… loving it!!!).
So, I wanted to include an extra “group C” that monitors the group-state of a two other groups alreadyt actively used in the sensor (I’ll Call them group A & Group B), because if Groups A & B are true, I want to turn on extra side-light near the rear of the house, (but only under this case.)
I don’t want the evaluation of Group C to affect the overall trip state of the Parent Sensor, So I assigned “NULL” to group C, but still set an activity if “Group C” is true to turn on the side light. (does that make sense?)
I think I’ve used the logic properly, this is essentially what the NULL state is intended for… (i.e. to not affect the state of a Parent), unless I’ve missed something.
So… This morning, group A & B were both true, yet my side light didn’t turn on… I checked the status, and despite the fact Group A & B were each evaluating true, The evaluation of Group C still showed false in the status.
Any idea why Group C would still be showing false, when all the conditions under it are evaluating true? I thought maybe I wasn’t using the NULL state for group C properly? or if I discovered a bug?
The NUL operator makes the group’s result condition irrelevant. It is almost the same as DISABLED, with the exception that the group’s conditions are still evaluated. But even though they are evaluated, the real group state isn’t stored, no activities will be run for the group, and the group is treated by the parent group is if it wasn’t there (it doesn’t affect the parent’s logic outcome, as you pointed out).
But you actually want the group state, and you want to run activities for it. Here’s the simple fix:
Put Group C’s operator back to whatever it needs to be… AND, OR, etc.
Create a subgroup of the root group called “Functions” (that’s what I use by convention, but eventually you’ll figure out what you want to call it).
Make the Functions group operator NUL.
Move (drag) Group C into the Functions group–don’t drag its conditions individually, drag the whole group.
Done. The wrapper “Functions” group will nullify the output of Group C, but Group C will still produce a logic output and still run associated activities (which should be intact–the moving of the group should not affect the activities assigned to it).
This is the start of what I refer to as modular logic. I use a “Functions” group (NUL operator) to contain reusable components of logic–it’s like a library of logic bits you can refer to in other groups (using the Group State condition type). You can even do this across ReactorSensors.
OMG, yes, loving the new toys, building some awesome conditional logic, streamlining a LOT of my other sensors now that I have the ability to make sub groups. Version 3 is really a HUGE step forward in logic control. (I’m trying to not make any as complex as some of my spreadsheet models LOL)
Ahhh! So the group state of a NULL assignment isn’t stored, that’s why I couldn’t get to to work
So just bury all my functions (as sub groups) inside one master group that has a NULL state assigned to it, so none of them affect the parent sensor trip state, but, keep the AND, OR etc states assigned to each of my sub functions so I call all activities from their group state. Makes sense! I will give that a shot.
And thanks for the tip of making a Functions group with a NULL operator across reactor sensors!! Wow, I hadn’t even thought about that yet, but that could save a lot of time, and save from having to reprogram similar logic steps under multiple sensors. Very cool, you’re giving me more ideas!!!
Just wanted to report back and say that change made all the difference. Working perfectly as intended now, thanks Patrick!! So cool that you can now use a reactor sensor to trigger activities based on values of subgroups. And even more so that you can use the NULL operator to prevent a subgroup affecting the parent condition. (long as you bury it one level down anyway! :))
Nicely done, thanks for steering me straight on this one.
Fun, right? I think making the groups hierarchical was an important and necessary step so that you could “write” real boolean “expressions” (e.g. express A and ( B or C )) in condition structure), but adding activities for each group makes it that much more useful. This should do a lot to help contain logic in a smaller number of ReactorSensors and really let you organize your logic in a sensible way. At this point, I basically have one RS per room to contain all the logic that applies to that room, as a guideline. My home theater has two, one for the AV system, and one for everything else, since the complexity of the former warrants it. I also have a “global” RS with logic elements that apply house-wide–the ability of an RS to react to group state in another ReactorSensor makes this modularity possible.
Keep experimenting! And don’t forget to use Backup/Restore a lot on the master device, to capture your success milestones. As is often the case, it may be faster to restore than rebuild if you need to go backwards.
awesome! Love it. Yes since seeing this new improvement I’m also thinking I can get my system down to 1 reactor sensor per room… and I’m excited about the idea of having one master with functions contained that might apply house wide. I had so many repeated logic checks vs now being able to have the heirarchial structure you exemplified of the A and (B or C or D) variety. Seriously helping with streamlining.
I haven’t made use of the backup / restore yet, but I’m glad you pointed that out as sooner or later I’m gonna “tweak one step to many” and forget all the changes I need to make to undo it. ha ha Restore might save a lot more time!! Thankyou
The NUL operator makes the group’s result condition irrelevant. It is almost the same as DISABLED, with the exception that the group’s conditions are still evaluated. But even though they are evaluated, the real group state isn’t stored, no activities will be run for the group, and the group is treated by the parent group is if it wasn’t there (it doesn’t affect the parent’s logic outcome, as you pointed out).
Hi Patrick, I see that a NUL group can still have its own activities but does this mean they will never actually execute?
From what I understand, that’s exactly what it means. I couldn’t figure out why the activity I assigned to a Null Group wouldn’t execute. I buried my desired conditions into a sub group under the NULL group, and now the activities assigned to the sub actually execute, but the NULL group doesnt affect the state of my reactor sensor, which in this case… Was exactly what I wanted
If you select the NUL operator on an existing group, and it has activities, a warning dialog will be presented asking if it’s OK to delete the assigned activities (“Cancel” prevents the operation, “OK” proceeds).
On the Activities tab, prevent editing (adding) activities for a NUL operator group (new or existing).
I was pondering whether it would be desirable/acceptable to just leave any assigned activities in place on an existing group that is changed to NUL, just in case the change was accidental or temporary for some reason, but I came to the conclusion that this would be a rare use case, not at all optimal, and could be handled using other features (e.g. create a disabled group and copy the activities to it for storage).
Do you guys have any feedback here? Other ideas about what it should do?
I’d agree that it would be a very rare use case. I think disabling NUL associated activities (for a new group) is a good approach but I also think hiding/deleting them is sensible too, given that they are never going to be used. It would also avoid unnecessary clutter.
PS - I’m using this NUL group technique everywhere now and love how I can re-use conditions! Really great stuff!!!
I vote for hiding activities for NUL condition groups to help declutter the activities tab. In fact, one can even think of using NUL to simplify/shorten their activity tab. Also, another useful UI tweak would be to add a “collapse-all” inverted chevron to the root condition of conditions group tab. It would be a lot easier to collapse-all to hone in on a condition group that needs to be adjusted when you have a relatively flat set of condition groups.
Excellent idea Patrick! And perhaps well thought out given the recent questions.
I like the idea of disabling the groups on the activities tab (greying them out or something with a tool-tip that says “activities not possible for a NULL group”). Then the user can readily see why they can’t assign an activity to that group (in case they didn’t already know), and it will be evident what they have to do to assign an activity to it, should they so wish. Might save on the same question being asked again?
An I think this idea of warning the user (if they change a group to NULL), that the associated activities will be deleted as a result.
