Directions for openHAB 3

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

1 Like
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.

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.

65

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

1 Like
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.

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.

1 Like
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.

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

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

Compliments!

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…

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.

Thanks.

Bas

7 Likes
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

3 Likes
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?

73

For anyone interested in a (the?) future sitemap concept, I can only recommend to look at https://github.com/eclipse/smarthome/issues/5337.

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

75

Cool!

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.

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!

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.

79

Hello

This is all my point of view …

Backward compatibility:
Backward compatibility is ever a big big point !

Ok i agree it is very bad that some binding providers dont take care of their bindings …

But what should do a simple user without the knowledge to write a new one
but have 1.x 2.x devices/bindings in use ?

Sorry but this where only a way when every oh version are maintained and developed in the fututre and have a coexistence.

But the older versions are out of maintance and development.

Out of maintance and development is equal to the system is dead and will broke
sooner or later because sooner or later they have no compatibility to other newer software like new releases of java and so on !

And dead software where nobody cares about it is always a security leak !

Run some oh versions side by side ? I think this cant be the answer …

  • You will never get an really clean system (stability/dependencies)
  • You run not maintanced dead software (see above)
  • You will burn to much system resources to run it on an system like an raspberry.
  • Your security is weak

So i think backward compatibility is really necessary !

Or at least all 1.x and 2.x functions (bindings etc.) will be available in oh3 also.

But who write them all new and test them …

If not Oh will lose much of its device compatibility and so users.

Oh will also lose much users by a every oh version is a new product policy !
Why a user should spend so much time to get deeper into a system and so on when ervery new version has nothing to do with the old and there is no compatibility ?
I think they will switch to a continuous developed system and not use a system with such a hard break in every distro change …

Code Config vs Ui Config

First here i only mean the config part not the sitemaps habpanel and so on … there should be a nice ui in frontend !

In my eyes oh is a system for people they want to do more or want to do it their own way.

So i think code config should come first !

Why ?

Its simple a ui never can give you that possibilities and freedom that a writen config file can give you !

Why shold i click around in some fancy uis und fill text boxes etc. when i can have it done with a short line of code in a config (item,things,rule,script) file and have more possibilities ?

As said i think oh is a system for people who want to do “more” , go deeper have it their own way.

And i think if you invest a very little bit of time everyone should be able to write a
simple basic config (item,thing,sitemap).

If the people dont want to spend a little bit of time and have a hassle free simple fancy ui config … go out and buy some of the x hundred ready to use systems out there.

And be honest if you want a real open system with that much possibilities you will never get a real hassle free real working config ui …

That will not be possible because every device / every communication communication protocol has its own needs … thats possible in closed out of the box systems but if you want do be open for all eventually needs a ui will get to its borders really fast.

Take a look at the automatic thing discovery in oh2 it sounds like a nice future
especially for new users and sometime it works but be honest in the most cases it cause more problems than it solves …

Look at the communitiy posts there are many posts of people that spend much time to get their config done with the ui and has problems or fail with it. The better spend the time do read the few sheets about the code config and be sucsessfull.

So i dont say there sould be no ui config but i think the code config should come first …

The Ui und Code config should be in one place YES but PLEASE dont make fancy ui boxes to write the code in it just stay by the config files !

There are much possibilities to get both running side by side !

  • Let oh read the config files and write it int the db (overwrite the config values in db).
  • Let oh ui write their own config files and handle all over read/write config files
  • and so on …

I think the best way would be if the ui write out their own config files.
This will help new users to understand and you can make changes in the ui and in the ui config files … or write your own config files like at the moment.

The possibility to make your own files like at the moment should be remain because it is easyer and cleaner to have the possibility to split your config in pices and dont have some big long config files …

Sorry for my bad english :frowning: but if i can help or do something für the old or new system let me know :slight_smile:

Thanks
Patrick

1 Like
80

The eclipse foundation forces the project to remove all “org.eclipse” package names out of the project.
And all interfaces in OH2 core have those. So bindings need to be adapted and recompiled but that can be done by a script.

But other than that there are additions, not API removals planned.

81

You are wrong. But there are a gazillion posts about this already. Please read through those 3 hours worth of discussion first before repeating wrong arguments again.

Think of Microsoft Azure, Google Cloud, Amazon S3, Lambda etc all those huge cloud services, used by almost everyone, are configured via UI. Surprise.

There is one thing, that a UI can provide that a text file can’t. Imagine you are new and the text file is empty! What to type? And the syntax? Copy/paste from others? But then something doesn’t work… you have copy/pasted old examples oh. Where as with a UI you are guided through the process, even if it is a complex one, and yes OH is already a complex one.

You always need both UI and a textual interface. And UI does not work the OH1 way. Just accept that.

5 Likes