Life360 Device Tracker Platform

… and still waiting.

Honestly, not sure how to get this done. I think I’m proposing a reasonable compromise, but it seems to be dead in the water. No response in over 9 days. If anyone has any suggestions, I’m all ears. Or feel free to chime in.

[Add support for Life360 device tracker PR #23405 ](https://github.com/home-assistant/home-assistant/pull/23405

FWIW, I think this part of the discussion is the crux of the matter:


balloob 9 days ago

Home zone is created based off the core configuration. We can’t have integrations start overriding it, because it won’t be clear who “owns” the data and there is no longer a single source of truth.

pnbruckner 9 days ago

Sorry, but I don’t understand this.

First, as I already mentioned, the need came from practical experience. If HA and Life360 have different definitions of home then they can, and will, disagree. This has been noticed by the users of my existing custom component and has caused confusion.

Second, to avoid that bad situation the two systems need to come into agreement as to where home is. Either this needs to be done manually, which is error prone and not as easy as it might seem (HA defines via GPS coordinates, whereas Life360 does it via address or a map), or this can be done automatically for the user. At least making HA agree with Life360 can be done automatically. (See this on the proposed doc page for more details.)

Third, who’s to say whether HA’s or Life360’s definition of home is correct? I think this should be up to the user. Updating HA’s home zone from Life360 info is a configurable feature – the user can decide whether that’s what they want or not.

And lastly, even in HA there is no “single source of truth”, because it can come from either configuration.yaml or from an IP address lookup. And even if it comes from the config, there’s two choices: under homeassistant or zone. So that’s three different places it can come from in HA.

The bottom line to me is, it should be up to the user, and having a way to automatically keep the two systems in sync is better than forcing a user to manually copy data from one system to the other.

Oh, and BTW, if debug is enabled it tells you that it’s doing this:

2019-05-13 12:58:59 DEBUG (SyncWorker_29) [homeassistant.components.life360.device_tracker] Updating zone.home from Place: Home: LATITUDE, LONGITUDE, RADIUS

pnbruckner 2 days ago

balloob so how can we make some progress on this? Maybe I should back out the changes to the zone and owntracks components and just put the life360 code back the way it was, which as I’ve said, has been not only working well in my custom component that many, many people use, but it also solves the real problems I’ve outlined. Then you can take your time to work out what you want to do with zones, and then this, as well as owntracks, etc., can be updated accordingly. But in the meantime I can retire my custom component and people can start using a standard component.

I think I’m going to take the time to reconsider how configuration is done. I think if this comes into more widespread use the current configuration options are insufficient to handle all the complex Circle/Member/Place scenarios out there. I also need to look into maybe making this configured strictly via the UI, since that will probably be necessary. Anyway, making this a standard component is back to being a Work-In-Progress. In the meantime the custom component is still available.

If anyone has any thoughts about config options overall, by all means, let me know.

1 Like

The way that I use your component is to treat is as an independent sensor. I define places in the Life360 app and use those names in my automations. I don’t try to sync Home Assistant and Life360.

I did define some zones in Home Assistant but they are only used as labels on the Home Assistant map.

I’m not sure if this helps and I’m not suggesting anything. It’s just the way that I use it.

1 Like

Same here. If I need specific zones defined, I define them in HA. Not interested in syncing between Life360 and HA.

Hi, hope this custom component will be available with HACS, from the custom_updater developer

1 Like

Sorry, but that probably won’t be happening. First, I’m focusing on trying to make this a standard component. Second, HACS requires each custom component to be in its own github repository, which none of mine are. At this point it’s not worth the effort to completely reorganize my github repo, and custom_updater, AFAIK, still works.

FYI, although custom_updater should still work it appears it can’t work alongside HACS. https://custom-components.github.io/hacs/install#moving-from-custom_updater

For my CC I’m trying to decide if it’s best to migrate repos to the “custom-components” GitHub organization or just require users to manually add the URL to my existing repo…

Oh, hmm.

Still, not planning on doing anything new in that regard for this custom component. Since I’m focusing on making it a standard component I don’t plan on releasing any updates to the custom component. And it can be manually installed if necessary in the meantime.

1 Like

seems like balloob wants to now scrap the PR and keep as custom integration.

I’d really like to see this become an official integration.

It’s the best device tracker out there by far, and I recommend it every single chance I get, but the act of finding/installing/maintaining it has been a little cumbersome. There’s been the “great migration” folder structure change, the method everyone has been using to keep this up to date (custom_updater) is now deprecated and won’t be maintained, and the replacement HACS doesn’t work side-by-side with custom_updater either, etc… It’s sort of a mess right now and an official integration would make this stuff a lot more easier and less prone to breakage.

I personally don’t use the Places feature in Life360 and I think most would understand if that had to be dropped in order for this to become an official integration. The benefits of being an official integration (more exposure, easy setup, no breaking changes) greatly outweigh the cons imo.

1 Like

I’m sorry in advance that this is off-topic but what is HACS?
I have been away a lot recently so must have missed something…

Just a link or pointer is all I need as an answer - I don’t want to deviate this thread.

Closed the PR. The current feature set is not being accepted. I’ll try to come up with something simpler and propose another PR at some point.

A thought came to mind to deal with this if you’re ever so inclined. You could create a new repository and then fork your Life360 component in it. The idea is that you would just pull updates into the new repository but continue to work in the old repository.

Perhaps this would allow you to support both updaters.

Then again, I haven’t used github much so this might not be as easy as it seems.

As I’ve implied before I’m satisfied with the component as it is. :wink:

What were the issues?

The main issue is changing the Home zone (i.e., zone.home), even though it was an optional feature that the user can decide to use or not. For some reason zone.home is being considered special, even though considering it as such, in my mind, makes no sense, and also prevents solving the main issue people have had using this integration – i.e., Life360 and HA disagreeing when someone is “home.” And as far as I know, the current implementation works just fine; at least it has for me and nobody has complained about problems with it. I thought I made a clear and valid argument to let life360 update the Home zone automatically, but that argument was rejected. At least that’s how I read it. Feel free to read the comments in the PR for more detail.

There is also the issue of complexity when it comes to names of Circles and Members, and how to control which are included and which aren’t. Although every Circle and every Member has a unique ID, that information is not visible to the user. Also, although Members have both first and last names, only the first names are generally displayed. And, if that’s not bad enough, Circle and Member names do not need to be unique, and Members can be in multiple Circles. The configuration options I had in the custom component are probably not up to the task. What’s really needed is a way to present the existing Circles and Members to the user, with Circle membership being clear, during configuration (or re-configuration) so the user can select which to use. I was attempting to use the new config flow stuff, but that doesn’t seem to be up to the task either. Supposedly “options flow” can be used for this, but there’s next to no documentation on how that works.

So basically I need to go back to the drawing board and come up with something simpler.

This may be possible using git commands, but as far as I know it’s not directly supported in github. Even if it could be made to work, I suspect it’s not easy. Nor am I looking for more maintenance tasks. So thanks for the thought, but I don’t think I’ll be going there.

I tend to agree, although I personally like the ability to automatically create HA zones to match Life360 Places. I’ve been using it myself. But I think you’re right that I’ll have to drop the idea of using Life360 Places (even for states – in fact I’ll probably drop the whole show_as_state concept.) or changing HA zones in any way. (FWIW, I’ll probably make myself a tool to create a HA zone YAML file derived from Life360 Places, but I don’t know if I’ll share that. With all the various ways HA can be installed, trying to support something like that is too difficult.)

That does sound like a neat feature, although I suspect that the vast majority of people only define a handful of places such as home, work, school, gym, so it would be fairly trivial for users to recreate those as Home Assistant zones in most cases.

I don’t know if this is possible and/or worth exploring, but maybe you could just dump the users Life360 Places (name + latitude + longitude) in JSON format into the Life360.conf file, kinda like this.

[
  {
    "name": "Work",
    "latitude": "40.7829",
    "longitude": "73.9654"
  },
  {
    "name": "Gym",
    "latitude": "40.7829",
    "longitude": "73.9654"
  }
]

Then when copied and pasted into a site like JSON to YAML they can easily get the YAML output to paste into their zones file. Just a potential idea.

What I came up with is to dump the Places to home-assistant.log (when debug is enabled) in a format that can simply be copied and pasted into a yaml file, especially if you add something like this to your configuration.yaml:

zone: !include zones.yaml

The output looks like this:

2019-05-31 12:16:58 DEBUG (SyncWorker_3) [homeassistant.components.life360.device_tracker] My Family Circle: will be included
2019-05-31 12:16:58 DEBUG (SyncWorker_3) [homeassistant.components.life360.device_tracker] Circle's Places:
- name: Home
  latitude: XX.XXX
  longitude: YY.YYY
  radius: ZZZ