Main UI: Visualize semantic model tree in item details screen

[mherwege]

Closes #3217

This is not ready for merging as it heavily relies on #3165, #3178 and #3223. All the code from these PR's is included in this one, so it is fully functional. It should be rebased once the other PR's have been reviewed.

This PR extends the item details screen to show part of the model the item is in, from the top, down to all its children. The tree is opened up to the level of the item. Clicking on a level in the tree, will take you to the related item.

With this PR, the terminology discussion from #3211 becomes less critical as the terminology is replaced by a graphical representation of the model with all information in it.

Below is how it looks like.

Note the Parent Group and Child Group sections will contain all semantic and non-semantic direct parent and child groups.

A concern may be this is introducing a load of the full model for each item. The REST API call only retrieves static data, therefore I believe it is cached and should not continuously pass the full payload over the network. In my tests with over 1000 items, I didn't see a strong negative performance impact, but it may depend on the system. An improvement could be to move the filtering to OH core with an extra REST parameter. However, this will also make caching less relevant.

[relativeci]

#3232 Bundle Size — 11.33MiB (+0.39%).

aefbbf3(current) vs 204ca25 main#3231(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   7 changes 2 regressions

	Current #3232	Baseline #3231
Initial JS	2.01MiB(+0.03%)	2.01MiB
Initial CSS	577.53KiB	577.53KiB
Cache Invalidation	21.13%	17.81%
Chunks	253(+0.8%)	251
Assets	276(+0.73%)	274
Modules	3019(+0.84%)	2994
Duplicate Modules	157(+6.08%)	148
Duplicate Code	1.73%(+2.37%)	1.69%
Packages	97	97
Duplicate Packages	2	2

Bundle size by type   2 changes 2 regressions

	Current #3232	Baseline #3231
JS	9.53MiB (+0.42%)	9.49MiB
CSS	875.53KiB (+0.52%)	871KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
IMG	140.74KiB	140.74KiB
HTML	1.38KiB	1.38KiB
Other	871B	871B

Bundle analysis report Branch mherwege:sub_model Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[ghys]

A concern may be this is introducing a load of the full model for each item.

Absolutely a concern, as you've identified :)

The REST API call only retrieves static data, therefore I believe it is cached and should not continuously pass the full payload over the network. (...) In my tests with over 1000 items, I didn't see a strong negative performance impact

I'm not sure we can rely only on the fact that the data retrieved repeatedly would be cached to say "it's all okay".
Sometimes there could be proxy servers between openHAB and the client, and the cache mechanisms might be screwed up so we could have a problem.

[mherwege]

I'm not sure we can rely only on the fact that the data retrieved repeatedly would be cached to say "it's all okay".
Sometimes there could be proxy servers between openHAB and the client, and the cache mechanisms might be screwed up so we could have a problem.

So what are the options then?

1. I abandon this.
2. I extend the REST API to return this local tree for use in this view. It does mean it will effectively return data for each item opened and caching will not have any effect.

Any other suggestions?

[ghys]

So what are the options then?

I abandon this.

Please don't ragequit, it's a good feature, I just struggle how to implement it correctly :)

I have understood recently that you can't rely on client caches only.

I extend the REST API to return this local tree for use in this view. It does mean it will effectively return data for each item opened and caching will not have any effect.

It could work but it's a very specific API, will it have an use outside of that screen?

[mherwege]

Please don't ragequit, it's a good feature, I just struggle how to implement it correctly :)

That’s not at all what I meant. I am much less experienced then you though, and I don’t see an easy solution.

It could work but it's a very specific API, will it have an use outside of that screen?

There actually already is a very specific one I believe is mostly there for this screen: get all children (recursive), including the dynamic data. It could be extended to get the parents as well. I was already looking into that, also because there still is a mismatch. On the item screen, the direct children have a state (from that API), but not the parents. I get these trough the model static data request, so without state.

[mherwege]

@ghys With the last commit, I now use an adjusted REST API to only retrieve the item model information. Therefore this requires openhab/openhab-core#4861