make it also possible to do the Page Layout and Location via file based configurable, for those, they have already file based configured everything else since a long time in openhab.
also to download and configure templates from the marketplace.
that would be great
If you mean the Locations tab of the Overview Page in MainUI than you already can define most of it via file based Items. Everything you see there is driven by the semantic model and “default list item widget” Item metadata.
I believe OP asks about making his own, custom page definitions stored in files, not in items.
I think he was asking about both. There isn’t anything now but on the horizon to support widgets and pages through text configs but there is already support for “Locations”.
is it possible to show in the items detail page (UI), in what rule the item is used, like in a rules file?
like a bulb item item, where I can see, in what rule it is added and is doing something.
Not right now but the Developer Sidebar search now searches in rules, widgets, and metadata so if you search for an Item name you’ll get all the rules and widgets that Item is used in by name. I think it works for both text based and managed rules.
But if you are using text files it seems it would be more effective to use the “find in files” of your editor and/or grep rather than searching it clicking around in MainUI only to need to go back to your editor to do something about what you’ve found.
Note, it’s just a text based search so if a role uses an item indirectly l such as through a Group or by dynamically constructing an Item name that use will not be found.
The amount of calculations required to determine that case would be pretty high I would think because there is nothing a rule does to tell OH it’s using a file until it senda s command or posts an update. And there’s nothing to tell the Item from whence the update or command came. So OH would have to somehow run through every rule with every possible trigger for each rule and every possible combination of Item states and then stimulate the execution of the rule to know whether an item is used indirectly by a rule it not. I’ve but done the math but this feels like an NP type problem.
That’s because I have well defined the structure of my system in the semantic model and browsing it directly or implicitly via default sitemap widgets is not nice.
I’d rather not have to recreate the same information in the widget side of things, I would like for it to be automatic.
But I see that once again my suggestions are pointless so I’ll keep the other ones to myself (forward only group state propagation to item command, automatic group membership, use UI scripts as scripts in other rules…)
It wasn’t a rhetorical question. It was a request or more details on how this would be used given the already existing ways that OH supports this use case.
That’s why I asked the question. If you are using the sitemap, you probably are getting very little benefit from the semantic model in the first place. The sitemap doesn’t know nor does it understand the semantic model. And if you are trying to use the semantic model with the sitemap using the Group element, a better request might be to make Sitemaps more aware of the semantic model to support this use case than to somewhat break the purpose of the concept of Equipment in the semantic model by giving it a state derived from only one of it’s members.
I can think of a lot of things that the sitemap could do with the semantic model to make building sitemaps better. But for now, I indeed am a little bit against corrupting the concept of Equipment and Groups for the purpose of making the semantic model work better in a place where it currently isn’t. In some cases half measures are worse than full measures.
So think bigger. I don’t use sitemaps so I’m probably not the best to come up with ideas. What could sitemaps do with the whole semantic model to support new use cases or existing use cases better?
If you are really referring to the Overview page on MainUI (Locations, Equipment, Properties) the state of the Location, Equipment Groups are not even shown in the first place, so what would be the point? If it’s semantically tagged as an Equipment, the only way to see it’s state is if you build a custom Page and put a custom widget that uses that Equipment Group somehow on that Page. The actual state of the Group wouldn’t be used.
FYI, it even is able to search within blockly rules (and then with the blockly rule itself you can search the blocks with Cmd/Ctrl-F even further).
2 Likes
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.
It shows the state:
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.
OK, so we are only talking about sitemaps then?
Then I’ll reiterate that:
- sitemaps know nothing of the semantic model
- 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.
2 Likes
No, it’s just an example of a part of openHab that happens to kind of work.
But look at the semantic model view:
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.
First navigate to the Equipment Item
Then choose “Add metadata” and “Default Stand Alone Widget”
Change the Item to the temperature Item that’s a member of that Group.
Done.
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.
2 Likes
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.
1 Like
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.