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.
That’s on purpose, see The Road Ahead - Reintegrating ESH. Please note that the idea is only to decide whether or not to reduce/merge the existing UIs, it is NOT about any technical decision, what framework to use and what exactly to build - that’s up to the developers then.
Love this idea! It is possible to vote for this somewhere or indicate that it would be great that this UI should replace the existing one (mainly PaperUI)?
Don’t know why you deleted but I was able to read it through fastly.
In my opinion (as only a 1 year old user of openHab), your way could be the best I think. We will still need some HabPanel or other UI which can be optimized just for display&control, but it would be much-much easier to understand. Just one Next-Gen PaperUI and a HabPanel like UI.
At first sight when I saw openHab, the main problem was that I didn’t really know why it has so many interface. Somehow I found that PaperUI seems the ‘most advanced’ I started using that as an ‘admin’ panel. Later I just read that this is what it supposed to do. However since then I have seen many others who gets confused what to use for what.
Also you wrote there or in another post, that usually people configure their OH on a bigger screen. That’s right, but if it’s possible, the new ‘PaperUI’ should have a mobile friendly version. Sometimes I need to configure something simple (like adding a new IP or similar) and if I don’t have my laptop/PC turned on or nearby to me I usually use my phone for these simple tasks.
It can be one, but then that one should have much-much configuration option. I have a wall-mounted tablet with HabPanel on it, I don’t want to see anything other than controls on that tablet (no big menus with inbox, maintenance and others in it…).
I disagree, I think you need at least two UIs. One user UI and one admin UI. In my perception, and many others, that’s exactly what PaperUI and HabPanel currently are.
I experienced both separate and unified UIs. What I found to be optimal for me is one UI which allows you to pick “favorite” controls that appear on a “main controls page”.
UI reduction is necessary. But habmin for instance has a super advanced zwave UI for example. And nobody talks about rescuing all those man hours that went into it.
I have some advanced proposal in this design study as well. And the way how the AC is currently acting is not correct is my feeling.
To be clear, I understand your point completely, but my perspective would be to have two separate interfaces, and they can be using the same engine or backend or whatever (or not), but I would provide a clean user-only interface to the other people in my home, to avoid “Daddy, what does this button do?” kind of situations.
