New option to display equipment as accordion in Locations cards

[tarag]

This PR provides a new option to display equipment as accordion in Locations cards, also giving the possibility to promote the main item of the equipment (widgetOrder == 0) as the accordion opening item (or equipment with a single point), while keeping the functionality of the control in the list item:

This is an improvement when having very long list of equipment in one location, as it give a fast access to each point, while not having to scroll a lot and be overwhelmed by the quantity of items. A good selection of the main item for each equipment and selection of the 'promote' option further increases speed of use.

[relativeci]

Job #387: Bundle Size — 10.7MB (~+0.01%).

40054c4 vs bc05b2d

Changed metrics (2/10)

Metric	Current	Baseline
Initial CSS	607.04KB(~-0.01%)	607.09KB
Cache Invalidation	7.49%	21.3%

Changed assets by type (2/7)

	Current	Baseline
CSS	856.91KB (~-0.01%)	856.96KB
JS	8.65MB (~+0.01%)	8.65MB

---

View Job #387 report on app.relative-ci.com

[tarag]

All the changes are linked to new options (it seems people don't like unexpected changes 😉) Still a little bit a work in progress.

Code-wise, I know there are some improvements to be made, specially in homecard-mixins.js as there is quite a bit of duplicate code. But for this I would like to propose to remove the Equipment | Property top level distinction in Location/Equipment cards. I really don’t see what is the purpose of this or how to explain a user what he will find behind each category. I don’t use Properties at to level in Locations but looking at the openhab demo I really wonder what is the purpose of this distinction in Locations card (I don’t question the purpose of properties in the model of course). @ghys , do you think this distinction is really useful in this part of the UI?

I also would like to use equipment accordion opening list items with custom list widgets (like the central light controller in screen recording) but this does not work. I need to figure out a way to pass the accordion slots context along the way for custom widget. Do you have an idea?

By the way some corrections were performed so that sub-equipments are not forgotten in these pages.

[ghys]

Thank you very much for this @tarag because it is pretty much what I had in mind for quite some time - I even made some experiments a year ago or so but didn't pursue them further because I had some problems with accordions as you found out yourself.

I'm giving it a quick try and it works pretty well - with a few rendering issues but nothing major, we can address them as we go along - there is something that I can't figure out though (I only looked at the code in passing yet):

The accordions in the location cards seem to work when enabled but not the equipment cards:

So I'm not sure if i'm missing something.

Also maybe it would be nice to repeat the options on the cards to override those set at the tab level
(not the biggest fan of the "eqpt" prefix in eqptNesting: accordion prefix to be honest, equipmentNesting looks better IMHO 🙂).

Great work overall though, I think we can push this forward.

I would like to propose to remove the Equipment | Property top level distinction in Location/Equipment cards. I really don’t see what is the purpose of this or how to explain a user what he will find behind each category. I don’t use Properties at to level in Locations but looking at the openhab demo I really wonder what is the purpose of this distinction in Locations card (I don’t question the purpose of properties in the model of course). @ghys , do you think this distinction is really useful in this part of the UI?

It was implemented only because the model allow this (property -hasLocation-> location) and it's useful in some cases, like for NLP (HABot & co.), when you ask "what's the temperature in the living room?" the Measurement>Temperature property directly under the room location is supposed to take precedence over any such property part of equipment in that room.
Mostly the badges in the location card header respect this as well, but you can't do advanced things on badges like open the analyzer. Are you proposing to remove the properties from the location card or just the segmented button to have them separate?

[ghys]

Btw another idea that I had, off-topic for this PR but still, is to have an "advanced" flag for items defined in metadata, maybe in the widgetOrder namespace e.g.

String AdvancedItem { widgetOrder="3" [ advanced=true ] }

Advanced items wouldn't be shown by default unless you check a box (similarly to configuration properties).
It's not that hard to implement and perhaps easier for users than fiddling with visible properties, while allow some kind of ad-hoc interactivity - you can still view the advanced items if you wish.
This flag could be set automatically on items when doing "add equipment from thing" operations if the channel is an advanced channel.

[tarag]

Thank you very much for this @tarag because it is pretty much what I had in mind for quite some time

Glad you like it, it did not really experiment it other than testing but I really think it’s an improvement.

I even made some experiments a year ago or so but didn't pursue them further because I had some problems with accordions as you found out yourself.

The PR doesn’t eventually have lots of code lines for this mechanism but it took quite a few hours of trial and error, head scratching and deciphering f7 code to reach this state. F7 does lots of behind the scene work with events that would prevent reaching the expected result. It does rely on what appears to be some internal API but I don’t think it will change. Maybe we could ask for an evolution of f7 to support this without fighting against it….

The accordions in the location cards seem to work when enabled but not the equipment cards

This is not yet implemented. It will rely on the same mixin but there are a few labelling changes to make in addition. I wanted to show the principle first before continuing.

Are you proposing to remove the properties from the location card or just the segmented button to have them separate?

The latter. I perfectly understand the reason to have Location-level Property ( or Point for that matter). What I don’t really understand is why they are separate (at least in the demo example it doesn’t really make sense to me). I’d propose to group them with the Point and Equipment, or maybe display the non-Property Points along. In that case the designer of the model could use an enclosing equipment to decide where he wants to display the final item. Maybe this separate category makes sense for Location settings that would affect automation linked to the room or multiple equipment (eg: activate presence simulation, activate automatic light switch on, pair speakers with other rooms). I’m just trying to understand…

Btw another idea that I had, off-topic for this PR but still, is to have an "advanced" flag for items defined in metadata

I am also thinking a bit about how to handle this. The current solution I use with other account/roles and use of visibleTo is not good.

With this PR I it’s less useful though because these items would not be displayed when the accordion is closed. I also thought defining a sub-equipment labelled « Advanced »  that would gather all these items but it is somehow an abuse of the model and a dedicated metadata flag and dedicated UI control would definitely be better.

[tarag]

Also maybe it would be nice to repeat the options on the cards to override those set at the tab level

I was also thinking about this capability, maybe not necessarily providing the UI for it (just allowing it if defined in YAML).

(not the biggest fan of the "eqpt" prefix in eqptNesting: accordion prefix to be honest, equipmentNesting looks better IMHO 🙂).

No problem for the options names, I’ll use the full « equipment »  word.

[ghys]

Maybe we could ask for an evolution of f7 to support this without fighting against it….

Framework7 is a one-man show, we are already one major version behind (v5, migrating to v6 implies switching to Vue 3 and would involve a lot of work), and the author only seems to support the latest version (apart from critical bugs).

(at least in the demo example it doesn’t really make sense to me)

Not so surprising, the demo items were there for a long time (maybe since 1.x.) and was directly taken over to 3.x, and some items (like the temperature in a room) were directly attached to the room's Group, the general principle of having Equipment groups didn't exist at the time. Still it makes sense to attach properties or points to Locations - I've mentioned a couple of times that you can modify the group membership of a Measurement>Temperature or Setpoint>Temperature Point to be both under an Equipment group (measurement or setpoint as reported by a thermostat) and a Location group (what is considered to be the temperature measurement/setpoint for the whole room) - the semantic model allows it and it also makes sense semantically.

Also I'm not sure that all Properties under a Location should also be in an Equipment under the same Location.
For instance you could have an central Equipment in your basement (so in the model it would be under the Basement Location), that has multiple Points managing stuff for different rooms.
I'm open to suggestions on how to present Properties of the Location in the location card that would appear before the Equipment - maybe not as list items?
Or maybe it could simply be the first section of the list when you expand the card (perhaps with appropriate separators).

With this PR I it’s less useful though because these items would not be displayed when the accordion is closed.

I'm not so sure, accordion or no, it would be nice to have only the most important items displayed (as an end user of those cards, you care mostly about a few items and the rest would be only on a needed basis, when you check the "Show Advanced" box). Having this flag set automatically when you convert a thing's channels to an Equipment (depending on the advanced status on the channel) would be nice too.

[tarag]

Still it makes sense to attach properties or points to Locations

I fully agree, but one has to be careful so that it makes sense to the user. I believe that a non-Property Point should go along with the Property in the Location cards context don’t you think? They are just a less precise kind of Property.

(This is what I did in today’s commit)

I've mentioned a couple of times that you can modify the group membership of a Measurement>Temperature or Setpoint>Temperature Point to be both under an Equipment group (measurement or setpoint as reported by a thermostat) and a Location group (what is considered to be the temperature measurement/setpoint for the whole room) - the semantic model allows it and it also makes sense semantically.

I did not know that. I’ll have to check if I did not make assumptions in the code that could cause issue in this regard.

For instance you could have an central Equipment in your basement (so in the model it would be under the Basement Location), that has multiple Points managing stuff for different rooms.

I deal mostly with KNX installations where almost all the equipment is in the electrical cabinet in the basement or elsewhere. I completely disregard this and it does not appear anywhere in the UI to the user. I think this is the distinction between Things (devices) and Items (function). Equipment are group of items and it make sense for the end-user to place them in the room where the function is provided (if the function is not shared among a single room, then I’d place it in the upper-level Location that would make sense). I do have a few Equipment in the room where the device is physically installed but this is for maintenance Points/equipment shared among several user function-equipment available in the corresponding room (for example a heating boiler). I find this maps quite well to voice assistants also.

[tarag]

@ghys, did you have a look at the latest commit ? Could you tell me what would be needed to go forward (you said there were some cosmetic issues) ?

Related to our discussion, Points belonging to the model directly under a Location are now displayed under the 'Properties' sub-part of location cards (they would not show-up anywhere before...). So even if I don't necessarily plan to use them I thinks that's an improvement.

[ghys]

@ghys, did you have a look at the latest commit ? Could you tell me what would be needed to go forward (you said there were some cosmetic issues) ?

The accordions in the location cards seem to work when enabled but not the equipment cards

This is not yet implemented. It will rely on the same mixin but there are a few labelling changes to make in addition. I wanted to show the principle first before continuing.

I admit I didn't, but I thought it was still a work in progress?
I'll have a fresh look in the next few days!

[tarag]

I admit I didn't, but I thought it was still a work in progress?

There is always room for improvement but I believe it’s quite consistent right now.

In addition, merging would allow me to tackle the configuration of the labelling that was raised in the community discussions.

[ghys]

There is always room for improvement but I believe it’s quite consistent right now.

Ok, but options in the equipment list that aren't implemented and do nothing should be removed first then (or commented out or hidden):

The accordions in the location cards seem to work when enabled but not the equipment cards:

This is not yet implemented. It will rely on the same mixin but there are a few labelling changes to make in addition. I wanted to show the principle first before continuing.

[tarag]

This should work for equipment (it works for me). Are you sure you fetched the latest commit?

[tarag]

@ghys, sorry for harassing you 😉 Could you tell me what should be improved before a merge is possible ?

[ghys]

@tarag thanks for the update, I just had a look (I have low bandwidth for OH these days) and had to set up my dev environment again.
Unfortunately the location cards don't display at all for me with the latest changes:

So it's probably linked to the changes wrt. the card model building in homecards-mixin.js although I have to diagnose why (there's nothing in the console).

