Because developers want to be able to code rules in the language of their choice. So they volunteer their time and efforts to make openHAB support their language of choice. Should the project say “no, we don’t want your free volunteer work because we want to keep openHAB ‘pure’” or should we say “thank you for your contributions!”?
Here’s the deal. openHAB is 100% volunteer effort. There is no plan. A plan would be useless. Nothing gets done unless and until someone volunteers to do it. There are ideas of course. There is a general direction to be sure. But ideas and general direction doesn’t turn into code until someone volunteers their time to write that code. So devs pick and choose what to work on. Sometimes it’s a pet project completely off the “plan”. I think it’s safe to say that except for Rules DSL, all the other rules languages supported by OH fit this category. No one asked for them. No one pushed their implementation or inclusion. A set of developers decided they would rather code their rules in Java or Python, or JavaScript, or Groovy or Ruby and did the work to make that happen.
JSR223 is already dead in openHAB. JSR223 was an old approach that allowed the JVM to run other scripting languages like Python and embed those languages into a Java program. It has long since been replaced by a Java Scripting interface which in turn has been replaced by GraalVM (if I understand the history correctly).
Jython was ported from JSR223 to Java Scripting. The upstream Jython project hasn’t ported to GraalVM. Furthermore, development has all but stopped on the Jython project and there is no Python 3 version of Jython in sight. Do you want to volunteer to go take over the Jython project and get ti going?
We backed the wrong horse. In 2008 it looked very promising as development was very active and it looked well supported and maintained. Now no one is supporting it and it’s not part of the openHAB project so we don’t have power over that. But there was twelve years of good use of Jython. I’d hardly say that openHAB was wrong to support it way back then. There was every indication it would continue to be supported and a Python 3 version would be developed.
They sound like good ideas. Do you have plans to work on implementing something like this? I’m not being glib here. openHAB is a 100% volunteer effort. Having a good idea is almost never enough to actually get something to happen in openHAB. Someone has to volunteer their time and effort to build it. You are unhappy with what the volunteers have built so far and have good ideas of your own. But if you are not willing to implement it they are not worth much.
Much of the foundation for these “room” ideas is already there. It’s one of the things that kind of drove the creation of the semantic model in the first place. In the model you attach devices to rooms. Those rooms to map to the house and are used to generate a UI. Locating users is hard but if you have a solution that can implement this idea I’m sure we are all ears. And one can write rules (or even better install rule templates) to provide functionalities per room. And rule templates can be reused. And all interactions in OH occur in a standard way through Items.
From what I can see, OH already implements 90% of what you are asking for in terms of rooms. But you don’t like how it implements it, which is fair and fine. But if the current set of developers haven’t implemented it the way you like so far, what makes you think they will in the future? That’s why anyone with a good idea like this needs to back it up with some effort too. Otherwise it’s just complaining.
I can go through the rest but ultimately it’s the same thing. Good ideas. Much of the infrastructure to build it is there already. Some would argue much of what you are asking for is already implemented. So, who is going to implement the rest?
And don’t forget to answer the question: “what if I want to do it another way?” and “What if I don’t want to do it that way?”
Ultimately this whole list looks like a great one for people to use to start implementing rule templates. A number of them already are. It’s kind of the whole point of rule templates really. To eliminate the need for users to have to copy/paste/edit code or come up with scripts on their own. Notice how among those links that I posted in my previous reply I included links to a number of rule templates and UI widgets?
Take Scene Control Suite - Scene Activation, Scene Control Suite - Scene Modification, and Scene Control Suite - Scene Control Widget for example.
Those two rule templates and UI widget allows one to set a bunch of devices how they want them, capture their current states and save that to a “scene” that can be restored at any time. No coding is required. Users just need to install the templates and UI widgets and instantiate them.
Right now the marketplace is in it’s infancy and there are limitations but there is talk of being able to bundle bindings, UI widgets, and rule templates into one installable add-on so, for example, you don’t only get the ability to create Things and Item that interact with your HVAC system, but you also get a nice UI widget to control it and some standard rules that implement behaviors for it. That sounds a whole lot like one of your bricks to me.