IP Address Change trigger does not always work

420

Active member
I've been using this trigger for a while (as an alternative to the Wifi State Change trigger, that now requires location services to be turned on) and it works 95% of the time, but sometimes when i walk out of wifi range and wifi disconnects it just does not trigger at all... This is pretty annoying since it means that my phone thinks it is still at home, and it will speak things out loud in public :ROFLMAO:

From what i can tell the circumstances are exactly the same everytime, i just walk out of wifi range with my phone in my pocket..

Is anyone else having this same problem? Or does someone know what could be causing it and/or how i can resolve it?

Could it be that macrodroid is to busy with other things to pick up on the IP change or something?
 

420

Active member
Maybe it's actually a 'New IP Address Detected' trigger?
I'm not sure what you mean by that? That it would only trigger the first time it detects a certain IP?

That is definitely not the case because as i said it works 95% of the time :p
 

Pseudocyclic

Well-known member
I mean maybe it doesn't consider IP address to have changed until the changeover from 'old' IP to 'new' IP has been completed.
 

420

Active member
I mean maybe it doesn't consider IP address to have changed until the changeover from 'old' IP to 'new' IP has been completed.
I don't get it, howlong should/could this changeover take to complete?

95% of the time it just triggers right away as i walk out of wifi range, the other 5% of the time that i walk out of wifi range it does not trigger at all, even after several hours.

Also, when i notice that the trigger hasn't fired, i always test the action that writes the current IP to a variable and it has always changed, so i really think that the trigger does not always fire when the IP changes.
 

dsnz

Well-known member
I use this trigger too and it works 100%.

Maybe your mobile operator addresses and your home addresses are in similar range and often are the same ? (this should be ultra rare to impossible, mobile operators provide IP addresses in big ranges like 10.xxx.yyy.zzz and home IP addresses are usually in ranges like 192.168.1.xxx)

For me the most plausible scenario is that, your phone disconnected from wifi but your mobile wasn't authorized to use mobile internet (no more MB in mobile plan or some other reason) or could not connect to mobile service due to bad signal and so the IP did not change.

PS. a fact that is important in thinking of a scenario that explains the OP issue is that: the IP still changes even if the mobile internet service is available and authorized to use but the mobile internet is disabled in your quick settings
 

420

Active member
Does the IP Address Change trigger work reliably if you test while mobile data is disabled?
I just tried this (once) but the trigger did not fire at all, so no i don't think it works reliably :p

I use this trigger too and it works 100%.

Maybe your mobile operator addresses and your home addresses are in similar range and often are the same ? (this should be ultra rare to impossible, mobile operators provide IP addresses in big ranges like 10.xxx.yyy.zzz and home IP addresses are usually in ranges like 192.168.1.xxx)

For me the most plausible scenario is that, your phone disconnected from wifi but your mobile wasn't authorized to use mobile internet (no more MB in mobile plan or some other reason) or could not connect to mobile service due to bad signal and so the IP did not change.

PS. a fact that is important in thinking of a scenario that explains the OP issue is that: the IP still changes even if the mobile internet service is available and authorized to use but the mobile internet is disabled in your quick settings
Thank you for your time and good to hear that it works 100% of the time for you!

Yeah the IP's are definitely not similar/the same.

My phone is always authorized to use mobile data, and theres always more then enough MB, at most i use 25% of what i get each month.

I also think that bad signal is highly unlikely to be the cause, the network is very good here, and if this was the case shouldn't the trigger still fire when the signal becomes available again?

When i notice that the trigger has not fired while it should have i am still able to use the internet/receive notifications and everything, and when i manually test the action to write the current IP to a variable it is the mobile data IP, so the IP definitely has changed the trigger just hasn't fired.
 

dsnz

Well-known member
I think I know what happens and an experiment will prove it.
Change your macro so that the first action is "User log" where you will log the IP with timestamp and examine the log.

My idea is that since you don't use any wifi trigger, you have a state variable which you change on every trigger from IN HOME to OUT HOME and vice versa. But, this is not reliable. Just think what happens if you mobile internet connects once, then disconnects and finally reconnects with new IP ! (a very common thing with mobile service where there may be a few reconnects often). Or if it changes IP because it connects to a new mobile tower !

If you verify that this is the reason of your problems I suggest that in your home wifi you set it to use static IP and in your macro compare the current IP with this static IP to determine if you are IN HOME or OUT HOME.
 

420

Active member
I think I know what happens and an experiment will prove it.
Change your macro so that the first action is "User log" where you will log the IP with timestamp and examine the log.

My idea is that since you don't use any wifi trigger, you have a state variable which you change on every trigger from IN HOME to OUT HOME and vice versa. But, this is not reliable. Just think what happens if you mobile internet connects once, then disconnects and finally reconnects with new IP ! (a very common thing with mobile service where there may be a few reconnects often). Or if it changes IP because it connects to a new mobile tower !

