Finally I’ve got some time to start the migration from OH2.5 to OH3.1 - and as a beginner to OH3 I read as much as I can before but I’ve a question regarding your experience.
I found the post from Rich here:
Is there any performance benefit when using MainUI-rules? In OH2.5 most time was spent on loading my rules during startup
Is there any other benefit of using MainUI-rules than being able to edit them via the UI
I guess the MainUI-rules are backed up with the normal backup-command right? With textual files I would be able to restore them one by one with Amanda-Backup for example… How is this working if the rules are maintained within the MainUI? Is there a direct database access possible?
What about future migrations? Wouldn’t textual rules be more easier to handle?
Sorry, a lot of questions! But I want to take the chance to cleanup everything during the migration and to choose the right direction from the beginning.
I’m no expert about UI Rules but some thoughts about…
Afaik MainUI rules are much faster than those out of the rules files. I did not test this, though, and it might be highly dependent on which flavor of MainUI rules one does use. I never had real issues with slow rules, but only when struggling with chaos code
There are some nice features through the UI, you can disable a rule and there is a button to run the rule manually. It’s also possible to enable and disable another rule from within the code. On the other hand, there is no option to use true global vars through MainUI (at least I’m not aware of any), so there are some things, you simply can’t do anymore, such as dynamic timers.
As of backup, even the rules files are backed up when using openhab-cli backup. To restore parts of a file, you will have to make a copy of the file, then restore, then copy&paste the parts, you want to use instead of old code out of the copy. Of course you can do this through the REST API for MainUI rules, too.
But a partly restore is always much manual processing
A glance into the crystal ball is always hard, especially when it comes to openHAB
Please let me rephrase: I understood that MainUI-rules are not stored as files in /etc/openhab/rules - diretory or does openhab-cli backup extract them and store them there?
Rules entered via Main-UI are stored in /var/lib/openhab/jsondb/automation_rules.json.
Backup takes them from there and restores them to the same location.
Thanks for the information! So in case I „destroy“ a rule, I can restore this json from a backup to an alternate location, and take out the „old“ code from there right?
MainUI rules load much much faster than .rules files. However, the first time an individual rule runs will take a little bit of time as that rule is parsed the first time. Subsequent runs of the rule will run without the delay.
I find the conditionals to be a huge advantage. It lets you separate the tests for state from the actions to perform and ultimately I find the overall code ends up being simpler. Personally I think it encourages the development of simpler and easier to manage rules over all.
And as already mentioned OH initial startup is way faster.
Depending on the scripting language you use, there are additional capabilities that are not available to Rules DSL .rules files such as an easy way to enable/disable rules from rules (e.g. when. a switch changes to ON enable one set of rules and disable another set) and the ability to call another rule as an action for a rule.
Everything done through MainUI is stored in the text based JOSNDB files located in /var/lib/openhab/jsondb. Again, these are text files with all the advantages and disadvantages of text files.
However, every time you make a change, a backup is automatically created in /var/lib/openhab/jsondb/backups. So unlike text configs these files are automatically backed up for you without your needing to do a thing.
And yes, openhab-cli backup/restore backs up and restores everything OH related including JOSNDB.
I can’t see why. It was no harder to migrated JSONDB rules from OH 2 to OH 3. Most of the developers I’m aware of are using JSONDB for their rules.
If using JavaScript or Python one can take advantage of the fact that the Script Action and Condition Action gets reused from one run of the rule to the next. So you can test if a variable exists and if it does not, create and initialize it. If not use the old value. In JavaScript it looks something like:
That way you can save the reference to the timer from one run of the rule to the next and cancel it or reschedule it as needed.
I know of no way to do this with Rules DSL though.
Or even easier, depending on how many changes you’ve made after destroying a rule, you can recover the file in /var/lib/openhab/jsondb/backups. By default it will save five backups of each file.
Thanks for the heads-up! The automatic backup of the json is definitely a pro for switching over to MainUI-Rules!
Thanks again everyone for your help - really appreciated!
So will go ahead with the 3.1 migration but I‘m afraid some more questions will come up - especially as the imho most important document about breaking changes is gone
For completeness, to configure how the JSONDB is backed up navigate to Settings → Json Storage. You can configure how many backups to keep as well as some caching options to limit the number of writes if the JSONDB is changing a lot of records all at once.
Indeed I do have a lot of event changes (for example the gps in my car sends it‘s NMEA-data every 5 seconds) - I also „abuse“ OH as a small network monitor (latency checks, service availability etc). - so I guess it‘s a good idea to limit the amount of writes. I am running on a Mac mini within a virtualbox - so basically I won‘t run into trouble with the sd-card…
Just one more thing: I‘m scratching my head for what „scripts“ are really useful - as far as I read, I can‘t send parameters and I don‘t get return values… Have you found a use case for it?
Not those kind of event changes. Configuration change events. Adding or changing Things or Items or Rules and the like. JOSNDB does not store nor does it do anything with Item events. Persistence is for that.
But if you do something like Create Equipment from Thing a dozen or more Items might be created all at once so those settings can make it wait until all dozen Items are created before making the backup.
Depends on what you mean by “scripts”. Unfortunately the term is overloaded in openHAB.
In Rules DSL you can write chunks of Rule DSL code and put it into /etc/openhab/scripts and call them from Rules DSL rules. These have limited use because you cannot pass arguments to them or get return values from them. But there are some uses: A simple scene management: finally a good use of scripts
In MainUI, on-the-other-hand, a Script is just a regular rule that only consists of a single Script Action. And remember, in MainUI you can call a rule from another rule. You can even pass arguments to that other rule.
JavaScript
// Run another rule
var FrameworkUtil = Java.type("org.osgi.framework.FrameworkUtil");
var _bundle = FrameworkUtil.getBundle(scriptExtension.class);
var bundle_context = _bundle.getBundleContext()
var classname = "org.openhab.core.automation.RuleManager"
var RuleManager_Ref = bundle_context.getServiceReference(classname);
var RuleManager = bundle_context.getService(RuleManager_Ref);
RuleManager.runNow("tocall");
var map = new java.util.HashMap();
map.put("test_data", "Passed data to called function!")
RuleManager.runNow("tocall", true, map); // second argument is whether to consider the conditions, third is a Map<String, Object>
NOTE: Most of that should be put into a library if you plan on using Scripts in this way.
However, these cannot return a value. But often there isn’t a need to return a value. This can be an alternative to writing a library for things like centralizing sending alerts, for example.
When I figure out how to do something I like to save that code into a rule in a MainUI Script for future reference. That’s why I was able to paste in the code above so easily.
There is a special Script you can create from the Developer Sidebar called -Scratchpad- which is a great place to write experiments or test code. It’s quickly accessible from the sidebar and then write some code to sendCommand to Items to trigger the rules under development, for example.
but some thoughts about…
