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.
-
Create the first rule
-
Copy the code
-
Create the second rule and fill in the ID, name, and description
-
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:
- Create the Equipment from the Model page and configure as appropriate
- Switch to the Items page and search/browse to the Item you want to add to the Equipment
- 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.
I just asked for help 
My English is very bad, maybe that’s why I didn’t find the information I needed. I’m not aware that model building was available in OH2, maybe there were equipment and points, but I could not formulate the correct search request, sorry. Of course, before asking a question, I spent more than one hour searching for the information I needed and from hopelessness, asked for help. If you find it difficult to help me, ignore my question, there may be another person who can help me …
Thank you for understanding.
1 Like
Just to be preceise. Model Building is nothing special used in OH2. A model consist of tagged groups.
I.e. A Living room in the model ist a group called “Living room” with the tag “LivingRoom” and Groups and Tag are used in OH2 too.
If you like to learb modeling just try it in the ui and see waht happens and then try to build it with a file definition. The most complex parts is to catch all the ideas behind the model
You asked about groups and tags that are documented on the Items page. I answered on that basis. Sorry.
I am still trying to understand the current usefulness of semantic tags.
An argument for programming via the UI is for me, especially since 3.0, that everything can be done via “myopenHAB”. That works really well.
Of course we can also use VPN, but it works without creating a back door into the rest of the network.
You cannot add items there I thought.
Entities added through files are still accessible from myopenhab.
“Add Link to Item” and “create new Item” in things works her and “add new Item” also.
1 Like