IP Address Change trigger does not always work
- Thread starter 420
- Start date
I just left my house for a couple minutes and the IP adress change trigger failed to fire again, both when i left and when i arrived home, my macro that logs the magic text IP every minute managed to catch it both times.
I already reported it via report a bug like you asked but i was unable to attach a screenshot to it and this custom log clearly shows the time windows in which it failed to trigger so i just thought i'd post it here.
Attachments
Thanks for the bug report. I am going to tweak this trigger a little for the next release to try and make it more robust. I can't recreate the issue myself but I have some ideas of things that may help.
Eigenvector
New member
Hi 420,
first of all thanks for thread. Using IP change without the need to keep location On - that's a beaut. In theory, tho. Because I can confirm that reliability on IP change is not great. I'm testing this now for over a week, with 2 phones simultaneously on different mobile networks. Leave home in the morning -> change wifi/mobile date, then enter work place -> change mobile data/wifi. And vice versa in the evening. Triggers sometimes on both phone, sometimes on one phone, but not the other, sometimes not at all, sometimes up to an hour late etc, without any distinct differences between phone model or network provider. Completely random.
However, when I test the IP change trigger by manually toggling wifi on and off, it triggers always and more or less instantly. But not when I leave wifi enabled and just walk out of range. So I tend to believe, it's not that IP change doesn't trigger the macro, but that IP change from Wifi to data is not registered correctly or not promptly when Wifi is enabled. This must be Android specific (both my phones run Android 10) or Macrodroid specific. And not a matter of your IP provider (or your macro settings/constraints)
Cheers.
first of all thanks for thread. Using IP change without the need to keep location On - that's a beaut. In theory, tho. Because I can confirm that reliability on IP change is not great. I'm testing this now for over a week, with 2 phones simultaneously on different mobile networks. Leave home in the morning -> change wifi/mobile date, then enter work place -> change mobile data/wifi. And vice versa in the evening. Triggers sometimes on both phone, sometimes on one phone, but not the other, sometimes not at all, sometimes up to an hour late etc, without any distinct differences between phone model or network provider. Completely random.
However, when I test the IP change trigger by manually toggling wifi on and off, it triggers always and more or less instantly. But not when I leave wifi enabled and just walk out of range. So I tend to believe, it's not that IP change doesn't trigger the macro, but that IP change from Wifi to data is not registered correctly or not promptly when Wifi is enabled. This must be Android specific (both my phones run Android 10) or Macrodroid specific. And not a matter of your IP provider (or your macro settings/constraints)
Cheers.
For me it is pretty reliable it has only failed to fire once since my last post here, i also added a macro to catch it incase the ip change trigger fails
but that one is really specific for me and probably won't work for you (i have it write the IP to a variable every 10 seconds for 2 minutes after my front or backdoor closes, this is still not perfect because in theory i could be right outside my house for 2 minutes before actually walking out of wifi range but so far that hasn't happened)
I'm no longer using the test macro that wrote the ip to a variable every minute but that macro has been 100% reliable for me, so maybe you could do something like that.. maybe every 5-10 minutes instead of every single minute if you are worried about battery consumption.
Eigenvector
New member
My IP macro has no constraints, that is, no specific IP settings need to be satisfied. It should trigger any time everywhere and regardless of current IP address. All it does, is switching Location On. Then invoke another macro (with otherwise empty trigger) that tests whether I'm connected to trusted network (yes -> no action, no -> change mode etc), then switches conveniently Location Off again. I've checked the activities logs, and fairly often IP change has not been recorded. Interestingly, it seems hardly ever working in the morning and reasonably reliable in the evenings. Might have to do with the weather...hazy in the mornings this time of the year, and clear in the evenings?!? Bizarre...
I should mention that I'm always in VPN. Perhaps this tempers with the detection of IP change? Though, toggling VPN on and off never triggered the IP macro. Which makes me wonder about my VPN provider, but that's beside the point.
I'm playing around with geofences, too, but they appear to be even more unreliable than the IP change.
Tests continue.......
I should mention that I'm always in VPN. Perhaps this tempers with the detection of IP change? Though, toggling VPN on and off never triggered the IP macro. Which makes me wonder about my VPN provider, but that's beside the point.
I'm playing around with geofences, too, but they appear to be even more unreliable than the IP change.
Tests continue.......
tanutanu
Well-known member
VPN on/off doesn't causes your ip adress basically. It is working same as proxy though.
Geofence is reliable if yor device can reach one of location data sources. If not, follow the instruction of dontkillmyapp.com. The background services of MD might be killed.
Eigenvector
New member
Ref Geofence: for test reasons, I've set up a macro to force location update (every 3 minutes, easily before my phone kills any apps, if indeed it does), then run another macro that is constraint by being inside the particular geofence. Looking at my system log, that constraint macro never triggered because the constrain always fails - supposedly I'm not inside the geofence. When I check the blue dot on goggle map, then it sits exactly where the pin drops in my geofence definition. So, clearly, I'm inside. Also, the location update coords (long/lat) correspond. And still, the activity log constrain "inside geofence" failed.
What I also see in the logs, a lot of lines in white "DISABLE GEOFENCE", "ENABLE GEOFENCE" (-Update rate etc). And about 1 sec later "Geofence event: Home Status = outside", with a fused location about 5km away. It is always exactly the same location, and on both my phones. Anytime I switch Location On, the blue dot initiates on the other side of town. So, I assume it's the location of the provider, or cell tower (even though the 2 phones operate on different networks). I guess now, any time the Geofence Event happens, milliseconds after the system "enables geofence", I'm 5km away from where I'm really are (unless I opt to venture out to find this mysterious signal). Any thoughts how to circumvent this?
As I said in another thread that I've posted yesterday, the geofence entry/exit triggers do fire occasionally, but really only occasionally. 1 out of 10, perhaps. And on both phones equally randomly (just as the IP change triggers sometimes and sometimes not, tho that trigger fires rather 8 out of 10, so - still better)
tanutanu
Well-known member
The location data reliability is different country by country, area by area. I think it a little worse in Europe, South and North America even I'm in downtown.
One another suspicious thing is that your background services are killed by OS task manager. I'm not sure which service, only MD's and the reason exactly. Because it depends on your preferred settings of OS and a specific customization of the manufacturer.
dorothymulinix5
New member
I contacted customer support about this issue, and they told me they were aware of the problem and working on a fix. In the meantime, they suggested I use the "Check for IP Address Change" action instead of the trigger. I did that, and it seems to be working. However, it's a bit of a hassle to remember to check for an IP address change every time I want to use my VPN, and that's why I moved on to residential proxies from https://soax.com/iran-proxy. I hope that the fix for the trigger will be released soon.
Last edited:
LaurenWelchat
New member
My friend, in such cases, changed the Ip address by reconnecting to the ISP, or rebooting the router, until he got tired of it. Searching the web found a script needed to reboot the router and, after a little bit of fiddling, configured it to reconnect to the ISP without rebooting. He also found routeriplogin.com, which lists routers' local IP addresses. This was a good time-saver. The attached archive must be unpacked into a folder to use the script. In the file "ISPIPchange1," you had to change the data in the comments to your data with a text editor. (IP of the router, login, password). After the configuration, you had to run the file "ISPIPchange.bat."
Last edited: