I am running much older setup (for better or worse…i leave things alone if they are working over here)
Core 2023.3.6
OS 9.5
Frontend 20230309.1
I think I’ve identified why some of the recent attempts to get this working again have been successful, and others haven’t. The server API has definitely changed (yet again.)
But I think I have an idea of how to make it work again (assuming no more changes to the server API.) The changes necessary are a bit extensive. I will probably need to overhaul the life360 pypi.org package, as well as the HA integration. I’ll do this with my custom version of the integration. This will take some time. I’ll keep everyone posted on my (hopefully continued) progress…
7 Likes
Good luck!
It would be really nice if we could get Life360 back. The other solutions just aren’t as responsive for some reason
1 Like
Though I also would like to see Life360 working, I’m surprised on how well the location on my pixel has been working as a substitute. And I have very poor mobile coverage where I live
UPDATE: I now have a version of my custom integration that basically works. It’s not complete, and I’m not even ready to release a beta, but this is potentially good news.
FWIW, the most recent issue was the HTTP 429 Too Many Requests error. Turns out, it only seems to respond that way for the request that gets the list of Circles, and then only sometimes. It does return a retry-after header, and using that, I’m able to get it to work.
I’ve effectively rewritten the integration mostly from scratch. There is now only one “config entry” (aka Integration entry), and it will accept more than one Life360 account in the options. It still only supports the older email/password login method.
I’ll keep everyone posted as to how it’s going. If anyone would like to give it a try, let me know. Take a look here:
Overhaul implementation by pnbruckner · Pull Request #14 · pnbruckner/ha-life360 (github.com)
9 Likes
fair play Phil…that’s great.
Happy to test if you’re happy it’s more or less good to go…is it the “new_api” branch to install?
Yep, that’s it. The binary sensor isn’t implemented yet.
Note that if you still have config entries, it will migrate them to a single one, with the account details from each all being added to the new entry. Also, all entities (if they still exist in the registry) will be moved to the new entry. All this should happen automatically (and there will be a warning about it, just so you know it’s happening.)
If not, then just add the (now) one integration entry and enter the credentials (email/password) for any Life360 accounts you want to use. If you have advanced mode enabled, the first options dialog will have debug verbosity choices.
There is also a new “life360” file in the .storage folder. The details of the Circles each account can see, and the Members in them (by ID) are stored there, since this information is only obtained once an hour (to avoid the 429 error.)
Anyway, if you give it a try, as usual, let me know how it goes. And if you run into any problems, I’ll try to fix them ASAP.
1 Like
I pushed a new commit that handles the case where more than one Circle is seen by the registered Life360 account or accounts. In this case, the tracker’s place attribute will include the Circle’s name in addition to the Place name (if the Member is in one or more Places.)
E.g., let’s say there are two Circles, Circle A & Circle B. They each have their own unique Places (locations & names), but in this example, there is a Place in each that happens to be co-located, and a Member happens to be at that location. In that case, the Member’s tracker’s place attribute will be a list of str (instead of just a single str.) E.g.:
place:
- Place A (Circle A)
- Place B (Circle B)
Even if the Member is in just one place, the place will still have the Circle name in the suffix. E.g.,
place: Place C (Circle A)
If there is only one Circle that can be seen (which is probably the case for most users), then the place attribute will be like before and just include the Place name.
2 Likes
Thanks Phil…have installed it, rebooted and configured without any issues. Is reporting Home, Away and Circle Locations as expected. Will use/observe it today and let you know if I see anything odd. If there is something you want checked specifically let me know. Thanks again.
1 Like
Installed and begin to test…
Thanks.
1 Like
Currently, the speed attribute is given in MPH, because that is what Life360 returns (AFAIK.) The next change I commit will convert that to KPH if the system is configured for Metric. If anyone who tries this has their system configured for Metric, I’d appreciate some feedback if it’s doing the right thing (or maybe Life360 already reports speed in KPH when used in countries that use Metric???)
1 Like
For those trying this, you might want to change the update period from 10 s to 5 s. (Change UPDATE_INTERVAL in const.py.) I think the server won’t mind too much. 
I’m considering just changing it to that, or maybe make it configurable (with maybe the smallest being 5 s.) I just changed the value on my system, and I’m watching my wife’s tracker on a map card while she’s driving, and it’s definitely updating with new positions every 5 s.
If anyone does try the faster update period, I’d really be interested to hear if that caused any problems/errors, or in general, if that seems like a good thing to do.
We will get the updates from HACS or we must do it manually?
For now, manually. After I start making releases (betas first), then you can use HACS.
Ok will you notify us when there is a new release here?
1 Like
Yes, of course.
1 Like
Interesting. If I have the Life360 app open on my phone, then I definitely see new location updates from my wife’s phone every 5 s while she’s moving. If, however, I close the app on my phone, after a short while (maybe 15 - 30 s), the updates stop coming so frequently. Then if I open the app on my phone, the updates from her phone start happening frequently again.
Obviously, this was a very limited test and requires more observation to confirm if there is such a cause & effect. Again, I’d appreciate any feedback on this as well for anyone trying it.
Either way, I’m hoping querying the server every 5 s won’t cause any issues.
Now, I know there is a request that can be made to ask the server to update someone’s location. That was manifested in the built-in integration towards the end via a button. I’m wondering if maybe the integration can make use of it automagically. Maybe, when the speed goes above some threshold, then issue the request for that person, say, every 15 to 30 s. Maybe this “feature” would need to be configurable, because I certainly don’t want HA’s integration to have any significantly negative effect on battery usage, which I suppose it might. For the app, it makes sense to get more frequent updates when it’s open and you’re actually looking at people. But for the integration, I don’t want it to do it all the time because, like I say, it has the potential for increasing battery usage (and the server might get upset, too, which we don’t want! 
)
3 Likes
I’ve a metric HA and seems speed is reporting as MPH alright…360 app is showing KM but HA is showing Miles…
Also as fyi the 360 Person shows as away in HA when “Driving” in the 360 app
Wait, first, what version of the integration are you using? Did you get the commit with the change to report speed in kph if the system is configured for metric? If so, and your system is indeed configured for metric, then the speed attribute in the tracker should be in kph, not mph. (If you did not update to at least that commit, then yes, the attribute will always be reported in mph no matter what the HA system is configured for.)
What do you mean by “360 Person”? Do you mean a device_tracker entity, or a person entity? If you mean a person entity, then its state should show the state from the input it has selected.
If you mean the Life360 integration’s device_tracker entity, (or, I guess, a person entity that uses a Life360 device_tracker entity as input) then it depends on how you have the integration configured, and what the server is reporting for that Member.
First, if you ever want the tracker’s state to be Driving, you have to turn the “Show driving as state” option on.
Next, the integration has to determine if the Member is driving. It bases that on two pieces of data it gets from the server, namely “speed” and “isDriving”, and the “Driving speed threshold” option value. If a threshold is set (i.e., that option isn’t blank), then driving is True if the speed reported by the server is greater than or equal to the set threshold. If a threshold is not set, or the speed is below it, then driving is based on “isDriving”.
You can see the speed reported by the server in the tracker’s speed attribute, and you can see if the Member is considered driving by checking the driving attribute.
If the driving attribute is True, and the “Show driving as state” option is on, then the state of tracker entity should be Driving.
Note that this currently overrides the state based on location, meaning, if the tracker’s state is Driving, it will continue to be so, even if the tracker enters (drives through) a HA Zone. I should probably change that. E.g., with my composite integration, a HA Zone supersedes the Driving state.