[RELEASE] PositionGuard Family Presence — one presence device per family member, area-level, no coordinates on your hub

[clundin1]

Since Life360 shut off its API, there hasn't been a great answer for family presence on Hubitat: phone geofencing is flaky, WiFi presence broke when iOS and Android started randomizing MAC addresses, and most alternatives want every family member to fiddle with hub-side setup. I built PositionGuard because I wanted presence that survives a real family — mixed iPhone and Android, people who will absolutely not maintain an app for your automations' sake.

This is the native Hubitat integration: a parent app plus a child driver, one presence device per family member, installable through Hubitat Package Manager.

How it works

Your family members install the PositionGuard app (iOS or Android) and join your group — that's their entire involvement, ever. On the hub, the parent app polls the PositionGuard API with a key you mint, and creates one child device per member. Each device gives you:

• presence — standard PresenceSensor capability, present / not present

• currentArea — which named area they're in ("Home", "School", "Grandma's"), away if in none, unknown if they've paused sharing

• areaSince and sharingStatus

The one thing to understand before your first rule: presence and currentArea are deliberately different signals. presence is binary and maps to ONE designated area per member (default "Home", configurable per device) — that's what dashboard tiles, HomeKit/Alexa bridges, and presence-based apps see. currentArea is the full picture — use it in Rule Machine for anything multi-area ("if Mom is at Home OR the office"). Custom attribute triggers handle it fine; no extra devices needed.

Pausing never looks like leaving. If a family member pauses sharing, their presence freezes at its last value, currentArea goes to unknown, and sharingStatus tells you why. Nobody's "left home → arm the alarm" rule fires because a teenager toggled sharing off. False departures are the thing that makes people stop trusting presence automations, so the integration treats this as a hard guarantee.

Privacy, concretely: the hub receives area names only. GPS coordinates never reach Hubitat — the app deliberately never calls the one API endpoint that contains them, raw responses are never logged, and there is no coordinate data in any attribute, event, log line, or state variable at any log level. Your hub knows "Sarah is at School," never where School is or the path she took. Members control their own sharing and can pause anytime.

It composes with everything downstream. Because members are plain native presence devices, they flow through anything Hubitat already bridges — Dashboards, Rule Machine, Echo Speaks, HomeKit — with zero extra setup. I run the Maker API → Home Assistant bridge myself and the same devices show up there too.

Example: have the house announce when your kid reaches school

Install

1. Family side: members install PositionGuard and join your group — iOS on the App Store (23 countries), Android on Google Play (open beta, US & Sweden so far). No hub involvement for them.

2. Mint an API key at dev.positionguardai.com.

3. Hub side: install via HPM (search for PositionGuard, or "From a URL" with the packageManifest link in the README), or manual paste — driver first, then app. Add the app, paste your key, pick your groups. Members appear on the next poll.

Full walkthrough, Rule Machine examples, and the attribute reference are in the README: GitHub - positionguard/positionguard-hubitat: Privacy-first family location for Hubitat — area-level presence, no exact coordinates. · GitHub

Status: v1.0.0, open source. My own family has run PositionGuard daily for a long while — across two continents, on both iOS and Android. The Hubitat integration is the newest surface and I'd genuinely like to hear what breaks, what confuses, and what presence automations you'd want that this doesn't enable yet. It does depend on the PositionGuard hosted service (presence syncs through the cloud — if local-only is a hard requirement, fair enough). Free for a typical household.

Support: GitHub Issues and Discussions on the repo — or right here, I'll be in the thread.

— Christer

[dstutz]

@clundin1

WiFi presence broke when iOS and Android started randomizing MAC addresses

Don’t want to crap on your effort which is way more than just this one thing, but on this point, it’s pretty easy to turn this off (at least on Android).

The rest of the app looks really cool!

[SuperDupe]

This looks great and I’m definitely going to test it! Here is a basic question, I might be able to figure out on my own but thought I’d ask.

I have multiple hubs at multiple locations and use some basic rules for arrival, departure from those locations. Is the app / configuration able to set multiple present / not present locations or do I need to reconfigure the rules based on areas?

[sburke781]

Are your hubs meshed?

[SuperDupe]

Yes and no. For what we are talking about here, they are at different physical locations so I still use HubConnect to pass info. But for presence rules, it is localized to that hub and I’m using a variety of presence options tied together with the Combine Presence app…

[sburke781]

I guess what I am wanting to know (asking) is whether local presence is likely to be reflected across all locations…. Which, now that I think about it… is pointless…. ignore me…

[SuperDupe]

I’m going to install it and test it… Where I was going is it sounds like once you install the app on your phone, there is one location that is present or not present, but the app will show you in other areas. So if a family member is arriving at different locations where I have hubs, it may or may not show present / not present except for the one location designated… Not necessarily a hub thing, but an app thing on the phone…

I’ll install it later today or tomorrow and see what I find…

[sburke781]

Something I am certainly interested in… I had started to look at connectivity to a whitelist of Wi-Fi SSID’s as being “work” locations or “alternative” locations…. I would be interested in the potential use cases people may have for something like this, including GPS locations…

[clundin1]

Fair point — you can absolutely turn it off per device on Android (and per-network on iOS). Where it broke for me was the family-scale version: keeping it off on every person's phone, surviving OS updates that re-enable it, plus guests' devices — herding cats. That's really the design goal here: nothing to maintain on anyone else's phone. And thanks — appreciate the kind words!

[clundin1]

