First of all, thanks to Athom for cleaning up bugs in the internal Homey presence (Android app) right before Christmas. In the process, I suspect that the time delay was removed for setting home and away status based on GPS position. Probably with the best intentions. However, this causes issues as many live in tight streets or drive along roads where you briefly enter and exit the GPS “home zone” for a short while when going places in the neighboorhood with car, e.g. shop, school nearby, resulting in for instance lights going off and on quickly due to unintended home/away switching (even doors unlocking and locking for those who have that implemented). I think it would be useful if we could define the delay for “away and home” in the Android app (would like something between 3-5 minutes) or at least get back the delay that was in the app before the December Android fix (which was a tad too long maybe 5-10 minutes). Do you guys agree or know about a workaround? I could of course add a timer to all home and away-based flows, but that would be a hacky workaround (which would cause issues because certain actions should take place rather fast when I get home etc.). I am aware that I should consult Athom about this as this is a user forum, but just wanted to hear if others have experienced the same after the December Android update and agree upon the suggestions before posting a ticket with Athom. Any suggestions are welcome.
Yes, intuitively that could make sense. However, that will not stop Homey in jumping forth and back into home/away mode (which floods the timeline). The GPS-detection of home/away statuses is to the best of my knowledge not possible to influence by flows. Also many of us, including myself, have plenty of flows related to home and away statuses (as triggers), which would cause plenty of timers launched in parallell putting unnecessary load on Homey. Then I have not mentioned that this approach would also cause unnecessary many extra flows in order to deal with starting and stopping timers (alternatively many additional parameters in advanced flows). I guess the core point is that this used to work nicely and was not an issue before the Android mobile app December fix, and we should not need to create work-arounds which will not solve the entire issue anyway.
Nope, there never was. That was my humble suggestion to solve the issue. An alternative is the ability to adjust/decrease the size of the built-in geofence (or even both).
What used to be there though was a default delay of about 10 minutes which made sure that away/home moduses did not activate in a jo-jo fashion when you quickly enter/exit the relevant home/away GPS-zone. I am aware of alternatives/supplements such as Smart Presence (already use that one as a supplement to the internal Homey one), but both used to work satisfactorily. For different reasons I do not want to rely on Smart Presence alone.
I have never heard of this either, and have been using Homey since 2019, but with Apple smartphones.
It would also not make sense to use a 10 minute delay. The geofencing range of the Homey smartphone app is probably somewhere between 300 and 500 meters. So if I reach the geofencing area by car coming from out of town, I’ll be home in 30 - 60 seconds. Then Homey would only recognize me as home after 9 minutes? That makes absolutely no sense.
I can absolutely understand the problem you describe. I also recognize this as a problem from time to time. But that’s how geofencing works.
As Joreon already suggested, you can add a timer to flows and a second trigger, e.g. the Smart Presence app.
Another possibility could be an NFC tag on the front door, on the apartment door, on the garage, with which it could verify the “home” status (within a certain time).
Or you use another geofencing app where you can set the geofencing area smaller, e.g. 50 meters (Homey apps: Location and Presence or Connect Life360). This is partly possible with other geofencing smartphone apps, for which there is no Homey app. If these apps can send WebHooks, then Homey can receive them.