//this is how to run a script file
var FrameworkUtil = Java.type("org.osgi.framework.FrameworkUtil");
var _bundle = FrameworkUtil.getBundle(scriptExtension.class);
var bundle_context = _bundle.getBundleContext()
var classname = "org.openhab.core.automation.RuleManager"
var RuleManager_Ref = bundle_context.getServiceReference(classname);
var RuleManager = bundle_context.getService(RuleManager_Ref);
RuleManager.runNow("bbe68f1179"); //the bbe68f1179 is the id of the script found when you look in the script list
There is some overlap in terminology here that needs to be cleared up first.
In OH 2 and earlier, there was a concept of a Script which is a block of Rules DSL code that can be called using callScript(name_of_file.script)Actions | openHAB.
callScript is in the same class as createTimer and transform (ScriptExecution) so it should be accessible by default in Rules DSL. In the other languages ScriptExecution will have to be imported, just like is required for createTimer.
But note the difference. callScript can still only call a Rules DSL script placed into a file in the $OH_CONF/scripts folder. It cannot execute another Rule and since the things listed under Scripts in MainUI are rules, they cannot be called using callScript.
So, a tl;dr is yes, callScript still works and it works exactly like it did in OH 2.5. That means no UI support is provided to create the Scripts in the first place.
That’s pretty confusing
I am actually transferring all my DSL into mainUI (mostly using Blockly so far).
In DSL I used sometimes shell scripts and I have tried this with callScript in mainUI (assuming that the engine looks in /etc/openhab/scripts for it.
This does not work though.
Failed to execute rule 'openVPNon': Fail to execute action: 2
Is there a way yet to execute shell scripts or bash commands like executeCommandLine in DSL?
Another solution, which I had to resolve to when coming to OH3 from OH2 (because callScript was broken there for a while) was to put the contents of my (DSL) scripts into (DSL) rules and just postUpdate a virtual Switch item to trigger them instead. That will always work.