I chatted fellow member @skalavala. He has his own Life360 component and works well for him. But unfortunately, that didn’t work for me. He mentioned he uses ‘speed’ (velocity) to determine if the family member is in the car or not. Can you capture the same information to determine if a member is driving or not?
Thanks for the suggestion! I opened issue #23 driving attribute doesn’t seem to work. Feel free to provide additional comments there.
I think you’re confusing successful communication with the Life360 server as a valid location update. It just isn’t. It’s not equivalent to a network-based tracker that successfully pings or otherwise communicates with a device. For the network-based tracker, that is an update. Pretending that a successful communication with a GPS-based server that provides a last update timestamp is an update is wrong. And using that to compensate for a less than useful network-based tracker is basically trying to make two wrongs a right. If that’s what you personally want to do, then obviously you can. You can do that by modifying the code, adding automations and/or using the existing features such as the last_seen attribute and/or the overdue/restored events. But I don’t want to add a feature I think is wrong, at least given the current implementation of the component level tracker code.
Obviously there is a general desire to somehow better handle significant gaps in location updates. I would suggest addressing that with the HA developers, specifically the component level device tracker, because this is not limited to this one GPS-based tracker platform (or, at least, I don’t think it is.)
Hence, why I said that I didn’t disagree with your logic and have no problem with you not implementing a change.
I care more that my presence detection scheme is reliable than whether it’s wrong or right how I use a network-based tracker alongside a GPS-based one. So, I’m quite happy just modifying the code, and am grateful for your component and that I am able to modify it to suit my need.
Quite frankly, I only use the fallback to the network-based tracker for quicker “At Home” detection when arriving home. Since there is no public API for Life360, I don’t want to abuse it by polling Life360 too often. If that weren’t the case, I’d be quite happy with only using your component with no need to modify the default way state is updated.
@sbmlat or @skalavala, I recall I looked at the speed reported by the Life360 server quite a while ago, but I couldn’t determine what it meant. Specifically, the numbers I see when someone is moving (that aren’t zero or -1) don’t seem to be mph, or kph, or even fps or mps. Also, skalavala, I looked at your configs on github and I don’t see any automations based on them. I only see the values shown in a group.
So, any idea how to interpret this number, and moreover, how to use it to judge if/when a person is driving?
Okey dokey. 
FWIW, I have my system configured to poll the Life360 server every 10 seconds. And the default is 12 seconds. So far no problems. But like you say, who knows.
Also, I have my home zone (in both HA and Life360) set for 300 meters. I rarely, if ever, find the device_trackers haven’t already switched to home when we step in the door.
Regarding the scenario of using the network-based tracker for quicker “At Home” detection, I can certainly see that use case. I’m considering adding support for network-based trackers to my composite tracker. The idea would be to only use the transitions to ‘home’, since the transitions to ‘non_home’ are seemingly unreliable, and are at best a guess (given their nature.) But I really haven’t used these trackers (although I toyed with the ICMP Ping tracker a bit.) I would need to be able to tell if a tracker was network-based. But I’m not sure how to do that automatically. E.g., I looked at the nmap platform code, and it seems to pretend to be GPS-based, since it passes GPS info (i.e., the GPS info for the home zone) to the component level code. At least the ICMP Ping tracker says the source is a router. Anyway, just wondering, could you tell me what your network-based tracker shows for its attributes? Of course block out any personal data.
It looks like HA combines the attributes from both trackers:
source_type: router
latitude:
longitude:
gps_accuracy: 0
battery: 89
scanner: NmapDeviceScanner
ip:
last_update: 2018-09-18 21:26:50-04:00
at_loc_since: 2018-09-16 17:26:30-04:00
moving: false
charging: false
wifi_on: true
driving: false
friendly_name:
entity_picture:
1 Like
I replied here.
1 Like
from a side PM discussion:
Well, not exactly.
I use them both, but not inside each other…
Both the mqtt sensor, and the life360 sensor in my setup are built on the same individual gps sensors and I added network/bluetooth sensors in the Mqtt.
The advantage of the mqtt sensor is I can sense that also on other HA instances, and use its state and attributes value for logic on those systems, albeit a bit more complex to setup. Has ‘home’ network sensors
The advantage of the life360 sensor is its easier to setup, but, it is a strictly local setup. No network sensors.
They are both spot on, and I am very happy with the results after having spent more than 6 months on issues of unreliability and timing with the other ‘default’ devices and techniques at hand.
I ditched the iCloud trackers completely, and would hazard the conclusion that has sped up the system altogether. Cant prove it, but it feels much more responsive.
One caveat though at reboot: the device_trackers component takes about 230 seconds to initiate…
1 Like
This sounds like a great idea…
Is this what you want? (Yes I am using all three at the moment while I test and experiment!)
1 Like
I use the vel attribute to determine the speed. Although there is no documentation around what unit of measument it uses. I compared the vel value that it gives with the actual speed, and I noticed it is almost half the speed. Since I am not looking for accuracy, I just multiply the value with 2, and I get aproximate speed.
I only needed that information to let me know when the kids get in the school bus, and the bus is in motion, so that I can go pick them up zt different locations - depending where they are going - field activities, sports…etc.
The Life360 component I wrote dumps the entire json into MQTT, and also dumps just the device_tracker information. It is useful for me to look into the dump once in a while to see whats changing.
I also think you have to enable “drive detection” mode on the individual/circle in the app. I am not sure the setting is same for all android/ios users, but worth looking into if you don’t get proper value.
Some people suggested that I modify the code to remove the dependency on MQTT and create device_trackers automatically. As mentioned earlier, I use MQTT to inspect data and for troubleshooting purposes 
1 Like
What unit of measure are you using in your observation? mi/h? km/h?
I’ve noticed that, at least for my usage, Life360 reports GPS accuracy in feet. (More on that below.) So my guess would be the speed would be reported in mi/h.
I did experiment a bit with turning on drive detection, but at the time I was more concerned with the isDriving field, not speed. Maybe I’ll give that a try again. Thanks. Because right now what I’m seeing in the speed field is not very useful because it doesn’t really seem to correlate with the actual speed of the vehicle.
Regarding unit of measurement, I really don’t know if the server always reports using the same units, independently of where the devices are. Does anyone have any experience in that regard? E.g., I had noticed the circles drawn around the devices on the map in the frontend didn’t seem to agree with what I saw on Life360’s website and in their app. I realized that Life360 was reporting the GPS accuracy in feet, and the device tracker was expecting meters, but I was just forwarding the number as is. So recently I made a change to convert from feet to meters. That fixed the circle sizes for me. But I’m wondering if that broke the circle sizes for people in parts of the world that use meters.
Thanks. So you’re using my Life360 (an old version ) and Nmap, right? So you just see one, combined device_tracker, right? Interesting. I wonder if the source_type (in this scenario) keeps changing, depending on which updated last. In any case, it would seem Nmap specifies a source_type of router, which is good (at least for my idea of adding support to my composite tracker for network-based trackers.)
Yes, perfect! Thanks!!
Hmm, may it does correlate, within reason. I just happened to be driving on the highway for a while, and if I take the speed values and multiply them by about 2.2 mi/h, they do seem to correlate to the speeds I was driving. Hmm… Oh, and I didn’t have drive detection turned on either.
So maybe it can be something as simple as ‘driving’ = isDriving or speed > some_threshold, where the threshold could be something like 5 or 10 or so. I could even make the threshold a config item, which could be optional if the user doesn’t want to use this feature.
You got it. One combined tracker. The source_type changes, in my case, between router and gps.
Im probably not following, bit what does this mean? Can we combine trackers in the life360 component??
on your GitHub you mention this too:
where the Life360 tracker is combined with a network tracker by the component level code by the user adding the network tracker’s MAC address to the Life360 tracker in known_devices.yaml.
I didn’t know of this option, and use the composite component you made yourself, and also a selfmade mqtt sensor following @NotoriousBDG suggestions. But not in the Life360 component itself?
@Mariusthvdb Is this what you are asking about?
Using GPS device trackers with local network device trackers
GPS based device trackers (like OwnTracks, GPSLogger and others) can also be used with local network device trackers, such as Nmap or Netgear. To do this, fill in the mac field to the entry in known_devices.yaml with the MAC address of the device you want to track. This way the state of the device will be determined by the source that reported last . The naming convention for known device list is <username>_<device-id> and could be set in the app configuration.
An example showing the inclusion of the mac field for multiple platform tracking. The mac field was added to the GPS based device tracker entry and will enable tracking by all platforms that track via the mac address.
USERNAME_DEVICE_ID:
name: Friendly Name
mac: EA:AA:55:E7:C6:94
picture: https://www.home-assistant.io/images/favicon-192x192.png
gravatar: [email protected]
track: yes
hide_if_away: no
If you want to track whether either your GPS based tracker or your local network tracker, identify you as being at home, use a group instead.
Yes, I guess.
I use groups for all my family members, and have both network and gps trackers galore…
SO to be a bit more to the point, if I add the network Mac-address to the Gps device tracker Life360, this would combine the 2 into 1 device_tracker?
Cool, another option to test…
Any suggestions or experience t share about the main difference between the latter combined device_tracker, and the use of groups? Would either of these be more precise?
As with anything, there are usually more than one way to do things. It all depends on your details, what you’re trying to ultimately accomplish, and your own preferences.
Regarding combining a GPS-based tracker with one or more network-based trackers by adding the MAC address to the GPS-based entity in known_devices.yaml, my own personal opinion is that there are better ways. But it works great apparently for some people. Just another tool in the bag of tricks.
1 Like