Backups for openHAB are addressed in the design study. But openHAB is not responsible to restore your Grafana installation for example. Did I miss-read you?
It would be nice if it could. (I m. viewing my raspberry pi + openhab + all other modules as an openhab box). Anyway “snapshots” are directly related to this discussion, the other ideas are more generic ideas that may not be doable or what openhab wants to be.
Openhab wants to be an Home Automation platform, not an operating system or a back-up manager.
This conversation has already been had on another thread.
If you want an operating system use, openHABian that comes with Amanda for back-ups
If you want a back-up system there is a lot of choice out there depending on your OS.
I understand to,some extend and I’m not sure whether I’m the only one but my 2 most important bindings are v1 bindings without support or any development towards v2.
So for me this would mean I have to abandon upgrading.
Do the developers have any data on binding usage, do you know what bindings are used most often, it would,give you an idea about how many people still use v1 bindings
1 Like
At some point OH1 bindings cannot be supported anymore, but that is still somewhere in the future. Http will get a new version this cycle. For expire there are already solutions being worked out. What are your OH1 bindings?
Let’s come up with a new name. By referencing PaperUI we will be primed to compare this design to PaperUI when we really need to assess it on its own merits. Just an idea.
Does this extend to code entry? One thing I used to love about Java development with a good IDE was not just that we get code completion, but we were also just a quick key combo away from the JavaDocs. Even some of the Ansible add-ons to VSCode and PyCharm have this and it’s a real time saver. I’ve no idea if anything like this is possible but it sure would be nice.
Comments (they are a little rules heavy since I’ve spent a lot of time with the experimental NGRE):
-
The Rules List view is missing an edit icon
-
I don’t like the mix of JSON and YAML for rules. I’d rather see the JSON part also broken up into YAML
-
I love the Rule creation page
-
It’s not shown but I would like to see the ability to create and jump to the Script editor from the Rule Creation page. For example, I drag a Script block to the grid and I have a choice of selecting an existing Script (more than one?) or new and it takes me to the Script editor page.
-
Where possible, when I save or cancel something in the UI I should return to where I was. This is one thing PaperUI gets really wrong IMHO and it makes using it very frustrating.
-
The example code in the Script editor doesn’t really make much sense to me. The Rule is already created on the Rule creation page. The Script part is just the “body” of the Rule. The equivalent of the code between the when and end in Rules DSL. So the only code that should be necessary here is
print("This is a 'hello world!' from a Javascript rule.");. The rest of that code is setting up the Rule and Rule triggers, which is handled elsewhere in the UI. Or do you intend this UI to also be the UI for creating what we call JSR223 Rules today? I want to make sure that we give users the option to have to hand code as little as possible should they choose to, but then give them a way to gradually move into coding as far as they want/need to. I also want to make sure that conceptually, at least using the nomenclature of the NGRE as it exists right now, there is a distinction between a Rule and a Script. The Rule is a collection on one or more of “when”, “but only if…”, and “then” clauses and a Script is some hand written code that can be written for “but only if…” or “then”. When a user is coding in JSR223 style, they will be responsible for all the parts of the Rule in their code. But in the UI side, Scripts are a way to create our own custom “blocks” we can wire up with a trigger (“when”) to form a Rule. Make sense? I know the example shown is probably little more than just an lorum ipsum, but it’s a detail I think is important. -
Change the name of Timer to Scheduler or Schedule. That is really what we are talking about.
-
Now that I see it, I wonder if it makes sense to use a UI more like one sees in Calendar apps like Google Calendar or Outlook for the “default” scheduler.
Then under Custom we can present the cron expression type UI. We would need to include some more time based as opposed to just day based options. Users will be more familiar with that sort of interface and in the decades since calendar apps like this have existed, they have evolved into a UI like this for a reason. -
Is commanding an Item the only way the scheduler can trigger Rules? I think it is a pretty elegant solution. Does it make sense to include Astro events in the Scheduler? Then the entire Time of Day design pattern could be fully implemented in the Scheduler.
-
I really like the options to select the version of an add-on to install and the buttons are clear.
Over all I like the over all look and organization. I love the hints at new features like the log viewer, health and status page, and ability to install alternative versions of bindings. I think it’s a great step forward I look forward to see how it evolves.
This gives me a thought. If I scroll to the middle of my list of Things or Items and switch to one of the other views, it would be fantastic if it kept my place. For example, if I’m looking at Item Foo which is number 45 in the list in the Grid View and change to the List View or the Text View I’m still looking at Foo.
Good idea. It would be really useful to have the option to sort by last edit time so, for example, all the Items or Things you are working on are at the top of the list.
But harder to copy/paste/bulk edit. I don’t know if I necessarily want ALL my Things, but having more than one I think is pretty important.
Having worked with the NGRE a bit, I think a better approach for solving this sort of thing will be to either create a generic Script that can be called from the different Rules, or create a Rule Template (not shown in the mock up) that can be applied then edited as necessary. One thing to remember is that the NGRE is going to allow for more opportunities to reuse code than Rules DSL does.
@ysc built it and it is described at Flows Builder - a visual designer for the new rules engine - #12 by ysc and the source code is at GitHub - ghys/flowsbuilder: Flows Builder - an alternative GUI for the ESH/openHAB2 automation engine
It was mentioned that each JSONDB entry has a version field that denotes which version of OH it was created with. My understanding is OH remains backward compatible with the older versions rather than modifying the entries to comply with the new versions.
At least until such time that there is a change required by the binding that requires changing the format. But we have that problem whether you are hand writing .things files or using JSONDB.
3 Likes
Only this far in your post yet. But yes. Paper UI NG should be able to create “Rules” and “Scripts” and they are differently handled within openHAB. A rule is expressed as a json file (which is markup, not code) in declarative style and contains trigger, condition and action sections like you see in the design study. Those can be edited via a graphical editor with blocks and alike, but also in the yaml markup while you are in the list view.
Scripts are more advanced as you also said and the average user barely need to use a script. The context help on the rules list page explains a bit. Btw: The script that is shown should be state-of-the-art on how to create a rule via javascript, isn’t it?
No. The scheduler code module already provides a “trigger” for NGRE Rules and a timed-task (probably a better name for “timer”, I guess) would cause that “trigger” event to happen on a timeout.
That’s not easy to archive. Usually the browser would, by clicking the back button, bring you automatically back to that position. But all lists are dynamically generated and those need a few milliseconds to build up… too late for the browser. There are some hacks that can be applied. But for sure that should work. This here is just a design proposal anyway. The core developers have not yet decided on a tech stack to be used. That will apparently happen on the next board meeting of the foundation.
For the design study I plan on simulating a 1000 items to find design solutions for huge installations.
I though of showing only the first 50 or so items and a “Load more …” button at the end to dynamically insert another 50 items.
That is only possible with a working filter+sort mechanism, I agree. But I don’t know where to put that sort stuff into without everything looking cramped.
You guys have noticed that you can filter while the editor is open to live update the view? So there is really only what you actually want to see.
That is hard to mockup actually. Because you would need the user to define Variables and those can then be used in a rule-like structure.
But a Script is one of the supported Actions.
Yes, but, at least using the terminology used in PaperUI, a Script is a bit of custom code you write (currently only JavaScript is supported) to be an Action or the “but only if…” part of a Rule. The code gets encoded and saved as part of the JSON entry. For example:
{
"7a6ebf3b-6f0c-4a82-b582-5e7ded2dae42": {
"class": "org.eclipse.smarthome.automation.dto.RuleDTO",
"value": {
"triggers": [
{
"id": "1",
"label": "an item receives a command",
"description": "This triggers the rule if an item receives a command.",
"configuration": {
"itemName": "Test",
"command": "ON"
},
"type": "core.ItemCommandTrigger"
}
],
"conditions": [],
"actions": [
{
"inputs": {},
"id": "2",
"label": "execute a given script",
"description": "Allows the execution of a user-defined script.",
"configuration": {
"type": "application/javascript",
"script": "\u0027use strict\u0027;\n\nload(\u0027./../conf/automation/jsr223/jslib/JSRule.js\u0027);\n\nlogInfo(\"Using the library!\");\n\n//var myLog \u003d Java.type(\"org.slf4j.LoggerFactory\").getLogger(\"org.eclipse.smarthome.model.script.Rules\");\n//myLog.info(\"createTimer---------------------------\");\n//var ScriptExecution \u003d Java.type(\"org.eclipse.smarthome.model.script.actions.ScriptExecution\");\n//var LocalDateTime \u003d Java.type(\"java.time.LocalDateTime\");\n//var DateTime \u003d Java.type(\"org.joda.time.DateTime\");\n//var fnc \u003d function(){\n// myLog.info(\"Timer completed\");\n//}\n//myLog.info(\"Creating timer...\");\n//ScriptExecution.createTimer(LocalDateTime.now().plusSeconds(5), fnc);"
},
"type": "script.ScriptAction"
}
],
"configuration": {},
"configDescriptions": [],
"uid": "7a6ebf3b-6f0c-4a82-b582-5e7ded2dae42",
"name": "Test4",
"tags": [],
"visibility": "VISIBLE"
}
}
}
As you can see, the Action of this rule is called a Script and it includes a bit of JavaScript (with all the spaces replaced with \u0027 for some reason.
In fact, the bulk of the time and effort I’ve spent on Experimental Next-Gen Rules Engine Documentation 1 of : Introduction has been documenting exactly how to write these Scripts (postings 3-5 and counting).
The example you have would be how I would create a completely independent Rule using JSR223. That code would not be saved in the JSONDB.
I’ve been using “Scripts” to denote these self implemented Actions and “JSR223 Rules” to denote whole Rules written in one of the JSR223 languages.
I’ve not seen any official glossary of what we are supposed to call all of this stuff so I’ve been treating PaperUI as the “truth” when it comes for what these various things are supposed to be called.
At least until such time that there is a change required by the binding that requires changing the format. But we have that problem whether you are hand writing .things files or using JSONDB.
Well with hand written files, I can create two copies and rename one to binding.thing. old instead of binding.thing, so I can don’t loose my old configuration when going back.
Ok, we might come up with some new terminology then, as I’m getting confused already. I now got you. Personally I would say a “Script” is a full blown script that stands on its own. And a “Script snippet” or “Scripted action” or so is what is used within a decoratively created rule.
Please stay on topic, textual file configuration is not the subject here.
Please stay on topic, textual file configuration is not the subject here.
for me it is, because you keep mention also in this thread you want to have text files go away.
if you design something with the intention to remove text files, I want to be sure you understand why I think I need them so that what I need to do, is still possible.
Yes please!
I raised this with @5iver earlier today too. I hate the nomenclature we have right now surrounding NGRE and JSR223. It’s indeed very confusing.
Maybe we just use what it’s called in the type and call them “Script Actions”. I think these Script Actions should be callable from a “Script” too, just to further cause confusion. 
BTW, do you want me to generate a bunch of issues on the github repo, one for each bullet point, or just one big one? Or wait until you’ve reviewed the rest?
1 Like
Yes please do so. That’s why this thread is existing, to encourage people to use github as a structured way. Somehow that got out of control (as usual).
1 Like
I do want to. But there are a bunch of other developers and it’s not on my behalf to decide that.
But for the UI presentation I will absolutely hide the fact that we have those .thing/.item files in the hope
that new users will never now. If you go to https://davidgraeff.github.io/paperui-ng/tutorial-1.html and open the yellowish detail part labeled as “This tutorial and also this interface is strictly using new openHAB 2 technology.” it says:
Please be careful when reading user topics in our community, as those can reference older techniques. You want to avoid topics about:
- Sitemaps
- DSL Rules
- .thing , .item files
I love that part 
1 Like
There are 2 ways script is supported. The one you mentioned and as implementation of an abstract method of the class SimpleRule as shown in David’s experimental design. Internally that is some special handled action. If you use that the rule shows up in paperui but the JavaScript not. This will also work with python.
And if I’m correct there is no ‘else’ condition in the new rules. Making creating useful rules rather difficult imho.
It is not turing complete anyway. There are no variables or loops. You would need branch support in the rule json syntax. Those rules are really for the low hanging fruits like “If I’m getting home and it is between 6 and 8, turn the light on”. That will still solve 90% of all automation needs, I guess.
It is common enough for you to have put it in your experimental design example
I might have shamelessly borrowed that from Rete.js, maybe ^^.
We need to find a good way to express those rules graphically. Yannick with this FlowBuilder app chose another way. He “compiled” the designed flow into multiple rules, which allowed him to have branches.
???
I’m not sure I follow what you mean by an else condition.
Anything you can do inside the body of a JSR223 Rule can be done in a Script Action. It also supports all the usual triggers (though it is currently missing Member of, though that may just be a PaperUI limitation). It also has a “but only if…” section where you can specific the states under which the Rule is allowed to Run (essentially all the if return; statements at the top of our currently Rules).
Thus far I’ve not run into any use case that cannot be implemented in NGRE as it is, except for the lack of certain necessary Rule triggers, most of which are a PaperUI limitation, not a NGRE limitation.
Maybe an example will help me understand what you mean.
But that is what the Script Actions are for, or am I missing something?
Though indeed, the equivalent to “global vars” in Rules DSL is absent. There is no way to preserve data in a variable from one run of a Rule to the next or across multiple Rules except by using Items.