Roadmap to Happiness - What is missing in the core framework

Hello Community,

I was wondering what is bugging you most because it is missing in the core of openHAB (and Eclipse Smarthome) and what only works with a ton of workarounds and should be part of the core instead. Especially if you compare openHAB to competitors.

Of course I’m talking about the OH 2.4 Snapshot release or Eclipse Smarthome latest git with the new rule engine and the new zwave security implementation.

In a second step I like to open up a new GitHub Issue for each of those topics or find an existing one.

This is what I have gathered from your replies so far:

Logview within PaperUI

This is the only reason for me at the moment to go back to the command line. I’d like to have:

  • A new menu entry for logs.
  • In the binding view, I’d like to see the last x logs for that specific binding.
  • Set the log level for a binding


A binding doesn’t need to tell its user that an error happened and a device went offline. We have the Thing status for this. But what about a warning that a certificate is going to expire or a user interaction will be required soon/now?

Related issue:

Secure connections

  • OpenHAB to external: It is a very manual process at the moment to trust an additional SSL certificate to establish a connection to an external service (weather, amazon alexa etc). The default is to trust all SSL connections (NOT SECURE -> man in the middle attack possible). It should be a click on PaperUI or a single line in openhab.cfg.
  • External to openHAB: openHAB provides a few endpoints to be accessed externally, like the :8080 web-page, the MQTT embedded broker, the REST API, audio streaming endpoints. But there is no way to configure SSL certificates and private keys

Secure Vault for sensible configuration values

Some bindings require usernames, passwords, access tokens to work. And there is nothing wrong about it.
But at the moment those values are stored as plain text in the file system, can be accessed by the REST API by everyone in the network, and all bindings have full access via a comfortable java API on top of that. You have to be super careful on what you download from the Eclipse Marketplace!

Related issues:

Multi-user support with access restrictions

A concept for access restriction is required if more than one person is using the system (almost always the case I guess).

Related issue:

Reliable startup

There are several reports about the framework starting up slow or items / bindings not initialized in time for rules. All reports boil down to a bad / missing startup order.

Relasted issues:

Chained transformations

There are some cases where you need to extract a value first from a structured data format (JSON, XML) and then map the value to one that is understood by openHAB. This can be handled by a script transformation, but chained transformations might be easier to grasp (and are probably more efficient as well).

Update Thing definitions automatically

When a binding is updated the Thing definitions should be updated, rather than having to manually delete/rediscover Things.

Related issue:

Item Metadata: Add REST API to enumerate metadata

The REST API lets you add/remove metadata, but does not allow for reading it.

Post, what you think that is required in the framework, to make it an easy to use, reliable and secure Home Automation system.

If any other developer want to tackle one or more of the listed subjects with me, send me a PN.



Can I add one:

Multi-user with access restrictions. I want my kids to be able to control a few things with the app but not the heating controls for example

There are ways but it’s complicated. It should be accessible from the paperUI


This sort of thing has been discussed, and I implemented something in the ZWave binding a few years ago, but it’s not in OH so doesn’t work with PaperUI etc -:

There is another issue that was also discussed, but it never went anywhere and hence both have stalled.

Both are 2 to 3+ years old but I guess could be revised as I would agree this is a significant shortfall at the moment.

  1. Tracking of which things/items were updated and when.
  2. A rule editor in the GUI. It doesn’t have to be complex. Just something that will open allow editing and save to etc/openhab2/rules
  1. Better graphs. The ability to show a 1 year graph of temperatures at 1 minute resolution in HABPanel from mysql without bringing it to its knees.

  2. Graph functions.

  3. A built-in RRD that works. I’ve used RRD4j - and abandoned it back in 2.2 for mysql. Feeding rrdtool itself would work better. And produces great graphs quickly. (And would solve the previous - graph functions)

1 Like

