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.
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:
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.
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).
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.
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).
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…
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.
Hi,
allow me contradict the topic title by stating:
I have a GPS based tracker and still, the zone trigger doesn’t work when the GPS based tracker changes state
I am a newbie on the HA world and these are my observations based on my use case:
I have an Android Phone with an integrated GPS receiver (as most of the phones out there).
The source type of the device tracking entity on HA for my phone is GPS.
I did not force it to be GPS. It reports “GPS” since HA created it automatically when I installed the Companion App on my phone.
The Companion App on my phone reports to HA a Sensor called “Background Location”. This sensor as an option called “Location Sent setting” with only two options possible:
“Exact” which reports the device GPS coordinates to HA.
“Zone Name Only” which masks the device GPS coordinates to HA by sending it only the correspondent Zone Name where the device is located.
When I choose “Exact” for the “Location Sent setting” of the “Background Location” sensor my Zone Trigger automation works.
When I choose “Zone Name Only” for the “Location Sent setting” of the “Background Location” sensor my Zone Trigger automation doesn’t work.
Whatever the option I choose for the “Location Sent setting” on the “Background Location” sensor of the Companion App, the device tracking entity on HA for my phone is always GPS. It does not change.
I am a newbie on the HA world… and I spent hours trying to figure out why my zone trigger automation was not working when I was using my phone, with an integrated GPS, as a tracking device.
I read the HA Trigger’s documentation, the Companion App Sensor’s documentation and some google search entries for articles related to Zone Trigger. I could’t figure it out.
Why I spent hours to figure it out? Well, first, my googling skills could not be that great , second, my focus was privacy, it was undeniable to my common sense that my phone is a GPS device, and because I spent hours resisting to change the Background Location sensor from “Zone Name Only” to “Exact”.
My thoughts were:
I have a phone that is also a GPS receiver - bullet 1)
I install the Companion App on my phone and HA sets my phone device tracking type as GPS as I was expecting it to do - bullet 2)
I choose the “Zone Name Only” option, my automation doesn’t work - bullet 4) - but I know the zone name sent to HA by my phone is the result of some matching between my zone coordinates and my phone’s GPS coordinates so, to my understanding the zone name is a mask for latitude and longitude. The HA should know this to because the device tracking type is still GPS - bullet 5) (so I thought…).
Why my zone trigger doesn’t work???
HA is awesome, is smart, it should understand the zone name comes from a GPS device despite being a phone and for that reason the zone names received by it should be considered as reliable as proper GPS coordinates… - - hum… Wait a minute… is HA that smart?..
I paused for a minute. I started to question my assumptions…
Maybe I am assuming wrong when I see the zone name sent by the phone as only a mask for the GPS coordinates…
Maybe HA is not that smart to assume that since the zone name is being sent from a GPS device type, the zone name can be assumed to be as reliable as proper GPS coordinates…
Maybe there is a bug on HA that makes the device type reported as GPS when I choose the option “Zone Name Only” on the Companion App or maybe it is the other way around and the bug is in the Companion App that should report that type change to HA…
I finally decided to change the Background Location sensor from “Zone Name Only” to “Exact” and test.
Voila, it worked.
So…
I have a GPS based tracker and still, the zone trigger doesn’t work when the GPS based tracker changes state
And I can’t figure it out why…
I understand the arguments I read about why HA needs reliable and trustful information to make zone trigger work.
What I don’t understand is why it only assumes GPS coordinates as reliable and trustful information.
The reason is, the zone name that comes from a GPS device is a match result between the zone GPS coordinates and the GPS coordinates from the GPS receiver. The zone name coming from that match result is as reliable and trustful as GPS coordinates for the purpose of making zone trigger automation work.
As so I think…
Understandings apart, I believe the HA and/or the Companion App documentation should be more explicit regarding the zone trigger functionality.
Yes, because gps tracking on your person requires latitude and longitude. When you remove those, it doesn’t work. When you click “zone name only”, you hide your lat/lon.
If you go this route, don’t use a zone trigger. Use a trigger that uses that entity. You’re using the wrong trigger.
Thanks @petro .
I wrote my thoughts right after figuring out how to tackle the problem.
The text is a kind of a scream of frustration.
I started by tracking my person entity but then I changed to tracking my phone device that, like I wrote, is always a GPS entity type no matter location info it returns to HASS.
I can’t understand why the explicit coordinates are needed except by acknowledging the function code to defect enter and leaving zones is as it is and accept there must be a strong reason for being like that.
Although It feels like something is odd…
Anyway, I already accepted it.
Thanks once again.
, second, my focus was privacy, it was undeniable to my common sense that my phone is a GPS device, and because I spent hours resisting to change the Background Location sensor from “Zone Name Only” to “Exact”.