But after re-enabling, it works for a few polls, then back to 403. So whatever they are checking for now is NOT instant. It looking for a pattern that shows we aren't real.
I've loosely tried both of these. Both HA repos haven't been touched in ages
homeassistant-config:
commit ac37bbf7669393b1a7d5638a6d37a94b6436afa8
Author: Phil Bruckner <pnbruckner@gmail.com>
Date: Fri May 31 11:47:44 2019 -0500
Life360: Adjust to changes in the upcoming 0.94 release (#148)
Items imported from device_tracker and zone have changed. Adjust accordingly, while maintaining backwards compatibility.
life360:
commit 0ef54153f29c8f88ee9825f43d2ab0507a7156b6 (HEAD -> master, tag: v7.0.1, origin/master, origin/HEAD)
Author: Phil Bruckner <pnbruckner@gmail.com>
Date: Fri May 24 08:57:29 2024 -0500
Bump version to 7.0.1
I tried moving the fetchCircles() to the v4 endpoint like HA is already doing, but that didn't help.
I also tried moving to NOT fetchMembers() every poll and only run fetchLocations() but that didn't help either.
Whilst I admire all you guys tenacity in pursuing the Life360 integration, and I'm not trying to be controversial here, wouldn't it be better to move on and try something else that works faultlessly?
Have a look at the 'Owntracks' integration. I switched over to it when Life360 failed for the second time months ago and haven't looked back.
Just my opinion and like I say I'm not in any way trying to be controversial but it does seem that as soon someone opens a door into Life360, they spot it and close the door again.
So, following loosely, it seems that stopping it for (some time), then restarting it works for (some time). Seems they aren't banning the ID/token but are resetting it after some period of good behavior (in this case, no calls, maybe the ultimate good behavior.) Then it takes only a few polls (1, 2, 3, more?) before they see something they don't like and put us in timeout. I keep thinking that the token is fragile - we authenticate one and never again. OTOH, since they don't just kill it permanently, it seems they don't track them on their end? Can an authenticated token be validated just against itself? Or, is it something more like a session-id tracked by their server? Again, the fact that our authentication can get out of token jail and work again after some period of good behavior seems interesting. They either can't ban it forever, or choose not to do so, for whatever reason. Don't know what it takes to setup a local HA instance, steal the private key and use WireShark to shadow/monitor the communication. Figure out exactly what the communication with HA is over even a poll cycle or two. If HA is so stable, isn't changing, and we can look just like HA, then it seems we'd blend in chameleon like and not get zapped for either misbehavior or just for being an unsupported app. Random thoughts. Anything here make any sense?
yeah that was the idea.. I think we were behaving almost like HA with the only difference HA polls a lot more frequently and less random (I could be wrong but that's what I remember)
The best way IMO is track exactly what a real Life360 client is sending. I did that a while ago and they are using newer API's than what we/HA were using. So, that's something that we could try again (at the time when I first implemented it I wasn't handling cookies -- something @matt.palermo noticed and fixed.
Of course - if you're looking for a stable/reliable way to track multiple devices than the Owntracks project is probably a better fit. I personally use HD+ for geofencing (automations when my phone leaves the house and returns) but it's Android only where Owntracks supports iOS.
I'm the only Android user in my household and at some point I would like to convert my family over to Owntracks.. it's just a bit of a hard sell since Life360 does have quite a nice and useful UI -- and we're just on the free version. The paid version offers a lot more too.
So, hopefully this project will continue to evolve and work but I think anything we do at this point will take time to test and make sure it's working reliably.. just my $.02
I have 5 people on my Life360+ account. Two of them don't really want it on their phones, but accept it enough for the "in an emergency" aspect (which really is the purpose). Two other people are pretty elderly at this point and this is all they really know or want... or care to know or want.
Moving away from Life360+ to some self-hosted thing that now I have to babysit and keep running 24/7 - AND be user support for? Nope. Time is money, friend. I don't get paid at home for keeping containerized web apps running 24/7. I do that all week for a very large technology company everyone here knows well.
Owntracks a pretty tough sell. I'll pay for someone else to do it.
Similar use case/users/situation here. Looked at Owntracks after the previous generation of Life360 Hubitat imploded, and I just couldn't pick up that load. Hubitat is hard enough to keep running (recent changes have destabilized the ZWave network - apparently new ZWave firmware pushed out? just briefly saw in release notes.) A few weeks ago, everything Zigbee started hanging up and had to reset that networking. Life360+, when working, is exactly what I need. I'm running too fast to get deep into it but greatly appreciate the efforts the several of you have put into debugging and understanding it. Buying an up-level Life360 account doesn't get me anything if it isn't integrated with Hubitat. Switching from Hubitat to some other automation scheme is almost unimaginable due to sunk cost in Hubitat rules and gear. Sort of stuck here. When Life360+ works it's great, would even pay reasonable fee/subscription if that worked/could stay working. In meantime, If Life360+ integration stays broken, I just have to accept that and try to deal with the rest of my mess here. Thanks for trying - hoping someone gets some inspiration as to what HA magic we're missing for the Hubitat implementation.
Funny comment since you need to babysit Life360 to try to keep it running!
Does HA inject different outgoing header information to the requests? Maybe that's why the Hubitat one gets filtered after awhile?
For the record, I set up OwnTrack on the family's phones. Clicked the button so that Google wouldn't try to remove permissions if they never opened it, and just forgot about it. I added some features back in January to the Hubitat side of the app, but it just keeps chugging.
Same here. It's on my android and my wife's iPhone. I haven't even thought about it since the last update. It's a great alternative for those that do not need the other services of life 360.
That was an issue in the dev's 2.4x version of the app. They enabled the "background operation" in 2.5.x (current Play/App store versions) which allows Android to start the app in the background without user intervention.
But yes, in 2.xx, that was a PITA and a bit of a show stopper.
That's what I thought.
I haven't touched the app for 2 months. I had to because we moved house. I had to change my home location.
It just works on my android and my wifes crapple.
Laugh all you want, but you are missing the point against OwnTracks. It's exactly this kind of B.S. you have to go through when host stuff YOURSELF.
Life360, as a cloud location tracking service, works perfectly fine. There's an entire engineering team keep it running and keeping it updated. There's people on-call getting paid to be woken up at 3:00am because something failed (depending on their infra) to keep it running 24/7/365.
It's only this little app that has issues because they won't release their API.
OwnTracks? ALL of it is your problem. Do you feel OK taking the risk that a family member is in some kind of trouble and don't know where they are or UNABLE TO tell you because they are out cold, or it's your elderly Alzheimer's parent that has gone missing, and oh look...
the container on your NAS crashed and their location isn't recorded
F'in' comcast was out again and their location isn't recorded
UPNP port didn't open for some reason and their location isn't recorded
etc etc etc
If this is acceptable, I'd agree that OwnTracks is probably a better solution for you.
Before last week, I cant remember when the last time it didnt work for me. Its been rock solid. All these apps need babysitting from time to time. Owntracks is no exception.
I may give owntracks a try but I will wait a bit to see what happens with this first.
This was my point. If you need locations inside Hubitat, you can run both. I do since my kid has a friend in one of her Life360 groups, and I didn't want to link her friend to my Hub to track.
But from my other point above, goes HA add in different outgoing header information? When Hubitat does the get/post we can load the header as well as the body of the outgoing JSON request. Maybe they do something different there? The Cloudflare edge server does scrape that off and do things with it.
This almost feels like something specific to either the hub or groovy or something. I can make a request from postman, curl or node-red and it works just fine, I get a valid response back from Life360. But the exact same request from Hubitat results in a 403. I even put a little http catcher together and looked at the requests from postman, node-red, curl, and hubitat and they all look identical. Same headers, same everything. So for the life of me I can't figure out why it doesn't work from Hubitat.
The only way I can cause a 403 error is I take out the User-Agent header. But I can see the User-Agent header going out from Hubitat.
Don't know if this is any value, but thought I'd share my $0.02.
I've also been using Life360 forever, and it's very nice for keeping track of the family, especially our young drivers. While it was working in Hubitat as a presence sensor, it was great. But now I just get 403s when attempting to Fetch Circles, Places, Members, etc. Strangely enough, yesterday it started to work, but today it's down again. Something is wonky, it's a puzzle. Thanks for all who are attempting to figure it out.
Yea, I understand - but I think it's something else because it DOES work from everyplace else with the exact same headers. And greanted I can't see what the app is sending from my phone, but with postman & curl I get a successful response every time. And I've made sure that they both match the headers coming from HE. Plus HA works great, so the only place it's not working from is the HE hub.
Are you able to see what encryption is being negotiated between curl/postmand vs the hub? Like maybe they are dropping an older TLS or something? Yes I'm aware that doesn't explain it working intermittently...
Just a thought I had since every damn thing else seems identical...
