Since it is now very close to christmas, I first of all want to pass my best wishes to the community, and also wish everybody a happy new year.
I also wanted to in the spirit of christmas to start a little “dear santa” style wishlist, maybe we can get all of those good wishes out in the open.
Dear santa I wish:
I have gone through the wishes that have been posted below and sorted them by topic as best i could. I will refer to the original posts where more in depth descriptions are given of the wishes.
Rules and scripts
That the script part of a rule could be split from the rule into a separate script without copy pasting (OP)
That transforms would be treated as just another script (and indeed that any script could be used as a transform) (OP)
Create new item, thing, channel with other item as a template (OP)
Default choose the one thing in a list of there is only one thing in that list (example create a new mqtt thing i have to choose the broker even though i only have one option) (OP)
More “drag and move” mechanics. For example, setting up a dashboard is a bit convoluted. Let me drag, drop, resize the widgets around.
Or when setting up the semantic model, iirc (haven’t played too much with it yet) there’s some fiddling there as well to get things in the right order.
User management. A way to add more users with different basic permissions. I know I can do it in cli. Need it in gui as well.
E.g.: add wife to allow her to create her own dashboards, with her own user account. She wouldn’t need to add or configure bindings, but creating items and mess with the semantic model would be required. Or better yet, aside from a couple basic roles, allow me to create roles and set them up as I require.
a standard and simpler solution for high availability. Yes I can use proxmox and such, but in my head I think it would make more sense to have openhab be responsible for its own solution.
(new!) A simpler way of using the state description pattern through the Main UI to pick, choose and display units, that do not require using special characters. E.g.: if I want to display my units in watts, let me choose through a list menu, drop-down menu of similar, and have the unit automagically appear in the item/dashboard/mainUI etc.
(new!) linked to previous topic:
Add a link to the relevant documentation to help those who might not be familiar with it. E.g.:
*) metadata / state description : link to UoM documentation
*) rules menu : link to rules documentation
If there is a relevant documentation page, it should be accessible through the UI (just like the bindings and widgets are. Which btw, excellent work)
What do I mean? I’ve got loads of similar items and/or channels, which I just want to copy and change a tiny bit. Having to do that over and over and over again in the UI is a pain in the a…
Using text-based configuration it was easy, but I want to leave that path behind me.
also: as I forgot one time to put “create equipment from thing”-items in the correct parent group, I’m now left to change a bazilian of items to their correct parent… exhausting (because they already have persistence and logic attached to)
So:
I want to copy the contents of a binding/channel/thing/… and insert it and want to be able to re-use this
I want to mass-change a configuration: let’s say items, which are in the wrong parent-group, item-types, item-definitions, … by clicking on them in a list and then editing their configuration all at once
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.
