Cleaning up the startup process / renaming rules (windows possible)

Tags: #<Tag:0x00007faed171fc00> #<Tag:0x00007faed171fac0> #<Tag:0x00007faed171f980>

I got it now thanks

FYI: I have added @ptweety’s workaround to openHABian.


If I try this option on openHABian I get:

/bin/cp: cannot create regular file ‘/etc/systemd/system/openhab2.service.d/override.conf’: No such file or directory

For the record, I am not on the openhabian image. I just installed the script. I’m on strech.

If that directory does not exist, how did you install/start OH then ?
(well my real question is: does that dir exist in a normal OH installation ? Why does it not exist in yours ?)

I can start openhab with

sudo systemctl start openhab2.service

If I look in /etc/systemd/system there is indeed no openhab2.service subdirectory.

For what it is worth, there is a /etc/systemd/system/multi-user.targets.wants subdirectory. In that directory there is a link called openhab2.service. The link points to the file /urs/lib/systemd/system/openhab2.service

That’s great - OH now starts much faster, thanks!

Is there a way to test if Things (particular or a list of)are online

I think it is safe to enable rules only after all Things are online which interact in rules.

I have implemented in one of my rule files a “System started” rule, which does an initialization and other needed stuff and after all also precompiles the rules file.
What I have seen at startup is, that a “storm” of “System started” events are fired. The rules files are recompiled zillion times, e.g. when particular things/items get online. This for sure does not speed up the startup process.

My suggestion is to wait activating rules (copying, or whatever, e.g. disable rules engine in karaf) only after the Things and Items are online.

Any ideas?

THANK YOU!! I was having a ton of problems before. Just created a new OpenHABian off your latest release, brought in all my old item and rule files, and noticed you fixed this issue. It worked great. All the persistence null > value changes took place well before the rules loaded.

For the first time ever, I rebooted without one single error!

Works like a dream and everything starts up with no complaints

Thank you so much - super appreciated

Just for your information: According to Delay Rule loading after Startup in OH2? it should be possible to configure openhab itself to load the rules later by doing the following 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

This means no hacks like renaming the rules on startup should be necessary which is clearly the cleanest solution. From my limited testing it really seems to do the job.

could somebody explain to me what is going on here?
how does this work and what does it do?

could somebody explain to me what is going on here?
how does this work and what does it do?

From my guessing it is like this:

On startup different things are done. Bindings are started, rules are loaded. You can see everything with its startup level by doing


For me it outputs stuff like:

 ID │ State    │ Lvl │ Version                │ Name
129 │ Active   │  80 │ 0.10.0.oh240           │ Eclipse SmartHome Item Model
130 │ Active   │  80 │ 0.10.0.oh240           │ Eclipse SmartHome Item Model IDE
131 │ Active   │  80 │ 0.10.0.oh240           │ Eclipse SmartHome Item Model Runtime
160 │ Active   │  80 │ 2.14.0.v20180522-1629  │ Xbase Runtime Library
175 │ Active   │  80 │ 1.9.6                  │ MIME streaming extension
177 │ Active   │  80 │ 6.2.0                  │ org.objectweb.asm
178 │ Active   │  80 │ 6.2.0                  │ org.objectweb.asm.commons
179 │ Active   │  80 │ 6.2.0                  │ org.objectweb.asm.tree
180 │ Active   │  90 │ 2.4.0                  │ openHAB Core
181 │ Active   │  80 │ 2.4.0                  │ openHAB Karaf Integration
183 │ Resolved │  80 │ 2.4.0                  │ openHAB Sound Support, Hosts: 116
184 │ Active   │  80 │ 2.4.0                  │ openHAB Dashboard UI

There you can see most things have a level of 80, including bindings. Without the above change, rules also have a startup level of 80:

bundle:start-level org.eclipse.smarthome.model.rule
Level 80

What I assume is that everything with the same startup level is started at the same time. So when the startup level reaches 80, everything with startup level 80 is loaded at the same time. By increasing the level of rules, rules are loaded after everything in startup level 80 (like things or bindings) are loaded. Effectively delaying rule loading after everything else is loaded.

I even got a step further by loading things, items, etc. step by step by doing:

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.item 85
bundle:start-level org.eclipse.smarthome.model.item.ide 85
bundle:start-level org.eclipse.smarthome.model.item.runtime 85
bundle:start-level org.eclipse.smarthome.model.sitemap   88
bundle:start-level org.eclipse.smarthome.model.sitemap.ide    88
bundle:start-level org.eclipse.smarthome.model.sitemap.runtime     88
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

So first things are loaded (after everything else in level 80 like bindings), then items, then sitemaps and finally rules. I’d guess they depend on each other in this order (e.g. items need things and sitemaps need items etc.).

This is just my guessing - I didn’t take a look at the code or so. If somebody from the devs could confirm this I’d be grateful.

1 Like

To be confirmed by experience but it does not seem that bad.
I created a custom.script in /var/lib/openhab2/etc/scripts and adapted your proposal to last snapshot module names :

bundle:start-level org.openhab.core.model.thing 83
bundle:start-level org.openhab.core.model.thing.ide  83
bundle:start-level org.openhab.core.model.thing.runtime   83
bundle:start-level org.openhab.core.model.item 85
bundle:start-level org.openhab.core.model.item.ide 85
bundle:start-level org.openhab.core.model.item.runtime 85
bundle:start-level org.openhab.core.model.sitemap   88
bundle:start-level org.openhab.core.model.sitemap.ide    88
bundle:start-level org.openhab.core.model.sitemap.runtime     88
bundle:start-level org.openhab.core.model.rule 90
bundle:start-level org.openhab.core.model.rule.ide 90
bundle:start-level org.openhab.core.model.rule.runtime 90

@kai, @maggu2810, or @wborn, are start-levels something users should be meddling with? IIRC, this discussion has come up before and the advice was not to do it.

Should we bring ESH #1896 over to openhab-core (if it has, I couldn’t find it)?

No, start levels should not be touched by users.
And yes, the startup issue is still open, definitely worth to address.


I definitevely agree that touching start levels should not be in end user scope, but while this subject is not addressed at framework level, this can be a way to clean and clear startup process. I hate seeing warnings or errors when I browse my log files. Every time I wonder what’s the reason behind, is it a real failing or just a temporary error

I’ve implemented the workaround from this thread in openHABian so at least the major pain point (evaluate rules last) is adressed.
However I also prefer a complete start level based solution and we shouldn’t care if that’s user or developer level if it works. But that’s the question - does it ? If so, can anyone create a PR ?

This is giving me

Error in initialization script: /var/lib/openhab2/etc/scripts/startup.script: Bundle org.openhab.core.model.item does not match any bundle

on every console start so I doubt it’s right.
(running 2.5M1 - have the bundle names changed since and you used the new ones ?)

Thank you Gael, it seems to work well for me.
PS: I created a start-level.script in userdata/etc/scripts

Yes, I’m on snapshot