Directions for openHAB 3

(Rich Koshak) #62

You’re gonna have to tag it’s location anyway, so what are we really saving? Personally, I’d rather see Dimmer renamed to something more generic like “Level” than see a proliferation of Item types which ultimately just end up being different names for the exact same functionality. I don’t know if there are other current Item types that are not sufficiently generic also, Dimmer is the only one that comes to mind.

But I’m not going to code it so my opinion doesn’t count for much.

There is a very real benefit to users, particularly new users, by limiting the types of Items that they have to choose from. If you define a Dimmer and a Volume, what is a new user going to think when they want to represent the level of their oil tank? They won’t see an OilLevel type and assume we don’t support it.

(Yannick Schaus) #63

Because then you would have dozens of item types, possibly in a (object-oriented) hierarchy, and it would be a mess if not introduced properly to users. Hierarchies usually are hard to grasp - a limited set of ‘primitive types’ however, along with a ‘kind’ which gives more information about their nature is a good compromise.

(Michael Cumming) #64

That doesn’t make sense to me, to say we shouldn’t have more item types, because someone has to tag an item location?

There easily could be a generic level type, but if there wasn’t the number type would cover that.

A greater selection of item types if done properly, doesn’t add complexity, it reduces it.

That’s partly what the Homie MQTT specification does.

(Rich Koshak) #65

Well, as with anything in an opensource project. If you feel strongly about it, open the issue or even better submit the PR.

(Michael Cumming) #66

Sure, a major/minor descriptor could be used. That’s more of a hierarchically approach than a flat list of item types - which you suggest is harder to grasp.

(Michael Cumming) #67

Is that your way of saying I didn’t convince you so go do it yourself if you want to?

I was hoping to engage in a dialog about ways to make OH better.

(Rich Koshak) #68

Not at all. it’s my way of saying indeed you haven’t convinced me but I don’t really care that solely about it. And I’m not a developer nor am I maintainer and you don’t have to convince me. I have no power to either make it happen nor to keep it from happening (unless it comes befire the AC, which I don’t think is likely as either the maintainers will agree its a good idea or not without too much contravercy).

While I think these contravercy are interesting and I learn a lot from them, I’m also getting burned out on them. For three weeks I’ve been spending a while lot of time and energy playing diplomat and I’m burned out. It’s not a measure of your idea, I just don’t have the energy to argue about it. And even if I did, like I said, you don’t have to convince me. It wouldn’t do any good if you did. You need to convince a developer to take on the significant effort of implementing it (or become that developer yourself) and the maintainers to agree to accept the PR.

This might go befire the AC though because it does impact almost everything from Rules to the UIs to the bindings. At which point perhaps I’ll be rested and able to devote more than the little bit of thought I can manage right now.

If you do want to engage in the dialog, I do suggest starting a new thread. This one is anyway very long and very heated.

(David Graeff) #69

@rlkoshak I sometimes have the same feeling. Take a break for a few days, watch an awesome sci-fi show or read good novel. I’m sure that oh3 will be awesome and will result in way less required support.

I don’t think that we should continue this topic about the “direction of openHAB 3” without having a roadmap document / white paper were we collect interesting ideas. This is the 3rd topic about oh3 and things keep repeating themselves.

My vision of oh3 is what I’m presenting in paper UI NG. There is a roadmap document in the repository as well with all required services.

Btw I have thought about scheduled tasks once more and changed my mind a bit. But I’ll talk about that tomorrow.

Cheers, David

(BasM) #70

For what it’s worth:

I’ve been using OH now for as little as six months (I see myself as just getting started). I’ve chosen OH after evaluating multiple other solutions. In finding your/our way forward for OH 3.0 I at least like to share my thoughts and if they make sense great, if not well, no worries. Thanks for reading.

As I’m not an active contributor please see my input into the discussion as one soul looking to automate/smarten his home/life. Nothing more nothing less.

Why choose OH
I choose OH since after evaluating multiple alternatives. These were the things I valued the most:

  1. The easy integration of hundreds of types of hardware.
  2. Abstraction to logical items (wchange a binding/hardware and still have everything working).
  3. Build under software architecture
  4. Resillience, stability, active life-cycle and release cadans
  5. Active, positive and skilled community (your guys).
  6. Being able to work disconnected (Internet down, no problems).
  7. Plug and play integration with persistence providers (Influx), rule engines (NodeRed), etc.
  8. Bridging capability to cloud (OH Cloud) without exposing entire system.


Stuff that hurts a little:

  1. Complex setup.
  2. Breaking changes when running an upgrade @ 11pm (my bad, RTFM).
  3. Developer energy / innovation speed might be lost in maintaining 3 or 4 UI’s.

Why I like the idea of OH 3.0
Other home automation systems speed up. The ecosystem is rappidly developing and more and more players enter the realm. Every supplier want’s their piece of the pie (data, lockin, etc). Not the least being Google, Apple, Philips, Ikea, and other large vendors themselves. One could argue it’s about time to standardise item descriptors, hardware bindings etc, rule definitions, etc. so as to ease integration going forward. But that might be a different topic.

Having worked with OH for only 6 months made me dive into the Eclipse Smarthome sources to debug some settings and the whole architecture and composition got quitte complex over the years (IMHO).

I hope OH3.0 continues to be THE platform of choice for reliable future proof integration of smarthome devices, services and being the foundation for many more years.

