Examples of dashboards

As mentioned in another thread

I promised to show some examples of dashboards.

Here goes…
Please remeber, these are just a few simple example to show what can be archived, but not without a huge knowlegde or several hours of working/fiddling.

The last example is my mainUI page as it looks right now :smiley: (dont mind the missing data from the items… Its an cloud issue I cant seem to fix. It works fine in local mode).

2024-12-17 11_52_28-Figma UI kit - Smart Home Dashboard (Community) _ Figma – Google Chrome

2024-12-17 14_01_13-https___www.fiverr.com_s_XLYVjPG – Google Chrome

2024-12-17 14_04_34-Jack R. – Google Chrome

6 Likes

Thanks,
there are some nice designs.
Let me study them briefly and I will come up with some suggestions, but this will take some time…
From first sight I doubt that those will be doable without custom widgets or tweaked versions of marketplace widgets.

Just a quick comment.
The first example is really dificult, as openHAB does not have user management, therefore user based information is not available. This takes a big part of the screen in the example.
Dashboards 3 and 4 are stock/finance dashboards, which I do not see to be valid as templates for a smarthome dashboard. Even the information can be shown on an openHAB dashboard, I will not provide examples for those two.
My focus is on smarthome, not finance.

The widget expressions to have access to a user object which contains the name and the roles of the user currently logged in to that instance of the MainUI. This can facilitate custom displays per user or for specific roles.

I know, but see the lower right of the first example. This is about editing users…

Humm - how about… adaptation? It doesn’t matter much the topic as long as they look - what is decidedly subjective - cool right?
What if we’re talking about a room dashboard, and the user it shows, instead of the user logged in, it’s the person/s detected in the room.
Through… a BLE beacon as an example . Now that would make more sense for openHAB.

And the others, instead of finance why not… energy … overview. Not management. Just showing “these items are consuming this amount of energy” and maybe a line showing the consumption of the current day.

I see these dashboards not for what they are showing but for what we can take from them. Not the content itself but the art, organization, and such.

Another idea: I am definitely not an artsy or creative person. I can use the semantic model and mainUI all day long and I feel totally content. But having even simple dashboards “pre made” for specific content/context (in exactly the same fashion as widgets now that I’m thinking about it), that allow me to add items and do some minor adjustments but that look great are definitely something I would enjoy playing around with.

It could be another “downloadable content” like widgets and bindings. Entire dashboards with backgrounds and we simply add the items, and maybe change some gradients and colors, upload a different background image and baaam.

Man that would be awesome :smiley:
Maybe I should add this to the openHAB 5 thread…

Oh right, I’m now looking at the layout page which I’m starting to feel could have half of the answer to my post actually…

2 Likes

It is already there, thats where it started.

I just wrote, the first one would not be easy, but if other content than user information should be shown, fine.
As a start, we can have empty placeholders, no problem.

Regarding the finance dashboards. I can do the layout, but I am not going to define information to be shown there. This has to come from the community.
If you tell me what detailed information you would like to see in lets say dashboard 4, we can create a draft…

But I am not your dashboard designer…

1 Like

this is exactly what OH5 should focus on if we as OH users want to survive…

2 Likes

What? Anybody can start do design Dashboards, Pages, Widgets or whatever. Don‘t expect me to provide complete solutions. I will help with some first drafts, maybe one complete dashboard.
I am just an openHAB user like you, who started to learn how to develop a binding or create widgets. I am no developer by profession and there are many other things in my life that need my time.

Please dont misunderstand this topic.

The examples are meant as examples of design. What their purpose is in the examples, is not important. Its the design only…
As for the finiance example, a user could exchange the data with Energy readings or anything simular, and there you have a smarthome purpose.
The user management could be exchanged with a present detection, and there you have another smarthome purpose.

The point with this is to give someone (a design developer) an idea of, how a “basic package” dashboard could look like, and then, if possible, create a template including the widgets mentioned as examples in the other thread, all in one design. A template a new user can import quickly to his openHAB setup, and he will be on his way with a great and fast start, including a nice an more modern looking dashboard.

Thats the purpose of the topic regarding the debate we had in the other thread.

Exactly!!
Thank you :wink:

I dont expect anything. I´m suggesting what I believe is an important task to focus on regarding the future of openHAB. Design and easy adaption/implenting for the users.

I suggested a coupple of finished design templates, which ofcouse will require some widgets to match the design as well, as a kind of “basic package” easy to implent for a user, who are not familiar to making designs, widgets, html, css etc etc.

Will it work in openHAB today? I have no idea. Im just the idea maker, not a developer. If not today, then hopefully in the future.

Not as simple as you think.
Financial numbers and energy readings will use different item types which will need different formatting snd styling. You cannot simply exchange the information to be shown. Next issue will be item naming, which will be completely different.

Let me see what can be achieved as generic as it could be…

