Life360 Device Tracker Platform

[Cali]

device_tracker:

• platform: life360
  username: [email protected]
  password: password

[pnbruckner (Phil)]

Ok, thanks.

So you might be seeing the same behavior as @rossmatt06 did (see posts just above.) I.e., your Life360 Home Place may not agree with your HA zone.home. Even if their centers are the same, their sizes might be different.

By default, your HA Life360 device_tracker entity’s state will be set to 'home' when the circle defined by the GPS coordinates & accuracy reported by Life360 overlaps with HA’s zone.home. Whereas Life360 decides if you’re home based on how you defined the Home Place in Life360. So, again, if HA’s zone.home does not agree with your Life360’s Home Place, then HA and Life360 may not agree as to when you’re “Home.”

If this is what is happening, then I’ll make the same recommendations as I did to @rossmatt06:

@pnbruckner

So, my recommendation is to do one of the following, or both:

1. Override the default radius of HA’s zone.home by explicitly defining a HA zone named “Home” with a radius that is the same as the radius of Life360’s Home Place. See HA’s docs about defining zones.
2. Make sure you define show_as_state and have it contain at least the option places .

If you do one or both of these then Life360 and HA should always agree about you being “Home” or not.

So, really, the easiest way to resolve this (assuming this is your problem) is to add the following to your HA life360 configuration:

    show_as_state: places

This will cause your HA device_tracker entity’s state to be set to 'home' whenever Life360 reports you are in your Life360 Home Place. (BTW, this assumes the actual name of this Life360 Place is “Home”. If not, you should also add the HA life360 configuration variable home_place.)

[pnbruckner (Phil)]

Based on recent feedback and discussion, I’m considering adding a new choice for add_zones that would update HA’s zone.home to match Life360’s Home Place (or, more accurately, any Life360 Place whose name matches the home_place configuration variable.) This would override HA’s zone.home (as described here.)

Currently the add_zones feature purposely ignores Life360 Places whose name matches the value of the home_place configuration variable. However this can lead to the situation discussed above – HA and Life360 not agreeing if you’re home, due to differing definitions of the home area.

The new option would be add_zones: include_home_place.

Before I look into implementing this I’d appreciate feedback on what you think about it.

I’m also considering adding a service that will run the zones_from_places function so that you can manually update the HA zones created from Life360 Places (say when you change the Places defined in Life360.) Currently you’d either have to restart HA, or wait until the next periodic update (specified by zone_interval.)

[Cali]

I think thats a good feature.
However; After adding the config in the main post I set the lat and long in my config to 0.
But the Home/Away feature is working perfect, seems like its using the zone in Life360?

[pnbruckner (Phil)]

You should still make sure latitude and longitude under homeassistant in configuration.yaml (or the explicit definition of HA’s Home zone, if you use that) is correct, since these values are used by other things such as sun.sun, etc. Of course, if/when I implement the new feature, and you choose to use it, this can be done automatically for you.

And, yes, if you added show_as_state: places to your life360 configuration in HA, then when Life360 reports that you are in its “Home Place”, then your HA device_tracker entity will be set to home. In this case it doesn’t matter (for the most part) how HA’s zone.home is defined.

[pnbruckner (Phil)]

Released 2.5.0

Add new configuration variables warning_threshold and error_threshold to filter inconsequential communication errors.

[maurizio53 (Maurizio Fabiani)]

I am having serious problems after upgrading to 2.4.0. Home Assistant refuses to start without giving me any error. It just stops the process of running… After downgrading again to 2.3.1 the issue is solved. What do you think about it? What i did was only to download the 2.4.0 and adding the ‘time_as: device_or_local’ option to the configuration. Did i miss something? @pnbruckner

[pnbruckner (Phil)]

2.4.0 (and later) has a new Python Package requirement, specifically timezonefinderL (which itself requires numpy.) The first time you start after upgrading the Life360 custom platform, HA will need to download and install these (from PyPI.) This can take a while. Even though the GUI may not respond during this time, you should see activity in home-assistant.log (try using “tail -f home-assistant.log” to see if events are being logged.) These are both somewhat large packages (relative to other packages used by HA and its components.) So, even though this is the same thing that would happen whenever any new package (or new version of a package) is required, the size may make it take longer than usual.

