Rules and rule templates YAML integration

[Lolodomo]

For DSL Rule, we now have tags and time of day trigger available.

I also created a PR to add UID and another one is in progress to add conditions.

[DSL rule] Add optional rule UID to DSL Rule file syntax (#5449)

[DSL rule] Add time conditions to DSL Rule file syntax (#5453)

[Lolodomo]

Can someone explains what means and what is the purpose of this condition ?

What means “checks” in that context ?

[Nadahar (Nadar)]

@Lolodomo

Can someone explains what means and what is the purpose of this condition ?

I don’t know it, but it seems like, if you have a trigger that might happen very often, depending on other circumstances, but you want to make sure that the rule doesn’t run too often, you can set a condition that it won’t run more than e.g. once a minute.

@Lolodomo

What means “checks” in that context ?

I interpret it as “triggering”, but perhaps it’s badly worded.

[jimtng]

@Lolodomo

what is the purpose of this condition ?

What means “checks” in that context ?

It is badly worded, but it is not “minimum interval between triggers”.

A better description may be: “a minimum interval since the previous rule execution”.

Say you have triggers that can occur as often as every second, but you only want to run your rule every 60 seconds at most, and not any more often than that. In this case you would set the minimum interval to 60 seconds and it will ignore triggers until 60 seconds have passed since the last rule run.

[Nadahar (Nadar)]

@jimtng

It is badly worded, but it is not “minimum interval between triggers”.

It is what I meant, you can’t prevent the triggers, but you can prevent letting them trigger. That is, reject any triggers that occur before the defined interval has elapsed since the rule was last triggered.

[jimtng]

@Nadahar

It is what I meant, you can’t prevent the triggers, but you can prevent letting them trigger. That is, reject any triggers that occur before the defined interval has elapsed since the rule was last triggered.

Yes I understand what you meant and I knew you were going to come back with this statement!

Using the word “trigger” or “triggering” or “trigger*” may cause ambiguity / confusion, so it’s best to avoid it.

[Nadahar (Nadar)]

I’ve now rebased my working branch to latest main, and something has broken when serializing DSL rules. Does anybody have any idea what might cause this?

java.lang.IllegalStateException
	at org.eclipse.xtext.serializer.sequencer.AbstractSyntacticSequencer.enterAssignedParserRuleCall(AbstractSyntacticSequencer.java:354)
	at org.eclipse.xtext.serializer.acceptor.SequenceFeeder.acceptEObjectRuleCall(SequenceFeeder.java:325)
	at org.eclipse.xtext.serializer.acceptor.SequenceFeeder.acceptRuleCall(SequenceFeeder.java:354)
	at org.eclipse.xtext.serializer.acceptor.SequenceFeeder.accept(SequenceFeeder.java:248)
	at org.eclipse.xtext.serializer.sequencer.BacktrackingSemanticSequencer.accept(BacktrackingSemanticSequencer.java:452)
	at org.eclipse.xtext.serializer.sequencer.BacktrackingSemanticSequencer.createSequence(BacktrackingSemanticSequencer.java:512)
	at org.openhab.core.model.rule.serializer.AbstractRulesSemanticSequencer.sequence_Rule(AbstractRulesSemanticSequencer.java:587)
	at org.openhab.core.model.rule.serializer.AbstractRulesSemanticSequencer.sequence(AbstractRulesSemanticSequencer.java:133)
	at org.eclipse.xtext.serializer.sequencer.AbstractSemanticSequencer.createSequence(AbstractSemanticSequencer.java:68)
	at org.eclipse.xtext.serializer.acceptor.SequenceFeeder.acceptEObjectRuleCall(SequenceFeeder.java:327)
	at org.eclipse.xtext.serializer.acceptor.SequenceFeeder.acceptRuleCall(SequenceFeeder.java:354)
	at org.eclipse.xtext.serializer.acceptor.SequenceFeeder.accept(SequenceFeeder.java:265)
	at org.eclipse.xtext.serializer.sequencer.BacktrackingSemanticSequencer.accept(BacktrackingSemanticSequencer.java:445)
	at org.eclipse.xtext.serializer.sequencer.BacktrackingSemanticSequencer.createSequence(BacktrackingSemanticSequencer.java:512)
	at org.openhab.core.model.rule.serializer.AbstractRulesSemanticSequencer.sequence_RuleModel(AbstractRulesSemanticSequencer.java:567)
	at org.openhab.core.model.rule.serializer.AbstractRulesSemanticSequencer.sequence(AbstractRulesSemanticSequencer.java:136)
	at org.eclipse.xtext.serializer.sequencer.AbstractSemanticSequencer.createSequence(AbstractSemanticSequencer.java:68)
	at org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:122)
	at org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:135)
	at org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:205)
	at org.eclipse.xtext.resource.XtextResource.doSave(XtextResource.java:431)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1475)
	at org.openhab.core.model.core.internal.ModelRepositoryImpl.generateFileFormat(ModelRepositoryImpl.java:283)
	at org.openhab.core.model.rule.runtime.internal.converter.DslRuleConverter.generateFormat(DslRuleConverter.java:279)
	at org.openhab.core.io.rest.core.internal.fileformat.FileFormatResource.createFileFormatForRules(FileFormatResource.java:495)

