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.
…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):
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
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.
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.
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…
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?
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.
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.
(?) 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?
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.
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.
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.
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)?