openHAB 4.0 wishlist

Hello All

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)
  • Stronger data typing post by @bartus
  • More javascript examples in documentation post by @tcgerhard
  • Ability to create rule snippets post by @tcgerhard
  • Ability to create and manage things via javascript post by @tcgerhard
  • Debugging engine/sandbox to debug rules post by @jptaszyk second by @joriskofman


OH UI Widgets

OH UI Drag and drop

OH Core




openHAB app



  • This is my best interpretation of the wishes and is up to date to post 76 in this thread
  • The list is in no prioritized order
  • I just collected the wishes, i do not judge :slight_smile:
  • I have not removed wishes that could be interpreted as solved in the following replies
  1. 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.

  2. 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.

  3. 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.

  4. (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.

  5. (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)

1 Like

on my wishlist right on top:

  • more mass-data editing

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)


  1. I want to copy the contents of a binding/channel/thing/… and insert it and want to be able to re-use this
  2. 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.


Changing items is sometimes a nerve-racking job.

  1. You are in the items list and scroll miles down to an item or start typing in the name.
  2. you make the modifications to the item and as soon as you press „store“ it jumps back to the top of the items list.
  3. so you continue with point 1)

It would be nice, if the return point in the items list would be the item you have modified.


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

1 Like

[quote=“joriskofman, post:1, topic:142388”]
and indeed that any script could be used as a transform

This is already possible in 3.4.0: Transformations | openHAB

Dear santa I wish that

  • 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.

+1 for backup and restore through the UI


What dou you mean by that ? Custom metadata namespace, e.g. uiSemantics already exist and can be used on all items.

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.

1 Like

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 mean that anything beyond this list: openhab-webui/namespaces.js at 3.4.0 · openhab/openhab-webui · GitHub does not get any form. End user is forced to write configurations by hand using yaml, even if openhab-webui/bundles/org.openhab.ui/web/src/components/item/metadata at 3.4.0 · openhab/openhab-webui · GitHub components which are used could be defined using config descriptors and core functionality of framework. Even if complexity of ie. homekit or alexa exceeds designed capability of config descriptors other binding-rule-misc-specific cases might be perfectly fine with regular metadata descriptors.

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.

1 Like

As you are a dev yourself and don‘t be satisfied with what’s existing, why not contribute to that then :wink:

scenes !!!

1 Like

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.


I wonder what is the right way to handle a device disconnected from the network :

  • Having the thing “ONLINE” (meaning the handler is functional) and a dedicated channel “online” like network binding does it
  • Having the thing “OFFLINE” without dedicated channel (like done in Netatmo binding).

I’d like your insights on this and OH4 could be a good time to enforce a single way of operating on this.

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.

1 Like

Add the ability to associate tags with things the way it is done for Items.