in AD3 (haven’t checked to see if the attributes are correct anymore for ad4)
self.listen_state(self.check_devices, 'device_tracker')
def check_devices(self, entity, attribute, old, new, kwargs):
if all([ self.get_state(entity_id) == 'not_home' for entity_id, value in self.get_state('device_tracker') ]):
# do your stuff here.
The first code you’ve pasted, like I said originally, will trigger the first time any device’tracker changes state. Not all.
You 2nd code is not a listener. Unless I’m mistaken, in appdaemon get_state only checks the state of a device once when exucuted. It doesn’t monitor changes to state. That’s what listen_state is for.
Yes… but…
the if statement checks all the devices…
This is identical to the functionality of group.all_devices
What petro wrote should work. You listen to the state changes of all entities, the callback gets executed when an entity state changes. In the callback you then check with get_state, whether all device trackers are “not_home” if this is true it continues otherwise not
Exactly. It will work because I use it.
Do you have a repo with your appdaemon apps somewhere? Would love to take a look at them.
Yes your right. This should work.
I think I prefer the method of creating groups I need in an automation startup script someone posted earlier.
But good to know this alternative.
I’m slowly adding them to HACS but I have to generalize them. I use ‘non-appdaemon’ ways so i’m rewriting them all to be appdaemon friendly. They are in my config currently but soon will be separate repos in my github. My Configuration, you should be able to navigate to my other repos.
The only difference with the group.all_* method is that home asssistant is handling the ‘looping’ accross the items and it occurs prior to your callback being called.
So in regards to performance, it should be the same. But the benefit that group.all_* is that you have a UI item.
Thanks for the link. Will definitely take a look at the “master of templates” repo 
The other benefit for me is this use case.
I have a xiaomi button next to me in my bedroom. To turn of almost everything in the house. I have an app like this
bedroom_button:
module: xiaomi
class: Button
dependencies: utils
buttons:
- binary_sensor.xiaomi_switch_1
actions:
- click_type: long_click_press
type: standard
target_dev:
- group.all_lights
- remote.living_room
- fan.diffuser
- switch.template_samsung_tv
service: turn_off
see how target_dev has mixture of lights, switch, remote, etc. 1 is a group the rest are specific entities.
I can use very simple code to loop through all devices and 1 line of code in the loop
for dev in target_dev:
self.turn_off(dev)
Without any conditions to check if group, if light, etc. And because of this I can use the generic turn_off method.
I’m trying to have something similar but with the binary_sensor entities that have device_class: motion or opening and are currently triggered.
The code should be somewhat like this, right?:
value_template: >
{% set domain = 'binary_sensor' %}
{% set device_class = 'motion' %}
{% set state = 'on' %}
{{ states[domain] | count == states[domain] | selectattr('state','eq', 'on') | selectattr('device_class','eq', 'motion' ) | list | count }}
I cannot try it right now but in theory that would give me the number of the currently triggered motion detectors right?
My question is how to make this into a template_sensor.
HA cannot identify the entity_id it should check for and gives me a warning about this sensor needing to be manually updated.
If i set entity_id: sensor.time it updates every minute which defeats the whole purpose, and if i set entity_id: all that i saw in the latest documentation i get a dictionary error.
What would be the correct way to get the following sensor that would update instantly:
number_of_sensors_on:
entity_id: ????
value_template: >
{% set domain = 'binary_sensor' %}
{% set device_class = 'motion' %}
{% set state = 'on' %}
{{ states[domain] | count == states[domain] | selectattr('state','eq', state) | selectattr('device_class','eq', 'motion' ) | list | count | int }}
or in a simpler format:
number_of_sensors_on:
entity_id: ????
value_template: "{{ states.binary_sensor | selectattr('state', 'eq', 'on') | selectattr('attributes.device_class', 'eq', 'motion') | list | count | int }}"
I don’t believe there is a way to get device_class from a state object.
I’ve tried the last part of the code i wrote above, after @Burningstone’s suggestion and it does work OK, my issue is making it update instantly.
This code:
#template_sensor:...
number_of_sensors_on:
entity_id: ????
value_template: "{{ states.binary_sensor | selectattr('state', 'eq', 'on') | selectattr('attributes.device_class', 'eq', 'motion') | list | count | int }}"
You won’t be able to get it to update instantly inside a template sensor. You can get it to update every minute by adding entity_id: sensor.time if you have sensor.time implemented.
Yup, tried that too, check a couple of posts above.
So the fastest we can get is every minute by sensor.time, no option to get it to update more frequently right?
You’ll need to add a list of all binary_sensors that you wish to monitor (i.e. motion sensors) to the Template Sensor’s entity_id. The moment any of them changes state will cause the Template Sensor’s value_template to be evaluated.
That’s exactly what i was trying to avoid, or avoid having to create a group of all binary sensors.
I used auto-entities to display them on my ui, but was trying to use them as a single entity indicated somehow.
That’s how i ended up here 
Anyway, good thing is that they can still work as condition to automations right?
I mean the automation will have to check if the condition is met when firing… which is the most important i guess.
Yes, check in the first post, it shows how to use it in conditions.
The only thing I’m missing is the option to display them in a single entity, which is not that important.
Thanx for all the input guys.