I’m not even sure about that. The scripts have access to the “context”, which contain the outputs of previous modules, in a map whose keys are like “moduleUID.outputName”. Then the outputs are “flattened” (code here) and put as “outputName” as variables in the scope of the script. If there are collisions i.e. multiple outputs with the same name from different modules (does that ever happen?), I believe it’s not handled.
Each module has its own outputs which are described in the module types’ manifests (most of them are here) or in the API (/rest/module-types). That’s why you sometimes get event available in the script scope, or sometimes state or command or oldState. It depends on which previously run modules have put their outputs in the context. As for inputs… I don’t even know which module types actually have or use them in openHAB, maybe none!
Edit: I believe the inputs are actually used for “generic” module types i.e. there is a GenericEventTrigger and a GenericEventCondition which will accept an event as an input, and more specialized module types will catch certain types of events and feed them (via their output) to the input of the generic module type… or something… I haven’t fully understood
I don’t expect the “experimental” moniker to be removed from it until after 2.5 anyway so that doesn’t bother me much. Those currently using it are doing so at their own risk.
I’m not sure what the best set of inputs would be. From a strictly library perspective it would be awesome if the user can pass a Group or collection of Items or something like that to the Action Script. Then we wouldn’t need to enforce a “you must name your Items thus” situation.
I’ve only ever seen event (and its absence when the Rule is not triggered by an Item or Channel event.
If developers or users are allowed to define their own outputs then this will almost certainly occur. Right now I don’t think anyone if using this feature yet so I wouldn’t expect any collisions.
@5iver, do you have any insight? You have been mucking around in this code some from the Jython perspective.
The input and output format just string key-values. Triggers have their own values they store. So the interpretation of the values has to be done by the user of a specific Trigger. I would prefer some defined format that is more standardized such that different triggers, conditions and actions can be connected automatically.
Also, from a library perspective, I don’t want to have to write my Rules to only support certain Rule triggers. That takes away a lot of the flexibility we can use. Perhaps there are some Rule template or the like that should support any sort of trigger. Then again, in that case I may not need to depend on the event at all because if it doesn’t matter what the trigger was we probably don’t care what the event was either.
@David_Graeff, just quick fyi, is each namespace may have a value, and/or a set of key/value pairs. It might be worthwhile to have use be able to set the value of a namespace for the UI and leave the JSON for the key/value pairs if used.
The MQTT rule action has two inputs (“topic” and “value”). There are more bindings providing rule actions already like Hue, DMX etc. I haven’t checked the code but I guess they are providing Inputs as well.
The script action takes a generic java object as input, so theoretically everything can be feed in. At least that’s what I’m allowing in Paper UI NG.
There is nothing that outputs a collection yet though. So you are suggesting a component (probably an “Action”) that outputs a configured set of items? That makes sense I guess.
Although this design study is not meant to be an end product, I will finish this part of Paper UI NG. I feel that we need to experiment with the available components in an environment that supports all features. And some components need to be fixed ASAP actually (some are outputting with the type “Event” some with “org.eclipse…type.Event” etc).
Probably just a really poor choice of words, but man, it’s hard not to take that as a low blow, Rich.
I’ve spent a whole lot of time in core.automation. There currently is no maintainer, and it seems all of the developers have pretty much dropped it. I’ve been trying to help fill that gap, and I’m surprised you have such a low opinion of my efforts.
There’s a lot that I would like to contribute towards the design of a UI for rules… when the time is right. I think the rest of this design study is great, just too soon for rules, so I’ve chosen to stay out of that part of the discussion. I often run into this when product managers or UI/UX teams try to build a product around the UI. NGRE will be very much evolved in OH3, so it’s just too early to design a UI for creating/maintaining rules.
ESH is not migrated, there are still a few NGRE bugs to fix, there is very little documentation for the current iteration of the NGRE (Paper UI is only a fraction of this), the unit tests are weak to nonexistent, we don’t have a 3.0 branch cut yet, and far more importantly…
Not dropped. But look how many core developers we actually have: Sign in to GitHub · GitHub, plus @wborn, @martinvw and @hilbrand and @maggu2810. And they all have their specific resort. Everybody is busy with the many PRs we got recently, the ESH reintegration plus the build system change.
I disagree. The rule engine will not change much anymore, it was after all an external contribution and there is too less man power in the OH dev team to re-architecture this. The bugs and unit tests will be tackled of course, but realistically nothing else.
That’s a valid approach though. Because the UI usually expresses what the customers wants. How core developers make that happen in the end is another question. But here we have another situation. The REST api is available, working and reasonable. Not depending on any config formats etc.
It’s absolutely the right time to think about rule UI now.
I would really like to invite you to this design study and to post your ideas and requirements.
I completely agree. Unfortunately experimenting with the JSON directly is really really challenging for those of us who are not experienced with the actual code.
My biggest concern is that it’s really hard to write a Script Action if I can not know ahead of time what information I will have in the Script Action ahead of time. For example, let’s say I have a Rule that is triggered by an MQTT Channel, an Item, or Time with out having to blindly iterate over all the possible combinations of inputs. Some sort of standardized way to make this easier on the Action Script writers (I’m really talking about those of us who will be writing Rules Libraries) would be greatly appreciated.
It wasn’t intended to be negative at all. I intended it to be kind of funny, not negative. I apologize if it came across that way. Text is an imperfect medium.
Let’s rephrase it “you’ve spent a whole lot of time with this code”. That’s what I really meant.
I have nothing but the highest opinion of your efforts. They are the only reason that any progress has been made on JSR223 or NGRE at all.
But those triggers are different by their nature and different outputs are expected. Could you bring up a concrete example for a script that you would have published? Maybe you just need to consider that one case that an item triggered your script action and ignore other cases?
Let’s say someone takes something like the Heating Boiler Plate and turns it into a library of Rules.
No many of us use MQTT to report temperature while others use other technologies that require an Item. Some users may even use a combination.
After importing these Action Scripts (or perhaps Rule templates) some users will say to themselves “Hmmm, I don’t need an Item to trigger this, I’ll just use an MQTT trigger.” Others will be stuck with just using an Item. And who knows, there may be a bunch different triggers that can be used to trigger the Rule.
Inside the Script Action, I need to know what the new temperature is. If I don’t have a standard way of discovering that value I’m forced with creating a switch statement or if/else where I have to go through all the possible inputs until I find the one that has the new temperature. And of course the library has to be updated any time a new trigger type is added to the core that could carry the new temperature.
When I first started playing with NGRE in PaperUI, the separation between the three parts of the Rules really seem to be a powerful way to promote building Rule libraries like this. But the inputs/outputs feels like it pulls us right back to tightly coupling the triggers with the Action, which makes libraries of Rules much more challenging.
I understand the requirement as in the picture. Your published “Script action” would require that the user uses a Trigger component that outputs a “State” type.
That could work. If there is something standardized where I can get the “state” and where the state came from (so Rules can be made generic across multiple Items) that would save a lot of the complexity.
Very true but I’m OK with Time triggers being a special case. The likelihood that it makes sense to trigger a Rule with a state and a cron where the state of something matters seems like it would be low. And I think we can work around that in the rare cases it does come up.
And I don’t mind there being only one or two cases to check for (if cron triggered state will not exist, if state triggered then state exists) then needing to check for every combination of what developers decided to make as inputs.
Although if we can give a name to cron triggers and have that as the input to the Item that could be pretty useful itself. Even better would be a DateTime (or whatever is appropriate for the given scripting language) that the cron trigger represents.
What you probably want is to publish rule templates ay?
I see two possible ways:
In such a template you would just put your script action, nothing more. When the user creates a rule and selects that template your action will be inserted. It’s still the users task to “connect” his trigger with your action. And he can only connect triggers with a “State” output.
Your provide a rule template with a “Channel trigger”, and “Item changed trigger” and your script action, pre-connected. The user would delete whatever he is not using (it he is using items he would remove the channel trigger component for instance.)
In both options I do not see any problem for your script action. You would only need to handle a “State”.
At the moment a script action does not support any Inputs, but as I said that should be changed and the input should be made available to the script context in a documented way. I suggest to add a few generic inputs (java object).
If you wrap such a script action via a composite module type in a rule template (Archived Projects | The Eclipse Foundation) you can define a script action that only accepts inputs of type “State”.
But I have no ideas for the design study how a rule-template creation and publish interface would need to look like. All those goodies like composite module types and freely definable inputs/outputs on such composite types makes it quite complex. It’s definitively a different interface than just editing a rule.
That’s will clearly be an advanced feature we don’t have to worry too much about right now I think. As long as I can create the JSONDB without needing to hand code it, I can then edit it to turn it into a template and publish it somewhere by hand.
Of course, all of this is brain storming. It all needs to be run by the AC before any forward actions are taken I think.
I have added a “Repositories” page. Feedback is welcome.
Technical background: You can install extensions that provide further extensions. One example is the Eclipse Marketplace. Such an extension is configurable. The Eclipse Marketplace for example can provide bindings and also rule templates. Another extension could manage arbitrary maven repositories where add-ons can be found. The extension I have in mind adds npm as source for openHAB UIs. A dedicated repository page might help in organizing add-on sources.
Items
Group functionality (more complicated than I thought to model this)
and writing the tutorial pages. We need some nice diagrams, videos, pictures and of course text to introduce newbies to the interface and openHAB in general. The text should be concise still, no complete novels
It already supports this. Just nobody has uploaded templates yet, I guess, which is not surprising considering that we only do negative marketing (“experimental”) and have no easy to use tools at hand.
FTR, as this is “merely” a design study to drive some discussion about potential future options, I’ve now started the decision process on how to evolve the web UIs for openHAB in general. I think it is pretty important to streamline different efforts and to have a rough official roadmap.
