Directions for openHAB 3

[phantom001 (Patrick)]

@David_Graeff

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.

Sorry i read the post befor and i dont want to step on feeds just post
my view of things …

And why i am wrong because its a other point of view ?

@David_Graeff

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

Suprise when this big huge sooo amazing cloud services with its so amazing uis provide all the needs to get all the devices and protocols together include not well known devices or self made things (like arduino esp and so on).

Why we use Openhab and spend hours to get our own config scripts rules etc. to work … do have it our own way with sometimes own devices etc… why dont switch to an so amazing cloud service if they provide all that possibilities things and the flexibility at one place ?

Why we do this when we can have it with thew clicks in their amazing uis ?

The simple answer is they dont and we cant have it in their uis !!!

Services like that are made to hit an “wide” range of standard user needs but dont offer real flexibility in wide ranges.

In in my point of view this is why oh exsits and live because it offer
these special needs in config that these big players dont offer.
(And i dont mean the limited Oh Ui config possibilities i mean the wide range codebased section)

So what way will oh go in future … try to imitate these big players offer the same simple to use service for a wide user range … also in that case that oh lose a wide range of its lets say maker community possibilities ?

Here i can say good luck these big players have a lot more resources, a big budget from the companys and a million people community !

If oh provide the same services why dont switch to one of the further spread big players …

@David_Graeff

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.

Exactly this is the Point if you will have these flexibility you have to spend some time to read the manuals and code examples to figure out how !

As benefit you will get the flexibility and possibilities to make it like you want to do it.

And in my point of view this is the big advantage in oh that the most of the big players dont have.

If i want a real simple out of the box system why should i use oh then i will buy an out of the box system from one of the hundreds providers out there.

At the moment oh is used from people they want to do a little bit more.

@David_Graeff

Where as with a UI you are guided through the process, even if it is a complex one

That’s right to a certain extent.

But can you rebuild all eventually needs and processes in an ui ?

Its simple no you cant because there will be needs you dont think about it.

In config files what language ever you have more possibilities because they dont have a given guided through process where you cant break out like in an ui.

Look at the community why so much and so a wide field of user write their configs … why so much bindings require an codebased config …
why the dont all use the given ui ?

Because the ui cant beat all eventually needs …

@David_Graeff

You always need both UI and a textual interface.

I have never said there should be no config ui !!
Yes an ui in some cases is very usefull !
And especially for new users it will be very helpfull !

Especially if the ui will write also config files where new useres can look in and learn …

Or lets say oh will provide both possibilities make changes in the ui or make it directly in the config file from the ui so the user has the decision.

I said that OH should not loose its wide coding possibilities and they should come first because this is the big advantage that oh provides and the big difference between oh and the big cloud players.

@David_Graeff

And UI does not work the OH1 way.

I dont ever speak about the OH1 way … i speak generally …

And yes this im my point of view and my thoughts about what i read here in the oh3
discussion !!!

And whats in my point of view will be important.

It would be a colorless world if everyone were always of the same opinion !

Thanks Patrick

[David_Graeff]

Pointless to argue with you as we have fundamental different opinions. You want it complicated and that you have to read dozens of manuals to configure your smarthome. I don’t want that.

It’s also pointless to write here as well. Developers will do their own thing without ever reading this thread. If the product is not for you, you need to chose another one.

[phantom001 (Patrick)]

@David_Graeff

You want it complicated and that you have to read dozens of manuals to configure your smarthome. I don’t want that.

No i dont want it complicated a ui is a realy good thing …
But i want the possibilities in the case i need it !

@David_Graeff

It’s also pointless to write here as well. Developers will do their own think without ever reading this thread.

Thats very bad to hear because if they only make their own thing and dont have a look at their user needs many useres will be gone at some point …

@David_Graeff

If the product is not for you, you need to chose another one.

You are right !

[smhaller (Stefan M. Haller)]

Dear all

