Roadmap to Happiness - What is missing in the core framework

[rlkoshak (Rich Koshak)]

@redm

My number one gripe ist the scripting engine. Sorry to say that, but the current one is a PITA. Spent hours to do things which should be obvious, like adding two numbers… Glad to hear, that this point will be solved with 2.4. If I got it right. Standard languages like Python or JS are a great step forward! Though if I read terms like JSR223, Jython, Nashorn Javascript, I get worried again, if this might be some awkward dialects … Also the simple examples on https://github.com/eclipse/smarthome/wiki/Scripted-Rule-Support lack a lot of clarity and seem to involve lots of boilerplate code. Maybe this could be hidden behind an interface like the current rules, just with the bodies in JS instead of the current language? Also I think there should be a clear number 1 scripting language, probably JS.

The Next Gen Rules Engine remains experimental. I don’t think that will change by 2.4. The documentation for it is just being started. See Experimental Next-Gen Rules Engine Documentation 1 of : Introduction.

No one is expected to write the JSON by hand. There is a UI in PaperUI for creating Rules and eventually there will probably be a couple of choices.

All three of the JSR223 languages as well as legacy Rules DSL Rules will be supported.

If one is already using JSR223 Rules, they are already using the base NGRE.

JSR223 is just a name for the mechanism that allows one to run non-java programming languages in the Java Runtime Environment (JRE). Nashorn is the JSR223 implementation of JavaScript. Jython is a version of Python that runs on the JRE. OH is a Java application. Whatever language Rules are written in must run in that environment.

@redm

Another point is to make it easier to create reusable components, of items and rules, maybe UI. There are many design patterns with describe solutions to achieve this, written with the best intent. But really they are just creative workarounds. And if I read many of them I only want to scream and run away, wondering why it has to be so complicated And usually they require a complete redesign of what you just created. Leave alone that maintenance will be a nightmare, when you get back to such code years later trying to figure it out again.

The Rules DSL is its own language and it has its own preferred way of structuring code. This is true of any programming language. The DPs are not work arounds. They illustrate the proper way to structure Rules DSL code. Indeed, if you try to structure your solution in a different way, you will probably have to restructure your approach, sometimes significantly. You sound like a programmer and for years I have pushed programmers away from the Rules DSL and to JSR223 Rules because most of the time people who already know how to program cannot or will not structure their code in a way that works well in Rules DSL.

@redm

Maybe some sort of templating?

NGRE has support for Rule templates (I’m not sure how it works yet) as well as libraries. But this will only be for Rules. You will have to manage your Items separately.

@redm

and then turn it into a template which I can instantiate multiple times with a different name and a set of parameters. Basically the engine in the background is taking care of the replication logic.

In the NGRE Rules can call Rules, Rules can be enabled and disabled, and of course there is support for libraries. But in Rules DSL, you shouldn’t have any duplicated code either. Using Groups, Member of triggers, and the like you should only need the one Rule in the first place.

In neither the Rules DSL nor the NGRE should there be replication of logic.

@redm

Take for instance implicit variables, like receivedCommand . I did that wrong first, and accessed the <item>. state , probably just like many other first time users, getting weird behavior, hard and time consuming to debug. If the rule had a forced (or at least optional) parameter with the received command instead, my code would have likely been correct the at first time. Without even thinking about it.

The NGRE takes a really different approach to implicit variables. They are still there but not you have an event Object that encapsulates everything you can know about the event that caused the Rule to trigger. For convenience, some of those properties are exposed as variables (e.g. on a changed triggered Rule there will be a newState and previousState variable populated).

I’m not sure I understand what you are suggesting though by a forces parameter with received command. Regardless, there is a reason why it is the way it is. There are circumstances where one needs received command to work exactly like it currently does. Any change to this breaks those cases. For example, imagine you have a device that always reports it’s new state. With such a device one will likely want to use autoupdate=false which will prevent the Item itself from being updated or changing state on the command and instead waiting until the device reports back that it changed state. So, in this case, you can’t rely on an update to trigger your Rule and you can’t rely on a state change to trigger your Rule when you need to have a Rule triggered when the Item receives a command but you don’t want to or need to wait for the state change. The only way to trigger a Rule in this circumstance is to trigger it based on the actual received command event independently of what the Item’s state is doing. But this also means you can’t rely on MyItem.state in that Rule, hence the variable.

Sometimes the complexity is deliberate, well thought out, and required.

@redm

Or this awkward thread locking I need to do.

You shouldn’t be doing much locking. It’s dangerous and prone to errors. If you need the locking then my recommendation would be that there might be a better approach or you should be using JSR223 Rules.

@redm

Or this awkward thread locking I need to do. Shouldn’t be needed => doesn’t need to be documented. So telling the user he’s wrong and point him to some lengthy doc is not always the answer.

One can counter with just because one doesn’t understand why something is complicated doesn’t mean it can be made simpler.

I’m not arguing that there are not areas where OH can’t use some simplification and it has frankly come a really long way in only a couple of years. But it needs to support a lot of use cases and that adds complexity.

Based on the description I really think you would be better off using JSR223 Rules or, if you are adventurous you can start to experiment with the NGRE. There are a few things it can’t handle just yet but it’s pretty capable.