I never expected this to be simple in anyway.
But whats not simple for a educated or experienced design developer, is totally impossible for a newbie (ordinary user).
Thats why I focused on suggesting this to be an easy to import/change/configure kinda thing, by the use of templates designs.

I think you´re overthinking this one.
The user should still be configuring the widgets to suits his items. No developer can do this for him. But the user should not be concentrating on the actual design, as this will fitt the main design by the use of the template…
At least thats the idea I had.

I never said this would possible in openHAB today. It probably requies some changes.
In the other thread, Rich mentioned much of it could be done by semantic model. But I fail to see how the design would do from a template through the sematic model. Though I have no idea, as I had to give up on the sematic model, as I dont get it at all.
(I have tried a few times, and everytime I read the docs, I get even more confused… Notice, I dont blame anyone on this… I simply had to give up as I was spending too much time going nowhere).

Of course it will work today, but you need more volunteers to do the job.

I will give you example from the main_widget/semanticHomeMenu.

It all started with a user who created the design drafts for the page, the menues and the widgets, to make sure to have a unique look and feel. Those drafts are mockups in PDF documents. Alltogether, we then had 6 developers/volunteers contributing to the project, some to do the styling, some to do the functionality logic. Unfortunately It is mostly me now bringing this to the next level.

You see, it needs someone to start the initiative and then orhers who like the idea and start to work on it.

What we have here is „just a big picture“ I can help to achieve what is on the wishlist, but I am not going to design complete widget sets to build those dashboards. There are other important projects that need my attention….
So if there will be someone to take those dasboards into pieces, defining what widgets will be needed, define a styling base (colorscheme, fontsize etc,) we are a step further.

Please check the semanticHomeMenu. This is the project I described in my last post.

It might seem I am overthinking, but I don‘t believe do,
Yes, everything can be done with individual widgets. But I hate double work, so those should be interchangeable. Users still will be overwhelmed to configure >20 widgets on a single dashbord with unknown number of config options.

I know. And I know that is a hardest part, which is my main concern in this.
But I still find it important enough to be mentioned/suggested. From here we´ll see who catch the ball to continuing.

Exactly! An idea. Thats all it is at the moment.

I cross my fingers, that others may see this as an important focus as well. And then hopefully we can get the idea from paper to work in real life. If not, at least I gave it a try by suggesting this, as thats probably all I can add to the project for a start.

My experiences with the widgets I use, I find them fairly simple to configure regarding which items to use. Hardest part is getting them to match the page/dashboard/design. And when I find a widget which needs some tweaking, Im totally lost as I have no idea what to look for in the code or I have to ask the developer for help.
So I end up using the standard “card” alike sizes and layout, as you can see from the last example in the first post, which make it look totally stupid :slight_smile:

This is my “work in progress” of my Solar/Energy pices/heatpump kinda like page/dashboard… Its nowhere close to what I had in mind, but thats as far as I can go, and it looks like shi*** :smile:

Cause the widget I see are fairly simple configurationwise.
And you look for tweaking as many options for customizing are „hardcoded“ and not put into pops.

Let‘s see where this all leads to…

Your work in progress is the same one I modified and I use it everyday and it just works.
I have tried other solar widgets but I find this one the easiest to read.

There are a couple of different issues that I see here.

  1. MainUI does have strong and consistent design idea. It was built to emulate the “material” design guidelines that were really maturing around the time OH3 came along with this new MainUI. If that design idea doesn’t work for you, that’s OK. I think we all recognize that there’s no one design that’s going to work for everyone. Some users prefer more flashy designs, some prefer even more streamlined and flat designs. That’s where we run into the two bigger issues here.

  2. Creating a “theme” or well-designed dashboard or whatever you want to call it, is not actually difficult. Non-pros like @hmerk and myself can learn to do as part of our hobbies. There are a few moving parts to get comfortable with but most of the rest is just the details, and that’s what reference docs are for. I’m quite sure that anyone on this thread can learn to do it. What it is, is incredibly time-consuming. Here’s a link to the one of the files that defines the basic styling for MainUI. It’s several hundred lines long. And that’s just for the basic styling of the main app itself. Each component, each page, have additional styles as well. I’ve never counted but I’m pretty confident there’s over a thousand lines of style directives across all the various parts of the UIs. Would creating a new design for a dashboard require over-riding all of those thousands of lines? No, but a good percentage of them yes, and even then you can’t actually over-ride many of them, which brings us to the other issue.

  3. As it currently stands there is no supported way to actually modify the style of the base app. All the styling capabilities that currently exist will only work on the custom pages and widgets. The outer MainUI frame with page menus and the all administrative pages are currently outside of what users can modify with custom system. It’s still possible to create novel and attractive custom pages (and even display those pages with a minimum of the app frame interfering), but it’s worth keeping in mind that you can’t expect to overhaul the entire app without a major refactoring of the complete MainUI itself.

2 Likes