Refresh location
- Thread starter SolaFide
- Start date
Are you using the old legacy location triggers or the newer geofence triggers? I think geofence triggers are coming from the "Google black box" and have much less configuration options. Geofence triggers have the update rate in the specific trigger but based on my experience it doesn't seem to change the trigger behavior. Maybe the location refresh doesn't work anymore as it was meant to be used with the legacy triggers.
@MacroDroidDev or @UndeadCretin could shed some light to this issue about the two types of location triggers in MacroDroid.
@MacroDroidDev or @UndeadCretin could shed some light to this issue about the two types of location triggers in MacroDroid.
I have, no avail.
Pseudocyclic
Well-known member
Try setting the update time to the munimum and then test the macro while you also have Google Maps running.
Geofence uses Google Play services and will update when it feels like it. The value passed in is a suggestion and then Google will do what it likes (as normal). The location trigger uses my own implementation and will (Attempt to) update as frequently as it is selected.
Hi all.
I've been using MacroDroid for a while now. Amazing app.
I have set up a few macros that work pretty well.
I have searched and read the other Geofence and Location trigger threads to try to understand and workaround these triggers. I have several geofences set up, and have several macros that run depending on location. These zones get tested and set up a global variable (simple true/false) that is used to either trigger or constraint other macros.
I was using Geofence and made a copy of these macros to test Location triggers after reading the Dev explanation because of inconsistency. In my case the problem may not be Geofence or Location. What I found is that MacroDroid will test all these zones or locations in a certain order, and the global variable might end up being false if a zone gets tested after the one the phone is in. Something like...
Zone 1 test: false -> Global variable= false.
Zone 2 test: true -> Global variable= true <-- phone is here, some macros run because of this
Zone 3 test: false -> Global variable= false <-- macros no longer run because this location was tested afterwards (as "area exited")
So the question is: what is the best way to let MacroDroid set your location if you have to test several zones? I have tried this in different ways: all zones "entered" or "exited" as triggers, and actions with these as constraints; "entered" zones as triggers in one macro and "exited" zones in another macro, etc; but the ultimate problem is the order in how these get tested. How to set up a logic of just "inside or not" an area, instead of testing if you "entered or exited" every defined area?
Hope it makes sense.
Thanks in advance.
I would suggest you combine the geofence trigger with (new) location constraint to create whatever logic you need, for example:
T -> Geofence Zone 1
| - Constraint not in Zone 2.
Or similar, you get the idea.
Just something you said raises alarm bells. "macros no longer run". This is not how MacroDroid works. The actions run when the trigger fires and there is no such concept of a macro being running beyond this(Unless you are talking about persistent loops etc. which in this case is not relevant).
T -> Geofence Zone 1
| - Constraint not in Zone 2.
Or similar, you get the idea.
Just something you said raises alarm bells. "macros no longer run". This is not how MacroDroid works. The actions run when the trigger fires and there is no such concept of a macro being running beyond this(Unless you are talking about persistent loops etc. which in this case is not relevant).
Hi.
Thanks for the feedback. Really appreciate it.
Well well well... I never tested "location" as a constraint and it is actually the logic I was after: "inside or outside" some area (or all areas) instead of "entered or exited" some area (as in a position change logic).
As I said, I changed the macros to use your own implementation and now everything works the way I want. Just perfect. Location as a constraint opens up new possibilities because of the logic it implies. GREAT!
I'm sorry about the "macros no longer run" misconception. What I meant was that they don't run (execute) because of the location test result, nothing more. The thing is that after reviewing the system log, I found that Geofence would update inconsistently (and later confirmed by your comment in this thread) and test every geofence set up, so the phone might be in a second defined geofence by the time the location updated and this was the problem:
The global variable was set to false if the phone was outside any area, set up as trigger "exited area". Then the system log showed that "entered area 2" (where the phone was) would set the variable to true correctly, and then immediately evaluate "area 1" as "exited area" effectively setting the variable back to false. I hope this makes more sense.
Best regards.
Thanks for the feedback. Really appreciate it.
Well well well... I never tested "location" as a constraint and it is actually the logic I was after: "inside or outside" some area (or all areas) instead of "entered or exited" some area (as in a position change logic).
As I said, I changed the macros to use your own implementation and now everything works the way I want. Just perfect. Location as a constraint opens up new possibilities because of the logic it implies. GREAT!
I'm sorry about the "macros no longer run" misconception. What I meant was that they don't run (execute) because of the location test result, nothing more. The thing is that after reviewing the system log, I found that Geofence would update inconsistently (and later confirmed by your comment in this thread) and test every geofence set up, so the phone might be in a second defined geofence by the time the location updated and this was the problem:
The global variable was set to false if the phone was outside any area, set up as trigger "exited area". Then the system log showed that "entered area 2" (where the phone was) would set the variable to true correctly, and then immediately evaluate "area 1" as "exited area" effectively setting the variable back to false. I hope this makes more sense.
Best regards.