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.
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.
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. 
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
Released 2.10.1
Adjust per some changes coming in the HA 0.94 release, while maintaining backwards compatibility with existing HA releases.
New PRs submitted to make this a standard component. Implementation was simplified over the original proposal.
Just to be clear, the configuration is different and you’ll need to adjust if/when you move to the standard component. You can see the new config variables, etc. here.
And at some point (assuming it does get accepted as a standard component) I will drop support for this custom component.
Some of the major changes from the custom component:
life360 as opposed to device_tracker.place attribute was added that can be used to determine if the device is located within a Life360 Place. Or, of course, you can manually create HA zones from Life360 Places (as mentioned above), which will effectively do the same thing as show_as_state: places. And there still are driving and moving attributes, too.Will the new component be considered a device_tracker by Home Assistant?
Sorry, I guess I don’t understand the point of your question.
Technically speaking, in the current terminology (as I understand it), it will be an “integration”, and it will create device_tracker entities indirectly via the device_tracker, er, whatever-its-called.
Does that mean the time in the sensor will now be displayed in UTC only? If so, is there a way we can convert to local? If not, I’ll stick with your custom component for now 
Also would like to ask, what’s the shortest interval_seconds we can do?
I have my gpslogger @ 1 second
One more for you. Is it possible to increase/decrease the zone’s radius?
I have automations set based on entering the zones which gives enough time to open the gate etc
Edit: Found out that you can set the radius on a zone in the Life360 app
But unfotunately the max radius is 3.2KM. If I set HA to take all zones from life360, can I add additional zones in HA and build an automation when entering that zone? (in case you’re wondering, I need 10km which is roughly 10 mins from home and HA notifies me if the inside temp is too cold or hot)
Since we’re on that subject, is it a problem if 2 zones overlap each other? I.E 10km out and Home
Thank you so much for all your hard work with this component thus far
Yes, like most things in HA, datetimes will be in UTC, and unless there is some special frontend feature to display it in a different time zone, it will be displayed in UTC.
You could use my composite tracker, even with just one “input” tracker like Life360. It sill has the time_as feature. The downside is it doesn’t take all the attributes from the input trackers, so you’ll lose direct visibility of those.
Technically speaking, it can be negative infinity. Practically speaking, I guess it depends on your system. Also don’t forget the shorter you make this the more frequently it will be hitting the Life360 server. I personally wouldn’t go any lower than 5 to 10 seconds.
To answer your questions about zones, no, I currently do not provide (nor plan to provide) a way to adjust a zone that is created automatically from a Life360 Place. Yes, you can still create zones in HA (the normal way), even if you have life360 automatically creating zones from Places. No, AFAIK, there is no problem with having overlapping zones. When HA tries to figure out if you’re in a zone, and if so, which one, it has an algorithm to pick the “best” one if the device is in more than one.
I’m not guaranteeing how long I’ll support this custom component after it becomes standard (assuming it does.) I may not delete it, but at some point I won’t work on it to keep it working when things change and it breaks.