At begin I refused to write something within this thread. But when I see the discussion between @phantom001 and @David_Graeff I thought it’s maybe time for me to write something down.

Firstly as far as I like good driven UI’s the possibility that it becomes over complex is in.

Secondly, when I started using OH2 (no experience with OH1) I was fascinated about the UI possibilities and auto detection and and and…until I realized, that it is not goinf in the way as I prefer to have my config. So I started working with config files. Nowadays most of my setup is purely done in config files due to the fact, that I can do a quick copy & paste- adjust and have a new item ready to be used. Such you don’t get with UI driven configs.

What I don’t like in OH2 is the hidden “_default” sitemap, auto created and not really useful at all. And it’s not possible to hide it completely within the system.

I fully agree with those saying, it’s time to get rid of OH version 1 based bindings - within OH3 at least.
My expectation is that it would take some time to completely stop with it, but has to be done. So a parallel run of OH2 and OH3 for the time being. While OH1 support is getting to go back and will disappear.

@David_Graeff

Pointless to argue with you as we have fundamental different opinions.

Different Peoples different opinions is a matter of fact. While some devs say they don’t want to support to much UI’s which I agree. But I don’t agree In that point that a certain HA admin should not have the possibility to design the UI is he likes to. And doing this in an easy way instead of writing an own addon. Yes there is the REST way one can go, but even this is time consuming.

You mentioned the Big players as those where all is configured through UI. Which is good and fine working for them and most probably the users of these platforms. Honestly I don’t use them all and I try to prevent them as long as possible. Because all, which is out of my house is not controlled by me. It’s controlled by 3rd party. This is also a reason for me not to use openHAB’s own shared platform.

And the reason why I’ve chosen OH is as @phantom001 mentioned it’s varieties and possibilities to use it.

From my point of view it is important to keep the flexibility of configuring OH but as well enhance the interaction possibilities through an Admin UI. While an item should be reflected in the same way as it would be in a Frontend UI (this is for instance now not the case in habmin).

[rlkoshak (Rich Koshak)]

I think we all agree that with the loss of support for OH1 bindings there will be a loss of users.

It is also clear that the current set of developers are not interested in preserving OH 1.x binding compatibility.

So there is only one solution. Volunteer or find someone to volunteer to make the changes to the core/and or the OH 1.x bindings so that they can be supported in OH 3.

The time for complaints is over. Everything that can be said has been said here or in other threads. Now is the time for action.

For all of you who think losing the OH 1.x bindings is the wrong direction. Step up! Start submitting PRs. Start contributing to the code to save them! If you value them please do the work to save them!

Anything short of that is just complaining. And frankly it’s complaining to the wrong people as the core maintainers are not active in this thread.

@phantom001

but be honest in the most cases it cause more problems than it solves …

I would welcome new thread to iterate what problems automatic discover causes with a productive discussion on how to address them.

@phantom001

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.

And there is an equal number, if not more, with people struggling to get the .things file correct.

@phantom001

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 …

There is another length thread that discusses this. All of this has been considered and addressed. The tl;dr is:

• You will be able to do anything in the UI including editing Things et al as text. No clicking around in the UI required.
• You will be able to export your Things et al to text config files where you can create and edit with your editor of choice.
• You will be able to create config files for Things et al in text configs independent of OH should you choose.
• Text config files get imported into OH on command.
• You will be able to export you OH configs to text files.
• The formats of the config files will be changing, likely to YAML.

I believe that was the consensus, if you could call it that, from that other thread.

@phantom001

Thats very bad to hear because if they only make their own thing and dont have a look at their user needs many useres will be gone at some point …

It’s an open source project without corporate backing. The developers will work on what they are willing to work on. If you feel strongly about this, become a developer or find a developer who can contribute. We can have the best ideas in the world but unless and until there is a developer willing and able to actually do the work, it’ll never be more than just an idea.

@smhaller

Nowadays most of my setup is purely done in config files due to the fact, that I can do a quick copy & paste- adjust and have a new item ready to be used. Such you don’t get with UI driven configs.

