group.all_devices was useful in appdaemon to set a listen state for when someone arrives home or everyone leaves.
What’s the preferred method now?
Group.all_lights, and group.all_switches was also useful in appdaemon to turn off a mixture of different platforms (eg lights and switches) and mixture of groups and individual entities specified in apps.yaml.
What is the preferred method now?
I’m not sure, but maybe you can use something like self.listen_state("device_tracker") to listen to all device_trackers. @ReneTode what is the preferred way to do this now?
That might work when “someones arrived” because just one device tracker needs to change state from not_home to home.
But in the case of “everyones left”, all device trackers that are home need to all change to not_home. So I dont think this will work 
Came across this post to get any desired group.all_* back.
Seems the best option for those needing group.all_lights, group.all_devices, etc
I ran Check Configuration and I’m seeing:
“Platform error sensor.modem_callerid - No module named ‘serial’”
What does this mean and how to fix?
I’ve just started experimenting with this platform in 103 and would like to continue in 104.
After this update and after re-configuring Ring via the config flow, my Ring binary sensors for doorbell press and motion are not working. What’s strange is that the “last activity” sensors are correct, but the binary sensors don’t change state. Anyone else experiencing this?
EDIT: Looks like I’m not the only one, post #312 Ring integration setup fails
Will try again later today. I reverted back to 103.6 yesterday.
Althou I don’t remeber seeing a delete button anywhere on the dead group.
For this that have not yet upgraded OR have reverted back to previous version.
Robban has explained that the issue is a side effect of a code change he did (side effect that he had missed - hey we are all only humans 
) and he has described a manual hack of the core.device_registry that you can do BEFORE you upgrade.
In short - the issue is that from 0.104 the Deconz integration generates internal references to groups with a new method and if you already have groups defined you end up with duplicate groups. Robban’s workaround is to stop Home Assistant and hack the Deconz existing group reference to the new format (which is removal of 4 F’s in a hex number).
This only works before you upgrade Home Assistant!! See the link and also follow the next 10-15 comments. It is hacking of a JSON file but much less trouble than the clean-up I describe that you need to do AFTER the duplicate groups have been created.
yes you can listen to all device_trackers and then loop through the state from the devicetrackers and generate the group state.
with some simple apps you can even get the wanted groups back.
It’s a config error. What does the error look like in home-assistant.log? That message does not look like it came from the log files.
make use of the presence functions that AD has. (everyone_home(), noone_home(), anyone_home() )
and the presence constraint functions
with get_state you can get a dict with all lights or all switches, which then can be used to turn off.
Yes this was what I was going to do. Saw some methods using HA automation and python_script.
Do you know what the listener function in appdaemon is for when HA boots up?
listen_event and then the special HA event. please check the docs
i would however use an input_boolean.
set it to off on default in HA, and to on when the groups are made.
when HA restarts, the boolean changes state to off, so the callback gets triggered ands sets it to on again.
You don’t really need to do that. You can make the group and have it dynamic using this:
self._entity_id = 'group.all_devices'
self._friendly_name = 'All Devices'
self.handle = self.listen_state(self.updategroup, 'device_tracker')
def updategroup(self, entity, attribute, old, new, kwargs):
entity_ids = [ entity_id for entity_id, value in self.get_state('device_tracker') ]
state = 'on' if any([ self.get_state(entity_id) == 'home' for entity_id in entity_ids]) else 'off'
attributes = {
'friendly_name':self._friendly_name,
'entity_id': entity_ids,
}
self.set_state(self._entity_id, state=state, attributes=attributes)
It should update on startup and whenever a device tracker changes or if a device_tracker is added, it will add it.
Thanks for the reply, the error came from the log on home assistant. I’ve copied and pasted an example of the error from home-assistant.log below:
2020-01-17 07:41:58 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.139915952104016] extra keys not allowed @ data['0']
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 134, in handle_call_service
connection.context(msg),
File "/usr/src/homeassistant/homeassistant/core.py", line 1204, in async_call
processed_data = handler.schema(service_data)
File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 272, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict
return base_validate(path, iteritems(data), out)
File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['0']
Is there a line before this? Can’t really help without seeing what component it’s coming from. Voluptuous is the config validator, so it’s most likely a bad config.
The line before this is a warning:
2020-01-17 07:41:56 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform alexa_media is taking over 10 seconds.
UPDATE: I think I may have pinpointed the issues. duplicate template platform reference in sensors file that isn’t picked up in config check. Just rebooting now testing.
UPDATE 2: nope still reporting an issue.
group.all_* were removed.
Signal messenger works well so far, able to send a notification with an image attached.
note the attachment key threw an error extra keys not allowed @ data['attachment'] when following the documentation signal messenger.
It works for me by putting this in the automation this way instead:
action:
- data:
data:
attachment: "/config/www/images/myimage.png"
message: "There's somebody at the door!"
service: notify.signal
It seems it must be in the /config/ directory for HA to see it? Didn’t work for me using /tmp/
Really appreciate this addition, been wanting this as feature and it’s now here and it works well.