# Roadmap to Happiness - What is missing in the core framework **URL:** \ **Category:** Runtime\ **Tags:** development, eclipse\_smarthome, core\ **Created:** [October 23, 2018, 1:09pm UTC](https://community.openhab.org/t/roadmap-to-happiness-what-is-missing-in-the-core-framework/54522 "2018-10-23T13:09:36Z")\ **Posts on this page:** 1\ **Showing post:** 65
**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\ **Post date:** [October 25, 2018, 5:03pm UTC](https://community.openhab.org/t/roadmap-to-happiness-what-is-missing-in-the-core-framework/54522/65 "2018-10-25T17:03:11Z")
> [@dotorg](#): > > Instability and inconsistency in the common interface bindings, Z-wave being the worst offender. Its not a core OpenHAB issue, but the need to run non-standard builds for typical things like security bindings in Z-wave. It makes it hard to keep up to date on anything because you just never know what is supported where, if your entire install is going to blow up, etc. This is, IMO, the #1 issue I’ve had, and I’ve heard from others, where switching to OpenHAB is concerned. Its one thing for ESH to say “hey, we’re the framework, that’s a binding thing”, but OH needs to work – and work properly, out of the box, every single time – with the big two or three automation standards. With that and simple-to-install systems like OpenHABIAN would make OH the automatic choice for people who want more capability than Smartthings or Vera can provide. One can counter with this that the non-standard build was an alfa test intended for testers to exercise the new features in the binding. In the commercial world there simply would not have been and still would not be any support for security until OH 2.4 gets released. What you are describing is not standard operating procedure for typical OH users. It was intended for the alpha and beta testers. The only reason so many people who are not necessarily testers went down that path is because many people would not or could not wait for the fully tested and merged in version became available. > [@dotorg](#): > > One UI. This is an issue that really hurt Linux as an OSS solution on the desktop for most of the 90’s and naughties – too many desktops, too many ways to do things. Its a huge issue for OH that you need to use Paper for some things, Habmin for others, BasicUI for yet more. Nevermind the confusion over which scripting engine is best to use, or NodeRED, etc… Like the last bullet, lacking this OH will never be the choice of people who want their automation to just work, and it’ll be stuck as a “this is my hobby and what I’m spending my free time on” sort of solution. Many on this forum, myself included, would argue there should be two UIs. One UI created for the users of the home automation and one UI created for the builders of the home automation. You don’t want to present a UI designed around managing Things and Items and bindings and such to your house guests. But ultimately this is not something that OH can control short of shutting off the REST API entirely. Anyone can write any UI they want. It’s an open interface. And it’s an opensource issue. I don’t think you will ever see this addressed until and unless someone creates a commercial offering based on ESH. OH is and always will be a more open and inclusive platform. And I think that is an important point for people to realize. OH is not intended to become some polished and unified commercial offering. The trademarks and licensing would prevent that. This is why there is an ESH in the first place. So from that perspective, OH is and always will be something more on the bleeding edge and more something used by enthusiasts and hobbiests. That is what it is here for. > [@dotorg](#): > > Better state management for devices, and clearer association between things/channels/etc. This is really a core architectural “issue” in ESH, but causes a lot of non-developers confusion. People don’t think about channels, they think about things. A non-developer doesn’t think “when the power status of this channel > associated with this light changes and the value is ON, do this other thing”. They think “when the light turns on, do this other thing”. Every other automation system treats things as a more concrete concept. You mean something like this? ![image](https://community-openhab-org.s3.dualstack.eu-central-1.amazonaws.com/original/3X/5/a/5a8566db837808bdddc66282478d0a93ac8347d7.jpeg) > [@dotorg](#): > > In terms, though, of smaller things that really should be in the framework and probably could be, the most useful thing for me would be a simple way for implementing the “when something has been happening for x amount of time, do y” or the inverse “when something hasn’t been happening for x amount of time, do y” pattern. There’s a lot of manual-intensive ways of doing it in scripting, but that’s a core eventing capability in pretty much every other system, and one of the most common one people use. Have you explored the Expire based binding? I’m not arguing against the idea (I like it), just offering less code intensive ways to do this now. See [Design Pattern: Expire Binding Based Timers](https://community.openhab.org/t/design-pattern-expire-binding-based-timers/32634). I’m still exploring the Experimental Rules Engine but I think this is something that might be doable with a minimum amount of code. --- _[View the full topic](https://community.openhab.org/t/roadmap-to-happiness-what-is-missing-in-the-core-framework/54522)._