Yet this is what is proposed in the replacement to PaperUI. David already has a design study that can show your Things (for example) in a “text editor” in the UI. Don’t think that UI means PaperUI as it currently exists. It’s pretty much agreed the PaperUI in it’s current form is a disaster. Look at the PaperUI NG Design Study thread and see for yourself.

Again, I’ll summarize.

The current set of developers have their ideas about where OH needs to go. Note that David is just one of those developers. If you don’t like the direction the developers are going, you need to become one of the developers or find a developer to support those ideas and features that are important to you.

Between this thread and the two other length arguments pretty much everything that can be said has been said. Now is the time for action. Start creating issues and PRs.

[David_Graeff]

@rlkoshak

The current set of developers have their ideas about where OH needs to go. Note that David is just one of those developers.

I also need to point out one design aspect of openHAB: It is in any way extensible.

• The storage backend can be a json based one, mapdb or anything that implements the very simple 4-method java interface.
• The things and items can be provided by the storage backend, but also files or any other source.
• Controlling openHAB can happen via OSGi console commands, rest API, java API, scripting.

If you miss a way to communicate with openHAB, code it. You need to know java and a tiny bit (like 3 or 4) of OSGi annotations for java classes. That’s it.

The core of openHAB hasn’t changed for a long time actually and for OH3 will only change because of legal reasons. So I really don’t get why everybody is so nervous.

Personally I follow the agenda of making .thing and .item files (the entire subsystem behind that machinery) optional for the major next core version.
I don’t need them and they cause instability for me which is a no-go for a reliable HA system.

[diyha]

@David_Graeff

The core of openHAB hasn’t changed for a long time actually

Thats correct, from a coder’s perspective. But I have mentioned the need for binary compatibility. A proprietary binding’s jar from 2.1 should work on 3.2. Because that binding’s writer or company may NOT be active anymore, but the binding used to work perfectly back then. Of course this cannot be done for ancient bindings from 15th century. But there has to be a guarantee from platform that binary addons will work for reasonable period of business time if core is upgraded (5-15 years for building automation systems).

In short I want a feature from next OH, “forward compatibility of binary addons”.

Look at Windows and Solaris, their binary compatibility is 5 to 15 years.

[David_Graeff]

@David_Graeff

for OH3 will only change because of legal reasons.

@diyha

But I have mentioned the need for binary compatibility.

Are you on a mission to steal other peoples time?

[diyha]

Are you?

Stay to the point of “forward compatibility of binary addons”.

[sihui]

@David_Graeff

steal other peoples time?

Don’t spend too much time on this, he is an old friend:

Fun project: kotlin scripting for openHAB

Ganesh (I’ve suspect that’s you returned in another guise for awhile now and this confirms it), if you see this I have one last parting statement for you but I’m mainly posting this for everyone else who comes along with big ideas. OH is a community project. You have to work with the members of the community and work within the rules and procedures of the community. If you are not willing to work with the members of this community, in particular the maintainers, then you will accomplish nothin…

[diyha]

Stay on the point.

[rlkoshak (Rich Koshak)]

Please open a new thread to discuss forward “binary compatibility”. For all intents and purposes, this thread should be closed.

Or better yet, open an issue on github where the right people will actually see it.

We all know you are a developer, so I do recommend that if you make such a proposal to be prepared to actually work on submitting a PR.

This is all I have to say on the subject, and am kicking myself for even saying this much.

[diyha]

There was actually. With the old id. Need to create new one.
Its an important thing. No commercial dev or company will ever choose OH if binary compatibility is not guaranteed for even 6 months.

[rlkoshak (Rich Koshak)]

Please open a new thread to discuss forward “binary compatibility”. For all intents and purposes, this thread should be closed.

Or better yet, open an issue on github where the right people will actually see it.

[David_Graeff]

I second that everything has been said in this thread. Almost every fellow reader will find himself in one or more posts in here, so we can really close this topic.