Improve equipment rendering in model cards

[krocans]

The problem

There is no way to group Controls/Points under Equipment at same time keeping semantic structure (tree) consistent.
I guess this issue generalizes #749

Your suggestion

Imagine Equipment which has many controls/points like 20 or even more. Such equipment when correctly configured with semantic tags cerates enormously long list in Location and other cards and makes those hard to read/use.
Logical solution seems to be arrange those controls in some groups. "Group" in legacy sitemaps did that well but un OH3 UI this causes problem.
here is sample item setup with two points grouped.

Group TestRoom "Test room" <sofa> ["Room"]
Group TestEquipment "Test equipment" <receiver> (TestRoom) ["Receiver"]
Switch TestEquipment_Control1 "Test equipment control 1" <switch> (TestEquipment) ["Control"]
Group TestEquipment_ControlGroup "Test equipment control group" (TestEquipment)
Switch TestEquipment_Point1 "Test equipment point 1" <text> (TestEquipment_ControlGroup) ["Point"]
String TestEquipment_Control2 "Test equipment control 2" <text> (TestEquipment_ControlGroup) ["Control"]

In this setup non-semantic group TestEquipment_ControlGroup is not shown in cards at all and items are placed as standalone of semantic tree. (Probably for that setup it's expected behaviour)

When group is configured as "equipment in equipment"

Group TestEquipment_ControlGroup "Test equipment control group" (TestEquipment) ["Equipment"]

semantic model looks great

but items in group still are not shown in locafion/equpment cards

And bogus Miscellaneous Equipment is created in equipment tab

That's not expected behavior because those two items are not some kind of standalone equipment.

Expected behavior

Result most close to expected I was able to achieve by tagging group itself as control.

Group TestEquipment_ControlGroup "Test equipment control group" (TestEquipment) ["Control"]

That makes cards to work as expected - group is shown as list item (with nasty NULL value) but it's there and clicking it opens new popup with contents.


But semantic model is broken

So it would be very nice to have some new semantic tag (like ControlGroup or PointGroup) for groups which will behave like "Control" in above example (show as item+popup card in cards) but in same time semantically keeps items as belonging to upper group (Equipment)

Your environment

n/a

Additional information

n/a

[curlyel]

I basically agree to Kaspars 's thought - at least I feel the same pain ;-)

For me this boils down to the question, how to organize points for equipment better in automatic generated cards and lists while keeping the the semantic correct and provide a decent user experience?

As Kaspars said, equipment with a long list of points clutters the generated card and makes them less usable.
Since the card's content is derived from the model's metadata, some additonal control over the UI representation should be done via (additional?) metadata in my opinion too.

Could we use some existing metadata already to improve the representation?
Let me share my thoughts on this feature request. I currently see three options how to deal with long lists of points:

General idea

We likely have a bunch of point for a specific equipment but just few of them (maybe just one) is relevant for most uses, but all the others should still remain accessible via model driven UI components. So, just "untag" them as points would not solve the need.
BUT: Could we limit the default listing of points to just the most relevant points? If access to the remaining points is needed, some expand/popup/etc. should reveal them.

Example

I'll share my example of my weather sensors in the garden. All are battery powered and transmit the data via wireless. So all have battery channels as well as signal strength which clutters the UI. But the most relevant data are the sensor readings for temperature/humidity/rainfall:

Option 1:

When we use "Default Widget Order Index" metadata, we can promote more relevant points (items) to the top of lists. This works in the model as well as in the generated cards. If we tag just the relevant points (e.g. the rainfall counter in the example), this reading is promoted to the top of the list. Current default behaviour is the presentation of all the remaining "untagged" points (no WidgetOrderIndex is set) at the end of the list. Option 1 would be to hide them (instead of appending them to the end) and reveal them just on click/tap on the equipment line in the UI.

Option 2:

If the equipment group has expicitly an "Default List Item Widget" assigned which links the representation of the group to a specific item of that group, ALL points could be hidden first and just the defined list widget is shown. The hidden points will be revealed through expand/popup after click/tap on the equipment list widget.

Option 3:

Introduce an additional metadata tag for the equipment groups indicating how many of the points belonging to the equipment should be listed by default. The rest remains hidden until some click/tap as above. Think similar to the basic/advanced channels of things. Semantic for this additional tag could be:

• 0 ... collapse the whole equipment group to just a single list widget. Shows the "Default List Item Widget" for the equipment itself
• 1 ... same as above - collapse to a single list widget per equipment, but shows the "Default List Item Widget" of the first (top) point of the points in the group (no need to assign a widget data source item to the equipment group)
• 2 ... [number of list entries] show a line for the equipment and the leading given number of points. The order of the points could be sorted by the widget order index again.

In all cases, the rest of points should be revealed after click/tap on the equipment line.
Pinging @ghys - WDYT?

[ghys]

I agree that the equipment rendering doesn't scale well, and I intended to work on it for 3.1.
My original idea was to use accordions/collapsed nested lists when the total number of points in a card exceeds a threshold. @curlyel your proposals of using metadata to influence are very interesting as well and perhaps even better.

I also wanted to improve the default widgets for Group items which are also Equipments anyhow, because they will often just display the group's state which is NULL unless the admin does something about it.

I'll make some experiments to help in deciding the final design, it's better to have some visual feedback to make up our minds.

[hannibal85]

Thanks @krocans for starting this. I had similar thoughts already and posted on the community forums. But your summary and suggestion is much more detailed than mine. So I will try to give some additional input from my POV

When group is configured as "equipment in equipment" [...] semantic model looks great

For me this is the most "natural" way of modelling this and exactly what I did. To achieve the expected behaviour I added a dummy item like Test equipment show control group w/o any functionality beside being tagged as Point (and thus shown under Test equipment) and showing the control group by configuring the Default List Item Widget with a Group details action. Leads to the expected behaviour and semantic model is fine at the cost of an additional item.

But it is a really ugly workaround and having a solution to realize this would be great. Creating a new tag like PointGroup sounds good ... BUT ... I even more like the idea of @curlyel to make it configurable by the user with metadata.

We likely have a bunch of point for a specific equipment but just few of them (maybe just one) is relevant for most uses

This is how I modelled all my equipment... some basic points in the equipment group plus one or more sub-equipment for "advanced" functionality. To make the visual representation configurable by the user I can imagine following metadata as additional namespace like in @curlyel Option 3 (of course with nice UI configuration like for the expire timer ^^)

• 0 ... collapse the whole equipment group to just a single list widget. Shows the "Default List Item Widget" for the equipment itself
• 1 ... same as above - collapse to a single list widget per equipment, but shows the "Default List Item Widget" of the first (top) point of the points in the group (no need to assign a widget data source item to the equipment group)
• 2 ... [number of list entries] show a line for the equipment and the leading given number of points. The order of the points could be sorted by the widget order index again.

In addition:

• -1 ... hide the element completely
• 0 ... as described above, would be the default if no metadata specified
• 1 ... 👍
• 2 ... 👍
• parameter to set the "style" for showing all points -> pop-up window with list widgets (like today), accordion list, page with standalone widgets, whatever makes sense
• also use the same namespace for Points (only -1 and 0 makes sense) -> so I can hide a point in properties tab while showing it in equipment (e.g I don't want to see the temperature of my server under temperatures but under the server equipment)
• possibility to configure the behaviour for all standard tabs (location/equipment/property) individually (e.g. I want to see my server under locations in style 0 just as a group while I want to see the 3 first points as Network Appliance directly)

This leads me to a namespace mock-up like this

value: " "
config:
  location_tab: -1
  equipment_tab: 2
  properties_tab: 0
  leading points: 3
  style: pop-up, accordion, page, ...

One last point I'm not so sure about right now is how to handle the automatically created glance badges for location cards. As of today only Points located directly under the location or the first equipment hierarchy are shown. What about Point located under some sub-equipment? Should it be considered or not?

[krocans]

Of course it's up to developers but my opinion still is that this separating of some points under equipment internally should be based of Group no matter what tags are assigned to that group. Simply assigning like 10 items to group leads to more visibility than "metatadating" those 10 items individually with order number, show/noshow and things like that ... and definitely leads to less mistakes. Plus my personal interest in it - I'm still using text configs + git on OH3 (and probably somebody else does too) so tons of metadata for each item in text configs makes them awful.

And about tagging of this group ... or not group ... in other words about model hierarchy. Whatever it will be I think it should not be nested "Equipment". Seriously what the h is "equipment in equipment"? It just breaks my mind :). The only case I can imagine is if you have some coffee machine with built in radio both WiFi controllable :). That's why I initially called this "PointGroup". What I was talking about was for example merging, separating and by default collapsing in UI bass, treble and sound effect controls of AV receiver. As you can imagine such group logically is not any type of equipment just controls.
And don't forget that classifying something as some kind of equipment by default behavior causes them appear as bogus equipment on equipment tab. So (ab)using "equipment in equipment" automatically causes either new dirty workarounds either requires additional UI development to hide this pseudo-equipment from default equipment tab.

