Ways to find controller's external IP address using MSR
-
Just found this free API that will also give your WAN IP
-
Just found this free API that will also give your WAN IP
-
Maybe this is fair game to ask @toggledbits to include as native "system info" within MSR then, instead of rolling our own IP detection. After all, he's already pinging DNS servers to monitor Internet availability.
Answer: "Nope" (reasons below)
-
Yeah, but that's not really related; the fact that they are both network-based queries is about where the commonality ends. Pinging the DNS servers doesn't give me any information back other than that they are reachable, and that's not even done the same way (it's handled at layer 3 in the stack). I'm not making a DNS query to them (which would be up at the top layer 7). The ping is meant to be fast and speak only to the functioning of routing beyond the LAN, where a DNS query (or more correctly, a DNS failure) would require a lot more analysis to determine if a problem was a fault of the network layer, the service, the server, etc.
A DNS query is also not really going to expose your external IP. It has to route through it, for sure, but the DNS response packet itself contains only an answer to the question asked, which is typically "what is the A or AAAA record for <some name>?". The response contains only the answer to the question asked (it's one of <array of addresses>" or "I don't know"), and does not contain routing information for how either the query or the response moved. The only way to use DNS to get your external IP is if (a) your external IP has a name associated with it, (b) the owner of the domain in which the name lives has provided PTR records to provide "reverse DNS" data (map the name back to an IP address), and (c) you make a reverse DNS query for that name (which is not what's happening). That's such a "hail Mary" set of conditions in the real world (and requires user configuration when it is possible) that sites like ipify.org exist and are more useful.
-
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