If you verify that this is the reason of your problems I suggest that in your home wifi you set it to use static IP and in your macro compare the current IP with this static IP to determine if you are IN HOME or OUT HOME.
My home IP is not static but it doesn't have to be as it is the only wifi network i connect to with my phone.

Apart from the 5% of the time where the trigger doesn't fire my macro works reliably, i've been using it for months, works like this;

Set (string) variable - IP - [ip]

If - (variable) IP - contains 192.168.2. AND (boolean) At_home = false

Set (boolean) variable - At_home - true

Else if - (variable) IP excludes 192.168.2. AND (boolean) At_home = true

Set variable - At_home - false
 

tanutanu

Well-known member
I think I know what happens and an experiment will prove it.
Change your macro so that the first action is "User log" where you will log the IP with timestamp and examine the log.

My idea is that since you don't use any wifi trigger, you have a state variable which you change on every trigger from IN HOME to OUT HOME and vice versa. But, this is not reliable. Just think what happens if you mobile internet connects once, then disconnects and finally reconnects with new IP ! (a very common thing with mobile service where there may be a few reconnects often). Or if it changes IP because it connects to a new mobile tower !

If you verify that this is the reason of your problems I suggest that in your home wifi you set it to use static IP and in your macro compare the current IP with this static IP to determine if you are IN HOME or OUT HOME.
I think it good idea.
Even if DHCP environment, it is easy to add static IP address assignment to the router with the device MAC address.
 

dsnz

Well-known member
well.. the only plausible idea remaining is that MD is in deep sleep and can't respond

however the best resolution can be done by OP, when he discovers that the phone at_home variable is wrongly true to examine the phone setup, the current IP and also the IP changes in user log (and compare to system log too as extra verification) in relation to his movement timeline and determine what's happening

if the resolution is that the trigger definitely did not fire when it should then it's due to deep sleep and there are many posts about how to handle this
 

420

Active member
well.. the only plausible idea remaining is that MD is in deep sleep and can't respond

however the best resolution can be done by OP, when he discovers that the phone at_home variable is wrongly true to examine the phone setup, the current IP and also the IP changes in user log (and compare to system log too as extra verification) in relation to his movement timeline and determine what's happening

if the resolution is that the trigger definitely did not fire when it should then it's due to deep sleep and there are many posts about how to handle this
I always examine the phone setup when i notice the trigger hasn't fired, as i said when i manually test the action that writes the current IP to a variable it will be the mobile data IP, also the macro with the IP adress change trigger will say last invoked X amount of time ago (corresponding to the last time i arrived home and my IP changed), so i'm 100% sure that the trigger did not invoke without checking the entire log.

I will see what i can find about this deep sleep, i do have all batery optimization disabled though and macrodroid is set as device administrator.
 

MacroDroidDev

Administrator
Staff member
The code to get a local ip address is a bit wacky and it is possible that at some point the ip address cannot be obtained. In this case the trigger will not fire. So if for any reason your ip address changed but MacroDroid couldn't determine your new local ip then you would see the behaviour you are witnessing. If you can create a good test macro where you log the reported IP address regularly then please send that via report a bug in the troubleshooting section and point out at what time it failed to fire. I can take a look through this and try and figure out what might be going on.
 
  • Like
Reactions: 420

420

Active member
The code to get a local ip address is a bit wacky and it is possible that at some point the ip address cannot be obtained. In this case the trigger will not fire. So if for any reason your ip address changed but MacroDroid couldn't determine your new local ip then you would see the behaviour you are witnessing. If you can create a good test macro where you log the reported IP address regularly then please send that via report a bug in the troubleshooting section and point out at what time it failed to fire. I can take a look through this and try and figure out what might be going on.
Ok, i've created a macro that logs the current IP whenever the IP adress change trigger fires, and also at a regular interval of every minute.

When it happens again this log should show that the IP has changed in the last minute and that the IP adress change trigger did not fire.
 

dsnz

Well-known member
from the MDdev description it's that MD cannot get the IP address correctly (this is what I understand) so you should log the IP address not only using MD magic variable but in other way too (eg. shell script or other app)
 

420

Active member
from the MDdev description it's that MD cannot get the IP address correctly (this is what I understand) so you should log the IP address not only using MD magic variable but in other way too (eg. shell script or other app)
Hmm, maybe... From what i understand the problem is with the trigger and not with the magic text, i will let this run a couple days first to see if it can catch it before i download yet another app, i don't know how to get my IP with the shell script.. :p
 

Jacob L

Moderator (Lawsonator)
Hmm, maybe... From what i understand the problem is with the trigger and not with the magic text, i will let this run a couple days first to see if it can catch it before i download yet another app, i don't know how to get my IP with the shell script.. :p
ifconfig
in shell script action, maybe use interval for trigger or connectivity change such as wifi
 
Top