New item type - object/array?

Setup, Configuration and Use Items & Sitemaps
1

Hey,

are there any plans on imposing a new item type, e.g. object with subfields or array?

Namely, I have managed to set up a central API in my house that serves all the required data to OpenHAB. For instance, my /api/weather API endpoint serves temperature, humidity, sunrise, … data I, then, use in OpenHAB together with http binding and JSONpath transform.

The problem here is that different items make the same API call to get data, which is quite redundant:

  • itemTemperature calls /api/weather with JSONpath($.data.temperature)
  • itemHumidity calls /api/weather with JSONpath($.data.humidity)
    etc

All these calls return the same data, since both temperature and humidity are contained within the JSON structure of /api/weather

All this could be solved if an item with type object/array was defined in OpenHAB, receiving the JSON from my /api/weather, and then other items could set this item as their source (instead of calling the main whole API again)

My workaround for this is to put memcache in front of my API, so instead of my API calling external weather sources everytime, it caches those external values and OpenHAB’s http binding calls then only take cca. 30msec instead of 500msec … only the first call after 5min (when cache expires) takes 500msec since it loads external weather values into my local API.

By using memcache in my local API, I’ve managed to speed things up. But I think this is an OpenHAB item design flaw since grabbing a whole JSON from http, and then dispatching subvalues to items would be a more appropriate approach.

Any ideas?

Thank you and Best,
Denis

2

What’s the objection to fetching the whole JSON into a single Item, and then triggering a rule to analyse it into the many part Items?

3

OK that’s a great idea. A rule can, then, process fields and dispatch those values to corresponding items in case their current values are different. Great, thanks! I’ll just need to refactor my items - I’ll remove http bindings for groups with same API call, and make a super-item to them with an ‘on value changed’ rule that will send individual .postUpdate calls. Thank you!

4

I don’t know how much work it is to process text into JSON within a rule, but hopefully there will be examples in this forum

5

If its as simple as calling

transform("JSONPATH","$.result.0156-76BC5229.6400_00462F00.1[0].val", jsonString)

then I don’t see any problems.

6

You could use the cached function of the http binding.

7

That is what the caching config in the HTTP binding is for. It polls the URL once every X seconds and caches the result. The Items poll the cached version every so often to get their value. So your service only gets hit once every so often, not once every so often times the number of Items.

In short, the HTTP binding already implements your memcache.

See Comprehensive Wunderground using HTTP Binding Example for a complex example of using the HTTP binding in this way.

You can call JSONPATH transform from Rules using the transform Action. But it is not needed in this case.

And I get all the way to the bottom and Vincent beat me to the answer. :smiley: