Delay Rule loading after Startup in OH2?

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.


If this works (does it?) then this should definitely be documented at - 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)?

This is likely not going to be resolved.
While it should be a marginal problem (because OH is made to run 24x7) and checking against NULL should be part of “proper” programming anyway, this is annoying when you hit it.

But there’s a workaround available here. It is also available as a menu option in openhabian-config

This causes all kinds of other issues though, for example this one:

An error occurred during the script execution: Cannot assign a value in null context.

Even a few hours after a restart that is still there. How should I check for null there? And whats even more important: What should I do if I hit a null context there? Simply don’t execute the rule? Thats whats happening now and not desired at all.

Stuff can get even more weird with the current loading:
The name 'ON' cannot be resolved to an item or type

What should I do with this one?

And another one that’s “great”:
An error occurred during the script execution: Could not invoke method: org.eclipse.xtext.xbase.lib.BooleanExtensions.operator_and(boolean,boolean) on instance: true

And even when you check for NULL (in case of an item), you are not safe:
The name 'NULL' cannot be resolved to an item or type

And that’s all part of a single startup that horribly went wrong. The last 2 issues are not something that can be fixed with any checks, delayed loading might help there but that shouldn’t happen in a nasty workaround that relies on openHAB to complete startup in X seconds, often after an update it takes longer and waiting 10 minutes for example to load the rules after a startup is not really great aswell.

Just because something is running 24x7 that doesnt mean restarting can or should be a pain requiring all kinds of manual work, it should recover itself from a crash perfectly fine. I think the behaviour that @doits mentioned should be default, persistence should be loaded after items though so restoring works properly.

Did you understand that variables/items are not initialized by default ? That you have to do yourself.
You can persist them with mapdb or use a System started trigger, but they will remain uninitialized until you initialize them. Just like in about any programming language.

It’s the programmer’s (your) job to decide.

You can blame OH and demand this to be changed (which will just annoy people willing to help but won’t change a thing) or you can put your energy into getting along with it. It is what it is.
Proper programming includes checks for NULL/Uninitialized, and the workaround is proven to work reliably. Take the advice or leave it.

Yes I do understand that. However, do you understand that some things have to be initialized by the environment itself (like NULL)?

Restart openHAB so I hopefully find myself in the lucky situation to have a proper context at some point aswell as having NULL properly defined. Cause that’s the only way to get it set properly. That would end in a restart loop though. Other suggestions to set up the context around that rule or set NULL correctly are more than welcome.

If you provide an example on how to get along with The name 'NULL' cannot be resolved to an item or type I’ll gladly take it, unfortunately to my knowledge there is no way to do it as it’s not even defined yet and I can’t just define NULL there (and I can’t check if its defined without throwing an error). A workaround to simply wait x seconds is not a way to get along here, as you are not checking if its defined after x seconds.

Which works great if NULL itself isn’t there (see above). And you know why I am even having this issue? Cause I am doing exactly what you consider proper programming: Checking for NULL. Without that check this error wouldn’t even exist…

I am not sure where I demanded something, I just gave my opinion on this topic and provided my experience with this so far and I just wanted to know if there is anything planned to work on this. In fact I wanted to work on this if nobody else is taking care of it yet, but apparently the wanted solution is a nasty workaround rather than a proper fix (proper programming includes making sure that dependencies get loaded in proper order by the way, just like checking for null, not just delaying for x seconds to hope that things have sorted out themselves, but that’s just my opinion I guess). Works for me, more time for me to do other stuff.

Nothing is proven, it works in a certain situation for a certain amount of people. I am missing a proof why this must be always true, and in fact I provided a case that it’s not always true, so saying that its proven to work is simply wrong as there is at least one case in which it won’t work (unless you can prove that my case can never happen, which you can’t since this happened to me before).

And to make things worse: Your workaround is not “proper programming”, you are not checking if the startup is completed… You just assume it is after x seconds. If you criticize others for their Programming (which is completely inappropriate in this case as NULL is not defined and I can not define it properly, what should I do there, if NULL == NULL? If NULL == null? Both is going to thrown an exception) you might want to fix your own things first, especially if they could be fixed…

The errors you’re reporting sound like what occurs after clearing the cache when using the snapshots. Once things settle down (couple minutes with my hardware), restart OH again and you shouldn’t see these errors. This is something I need to do in my production and test environments after upgrading a snapshot. There is currently not an issue submitted for this.

