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)
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.
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!
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.