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
Yes. Each ‘branch’ in the tree needs a . between it. In each of those cases, you are directly accessing a property (or branch) under the previously expanded item.
You only need the numeric indexes when there is a ‘list’ of items (array) which in the raw JSON is indicated by square brackets. And you have to access those by their zero-based index.
No, there’s no meaningful difference for practical purposes here. The [0] format is the preferred format within expressions.
We still support the $variable.property.0.subproperty format for referencing global variables, but it wont always work with expression local variables, so it’s better to use the proper bracket format.
Is that the actual expression used? If so, it’s got a few issues.
On the first line, you are referencing the full variable, but not doing anything with it
On the second line, you are applying the title() function to the existing$CurrentCondition variable
If you wanted to take the description, title-case it, then assign it to your $CurrentCondition variable, that would look like:
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:
I’m getting an error, and looking at the logs, it seems the “h” is missing from the expression. Is this my problem? I replaced the expression with the above, but the “h” keeps getting removed.
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.
The rain field itself might be missing. Trying to access that field in your first line will cause the expression evaluation error. You would need to use the same type of isEmpty() check to see if that field exists or fallback to a default.
