I organize my work flow so, that I know which file is what and belongs where, by the file_name.
If I stumble on a file called device_tracker.py, I wouldn’t know what it would be, and needed to check its contents. Testing setups is very easy that way. Put a file in my folder put_aside, restart and see what happens.
So yes, I want unique filenames.
Then you need to take that up with the developers. We’re just reacting here to what has already been decided and put into place.
Does HA know it’s a device_tracker file because of the filename ? Iow, if we’d call it random.py, it would not know what to do and give a config error?
Does HA use reserved names for this new system then?, and if yes, do you know where to read about that?
too bad would that be. Before we had several files life360.py and hue.py, which was awkward, confusing an possibly dangerous.
So I like that the devs took up on that and created a new way of handling things. Don’t like they invented a new way for identical naming… nothing solved here.
Nothing “reserved” about the names. But the names do mean something, just like they did before. It’s just where the files need to be and exactly how they need to be named has changed. Basically, nothing has changed (except for the details! 
)
And although I don’t like having to deal with the changes (like many people are having to do), the new structure does make a bit more sense. Remember, HA 1.0 hasn’t been released yet, so anything and everything is still vulnerable to significant change! 
Hi Phil,
In case you haven’t yet seen the v88.0 release notes… There is a new core component PERSON which combines the last state of multiple device trackers tied to an individual, much the same as your custom composite tracker (but much more basic). The UI even includes an integrated means to manage this component.
Interesting discussion of how this component came about can be found found in this architecture thread. There were references to related work in this area, but unfortunately your excellent custom composite tracker was not recognized. Even @balloob stated “The device tracker component should no longer be used to merge devices, this has never worked properly.”
While I think he is referring to the native merge function of the device tracker component, the fact is Person is now a core component and will even be automatically included by default for noob builds (per another new component Default_Config).
All of this circles back to the strong desire to see your premier presence detection work become official. Maybe @MartinHjelmare could work with you to incorporate your advanced composite tracker features like time zone into his Person component. Possibly this interaction could lead to someone who would willingly take over Life360, including making it an official Hassio add-on.
You could still be very actively involved with developing new features and we could still continue to use Life360 as a custom component temporarily if those new features (or fixes) were needed immediately - especially if we knew they were submitted as a PR for review and eventual implementation.
Hi,
Thanks. I am aware of the new Person component. See this post. I suspect (and hope) that my custom composite tracker platform will no longer be needed.
I e-mailed him directly to tell him about my custom composite tracker platform and said he should feel free to leverage any of my work. I have not heard back from him.
I’m a very recent convert to Home Assistant (from Vera) and have been trying to get this Life360 integration working because I’ve been using it with my family for a number of years and seems like this integration works well…when it’s functioning, which is my issue.
I’ve installed custom_components/life360/device_tracker.py (previously using the old configuration, but changed today although the same issue either way.) I’ve added the following to my configuration.yaml:
#Life360 Tracker
device_tracker:
- platform: life360
username: !secret life360_username
password: !secret life360_password
add_zones: all
driving_speed: 20
home_place: Home
interval_seconds: 10
max_gps_accuracy: 200
max_update_wait:
minutes: 45
prefix: life360
show_as_state: driving, moving, places
time_as: device_or_local
zone_interval:
minutes: 15
warning_threshold: 1
error_threshold: 2
new_device_defaults:
track_new_devices: true
When I restart I get the following error:
2019-02-21 18:29:37 ERROR (MainThread) [homeassistant.components.device_tracker] Error setting up platform life360
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/device_tracker/__init__.py", line 189, in async_setup_platform
raise HomeAssistantError("Invalid device_tracker platform.")
homeassistant.exceptions.HomeAssistantError: Invalid device_tracker platform.
I’ve read through this thread and have tried a number of things on my own to try to resolve this, but to no avail. Help? 
You might not have copied the file correctly from github. Did you use the Raw button?
As has been discussed, starting with HA 0.86, the folder layout in custom_components has changed. I’ve recently updated the installation instructions. custom_components.json (which is used by Custom Updater) has also been updated to be compatible with the new layout.
Then just follow the recently updated installation instructions
Then you need to manually move/rename the file. The following Linux commands (or similar) should make the necessary changes:
# From config folder
cd custom_components
sudo -u homeassistant mkdir life360
sudo -u homeassistant mv device_tracker/life360.py life360/device_tracker.py
Then you’ll need to update the following line in your configuration for custom_updater. Change:
component_urls:
- https://raw.githubusercontent.com/pnbruckner/homeassistant-config/master/custom_components.json
to:
component_urls:
- https://raw.githubusercontent.com/pnbruckner/homeassistant-config/master/custom_components_old.json
Note: Once you update to HA 0.86 or later you should change it back.
Then you should be good to go. Just use the Custom Updater to install and/or update.
Note: You may need to clean up the old files after you install/update, if you care.
And just a heads up…
I was just about to post saying that the component still wasn’t being seen by the custom_updater then I thought I would try to and hit the “check” button one last time…and it popped back up.
So just in case anybody isn’t seeing the component in the list then hit that check button once more. 
Do you mean 0.88? If not then I am even more confused with this breaking change than I was before!
Starting with 0.86 the loader tried both cases, and silently accepted either. Starting with 0.88 it still accepts either but now generates a warning for the “legacy” layout.
Thank you. I’ve got it running now. I’m on 0.88 and did have Life360 setup properly, but I had failed to setup the custom_updater configuration. Now if I can just learn how to use it!
I’m confused. The custom Life360 platform does not require custom updater in any way. You can use custom updater to install/update life360, but that’s not required. But as long as you’re good now, then I’m happy.
Releases 2.8.0
Delay firing events at startup so automations have a chance to get ready.
If i will use custom_updater to update the component, will this follow the latest news about platform path? Or we must always rename it to device_tracker.yaml ?
Yes, but actually running the update_all gives me a failed call to that service…
I just updated to 0.88.1 and I am now getting this error:
Validate your configuration if you recently made some changes to your configuration and want to make sure that it is all valid
Configuration invalid
Platform not found: device_tracker.life360
Any suggestions?