rossko57
November 16, 2021, 10:50pm
2
I’m pretty sure you have understood correctly
openhab:master ← kaikreuzer:sls
opened 11:47PM - 11 Dec 20 UTC
This finally implements https://github.com/eclipse-archived/smarthome/issues/189… 6, fixes a couple of issues that currently exist due to the unpredictable startup sequence and it should also improve the startup performance, since activities do not have to be done multiple times in order to deal with lazy loaded stuff.
This service combines different ReadyMarkers into a new start level ready marker and thus lets other services depend on those, without having to know about the single markers.
This brings an important decoupling, since the set of markers for a certain start level might depend on the individual set up-
The start level service is therefore configurable (see [here](https://github.com/openhab/openhab-distro/pull/1211/files#diff-6f5d3ba8289d20be508f0997f8b24e4b48962d8f5e56df3e793a566bec2469f1R16-R21), so that users have a chance to adapt the conditions upon a certain start level is reached.
Start levels are defined as values between 0 and 100. They carry the following semantics:
- 00 - OSGi framework has been started.
- 10 - OSGi application start level has been reached, i.e. bundles are activated.
- 20 - Model entities (items, things, links, persist config) have been loaded, both from db as well as files.
- 30 - Item states have been restored from persistence service, where applicable.
- 40 - Rules are loaded and parsed, both from db as well as dsl and script files.
- 50 - Rule engine has executed all "system started" rules and is active.
- 70 - User interface is up and running.
- 80 - All things have been initialized.
- 100 - Startup is fully complete.
Note: Levels 70 and 80 are not yet implemented in this PR, but should be added at a later stage.
While still being in a level <50, no events will be logged out anymore, which reduces the logs wrt "item added" and "link added" events tremendously.
I have also further improvements in mind like automatically registering what bundles are installed and for which markers needs to be waited, so that there is less necessity to adapt the configuration, if anybody does not use a "standard" setup of openHAB. Note that for anybody using the normal distro and not removing any essential parts of it, there should be no need to configure anything with the current implementation.
Fixes https://github.com/openhab/openhab-core/issues/1637
Fixes https://github.com/openhab/openhab-core/issues/1777
Fixes https://github.com/openhab/openhab-core/issues/1734
Fixes https://github.com/openhab/openhab-core/issues/1823
Fixes https://github.com/openhab/openhab-core/issues/1808
Might also fix https://github.com/openhab/openhab-core/issues/1365
Might also fix https://github.com/openhab/openhab-core/issues/1829
Signed-off-by: Kai Kreuzer <kai@openhab.org>
but - just because you have triggered a rule does not mean it’ll get to execute anything, waiting for resource at this busy time.
You don’t need the hacky file rename stuff; it’s not even going to work with UI entered rules anyway.
Which puts you back to a timer based solution.
