Hi, has Life360 integrated into HA and working well? I'm giving up on using it in HE, and I just installed a VM with HA specifically for this use of Life360, but since I'm not familiar with HA, any tips or links on how to install and configure it? Thank you.
just FYI -- I tasked AI to take a look at this app and the Home Assistant one which is still working for me. Specifically I pointed it to this recent commit.
This is the part I think that is the most important:
Life360's edge appears to fingerprint the TLS handshake, not just headers
Hubitat's httpGet is built on the JVM's HTTP client, which has its own TLS fingerprint distinct from a real Android device
This seems to explain how Life360 IS able to get past this..
If shifting between two Python SSL setups is enough to flip Life360 from "allow" to "deny," then crossing from Python/aiohttp to JVM/JSSE is a much larger fingerprint difference, and the Life360 edge can absolutely treat it as a separate (and revocable) class of client.
Here's more of the conversation for anyone interested:
That commit is the most recent fix in ha-life360 and it is not an auth, retry, or header change. Home Assistant 2026.2 changed how aiohttp.ClientSession builds its TLS connector, and that change alone caused Life360 (or the Cloudflare WAF in front of it) to start rejecting requests. The fix pins the connector back to the pre-2026.2 SSL context via
ssl_util.client_context() plus a HomeAssistantTCPConnector with explicit connection limits.
The implication is important for the Hubitat app: Life360's edge appears to fingerprint the TLS handshake, not just headers. A correct User-Agent and a valid Bearer token are not sufficient if the TLS / connection-level fingerprint drifts into something Cloudflare flags as a bot. This is a plausible root cause for the Hubitat "works for a while, then stops" pattern — Hubitat's httpGet is built on the JVM's HTTP client, which has its own TLS fingerprint distinct from a real Android device, and Cloudflare's bot rules can change at any time without any of our code changing.
This is also a constraint: from inside Hubitat Groovy we have very little control over the TLS stack. We cannot match an Android client's JA3/JA4 fingerprint the way a real Android app would.
---
The short answer: **Cloudflare doesn't fingerprint the device; it fingerprints the TLS library. And nearly all Android apps use the same TLS library, so they all hash to the same fingerprint**. Hubitat uses a different one entirely.
The mechanism — JA3 / JA4:
When any TLS client opens a connection it sends a "ClientHello" with an ordered list of: supported TLS versions, cipher suites,
extensions, elliptic curves, signature algorithms, ALPN protocols, etc. Hash that ordered tuple → you get a JA3 (older) or JA4 (newer)
string. That hash is stable per TLS implementation, not per device.
Why "all those Android phones" collapse to one fingerprint:
The Life360 Android app, like most Android apps, uses OkHttp on top of Conscrypt (Google's BoringSSL fork that ships in Android). Pixel,
Samsung, Xiaomi, OnePlus — doesn't matter. Same library, same handshake, same JA4 hash. Cloudflare just needs to recognize that one hash
as "looks like an Android app." It doesn't need a device list.
Why Hubitat doesn't blend in:
Hubitat runs on the JVM, so httpGet goes through Java's built-in TLS stack (JSSE / SunJSSE). JVM TLS handshakes have visibly different
cipher orderings, different extension orderings, different ALPN advertising than BoringSSL/OkHttp. To Cloudflare it doesn't matter what
the User-Agent header says — at the TLS layer the request looks like "Java HTTP client", not "Android app." The header is claiming
Android; the handshake is claiming JVM. That mismatch is exactly the kind of signal bot-detection rules look for.
Why the ha-life360 commit is evidence for this hypothesis:
That fix wasn't about retries or auth or headers. HA 2026.2 changed aiohttp.ClientSession's default SSL context construction — a Python-internal change — and Life360 immediately started rejecting requests. Pinning the connector back to ssl_util.client_context() fixed it. If shifting between two Python SSL setups is enough to flip Life360 from "allow" to "deny," then crossing from Python/aiohttp to JVM/JSSE is a much larger fingerprint difference, and the Life360 edge can absolutely treat it as a separate (and revocable) class of client.
Why "eventually" rather than "immediately":
Cloudflare's rule sets aren't static. A fingerprint that's allowed today can be added to a managed-challenge or blocklist tomorrow —
either globally (Cloudflare's threat intel adds "JVM-default-TLS impersonating Android UA" to a list) or per-account (the same Bearer
token making N requests/hr from a non-Android handshake trips a heuristic). That's a much better fit for "works fine for weeks, then
degrades" than token expiration would be — Bearer tokens generally fail abruptly, not gradually.
sounds like this is it.. see my AI response in the previous post. Wish there was some way to change this but doesn't seem too hopeful
Question: How is Home Assistant using the Android TLS library to continue working? Is is possible to include a more appropriate TLS library as a Hubitat bundle?
AI didn't seem to think it was possible for the Hubitat to mimic an Android device at that level.. but would be happy to research any ideas
@jpage4500, I recently took to AI as well and decided to check if I can get this working again...
I can't remember exactly what I did, but I've been testing a version for a month or so now and it has not died on me yet - the same Bearer token has been working for me, even after a accidental uninstall then install again.
As I made too many changes, and there are still some issues, including, still trying to get an accurate journey log, I will PM you a modified version of your code with just changes to the authentication method for your review.
This is what AI reported when I compared the two version:
"My read: Life360+ is not failing because the Bearer-token authentication is fundamentally different. It is more likely failing because its request pattern plus CloudFront/cookie recovery is easier for Life360 to throttle or reject. Life360 Connect is more resilient because it uses api.life360.com, handles 429/403/401 explicitly, and has safer scheduling/watchdog behavior."
See what you think.
1 Like
Nice!! AI really does change the game for low level things like this.
I had pushed the changes I was testing with as long as 1 more really small but hopefully useful one -- the app will notify my phone when the token expires.. just makes detection a little faster 
add device notification when token expires
1 Like
that's pretty handy for sure.
Like everyone else, I setup a HomeAssisant container and use that for Life360 --> Hubitat these days - but even it can't do that (I don't think). 
@jpage4500, please consider changing the thread title to [Not Dead Yet] Life360+ or [Maybe working again?] Life360+ 
1 Like
Sorry, easy for me to throw out the occasional probing question. Short on implementation ideas, especially regarding the HE platform and groovy. 
I'll ask my friend, Claude, to see what they think!
I uploaded a bunch of info to Claude. The prompt and response are below. I like the Docker idea to implement a proxy/relay approach. However, I have ZERO skills in that area other than installing a container.
Hubitat's integration with Life360 started failing with login issues and randomly expiring tokens a long time ago. jpage4500 and iEnam used AI to fix the login issue - see attached 3 files. My question to jpage4500 was "Question: How is Home Assistant using the Android TLS library to continue working? Is is possible to include a more appropriate TLS library as a Hubitat bundle?" to which he replied "AI didn't seem to think it was possible for the Hubitat to mimic an Android device at that level.. but would be happy to research any ideas". What is the real possibility to include and implement a more android-like TLS library into an HPM bundle?4:19 PMClaude responded: This is a genuinely interesting technical question.This is a genuinely interesting technical question. Let me give you a straight assessment.
Hubitat's httpGet uses JSSE (Java's built-in TLS stack). Life360/Cloudflare fingerprints the TLS ClientHello (JA3/JA4 hash). A JVM handshake looks nothing like OkHttp+BoringSSL/Conscrypt, regardless of what headers you send.
Can You Bundle a Different TLS Library in an HPM Package?
Short answer: No, not in any practical or supportable way.
Here's why, layer by layer:
1. Hubitat's sandbox doesn't allow arbitrary JAR loading. HPM bundles are Groovy drivers and apps — source files that get compiled and run inside Hubitat's sandboxed execution environment. You cannot ship a JAR (like Conscrypt or OkHttp) and load it into the JVM's security provider chain. That requires Security.insertProviderAt() or a custom SSLContext provider, both of which are outside what Hubitat exposes to driver/app code.
2. Even if you could load Conscrypt, you can't control the socket at the right level. Hubitat's httpGet/asynchttpGet abstractions sit on top of the JVM HTTP stack. To use a custom TLS provider, you'd need to construct your own SSLContext → SSLSocketFactory → HttpsURLConnection or OkHttpClient pipeline. Hubitat doesn't expose raw socket construction at that level in the sandbox.
3. BoringSSL/Conscrypt is native code. Conscrypt ships .so files (native ARM/x86 libraries). Even if Hubitat let you load JARs, the native layer would require OS-level deployment — not something an HPM bundle can do.
4. Groovy's @Grab / Grape is disabled on Hubitat. On a standard Groovy/JVM environment you could @Grab('com.squareup.okhttp3:okhttp:...') to pull in OkHttp at runtime. Hubitat explicitly disables this mechanism in the sandbox.
What Home Assistant Does (and Why It's Different)
HA runs as a full Python process on real hardware. The ha-life360 fix works by controlling the ssl.SSLContext object that aiohttp uses — something any first-class Python process can do freely. That's a completely open execution environment vs. Hubitat's locked-down sandbox. HA isn't using BoringSSL either — it's using Python's OpenSSL bindings — but it has fine-grained control over the context, cipher list, and connector behavior that Hubitat simply doesn't expose.
What Is Actually Possible
The only realistic paths are:
A proxy/relay approach — Run a small local service (Python, Node.js, a Docker container on a NAS/Pi) that handles the Life360 HTTP calls using a properly configured TLS stack, then exposes a simple local HTTP API that Hubitat calls. Hubitat's JVM TLS fingerprint doesn't matter for a local HTTP call to 192.168.x.x. The proxy handles the Life360 side with Python aiohttp + proper SSL context, exactly like HA does. This is the most viable real solution.
iEnam's approach — Tweaking request patterns, endpoint selection (api.life360.com), 429/403/401 handling, and watchdog behavior to be a less obvious non-Android client. This doesn't fix the TLS fingerprint but may reduce the heuristic score enough that Cloudflare's bot rules don't trigger as aggressively. It's buying time, not solving the root cause.
Wait for Hubitat platform changes — If Hubitat ever exposes a way to make raw HTTPS calls with a configurable SSL context, or adds a bundled HTTP client with BoringSSL-like fingerprints. Unlikely and not on any public roadmap.
Bottom Line
The AI that told jpage4500 "it doesn't seem possible" was correct. The constraint isn't knowledge or cleverness — it's that Hubitat's sandbox deliberately prevents exactly the kind of low-level TLS stack manipulation that would be required. The proxy approach is the only path that actually solves the problem rather than works around it temporarily.
and jinx it? no way
3 Likes
I just merged in some changes from @iEnam that I've had running since Friday. I'm definitely not going to get anyone's hopes up and say "it's working again!!" since we've been down that road before.. but, hey, if you rely on Life360 like we do in my family and want something to try -- give it a shot.
2 Likes
Will do.
It would be nice to not have to maintain a HomeAssistant container for only this one reason.
M.
Well, I'm not going to use the F word, but I'll say it the other way around and say:
"It doesn't appear to be broken."
and just leave it there. 
I'm not going to go through all the B.S. of moving all my automations back to it just yet... again... but I'm cautiously hopeful I can shutdown the HA container soon.
M.
1 Like
@jpage4500, I have been running your latest version with my original access token created around 20th March 2026 (still working 
)... will keep your version with one member running alongside my version with 4 members.
Hopefully - running two versions will not have any adverse affects, I have recently seen some errors, see below - everything is still working fine.
My Hubitat is using the same token as my HomeAssistant, so we'll see what happens... 
1 Like
Working great here, 4 family members. All I did was update the app in hubitat, re-enable it and nothing more.
1 Like
This app works well again.
1 Like
version 5.1.3
- add /view endpoint to view life360 members on map (either google w/API key or openstreetmap)
Fun little extra for anyone who wished Life360 had a web view..
I added a new section called Map View -- there's a field for a google maps API key but it's optional and a "Generate Map Link" button. Click the button and a URL will show up that you can bookmark -- it'll show all of the Life360 members on a full screen map (google maps if you set a key otherwise OpenStreetMap)
Google Maps is more detailed and getting a Maps API key is free -- just requires a little setup work.. make sure you lock it down as well so you can't get charged. I have a guide on how to do this here
4 Likes