1: If you have the log viewer, you can filter for Item Changed events. That would be a solution to this point, wouldn’t it?
2: The new rule engine does have an interface for the PaperUI. You basically click your rules together, otherwise I would have this in the list as well. Important stuff to have.
3: Responsibility of UIs not the core, I’d say. A valid think to mention though.
4-5: Yes, that needs to be improved but it is at least already there.


  1. Not really. I want to be able to look at my items and know when they were updated. Even sort the item list by it. With items on 1 line each. having to go to a separate interface (LogViewer) doesn’t make it user friendly (I’m thinking user friendliness and usability here. Not whether a developer knows something is possible somewhere).

  2. I keep reading that the ‘new’ rule engine isn’t ready to use (It does say Experimental after all. And seems to be incompatible with the existing rules in /etc/openhab2/rules. I just went to try & follow the rules engine (Experimental) to the docs (Some add-ons have a link to their docs). The experimental rules engine doesn’t have that link… Again. Inconsistencies.

  3. I don’t agree that the UI’s shouldn’t be core. They’re how the users interact with the product. It’s the first thing people see. And the first thing that puts them off. It doesn’t matter how good the backend is if nobody can use it. Look at all the coll stuff that’s file din the past because it was too hard or too expensive to use (The Betamax rule)

  4. It’s not there… There’s only rrd4j which is not rrdtool.

Currently, my biggest gripe is a lack of any startup ordering. Following an update and restart of OH2, I typically have to restart OH2 two or more times after the initial restart before all groups and DSL rule globals are properly and completely initialized. This means I have to manually monitor openhab.log to determine when a good restart has finally been achieved.


@scottk - Agreed. I dislike non-deterministic software at the best of times.

1 Like

+1 for reliable startup ordering.
@henning mentioned in his presentation he’s working on it or at least is planning to.

@mstormi, That is excellent news! Thank you for the report, Markus.

I wish you a speedy success, @henning.

He definitely didn’t say that - it is just one of the things we consider important to be implemented.
Henning is not working on it.
Good news is, I had some discussion today about a new feature in Apache Felix that should soon be implemented there and which will hopefully be an ideal basis for us to do a proper startup. The related issue in ESH is


Thanks for the clarification, @Kai. Regardless, I’m happy to know the issue isn’t dead (as well as now knowing where to monitor discussion and progress on the related ESH issue.)

I would like to see in the Addons/Bindings page of PaperUI that the version numbers of available and installed bindings show the full version number.

Currently the version shown is only the prefix, not the full version number. When working with snapshots and testing new features it would be nice to look at a GUI instead of querying the Karaf console for that information.

This method would also be a visual confirmation when attempting to upgrade a binding, you could confirm the version number change once you have uninstalled and reinstalled the binding.

An indicator of an updated version of the binding being available next to the version number would be a great addition as well.

1 Like

The Karaf Webconsole would not be in PaperUI, but a UI addon. I have it in my backlog to build this… I’m surprised nobody has done it yet. It is nice to have a UI for Karaf! You can adjust log levels, but the logging view appears to only have the event.log. But you can view a Karaf console in a browser, so there’s all the logging you’d like.

To install, modify /userdata/etc/org.ops4j.pax.url.mvn.cfg to include the Maven repo. Mine looks like this…

org.ops4j.pax.url.mvn.repositories= \, \

Then feature:install webconsole in Karaf. More info here.

+1! To be more specific, System Notifications.

And another +1 for reliable startup.

My list:

  1. Update Thing definitions automatically when a binding is updated, rather than having to manually delete/rediscover Things to update the definitions.
  2. A generic UPnP binding, with separate addons for specific devices, as suggested here. The bulk of the Sonos binding would work for this. Here is the previous discussions about this, and an example project that is currently functional. Not so much core framework, but it makes sense to me that UPnP renderers would be auto-discovered as audiosinks.
1 Like

One more thing:



Maybe a good backup plan?

Today I use the /usr/share/openhab2/runtime/bin/backup /backup/
But a GUI backup/export would be a nice feature?

And since today, these kind of servers start to be very important. Will be a nightmare if it crash today.
A kind of cluster configuration? Where you can run fe 2 servers in a clusters, just in case?


I am a fan of the rrd4j persistence as it is ( working for me). I’m using year charts (plural!) with no problem. What isn’t working for you?

This thread is on requests to the CORE framework.
Backup and HA (highly available) servers can be/need to be implemented well outside of this.
Btw, there’s openHABian to include Amanda.

I’m not sure about the backup topic in how far the core should be aware of it.
At the moment the way you would create a backup is to copy the user files, I guess?
If that is the case the core should be notified to synchronize in-memory values to files first.