Unfortunately not, I haven’t updated this installation for a while (still on 2.5M1), I have to say though that I have a lot of items (about 1000), aswell as quite some rules, not sure if/how that is affecting it. I think adding either more items or rules caused this, it used to work until a few days ago where I added a few more items and a few rules to it. The problem is that I still have more to come, about 500 more items will follow so I guess it will get worse. I assume this has a similar effect as clearing cache (slow startup), so these issues might be indeed related (just that you only see it once while I see it every time). The cause is a slow startup then (which can happen in quite some cases I’m afraid).

Now if I do manual loading and throw in everything in the right order and wait until every dependency is fulfilled (which can even involve uninitialized items), everything works fine. No exceptions thrown (that’s because of proper checking for NULL :wink: ) as NULL is now actually existing aswell as other fundamental things are working when the rules get fired the first time.

I guess I’ll open an issue for this just so this is properly documented as “being a restriction at the moment”. As far as I understand, it would even be possible/“kinda easy” to do this properly. Now that openhab and esh are merged again I finally know where to open it and I don’t always choose the wrong one and when I started working on it I notice that its part of the other one… :wink:

Then this statement is not accurate…

… since 2.5M1 is nowhere near the close to the latest master. It’s actually a completely different species of animal at this point. :slightly_smiling_face:

I wouldn’t bother, unless you can reproduce the issue using a recent snapshot.

I ran a test with a snapshot build after I couldn’t get it to work in M1 to make sure I am not hitting something that’s already fixed. After that I did a downgrade again as that snapshot is not that great, so I am on M1 again now… I knew that there was a lot of refactoring and moving things around going on due to the ESH Merging, that’s why I did this test. I should have been more precise there, thought this was sufficient to outline the issue and environment.

Apparently this problem is well known and “accepted” already for quite some time, and it was even mentioned in here already, just that it used to be an ESH issue: (or if you prefer something a little less technical: which was closed as duplicate of 1896)

There seem to be other problems aswell that are caused by something very similar, so I am sure it will get fixed at some point, maybe the focus won’t be on this issue but that’s perfectly fine if this just gets fixed “along the way”.

thanks @HaKuNa
you could help me with that

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

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

this is rules file

rule "Alert: System started"
    System started
    executeCommandLine("/bin/sh@@-c@@mv /opt/openhab2/conf/rules/prestart/*.rules /opt/openhab2/conf/rules",10000)
    logInfo("Rules", "Startup: Rules restored")

my file

echo Launching the openHAB runtime...

if [ ! -z ${OPENHAB_RUNTIME} ]; then
    RUNTIME="`dirname "$0"`/runtime"

exec "${RUNTIME}/bin/karaf" "${@}"

I should add that and delete My file ?

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

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

tbh. read this thread carefully. also use google and then ask dedicated questions. this is not a helpdesk.

1 Like


it does not look like you have the necessary skills to implement the prestart stuff neither you are willing to improve your knowledge, therefore your solution is

And do not forget to study this thread before ask new questions:

1 Like

I suggest you move to openHABian. Delayed rules loading is already implemented in there as an option.

First of all you are not the one to judge me and knowledge and let me be the one who knows if I spend time on the forum to improve them. Secondly when you answer a question you should be willing to help. And finally if you want to know I find the solution to my problem. Thank you for your help though that google thing really helped me 🙏

@mstormi Thanks
isolved my problem

1 Like

Hands down this helped my startup OH 2.4 process to an extreme! I have over 11k lines of items and 30k lines of rules. The normal startup process took over an hour and it restarted the rules process numerous times over that period because of the timing of loading bindings, etc.

After putting this script below into /userdata/etc/scripts/startup.script

bundle:start-level org.eclipse.smarthome.model.thing 83
bundle:start-level org.eclipse.smarthome.model.thing.ide 83
bundle:start-level org.eclipse.smarthome.model.thing.runtime 83
bundle:start-level org.eclipse.smarthome.model.persistence 85
bundle:start-level org.eclipse.smarthome.model.item 90
bundle:start-level org.eclipse.smarthome.model.item.ide 90
bundle:start-level org.eclipse.smarthome.model.item.runtime 90
bundle:start-level org.eclipse.smarthome.model.sitemap 91
bundle:start-level org.eclipse.smarthome.model.sitemap.ide 91
bundle:start-level org.eclipse.smarthome.model.sitemap.runtime 91
bundle:start-level org.eclipse.smarthome.model.rule 98
bundle:start-level org.eclipse.smarthome.model.rule.ide 98
bundle:start-level org.eclipse.smarthome.model.rule.runtime 98

It took 22 minutes now!

Best, Jay