I would like to bring up a discussion about the future startup process of openHAB 3 as the first discussions are alread starting in the AC.
The current startup process is doing everything at once and causes problems on slow hardware like the raspberry pi3.
Not everyone has a powerful hardware to run openHAB or doesn‘t want to run a server for the home automation.
This has led to many workarounds to bypass problems but not a solution where the problem is really based.
Just a quick idea about a startup process:
Core components
Thing handler
Item handler (maybe directly combined with persistence to restore available values?)
Persistence services and restoreOnStartup procedures
Rule engine (should be the very last one )
I‘m aware that a startup process could slow down the overall startup time especially on very powerful hardware environments.
But i would assume that many openHAB installations are based on IoT hardware like raspberrys.
So i would like to ask two questions:
Why openHAB doesn‘t have a real startup process to make sure everything works fine on many different environments?
Could it be a goal for openHAB 3 to establish a real startup process?
Actually the problem goes away as soon as you remove all xtend based inputs like the current thing, item, sitemap and DSL rule files.
Because the internal storage system with all otherwise stored things, items, new rules, (new sitemaps at some point) is started and waited for way before other bundles start up.
But I had this very long heated discussion already in another thread.
The startup order problem all boils down to the underlying osgi framework karaf that loads all components. Because limitations the order is not defined, leading to all kind of problems and need for hacks. See:
The startup speeds is mainly slow due to the slow DSL rule parsing. Loading of items and things was relatively slow, but that has been improved in openHAB 2.4:
I forced the rule evaluation to be after getting everything else set up in a way that the startup script moves all rule files into a dedicated folder and ensures they are moved back 5min after start. Works like charm. Not sure what else one would need.
Hm. In hue emulation I’m using the org.eclipse.smarthome.core.service.ReadyService to delay the start of the hue emulation (which needs the item registry to be ready):
Why can’t we do that with the DSL-rules model bundle? (Considering that the model bundle is the less preferred solution nowadays anyway, so a “hackish” but working solution would be fine, I guess).
If some people are against such a delay, then it would be very simple to make the delay be enabled or disabled by the user with the default behaviour as enabled. Since enabled works in all cases and for those that do not wish to use the delay feature they can simply turn it off. A great idea as it is really annoys me when I look at my logs and see this happening.
True. I’m using openHAB without the models as well. But the hue emulation should really only be started after the json storage and the models have been loaded for the “default” openHAB distro. (Personally I still hope that the models get optional for the next release.)
)