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
in my openhab.cfg file.
rule "Alert: System started"
executeCommandLine("/bin/sh@@-c@@mv /opt/openhab2/conf/rules/prestart/*.rules /opt/openhab2/conf/rules",10000)
logInfo("Rules", "Startup: Rules restored")
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.
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.
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?
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)?