Feature Request: Zone Prioritization

[pnbruckner]

Feature Request: Zone Prioritization

[pnbruckner]

The main purpose of this custom integration is to try to use the most up-to-date data from the list of "input" trackers, but it also recognizes that non-GPS based trackers tend to only be useful (i.e., not very stale) when they switch from not home to home. I'm not sure how this suggestion would really work, especially for non-GPS based input trackers (which, AFAIK, have no way to know what zone they're in, other than home.)

You might want to check out #28. I need to get that PR merged. Let me know if you think that would help at all.

[pnbruckner]

The other problem with this is that, generally, the composite integration does not determine what zone the composite entity is in. It just updates the GPS coordinates, and it's the device tracker component level code that makes that determination. There is a way for the composite integration to override that, but still, not really sure how this could work.

E.g., let's say the composite is just outside one of these "low priority" zones, and then a GPS input entity moves into one of them. What is the composite supposed to do? Ignore the new GPS location and simply not update? So, the composite entity is left outside the zone? Then ignore the updates from the other input entities until they are all inside the zone?

This seems too complicated, and I'm not really sure what the benefit is. Is this intended to make up for the shortcomings of one of your device trackers?

[leoherzog]

Indeed. I'm trying to solve for the problem of "I use a composite tracker of my phone (HA App), keys (Tile), and wallet (Tile). When I leave the house with my phone and keys, but leave the wallet at home, the composite tracker waffles between 'home' an 'away' zones". I think it's small updates in the wallet tracker's lat/long that are triggering the change?

[pnbruckner]

Ok, thanks for the clarification.

I haven't used a Tile. What states (including attributes) do the corresponding device_tracker entities take on? Does their source_type attribute stay the same, or does it dynamically change? If the former, what's its value (router, gps, ...?) If the latter, what are the values, and what makes it change?

Do the Tile device_tracker entities ever have GPS coordinate attributes (latitude, longitude & gps_accuracy), and if so, always, or under what conditions? What is the value or values of their source_type attribute when they have GPS attributes, and when they don't (if they don't)?

Basically, I need to know some more details about how these Tile device_tracker entities behave before I can decide what the right thing to do here is.

Ignoring those details for now, basically what you want is for the composite tracker to ignore an input tracker that you accidentally leave at home (or maybe somewhere else???), right?

If it was a GPS-based tracker, then that's what the require_movement feature was added for. It will ignore updates for the specified input tracker unless its new location circle does not overlap its previous location circle. (The location circle is a circle whose center is defined by the latitude & longitude, and its radius is defined by the gps_accuracy attribute.)

If it was not a GPS-based tracker, then that's why the composite, by default, does not use an input tracker's update if it changes to anything besides home.

If you could share more details about how the Tile device_tracker entities behave, and exactly what your composite configuration is (redacting any sensitive information, of course), that would be helpful. I have a feeling the current implementation may work for you with a slight configuration change. Or, if not, then I might be able to make a change to get what you want.

[pnbruckner]

I just briefly reviewed the tile integration. It looks like source_type is always gps, but I can't tell if it always has valid latitude, longitude & gps_accuracy values (mostly, not null/None.)

What is also intriguing are the last_timestamp & last_lost_timestamp attributes, especially the former. At the very least, I can add code to use last_timestamp, which should help the composite decide whether or not to use a Tile's update. I.e., just like the last_seen attribute of other tracker integrations (e.g., Life360 & Google Maps), the composite can ignore an update from a Tile tracker if its last_timestamp attribute has an older value than what the composite already has.

[pnbruckner]

I'm guessing if a Tile is left behind, it will stop updating its location (and especially the last_timestamp) attribute, since the phone it's paired with is no longer within range??? That should, at least help, resolve your problem.

Now, if the phone is also left behind... lol

[pnbruckner]

@leoherzog, I just released this new feature as beta version 2.8.0b0 if you'd like to give it a try. If you do, please let me know how it works for you, and especially if it helps resolve the situation you described.

[pnbruckner]

Hmm, just discovered that adding last_timestamp to the tile integration was only done very recently, like 2 weeks ago. It's only in the dev branch, so you won't really be able to try this with a versioned release of HA yet. Nevertheless, this still makes sense to add to the composite integration so it can use that new attribute when it becomes available.