Yes, if you want to continue to use the CC, then it would probably be a good idea to do that before upgrading to 0.95+.
Hi,
Iâve read through the above link and made changes to my files and folders (added manifest.json etc) and now my configuration checker shows my configuration is valid.
The only issue is the badges show my daughter and myself as being away when we are actually home.
I went into my configuration.yaml and changed add_zone: from true to all and added the home_place line, so it all reads as follows
- platform: life360
username: !secret life360_username
password: !secret life360_password
prefix: life360
# show_as_state: driving, moving, places
# driving_speed: 18
# add_zones: true
add_zones: all
home_place: Home
I also still have the zones.yaml file that has a list of places like my local shopping centre etc with their GPS numbers (but not my home address as I never needed it before). I have my home configured in configuration.yaml as follows:
name: Home
# Location required to calculate the time the sun rises and sets
latitude: removed_the_number_for_privacy
longitude: removed_the_number_for_privacy
If I log onto the life360 website, it shows both of us as being at home.
I can see discussion above about custom_updater and version numbers but got a little confused.
Any ideas why my icons show us as being Away when Life360 shows us as being Home?
Thanks in advance.
First and foremost, did you install the latest version, 2.10.1? Specifically, are the files you have in <config>/custom_components/life360 the files from here, and only those files?
If youâre using:
add_zones: all
home_place: Home
then it doesnât matter what your HA lat/lon configuration is. It will be replaced by the coordinates of your Life360 Place named Home.
If you add the following to your configuration, then youâll be able to look in home-assistant.log for messages that show what life360 is doing:
logger:
default: info
logs:
custom_components.life360: debug
I have those 3 files plus 2 folders.
- One folder I called âBackup 2019-06-22â which I put a copy of what was in the folder originally (a file called âdevice_tracker.pyâ and a folder called âpycacheâ).
- One folder called âpycacheâ
TBH, I canât remember how I set it up when I first got the Life360 account. Iâd have to watch Dr ZZâs YouTube video again 
I gather I just need to follow this - homeassistant-config/docs/custom_updater.md at 59f7bdc945ad1b418035987e2c57cc9eef6c1fd1 ¡ pnbruckner/homeassistant-config ¡ GitHub - and add the following to my configuration.yaml file:
custom_updater:
track:
- components
- python_scripts
component_urls:
- https://raw.githubusercontent.com/pnbruckner/homeassistant-config/master/custom_components.json
python_script_urls:
- https://raw.githubusercontent.com/pnbruckner/homeassistant-config/master/python_scripts.json
I havenât done this yet until you confirm thatâs what I need to do, plus Iâm a little confused as to what Iâm meant to do after that.
Ok, Iâve done that.
BTW, you replied quicker than I expected. I came back to edit my post to say that although the configuration checker says my configuration is valid, when I restart the services, the notifications bell shows the following:
(above screenshot has the 3rd notification cut off. It says there are newly discovered devices, but I always get this).
Anyway, Iâve updated my conf file with the debug lines and restarted and yet somehow, simply adding those lines have fixed the status on the icons as showing as home, plus the notification only shows the python issue and the ânewly discovered devicesâ
Iâm not sure why itâs now fixed as Iâve restarted the services multiple times.
Question. Do I still need to add those lines about custom_updater to my configuration.yaml file, and if so, what do I do after that?
Thanks
Hey, Phil, I really hope you didnât take anything I said as a criticism of anything youâve done. Iâm sorry if it came across that way. Iâve got nothing but respect for the work youâve put into all of your components.
Based on prior posts, I (wronglyâŚ) assumed that you had to remove the stuff you did to get it accepted. My bad.
And yes I think the driving & moving state option would definitely be beneficial to add back in if you would like to do that. It would be appreciated. I think iâm just going to add the feature request in the âfeature requestâ area of the forum. I donât want to get in anymore âhot waterâ because itâs not really a âbugâ.
Iâve already added all of the life360 places as zones in HA so that isnât an issue at all. So the driving and moving as states were the biggest thing I would be missing.
fwiw, as posted above: Ive taken Phils suggestion and issued the âbugâ: new Life360 integration missing 'Moving' and 'Driving' attributes ¡ Issue #24698 ¡ home-assistant/core ¡ GitHub
some support might help maybe? donât hold back 
I just went to add my support and saw that one of the devs/admins has already chastised you for posting the âbugâ.
See, I knew I didnât want to do it! Troublemaker! 
o well, Iâve already been chastised today, for asking politely⌠sometimes one wonders if the âblue guysâ have nothing else to do 
Iâll add my +1 then to your future feature request and added a somewhat more detailed explanation to why I filed the issue: https://github.com/home-assistant/home-assistant/issues/24698#issuecomment-504672875
Iâve added the feature request.
you should vote too
Ha!
I never knew I needed to (or even could) vote on my own feature request.
I always assumed that it was a given that of course I had voted on the request if I was the one who posted it. 
No wonder none of my feature requests ever get implemented. I guess they figured if the OP of the request never even thought it was good enough to vote on it then there was no use in implementing it!
Done!
1 Like
Something that might work would be to create a Person âcomponentâ and not give it any presence or tracker entities. Then you could set the state of the component to be moving, driving or places.
Since the person component isnât attached to any presence or tracker devices then Home Assistant shouldnât be changing itâs state. Meaning that whatever you set the state to should stay that way until you change it. (Iâm not sure what the state would be after restarting Home Assistant.)
I havenât tested this to see if it works or to see what the downsides are.
I personally disagree that the official Life360 component should have a âshow_as_stateâ option like the custom component did. The state of the official component should work exactly like all of the other device tracker components - it shows home/not_home or whether you are in one of HAâs defined zones. If you want to use Life360âs more advanced functionality all the information is there in attributes and can be accessed by automations or exposed using template sensors.
But if itâs as easy as making a few changes to the integration code then why shouldnât it be done?
there should be no reason to make the user jump thru hoops to create a bunch of sensors (at least one for each circle member) just to get the same functionality that we had before.
I will also say that if you donât want to use a âshow_as_state:â option then no one is forcing you to use it and it will work exactly as all of the other device_trackers work. Why would you get to choose which options other people can use if it literally would have zero effect on you?
added to that, if âall the other device_trackersâ would behave perfectly, and wouldnât cause any issue in tracking our devices, one could argue that that would have to be the default implementation.
unfortunately that is far from the case. wifi based trackers are famous for their unreliability, Bt trackers only work short distance, and several gps trackers (like iCloud) kill the battery of your device.
The Life360 component/now integration has proven to be (one of ) the most reliable device_trackers by far, except for maybe a set of device_trackers used as Composite (not coincidentally by the same author) or a hand_made configuration that takes a lot of fine-tuning (have one like that based on Mqtt device_tracker)
the Life360 is perfect out of the box. Id love it to be the next default tracker, including the moving and driving attributes, and set these as state. Once you use these, you donât want to go back.
If all it takes is an optional config setting
show_as_state: moving, driving
we can all have the best we want/need?
@finity @Mariusthvdb and anyone else who caresâŚ
Regarding the Driving & Moving states, I mentioned to balloob on Discord that there was interest in having this added to the standard life360 integration, and he said, âthatâs the kind of thing that we were thinking of adding to the person integration, but didnât do yet.â I think thatâs a better place for this kind of feature, so I guess I wonât pursue adding it to life360.
Did he give any kind of a time frame for doing it?
It will be disappointing if itâs put off being done there for a long time.
No, thatâs all he said.
No. You can do that, but you do not need to do that. The life360 custom integration can be added manually. Just follow these instructions (where you can follow the âAlternatively, place a copyâ part.)
That would not have had any effect. Something else must have changed.
No.
So is it working for you now?
Wouldnât the person: component still need at least one device_tracker to report a âDrivingâ state though in order for it know? So this is still needed on the device_tracker level I believe.
Although his comment was a little vague, I interpreted it as a sign of support, that it was a good idea they were already thinking of. I just left a comment in the Discord too, so hopefully weâll get a more clear answer.