Area Triggers --> Area Actions

Tags: #<Tag:0x00007fc20e864750> #<Tag:0x00007fc20e864610> #<Tag:0x00007fc20e864520>

The main thing I am aiming to communicate in this tutorial is the concept of using the logic built into groups to lessen the complexity of rules. By setting up your Items and groups in the following way, you will be able to use one rule for much of the automation in your home. A second rule is needed if you’d like to have the lights adjust to Mode (Time of Day) and outside lux levels. The concept is that each area within a home has triggers and the combined state of those triggers can represent whether there is activity/presence within that area. By putting the triggers into a group, actions can take place when the state of that group changes.

Sensor state change → Area trigger group state change → Rule triggered → Action(s) determined from metadata → Action(s) called

Putting the logic into groups takes some getting used to, but by working with groups you will not need to build the area/room specific logic into your rules. I have been able to build out group logic to fit all of the areas inside and outside of our home for use with lighting (including colors and brightness level based on outside lux), music/sound, and notifications (e.g., when the doors are unlocked for too long). I originally wrote this about two years ago using the rules DSL and stored the mode based light levels in a Hashmap. Moving to the new rule engine and scripted automation, I was able to incorporate Item metadata.

Setup groups and Items
  1. Create regular groups named gArea_Trigger and gArea_Action. These groups will hold the respective trigger and action groups. The gArea_Trigger group will be used in the rule trigger.

     Group gArea_Trigger "Area Triggers"
     Group gArea_Action “Area Actions”
  2. Section out your home into areas where a lighting or sound automation would take place.

  3. Create an area trigger group for one of the areas using a name ending in “_Trigger”. This group will hold all of the Items that can be used to identify if the area is active or not. All of the Items in a trigger group must be of the same type (Switch or Contact). Reread that last sentence… it’s important! Most of my devices use Z-Wave and have both switch and contact Channels to choose from. Area trigger groups need to have a type of Switch or Contact, an aggregation function, and they need to be members of the gArea_Trigger group. When a trigger group is ON or OPEN, the area is active.

     Group:Switch:OR(ON,OFF) gDS_FamilyRoom_Trigger "Family Room [%s]" (gArea_Trigger)
  4. Add the triggering Items to the area trigger group that you have created. If you do not have devices to use for the trigger, you can create dummy Items that can be used to manually trigger the rule.

  5. Create another group with the same name as the area trigger group but this time ending in “_Action”. The naming is important, since the rule will be using the area action group associated with the area trigger group based on the name. This group will hold all of the Items in the area that you want to take action on when activity in the area starts and stops. Add this group to the gArea_Action group.

     Group gDS_FamilyRoom_Action "Family Room" (gArea_Action)
  6. Add the action Items into the area action group that you have created.

  7. Repeat steps 3-6 for each area in your home.

At times, you’ll need to invert the state of an Item or group of Items. To do this, create another group inside of the trigger group using Group:Switch:NAND(ON,OFF) and place the Item(s) you need to reverse the state for inside this group. For example, when door locks are unlocked, their state is OFF. By adding a lock to a NAND area trigger group, the group will be ON when the door is unlocked (OFF). If you add more than one lock to the group, the group will stay ON until all locks are ON (locked). There are several interesting solutions that can be created using group logic. Experiment with the possibilities and look through the Example Lighting Scenarios in Github. As I find time, I will document more complex scenarios. If you have questions or difficulty, just ask!

Here are some truth tables that are helpful for understanding the states of groups using logic based aggregation functions:

Example Group and Item structure:

Group    gArea_Trigger
Group:Switch:OR(ON,OFF)    gDS_FamilyRoom_Trigger    (gArea_Trigger)
Group:Switch:OR(ON,OFF)    gUS_LivingRoom_Trigger    (gArea_Trigger)
Group:Switch:OR(ON,OFF)    gUS_EntranceGarage_Trigger (gArea_Trigger)
    Group:Switch:NAND(ON,OFF)    gUS_EntranceGarage_Bathroom_Trigger    (gUS_EntranceGarage_Trigger)
    Group:Switch:NAND(ON,OFF)    gUS_EntranceGarage_Lock_Trigger (gUS_EntranceGarage_Trigger)

    |_ gFamilyRoom_Trigger
        |_ DS_FamilyRoom_Motion
        |_ DS_FamilyRoom_Slider_Contact
    |_ gLivingRoom_Trigger
        |_ US_LivingRooom_Motion
        |_ US_LivingRoom_Slider_Contact
    |_ gEntranceGarage_Trigger
        |_ US_EntranceGarage_Motion
        |_ US_Laundry_Contact
        |_ gUS_EntranceGarage_Bathroom_Trigger
            |_ US_GuestBathroom_Contact
        |_ gUS_EntranceGarage_Lock_Trigger
            |_ Lock_GarageAttached_Inner
    |_ gFamilyRoom_Action
        |_ gDS_FamilyRoom_Bulbs
    |_ gLivingRoom_Action
        |_ US_LivingRoom_Dimmer
    |_ gEntranceGarage_Action
        |_ US_EntranceGarage_Dimmer
Setup your rule

