openHAB 3.3 Milestone discussion

This topic can be used to discuss problems/experiences/questions on the openHAB 3.3 milestones.


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).


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 ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at ~[?:?]

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.


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 :face_with_monocle:

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.


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:

  1. 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.

  2. 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.