In any case since there's clearly potential for regressions it needs to be tested extensively (since there are still no unit/e2e tests although the infrastructure is there).
I'll find what the issue is and get back to you soon.

[ghys]

Thanks a lot, it seems to work better at least in my case!
I left some comments below:

[ghys]

One more thing wrt. additional styles in oh-list-item

[tarag]

Not sure what this not successful check is about. I think everything should be all good now.

[ghys]

Right, I think we can at last ship this change. The code is clear enough and I believe there aren't any obvious regressions esp. in the behavior of system widgets, but if we missed something it can be dealt with.

To avoid another back-and-forth I finished cleaning up the styles in oh-list-item (putting everything under the dedicated class), and tweaked the loading indicator in the home page designer to avoid flickering, a minor change.

The build failure is not related, the version of HABot's code when you forked the main branch doesn't build with the latest core, it's been fixed since.

Many thanks for all your work and your patience in the last few months!

[SR-G]

Upgrading from 3.3.0-M3 to 3.3.0-M4, i have an issue : the "location" cards are now nearly empty and a lot of items are not displayed there anymore (whereas still attached to location groups).

Same with 3.3.0-SNAPSHOT (but one-week ago SNAPSHOT was OK).
If i downgrade to 3.3.0-M3, everything is fine.
So :

