Better_forecast REQUEST_INPUT_ERROR

Developers
1

I have been getting the following error from the better_forecast:

{"status_code":3,"status_message":"REQUEST_INPUT_ERROR lat and lon are required"}

I make a call for the better_forecast using a node_red http node, sending the following url on the hour:

https://swd.weatherflow.com/swd/rest/better_forecast?station_id=*****&units_temp=c&units_wind=kph&units_pressure=hpa&units_precip=mm&units_distance=km&token=*****

The url is passed as a single string to the node and is the same for each call.

The call returns the above error approximately half the time, and the expected data the remainder of the time.

Interestingly, the likelihood of the is much higher when the call is made on the hour and much lower when the call is made 2 minutes past the hour.

Has anyone else observed this behavior?
Can anyone suggest how I could improve the consistency of the better_forecast response?

2

If the station_id parameter is missing or malformed you will get that response. How are you feeding the URL to your request, is it hardcoded with a station_id or is this passed in to some function to build out the url string?

The apps constantly make requests to the better_forecast endpoint and I’ve never experienced a failure like this. I also ran a test for over an hour where my personal token was hitting the BF endpoint every couple minutes and I haven’t seen the issue. I even had it hammer the api every couple seconds around the top of the hour and it never failed for me.

Can you private message me the source? I don’t mind taking a quick look to see if there is something going on with the URL.

3

Hi Corey,
The station_id is passed to a node_red function node which uses JavaScript to build out the url string.

msg.url = "https://swd.weatherflow.com/swd/rest/better_forecast?station_id=" + msg.weatherflow_station_id + "&units_temp=c&units_wind=kph&units_pressure=hpa&units_precip=mm&units_distance=km&token=" + msg.weatherflow_station_id_token;

The strange thing being that I cannot see any aspect that should change between subsequent builds of this url.

So to be as sure as I can be that the url is not the problem, I revised my flow to recall the better_forecast in the event of a status error. The subsequent calls use the previous url and have been successful to date (i.e. it has not taken more than one recall to get a valid forecast).

4

Have you looked at logging the message contents that are coming from node_red when there is a failure? I would be curious to see if maybe the station ID is nil when this occurs.

5

I have sent you a copy of the message content from the node_red http node separately.