[maurizio53 (Maurizio Fabiani)]

Ok, so i don’t need to install manually any new package? It will all automatic made by HA?
During the start process i was using this command to check the activity: ‘sudo journalctl -fu [email protected]’ but nothing appeared about what you write… I expected also more than 20 minutes to see what was happening but… nothing…

[pnbruckner (Phil)]

No, you should not need to install those packages manually. HA’s module loader will do that automatically when it loads my module.

The command you used to see activity during startup should work as well.

So you say you waited 20 minutes and nothing. Do you mean there were no logged events that had to do with my component, or there was no output at all?

[pnbruckner (Phil)]

If you like, you can try manually installing it via these commands (which you may have to adjust, depending on how you installed HA):

sudo -u homeassistant -H -s
source /srv/homeassistant/bin/activate
pip3 install timezonefinderL
deactivate
exit

Then restart HA and see if it makes any difference.

[ludeeus]

numpy can use a good 30min on a RPi with little to no activity in the log

[pnbruckner (Phil)]

Not sure how long it took the first time it was downloaded and installed on my RPi. I probably would not have added this feature, and its requirement to use timezonefinderL (which needs numpy), due to this reason (and their size) if there weren’t standard HA components that also use numpy.

[maurizio53 (Maurizio Fabiani)]

During the 20 and more minutes there were no output at all. All it seemed blocked…

[pnbruckner (Phil)]

Well, not sure what to tell you. I know it has worked for me and at least a few others. Maybe you can try manually installing timezonefinderL (which will also install numpy) using the instructions I provided above. Then when you restart HA, it won’t have to install them so it should be able to start up normally. (If you’re on a RPi, and want to use the time zone feature, don’t forget to also install libatlas per the instructions on my life360 doc page.)

Or, you can use the Custom Updater, which also will install requirements when you use it to install or upgrade custom components such as life360.

[maurizio53 (Maurizio Fabiani)]

Does it means that if i don’t want to use the zone features i can also don’t need to install timezonefinderL ? Does it means i can not use the option time_as so to not need to install timezonefinderL and numpy?
I already use custom updater, so if i do an update_all from the frontend it will install all requirements together with the latest version of life360.py ?
EDIT: i already installed libatlas.

[pnbruckner (Phil)]

You can use time_as with utc or local, and it will not need timezonefinderL (and numpy.) However, the way the system works, if a package might be used, it needs to be listed in the REQUIREMENTS variable, and that will cause it to be installed, even if it isn’t going to be used. The system is not based on the configuration, only what the configuration might need.

There was discussion above about trying to find a way to have these packages installed only if the configuration actually needed them. But that turned out to be fairly complicated, so I gave up on it.

If you use custom updater, and if you updated life360 using its update_all service, then in theory, the packages should have been installed at that time (as opposed to when you restarted HA.) So, if that worked, then your problem should not be caused by HA taking a long time to install those packages.

Bottom line is, I guess we still don’t really know what’s causing you problems. We’ve only guessed that it might be the long download/install time.

As an experiment, you could edit life360.py to remove timezonefinderL from the REQUIREMENTS list. Then, if you don’t use time_as, or you set it to utc or local, then everything should work. If it does, then it would seem the problem does has something to do with installing these extra packages. But if not, then there is probably another issue causing the problem.

[maurizio53 (Maurizio Fabiani)]

Ok, tomorrow i’ll try again with custom updater and see what happens… will let you know…
So i can use time_as option with local instead device_or_local ?
EDIT: I updated life360.py manually as with custom updater i got often failed to call that service…

[pnbruckner (Phil)]

@maurizio53

So i can use time_as option with local instead device_or_local ?

Yes.

@maurizio53

with custom updater i got often failed to call that service

Were there any error messages, or any debug messages in the log (related to custom updater, or anything I guess) that might be helpful to provide some insight into the problems you’re having?

[maurizio53 (Maurizio Fabiani)]

No error in logs… only get ‘failed call service update_all’ or something similar on the frontend.