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

Add-ons UIs
, ,
848

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.

849

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

850

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.

851

Hello,

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 ?

852

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
853
854

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.
Sorry!

855

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

856

@marco_hoefle

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.

857

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"
when
	Time is Shutter_OG_Diele_Strasse_timeUp timeOnly
then
	if(Shutter_OG_Diele_Strasse_timerActive.state == ON) {
		Shutter_OG_Diele_Strasse.sendCommand(UP)
	}
end

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"
when
	Member of gShutter changed
or
	Member of gShutter_timeUp changed
or
	Member of gShutter_timeDown changed

then

and find out with
var strItemBaseName = triggeringItem.name
and
g.members.filter[i|i.name.equals(strItemBaseName)].head

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.

858

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:

859

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,
Nico

2 Likes
860

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,
Nico

861

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:

862

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:

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

mainWidget

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

widgte_FloorsAndRooms

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

widget:Rollershutter

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

https://imgur.com/a/h9FFgug

https://imgur.com/a/xiusNYR

grafik
grafik344×653 18.8 KB
grafik
grafik352×656 16.1 KB

All the best,

Nico

1 Like
863

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.

BR
Hans-Jörg

1 Like
864

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

865

@All,

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

866

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.

867

Done !

Great! Looking forward to seeing it.