Prevent "HTTP Request" Exception

[Hans-Stefan Suhle]

Dear all,

I wrote a tiny script which reads out BatteryLevel and DisplayState (every minute) from my cell phone and sends both values to my Home Automation System (via http request).

Once a day, my Home Automation System is unavailable for approximately 3 minutes.

Now, whenever my Automate Script tries to submit its data during these 3 minutes, it stalls with Error: "java.net.ConnectException: Failed to connect to /192.168.xxx.yyy"
 and bails out.

How can I prevent the script from failing?

I'd rather let it ignore the error - and keep going

What is the magic trick, here?

Thank you kindly for your help!

[narf...@gmail.com]

The Failure Catch block is what you're looking for. With it you can retry a given number of times before giving up. In this case you'll also want to use a Delay block to wait between retries as well.

All HTTP Request blocks need to be coded with this pattern; protected with a Failure Catch in case of network error, delay during the retry, check the return status for a 200 response.

[thec...@gmail.com]

I use a subroutine block for http requests, as if will return the status code to the originating fiber.  If there is exception the original fiber continues and status code will be undefined/null

[narf...@gmail.com]

It's nice to use Failure Catch and encapsulate a retry in the Subroutine instead of its client code though. Often a request will succeed after a network exception. I also happen to have a super fancy HTTP Request subroutine that can take request headers, launch separate fibers to do multiple requests simultaneously, and then coalesce the results. 😁

[Hans-Stefan Suhle]

Thank you for this hint.

As you have already developped such a subroutine - would you be willing to share?

Kind regars!

[Hans-Stefan Suhle]

There is a very good example in the Automate Community Flows which I could use to catch the error.

Thank you all for your great help!

Topic solved

Kind regards,

[narf...@gmail.com]

My multiple parallel HTTP request subroutine is in this flow:

https://llamalab.com/automate/community/flows/25025

Setup starts around block 229. It'll automatically retry on network exceptions or "busy" return statuses, and let you supply request headers and default error messages. When a service error occurs, it returns the message from the service back to the caller of the subroutine.

To use it, you set the service endpoint(s) in the serviceEndpoints dictionary variable, keyed by the endpoint URL. Each entry is al dictionary with optional "headers" and/or "error" entries. The latter is a default error message specific to that service if you wish. After invoking the subroutine, you check serviceEndpoints[forecastEndpoint]["error"], and if it contains a value, there's been a service error that couldn't be recovered from.

It's way overkill for most applications, but it vastly sped up another flow I wrote. That flow can generate arbitrarily large numbers of requests, so to be a good citizen it has additional logic to limit how many are in flight at once and not overwhelm the service:

https://llamalab.com/automate/community/flows/26815