• with 3.3.0-M3, i have all my location cards + all the attached devices (8 cards)
• with 3.3.0-M4, i have only 3 cards (5 are missing)

For example this card is shown without any issues in 3.3.0-M3 :

Whereas it's not even displayed at all in 3.3.0-M4.

My semantic model is still OK / still the same in both situations (and everything is coming from .items files).

Is there anything to change ? I tried the various new options, without any change on the display of theses location cards.

[tarag]

It would be great if you could send me the result of the REST call: '/rest/items?metadata=semantics,listWidget,widgetOrder' of your installation, to be performed via the 'Development' > 'API Explorer' page.
Finally, checking the browser's console for any relevant log messages would also help.

[SR-G]

I just restarted with .M4 :

docker run \
        --name openhab3 \
 (...)
        openhab/openhab:3.3.0.M4-debian    

to check chrome console's : there is nothing at all displayed in console.

I don't have any errors in openhab.log, by the way (outside a few WARN like some (for now) empty .things or .rule files) or a few weird things (like an error "cannot instale bindings" (whereas they are already there ...), but not related (and same ones with .M3).
Maybe something is wrong in my .items files (i'm just migrating from OH2 to OH3 and in the end starting everything from scratch) but anyway, they have been built in such a way that they were working with .M3, and they are not working anymore with .M4 as far as i can tell (and i was upgrading to .M4 as there are other issues that i were encountering and that are now solved).

[tarag]

If the location tiles where displayed in M3 and not in M4, it could very well be linked to this PR. What would really be helpful is the result of the REST API call of items, including the metadata. You can send it via email, I don't think there is anything too much sensitive (it's the current state of your installation).

