[OH3] Main UI - New „main_widget“ - development and testing [deprecated]


thank you for your up to now. Unfortunately at the moment for me the documentation is not so far to use it, but the design and idea is great.

Two questions :

  • Should it only work to smarthones or also on tablets ?
  • Is there planned, that the user can change the automated layout and add some additional widgets ?

thanks for reply

Should is only works on smartphones or also on tablets ?

We are working on improving the documentation and the will be a big update soon.
In generall, it will work on tablets, but the design is mainly made for smartphones.

You already can change widgets or add new ones, you just need to make according changes to FloorsAndRooms.

1 Like

What do you want to tell or ask ?
This topic is not about other widgets tha the ones we develop and publish.
So the Conditioner Card for Daikin AC is out of scope here.

OK sorry…
I didn’t know this thread didn’t belong to this, I just wanted to ask for help


Thats not completely correct.
The rules posted are proved working when created simply through the UI.
What rule language did you try?

EDIT : Sorry, saw you asked about groups. I am not using groups for the rules, you need one rule for each timestamp.

I am using DSL .rules files. I would need four of those when using weekend support which I have to do soon as my wife was today under the shower when the shutter opened :slight_smile:
Good that she adjusted the time herself.

rule "rule-storen-timer-up-OG_Diele_Strasse"
	Time is Shutter_OG_Diele_Strasse_timeUp timeOnly
	if(Shutter_OG_Diele_Strasse_timerActive.state == ON) {

So for example for this rule, which calculates a next action string like next_action = "▲ " + timeUp,
I can use groups:

rule "storen-timer-next-action-string"
	Member of gShutter changed
	Member of gShutter_timeUp changed
	Member of gShutter_timeDown changed


and find out with
var strItemBaseName = triggeringItem.name

which item caused the trigger and serve it accordingly.

So the same rules serves all Roller-shutters for the task “next action string”,

This would be handy for Time is DateTimeItem timeOnly too.

As long as we don’t have such a feature in openHAB, you have to live with having one rule for each device. :wink:
And that’s what I have documented as well, one rule each.

This is getting even more complex when using the extended Radiator Control as well, as It will support timestamps for comfort and eco temperatures, following the sme logic.
In my installation,this means

Radiators : 10 x 4 rules
Shutters: 7 x 4 rules
Total: 68 rules only for this little bit of comfort :wink:

Hey @hmerk , @Dimitris , and all other involved design-guys,

Very impressive widgets and designs :slight_smile:
Thanks for sharing :wink:

I’m going to take a closer look at your great work!

all the best,


Hello @hmerk,

I had a rough look at your results.
The concept is very interesting but also very complex. I mean here the structure of the page with variables.
This makes it impossible to program WYSIWYG in the widget editor.
Or I don’t know the trick? :sweat_smile:

Is there a reason why you didn’t put the navigation on items?
Mainsection-Item (as string) with HOME, FLOORS, ROOMS as possible value.
Subsection-Item 1 for FLOORS
Subsection-Item 2 for ROOMS

The values of the items are set by the repeaters.
This would also make it possible to control the content via e.g. rules.
e.g. In the morning the HOME content is displayed.

Surely there is a reason why you preferred variables. :slight_smile:

Thank you very much,

all the best,

Yes, it is very complex, but to be honest, this parts of the widgets is not mine, kudos got to @Nic0205.

As I (we) already see some performance issues with the extensive use of oh-repeater components, I started thinkin about a complete redesign and moving to itemPrefix usage instead.
Still under the aim to achieve a nearly zero config solution for the users.
We have to check whether there would/could be side effects, as oh-repeater is actually the only way to fetch metadata like uiSemantics, which is used for the fancy naming.

Is there a reason why we should use Items :wink:
I think no. IMHO, usage of items will introduce another issue, as you would always come back to your last selection, wanted or not. Even excluding those items from persistence would lead to that, as long as openHAB service is running.

Anyway, really appreciate you started that discussion, as it might lead us to overthink some parts of the concept. :+1:

Hi guys,

I found some time and analyzed the concept and the widgets more deeply.

I’m not sure yet if the approach is the best, because in this concept specific widgets on pages are not possible. For example: I want Cards to Climate, Shutter and Lights but additionally another custom widget under the chapter Rooms, Livingroom. This is not possible with the current concept. Another way would be to place the sematic-cards (rollershutter, lights etc. from this concept) in Room-pages, so that there is still the possibility to add custom widgets.

But as is well known, several paths lead to the goal :wink:

It would also be a big step forward if semantics were accessible via widgets and expressions.
For example: items[“Testitem”].name, items[“Testitem”].sematics.config.isPartof and so on.
Now the standard only includes item.state and item.displayState.

Maybe this is something for the future @ysc :wink:
Through this, many oh-repeaters can be replaced and more functionalities can be used.

Anyway, I accepted the challenge and tried to implement the design concept further. :smiley:
I also made various adjustments for a responsive layout. The current widgets were not optimally programmed for responsive layouts.

All my adjustments and suggestions are not to be seen as criticism. Everyone has different ideas and there are always several solutions :wink:

But now to the intermediate state.

In general:

I have removed the variables and control the chapters and things via two items. This way it is also possible to control the view via rules. I don’t know which is better :-D. But this is the biggest change in the concept, which I did only for myself. The owners and designers of the concept are @hmerk and @Nic0205 (as I see it). I don’t want to change the concept fundamentally at this point. Above all, enough time has gone into it. :star_struck:

For this reason I can’t publish any codes at the moment, because they are not backwards compatible with the concept favored here. (objVar)

When I find time I will implement the variables again and share the yamls if interested.

At this moment my comments as a design suggestion.

Major changes:


  • Removal of the oh-repeater to change floors and rooms. Instead f7-swiper components. This reduces the required computing resources (I think). The filter and map functions take a long time because of the nested components. Adjustments of the swiper possible depending on the screen size (more responsive).
  • Various style adjustments to use f7-variables. If possible I advise not to use hardcoded colors.
  • Instead of css-flex I used a css grid. This way the top-bar and bottom-bar are always fixed and the flex-content (sematic cards) is scrollable. It also works with flex attributes :wink:
  • The bottom-bar has the style of @Dimitris design.


  • Integration of responsive cols and rows
  • all components got a f7-col. So the design is responsive.
  • The repeaters are now nested in containers. So the repeater runs at intial site load and the container is always generated. The benefit is, that the repeater never runs again on change the room selection.


  • the timepicker is still missing. i have not implemented it yet.
  • The chart looks a little different because items for aggreation series cannot be used as props. There is a bug here. As far as I know this has been fixed (ISSUE, I tested the last snapshot but got some errors in the log so I went back to stable).
    As soon as the bug is fixed, the design can be made better via aggreated-series and a bar-chart.
  • the expand area was solved via css classes

Here is a little demonstration.



All the best,


1 Like

Hi Nico,
thanks for taking your time to dig deeper into the code and improving it. From what I can see in the screencast, I really like how you changed the responsive design.
I was also thinking of changing the segmented layout for the top menu to the swyper usage as you have done, but was struggling with the navigation arrows, which sometimes had been to close to the buttons and therefore usage was not always possible.
I would really love to see you code, once you have reimplemented the timepickers and the objVar. As already told via DM, I do not like the approach of using a String Item with arrays for the menu selection, but that’s another story.
From what I could see atm, great job !!!

I will try to define some issue and PR/MR templates soon, then I can publish the link to the github repository of main_widget (still don‘t like the name but don‘t have a better idea). Once this is done, I will announce it here.


1 Like

@Nico_R One additional comment, you have changed the color scheme for you screencasts. Could you please change it back to @Dimitris design before posting. Thanks.

And what I also saw in your screencast is the hoover background when selecting a menu enty. Could you please remove this. Does not look nice from my perspective.

Regarding your wish/need for different widgets depending on the selection, I would call this an edge use case. There have been some more requests for non standard uses cases, which I (we) would not like to implement as a standard.
Instead, we will provide (at a later stag) instructions, how to add individual widgets in addition to the standard widgets included.

Bu t I don‘t think you will need those instructions, as you are familiar with the code.


As already mentioned, I have created a github repository with the latest codebase for this project and defined some issue templates.

The repository can be found at

This repository can be used for issues (bug reports and feature requests) and for pull or merge requests (PR/MR).

I took the color from the suggestions at some point. Of course only very roughly (background and so one. left in the standard). I did not invent it myself. :wink:
The many posts of design suggestions are difficult to sort.
Can you please put centrally in github the latest versions?

Development… :wink: Here I didn’t change anything on the default button in the css hover class. But that’s no problem.

As soon as I get to it, I’ll adapt the latest version of the main_widget so that a responsive design can be created here. Following then floors&rooms. I’ll try to get the compatibility, so that the existing cards can be used.

Done !

Great! Looking forward to seeing it.

So do I understand it correctly that each type (Light, Shutter, Heating etc.) has a different colour scheme?
There is no global colour scheme for all cards?

Another question: Shouldn’t it be better to define an icon set? Iconfy icons and f7-icons behave differently in the container.

Yes, but I am not the master for this. What I understood and implemented, e.g. the HVAC is using different colors depending on the mode Item.

I we could find nice Icons for all needs in one source, that would be better. But we could not find any and did not want to implement custom icons which need to be copied to the openHAB server.

Feel free to make a suggestions regarding icon changes. :wink:

i was following the development of the new “main_Widget” since the beginning. Now i want to implement it for my smarthome.
I have created the model when i migrated to 3.x of Openhab and it is working with the “old” main page. I am running the Openhab 3.4.2 now on a Raspi installed with Openhabian.
I have downloaded the Main-UI widgets from the market place and created a layout page with the given code.
Unfortunately i don’t get the result as expected. I get the floor und rooms, but no rollershutters and limited lights.
Is there any kind of documentation available, what are the mandatory parts in the model and/or what are the limitations. Are there any metadata in the model which are mandaroy?
Any guidance is wellcome.