Upgrade advice - upgrade from aarch64 to ARM64 image

[cw-kid]

I can't work out why this existing rule now no longer works? It was a rule to get my current WAN IP address, store it in a variable and then send that value to the Multi-String device in Vera. The trigger was just a time based trigger to run every so often.

Set Reaction -

Temp Local Expression - This is empty and it shouldn't be.

The current IP value in the Global Expression "myIP" is also wrong and not up to date. If I press the Play button on the Set Reaction I get this error:

However the website https://ipv4.jsonip.com/ still seems to work fine and does show my correct current WAN IP address etc.

Thanks

[toggledbits]

@cw-kid The capture variable having a null value is a pretty indication that there was an error. You have the "Suppress alerts on HTTP errors" box checked, so you're silencing your first option for notification of an error on the request. But then, there could be another location...

[cw-kid]

@toggledbits said in Existing Rule stopped working HTTP command fetching IP address from website:

"Suppress alerts on HTTP errors" box checked

Sorry I didn't notice that, I unchecked it and saved the rule, now when I reset the rule the popup error box just says "The request failed" and I still don't get an actual alert in the status area of MSR with anymore detail.

Or if instead I press the Play button on the Set Reaction it then says:

Error: Command timeout (1782 start_reaction)
at _ClientAPI._commandTimeout (http://192.168.0.4:8111/client/ClientAPI.js:546:201)

But I can access the HTTP endpoint in my browser no problems on my laptop. I then SSH into the MSR box and tried to ping ipv4.jsonip.com at least and it does appear to reply from IP 34.160.111.145.

But it looks weird on the Debian MSR box, the ping reply it shows as:

from 145.111.160.34.bc.googleusercontent.com (34.160.111.145)

Where as if I just ping it from my Windows laptop it shows as:

from 34.160.111.145

I don't see the 145.111.160.34.bc.googleusercontent.com part what ever that is.

[cw-kid]

OK that's strange I just restarted MSR and the rule has started working again now. Its populated both the temp local expression and the "myIP" Global Expression and sent the correct current WAN IP address to Vera and the MultiString device. Maybe unchecking Suppress alerts on HTTP errors unblocked it. Dunno but its working now it seems.

[cw-kid]

Maybe there is something wrong with the HTTP end point, I am seeing these errors now in the MSR status area.

Reaction "GET My WAN IP Address<SET>" (rule-kmomxige:S) step 2 HTTP request failed
FetchError: network timeout at: https://ipv4.jsonip.com/
Last 10:30:28 AM

[toggledbits]

The endpoint has 15 seconds to answer by default (i.e. default timeout)... that's a long time for such a simple request. https://icanhazip.com is a popular choice for this purpose, apparently, and may be more reliable. Its response is plain text rather than JSON, but based on your use, that's more direct.

In any case, network errors are a fact of life, and requests will fail. If that's important to your process, error handling should be added (e.g. detect failed requests and skip changing the Vera variables).

[cw-kid]

@toggledbits > https://icanhazip.com

Thanks for the tip, I have changed the rule to use your suggested HTTP end point instead. Will see how I get on with that.

[cw-kid]

It seems to be working only issue is in the Global Expression "myIP" its adding a "\n" to the end of the WAN IP address for some reason. Like: Current value: (string) "10.20.30.40\n".

[toggledbits]

In your x_vera_device.set_variable action, where you have the substitution ${{ myIP }}, change it to ${{ trim(myIP) }}

Ref: String Functions

[cw-kid]

@toggledbits said in Existing Rule stopped working HTTP command fetching IP address from website:

${{ trim(myIP) }}

OK done that. I am still getting an error with that new HTTP end point:

Reaction "GET My WAN IP Address<SET>" (rule-kmomxige:S) step 2 HTTP request failed
FetchError: request to https://icanhazip.com/ failed, reason:
Last 2:05:16 PM

My rule now looks like this:

[toggledbits]

Best add some error detection, then.

[toggledbits]

Here's another one that is very likely to not have significant downtime: https://checkip.amazonaws.com/

If you still get errors with this one, I suspect your local network or something off with the configuration of your host.