OH3 files or GUI

Tags: #<Tag:0x00007efed25b79f8>

In OH2, I configured everything through files, it was very convenient and understandable.
In OH3, it seems to me, a lot of attention is paid to the graphical interface, as well as setting up the system from the graphical interface.
I have a question, when setting up a new OH3 server, what can be configured through files, and what is better to configure through the graphical interface, so as not to get any restrictions in the future, due to the fact that I used files (things, items) and not setting from the interface?
What is preferable to use for writing rules? And how to do this, in files or from the interface, which option will be considered official for OH3?

Currently many people are just using their OH files for rules and items. I personally define Things through the UI anyway for simplicity. If desired I believe your sitemap files will work with the Basic UI.

My current plan is to use files for items and use HABapp with files for Python 3 rules.

For me the main challenge will be learning and using the new UI.

1 Like

I previously setup oh2 with a combination of files and paperui. In my tests so far this upgraded fine using openhabian. a few issue’s as expected but easy to fix. I have also spent a bit of time learning the new ui and have completely setup my system over a few days using only the new ui. Still a few issues but should be an easy fix. And I am not a programmer, and did struggle at times with the files approach I have about 100 or so items setup and it seems stable.

It comes down to your preference really, but here’s my 2 cents after playing around with OH3 for a couple weeks:

  • Things via the UI remains the recommended way (AFAIK) because they are rather complicated.
  • Items via the UI will reveal more available configuration options like special metadata. You can just configure this metadata then change to the code view to know what the names for the keys are to use in a file.
  • One big plus I’ve noticed in OH3 with files is that they are fast. No longer does it take a second or two per file to load, I have 8 items/things files so far and it takes about 800ms to load them all!
  • Another plus I’ve noticed is the file loader is smart. No longer does it delete all items from a file and recreate them when a write happens to that file. Now it parses the file and only applies changes where needed.
1 Like

Very good information. I have not had as much time to work with OH3 due to other life commitments.

Another thing to metion is that not all information could be processed with the ui.

Transformations and persistence still require the use of files.

1 Like

Indeed the .persist files are the only way to setup persistence strategies, but what do you mean about transformations not being available?

At the weekend I had some time to play with OH 3 and came, for me, to the following result:
Things: Only through the user interface.
Items: Is much faster and clearer via files, but in OH 3 many items from files are not found when assigning them to channels, I also create new items via the interface. A table view with multiple selection would be very useful here.
Rules: Via files, in the user interface, the functionality is “still” too low.
Pages: Here the possibilities in OH 3 are a dream. I only use the sitemap for the Android app.

If I understand correctly, having some Items configured through files and some through the UI can lead to confusion later. Simply choosing one method is better, IMO, especially for this of us with aging memories.

1 Like

I meant the Transform folder. I.e. i use plant sensors and i have a map transformation that changes a numer into a roomname. This could not be done in the UI or i have missed something

Ah, yes you are correct as far as I know there is no way to define map/scale/js transformations from any UI.

It’s going to depend on what you are comfortable with. All the text configs that are currently in use are still supported. So you can do everything in files. There are some limitations with .things files even in 2.5 and those do not go away. There are also some long time bugs that may or may not be fixed in OH 3 when using text configs (missing Items after clearing the cache, rules start running before Items are ready, etc).

Based on my experience thus far, I do no hesitate to recommend doing almost everything through the UI. There are some neat little features with having rules in JSONDB which are nice such as getting to avoid a lot of the boilerplate for creating a rule, the “but only if…” conditionals, being able to create simple rules with no code, etc. Boot times are greatly improved.

Items are pretty manageable now and the UI fully supports tags and metadata now. And you can bulk create/import/edit them. And there is support for Google Assistant and Amazon Alexa directly in the UI. No need to look them up and risk getting the syntax wrong.

I’m personally not going to bother with sitemaps any more either. I’m relying on the Item model and Pages for my UI and it’s great! It almost builds itself all by itself.

Almost everything has a code view that shows the Item, Rule, Widget, etc. as YAML which can be edited, copied and pasted (e.g. for sharing or asking for help on the forum), etc.

I can’t guarantee it, but I expect the Getting Started Tutorial for OH 3 is going to focus primarily on doing everything through the UI. But if you are already comfortable with text configs nothing will force you to use anything else.

An issue filed on the openhab-webuis repo with more details would be welcome I expect.

What functionality do you miss? So far the only functionality I’ve encountered that is missing is the ability to define a global variable that is shared across multiple rules. But there are other probably better approaches for that anyway. There might be a bug with the notification Actions too but it’s a bug, not missing. So far I’ve successfully (in ECMAScript):

  • loaded my own libraries
  • exercised most of the built in actions including creating timers, executeCommandLine, logging
  • saved and recalled a variable from one run of the rule to the next (e.g. checking to see if the rule has an active timer to reschedule or cancel it)
  • accessing, commanding, updating Items
  • general programming stuff the language supports like creating functions, classes, loops, filtering lists, etc.
  • creating/deleting (I probably will drop this approach in my code), disabling/enabling, and calling other rules from a rule.

I’m in the process of rewriting my Jython modules tools libraries to JavaScript for use in UI created rules. Then I plan on writing the scripts so they can be imported as YAML (until we have a marketplace for rule templates).

I can certainly provide examples where needed. I’ve posted a bunch of examples as I figure them out already at openHAB 3.0 my getting started notes: Rules

2 Likes

Maybe I haven’t figured out everything that’s possible yet. So far I have seen “if then” in the “DESIGN” view with an additional condition. I haven’t spent much time with it either, the weather was too good for OH at the weekend.
I am not yet concerned with the “CODE” view, does it look like what I program in the files, or is there something else behind it?
I’ll take a look at your examples, I’ve overlooked them so far, thanks for that.

