Next generation design: A Paper UI replacement proposal

[aymeric106 (Aymeric)]

Hello, not sure it’s the right place to do so, but at least concerning the new Paper UI, here’s an idea.

In the “backup” section, a nice thing to add would be “snapshots”.
Meaning, not a full backup (you do on a regular basis), but a quick way to revert to your working configuration it you wan’t to try a binding or a new rule.

Also, some kind of docker module integration would be nice. In my case, on my openhabian raspberry PI, i’ve installed some modules with openhabian-config, and also manually, for my openhab ecosystem (like ZIGBEE2MQTT, MIFLORA2MQTT, TASMOADMIN,GRAFANA,…). It would be nice to have this integrated in some way into openhab, and docker seems to be a good way to do it. (I think home assistant works this way).

I didn’t really understand the GUI <-> config text files interaction in your proposal. Just to let you know, I always end up doing the same thing with the current interface.
First basic binding install + thing discovery + needed items selection (in Paper UI)
And after a while, most of the time, for different reasons, I have to create the same thing and items manually with config files, and remove the “automatic” things and items from paperUI.

Aymeric

[David_Graeff]

@aymeric106

I didn’t really understand the GUI <-> config text files interaction in your proposal.

The design proposal has new users in mind, who don’t know anything about the current .thing/.item files and I will do my best to never mention those in the interface as well. The idea is that you never have to fallback to those files.

@aymeric106

Also, some kind of docker module integration would be nice.

I thought about a “platform” service, that offers some actions via the REST API but came to the conclusion that this is not really openHABs task and would be a lot of effort. There are also windows users here and they would want to have a similar functionality soon, too. A better solution is probably for openhabian-config to offer a web-interface and we only add the link to Paper UI NG.

[aymeric106 (Aymeric)]

@David_Graeff

I thought about a “platform” service, that offers some actions via the REST API but came to the conclusion that this is not really openHABs task and would be a lot of effort. There are also windows users here and they would want to have a similar functionality soon, too. A better solution is probably for openhabian-config to offer a web-interface and we only add the link to Paper UI NG.

To clarify a little bit, the main reason to have this “inside” openhab is for backups. One backup with all inside is a good thing to beginners who break things

[David_Graeff]

@aymeric106

To clarify a little bit, the main reason to have this “inside” openhab is for backups

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?

[aymeric106 (Aymeric)]

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.

[vzorglub (Vincent Regaud)]

@aymeric106

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.

[rswennen (Rohnny Swennen)]

@David_Graeff

There is no official or community decision yet, but if its going my way, the old textual configuration syntax will vanish completely. (Import tool will exist then of course)

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

[David_Graeff]

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?

[rlkoshak (Rich Koshak)]

@David_Graeff

next generation Paper UI.

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.

@David_Graeff

Context help on every single page. Inline explanation texts were necessary.

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.

@5iver

I have ~200 Things and ~1000 Items. There is a lot of white space in the list view, which could be shrunk down for better viewing.

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.

@5iver

There’s a filter, but there doesn’t seem to be any option to sort Items, Things, etc.

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.

@5iver

Textual configuration displays all Items or Things… individually would be much easier to mavigate.

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.

@RolfV

What I also though about, is how I currently make my rules. That is, for like 50% of my rules at the moment, a lot of mimicking other rules that I previously made. To achieve that I generally switch back and forth between tabs in Visual Studio Code. So would that in some way also be possible in a new rule interface as well? So some kind of copy-paste function for actual copying and a way to quickly and easily switch between different rules for mimicking?

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.

@Andrew_Rowe

I have been digging around for 20 minutes trying to find the graphical rules engine project… what is it called with the node red type rules interface. That is what the rules engine should be in a ‘blue sky’ user interface IMHO. Some thing akin to IFTTT or stringify where folks with zero programing ability can piece together basic rules… someone please link but anyhow subject for another thread…

@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

@yves

I assume that will always be related to the installed version of OpenHab.

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.

[David_Graeff]

@rlkoshak

Or do you intend this UI to also be the UI for creating what we call JSR223 Rules today?

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?

@rlkoshak

Is commanding an Item the only way the scheduler can trigger Rules?

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.

@rlkoshak

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

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.

@rlkoshak

Good idea. It would be really useful to have the option to sort by last edit time so,

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.

@rlkoshak

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.

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.

@rlkoshak

Rule Template

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.

[rlkoshak (Rich Koshak)]

@David_Graeff

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.

But a Script is one of the supported Actions.

@David_Graeff

Btw: The script that is shown should be state-of-the-art on how to create a rule via javascript, isn’t it?

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.

[yves (YvesHanoulle)]

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.

[David_Graeff]

@rlkoshak

Yes, but, at least using the terminology used in PaperUI,

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.

[David_Graeff]

@yves

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.

Please stay on topic, textual file configuration is not the subject here.

[yves (YvesHanoulle)]

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.

[rlkoshak (Rich Koshak)]

@David_Graeff

Ok, we might come up with some new terminology then

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?

[David_Graeff]

@rlkoshak

BTW, do you want me to generate a bunch of issues on the github repo, one for each bullet point,

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).

[David_Graeff]

@yves

for me it is, because you keep mention also in this thread you want to have text files go away.

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

[hilbrand (Hilbrand Bouwkamp)]

@rlkoshak

But a Script is one of the supported Actions.

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.

[David_Graeff]

@hilbrand

‘else’ condition

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.