One reason I closely watch threads like this is becuase often the requests are already implemented or often started to be implemented. As long as we don’t go too far off topic, a thread like this can become more useful to learn what’s already possible than in how it influences development of the next verison of OH.
6 Likes
I could not agree more Rich
2 Likes
If someone would volunteer and create a structured wish list where users could upvote feature requests, it would be far easier for contributers to choose a feature to work on - rather than trying to make sense of a few forum threads with more than 600 posts total.
I guess it could be solved using github issues in a separate project?
1 Like
I would like to see the addons more decoupled from the core release…
That new addons / bugfixes can be introduced without releasing a new minor core.
Of cause, sometimes they depend on some changes in the core, but that’s mostly not the case…
Or is there any other reason I do not see?
1 Like
I would like to have one enhancement for MainUI that can make editing tabbed pages a lot easier.
I often use tabbed pages to display different charts on one page. But when I want to make some changes to one particular tab page, I can’t navigate to edit this page directly. If I use the edit button in top right corner I get to the tabbed layout, where I can manage the tabs, but it is not possible to go directly to page of one particular tab. I have to check the page UID and find that page manually on Pages list or using developer toolbar.
So having the link leading me to the page would be really nice. Something like this:
edit: I created feature request in github: Add "Edit page" link to tabbed pages · Issue #2899 · openhab/openhab-webui · GitHub
1 Like
I strongly recommend that anyone with a concrete idea for an improvement to file an issue on the relevany repo. Just make sure the issue is:
- clearly stated what the end goal is, not necessarily how to implement it (let’s not flood the issues with XY Problems)
- testable success criteria (how do we know when it’s done?)
- relatively modest in scope (i.e. do not require major changes across multiple repos, do not require major changes to the basics of how OH does things, etc).
Honestly, this is probably the least important thing when it comes to whether a new feature gets added to OH. The most important thing is that someone volunteers to implement it. It doesn’t require a poll to make that decision. If a developer decides they want the feature for themselves or if they think it’s a good idea, they will volunteer to implement it.
A poll also can lead to disappointment when the top voted wish doesn’t get implemented due to lack of a volunteer.
That’s a good and interesting point…
If it’s possible to release faster addon patches?
It is possible already, since a long time, to get updated addons from snapshots or PR builds. Furthermore, all devs can publish their updates for testing on the marketplace.
Absolutely. But I suspect filing 100 feature requests in either repo isn’t going to be very welcomed by the maintainers. Thus the suggestion for a separate project/repo.
Of course. I respect your personal opinion, and mine is as follows: As a volunteering developer, finding exciting ideas (and not just solving my immediate personal needs) isn’t to spend days reading endless discussions on this forum.
By my count we have maybe a dozen issues that would be spread between openhab-core and openhab-webui right now that meet the criteria.
But one of the beauties of an all volunteer project is there is nothing stopping you from setting up a repo, a forum post with a poll, or what ever you think would work.
Which is why I recommend issues that meet the criteria above. As has been mentioned in this thread and elsewhere, only a few of the maintainers are all that active on the forum and maybe two of them will probably read a thread like this. But creating another post or some new repo or something else isn’t likely to get their attention either.
If you want a developer to see it, you need to put it where they work, in an issue on GitHub in the proper repo. If a developer is looking for ideas to implement, they are most likely to look at the issues there first anyway. There is no shortage of open issues to choose from even now.
2 Likes
yeah, the OH 4.0 wish list had a poll or running list or whatever in the OP
hey @milo wanna turn your post into a wiki then anyone can try to dig thru this and create a running list
edit for: oh yeah great thread +1
So maybe we should one thread for all upcoming features whites maintained by a moderater because I see a lot on the list in the oh4 thread which are again up here 
1 Like
Modify the gain-offset profile for general usage apart from modbus.
Some Things send states with multiplied values and the gain-offset profile sometimes work but with edits of items linking the recalculation fails.
I think a general gain-offset profile is substantial for any interface.
OH seems to be very powerful but more for software experts.
More examples for basic functions in the documentation would help normal users using OH.
Personally I am still a bit confused of the arrangement of Channels and Items and how the are shown in different configuration windows.
OH team should think about the dedication for normal users or for experts.
There is no openHAB team to make such a decision. Everyone can volunteer to extend the docs or tutorials or whatever.
I totally agree on this one.
Adding devices is important. But if its possible to present it in an easy way, modern looking dashboard, then the motivation will rise alot to do more.
This has never been easy in OH, in my opinion.
1 Like
That tells me, there is something wrong somewhere. Either missing documentation, misunderstandings, or simply the requests/options are too difficult to spot.
What has never been easy in openHAB?
Can you be a bit more specific?
1 Like
Creating a modern looking dashboard/UI (end-user).
This is very user specific and openHAB already has many many options to create one.
But feel free to come up with a proposal