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

Hi @JustinG , @hmerk , @All

I would like to propose a git repository (GitHub or GitLab) instead of posting code snippets - at least the “released” once only into the community pages.

I believe this make collaboration between the involved parties easier and contributions to these great widgets better controllable.

Additionally it would easily be possible to see what changed between two released versions.

I would volunteer to create the public repository in GitHub and copy the current versions of all widgets into it as a start.

Let me talk to our maintainers, perhaps we can setup a repo under the openHAB domain.

1 Like

For floors and rooms, this is mandatory. Equipment will try to get the uiSemantics, otherwise fall back to labels.

Hi all,

a probably wiered question, but how to I get the configuration parameters passed to the weather widget?
e.g. I can’t get the itemPrefix set in the Main-UI.

All items are available and it looks great in the widget editor:

but in the Main-UI the items cannot be found as the itemPrefix seems to be unknown:

Those params are fixed in the home card:

        bigCard: true
        dateFormat: true
        itemPrefix: OneCallAPIweatherandforecast_
        locationTitle: =props.locationTitle
        sunIndicator: true

So your item prefix needs to be correct, like in the original widget.


I was afraid that was the only way to do it.

Wouldn’t it be nice to be able to configure all items the same way through the “page setup” (settings/pages/layout/<pageid>) as it is possible with locationTitle?

Then all page-widgets could remain unchanged - and easier maintained - and we have a single source of truth for the configuration?

It would have the drawback of having to connect all items through e.g. Main->Home->Weather but I think it’s worth it.

No, what we want to achieve is a zero conf solution with gathering all needed information from the semantic model.
The original weather widget only uses the item prefix as param and also sets a default value, cause it would make manually configure the widget to complex. Think of a 12hour forecast with I think 3 or more items per hour, plus weekly forecast…
If you follow the guidance to create equipment from thing and set the prefix like shown, you don‘t need any config for the weather widget/card.

Location is a bit different, as I did not find a way to retreive this one from the model, but still working on a solution.

OK - makes sense :-).

So instead of having to configure the itemPrefix you goal is to retrieve this info from e.g the WeatherEquipment (SemanticType == WeatherService)?

Hm, did not think of this. let me check.

Edit: Yes this should work, I will put it on the short list for the next update.

Edit2: Only solution I can see so far is to create a „normal“ openweathermap thing and bind the stationName channel to an item to pass it into the widget.


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: