Why not simply create a group containing all of the desired motion sensors? When any one of the motion sensors is on the group’s state will also be on. When all motion sensors are off, the group’s state will be off.
You can also create an automation, triggered at startup and by Reload Groups, that dynamically builds the group. However, this seems like overkill unless you are in the business of adding new motion sensors every day.
I’m trying to avoid restarting home assistant. Can I reload the group by calling the service without rebooting? Also, I have a lot of physical devices (300+). I like everything to be automated as much as possible so I had the hope I could just dynamically add sensors to the group when I add a sensor with a specific name. I have a lot of other grouped sensors beyond just motion. For example I have several groups I use to calculate temperatures for a room (doing the average) and don’t want to have to manually update them when I add a new sensor.
I know, I’m a bit crazy, but when you have this many devices you try to reduce long term maintenance.
Also, I’ve recently decided to move most of my automations from Node-RED to yaml… Node-RED is cool, just the simple stuff is really hard versus what I can do in yaml in seconds.
That’s why I said the automation would have two triggers, one to detect startup and the other to detect Reload Groups.
You can but you still need to execute Reload Groups.
You’re currently using the entity’s name (i.e. its object_id) to store meta-data. This is a fairly common practice, such as calling it ‘binary_sensor.hallway_motion_sensor_bla_bla_etc’. It’s handy as far as being able to easily distinguish one motion sensor from another but not the best when it comes for identifying entity-characteristics with templating.
When it comes to adding meta-data, my preference is to use custom attributes. Here are two examples from my customize.yaml file (you can also use Configuration > Customizations).
sensor.hue_dimmer_switch_battery_2:
integration: hue
type: 'CR2450'
light.family_ceiling:
friendly_name: Family
integration: upb
See the attributes called type and integration? Those are custom attributes I have defined and they will appear along with the entity’s stock attributes. It makes it very easy for me to create a template that selects all sensor entities whose type is CR2450.
OMG, I knew I could edit standard attributes, I tried once to add a custom attribute from the UI and it didn’t seem to work so I assumed you couldn’t do it. I just tried again and it worked. This is going to be very helpful. I appreciate you pointing this out. I’m glad I found this out early in my transition from Node-RED to yaml automations so I can work it into my plan. For example, instead of having to build into my automation a list of every contact sensor to set off the alarm when opened, I can just check for a specific custom attribute on any door or window event.
I was referring to an automation that can create groups dynamically at startup or when the Reload Groups service is called. If you don’t mind manually adding a new entity to an existing group, followed by executing Reload Groups, then there’s no need for that automation.