Ok, got it… The phones are all on my same WiFi so that must be how its tying them together. I’m setting up individual accounts and using the phone number from the phone, not a singular number… 
Got up and first thing tried the third phone and got the error… So if it linked my two phones (separate numbers but same WiFi) from last night, this could get challenging for a family to setup say 4-5 phones having to wait a long time… Anyway to find out how long that time period is?
I disconnected WiFi on one of the new phones and it still didn’t work… Must have logged that number against further tries…
EDIT: If it was the home network (WiFi) tying it together, until that is figured out if its an issue, maybe detail an instruction to disconnect from WiFi and setup the phone on cellular?
Your experiments narrowed it well — and one detail matters going forward: each failed attempt also logs against the individual number, so retries can extend the cooldown. Counterintuitively, the fastest path is to stop trying the burned numbers until tomorrow. If any phone's number hasn't been attempted at all yet, that one would likely go through right now.
Exact duration isn't published — observed is a few hours to about a day. Unsatisfying, I know.
The bigger point stands regardless of the exact trigger: setting up several phones for a household in one sitting is a completely normal thing to do, and the verification provider's anti-abuse defaults clearly don't agree. Exactly which signals it keys on (same network, same timeframe, number patterns) isn't published, so I'm not going to guess — I'm investigating both the triggering and ways to reduce or skip the SMS step for legitimate signups. Meanwhile your suggestion is sensible either way: I'll add setup-doc guidance about staggering batch signups rather than doing them back-to-back.
I was able to add the two phones… I turned off WiFi and let them sit for a bit… Added them via cellular. I have two more to go later today and will do it that way also…
Quick note on the app… I messed with a custom setting on one phone. It was the custom privacy level in one of the areas. It will not turn off now. I deleted the app, reinstalled and have tried several things. It looks like it might be a bug… Anyway, I only messed with it on one phone and won’t try any of the others… The notifications on and off seem to turn on and off fine, but once I set that custom privacy level, it won’t turn off… No biggie as I just set it to the same level as global, but FYI…
I’ll keep playing with this but great app so far! Thank you again!
This looks pretty cool - good effort and thank you for sharing!
When might Android be expanded to other regions? I'm in the UK.
Glad it cleared — and cellular-with-a-wait is now the documented advice: I've added a note to the README's install section about staggering batch signups so the verification limits don't flag whole households. Thanks for finding the edge and suggesting the docs note.
And good catch on the custom privacy level — you're the first person I know of to exercise that corner of the app, and "won't turn back off" is a real bug, logged. Fair warning that some of the options in custom are ahead of the rest of the product (that surface is where future capability lands first), so the global level is the well-worn path today. Digging into the stuck state — the fact that it survives delete-and-reinstall is a very useful clue.
Keep playing — this is exactly the shakedown I hoped for.
I've just added the UK to the Android open beta — submitted for review a few minutes ago. I'll post here as soon as it's live on Google Play. (iOS is already available in the UK.)
Not sure how useful it may be here… But thanks for the kudos… My use case is a little different and I actually haven’t developed it, if I’m honest… I have, at different times been developing a Tasker-based setup for Android mobile devices that can allow both control of the device from HE (when on the local network or VPN) as well as reporting status information back to HE (that part I have developed). I also intend to add some local automation within the Tasker setup, which is where I would be most likely to make use of the alternate location detection. Things like setting a phone to Do-Not-Disturb when at work, but undoing that once you leave work or are at lunch. I am expecting PositionGuard would likely need to also implement features like this within the app on the device.
That actually composes with what you've already built, I think — no PositionGuard-side features needed. Your Tasker setup already talks to HE, and the PositionGuard member devices put currentArea on the hub — so "set DND when I arrive at Work, undo when I leave" is an HE rule keyed on currentArea that pokes your existing Tasker bridge. PositionGuard's role is deliberately narrow: be the reliable location signal; the automation engines (RM, Tasker) do the acting. The SSID-as-location half of your earlier idea is the part that belongs on my side, and that's captured in the GitHub issue.
@jason12 UK is live — Google approved it overnight, so the Android open beta should now show for you on Google Play. You're better positioned than I am to confirm it actually appears from the UK side — let me know if it doesn't for some reason and I'll chase it down.
I’m in the UK and have downloaded PG OK on my Pixel10.
I’ve installed the app ok and a child device has been defined.
The child device is saying I’m AWAY and NOT PRESENT.
In the app on my phone it can be seen that I am in my ‘Home’ area.
The issue I seem to have is that the app is asking me to ‘Allow all the time’.
When I click on it a new page opens with some instructions on it but I cannot scroll down to complete the tasks required. What ever I try the request remains on the ‘Home’ tab.
Any thoughts on how to get round this?
EDIT: I am seeing the 1 minute poll in the logs
Welcome — first UK install, hours after the region opened, so thank you for the timing alone. And your edit confirms the good news: the hub side is completely healthy — key, polling, child device all working. The whole chain is fine except one Android permission.
The Away/not-present while your phone shows Home is the permission issue in disguise: without "Allow all the time," Android blocks the app from reporting location in the background, so the hub only knows the last thing the backend heard. Grant it and the two will converge within a poll or two.
That stuck non-scrolling page is a genuine bug on my side (Android open beta earning its label) — logged, thank you. But you don't need that screen at all — grant it straight through Android: long-press the PositionGuard icon → App info → Permissions → Location → "Allow all the time", and check Precise location is on while you're there. Battery → Unrestricted helps reliability too. Once set, your hub device should flip to Home/present on the next poll — would love to hear it confirmed.
I have already done this as I know it needs this when using other apps.
I’ve also allowed ‘Use Precise Location’ and have Battery unrestricted set also for this app.
Not sure what else to try.
Thanks.
You're ahead of the checklist, so this is now a proper bug hunt — thanks for the detail. Two things worth trying, and one thing I'll do on my side:
First: force-stop the app and reopen it (App info → Force stop), or simply reboot the phone. If the background service started before the permission was granted, it can keep running in its old, restricted state — everything looks right in Settings but the running process never picked it up. This is the most common cause of exactly your symptoms.
Second, after the restart: does the app still show the "Allow all the time" prompt? If it does, even with the permission granted, that's the app's permission check misreading your device — a real bug I very much want to know about (Pixel 10 will be a new one for my test matrix).
Meanwhile I'm checking on my side
Following up on what I said I'd check: whether location reports from your account are reaching the server at all. The answer is very telling — exactly one report has arrived (right when you toggled your visibility), and nothing since, while your hub has been polling flawlessly every minute. So the integration and your setup are fine; the phone simply isn't reporting in the background, despite the permissions being granted.
My working theory is that the broken screen you found is the actual culprit: the app appears to gate its background reporting on completing that setup step, so granting the permission through Android Settings satisfied the OS but the app never got the memo — which is also why it keeps prompting you. That makes the un-scrollable page a real functional bug, not just cosmetic, and it's moved up my list accordingly.
Two things to try meanwhile: force-stop the app and reopen it (App info → Force stop) — on relaunch it should re-check permissions and may start the background service properly. And as a verification: with the app open in the foreground, your position should update within a minute or two — if the hub flips to Home while you're in the app but goes stale when it's closed, that confirms the theory completely. Either way you've pinpointed a genuine bug within hours of the UK opening — much appreciated.
Boom!!! Nailed it.
Did a reboot of my phone and all is now good.
No prompt asking me to allow the permisions and presence has changed to ‘Home’ and ‘Present’.
Now time to play and see how the reliability goes. 
Boom indeed — glad you're in! The reboot confirming it is really useful: it means the background service just needed a clean start after the permission landed, which pins down exactly what the app should be doing by itself (re-checking permission state on resume instead of waiting for a fresh boot). Fix is on the list with your name on it. Enjoy the playing — and reliability reports, good or bad, are very helpful! Thanks
I’ve defined my Home Area OK.
I just tried adding a new area, go through the set up and then ‘Create Area’ for the new area I’ve set up.
It doesn’t appear to save it.
Any thoughts?
Reproduced on my Android device — good find, and here's the reassuring part: your area was created; it just doesn't show up when added from that screen. If you add an area from within the group (open an existing group → add area there), it appears, I did do a refresh after, and works immediately — that's the reliable path for now. The standalone add-area flow creating something you can't see is a real bug, logged. Two genuinely useful finds in one day — thank you.
Pretty sure it does create it, but you need to add it to your family/group. I fell into that trap.
Thanks. Did that and all the rubbish areas that I was trying to define were there.
Added an area from within the group and could define it OK.
After defining a new one that way, all the other rubbish seems to have disappeared. (Which is good).
Thanks for the heads up @clundin1 @jason12