@Lolodomo Could it be because of the added tag, do I have no initialize something related to the tag before trying to serialize?

[Lolodomo]

Sorry I don’t know but I doubt that it is related to my small changes.

[Nadahar (Nadar)]

I don’t know, I just know that something has changed, and I have no idea how to figure out what.

I’m guessing that it’s most likely related to the tags, I had to redo the formatter because of that, because the IDs of most of the fields had changed.

edit: Something is missing here, the rule model only has getTags() but no setTags() method. I need setTags() to be able to set the tags when serializing.

edit2: I think I understand why there’s no setTags(). In Xtext’s weird world, you don’t set collections, you get them and add/remove/clear them. So, I have to use getTags().add().

[Nadahar (Nadar)]

I managed to run a validator, and it gives this error:

Validation issue: This expression is not allowed in this context, since it doesn't cause any side effects.

So, perhaps this is related to one of your changes @dpa-openhab?

I’m creating a “placeholder script” that is only a string (so, it has “no side effects”). But, this used to work.

[dpa-openhab (Дилян Палаузов)]

@Nadahar

Validation issue: This expression is not allowed in this context, since it doesn't cause any side effects.

The above message was always shown, if the XBase code did nothing, and it supposed to be a warning, not an error. In the concrete case it is unclear which input creates that Validation issue and how to reproduce it. If I create a file openhab/scripts/a.script with content "abc" I see no such message in openHAB 5.2.0 build 5275.

You might have tweaked the default logging and for this reason you started seeing the message.

[Nadahar (Nadar)]

There is nothing wrong with the logging, I manually invoked the validator like this:

                IResourceValidator validator = ((XtextResource) resource).getResourceServiceProvider().getResourceValidator();
                List<Issue> issues = validator.validate(resource, CheckMode.ALL, CancelIndicator.NullImpl);
                for (Issue issue : issues) {
                    logger.error("Validation issue: {}", issue.getMessage());
                }

The reason I did that was to try to find the reason why serialization now fails with the exception shown a couple of posts above. If this is just a warning, and has always been there, it’s fine. I know why it’s there, I use a placeholder value for the script/action/then part when serializing, and then replaces that with the actual content after serialization. The placeholder is just a string, which has “no side effects”.

What I really need to know is why serialization of DSL now fails.

[Lolodomo]

I plan to make another change in DSL Rule file syntax to allow 0 trigger. Easy to do

Regarding the visibility, what is exactly the purpose of making a rule hidden to UI? I could also add this visibility feature to DSL file syntax.

[Nadahar (Nadar)]

@Lolodomo