[curlyel]

Just for reference:
I've done a tiny workaround which solved the "long list of points" problem while leverageing yet-existing features:

https://community.openhab.org/t/mainui-better-rendering-of-equipment-with-lots-of-points/115860?u=curlyel

This is a bit of work - sure. Therefore, I'd consider this as interim solution only... ;-)
Just wanted to share the idea with you too...

[tarag]

@krocans, @curlyel , did you have a look at the latest milestone ?

I believe PR #1307 addresses some of your concerns which I shared. I must admit I made an implementation in my own way, because I had not read this thread before having finished the work. Yet it is very similar to the options 2 or 3 described in your posts above, depending on the settings chosen.

I would be interested to have you feedback.

[krocans]

Good job @tarag!
Card behavior is now great but I have noticed couple issues (bugs?)

Here is my test model setup

And here is result on card:

Problem 1 (possibly bug): Values of "default items" (order index 0) are not shown in accordion header
"Test equipment/Test equipment control 1" is correctly shown as switch in accordion header but "Thermometer/Status/Battery level" is used as accordion header but it's value is not shown.

Problem 2: Card is ignoring measurement values if items in nested groups
As you see temperature/humidity measurement are not shown on card icon area because points are in nested equipment. It works if I move those items directly under "Thermometer" equipment.
This probably is not bug but inconsistency of behavior and probably must be discussed separately.
I see 2 options here.

1. If huge improvement is made for support of nested equipment in cards it seems logical also to adjust algorithm for card header to search for states/values in nested equipment.
2. Of course there is option to state that it's " by design" that points must must be in first level of equipment to be displayed in card header

[tarag]

Thanks for your feedback.

Regarding problem 1, it is indeed a bug. PR #1396 will fix it, but might introduce horrible 'NULL' if you don't configure your groups metadata properly.

For problem 2, indeed the code of the measurement/status at glance needs to be updated to parse sub-equipment. You could open an issue to keep track of this shortcoming. Apparently this is a single function that needs updating to be recursive.

[zylle86]

For problem 2, indeed the code of the measurement/status at glance needs to be updated to parse sub-equipment. You could open an issue to keep track of this shortcoming. Apparently this is a single function that needs updating to be recursive.

Has this been looked at yet?