Some great steps are already done on initial installations, but integration of more features of openhabian-config in WebUI would be something to make openHAB more user friendly for someone not familiar with Linux (or lazy guys like my …):
I know. And I was not trying to critizing openHAB. Its a highly difficult task. I was just trying to point, that its an very important task, as most people want to get fast results, without have a feeling of spending years in studying every aspect in a smart home enviroment.
I know… And I have been struggling trying to find the “holy grale” in how this is done the best way. I have no idea, maybe because I´m no developer and therefore cant spot the real deal in making things possible.
But, one thing that often comes to my mind is, a list of design templates for pages, in specific sizes.
Like pre-defined pages (templates), where the user just drop cards/widget onto, and only need to concern for configuring the widget.
My typical issues are, that the system is highly flexible. Usually we want that. But that also mean, that the user have to understand each and every flexible option. And that can become very time-killing.
Each time I create a new page, I feel I´m starting all over, even defining the size, placing cards etc. And when I finally believe I have got it, I see the end result all screwed up, not really fitting its purpose as I thought.
As for widgets, its the same… Finding something that looks interesting, but almost everytime I have to change it exactly to suit me needs. Again, this is due to widgets beeing flexible. But it also mean, I have to spend time learning how to fit my needs, again.
I wonder if it would be possible to do this with a minimum time spending, by the cuase of loosing some flexibility. And still end up with an nice looking modern dashboard, which fits perfectly into whatever device the user have chosen.
Difficult? Yeah.
Impossible? I have no idea 
Although I can’t find a smoking gun I suspect a memory leak in the mainui browser side scripts. Since the 4.2 version a 24x7 running dashboard crashes every 2/3 days. Restarting the dashboard (so not probably not an OH server issue) will get it running again. I’m hoping upgrading to the latest clientside frameworks will improve this.
[edit, did something wrong, was intended as a response/support to a post about upgrading vue and other frameworks]
And thats exactly why openHAB has so many options to create a dashboard YOU like.
I am using oprnHAB for 12 years now. Had a well structure Sitemap for openHAB 1 and 2. Starting with openHAB 3, I changed my UI a lot, finding many nice ideas in the community and on the marketplace. Since I joined the semsnticHomeMenu project (basicslly took it over) this is the only UI I use. I am adding more personal widgets which follow the design, but those are not published yet.
We are already brainstorming to add it as an easy installable page, so it can be used without a hassle, especially with very low configuration effort. But this will be a long way.
And alot of options means, alot of stuff to figure out 
To be able to creat epersonal widgets, the user have to figure out how to…
To be able to use (add) widgets already suitable, the user are on their way with very little hassle.
Glad to hear! 
@joriskofman are you interested in handle such a general thread for idea collection
Now I don‘t get you. How does this go along with your former comment?
Sorry, but you (@Pedro_Liberal ) did not get my point for many things I wrote.
In my opinion openHAB should not be something the nerds can use well. HomeAutomation is for everyone and not just a small group.
Second, when I say that HomeAssistent does something better then openHAB, then this does not mean I want to use the other product, and even if I would, it does not mean that openHAB shouldn’t do things better.
Why do people always weight products against each other and make it a sinn liking something an other product does better? Copying what is good and improving it in this process is the smart way to do things. When you look at products that are successfull for a long time they do excactly this. Of course additional inovation is required as well to become better as the other products, but copying the successful features of the oponent is what everyone does - Apple copying Google, Google copying Apple, Samsung …
This said I understand that some of my suggestions might not be welcome by those users who type faster on the command prompt then others using a modern IDE … still I feel those are innovations openHAB needs to get adopted by more people and not less.
I meant, the difference in adding an already exsiting Widget or creating a new one.
Just like Rich replied, too, please file an issue right away (on the openhab/openhab-webui repo).
I think you can already access tabbed pages with xxx/n (n a digit), so that should not be hard and maybe can even make it into earlier OH versions.
And that’s why openHAB is a volunteer project.
openHAB is for everyone because everyone can volunteer.
Instead of comparing to home assistant you can detail the improvement you want. That is well accepted. If you consistently compare it to other application (home assistant is of course a close relative) people will simply tell you “then use that instead.” Talk about functionalities instead of other applications, or if you can develop them yourself, or create an issue in GitHub to allow devs the opportunity to consider them. That’s how openHAB has consistently grown in the last years, by the community taking action.
Adding is simple, but creating complete new widgets can be a bit tough, cause of all the styling options/possibilities framework7 gives you. I don‘t see a way to make this easier.
That’s right, you can simply build simpler dashboards.
What I have just experienced again is that OH is being compared with another known system by end users. And this system has nicer out of the box dashboards and also simple options like theme templates to customize the look without having to deal with CSS, F7 and whatever else.
For us here who have been working with OH for a long time, elaborate may be easy, but someone who has to decide on a system and is only slightly enthusiastic about technology will, in my experience, decide more quickly in favor of a system where he doesn’t have to deal with code first.
I’m not a frontend developer either, but if you had options such as font size, font, general color themes (Color Themes | Framework7 Documentation) etc. by default alone, it would be easy for simple technology enthusiasts to choose OH.
I think that what could ease new comers life is being suggested, when they install a new binding, to a list of widget that goes with it. Eg, integrate in the UI the result of such a query : https://community.openhab.org/search?q=netatmo%20%23marketplace%3Aui-widgets%20order%3Alatest when you install the Netatmo Binding.
Maybe also, as we have the marketplace for rule templates, widgets, provide UI pages templates ?
Providing UI templates (pages) seems to be a nice idea, but we would need volunteers to implement the needed infrastructure in WebUI (mainUI) first. This will be the bottleneck…
I created issue for this feature request:
When using templates/designs things will be easier.
Or, in my experience, once people get up to speed on OH they never revist the docs to see what’s new and just assume it can’t be done.
That’t not to say the docs can’t use some love, but I’m constantly fielding questions of things that are clearly documented but the posters never looked.
A PR for this was attempted and eventually abandonded due to technical difficulties. That doesn’t mean it can’t be resurected by someone or another try made, but it’s not so easy to implement without eliminating options on where/how OH can be installed.
But the alternative is to not give you the ability to change it to suit your needs. You can’t have it both ways. You get what you get and like it (aka the Apple way) or you can make it exactly what you want it to be but it’s going to be some work (aka the Linux way).
You can have exactly the easily set up UI and UI Widgets right now. Just don’t customize them.
So we already have an approach to automatically generated a usable interface through the semantic model and MainUI Overview pages. You get that out of the box and it’s pretty darn usable. If it’s not exactly what you want, you have some options to configure it but you can do as much or as little of that as you want.
So any exploration in this direction should be sure to keep that in mind. It’s not that we don’t have a usable and very easily generated UI. Maybe it can look better out-of-the-box and there are things that can be done to make it even easier to customize (some of which have already been mentioned). Maybe we need something between the Overview tabs and creating a new Page from scratch to make things easier. But we do have attempts at making the UI easier to get started in.
The alternative is to eliminate:
I’m not sure OH would survive in such an environment.
That’s what the widget marketplace is for. I’ve not counted recently but we have to be nearing at least 100 installable widgets there now.
The hope and intent was that the people who are good at the UI would publish widgets to the marketplace and most users would be able to install and use them as is. I think that hope has mostly been realized but there is room for lots more variety and different widgets still.
The same goes for rule templates. The hope is that for common yet relatively complicated logic, end users install and configure a rule template instead of needing to figure out how to code it themselves. This has not been as successful as widgets. Calling all volunteers!
I have created issues related to the first steps of this sort of thing that have not gone anywhere.
I was thinking that perhaps one can bundle any mix of add-on, rule tempaltes, ui widgets and block libraries in one bundle. Installing that one bundle gives you access to all these parts in one go.
As you mention, it would be pretty cool if you installed a binding that controls thermostats it came with a few nice widgets customized to what that binding offers and maybe a rule tempalte of two which could be instantiated to do common actions (e.g. away/home mode based on information not available to the binding).
I’ve been gently pushing for this since OH 3.0 release.
Note, this doesn’t necessarily need to be limited to the marketplace. If supported I’m sure some binding developers would want to include these with the official add-ons too.
Hello,
I suggest you to link the last Timestamp of the change of any value from a item to a tag or other channel or link, where is easy to show in the UI or available in scripts independently from the Persistence.
The underlying problem:
Sincerely Jens
There is already work in progress for this: Add `getLastStateChange`, `getLastStateUpdate`, and `getLastState` to GenericItem by jimtng · Pull Request #4351 · openhab/openhab-core · GitHub