Ways to find controller's external IP address using MSR
-
This trigger isn't working for me. I am getting a lot of false triggers where its saying my WAN IP address has changed when it hasn't.
Sometimes it's showing a value of
${{ myIP.ip }}
And then the rule fires suggesting the WAN IP has changed when it hasn't.
I need the "changes" trigger to only trigger if its validated more than once or over a period of time, that the actual WAN IP address has changed and its not some blip or problem or slowness with it working out what the WAN IP really is.
-
Good catch. Sounds like some other condition is called for, which either inspects the contents of myIP.ip for a suitable RegEx match (e.g. digits and dots) or verifies that the contained value is not NULL, or at least different from the literal ${{}} you experienced.
-
That non-substituted value means that the expression failed. Check the log. I suspect that the query is failing from time to time, resulting in no data to
myIP. That would also be in the log. The query failing will clearmyIP, and that would makemyIP.ipthrow an evaluation error.This would be a good use for the
?.operator:myIP?.ipwill returnnullif the fetch fails andmyIPgets cleared, rather than throwing an error. You can then test for that null. -
I've changed the rule to use "myIP?.ip" instead that seems to still work OK and my current WAN IP is brought down from the online API request.
As for the false triggering when the query is failing from time to time, I tried setting the trigger "for at least X secs"
Expression Value: ip changes from 11.222.333.444 to (any) for at least 360 secs
However this doesn't seem to work at all. I turned off my VPN and the WAN IP address changed, the rule that checks for the IP worked and the global expression contains the new IP address.
However the other rule that is meant to trigger on expression value changes from specified IP to any other IP / value never fired.
So I am not sure what is the best way to setup this trigger, so it works and doesn't false fire if the expression value goes to null / the http request query didn't happen to work that time.
-
I was going to suggest the ol' "Sustained for __ seconds" trick, so glad you landed upon the same solution. Unclear why something would "stop working" just because of that. Have you checked the Logs? And is the secondary Rule enabled?
-
The changes operator produces a pulsed output (otherwise you would never be notified of two or more changes sequentially). A pulsed output cannot be "sustained", because it only ever lasts 10ms or less.
Since you are testing "changes from expected to anything else", that's really not logically different from "not equal to expected". Use a plain equality/inequality. That will produce a sustained output for which the sustained for restriction can be used.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
The changes operator produces a pulsed output (otherwise you would never be notified of two or more changes sequentially). A pulsed output cannot be "sustained", because it only ever lasts 10ms or less.
Since you are testing "changes from expected to anything else", that's really not logically different from "not equal to expected". Use a plain equality/inequality. That will produce a sustained output for which the sustained for restriction can be used.
OK thanks that makes sense.
I will not use "Changes" then in the trigger.
Instead I will try <> NOT expected value (IP address) and use a sustained for X secs.
-
On my end I'll tighten up the UI so that option can't be selected when the changes operator is used.
-
T toggledbits locked this topic on
