How to tell when OH has finished startup

Setup, Configuration and Use Runtime
1

Hi,
is there any possibility to know in Raspbian, that Openhab was fully started (start process is completelly done) ?
Thanks.

2

Monitor openhab log file there is not a direct indicator but maybe you could key off a binding starting.

Also, create a rule based on system started and write out a file or call a script. Or just write to the openHAB log file.

3

There is no safe method I know of.
But why do you ask ? Mind the XY problem.

2 Likes
4

Thanks for reactions.
My idea was to recognise/display status of some openhab internal variable, that ca be used to determine, that openhab start process was succesfully completed (without marginal errors).

5

You can create a trigger on “when system started” to set your variable, that would probably come closest.
But again why ? Still mind the xy problem.

1 Like
6

You can approximate.
You would need to clean up the openHab2 startup process and make sure that the .rules files get loaded as the very last step of setup.
Next you need a way to define the sequence of loading rules
Then create a rules file that will get loaded last and give it a rule “triggered by system start”
that sets a Flag or flips a switch or whatever you need at that moment.

There was a discussion how to cleanup the start process in 2018 and Cleaning up the startup process / renaming rules (windows possible) has a solution for that which has worked for me nicely ever since.
In a nutshell, all rules files get renamed to another extension before openHab starts (except one) and then you have one rule rule that is still active. When it is called openHab is still in the middle of everything so you start a timer here, 3 min worked good for me. When that timer fires the changed filenames get named back and openhab will load them one by one after that.
Now you can implement a naming scheme for your rules like
100_sensor.rules,
200_PIR.rules
,
999_last.rules

Bash will rename them in alphanumeric order and openHab2 will load them in the order bash renamed them. 999_last.rules will be the last file to load.

Let me know if you’d like more details

7

I migrated from OH2.4 to OH3.0.1 (both on Windows 10) and I’m having major System started issues. The initialization rule crash immediately. I can’t even logInfo or Thread::sleep(10000) as the first executable line!

I’ve read for OH3:

  • 40 - Rules loaded
  • 50 - Rule engine started
  • 70 - User interface started
  • 80 - Things initialized
  • 100 - Startup complete

Rules need to startup LAST!

I can visualize a way to hold off the initialize rule via use of another rule. Is there any means for me to know when the system is fully initialized? Any variable, property, etc. I can test?

My system is now dead in the water.

PS - This behavior is non-repeatable. Sometimes the rule gets through several lines of code before crashing.

8

Here’s what I had to my large system going from OH 2.4 to 3.2m4. I was having the same issues you where and they weren’t consistent. It was a real struggle to get a stable startup migration.

/usr/share/openhab/runtime/services.cfg I did play with this order quite a bit and I’m NOT sure if this is the original order or something I tweaked below. Just wanted to document it.

# Start level definitions
startlevel:20=dsl:items,managed:item,dsl:things,managed:thing,managed:itemchannellink,dsl:persist
startlevel:30=persistence:restore
startlevel:40=dsl:rules,managed:rule,rules:refresh,rules:dslprovider
startlevel:50=ruleengine:start
startlevel:70=dsl:sitemap
startlevel:80=things:handler

default.rules startup rule

		Thread::sleep(21 * 5000)
		
		logInfo("STARTUP","-----------------------------------------------------------------------------")
		logInfo("STARTUP","** Startup Is At The Beginning - Thread Slept 21 * 5000 (aka 105,000)** ")		
		logInfo("STARTUP","-----------------------------------------------------------------------------")

/services/runtime.cfg for thread increases

# Thread increases from OH2 used
threadpool:thingHandler=50
threadpool:discovery=20
threadpool:safeCall=50
threadpool:ruleEngine=50

webclient:minThreadsShared=10
webclient:maxThreadsShared=60
webclient:minThreadsCustom=10
webclient:maxThreadsCustom=30

Java Heap Size Increase

cd /etc then vi profile
Also do this one --> /etc/default/openhab

EXTRA_JAVA_OPTS=-Xmx1024m
export EXTRA_JAVA_OPTS

After all these tweaks, OH 3.x comes up and is stable consistently now.

Best, Jay