This topic can be used to discuss problems/experiences/questions on the openHAB 3.3 milestones.
5 Likes
I donât see it in the downloads page.
Thanks for noticing - I had indeed forgotten this. Now it is there!
1 Like
This milestone includes 2 PRs (labels and sorting) that will hopefully help to get cleaner/more meaningful secondary model tab pages (Equipment and Properties) almost out of the box in main web UI, while not compromising the readability of the main Location sub-pages. This will probably require rework of a few item labels and setting some widget order metadata by the administrator.
One deals with the labelling within model tab pages, which is improved by displaying the path inside the model leading to an item to provide context, either in the dividers of Equipment (Equipment pages), or in the subtitles of Properties pages items (rather than the non used friendly itemâs name). This allow defining label of item only providing information in the context of its parent in model (location/equipment) and not duplicating model inside the label: i.e: not having to use âJohnâs Room Bedside Lamp Color Tempâ label but only âColor Tempâ on the Point Item label, within a âBedside Lampâ Equipment inside âJohnâs Roomâ Location. Another PR might come to have the same kind of labelling improvement for vertical groups groups outside of model pages.
The second improves sorting, so that the resulting items are placed in consistent places among all model tab pages (sorting uses both Item's widgetOrder metadata but also the position inside the model and the widgetOrder on this Item parent model groups - Equipment/Location). When sorting several items within the same location/equipment in model, widgetOrder or the alphabetical order is used as before. But in a non-same-location context (Equipment or Properties pages), in case of ambiguity, the widgetOrder of the parent Location/Equipment is used in order to sort lines in consistent a repeatable fashion among all pages. Therefore, if you define widgetOrder at the Point level (within an Equipment) to display Point of greater importance first, but always choosing the same value for equivalent items (for example for lamps 0 for ON/OFF, 1, For Dimming, 2 for Color. or for thermostat 0 for set point, 1 for actual temp, 2 for heating/cooling modeâŠ), at the Equipment level to choose frequently used equipments before others, then at each location level (house, floorâŠ) to choose Locations of importance before others, you should have something that makes sense in the Equipment and Properties pages (all similar-function items sorted in consistent location order).
6 Likes
Would this thread be the correct place to also mention issues with bindings that come with 3.3 release?
Not really, If you have an issue with a certain binding, please open a new topic under the bindings category.
1 Like
I updated from Oh 3.2.0 to oh 3.3.0M1 via openhabian-config on as raspi 4b.
All bindings, rules etc. working as as expected but main UI only loading the overview page.
Locations tab, equipment tab and properties tab are not loading.
This happens on 3.3.0 M1 and the following snapshots, if i go back to stable 3.2.0 everything is working again.
I can confirm this behaviour.
You probably have loops in your semantic model groups.
Some of the changes in 3.3M1 rely on a recursive analysis of Groups in the model to create a matching tree structure from the list of Items received. If there are loops in the model Groups (i.e. My Room > Ground Floor > House > My Room), which makes no sense, this will lead to an infinite loop in the browser. This will cause the model dependent pages (Location, Equipment and Properties) to be unavailable (and cause a very long loading time).
I have tested with a loop on Location tagged Groups and observed the same behaviour you describe, with the following error in the browser javascript console: Error while loading model: RangeError: Maximum call stack size exceeded.
Can you confirm seeing this error ? (Safari > Preferences > then Develop > Show Javascript console, or for Chrome View > Developer > Javascript Console).
I also see that in server v3.2 there are already some stack overflow error in this situation. I assume the same kind of infinite loop occurs:
...
at org.openhab.core.io.rest.core.item.EnrichedItemDTOMapper.map(EnrichedItemDTOMapper.java:90) ~[?:?]
at org.openhab.core.io.rest.core.item.EnrichedItemDTOMapper.map(EnrichedItemDTOMapper.java:62) ~[?:?]
at org.openhab.core.io.rest.core.item.EnrichedItemDTOMapper.map(EnrichedItemDTOMapper.java:90) ~[?:?]
at org.openhab.core.io.rest.core.item.EnrichedItemDTOMapper.map(EnrichedItemDTOMapper.java:62) ~[?:?]
...
Nothing in the UI prevent the creation of such loops (when using the Items pages), and it is also quite easy to create them in Item files.
Iâll file an issue about this.
2 Likes
Yes i can confirm this error.
Error while loading model: RangeError: Maximum call stack size exceeded
I try to find the loops and report back.
The groups causing issue should not be visible in the Parameters > Model page, even though they are tagged as Location/Equipment//PointâŠ
Found it, it was a group in a group.
In the Items page i searched for group and checked all groups which are not generatet in the model page, but you have to look very carefully. in my case 4 times 
no need to clear the cache, after each change you should check if itâs working!
Thank you very much @tarag
One thing I donât like is the new Equipment tab
It shows the full model hierarchy instead of just the equipment name
1 Like
I agree. Is it possible to move this to an opt-in feature or setting? It seems to provide quite a bit of visual clutter for very little benefit (at least in my configuration). This also goes for the same change on the properties cards.
2 Likes
You can disable those pages in the home settings.
I want the pages. Iâd like to disable the new breadcrumb headers on the cards in those pages.
As far as Iâve seen (albeit only a very cursory look) there is no way to do so. This only useful under a very particular nomenclature setup (one where semantic names contain bare minimum information), so itâs not going to be a feature that every users needs or wants.
1 Like
I think they might go away when you define a custom list Item widget for the Item. That seems to be the case for me at least.
I havenât looked to see whatâs different or if there is a new field or something to turn it on or off on a per Item basis but appears to be possible at least.
The first two use my custom List Item Widget (can be found in the marketplace) and the last two are completely unaltered defaults.
I hadnât noticed that yet (just loaded up the milestone this morning). Defining new custom widgets for everything just to get rid of these is little bit of overkill even for my obsessive nature. Plus, that only fixes the property cards. On the equipment cards the breadcrumbs are in the header lines which we canât impact with custom widget (to my knowledge).
1 Like
This change avoids redundant labeling in the 3 model pages while allowing non-ambiguous labeling in all of them. I have not found another possibility to reach this goal without providing another metadata field to define various labels for each page.
Iâve had good feedback regarding the result of these changes from users in setups with dozens of equipment (several hundreds of points) and many similar equipment in various rooms (e.g. one thermostat per room), using only automatically generated pages (no custom widget).
As I wrote above, it relies on the assumption that you label the model without redundancy, or as you say, the bare minimum to fully define one location/equipment/point in relation with its parent. Bare minimum sounds good to me. No redundancy means less work in an initial setup and less work in case of change. In your case this means for example that âMaster Suiteâ > âMaster Bedroomâ > âMaster Bedroom Fanâ groups would simply have to be defined as âMaster Suiteâ > âBedroomâ > âFanâ.
There is always room for improvement but I personally think that ultimately openHAB should automatically provide the lightest but non-ambiguous labeling in all pages with the least amount of work for the admin and sensible configuration options as always in openHAB spirit. Therefore Iâll try to continue to propose PRs that improve labeling in other automatically generated pages (thinking about graphs), and also provide access to this labeling for vertical/functional groups.
There is no big issue to provide an option to keep the previous behaviour in the next milestone, and perform a few tweaks (remove the top level Location which appears to be identical in several setups).
Concerning the Properties page, again, I donât think user-facing pages should display Itemâs name except as a placeholder when a label is missing in the configuration.
All of this is my personal opinion and of course @ysc as both the maintainer and the author of the UI will have the final say wether we should revert to 3.2 behavior or go forward in this direction with configuration option to keep the old/new behaviour as an option.
1 Like
I have no objection to the addition this feature, and youâve done a good job with it. I merely think it should not be the default or only option, but an opt-in feature. As a default feature, it does something that, in some ways, is completely antithetical to OHâs design: impose a nomenclatural âidealâ on users. If a user chooses this kind of nomenclature, then this is a good option to have. Pre-supposing that all users prefer this is, IMO, a step backward.
As Iâm sure it does to many users. I can, however, say with certainty (myself being one of them), not to every user. In fact, for me this is an active step backwards. The âredundancyâ this is attempting to fix is not a significant issue for me or my users. A repetition of one or two words (e.g., âMaster Bedroomâ) in a header or footer is far less problematic when visually taking in an interface, than a long chain of verbiage, much of which is completely extraneous to the task at hand. It is distracting and more difficult to parse.
I do not want to take this feature away from users that do find it useful, I am only advocating that those users be able to opt in to it.
Yes, it is clear what you would like me to use as a nomenclature, but as I explained in the initial thread about this, that âsimplifiedâ version doesnât work for me, and the only thing I am pointing out is that because it works well for you does not mean it is a universal solution. In my system it has several significant disadvantages:
-
This is actually less useful in terms of a natural reference. This is only the âfanâ, if I am standing in the Master bedroom. In all other cases it is naturally referred to as the âbedroom fanâ or even the âMaster bedroom fanâ. It is only the âlightâ when I am standing in the kitchen, otherwise it is the âKitchen lightâ and if I am going into a natural user interface to interact with this device I am thinking about it in a natural way. Taking that information in from two sources is more difficult than reading it in a single label and it is extra difficult if I have to follow a long chain of extra text as one of those sources.
-
In all the custom widgets I have that aggregate similar devices, having each of them with the label âLightâ or âDoorâ becomes completely useless. In those widgets it is essential (and continues to be sensible and natural) to have the labels contain that extra bit of information whether or not it is âredundantâ with the equipment label. So I should rework all of my widgets to also traverse the semantic data in order to add some sensible label to the items being used?
The way I see it, this does not actually reduce any work, it just shifts that work (for example see above: widget development is now more difficult). The work has to go in somewhere and it should simply be a personal preference as to where not a one-size-fits all approach.
3 Likes