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

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.

Every widget in the marketplace contains information about what groups/items are needed and how they have to be tagged semantically.
Did you follow this?

Please show us the items which are not shown in the main_widget page.

ok, lets use the rollershutter as an example:
According to the description of the widget nothing special needes als long as i don’t want a fancy name.
This is the model for Groundfloor and Dining room:
This is the equipment:

This the the rollershuter for my dining room

and this is how it looks in the page, no shades:

You missed the part describing the schedules and very important

A Switch item to enable/disable the automatic/time control [mandatory]

This definitely needs to be created within the Rollershutter group, otherwise the widget will not be shown.

I am using this widget and the description:

As i don’t use time based triggers here i thought this part of the description is ot relevant. i will test it tomorrow as i need to move to an appointment now.
Thanks so far

Sorry if the docs are a bit misleading……

i have created the mandatory item automatic/time control and it is working now.
I found another issue: the last line in the widget contains after the “90” some " ` "

which are visible on the page as well.
i have deleted them in my widget copy and now it is working as for the 50/60/80.
Will continue now to figure out why the lights are not shown as expected.

Thanks, will correct this!

Hi, i realy like this concept and already implementet it in one of my OH setups.

I was thinking of how to add a customized space in the home view for additional buttons or switches
Without interfering with the existing design?

Whatcwould be the best approach?

Can you elaborate a bit more what you want to achieve ?
Actually there is near to zero way for customization without changing the existing widgets. Hence you need to track your changes and reimplement if we will publish updated code.

I have some general items like switches to turn on/of rules of the “scheduler”
or a switch to enable the presence detection which I like to add to the main screen.

I was also thinking of adding an additional section to the footer similar to the security or scenes one for those items.

You will need to add widgets to FloorsAndRooms under the HVAC widget, one for each item you want to add.
You can limit the visibility to „Appliances“. There is a bottom menu entry that is unused actually.