Yes but it’s just a regular rule so it would be like I posted up in post 103.
A “Script” in the UI is just a rule with a single script action tagged with “Script”. It’s actually a little confusing in that regard which, now that you’ve implemented it I wonder if this is going to cause some confusion.
Honestly the overloaded “Script” term is already causing confusion among users. Maybe if we change this action to “call script file” that might help. It makes it a bit more clear that we are calling a .script file, not a rule under the Script category in the UI.
As you found in your experiments, they are really two very different things.
It’s going to be a little different based on which transformation you’re calling. For examples:
vat Transformation = Java.type("org.openhab.core.transform.actions.Transformation");
var map = Transformation.transform("MAP", "MyFile.map", "Some sting, maybe Item's state"); // Calls the map transformation
var regex = Transformation.transform("REGEX", ".*Begin(.*)End.*", "Some sting, maybe Item's state"); // Calls the REGEX transformation
var jsonpath = Transformation.transform("JSONPATH", "$.foo.bar", "Some JSON string with foo and bar elements, maybe Item's state");
It always takes three Strings, the first is the transformation to apply. The second is the argument to the transformation, such as the file to use or some other string telling the transformation what to look for. The last argument is the string that the transformation will transform.
It gets tricky because the first argument can only be one of the currently installed transformation add-ons. The second argument wholly depends on what the first argument is. So I’m not entirely certain if you can do much to help the user beyond just letting them entry arbitrary strings for the first two arguments. But if there were a way to provide just the list of installed transformation for the first argument and then a sort of builder for the second argument that would be fantastic, but I’m certain well beyond what’s possible.
I would expect “call rule” to go here as well. But in case I’d expect the category to become Scripts and Rules. I can also see executeCommandLine here too. I big gotcha with that one though is can you do a function with an arbitrary number of arguments?
Maybe to avoid confusion between executeCommandLine maybe we should name the block you’ve already built “call openhab script file” and then executeCommandLine can be something like “execute command line”.
An argument could be made that transform goes here too. In all these cases you are calling out to something outside of the current rule.
No, it’s a core Action available by default on all openHAB instances.
No, the whitelist doesn’t apply to executeCommandLine, for which I’m not super happy with as I think it too should be protected in the same way. Either the authorization built into OH 3 is sufficient for both the add-on and Action or it’s not. But I lost that argument.
So you are OK with calling executeCommandLine without any other external dependencies.