Arrival automation fires twice when two of us get home within a minute Automation

Two fixes, and you want both.

First, trigger on the group rather than the people. Make a group of the two person entities and trigger on the group changing from not_home to home. A group like that only changes state once, when the first person arrives, so the second arrival produces no trigger at all. This is the actual fix.

Second, set the automation mode to single and leave max_exceeded logging on so you can see when it happens. Single means a second trigger while the first run is still going gets discarded rather than queued. Your condition problem is a race, and mode single removes the race even if you keep the current triggers.

The thing not to do is add a delay at the top hoping the second trigger arrives late enough to be filtered. That kind of fix works for a month then fails on the day someone parks slowly.

The state trigger detail people miss: trigger on from not_home to home explicitly, not just to home. Without the from clause, any attribute update while already home can re-trigger, which produces the same duplicate behaviour with only one person involved and is much harder to spot.

If you want belt and braces, add a latch: an input_boolean set when the automation runs and cleared 5 minutes later, with a condition that it must be off. It is slightly ugly but it also protects you from GPS jitter, where a phone bounces out of the zone and back at the edge of the geofence and fires an arrival for someone who never left.

Related tip: make the zone bigger than you think. A 100 metre geofence produces far more bouncing than a 250 metre one, and half the duplicate arrival complaints I have seen were really jitter on a tight radius rather than two people arriving.

For the light specifically, making the action idempotent solves half the pain. Turning a light on that is already on costs nothing. It is the announcement and the alarm state change that need protecting, so it is worth separating them.