Delay Rule loading after Startup in OH2?

Tags: #<Tag:0x00007f616e185228> #<Tag:0x00007f6173c7bda8>

Hi there,
I am currently migrating my OH 1.8.3 Setup to OH 2.1 stable. Everything is working fine so far except my rules. Everytime I start my OH2 instance I have different errors and exceptions related to rules because the triggers already fires up some code while loading all objects.
I remember this behaviour on OH 1.8.3 as well and to avoid this I changed

folder:rules=10
to
folder:rules=30
in my openhab.cfg file.

Is there a similair option in OH2?

Thanks in advance!
Ozzy

Unfortunately, this still seems to be an issue…

…where rules get loaded before everything gets initialized. There is no such configuration as in OH1 to delay the loading. Here is a related topic and the solution I had used:

Since then, I have modified the script (you’ll need to create the prestart directory):

#!/bin/sh
mv `\ls -1 /opt/openhab2/conf/rules/*.rules | grep -v Startup.rules` /opt/openhab2/conf/rules/prestart
echo
echo Launching the openHAB runtime...

DIRNAME=`dirname "$0"`
exec "${DIRNAME}/runtime/bin/karaf" "${@}"

And added a Startup.rules file with:

rule "Alert: System started"
when
    System started
then
    Thread::sleep(30000)
    executeCommandLine("/bin/sh@@-c@@mv /opt/openhab2/conf/rules/prestart/*.rules /opt/openhab2/conf/rules",10000)
    logInfo("Rules", "Startup: Rules restored")
end
1 Like

This was one of the things I had hoped was fixed when I migrated to OH2, can only hope they figure out a solution as I do understand (by reading the git issue) there’s not a simple fix. :slight_smile:

Thanks a lot for your Information.

This is a really unsatisfying situation. That means complex setups with a bunch of rules is not possible on OH2.
I will try your workaround and hope this is a temporary solution.

Ozzy

Some of these startup problems can be eliminated by changing “received update” rules to “received command” or “changed” whenever possible, since the items trigger a “received update” on startup…

That’s my experience atleast…

1 Like

Good hint, indeed I have some rules with “received update” triggers.
I will try to replace them :slight_smile:

1 Like

The line in the start.sh has not been executing with the recent openhab 2.2 snapshots. Any idea why or how to fix?

I update snapshot versions often (currently on 1140) and it is working for me.

I just looked again and its definitely not working. It was fine in 2.1. I’m on Build #1143 , but the previous builds were not working either. Perhaps this has to do with my apt based installation?

My /usr/share/openhab2/start.sh


#!/bin/sh
mv `\ls -1 /etc/openhab2/rules/*.rules | grep -v Startup.rules` /etc/openhab2/rules/prestart

echo Launching the openHAB runtime...

DIRNAME=`dirname "$0"`
exec "${DIRNAME}/runtime/bin/karaf" "${@}"

I also never see “Launching the openHAB runtime…” in the log which makes me think that this file is no longer accessed.

Hmmm. I have a manual install and launch OH from a screen session. I restarted last night and confirmed again that the rules were being moved.

image

According to the following, the startup service has been changed to directly start karaf and no longer calls start.sh.

There may be a more elegant want to get the command to run, but I edited my start.sh to comment out the exec line. Then add the following line to /usr/lib/systemd/system/openhab2.service.

ExecStartPre=-/usr/share/openhab2/start.sh

On service start, it will execute start.sh with the mv command first. Then it will start karaf. Likely there is a way to format the mv command to run right from the openhab2.service, but I didn’t have time to figure that out.

2 Likes

I know this thread is a bit old, but I had the same problem: rules which fired exceptions etc. because bindings haven’t been loaded yet. That also let peak the CPU load extremely after a reboot and made the system almost unresponsive.

I think I found a clean solution to this:
Increase the start-level of the org.eclipse.smarthome.model.rule bundles
By default most bundles have start level 80, at least in my installations, all bindings and the rule engine have that value. By increasing the start level for the 3 rule bundles to 90, the problem goes away.

In Karaf-Console:
bundle:start-level org.eclipse.smarthome.model.rule 90
bundle:start-level org.eclipse.smarthome.model.rule.ide 90
bundle:start-level org.eclipse.smarthome.model.rule.runtime 90

The change seems to be permanent. Of course updating openhab to a newer version most likely would reset the values again.

Is there any side-effect I haven’t considered here? Could this be made the default for the installations?

4 Likes

To also add the experimental rule engine to the list, I also had to issue the following command:

bundle:start-level org.eclipse.smarthome.automation.module.script.rulesupport 90

(?) Does anyone know in which config file these settings are stored so we can make these settings persist on updates, until the Openhab dev team finished the refactoring work in https://github.com/eclipse/smarthome/issues/1896?

1 Like

I´ve got some mess in my log and rules when restarting openhabian or just the OH2 service.
Because I have persisted every item via mapdb to restore its state at startup, rules are fired upon restoring these values and this should be avoided.
So luckily I´ve found this thread and configure my bundels in Karaf console (had to lookup what it is…^^) an set it to 90. Now I have to watch if it works.
One question, what does the level stands for? Is it just the sequence in which the bundles are startet or is this some type of delay?

By changing the start-level you can manipulate the execution order of processes. The bundles are generally started on start-level 80, so anything with a higher start-level will execute later.

1 Like

Setting the start-level works good so far. But is it possible to make it permanent? After every update I have to set these values again, which is anoying over time…

As a temporary solution to this you can add a *.script file to your /var/lib/openhab2/etc/scripts folder. The contents of this file would be exactly the same as you type into the console.

My /var/lib/openhab2/etc/scripts/custom.scripts

bundle:start-level org.eclipse.smarthome.model.rule 90
bundle:start-level org.eclipse.smarthome.model.rule.ide 90
bundle:start-level org.eclipse.smarthome.model.rule.runtime 90

The location of this file may vary based on how you installed openHAB. The example used was from “apt install” installation.

The reason why i call this temporary is because i find that it sometimes wont successfully adjust the start levels. This is usually only the case after i’ve updated openHAB.

5 Likes

If this works (does it?) then this should definitely be documented at https://www.openhab.org/docs/configuration/persistence.html#startup-behavior - or better: It should be the default that openhab does startup step by step, something like:

  • bindings, persistence: 80 (should not harm in parallel?)
  • things: 83
  • items: 85
  • sitemap: 88
  • rules 90
1 Like

Unfortunately this is still an “issue” in latest master, the loading order doesn’t make sense at all.

I agree that there should be a default step by step startup, for example like this: First load the things, then the items, then the persistence (including restore), then transformation, rules and sitemaps.

The current behaviour causes quite some issues for me, even though I do proper checks for NULL Values but with rules that start a timer on startup that runs periodically this is sometimes still causing issues for some reasons. I haven’t found a related issue on Github yet, is it planned to bring this loading into some kind of order to prevent this kind of issues (for example Mappings causing all kinds of errors as it can’t map NULL)?