WTH Why the heck does the zone trigger only fire when GPS-based trackers change state?

It says it right in the docs that the Zone trigger only fires if a person changes zones based on a platform that reports GPS coordinates. But if, as many do, one adds, say, a router-based tracker to improve accuracy, then a simple leaving-zone trigger will not fire if the router is the first to report the zone change- and that is problematic. The correct answer is to automate off of the state of the person, not the zone that they’re in. But then why do we need the zone trigger except to confuse newbies? Maybe just remove it.

Now, on to this Bayesian sensor business…

Never thought about it but makes sense to me. Good one :+1:

I’m glad my automations do not fire every time my wifi is disconnected for any reason, like reboot, flight mode or general loss of connectivity.

I guess that is the reason why

That’s a reason why. And I was actually about to post agreeing with fmon, but now I’m actually thinking I disagree. Then I read their post again and realised they weren’t necessarily arguing for non-GPS devices to be able to use zone triggers.

The zone triggers are a “X leaves zone”, “X enters zone”. Just because a device is no longer reporting itself as being in a zone doesn’t mean it has left the zone, much like you’re (seanomat’s) argument that there are many reasons why a device can be flagged as not being in a zone whilst still phyiscally being in a zone (wifi disconnects).

Also zones are geographical spaces, defined by a GPS coordinate and a radius. Entering and leaving a zone occurs when the boundary of those spaces is crossed. This is (I assume) when a device’s location changes from being at a coordinate outside the zone to being at a coordinate inside the zone. I don’t see how it is possible for devices that don’t report their location to replicate that process.

For devices that interact with zones but don’t report GPS location, you can still have automations picking up those zone changes via a state trigger, which is fmon’s point at the end there. If we can pickup zone changes via the state of a device, why do we need the zone trigger (use the state trigger instead).

I don’t know much about the programming behind Home Assistant, but one argument for zone triggers could be speed: I assume that in the backend the zone triggers themselves are triggering a state update, so by having the zone trigger an automation itself you can pickup those border crossings quicker than waiting for the backend to trigger the state update…? (I didn’t say it was a great argument for it…)

So after all that typing, all I’ve got is the same question as fmon - what is the zone trigger achieving that we can’t already achieve via state changes? Do we just have zone triggers as they are used in the backend to trigger the state updates and so those triggers were just exposed for users to use if they wish?

Anyone here have any automations utilising the zone trigger that could not be redone using a state trigger?

It’s just easier and less hassle to trigger, if anyone is in a zone or no one is.
You don’t have to list each and every person, device or whatnot in your triggers which is error prone when there are changes.

Well truth be told you don’t have to list out each entity either way. The state of a zone is the count of how many person entities are in that zone. So for “someone entered the zone” can just do this:

  - platform: numeric_state
    entity_id: zone.work
    above: 0.5

And this for “last person left the zone”:

  - platform: numeric_state
    entity_id: zone.work
    below: 0.5

The only reason you’d need to list out people is if you wanted to know if a specific subset of the people had entered/left a zone. If you just want any person, that can be done with a numeric state trigger.

For device trackers you can do this too but you need a template, zones only count person entities in them.


  - platform: template
    value_template: >-
      {{ states.device_tracker | selectattr('state', 'eq', 'Work')
        | list | count > 0 }}


  - platform: template
    value_template: >-
      {{ states.device_tracker | selectattr('state', 'eq', 'Work')
        | list | count == 0 }}

To be clear, I already voted for this. Just letting you know that there are options for this available today without listing every entity out.

I didn’t vote because I like it the way it is: using the zones the way you showed, without wifi connectivity overruling GPS presence.

But I might not fully understand what this WTH is about :thinking:

They have a timeout after which the device tracker shows as away. For my ASUS for instance the default is 180 sec but one can change that for, ex., iPhones that sleep their Wi-Fi connection at night.

My WTH is basically that this is confusing and adds little functionality. I spent months trying to figure out why sometimes my everyone-left-home automation would run and other times it mysteriously didn’t.

That’s not going to happen unless you want it to? Yea I think you’re missing something.

Some integrations (like mobile_app most commonly) make device trackers based on gps coordinates. These are great and then HA detects when they entered/exited a zone and fires zone enter/exit events accordingly.

Some integrations (like netgear, unifi or other integrations for networking software) also make device trackers. These device trackers are obviously not based on gps coordinates because HA is talking to your router/switch. That can only tell HA whether or not a particular device is on its network, it has no idea what its precise GPS coordinates are, it can just say whether or not its a network client right now.

