Http binding: items don't receive values although JSONPATH is correct

Hello community,

I tried to setup the fire index information from swedish SMHI (SMHI Open Data API Docs - Fire risk Forecasts) to fill some items with relevant indexes.

The .things file looks like this:

Thing http:url:fireRiskForecast "SMHI Fire Risk Forecasts" [
	timeout=5000] {
			Type string : fireRiskIndex "Brandrisiko" [ stateTransformation="JSONPATH:$.timeSeries.[0].[?('fwiindex')]" ]
			Type string : grassFireRisk "Grasbrandrisiko" [ stateTransformation="JSONPATH:$.timeSeries.[0].[?('grassfire')]" ]
			Type string : forestDry "Waldtrockenheit" [ stateTransformation="JSONPATH:$.timeSeries.[0].[?('forestdry')]" ]
			Type string : approvedTime "Bestätigt für" [ stateTransformation="JSONPATH:$.['approvedTime']" ]

And my .items are as follows:

Group	WeatherFireRisk						"Brandgefahr"	
String					WeatherFireRiskIndex						"Brandrisiko [MAP(]"					<fire>				(WeatherFireRisk)	{channel="http:url:fireRiskForecast:fireRiskIndex"}
String					WeatherGrassFireRisk						"Grasbrandrisiko [MAP(]"				<fire>				(WeatherFireRisk)	{channel="http:url:fireRiskForecast:grassFireRisk"}
String					WeatherForestDry							"Waldtrockenheit [MAP(]"					<fire>				(WeatherFireRisk)	{channel="http:url:fireRiskForecast:forestDry"}
DateTime				WeatherFireApprovedTime						"Bestätigt für [%1$tR, %1$tb %1$td]"						<timestamp>			(WeatherFireRisk)							{channel="http:url:fireRiskForecast:approvedTime"}

The item WeatherFireApprovedTime is filled by the data from the json (allthough it has a 1h offset, whyever?) but the other values remain NULL.
I tested my JSONPATHs by using and there the path is found.

The only thing I noticed are some errors that occur every 4-6 hours:

[WARN ] [p.internal.http.HttpResponseListener] - Requesting '' (method='GET', content='null') failed: java.util.concurrent.TimeoutException: Total timeout 5000 ms elapsed

But this doesn’t seem to be the issue - I’m on an 4G connection and with this, things like this happen from time to time.

Has anybody any idea why the items don’t get filled?

To be complete, here are the .maps:

\-1=Keine\ Daten
1=Sehr\ niedrig
5=Sehr\ hoch
6=Extrem\ hoch

\-1=Keine\ Saison
2=Grasbrandsaison\ vorbei
6=Sehr\ hoch

\-1=Keine\ Daten
1=Sehr\ feucht
3=Leicht\ feucht
5=Sehr\ trocken
6=Extrem\ trocken

If your data is the same as the sample data from the website, it seems that your path is not fully complete for what you are expecting.

Still returns an object and you want only the element in the values array within that object. So I suspect you need to add .values[0] to each of your paths.

Argh - thank you for this hint. I had .values.[0] before and it didn’t work.

I try with .values[0]as you mentioned and let you know if it works now.

Thank you

Unfortunately it didn’t work. The items are still empty.
Any other idea what is going wrong? @JustinG

Are you sure the items are empty? That would be very strange. If the JSONPATH transform fails it returns the original JSON string not an empty value. You know the JSON string is being properly retrieved because you said that your timestamp item is correctly populated. So the JSONPATH transform must be returning something. Look in the logs, not for errors, but for the events of the items. You should see events that look like item WeatherFireRiskIndex changed from ... to ....

I’m beginning to suspect that the problem is the map transform. Are you sure the map transform add-on is installed? If you remove the map from the item labels does it show the correct (but untransformed) value?

I removed the mapping from the items and tested again - the difference is, that items display NULL instead of -. And yes, the map transform is installed and runs fine with many other items.
The events.log file contain an entry for the WeatherFireApprovedTime item only. Nothing for the 3 other items.

Item 'WeatherFireApprovedTime' changed from 2023-02-16T00:53:03.000+0000 to 2023-02-17T00:53:03.000+0000

On my two other http things, the JSONPATH work perfectly. There I have paths like

JSONPATH:$.coordinates.[?(@[0] == 57 && @[1] == 15)].[2]



which contain similar paths.

Interesting update: I created a rule because I had the feeling that the JSONPATH transformation is a little bit more sensitive on the paths than

rule "Http test"
	Time cron "35 1/1 * ? * * *"
	try {
		var String json = sendHttpGetRequest("")
        var String value = transform("JSONPATH", "$.timeSeries[0].parameters[?('grassfire')].values[0]", json)
        logInfo("Http test","Value is: " + value + " " )
	catch(Exception e) {
		logError("Http test", "Error when rebooting server: " + e)

In this rule, the original path returned NULL, so I played around with the path from short path to full path and after ~30 iterations I finally received the desired value as output on value .

The path that works fine is $.timeSeries[0].parameters[?('grassfire')].values[0] but I recognized still an issue with the binding:

After renaming the thing to another name, the items have been filled once. Since then, I don’t receive actual value - no matter if I reboot or if I remove and add again the thing.

Is there a place where I can check when http binding called URL the last time?

That’s progress…strange progress, but progress nonetheless.

Sounds like you need to turn on debugging for the http binding and see if there are any informative messages in the logs after that.

I have never seen an instance of http binding not refreshing its calls at the correct times, but turning on binding debugging should let you see whether it’s trying to make the calls or not and if it’s getting some error. Is there a limit to the api you can make to this service? Are you somehow hitting that daily limit and being cut off?

I did the log:set DEBUG org.openhab.binding.http and checked but there wasn’t any output related to http.
I don’t think I hit a daily limit because the rule could still grab the values - This could only happen if the api distinguish between rule get request and http binding request.
At the beginning I thought the refresh= parameter is in minutes, so I set it to 5… which was of course much to heavy knowing that it is seconds :slight_smile:

That’s seems even more strange. If the binding is working, surely there should be some debug messages. What the output of:

bundle:list | grep HTTP


openhab> bundle:list | grep HTTP
 68 x Active x  80 x 3.4.5                  x Apache CXF Runtime HTTP Transport
170 x Active x  80 x 3.4.2                  x openHAB Core :: Bundles :: HTTP Interface
171 x Active x  80 x 3.4.2                  x openHAB Core :: Bundles :: HTTP Interface Authentication
240 x Active x  80 x 4.1.72.Final           x Netty/Codec/HTTP
260 x Active x  80 x 3.4.2                  x openHAB Add-ons :: Bundles :: HTTP Binding

I admit, I’m kind of stumped at this point. It sure looks like the binding is working, but you’re not seeing any activity. I know you said in the first post that you don’t think it’s the timeout value on the thing, but that’s one of the few pieces left to try (and one of the differences between the binding failures and the rule successes), so you might want to try increasing that value; 5s is just not a very long time to wait for an api response.

Other than that though, if it were me, I’d do two things:

  1. Stick with the rule and just populate your items from that. You know it’s working and there’s no real performance difference between the http binding and sendHttpGetRequest.
  2. Check the http binding repo to see if there are any similar issues already open and if not, file this one.