If someone can point me to a place in the docs or explain the order of execution of items such as, things, items, rules AND when does restoreOnStartup persistence kicks in. If not a doc perhaps a thread exists covering this already.
The last topic around the execution of restoreOnStartup persistence is quite crucial as many rules can fail if they have null values associated as they have not yet been restored.
I see that on a boot cycle it takes around 20 minutes and multiple executions of the ‘System started’ trigger before the OH server settles down. I am thinking a better understanding of the boot order and triggering events could lead to optimised code in rules to speed up this process and possible reduce the number of ‘System started’ triggers.
And finally, is there also a log entry for when the persistence restoreOnStartup has completed?
openHAB is designed for starting all processes in competition. There is no order in startup. There are some hacks to ensure that a rule will be executed after restoreOnStartup (with System started), but to be honest, one has to think about the rules and if System started is the correct trigger at all. System started will occur for every rules file when this rules file is loaded (or reloaded), so if you have more than one rules file, this is common behavior.
In question of startup length, which hardware do you use?
I noticed a certain extend of startup time in the last months for openHAB2, but I’m petted from openHAB1 which comes up in about 20 seconds, where openHAB2 needs about 2 Minutes for startup. (This is on a xen VM, 1GB RAM, 1 virtual Core @ 2GHz)
I’m not aware of a log entry regarding to restoreOnStartup, but this job should be done in a blink.
I run on a RPi3 so yes I know the platform will struggle when booting as it seems OH does not use all 4 cores making it even slower at times of congestion.
However that was not really where I was going with this thread.
I am still trying to work out the most optimum way to boot and ensure the least amounts of triggering of system start.
I use many .rules files rather than one super large one I had presumed that was better but perhaps not.
Lots of people have all sorts of complicated schemes to keep System started roles from running while oh restarts. I find them all unsatisfactory and overly complex.
Print everything in one file won’t really solve the problem because you still can’t guarantee that the one file will load after all the items have leases and restored.
To elaborate on Udo’s suggestion, you can write your System started Rules to set a timer and try again until such time that the items needed by that rule are no longer NULL.
If I’m understanding what you are saying here this in not the behavior I see. When i edit a .rules file, only the System started rules in that one file execute, not all System started rules across all .rules files.
so best to check some items required are not NULL in the startup rule and if they are go to sleep for a little longer.
Ok, I will give that a go.
The difficulty I have is some states are set by persistence while others are set by real time measurements, others are a mix of the two. without knowing when the persistence process has completed its difficult to know if a NULL value is a mistake in the rules or indeed reliant on measurements. Hence my request to see if there was a logged event of when persistence has completed a restore.
Well, you can set a “virtual” item and persist it with restoreOnStartup.
Then, manually set a value to it (e.g. ON).
In the startup rule, you can check if its state is !=NULL.
If it’s not NULL then you’ll know that persistence kicked in.
Just my 2 ¢…
which comes up in about 20 seconds, where openHAB2 needs about 2 Minutes for startup. (This is on a xen VM, 1GB RAM, 1 virtual Core @ 2GHz)
)