These integrations are great for people who want to do presence detection but either a) don’t want anything tracking their gps coordinates or b) can’t get gps information (like when guests come over who obviously don’t have the HA app). Because you know that if a device is on your home wifi network then its pretty close to your house. You can’t tell much beyond that but knowing whether someone is home or not is the most important presence event and these integrations do that pretty accurately without tracking gps information.

But people using these types of integrations to make device trackers instead of GPS based ones can’t use zone-type triggers. Those only work with gps based device trackers, as the OP points out.

TLDR - This change shouldn’t affect people that use GPS based device trackers, its simply a QOL improvement for those who don’t.

Hidden zones are probably the only use case I have personally.

I have one hidden zone where the only time I will enter it is if I am riding the subway, there’s no other reason for me to be there. It’s not an actual destination so I wouldn’t want my person and device_tracker entities to change their state when I enter it since any time a person entity arrives at a destination that triggers other automations related to Home ETA and I’m still in transit to somewhere.

But I do want to know when someone enters that zone since then I change the mode of transit select entity for that person from vehicle to transit. Which is used to calculate their ETA later when they are coming home.

So I have a hidden zone and use a zone enter trigger. It cannot be replaced with a state trigger.

Course that’s just an argument for not deprecating it, doesn’t make it useful for non-gps device trackers I suppose. It’s pretty unlikely someone is making their home zone hidden (don’t think that’s even possible).

1 Like

I’ll tell you another time that zone triggering doesn’t work is when I’m in the subterranean gym of my large apartment building. Or one of the restaurants on the ground floor. On a 2d map, yes, same zone, but I’m not home. So then I thought can I automate something off the altitude attribute of the gps sensor of the companion app? Good luck with that one. So it came back to the router after all.

I’m trying out a Bayesian presence sensor… all your trackers get a weighted vote. There’s a ton about this in the forums, which would seem to reflect the widespread trouble that folks have with presence detection.

1 Like

Never really understood the need for a Bayesian sensor, always seemed overengineered to me.

I have a bunch of binary sensors right now. These can be anything - motion detectors, chair occupancy, TV/monitor on, camera saw a person, door open event, wifi connect event, etc. For each I set some kind of delay_off (feature is called different things in different integrations but idea is the same) based on how long I feel their event means the area is occupied.

Then each room has binary sensor group. If any of these sensors are on - someone is there. Otherwise - no one is.

Works well enough. Someone stationary in a room is always the challenge, have figured out solutions to that in most rooms based on what we do and hopefully eventually mwave sensors will cover the rest. I don’t get the value in weighting them, they all mean someone is there.

But what is triggering your everyone-left-home automation?

Based on my understanding of Zones, device_trackers without location information don’t activate Zone Triggers as they haven’t “crossed the boundary”. They can activate Zone State triggers based on their state (home↔away) or the state’s number of devices (1↔2). It could also be that they do activate zone triggers when “entering”/“leaving” a zone but can’t be specifically used for those triggers (i.e. a zone trigger without a specified linked entity).

Did I get this across well?..

My understanding is a Baysian sensor could give you the same functionality as your binary sensor group, but with (maybe) a bit of finer control in regards to the individual sensors.

In your use case, you’ve utilised delays to the individual sensors of the group to help work out if a room is occupied. You could achieve something very similar with a Bayesian sensor and little/no delays on the individual sensors, using the probabily values to give you similar adjustment.

Just a different way to achieve the same result, IMO.

Side note: I’ve never used Bayesian sensors, so this could all be wrong…

1 Like

Fair enough, I definitely don’t understand it. Although truth be told I didn’t really try. The documentation starts with a section called theory, I basically stopped reading there.

I guess reading past it now it kind of makes sense. But still with the number of sensors I use around my house for presence I can’t even fathom how long it would take me to tweak those probability fractions to get it to the point where it was guessing accurately. And even more importantly when it was wrong I would have a very difficult time figuring out why. I prefer to be able to simply look at the history of my entities and see what was green/red at the problematic time.

Yeah that was part of my point - both methods are perfectly valid, and tweaking the delay_off and using a binary group sensor was the best option for you.

Totally get this- when the logic gets out of hand then the machine has a mind of its own. With that said I have a Bayesian sensor up and running and one can compare its calculated probability with a history graph of all included sensors. interestingly it all comes back to what the router says which is the result of the probabilities I fed it. You can see the bump when I drove by looking for parking but it wasn’t enough to exceed the customizable threshold; for my use case I may as well use the router exclusively. Adding other family members probably wouldn’t change things. Mike I’m not using motion sensors for intruder detection except to compare to the expectation as to whether anyone who is authorized is actually home.
So. More evidence that the zone trigger isn’t great.