@5iver, thanks for the guidance on the post category.
Area Triggers and Actions doesn’t manage items for you so that they are on when there is activity (whatever activity means for your application) and off otherwise. Area Trigger and Actions instead assumes you already have such activity items and then let’s you group them and act on state changes of the activity items in a highly configurable way (e.g. by time of day, luminance or any other custom factors). In some cases managing an activity item is straight forward. e.g. if you have a motion sensor that can be configured out of the box to be on while triggered and off after expiration then you have an activity item out of the box. Or a contact sensor that sets an item to open/on while open and off otherwise also gives you an activity item out of the box. But for all the more complex scenarios I described the ActionManager can manage the activity item as needed.
Area Triggers and Actions offers timers - not for the activity items, but for the resulting actions. For example if you have a motion sensor that only triggers motion but doesn’t support expiration you can start an action with the trigger and delay the turn off effectively simulating expired motion. However, you don’t have an actual activity item that represents the motion sensor with expiration. Thus you can’t include your logic in groups, can’t use the activity item to trigger other activity items, can’t get override support on the activity item and so on. ActionManager implements all functionality around the concept of activity items allowing for consistent activity functionality across and making all of it then available to Area Triggers and Actions for action handling.
The specific challenge with overriding an activity is that the system needs to track if an ON/OFF event from an override item was user initiated (e.g. user turned light switch off) or was system initiated (light turned off because motion expired). There is no deterministic general way to do this as the response to a system sent command carries no id matching it to the originating command. The ActionManager handles this by tallying what it sends and what it receives and thus detecting additional override events. And since overrides are commonly meant to be temporary (“I am turning this light off. I want it to stay off for the next 30 minutes. Then activity sensing should resume”…) ActionManager optionally makes overrides temporary. In other words overriding automation is more than just specifying a toggle. That’s why Area Triggers and Actions chose to use a designated intensity value that the actions then ignore to simulate overrides.
Hope this helps a bit.