Well, the Group element is very useful to my usage because it implicitly contains its children without me requiring to create child elements.
Sure, if there was a way to give the “semantic model root” as the root for the sitemap, it would make my life easier. But it wouldn’t change the need for a group value as a copy of one its members because when I look at the “outside” location, the most important information (to me) is the temperature. At such a high level, I don’t care for the battery level of the temperature sensor, nor should its value have any impact on the value shown for the group.
Today, I can sort of do it for contact equipment where the “main” value is its Open/Closed state, but the battery level impacts the “One open then open” rule in some hard to determine ways.
With two numeric values like temperatures, it’s even weirder where it seems to be working if the numbers have the appropriate dimensions.
That’s why I suggested this idea of “value from one item” aggregation because it makes for a codeless stable approach.
Well, I beg to differ, some are shown, but I don’t know how the decision is made:
Those three locations have a temperature/hygrometry sensor and yet, one is missing the temperature for some reason.
And I can’t even figure out why the “Bureau” has no temperature nor humidity despite having a sensor of that kind as well.
And that’s precisely what I want to avoid doing, there should be a “codeless” approach to all this. Defining a custom widget for each sensor type is tiresome, and replicating the model view with custom pages is a sure way to forget things.
I know some love to fiddle with configuration files, and it’s great for specific use cases, but there should be a straightforward automatic way that makes for the simple tasks. And having a group value be a copy of one its members makes for such thing, I believe.
The state of Location and Equipment tagged Groups are not shown. You get a card for each of your locations on the Locations tab. And that card shows the state of some of the Properties that are under that Location (the badges). But the Location Group itself has no state and if it did it wouldn’t be shown.
Inside the Location card each Equipment is represented as a heading, but no state is shown. the Equipment Group is expected to not have a state.
Nowhere is the state of the Location Item nor the Equipment Items shown. Only the Point tagged Items have their state shown. The Location tagged Items are only used on the Locations tab and one card is generated for each Location that has Equipment or Point tagged Items as members. The Equipment tagged Items generate the gray header rows in the list, no state is shown. Note I probably selected a bad example with the } because presently those Items do not have a state to show due to some errors I need to fix, but you can seethe Point Items above and below that show their state.
On the Equipment tab one card is generated for each type of Equipment and Location but again, the actual Equipment Group Items only generate that gray header row with the label. Only the Point tagged Items get their states shown.
On the Properties tab, one card is generated for each Property and each Point is represented as a gray row with the label and neither the Equipment nor the Location is represented in any way (though I think there is a setting to enable the showing of the Equipment and Location which will generate the gray row with the label as seen on the Equipment cards.
Note, I mislabeled the arrow in this last one and am too lazy to create another one. It should be labeled “Point”, not “Property”.
It’s either not tagged the same or something else is going on and we’d need details to figure that out. I believe for temperature the badge shows the average of all the temperatures in the location and if one is NULL maybe problems can arise? I’m just guessing.
But what badges get shown depends on the semantic tags of the Point Items that are members of the locations. You can also configure which badges get shown on a per card basis if there are some you don’t want to show.
There is, the Semantic Model and the Locations, Equipment, and Properties tabs. And in none of those places is the state of the Equipment Group Item nor the Location Group Item shown even if the Group had a state. That’s the source of my confusion about this request. Let’s assume there were a way to select a single Item to provide the state of the Equipment Group. You’d never see it anywhere in the “no code” parts of the MainUI,
Only for sitemaps, maybe, but I’m not completely certain there. If you use the Group element does it show the state of the Group or does it only show the > to open up the subframe showing the members of the Group?
Definitely not for MainUI. MainUI doesn’t show the states of Location or Equipment tagged Items anywhere. It only shows the states of Point tagged Items.
To be honest, it only does so if the group item label has the [%s] marker at the end. It can also be the group widget that has this special marker inside its label.
sitemaps have never been no code (the default sitemap was pretty much unusable)
adding a half measure that impacts MainUI, HABAp and others to make just sitemaps work just a little better is less preferable to a more comprehensive approach
OH currently already has a no code UI implementation in the Overview Page tabs. So for now (an unless someone takes up this and decides to implement it) that’s your no code approach.
But that doesn’t mean sitemaps can not nor should not be updated to support “less” code. The Group element for sitemaps has always only been barely usable. So instead of disrupting a bunch of stuff outside of sitemaps I’d much rather see changes made to just the sitemaps to make them easier to use. For example:
make sitemaps semantic model aware and/or able to build itself based on the semantic model
make the Group element on sitemaps more usable
be able to control sorting
be able to control the default sitemap element for each Item under the Group
show/hide certain elements based on that Item’s state/metadata/etc.
select what Item’s state (if any) to show for the Group element row itself
I can get behind all of this. I can’t get behind a Group aggregation function that selects the state from a single Item. That’s not aggregation. That’s going to cause problems with HABAp. That might cause problems with MainUI. And it doesn’t move the needle hardly at all to making sitemaps require less code to make a usable one. The cost benefit doesn’t check out in my opinion. It’s too much disruption for too little benefit.
Having a NULL value here is really bad looking, and I don’t understand why it shouldn’t be possible to have that “Equipment” group get a value that is the copy of one of its members.
If, in the future, there is a way to generate elements of pages/sitemaps/habpanel/mainui automatically from the semantic model, it’s going to be even more ugly to have NULL/UNDEF at all but the deepest level.
Well, that settles it then, and that’s too bad I wasted so much time trying to explain something that seems obvious from where I stand.
If your concern is entirely the visual effect, then it is possible to make that equipment look however you want. That is what the standalone widget metadata does. You can make a widget that shows the state of any item from within the equipment, or any two, or makes each item’s state dance across the screen one at a time (note: not an actual recommendation). Once you create that widget you can add it to each equipment group with just about the smae amount of effort as adding an aggregation function (possibly even less). Bonus: if you add it to the marketplace it becomes a nearly 0 code option for you and everyone else!
The best part is, once you create the standalone widget that you want, you can then put that anywhere else too. Not only will it show up on the model view, you can add it to any user created page with just a few clicks.
But it is, in the end, just an appearance change it doesn’t in any way involve changing the state of the group.
I think this may be where the philosophical disagreement is. We can’t fault your opinion, it’s your opinion after all. That model page you are showing, however, really is a very deep level. That is not intended to be a user UI page, it won’t ever work well as a user UI page. It is a system administration page. For that reason, most users aren’t concerned about if the null is ugly, but want the most accurate information.
One of the amazing things about MainUI though, is that you have enough control to pretty easily change that for yourself so that it matches what you want to see, and no major change in the underlying group code is required. This isn’t saying that your wish-list item isn’t worthy; this is saying that you can have you wish right now! No wishing necessary, you can just go out and do it.
OK, so set the State Description Pattern on that Item to ' ' and the NULL goes away. I could see how setting that pattern by default when creating Location and Equipment would be a good idea. But note, the state shown for any Item on that page represents the state when the page was loaded. Neither the Model nor the Items page gets updated with Item events.
Or set a default stand alone widget metadata that represents the entire equipment (or just one member, what ever you want).
Note, as an admin settings page, the Item states shown in the Model do not update. You have to refresh to see the latest Item state.
Not if they follow the same pattern as what get’s generated by the semantic model now and don’t try to show the state of the Equipment and Location Group Items.
But it’s important to be clear. “Pages” is MainUI. And MainUI already generates pages using the semantic model and this is not a problem there. The states of these Items are not shown because they are assumed to not have a state. If autogeneration is added to sitemaps it should be handled the same there and not show the state of these Items, or support a way to define the default representation of the Gorup similar to the default widget metadata MainUI uses.
It’s ultimately an XY problem. You’ve decided on a suboptimal solution to a problem that is better solved in other ways, several of which already exist in OH. But it seems you can’t get past your preselected answer to the problem.
But also, I don’t have veto power. I’m not a maintainer. But I do know more about the larger OH ecosystem than many and can see how proposals like this can cause undesirable impacts elsewhere in the system and might be solved in better ways.
So let’s step back and restate the problem:
“I don’t like to see NULL for the state of Semantically tagged Group Items in the UIs. I’d rather see nothing or something meaningful with minimal code/configuration.” OK, so we are talking about what you want to “see”. So shouldn’t the solution be implemented in the parts of OH that show you the Items rather than the parts that handle data management (i.e. setting the actual Item states)?
Having an aggregation function is not the only nor even the best way to achieve that, not only because it has impacts on other parts of the system, but because it’s implementing a visual solution at the data/model layer of the system. Visual solutions should be implemented at the visual parts of the system.
There are other options.
If you don’t want to see anything at all, set the State Description pattern to an empty string or space which suppresses the state in MainUI in the Model and Items page (the state isn’t rendered for these Items anywhere else anyway)
a. I could see an issue to have this created/set by default for all Locations and Groups created through MainUI. I’d support that though I’m not sure it’s feasible.
If you want to see something add a “default stand alone widget” to the Location/Equipment where you can show as much or as little of the states and controls as you want. So if you want to just show the temperature for the equipment, it’s very simple.
Like @JustinG says, that’s as easy if not easier than setting a Group aggregation function. Only it’s even more flexible because you can configure that widget to be as much or as little as you want it to be.
In sitemaps, if you want to see nothing, omit the [%s] from the label.
If you want to see something, modify sitemap UIs so the Group element supports specifying the state to come from some other Item than the Group Item. This would require code changes in core, webuis, iOS app and the android app.
Make the sitemap semantic model aware and suppress showing the state for Location and Equipment Items. This would require changes in all the same places as 4.
Bonus 2, it’s available now. And there’s quite a lot of stuff on the marketplace already that you can use from others.
an interesting option will be in the .items file a flag for the items to choose to not persist…
everytime i try to create a .persist file i only made disasters. So at the moment i persist everything…
There kind of already is with Design Pattern: Group Based Persistence. Just put the items you want to persist into that Group and set up persistence to only save that Group. Anything not in the Group will not be persisted.
