I’m pretty happy with OH (Compliments to all the maintainers and the community!), so my list is short.
It’s about simplification of basic tasks when it comes to problem solving, setting up and keeping the solution running:
A simple way to set a bindings logging into e.g. DEBUG mode from the UI. This way we could avoid explaining how to do this in the console over and over again.
“Backup” button that does backup the whole config ( or selectable parts) and provides a http-download as a result
“Restore” button - restore a backup that was done using the “Backup” button
A consistency report/check that, as result, shows where e.g. in the UI items are referenced, or where there a links to channels that are no longer available. Very often the log does not not provide useful information as the items name is not shown. A global text search for items, things, channels etc would be helpful as well.
For me those topics have been missing since the beginning and should be part of the solution to make it more user friendly - a need to dig into the console keeps users away.
I know about setting up a backup with e.g. Amanda, but in the end this would simplify it for new users to try out things and reset to a previous state a lot.
Same is true for setting log levels, this is very often the first thing when running into issues with a binding and for new users it always ends up in the console - goal should be to flatten the initial learning curve and to make things more user friendly.
Getting a consistency report will help to figure out what is wrong in which place without the need for lucky guessing.
I don’t know how widespread use of openhabian is but one of the items that comes up repeatedly in comparisons to home assistant is the requirement to use the command line to maintain the system. How about porting the openhabian-config functionality to the web gui to make setup and maintenance easier for less technical users.
I’m also very happy with openhab(ian) and thanks a lot to everyone who put their efforts into supporting it!
There is just one thing on my wishlist:
I would like to have a matter binding, so that I can connect other matter devices within openhab (e.g. hue bridge), but can also present any items via matter e.g. to Amazon Alexa or Google Home.
From my current understanding other bindings like hue, Amazon, google home, etc would than be obsolete and it would therefore save the valuable time of people contributing
handling of schedules and other complex data structures in openHAB is supported in 4.0 release. Neither ical/google cal binding nor existing ephemeris and rule engine functionality is solving trouble of boiler controller reporting its program.
custom metadata namespaces, beyond core and predefined addons, could have their own config descriptor which is not hardcoded in UI itself.
I am afraid, your understanding is not correct, as not all existing hardware will support matter, so the bindings will still be needed. But don‘t let us start a matter discussion here, there has enough been said regarding this in other topics and issues.
openHABian offers you a menu for all relevant administration tasks, providing enormous value:
you don’t have to know the commands, it validates the input for you, you cannot mistype, it automates and shrinks a series of commands you would need to enter correctly to single clicks menu selections.
That’s a big improvement over and not to be confused with what is commonly understood by the term “command line”.
Any user that would be able to do maintenance task X with a web version can do exactly the same in the text version today. A web UI replacement would not add any benefit whatsoever.
That’s just a pseudo argument, often misused in comparisons or “reviews” done by people that don’t understand how the systems they write about work, probably never even used 'em.
PS and off-topic. Thread is a wishlist on openHAB.
I can think of for example persistence service using metadata for specifying base untis for stored quantities or generic purpose rules which could use metadata for their work.
Come on! That’s a lame excuse in my eyes.
We’ve come a long way from downloading bindings and dropping them in some (seemingly everchanging) directories to first PaperUI, where I could do that with a click and some typing and then to OH3-GUI, where it is even more comfortable.
You can’t just weep away some legit requirements especially for entry-level users!
Experienced users and those capable of differentiating between SSH, openhab-cli, openhab console and openhabian-config will have no trouble whatsoever using openHAB. #
But the learning curve wouldn’t be so steep if the menu and some of the heavyily used functionality only possible with a bash would be reachable within openHAB-GUI: getting SSH activated, SSHing to my raspberry, knowing the difference between the console and openhabian-config and knowing what to type in in the console do just adjusting log-levels… that’s a pretty steep learning curve for somenone just wanting to walk some first steps into openHAB.
doesn’t mean, openHABian is superflous - it’s not.
Other thing I thought would be to standardize some very common configuration items like :
ip Address,
hostname,
macAddress
We could this way progress in associating a Network Device to a thing hosting one of these components.
My thought on this is still fuzzy, but I wanted to share.
This would allow retrieving a list of things by tags in helper libraries, the way it is done for items.
Doing so, you could for example easily define of list of things would want to monitor ONLINE/OFFLINE status.
I understand your point, but I think it needs way more than just adding tags to things. Even the UI rule editor would need to alow filtering things by tags, not just bindings with wildcards for the things.