You are certainly right, I also try to transfer room by room into the UI, as I keep running into problems when I want to assign the text items to channels.
I only find it clearer and more efficient when I want to change metadata or icons to see them in table form in front of me. I can search and replace many things very quickly.
But I will still try to replace the OH files in the coming weeks, at least for items.

Rules are, as they always have been, event based. In MainUI a rule has three main sections:

  • when: the events that occur to trigger the rule to run
  • conditions (labeled “but only if”): the states to check to determine whether or not to run the rule
  • actions: what to do when the rule runs

So, if you want to send an ON command to Item Foo when Item Bar changes but only if Item Baz is ON:

  • create a trigger under “when” for changes to Item Bar
  • create a “send a command” action under “then” to command Foo to ON
  • create an “a item is a given state” condition under “but only if” and configure it with Baz == ON

For both the conditions and the actions you have an option to write a script. This script lets you write arbitrary code in the supported language of your choice. So if you need more complicated logic or actions than the simple options in the design view you have those options. As I said, the only thing that cannot be done (as far as I’ve tried) is share a variable across multiple rules. Everything else that can be done in rules can be done through the MainUI. But of course, at some point everyone will have to touch “real” code in their conditions or actions. But even there Blockly will be an option.

It depends on what you mean by “look like”. It’s in YAML and it has that extra conditional “but only if” section. So from that perspective it looks different. But it still have triggers and code to execute so from that perspective it looks exactly like code you write in text files.

Here’s an example of a simple rule I have to set a Switch to ON when cloudiness gets above a certain percentage.

triggers:
  - id: "1"
    configuration:
      itemName: vCloudiness
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: >-
        if(items["vCloudiness"].class == UnDefType.class) {
          events.postUpdate("vIsCloudy", items["vCloudiness"].toString())
        }

        else {
          var newState = items["vCloudiness"] > new QuantityType("50.0 %") ? "ON" : "OFF";
          if(items["vIsCloudy"].toString() != newState) {
            events.sendCommand("vIsCloudy", newState)
          }
        }
    type: script.ScriptAction

However, this rule could easily be written as two rules without the JavaScript script action.

triggers:
  - id: "1"
    configuration:
      itemName: vCloudiness
    type: core.ItemStateChangeTrigger
conditions:
  - id: "2"
    configuration:
      itemName: vCloudiness
      operator: <
      state: 50 %
    type: core.ItemStateCondition
  - id: "4"
    configuration:
      itemName: vIsCloudy
      operator: "!="
      state: OFF
    type: core.ItemStateCondition
actions:
  - id: "3"
    configuration:
      itemName: vIsCloudy
      command: OFF
    type: core.ItemCommandAction
triggers:
  - id: "1"
    configuration:
      itemName: vCloudiness
    type: core.ItemStateChangeTrigger
conditions:
  - id: "2"
    configuration:
      itemName: vCloudiness
      operator: >=
      state: 50 %
    type: core.ItemStateCondition
  - id: "4"
    configuration:
      itemName: vIsCloudy
      operator: "!="
      state: ON
    type: core.ItemStateCondition
actions:
  - id: "3"
    configuration:
      itemName: vIsCloudy
      command: ON
    type: core.ItemCommandAction

The above two rules duplicate my original rule with the JavaScript Action’s behavior without needing to write any code. And with the code view, I was able to copy the first rule, create the second rule, paste and edit the code to flip the conditions and I was done.

  1. Create the first rule

  2. Copy the code

  3. Create the second rule and fill in the ID, name, and description

  4. Switch to code view and paste the YAML from the first rule and change the conditions and action as appropriate.

1 Like

Thanks everyone! No one said that I would get any functionality limitations when using files. Therefore, I transferred part of the files of things and items to the new OH3 server.
All my rules in OH2 were rewritten to jiton, what to do with this now, I do not understand. After reading the forum, I did not come to an unambiguous answer as to how it is preferable to write rules in OH3, this question remains open.
New question, I am trying to make a model. As I understand it, locations are groups in item files. And the equipment and points, how and in which files to register?
Thanks!

That is because OH is flexible and the decision is a personal choice after weighing the advantages and disadvantages.

Only you can weight the pluses and minuses of the approaches and come to what works best for you. Perhaps you don’t care about the functionality that is missing when using text configs (not that there really is all that much missing functionality). The getting started docs will have to choose an approach and I expect it will choose doing everything through MainUI, but that doesn’t mean it’s the best approach for you.

Equipment is usually represented as a Group. It’s location is set through which Location Group it is a member of. All the sensors and actuators that make up the Equipment are represented by Items that belong to it’s Group. You define whether a Group or Item is Equipment or a Point through Item tags. MainUI makes doing this relatively straight forward by presenting the semantic tags as separate options and have a drop down list of the allowable tags.

So, using MainUI, if you already have an Item that you want to make a point on an Equipment:

  1. Create the Equipment from the Model page and configure as appropriate
  2. Switch to the Items page and search/browse to the Item you want to add to the Equipment
  3. Click on edit and add the Item to the Equipment Group and set the Semantic Class and Property as appropriate.

There is an issue open to make it easier to select and modify existing Items as part of the Model. But there are more important issues being worked first.

1 Like

All my things and items are added as files. Therefore, the question was what and where to register in the files (groups, tags, or something else), so as not to create equipment and points through the UI.
Thanks!

That has not changed since OH2 and the file entries are well documented. This forum is not a replacement for the documentation from the developers.