I must say “BRAVO!!” 
on the documentation page for your integration. You have definitely set the standard for other authors to follow for well-written, informative documentation.
I read some of the back-n-forth comments about your previous PR. That’s what makes me think the PR gave HA a push to implement the new series of tracker changes sooner rather than later.
Most of the back-n-forth was regarding zones, which in the end I dropped. The tracker changes have to do with how the component & “platform” code interact. That has changed, although for the time being it still supports the “legacy” method, which is what I’m still using. I can’t take credit for any of those changes, or even helping to make them happen sooner rather than later. Totally different topic. I think the desire of the core team to release a HA 1.0 had much more to do with it. 
Hello,
I just upgraded to 0.94.1 today and I’m getting an error on restart. Cannot load device tracker and ios. I have updated the three files in the Life360 folder to the latest on github. I have not modified my config file. If I go into my config file and completely delete all life360 related items, the error goes away and everything loads correctly except our locations show away and battery percentages don’t show. If I leave the Life360 section in the config file, the errors come back and I get entity not available for our locations and battery percentages show None%. Any help would be greatly appreciated!
# Life 360
device_tracker:
- platform: life360
username: !secret life360_username
password: !secret life360_password
prefix: life360
show_as_state: driving, moving, places
driving_speed: 18
max_gps_accuracy: 200
max_update_wait:
minutes: 30
In your custom components folder, do you have a pycache directory? If so, try deleting it and restarting HA. Worked for me, and is suggested in one of the issue threads on Github.
No luck. The only thing in the directory is the Life360 directory.
My pycache was located inside my old devicetracker directory. I removed the whole directory, restarted and was right back up working. Does the life360 directory contain the manifest.json?
Found the pycache directory. It was in Life360. I just couldn’t see it until I used samba. I deleted it and restarted. It did not fix the issue but a new pycache directory was created with new files. Yes, the manifest.json file is also in the Life360 folder.
I have the same issue. Also I tried to delete all the pycache directories founded, restarted Hassio but without success, the problem is still present.
Hi Celestino,
check if in the configuration.yaml you have entries that refer to GPSLogger and comment everything, then restart;
Hi Raffaele, thanks a lot for your suggestion.
Now Life360 component works fine.
What version of life360 do you have? What exactly does you custom_components folder look like (i.e., can you provide a recursive directory listing)? Can you share the exact error message(s) you’re getting?
Out of curiosity, why would you guess that there were GPSLogger entries, and why would you guess that they were interfering somehow???
I lost 2 days there for this, and I don’t find any direct connection; I hope it can also be useful to other people to solve the problem.
Here’s how my custom component folder looks and it is working fine for me:
From my area we say “a culo!” … joke 
.
I noticed that no device_tracking was detected in the entities even those of Nmap that was not to be affected by the recent changes of HA. And I started removing GPSLogger first …
You cheated. You got a copy of what will become the standard component. 
Most people probably are using my older custom component from https://github.com/pnbruckner/homeassistant-config/tree/master/custom_components/life360.
With the new PR merged…why not use that right away (especially since the older component is custom anyways)
Fine by me!
BTW, I’m working on a small fix. Seems I didn’t handle all cases when importing accounts from configuration.yaml. It works as is, but…
- After the first restart it will output a warning about the account already being configured, which of course it shouldn’t do.
- If the password is changed for an account entered via configuration.yaml the corresponding config entry isn’t updated. You’d have to first remove the entry from the Integrations page in the UI, then restart.
- If an account in configuration.yaml is removed, the corresponding config entry wouldn’t be removed. You’d have to manually remove it again from the Integrations page in the UI.
The PR I will be submitting today should resolve those issues. (This was my first attempt at using config entries & config flow. 
)