I’ve been familiarizing myself with OH3 and so far I’ve found it to be a major step forward that’s beautiful, sleek and very polished. However, there’s one thing I was disappointed by, and it’s the limited ability to query the API from within the UI to garner extra information about an item.
With the introduction of the semantic model and the emphasis on a clear hierarchy and tagging, I was hoping you could create smart widgets that would “just work” given minimal information, for instance giving a smart thermostat Equipment to a custom widget and having it autodetect the various items from the semantic tags.
Unfortunately, as far as I can tell, the custom widgets only really have access to an item’s state and display state. The semantic tags aren’t exposed, nor are the item’s type or relationships. Even the label seems to be missing. All the examples I’ve been able to find use simple string manipulation with assumptions like “a thermostat’s setpoint is always <itemname>_SetPoint”. While that works, I find it defeats the whole point of having a semantic structure.
What’s the rationale for exposing so little of the REST API in the new UI? Is this something that could be changed in the future? It’s the last thing that’s missing (IMO) from the OH3 UI to make it the end-all be-all.
Hi,
I know this an old post, but is it still the case that there’s no way to access things like item tags in widgets (except the oh-repeater)?
I’m trying to construct a new Main UI dashboard and attempting to be “clever” and use as few templates/widgets as possible. I have various tags for items, which works well in oh-repeater, but then falls down on trying to link items or hide a widget if a specific tag is not present.
If all this is accessibly only from the REST API, then I think i’m going to consider pulling the plug on using the OpenHab front end at all. I’m now seriously considering something like Python and Bootstrap or React hooking into the OpenHab REST API.
I know the Main UI is relatively new and is still evolving, so I’m sure all this will be possible in the future.
This particular behavior is not likely to change for reasons of optimization. In terms of responsiveness of the UI, rest calls are pretty expensive. and in most situations, the required information about an item in the ui widgets does not need 99% of the information that comes through. As it is, the items object available in the widgets isn’t making rest calls at all. The widget compiler keeps its own list of items to watch the event stream for and updates the states and displayStates of items in items object from that.
If it’s really important for the function of a widget to be able to access some of this information, then there’s no reason you can’t use an oh-repeater to get it. There are a couple of different tricks.
If you just want one item then use a itemsWithTags repeater but add the filter property to restrict the repeater’s output to just the one item you’re interested in.
If you want access to an array of multiple widgets you can use a little trick with a repeater. In addition to the the regular loop variable (for example, loop.item) in a repeater you also have access to two additional useful variables a _source (e.g., loop.item_source) which contains the entire array the repeater is looping through and _idx (e.g., loop.item_idx) which contains the index of the current loop iteration. So, the trick is this. Configure the repeater to get the full list of items you want however you wish, and then use the map property to set the value of a single element to the complete source array. Using the item variable example it would just be this:
map: loop.item_source
The repeater is still going to render it’s child elements a number of times equal to the number of items, but we can fix this with the repeaters filter property and the _idx variable:
filter: loop.item_idx == 0
Now the repeater only loops once and its loop.item variable contains an array of every item it retrieved from the rest call. You can just build the rest of your widget starting as a child of the repeater and have access to all the information you want.
This is not an ideal solution because control over the array (e.g., sorting) is still limited to the widget expression system and access to the items is based on the numerical index in the array which you may or may not know depending on the situation. However, it does get you most of the way there and these smaller issues may well be fixable in the future where the broader full access to the items rest endpoint will not be.