What considerations I have going forward
Outside my OH bubble around me I see a larger community of consumers picking up and integrating Apple, Google, Ikea , Philips Hue and IFTTT as platform to build their home automation on. Integration is key and they find it more and more difficult to integratie.

Downside to these services is they almost all are connected, everything is connected to everything. No internet means no automated home, and thus being locked out of your home, missing safety lighting, irritated spouse because the convenience they are used to is no longer there. With a growing privacy and security concerns, I see people willing to share less and less data.

I would like to see OH3.0 be THE platform for integrating all my smart home appliances, optionally connected to the cloud, but being very well integrated into it.

On the debated topics op rule engines, and UI’s…

To be really honest I’ve spend weeks on building a UI for my home. Only to find out nobody in our household is using it (it might be the UI design, my bad). But thinking about it I see different behaviour. In our home we use the UI’s less and less. We use voice assistants and a few smarthome switches for scenes. Even the kids talk to the house. The rest of the house is mostly automated in rules and behaviours. The odd case I need to query for historical data I use Grafana. For managing OH I use source code, and a configuration UI (Paper).

Looking forward I’m going to spend my time improving the experience of interacting with the smarthome through voice, chat by natural language while using a basic UI for simple scene control and information.

Rule engines: the brains
I’m trying hard to minimize spreading the logic/ rules/ “intelligence” of my house by singling in on 1 rule engine. Sorry to say it became Nodered and not OH’s native rule engine. Nodered is far from perfect but it does the job. I’m missing version control and a lot more.

The key thing IMHO is going forward to build an eco system of a community being able to share advanced scenario’s so people are able te learn from inspirational examples from others. Simplicity is key I find. Most people don’t wake up and build a smarthome thinking through edgecases, initialization of scenario’s, persistence of state. They just want to connect things. For example: send my spouce a message when I leave office or if I run late and predict my arrival time based on expected traffic delays of use of public transport. How hard can that be :slight_smile:

Wishfull thinking on my part would be a home that knows about semantics and moving forward from there propose new rules by learning behaviors of individual users. Why would an smarthome not be able to detect someone diverting from normal behaviour and by voice interaction suggest turning on the light because the person gets up from the table, it’s almost dinner time and the calendar indicates a dinner appointment in the house. Please don’t shatter my dreams :wink:

Closing thoughts
I hope we can keep the good op OH looking forward and make OH more accessible for the masses and integrating with leading platforms and thereby becoming/staying a leading platform for smarthomes. Open, Reliable, Smart.

Thank you for all your hard work you put into the platform I’m an absolute fan and hope some of the things I value in OpenHab resonate with the future plans.



(David Graeff) #71

Exactly. Same with me. I use a UI only for setting up and maintaining the system.

The current OH3 vision is to have one UI only. But I strongly suggest to split the setup&maintenance UI part from any control part as the later one just blows up the maintenance and complexity of such a solution and most people will either not use it or are not happy with it (“why is the button on the left side, I want it on the right side”).

And I recently started to ehm… use a Hue app with the hue emulation service. Those hue apps look beautiful, animated, fluent. Exposed lights can be sorted into rooms. Hue Scenes allow to start OH rules. Hue Alarms let me configure rules with an absolute date/time trigger.

Our current Android Apps, iOS apps MUST gain the ability to auto-generate a “sitemap”, because I for sure will not write a sitemap file just to switch my lights via mobile.

Cheers, David

(marcel_erkel) #72

Wouldn’t it be better to add the auto-generation of a default sitemap to openHAB? Otherwise basically the same logic needs to be implemented in the Android app, the iOS app and the new unified web user interface?

(Kai Kreuzer) #73

For anyone interested in a (the?) future sitemap concept, I can only recommend to look at

(Nico Bille) #74

You are right, but I don’t know if @johntech’s intention was a little bit different.
I think having some tutorials with broadly used implementations is a great thing because it gives a starting point to understand the system and have something functioning. With broadly used things it is most of the people can get easily and cheapt (things on which tasmota is running e.g.) or have it already (maybe a hue lamp). But this kind of tutorials isn’t something for the official documentation it is something (advanced) users should create. It works like this already today, but maybe it could be improved in the future.

(Fabi) #75


(Unparagoned) #76

Where can I get more information about the NGRE rules engine. I know it supports jython but I don’t really understand what it is.

But I’ll make a comment without knowing what I’m talking about anyway. It seems like with the limited hardware and current issues with the rules engine you want an event driven language like javascript. Even with jython I’m using kind of lambdas to do things, so it’s a strange mix of thing to get things done. Javascript seems like it would just fit with this sort of event driven framework/setup. Maybe some kind of javascript with everything aysnced or awaited, so you can write normal code without worrying about callbacks or promises.

(Scott Rushworth) #77

There is not much officially documented… yet. Rich has some helpful topics in the forum, as a starter for more docs with a Paper UI focus, and the ESH info was recently pulled over into the OH docs. It sounds like you are asking about JSR223 though, which can be used to create rules for the new rule engine, and be used in scripted Conditions and Actions, but can do much more.

I don’t see your question fitting into this topic… please create a new one, and I will happily answer more questions in the new topic!

(Unparagoned) #78

You know I always thought JSR223 was just an alias for jython. That link was useful, it looks like javascript is naturally supported. I might give that a go, or search to see how to get that working.