[SR-G]

Yes, sure.
By the way, indeed, i have 0 evidence that the problem is coming from this PR, but by checking the content of .M4, it seemed to be the most possible one (but maybe i'm wrong).

[tarag]

After a quick look to the files you sent me, it seems that the missing location cards between M3 and M4 have no equipment/points, and are therefore not displayed. Looking at your items, it appears that some equipment have 2 parents: one container Equipment, and one Location. This is for example the case of the following Equipment:

    {
        "members": [],
        "link": "http://192.168.8.4:8080/rest/items/gDevice_HueCapteurPresenceEntree",
        "state": "NULL",
        "metadata": {
            "semantics": {
                "value": "Equipment_Sensor",
                "config": {
                    "hasPoint": "HueCapteurEntreeTemperatureBatteryLow",
                    "hasLocation": "gEntree",
                    "isPartOf": "gDevices_Hue"
                }
            }
        },
        "editable": false,
        "type": "Group",
        "name": "gDevice_HueCapteurPresenceEntree",
        "label": "Hue / Entrée / Capteur de présence",
        "category": "sensor",
        "tags": [
            "Sensor"
        ],
        "groupNames": [
            "gEntree",
            "gDevices_Hue"
        ]
    }

Therefore it is displayed in the Equipment tab but not in the Location one, because somehow Equipment belonging has precedence over Location belonging.

This PR makes the assumptions that the model to be consistent with the definitions given in the docs, and more precisely with these sentences:
An Equipment can only be the direct member of zero or one Location, or the direct member of zero or one Equipment. Put another way, an Equipment can only be the direct member of one Group that has a semantic tag.

A Point can only be the direct member of zero or one Location, or the direct member of zero or one Equipment. Put another way, a Point can only be the direct member of one Group that has a Location or Equipment tag.

@ghys : Are these descriptions no longer accurate ? Not having a single parent will lead to all sorts of difficulties one all my recent PRs... For example, what parent to display in the path of the item, the Equipment or the Location ?

[ghys]

(...) Put another way, an Equipment can only be the direct member of one Group that has a semantic tag.

This is false! You can only have at most one parent for a given relation type (isPartOf, isPointOf, or hasLocation, not considering hasPoint because it's not reliable) but it is perfectly valid to have multiple relations when they're not incompatible.
So an Equipment can be part of another superequipment and also have a location (for instance, a lightbulb both part of some central lighting system and also located somewhere), and a Point can be both a point of an equipment and directly related to a location (for instance, a temperature setpoint both part of a thermostat equipment and defining the target temperature of the room itself).

For example, what parent to display in the path of the item, the Equipment or the Location

In the Location card, I think the equipment path (as you already know the location), and in the Equipment card, the location path.

[tarag]

In the Location card, I think the equipment path (as you already know the location), and in the Equipment card, the location path.

This change, and the others that might be link are not trivial so at least I made a quick fix that restores the way Equipment and Points were previously selected for Location cards. At least it will prevent users from seeing disappearing items in their Location cards, while a more in-depth solution is found.

A new PR has been made: #1385

[matchews]

I'm running 3.3.0.M7. Noticed some issues a couple releases ago, but not sure of the exact version it started.

With the new accordion options disabled, something appears to have disrupted my existing tree structure using the group details action.

This image shows the members of gHayward are all displayed rather than being hidden until I select it. This was accessed from the location card.

From the overview layout, using a shortcut to the gHayward group, it still mostly works. It just isn't showing the item to display (water temp mem).

Any input is appreciated!

Thanks

[tarag]

Could you explain the model tagging of these items? I suppose Hayward OmniLogix is an Equipment and its children are also Equipment ? Are there any Points below OmniLogix ?

Please show me a screenshot of the Model page with this group expanded.

[matchews]

Thanks for looking at this tarag. Hayward OmniLogic only has equipment for children, no points.

Here is the entire sematic model.

I noticed that this item is not showing up in the model on either parent:

Thanks again for your help. Let me know if you need any more information. Please note this new behavior is not limited to this group. There are a number of others doing the same.

[tarag]

I did not check again as I'm running everywhere on the milestone 3.3, but my understanding from version 3.2 code is the following. When displayed in location cards, an Equipment would be displayed as a header (divider) and all the points of that equipment would be displayed below, but sub-Equipments would not be displayed at all. To get sub-equipment displayed then the parent equipment should not have had any point children, and in that case the Equipment would be displayed as a list item leading to the group contents (not only the model contents). This is probably what you were used-to from the Hayward OmniLogix equipment since it does not have Point children.

I thought this behaviour was a bug, or at least something only partially implemented so in this PR, I made sure that all the model children of an equipment are displayed in the location cards, wether they are points or sub-equipment. I agree that it changes what you were used to but is this really an issue @matchews? No you get the contents of the OmniLogix equipment with one less click. On the other hand, if you'd prefer not to have everything displayed at the first level then maybe switching to accordion is a good solution for you ? Then we can see how to get the temperature displayed where you'd like.

What do you think about this unexpected change @ghys? Was 3.2 design about sub-equipment on purpose. I don't recall that from our discussion.

[ghys]

To get sub-equipment displayed then the parent equipment should not have had any point children, and in that case the Equipment would be displayed as a list item leading to the group contents (not only the model contents). This is probably what you were used-to from the Hayward OmniLogix equipment since it does not have Point children.

I think it works even with Points.

I have 2 cases of a location>equipment>sub-equipment>points tree they're still working as expected both with the accordion feature disabled and enabled.
When it's disabled only the top-level equipment are displayed in a flat list with dividers, and the sub-equipment groups are rendered with the default list item widget, which in case of Groups is to open a "group details" popup.
When it's enabled these list items will act as an accordion instead of opening the popup and you get a tree of your model instead.

@matchews if I'm not mistaken, your temperature point above is a member of 2 equipment groups at the same time ("Body of Water" and "Heater") and that is not supported by the semantic model - perhaps that's what causing the problems.
What's supported though is to make it (and others, like the setpoint) a member of the Location group (gPool) and they will then normally appear as badges in the card's header.

[matchews]

I've removed the duplicate group memberships on any items with more than one parent with no change in behavior. The new accordion feature is nice, but still does not show the "Item to Display" as setup in the default list item meta data. With the new Equipment List/Display sub-equipment levels feature set to either option selected, or no option selected, I no longer see the "Item to display". Thanks again for the help.

[ghys]

Ah OK, I just got what you meant by "item to display", you redefined the 'item' property of the group to display the temperature.
Then your culprit is #1398. For group items like yours it will redefine the after property to clear the value in an attempt to avoid displaying unnecessary "NULL" states, and it takes precedence over the redefined item's state.

As a workaround you might want to set one of the after or badge properties to =items.YourTempItem.state for a similar look. Still it should have worked.

[tarag]

@ghys, maybe we can revert #1398 and do the simple and evident correction you suggested in the comments there instead. There might be other people using itemToDisplay in groups, I had not thought of this setting possibility.

@matchews, if you use accordion presentation and also 'promote' the temperature item by setting the widgetOrder to 0 and selecting the right option, you will get the temperature displayed as the header of your heater group.

[tarag]

I just issued the corresponding PR #1435.

[matchews]

@tarag, Thanks for the tip. I like the promote functionality for read only items, but it doesn’t allow you to control items.

@ghys, Can you elaborate on the “after” property? I’m not familiar with this one and not finding any documentation on it.

Thank you both for the help!

[tarag]

Thanks for the tip. I like the promote functionality for read only items, but it doesn’t allow you to control items.

It does allow to control item, and that's the main reason I coded it. I find it very useful to get the most used functionality promoted one level higher. Unfortunately, a very recent PR breaks the event handling in the accordion item and therefore breaks this functionality. I hope the correction is merged for 3.3...

Can you elaborate on the “after” property? I’m not familiar with this one and not finding any documentation on it.

The after property allows you to set the text displayed at the end of the line. It is normally used to display the item state, but you can set it manually to the item value, which will circumvent the bug. You need to select the "Show Advanced" checkbox to see it.