The link below is a full example that will work for everyone out of the box for lighting. By adding metadata, the lights will adjust based on the mode (time of day) and/or outside lux level. I’ve also included examples for speaker and notification area actions, though these are specific to my implementation. Custom area actions are easily integrated. If you build one that you feel will be useful for others, please post it here or submit it as a PR!

There is a lot of more information in github… Area Triggers and Actions.


To see the state of the areas, a simple sitemap entry…

Group item=gArea_Trigger

… will give you a view into which are active or inactive. You can drill down into the groups to see which Items are triggering the activity. Depending on your mode and lux settings, an active area does not mean that the lights are turned ON.

This is much better illustrated with an SVG floorplan. Active areas are green and inactive are grey. Note, the sun was bright when I took this screenshot, so most lights are OFF in the active areas of the house.

Related Concepts:

I appreciate any feedback!


What do I do if I have already an established system with Contacts for doors and windows and Switches for motion and switches?
How can I agregate the two types?

It would be technically possible, but messy. I haven’t had that problem, but I’ll think on it. OTTOMH,

  1. setup the area trigger group with just the switches
  2. setup another group for the contacts (aggregation function but not an area trigger group)
  3. setup a rule and proxy SwitchItem for the contact group
  4. put the proxy Item in the switch group

If you are using zwave and the Channels are there, you can setup new Items and just run with two sets of Items per device.

I’ll give this some more thought. Maybe there’s something that could be done with profiles. A group function that could handle both types would be handy…

Have you looked into how you could use this with the symantic tagging define for HABot? I’ve not studied this very closely but it seems like one could leverage some of those standards here and get the benefit of both. Anyway, I’m mentally fried right now so I’ll come back later when I’ve had a rest and look more closely.

The only concrete suggestion I have is to add a link to Associated Items DP to provide further explanation for the naming patterns.

I had spent a while thinking through how symantic tagging could be incorporated, but everything I came up with was messy, and I didn’t see anything cleaner than doing everything through group membership and group logic. The Alexa V3 metadata is now using more group information. I tested this a while, but I needed/wanted more customization, so that e.g. different sets of speakers could have different actions.

Instead of associated Items, you could use metadata to link the triggers and actions, but that only adds complexity. For now, groups are easier to visualize and setup than metadata. I don’t know of any simpler way to do this and yet have as much customization as what I illustrate in the example in GH. Most automation will be doing something in response to something else. When someone is in this area of the house, I want something to happen, and when nobody is there, the action should stop (maybe on a timer). Area triggers and actions fits this model and is hopefully something a beginner could pick up. After adding some metadata, they’ll have the lights adjusting based on time of day and/or the outside light level.

It’s there in the references at the end of the post… but if you missed it, I should probably add in some more links. :slightly_smiling_face:

HABot also uses Group membership for some things like room definitions which is what made me think of it. So I was thinking about using the room definition standard from HABot instead of a custom standard. I wasn’t really thinking any further than that. How the Groups are used and metadata and all that would be the same as you presented.

I’d hate to have to manage two different FamilyRoom Groups in order to use both.


this looks very interesting to me as I got several areas in the house with a group of lights which I’d like to control as areas. However I am somewhat struggling with the logic.

one example is the bathrooms, it has 3 individual light switches:

Switch    GF_MasterBath_Main_Light     "Main Light"            <light>         (gGF_MasterBath_Trigger,gGF_MasterBath_Action,GF_MasterBath)   ["Lighting", "Switchable"] 
Switch    GF_MasterBath_Toilet_Light   "Toilet Light"          <light>         (gGF_MasterBath_Action,GF_MasterBath)   ["Lighting", "Switchable"]   
Switch    GF_MasterBath_Shower_Light   "Shower Light"          <light>         (gGF_MasterBath_Action,GF_MasterBath)   ["Lighting", "Switchable"] 
Switch    GF_MasterBath_Closet_Light   "Closet Light"          <light>         (gGF_MasterBath_Action,GF_MasterBath)   ["Lighting", "Switchable"] 

Group:Switch:OR(ON, OFF)         gGF_MasterBath_Trigger         "Master Bath Lights"           (gArea_Trigger) 
Group                            gGF_MasterBath_Action          "Master Bath Lights"           (gArea_Action)

ideally I’d like to push one switch to have all lights turned on. however when I pus the main light on it inverts the state on the other lights. ig I use NAND or NOR instead of AND or OR it get into an infinite on/off loop.
I’ve build the logic as stand alone rule before, however I’d like to get more in general design pattern to make behavior easier reproducable throughout the house…

Any hint on what I am doing wrong?

PS I think I figured it out how to switch all with one, however now I am trying to figure out how to trigger when any of the groups switches is switched ON/OFF



Did you get it working? What you are trying to do with one light as the trigger sounds fine, just be sure to use an AND or OR group aggregation function or the state will be reversed. When you mentioned the other lights inverting their state, I was surprised, because I do not see how that would be possible in the scenario you were describing.

I’m thinking the best way to do this is to just repeat the single switch solution for each of the switches, using different triggering groups for each switch but the same action group.

If you are not going to use modes or lux levels, you may want to consider not using automation for this and just using profiles.