huh. I tried exactly that… with no luck
Ok, thanks. I’ll move to 1.6.0
My fault for not doing so sooner…
I don’t mean edit your configuration file, I mean edit known_devices.yaml.
I’ll take a look at other device_tracker platforms. If it’s common to have a config option for this then I can add it. But it was my understanding that unless the ultimate source (like a server) provided a picture to use, then typically one would add a picture by editing known_devices.yaml.
EDIT: I searched device_tracker code and I see no evidence of other platforms that take a picture from the configuration. A couple (icloud and automatic) provide static pictures/logos, and only google_maps provides a picture from the Google server (and, of course, my Life360 custom platform does this, too.) So, bottom line, edit known_devices.yaml. 
No problem. That’s the downside to being a beta tester. 
Which, BTW, thanks again for the input, feedback and testing! Luckily I found this problem before I released it into the wild!! 
Yeah, I have the pictures referenced in known_devices.yaml, and configuration.yaml. Neither work.
But **thank you**for making this. Very useful!
Are you sure? I’ve definitely used it in known_devices.yaml and it works. Could it be the link isn’t working? If I follow the link you provided above I get:
FWIW, if you use it in known_devices.yaml it looks like this:
google_maps_xxx:
hide_if_away: false
icon:
mac:
name: Phil (Google)
picture: https://lh5.googleusercontent.com/balh-blah-blah/photo.jpg
track: true
Yeah, I obfuscated the real image names… they do work/
I can see the individual trackers picutres ( defined in known_devices)… but I can’t see any pictures of the composite device. (which is defined in configuration.yaml)
My point is, you define the picture for the composite device_tracker in known_devices.yaml (not configuration.yaml), just like the individual trackers.
So have an entry in both files?
Almost all device_trackers have entries in both. The configuration enables the tracker. The first time the tracker is seen, the common device_tracker component level code will make an entry for it in known_devices.yaml. If the device_tracker platform level code supplies a picture, it will be entered in known_devices.yaml for that device at that time. Once an entry is made in known_devices.yaml you can edit it to make changes, such as add or change the picture.
So, bottom line, yes, first make the entry in the configuration yaml (with no picture definition, because that is not a supported option there.) Then once the entry is automatically made for it in known_devices.yaml, edit it to add the picture you want it to use. After a restart you should see the picture for the composite device.
Ah, I see. got it!
(i didn’t notice as there are way way to many devices in my known_devices.yaml).
Thank you.
I hate to keep asking for more but…
Is there any chance that you could include address?
Both Google and Life360 have it.
No problem. Happy to get the feedback!
I did consider adding address originally, but I noticed that Google and Life360 often provide different address details for the same GPS location. Obviously they must use different algorithms or data sets. This is why I didn’t include it in the composite, because even if the device isn’t moving, it’s likely the address would keep changing back and forth as the two sources update. Not sure there’s a great way to deal with this. Also I’m sure someone said somewhere along the way that it would probably make more sense to convert the GPS coordinates to an address using some independent service, but I don’t recall the details.
Anyway, I’d be happy to add the address attribute if there was a good suggestion for how to do so in a reasonable way.
Just to close the loop on the charging status differences between Google & Life360, I added some template sensors so I could easily monitor over time how these two services report charging status. Sure enough, Google reports when the device is plugged into a charger, and Life360 reports when the device is actually charging (i.e., plugged into a charger but not fully charged yet.) Unfortunately this means while the device is plugged into a charger, and is fully charged, the battery_charging attribute is going to toggle back and forth between True (Google) and False (Life360) as the two source entities update. Not sure there is anything reasonable that the composite tracker can do about this.
Yes and this is just a first response to make sure you don’t think I am ignoring it!
I have thought of the issues you mention and will consider if and how I think might be the best way forward (and for charging)
Just as a point of info though, today (now) I am seeing an address in the Google sensor but none in the Life360 one (for someone away from home) whilst looking at the Life360 app on my phone shows an address. I know all the issues around the unofficial api etc I just thought it might be interesting to you.
EDIT: I found a few more minutes so also…
I know this is a can of worms with a ton of variables ranging from actual devices (phones) through external apps (e.g. Life360) and platforms (e.g. Google) and then finally your component but…
I saw some, to my mind, strange behaviour today. Battery and Moving were being updated but the actual sensors (reported) not being so. Here is a partial screen shot, if you are interested I can try to makew some further observations but it will be a slow process obviously as I need to be here while someone else is out.
As usual, no pressure from me or expectation that you will take this anomaly on especially as I have no evidence whatsoever that it has anything to do with your components.
Here’s the screenshot, ignore the person who is ‘home’, that is me
Ok here are some general ramblings some of which might be interesting to you (@pnbruckner).
I have been using Life360, Google and Owntracks for a while now and I am think that Life360 is a bit of a battery hog (could be my settings?). It used 14% of my battery this charging cycle compared to only 3% for Owntracks. I must admit I don’t remember it using as much as that in the past but that is quite a chunk. I don’t know how I can find out how much Google uses.
I am not convinced that the composite tracker is always updating from the most recent device_tacker. I don’t have screen shot evidence but this morning the last_identity_id was not the device_tracker with the most recent information. That may well be by design for some reason I am not aware of or I may have something misconfigured. the problem is it is not an easy thing to troubleshoot.
As for addresses… I have tried to think of a way around this and to be honest I agree that it is fraught with problems. I think the ‘correct’ way to do it would be to simply update the composite address attribute with the address reported by whatever is the last device_tracker to report, it would then be up to the user to decide how to deal with fluctuating data. Before I used Google I was using a custom component called Places (https://github.com/tenly2000/HomeAssistant-Places) to provide addresses to good effect and I think I agree that this functionality might best suited to being outside the composite device tracker, although including it as I described would work for those who only use one GPS device_tracker.
Which leads me to… I am thinking that I will eventually rely on one GPS device_tracker because for me they all seem to be about as accurate as each other but battery drain could become an issue. I will still use the composite though as it combines well with network based trackers. I use presence detection almost entirely based only on home/not home anyway, so actual location is currently just a (very) nice to have for me.
Hope this helps or is at least interesting.
That is interesting, though it could easily be explained by the fact that there are delays between what the Life360 app on the device knows, and what the Life360 server knows, and what my HA component knows, especially the latter due to the periodic polling nature of the component. Although this is a different scenario than you describe, I’ve also observed the Life360 server doesn’t provide (or, at least, doesn’t always provide) an address when the device is in a “Place.”
Sorry, I’m not following what you’re trying to say here. What do you mean by “the actual sensors”?
That doesn’t sound right. I’ve never seen Life360 use anywhere near that, and I’ve got the settings on my phone configure so that Life360 can run and use the network whenever it wants. You might want to check with Life360 Tech Support.
The composite watches for any of the “input” entities to change. When one does it looks at its last_seen attribute (or the new state object’s last_updated field if the entity does not have a last_seen attribute) to decide if it contains newer information than the last data used for the composite. If it is newer, then it uses it. If not, then it doesn’t (and in this latter case there will be a “skipping update” DEBUG message in the log.)
So, if some of your watched entities do not have a last_seen attribute, then they could cause the composite to use their potentially stale information if they update even when there isn’t new information. This would definitely screw things up. I know that Life360 and Google Maps Location Sharing provide valid last_seen attributes. You also mention using Owntracks. I don’t know how that one behaves, and if it provides a valid last_seen (or similar) attribute. That might be the source of the problem. I’d be happy to add better support for Owntracks, but since I don’t use it it would take some digging to figure out how, or if it’s even possible.
One thing I could easily do is make using addresses a config option. Still, the whole point of having a “composite” tracker is to combine information from multiple sources, and if they don’t all provide consistent data for some attribute (like address) I’m not sure it makes sense to use that attribute in the composite.
Whatever works best for you. In my particular case (and the reason I created this tracker in the first place) was because we were already using Life360 and Google, so there was no battery difference, and neither was consistently updating (at least on a device set in power saving mode.)
As always, thanks for the feedback! 
BTW, the best way I found to understand what is going on is to search home-assistant.log for the state_changed events for the entities involved. All the raw data is there. E.g., here is a search I use:
grep -E 'new_state=<state device_tracker\.([^=]*phil[^=]*|google_maps_nnnnnnnnnnnnn)=[^>]*>' home-assistant.log -o
Of course nnnnnnnnnn would be the actual number for your corresponding google device_tracker.
I’m pushed for time but one tiny response:
Don’t do that for me alone, I am veering towards Life360. I don’t trust the battery figures I reported here as I definitely didn’t see that before and nor does my wife. And Life360 is much more rich functionally.
And on top of that I was bridging MQTT to make Owntracks work which I don’t think is the best way to do things form a security perspective.
I promise that my previous post in the Life360 thread wasn’t to soften you in preparation for this…
I have just started to get errors on start up for one of two phones, my configs for both are identical. I have some suspicions over my router as I have recently turned off it’s wireless and installed a Ubiquiti AP and whilst everything works the router is reporting some strange things in it’s web interface. It is a crap router which will also shortly be replaced but this doesn’t provide, to me at least, an obvious explanation as to why only one phone is ‘misbehaving’.
Do you have any thoughts?
## Log Details (WARNING)
Thu Dec 06 2018 22:19:52 GMT+0000 (Greenwich Mean Time)
device_tracker.phone2_bluetooth unsupported source_type: None
## Log Details (WARNING)
Thu Dec 06 2018 22:19:52 GMT+0000 (Greenwich Mean Time)
device_tracker.phone2_bt_smart_hub unsupported source_type: None
Known Devices:
# BT Smart Hub
phone1_bt_smart_hub:
name: Phone1 (BT Smart Hub)
hide_if_away: false
icon: mdi:cellphone-basic
mac: A8:xx:xx:xx:xx:xx
track: true
phone2_bt_smart_hub:
name: Phone2 (BT Smart Hub)
hide_if_away: false
icon: mdi:cellphone-basic
mac: A8:xx:xx:xx:xx:xx
track: true
# Bluetooth
phone1_bluetooth:
name: Phone1 (Bluetooth)
hide_if_away: false
icon: mdi:cellphone-basic
mac: BT_04:xx:xx:xx:xx:xx
track: true
phone2_bluetooth:
name: Phone2 (Bluetooth)
hide_if_away: false
icon: mdi:cellphone-basic
mac: BT_A8:xx:xx:xx:xx:xx
track: true
Device Trackers:
- platform: composite
name: phone1_composite
entity_id:
- device_tracker.life360_phone1
- device_tracker.google_maps_xxxxxxxxxxxxx
- device_tracker.phone1_bt_smart_hub
- device_tracker.phone1_ping
- device_tracker.phone1_bluetooth
- platform: composite
name: phone2_composite
entity_id:
- device_tracker.life360_phone2
- device_tracker.google_maps_yyyyyyyyyyyy
- device_tracker.phone2_bt_smart_hub
- device_tracker.phone2_ping
- device_tracker.phone2_bluetooth