If you’re unfamiliar with JSON paths, this is a really good tool for better understanding things. You can paste your JSON response in the panel on the left and it displays a tree on the right that you can navigate. Each ‘branch’ you click on expands and updates the path… then when you click on a ‘leaf’, it shows your full path.
As @Nezmo mentioned, some APIs can be a bit trickier than others as they’ll return different values based on the time of day or even what data is available that day.
In that case, you have a few options depending on what data is available and what your goal is.
For example, if the current.rain.1h is only available when there’s actually rain, you could conditionally determine if you read that value or use a fallback. From what I’m reading, it sounds like current.rain is always there… it’s just that the 1h subproperty isn’t set if there’s no rain – is that what you’re seeing? If so, something like the following should work
I would take a look at the following HTTP Action Troubleshooting guide:
Especially since you are using variables in the URL, I would check the Rule Logs to make sure that the correct URL is being called.
I would also check the raw $context.response.data to see what response body you are getting and snapshot the $context.response.status for troubleshooting to make sure you are getting a valid response code.
I can see in my rule logs that the URL is exactly what I would expect it to be.
I would make sure that the variable has exactly what you expect in it. No less. No more. In other words, you want to make sure there aren’t any spaces or any unexpected characters.
Looking back at your original post where you were asking about being able to inject a variable into a URL, it looks like the sample format string you provided has a space at the end of it, so you’ll want to make sure that doesn’t exist otherwise you’ll get a space in the resulting variable and that space will ultimately get included in the URL as well:
If I remember correctly, the Open Weather API does not always include a rain field. In that case, you would likely want to use the same type of approach you are using with the isEmpty() check and using a fallback as needed… perhaps in multiple steps.
Well, I was… It was in the JSON path finder. Looking back at the history, we’ve not had rain in the last 2 hours, so it does not appear now. I added the [“1h”] for future, but my current fallback does not seem to handle the missing field.