Using OH4.0.4 and if I open a rule and just view the script, the script gets “changed” and the log says “rule xy has been updated”.
Is this really necessary? I often open rules just to check the syntax and or their logic, but especially with JS-Scripting this results in the rule being “delayed” for 20secs for the next run, because it’s not yet loaded.
My wish would be to just open the script in “view mode”, if I later press “Save”, of course the rule has to be updated then, but not for viewing only…
it’s completeley independent, whether the script is a JS Scripting ECMA-Script or DSL or whatever script, the behaviour is always this (at least with my OH4.0.4):
change to rules => nothing
click on the rule => nothing
click on “code” => nothing
open the script => rule is updated
2023-11-28 12:03:04.977 [INFO ] [openhab.event.RuleUpdatedEvent ] - Rule 'BalboaTimeDelta' has been updated.
saving the script => rule is updated
2023-11-28 12:03:36.236 [INFO ] [openhab.event.RuleUpdatedEvent ] - Rule 'BalboaTimeDelta' has been updated.
the script:
configuration: {}
triggers:
- id: "1"
configuration:
cronExpression: 0 0/10 * * * ? *
type: timer.GenericCronTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/vnd.openhab.dsl.rule
script: |+
// Aufheizen dauert ca. 15min pro 0,5 Grad
var Number EinGradHeizen = 30 // in Minuten
var Number MinZeit = 30 // in Minuten
// Soll-Temperatur mal auf 36 oder wenn höher, dann höher
var Number SollTemp = (BB_TargetTemperature.state as Number).floatValue
if (SollTemp < 37 ) { SollTemp = 37 }
logInfo("Whirlpool-Heizen", "Soll-Temperatur ist: " + SollTemp)
// Ist-Temp
var Number IstTemp = (BB_CurrentTemperature.state as Number).floatValue
logInfo("Whirlpool-Heizen", "Ist-Temperatur ist: " + IstTemp)
// Aktuelles Delta errechnen
var Number DeltaTemp = SollTemp - IstTemp
logInfo("Whirlpool-Heizen", "Temperatur-Delta ist: " + DeltaTemp)
// Wie lange noch?
var Number AufheizZeit = DeltaTemp * EinGradHeizen
logInfo("Whirlpool-Heizen", "Dauert noch: " + AufheizZeit)
if (AufheizZeit < MinZeit) AufheizZeit = MinZeit
if (AufheizZeit >= 0) {
// Pool ist kälter als Soll -> wie lange dauerts?Pool
BB_Restheizdauer.sendCommand(AufheizZeit as Number)
var Number Strombedarf = AufheizZeit/60 * 2800
EMS_BBStrombedarf.postUpdate(Strombedarf)
}
type: script.ScriptAction
No and there is an issue open to prevent it. The problem is magnified for cases where there is a system runlevel trigger as not only does the rule get reloaded but it runs.
I maintain a series of Scripts with examples to use as a reference. I do that because it’s easier to find but it has the added benefit as since they are not functional the delay caused by the reload wouldn’t matter (I’m running on Intel 64-bit so there is no delay anyway but if there was it wouldn’t matter).
There is preliminary evidence that running on a 64-bit JVM or the GraalVM JRE reduces that delay from 20 seconds to 2 seconds. That assumes you don’t have other reasons for the delay like low RAM, swap usage, or high system load.
If you enable (i.e. set the log level to INFO) the RuleStatusInfoEvents, RuleAddedEvents, and RuleRemovedEvents in log4j2.xml you’ll see the rules being reloaded when clicking on a Script Action if you are not seeing the delay in the browser. That will add the rule loaded events to the events.log.
It’s a bug (IMO) in MainUI. It’s reloading the rule.
There shouldn’t be anything to clean up until the user saves the rule. Merely opening the rule or a script action from the rule doesn’t change anything. There’s no need for a reload. Would you happen to remember anything about the PR where this was implemented? I’d like to link it to the issue I linked to above if I can.
I don‘t remember a PR, but in general it was the intention to cancel timers when a script is unloaded. I wasn‘t aware it wasn’t the intention to unload the rule by viewing.
That would be handled in core, not MainUI. I don’t think that would be related to this behavior. Also, if this is the same changes I’m thinking of, that was implemented as part of the cache.
In this case, MainUI is actively pushing a reload of the rule to the server upon merely viewing a script, which is unnecessary. I don’t think this is deliberate.
I did the same in the past but now changed my behavior and using the code tab of the rule to review the code of the script action, instead of opening the script action itself.
This does not trigger a rule being reloaded.
At least for me that’s a good workaround and I thought it’s worth to mention.
Correct.
Timers created by setTimeout and setInterval are handled by the add-on and timers created using actions.ScriptExecution.createTimer and stored in the cache are handled by core.
It is not pushing a reload, it is just saving the rule, which triggers a reload. Saving the rule before leaving the rule towards the script editor is necessary if the rule has changed, but only if. Currently, the rule always is saved.
I will try to provide a fix for that soon.
Hi Flo, just to make sure you have full information. Are you aware that saving a rule is triggered even if you just view a rule (as opposed to leaving a rule from edit mode)?
Yes, this is what I tried to describe above.
MainUI should not save the rule when opening the script if the rule has not been edited, but it currently does.
Should be an easy fix once I have the time for it.
Now MainUI does only save the rule if it has actually changed when navigating to the script editor.
In case you add a new script, it unfortunately has to save the rule, so in that case the issue with the “blocked” rule editor because of the JS compilation time isn’t gone for rules with start level trigger.
Hi Flo,
when leaving a Thing‘s code tab without having changed anything, you will be asked to save the Thing.
I am on M5. I think this behaviour is new and might be related to your bug fix?
No, it isn’t new. In fact it is existent since the very beginning, I had a look into it a few weeks ago, fixing that requires some larger refactoring of the YAML parsing.
