Rules and rule templates YAML integration

[Nadahar (Nadar)]

@rlkoshak

The “demo.scripts” file is there too, but I never looked in it. If it’s empty as it appears it should be removed. If it is supposed to have content, that probably should be in a README.md file or the extension fixed. And there should be a README.md file in there anyway explaining the restrictions of .script files.

You might not be familiar with the “demo app”, but OH has such a thing. I don’t know if it’s related to the online “demo” or not, for some reason, the “demo app” is what we run when developing from Eclipse (and it can also be run without Eclipse). It runs without Karaf, which is necessary for Eclipse integration. These files belong to this “demo app”, everything you find under openhab-distro/launch/app at main · openhab/openhab-distro · GitHub is a part of this “demo app”. In there, there are demo.rules, demo.items etc., so that when you start it, it’s not entirely empty. These “demo files” can also be handy as a very basic reference for how things are done.

demo.scripts is a part of this, and it should have been named demo.script, obviously. My point was that I’m not the only one that find this confusing when even the “official demo app” has gotten this wrong. As to why the file is empty, I don’t know, but I can only assume that nothing was added because the author couldn’t get it to work. In my opinion, it should be renamed, and some very basic script added, so that it provides a “demo script” for the installation.

None of these demo files are part of the “downloadable distribution”, because that content is generated from another part of the file structure in openhab-distro: openhab-distro/distributions/openhab at main · openhab/openhab-distro · GitHub

The README files doesn’t exist in the “demo app”, since they are part of the “other tree”: openhab-distro/distributions/openhab/src/main/resources/conf/scripts at main · openhab/openhab-distro · GitHub

@rlkoshak

It is better to make it clear that the files need to be “.script” than to raise the question “why can I only put one script in a “.scripts” file”?

It’s not worth the time making a big discussion out of this, I think it would be better if both worked because I think it’s ample opportunity to get it wrong. For those that would want more than one script in a .scripts file, I would ask: How do you plan to indicate where one script stops and another one starts? But, forget this point, I won’t do anything about this.

@rlkoshak

With a whole bunch of caveats. You can’t pass anything to them like you can with “regular” rules (technically you can pass data, but there is no way to access them from Rules DSL, rules or scripts). But they can be invoked using the runRule action (which doesn’t exist in Rules DSL).

Yeah, the caveats are on the “DSL side” because it can’t access the “inputs”. I find this a bit strange, but haven’t looked into it, but it should be possible to make this available, because the triggers use these “inputs” when they trigger. So, they are “accessible” to DSL at some level, but not directly accessible from the code.

It doesn’t seem like you can pass anything to callScript either, so aren’t they both “equally bad” in that sense? Overall, it seems to me like “DSL scripts” must have very limited utilization.

@rlkoshak

That’s what I’ve been trying to say from the beginning. The whole concept of “Scripts” in the UI is something that only really exists in the UI. As far as OH core is concerned there really is no difference between a Rule and a Script.

Yes, and I’m still trying to understand exactly what they are useful for, and in particular why the distinction is useful. I assume that they are used for doing some “standard” thing that you want to trigger from different rules, but without parameters to pass, the possibilities will be very limited. Also, since the “run in rule thread” has never been merged, running them is full of threading issues.

@rlkoshak

There is not and never has been an action that allows Rules DSL to call other rules and there is no way I and others were able to figure out to gain access to the rule registry in Rules DSL to do it ourselves.

As I said above, you don’t actually need the rule registry to do this, you need the rule engine/rule manager (for some reason this has two names). But, without access to the instance, the problem is still a fact. I’ve never had the time to dig into how these instances are provided to other scripting languages, but I find it hard to believe that the same couldn’t be done for DSL.

@rlkoshak

Maybe something changed over the years, but access to the RulesEngine and the MetadataRegistry is the main reason I moved to Jython and then Nashron and finally JS Scripting. It jsut wasn’t possible to get access to those from Rules DSL. The whole OSGI stuff never worked. And these were never added to the rule context.

I doubt that something has changed, I’m just saying that there are no “obvious” reason why these can’t be made available. But, perhaps there are reasons that become apparent when you try to actually do it, like startup timing/cyclic redundancy. I don’t know why it was concluded that it was impossible, but it should be possible to access any such OSGi instance in the same “hacky way” as is done for ScriptExecution, which is necessary for callScript() to work. So, to me, it’s hard to understand what exactly makes these cases different, but maybe it is in fact “impossible” regardless of how strange it seems to me.

@rlkoshak

There’s an issue or maybe even a PR open on Github.

Yes, both:

[Rules DSL] Make triggers optional

Allow rule with no trigger in DSL Rule file format (#5462)

@rlkoshak

A template author is by definition a more sophisticated and experienced OH user. Documentation in the to be written “how to write a template” should be sufficient I think to identify keywords/reserved words like that.

This is just one of several challenges with these “hacks”. It’s clear to me at least, that other fields are “abused” because there are no place where this information really belong. But convincing everybody that adding a “proper place” for this type of information might be more work than just living with the complications.

@rlkoshak

For Scenes punt and deal with them later in a separate PR. Scenes really are kind of different and not related to Rules DSL so they don’t need to be addressed at the same time.

Yeah, it seems like a whole project in itself to deal with “the illlusion” that is Scenes. To avoid confusion, I should probably just block them for export to YAML.

@rlkoshak

For Scripts, I guess it depends on the outcome of the PR/Issue to allow a Rules DSL rule without triggers. But there’s also the problem that Rules DSL also needs a way to call other rules. So I can see these distinct paths:

1. Refuse to export Rules DSL scripts (i.e. rules with a single Rules DSL Script Action whether or not it has a Script tag). Trying to do so is an error.
2. Implement a runRule action for Rules DSL so Rules DSL can call other rules, not just Rules DSL scripts, and export the Rules DSL scritps as a rule without triggers.
3. Export all Rules DSL scripts as a .script file. These can only be exported one at a time though given the one script per .script file restriction.

YAML already allows a rule without triggers so if exporting to YAML just leave it as a rule without triggers.

Yes, I definitely need to wait for some decisions to be made. As for you options, only 1) is “easily achievable”. I don’t know how difficult 2) would be, but it would represent a “side track” from what I’m really trying to do now in any case, and should be its own PR. So, it would also act as a delay. 3) might be doable, but impractical, until you mentioned that you can only export one at a time. That is true, and is an even bigger challenge, because it breaks with the whole “conversion logic”. I don’t know how I would have to handle messaging back to the user why it failed if it’s because there are more than one script. This isn’t a very appealing option all in all.