You've got it basically right, with one detail that makes it nicer for your exact setup: the "which area counts as present" choice is a per-member preference on each hub, not in the phone app. So if you run the integration on both hubs (same or separate API keys — either works), Hub A can designate "Vacation Home" as its present area while Hub B designates "Home," and each hub's presence rules keep working locally, unchanged. And for anything fancier, every member device also carries a currentArea attribute with the actual named area — Rule Machine can trigger on that directly, so "arrived at any of my locations" doesn't need presence at all. The phone app itself shows everyone across all areas regardless. Would love to hear how the multi-hub setup goes — that's a configuration I haven't seen in the wild yet.

[clundin1]

That's an interesting angle — essentially WiFi presence done from the phone side, where it can actually work, rather than the hub sniffing MACs. Today areas are GPS-defined named zones, but "connected to SSID X = at Work" as an additional signal is worth thinking about. Mind if I log it as a GitHub issue with credit so it doesn't get lost in the thread? Curious what use cases you had in mind beyond work/alternative locations.

[danabw]

FWIW, other integrations use Wi-Fi to debounce unreliable GPS status. One example is the community Owntracks integration that was created to replace Life360 when it went sideways.

Owntracks can be set up to use designated "home" Wi-Fi network(s) to maintain Present status at a location even if GPS coordinates are exhibiting short-term flaky behavior and the phone GPS thinks it has moved when it really hasn't. TL;DR: Wi-Fi can help w/this stuff in multple ways. Nice work here.

[clundin1]

Thanks! I hadn't looked closely at how OwnTracks handles this — using home WiFi to hold Present through GPS wobble is a clever approach.

PositionGuard tackles the same problem from the server side: transition handling lives in the backend, and the hub polls area state (once a minute by default) rather than receiving every raw transition — so short-lived GPS jitter typically never surfaces as a presence event on the hub. No per-phone tuning, and iOS and Android behave the same. From my own event logs, most false exits are GPS bouncing across the fence for under 30 seconds — exactly the window this absorbs.

WiFi as an additional signal keeps coming up, though — @sburke781 raised SSID-based locations upthread too — so I've logged it: WiFi network as an additional presence signal (SSID-based locations / GPS corroboration) · Issue #1 · positionguard/positionguard-hubitat · GitHub. Credit to you both.

[SuperDupe]

Good morning! Are the PositionGuard servers down? I added two phones last night and setup the HE integration… This morning, as I’m trying to add two more, I am getting an exceeded quota message on the phone. On my main phone that was added last night, it hasn’t updated in about an hour.

[clundin1]

Servers are up — this is something on my side limiting your account, and you're the first multi-hub, multi-phone setup in the wild, so you've likely found an interaction I need to fix. Digging into logs now; I'll report back here shortly. Thanks for the clear report — the timing and both symptoms narrow it a lot.

[SuperDupe]

Ok, I did set it up on two different hubs that are at different locations. I got two different keys, one for each location to be safe. Whats weird is I can’t even setup an account on the phone. When I enter the phone number at the beginning stages it errors out… How does it know this phone will be added to my setup?

[clundin1]

Quick update while I dig: your servers-down worry I can rule out — I've been through the logs against your account and not one request was rejected; both your hub keys have been polling clean the whole time (and two keys, one per hub, was exactly the right way to set it up).

To your question — it doesn't know, and that's by design. Each phone creates its own account first; nothing is pre-linked to your setup. You then invite that person into your group from your app, and they accept. The error you're hitting is at the phone-verification step during signup, before an account even exists, which is why it can't have anything to do with your member count. That one's on my side of the fence — chasing it down now and I'll post back shortly with what I find.

[SuperDupe]

Ok, thank you for looking into it! If it matters, all of the family phones use one Apple account, so the app was downloaded to each phone from that account… Not sure if it registers anything like that… Last night went pretty smoothly with the first two phones, just this morning, when I open the app on the new phone and enter the phone number, it throws the error… Anyway, I’ll keep trying…

And I like it so far! I would love to get rid of a bunch of different presence solutions I have been using…

On another note, for what its worth, I have found the SmartThings app does presence really good, so I have been using that and bringing it into HE through the HubiThings Replica app. However, Samsung has announced that free access to the SmartThings API will be phased out starting in October 2026. So the timing of your solution is really good. SmartThings allows you to setup different locations in the app by the way.

[clundin1]

Found it. When you sign in on a phone, the app verifies the phone number by SMS code — and my auth provider applies an anti-abuse throttle when several verification requests for the same number (or from the same network) come in close together. Setting up multiple devices in one sitting is exactly what that protection is built to flag, so it temporarily blocked further attempts. It's not an account limit and nothing is wrong with your setup — project-wide there's masses of headroom.

The block clears on its own: give it a few hours before trying again — tomorrow morning at the latest — one device at a time, and it should go through.

One thing worth checking first, though: if you're signing multiple devices into the same phone number, note that a number = an account = one member. For separate family members on your hubs, each person signs up with their own number and you invite them to your group from your app. If the extra devices are truly meant to share your identity, that's a different setup than the member model expects — happy to talk through what you're going for.

You keep finding the edges first — genuinely useful, keep it coming.

[clundin1]

Our posts crossed — the shared Apple account is a non-issue, good news: that's only how the app got downloaded. Sign-in is by each phone's own number, so family App Store sharing doesn't register at all. Which also means your setup is exactly the intended model — each family member's number becomes their own member, and you invite them to the group.

One small caution on "I'll keep trying": each blocked attempt can extend the cooldown, so waiting the few hours genuinely beats retrying. One device at a time after that.

And thanks for the SmartThings heads-up — I hadn't seen the October announcement. Really glad it's earning a spot among your presence solutions; consolidating that pile is exactly the job it's built for.