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.
Cool!
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.
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!
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.
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 
but if i can help or do something für the old or new system let me know 
Thanks
Patrick
1 Like
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.
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
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 ?
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 …
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.
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 …
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.
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
2 Likes
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.
No i dont want it complicated a ui is a realy good thing …
But i want the possibilities in the case i need it !
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 …
You are right !
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.
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).
3 Likes
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.
I would welcome new thread to iterate what problems automatic discover causes with a productive discussion on how to address them.
And there is an equal number, if not more, with people struggling to get the .things file correct.
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.
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.
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.
6 Likes
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.
2 Likes
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.
2 Likes
Are you on a mission to steal other peoples time?
Are you?
Stay to the point of “forward compatibility of binary addons”.
Don’t spend too much time on this, he is an old friend:
1 Like
Stay on the point.
1 Like
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.
4 Likes