I’m trying to understand the way OH3 is handling a OH 2.5 rules file.
I have for example a sonos.rules file. That files starts with some val and vars then System started rule and then some other rules. I can find all the rules back in the OH3 GUI (system is splitting the rules file in separate rules). Now the question. Where are de val and vars? How do the rules know there values and where can I find them? How should I work with OH3 if in this case it comes to the sonos.rules file. How do I make a clean setup with the sonos.rules file matching the GUI?
Next I didn’t install any bindings or services through the GUI yet but in the copied the file addons.cfg with the line persistence = rrd4j, influxdb, mapdb for instance. How can I check if those services are installed? Is the only way the API explorer (as shown below)?
[
{
“id”: “influxdb”,
“label”: “InfluxDB persistence layer”,
“type”: “Queryable”
},
{
“id”: “mapdb”,
“label”: “MapDB”,
“type”: “Queryable”
},
{
“id”: “rrd4j”,
“label”: “RRD4j”,
“type”: “Queryable”
}
]
If you have your rules in a .rules file then those rules I believe still run in a scope where they have access to any global variable defined in that same file. In fact, if you have multiple rules that utilize global variables a .rules file is the only way to make that work. Rules created through the UI all exist in separate scopes and won’t have any access to global variables.
The UI will show all rules in the OH system, even those created by rules files. You just won’t be able to edit any rules defined in the text files through the UI. The UI will not recognize or present anywhere global variables that are define the in rule text files. If you want to be able to work with your rules through the UI then you will have to abandon the text files and rebuild the rules through the UI. This isn’t as bad as it sounds; for the most part you can just setup the triggers and conditions of the rule and then copy your relevant functional section into the appropriate type of script action. The problem will arise with those global variables. You will have to find a way to reconfigure you rules to run without global variables. There are a few options:
Convert all your global variable into items. All rules have access to the item registry and so an item that is not linked to any thing via a channel will simply behave as a global variable for all rules.
Keep the necessary rules in a library file of scripts and call those library scripts from the script action of the UI rule (doesn’t work with Rules DSL but works if you’re using javascript or python)
As for your other question: installed persistence add-ons will be viewable through the Add-ons -> Persistence menu on the settings page.
This actually won’t work as expected, unfortunately, in terms of sharing variables. Each Script Action/Script Condition will have its own copy of the imported library. As a result, they still won’t be able to share variables. But this is great for reusable functions and other code. For example, I have a library that centralizes all my alerting that I import as a library to multiple rules.
There is a theoretical way to share variables between rules using ScriptExtensions but I’ve not has time to dig into the code to figure out how to use them. What is a little exciting though is we ought to be able to share variables with other rules regardless of the language they are written in this way.
In addition to looking at the Add-ons settings page in MainUI, you can look at /var/lib/openhab/config/org/openhab/addons.cfg which should list all the add-ons that are configured to be installed.
If the add-ons are listed there OH will try to install them. To see if they were successfully installed, in addition to the REST API and MainUI, one can issue a command in the karaf console bundle:list which will show all the installed bundles including add-ons.
