Committed a change that adds this feature. Again, if anyone would like to try it and has questions, let me know.
I really would like to try. Is it possible that you make this available via HACS? I think you will get a lot more people testing this (because itās just easier to install for the basic user).
Thanks for considering this.
About Speed 0.0xxxxx instead of 0.0:
Idea: can you implement a ātimeā (in seconds/minutes) and āspeed belowā and after this force the āspeed-attributeā to display 0?
Itās up to the user to enable this or not.
That way, you can easily decide if the target is moving or not, instead of everyone having to implement his own additional code for this.
Is it valid also for people like me that, actually, have no probs in login to the account?
The integration is not ready for a beta release yet. Once it is, it will be installable via HACS. Anyone that wants to try it at this point must be willing to deal with potentially many breaking changes (although things are starting to settle down now), and the complete lack of documentation.
Itās possible, but I hesitate to do so. Any automation based on the value of this attribute will likely need to do a comparison of some sort anyway (i.e., just testing for zero is not very robust.) So, each user who cares probably already has a place to determine what the cutoff value should be.
Not really.
There are two ātypesā of Life360 accounts.
The first is the āolder styleā which is defined by username (aka email) & password. The HA Life360 integration has always supported this type.
However, Life360 now has, and strongly recommends (even pushes users to use), a āverified phone numberā type of account. Once a phone number is verified for an account, it can no longer be used via username & password (although it can be changed back to username & password using their very hidden password reset mechanism.)
Logging in with this second type requires entering your phone number, and then Life360 sends a code via SMS text. You then enter that code, and voila, you phone number is āverifiedā, and now this method must be used to log into this account.
An attempt was made to capture the network traffic between a phone & Life360 so that the HA integration could replicate this login method. Actually, multiple attempts were made. But so far, trying to implement it has not worked.
So, this new option in the integration allows an āadvanced userā to capture the ultimate authorization string (using browser features) and enter it directly into HA so the Life360 integration can work with these new types of Life360 accounts.
BTW, if youāre familiar at all with the Google Maps integration, this is somewhat similar in that a browser is used to log in, then data obtained by the browser is captured and used by the HA integration. The difference is that Google Maps does it with cookie files, whereas what I added to Life360 does it via captured network traffic.
So, what i must do to have the integration working as now?
Do i need to change the way to login into Life360 or not?
How do you log into the Life360 app?
actually with username and password
Then use that with the integration.
1 Like
So, to be clear, in case of forced reconfigure of the integration, it is recommended the phone number way?
I make no recommendation. Iām just trying to support both types of accounts.
Unfortunately, so far, I can only support the āverified phone numberā type of account through a āhackā. I wish it was cleaner. But, then again, I wish Life360 published & supported their API!
FWIW, if you mean a ālogin errorā that causes the account not to work in HA, like happened before, that will HOPEFULLY not happen anymore.
As best I can tell, only the server request that gets the list of Circles the account can see has this problem. In fact, it seems it is very likely this request will result in one of two errors: 403 forbidden (aka login error), or 429 too many requests. Much of what Iāve done recently is to deal with this problem.
In the past, the integration did basically three requests every update cycle: get Circles for each account, get Places in each Circle, and get Members (and their details) in each Circle. Since that first request is likely to āfailā, that was causing all the recent issues.
Now the integration only gets the list of Circles (and Members in each Circle) once an hour āin the backgroundā and saves this information in a file (so that it is immediately available after a restart.) When it does this, it will retry indefinitely if it gets either of those errors (403 & 429), or any ācommunicationā error, too.
Meanwhile, in the āforegroundā it continually gets each Memberās details, from each Circle they are in, (currently) once every 5 seconds.
So, bottom line, unless Life360 or Cloudflare make more changes, hopefully you shouldnāt see any more ālogin errorsā, forcing you to reconfigure the integration.
2 Likes
Thanks for the clear explanationā¦ so finger crossed !
Okay, I understand, but in that case, would you be so kind to tell me exactly where to download the latest version?
When I go to https://github.com/pnbruckner/ha-life360/tree/new-api
I see a green button with ācodeā in it. Is that the download-link to the latest one? Or do I have to look somewhere else?
When I download this, I still see version 0.3.10 in one of the files.
There are actually instructions at the bottom of the README.md doc (i.e., at the bottom of the page you linked.) There are instructions for three different methods. Use whichever youāre comfortable with.
As far as ā0.3.10ā being in manifest.json, thatās because I havenāt actually made a release. Iāve only committed changes on a branch that will ultimately become a release. You can ignore that for now.
EDIT: Actually, I can change that to a dev release, and try to remember to update it every time I make a commit. No guaranteesā¦
Thanks, so I had the correct download link, but because of the version number, I was confused.
Iāll give it try and reportā¦
1 Like
The next feature Iām working on is to send update requests to Members based on their current speed.
Some background. You may have noticed (and I believe Iāve mentioned this before), when you open the Life360 app, Member location updates become much more frequent.
Normally a Memberās location will be updated, say, every 5 - 15 minutes or so, depending on various factors. Sometimes itās more frequent (especially when the device is moving), and sometimes itās much less frequent. But when the app is opened, it seems like the updates come every 5 seconds. This appears to continue until about a minute after the app is closed.
Well, there is a known way to request those more frequent updates. It was in the built-in integration, accessible via buttons.
Through further testing, it appears once that request is sent for a Member, that Memberās updates will be every 5 seconds, which will continue for a minute. After that period of a minute, the updates will go back to ānormal.ā
So, my thoughts of how to use that is thisā¦
Add two more optional config parameters: min frequent update speed & max frequent update speed. If a Memberās reported speed is in that range, then send location update requests for that Member, once every minute, until their speed falls outside that range.
The idea is, you might want more frequent updates when a Member is getting close to home (or somewhere else) in order for automations to be more prompt (e.g., for opening a garage door.) Therefore, you might want more frequent updates when theyāre moving at least a certain speed (e.g., driving in the neighborhood), but you donāt need them when theyāre moving much faster (e.g., on a highway.)
As Iām writing this, another thought occurred to me. Maybe a better option is to select one or more HA Zones such that, whenever a Member is in one of those Zones (and maybe above a certain speed), then request the more frequent updates. This might be even better.
The trade-off, of course, is you donāt want to request more frequent updates all the time, because Iām sure that would but a much bigger burden on the phoneās battery.
Thoughts?
BTW, I had also thought of adding a service whereby this could be requested, say, via an automation, but thatās problematic. The request works via the Memberās ID, which is not really exposed (at least, not yet.) And, AFAIK, thereās no requirement to have unique Member names, so doing it by name canāt be guaranteed to work.
BTW, I had also thought of adding a service whereby this could be requested, say, via an automation, but thatās problematic. The request works via the Memberās ID, which is not really exposed (at least, not yet.) And, AFAIK, thereās no requirement to have unique Member names, so doing it by name canāt be guaranteed to work.
I remember from the previous integration that, when a member changes his name in the life360 app himself, a new device-name was created, breaking all automations that depended on this. Is this what you mean when you say this is āproblematicā ?
Well, first, currently the new integration does not create devices. It only creates device_tracker and binary_sensor entities (one per Member for the former, and one per account for the latter.)
For each Member, there is a unique ID. If you ever look at the debug data, or look in config/.storage/life360, you will see these IDs. They are assigned by Life360 and are unique to all of their Members. The same thing goes for each Circle. These unique IDs do not change when the name of a Member or a Circle changes.
I use these unique IDs in the HA integration as well when creating the entities. Therefore, the āsettingsā for each entity (name, entity ID, etc.) is associated with that unique ID. So, even if a user changes their name in Life360, the corresponding device_tracker entity in HA should not change. The name might change (if you havenāt overridden it), but the entity ID should not change once the entity has been created in the first place.
What I was referring to is, those unique IDs are not visible via the UI. So, there would be no way to specify them in a service call. Um, waitā¦
I just realized. The entity ID could be used in a service call, and the unique ID could be looked up using the entity ID.
So, never mind! Iāll look into also creating a service to update a Memberās location.
Actually, I think Iāve made it more complicated than it needs to be.
I realized I could do it similar to what I had started doing a long time ago. I.e., just use the standard homeassistant.update_entity service. So I āhooked that upā to the integration, and used the feature I added back to the life360 package. It seems to work just fine.
And, the benefit is, this has a lot of flexibility. Through automations, and/or UI buttons, you can request the updates however, and however often, you want.
Iāll commit the changes probably tomorrow morning.