Regarding the visibility, what is exactly the purpose of making a rule hidden to UI?

I have absolutely no idea, it’s something that has been there since the Eclipse days I believe. I did look into it somewhat once, and as far as I remember, there were some elaborate plans for using rules for “partial processing” or something that would make sense to be presented as separate rules. But, I just don’t remember. It’s there, and removing it would probably break something, so I’ve just “worked with it”.

Since I don’t know what it can be used for, I don’t know if there’s any point in implementing it in DSL.

But, unless I can figure out what broke DSL serialization, I’m stuck with this whole project. I really have no idea where to look, the DSL model structure isn’t very easy to debug.

[jimtng]

@Lolodomo

Regarding the visibility, what is exactly the purpose of making a rule hidden to UI?

In the JRuby helper library, it is used to create ephemeral internal supporting rules.

[Nadahar (Nadar)]

Regarding the serialization problem, I have gotten something to work now, but there is some work remaining to put it all together. I’m not entirely sure exactly what caused it yet, but I think I’m on my way to figuring it out.

edit: Tags are working too now:

rule "Self contained rule 1" [Test, Test2]
when
	Item MySwitch received command
then
	logInfo("test", "Global variable is not")
end

rule "Self contained rule 2" [Test, Test2]
when
	Item MySwitch received command
then
	logInfo("test", "Global variable is not in use")
end

[Nadahar (Nadar)]

It looks like the problem is solved. I have no idea exactly what triggered the problem, but it seems like it had to do with “hidden references” in the model. I create a placeholder for the script/action/then part during serialization, and then replace that with the actual content after serialization. This is to preserve the formatting of the script, and frankly, because it’s simpler than having to parse it.

When I generated the placeholder, I did it in a “temporary context”, and I then moved the generated “expression” into the rule. This used to work, but no more, apparently, probably because it contained some “hidden references” to the temporary context. I’ve now found a different way to generate the placeholder, that I think is “more robust” in that it shouldn’t contain any “hidden references”, and this made serialization start working again.

So, perhaps this had nothing to do with the rebasing, but that the previous process was simply “volatile”. Or, perhaps this has to do with changes to ScriptStandaloneSetup (which I used), but regardless, the “new way” is cleaner and should be more robust.

[Lolodomo]

@Nadahar

I have absolutely no idea, it’s something that has been there since the Eclipse days I believe. I did look into it somewhat once, and as far as I remember, there were some elaborate plans for using rules for “partial processing” or something that would make sense to be presented as separate rules.
…
Since I don’t know what it can be used for, I don’t know if there’s any point in implementing it in DSL.

Isn’t it even dangerous to have rules that can be hidden to our administrator UI ?

If they are hidden, by the way, they can’t benefit from any conversion feature in Main UI. So should not be annoying in practice if you reject these rules.

And what is the expert visibility?

[Nadahar (Nadar)]

@Lolodomo

Isn’t it even dangerous to have rules that can be hidden to our administrator UI ?

If they are hidden, by the way, they can’t benefit from any conversion feature in Main UI. So should not be annoying in practice if you reject these rules.

And what is the expert visibility?

I can’t answer these questions, it’s been like this “since the beginning of time” as far as I know. I don’t think it’s “dangerous”, we could easily make an option in the UI to show hidden and expert, so that they can’t be “truly hidden”.

From what I can see, these options have been there since the very introduction of automation:

Initial implementation of the automation component (#317)

[Nadahar (Nadar)]

I think I got tags working correctly now, I’ll have to study the changes to the triggers next:

rule "Self contained rule 1"
when
	Item MySwitch received command
then
	logInfo("test", "Global variable is not")
end

rule "Self contained rule 2"
when
	Item MySwitch received command
then
	logInfo("test", "Global variable is not in use")
end

rule "Managed DSL Test" [Testing, Tag2, tag3]
when
	Item MySwitch received command
then
	logInfo("testing", "Not really doing anything")
end