Delay Rule loading after Startup in OH2?

[mstormi (Markus Storm)]

This is likely not going to be resolved.
While it should be a marginal problem (because OH is made to run 24x7) and checking against NULL should be part of “proper” programming anyway, this is annoying when you hit it.

But there’s a workaround available here. It is also available as a menu option in openhabian-config

[Flole]

This causes all kinds of other issues though, for example this one:

An error occurred during the script execution: Cannot assign a value in null context.

Even a few hours after a restart that is still there. How should I check for null there? And whats even more important: What should I do if I hit a null context there? Simply don’t execute the rule? Thats whats happening now and not desired at all.

Stuff can get even more weird with the current loading:
The name 'ON' cannot be resolved to an item or type

What should I do with this one?

And another one that’s “great”:
An error occurred during the script execution: Could not invoke method: org.eclipse.xtext.xbase.lib.BooleanExtensions.operator_and(boolean,boolean) on instance: true

And even when you check for NULL (in case of an item), you are not safe:
The name 'NULL' cannot be resolved to an item or type

And that’s all part of a single startup that horribly went wrong. The last 2 issues are not something that can be fixed with any checks, delayed loading might help there but that shouldn’t happen in a nasty workaround that relies on openHAB to complete startup in X seconds, often after an update it takes longer and waiting 10 minutes for example to load the rules after a startup is not really great aswell.

Just because something is running 24x7 that doesnt mean restarting can or should be a pain requiring all kinds of manual work, it should recover itself from a crash perfectly fine. I think the behaviour that @doits mentioned should be default, persistence should be loaded after items though so restoring works properly.

[mstormi (Markus Storm)]

@Flole

Even a few hours after a restart that is still there

Did you understand that variables/items are not initialized by default ? That you have to do yourself.
You can persist them with mapdb or use a System started trigger, but they will remain uninitialized until you initialize them. Just like in about any programming language.

@Flole

What should I do if I hit a null context there?

It’s the programmer’s (your) job to decide.

@Flole

delayed loading might help there but that shouldn’t happen in a nasty workaround that relies on openHAB to complete startup in X seconds, often after an update it takes longer and waiting 10 minutes for example to load the rules after a startup is not really great aswell.

You can blame OH and demand this to be changed (which will just annoy people willing to help but won’t change a thing) or you can put your energy into getting along with it. It is what it is.
Proper programming includes checks for NULL/Uninitialized, and the workaround is proven to work reliably. Take the advice or leave it.

[Flole]

@mstormi

Did you understand that variables/items are not initialized by default ?

Yes I do understand that. However, do you understand that some things have to be initialized by the environment itself (like NULL)?

@mstormi

It’s the programmer’s (your) job to decide.

Restart openHAB so I hopefully find myself in the lucky situation to have a proper context at some point aswell as having NULL properly defined. Cause that’s the only way to get it set properly. That would end in a restart loop though. Other suggestions to set up the context around that rule or set NULL correctly are more than welcome.

@mstormi

You can blame OH and demand this to be changed (which will just annoy people willing to help but won’t change a thing) or you can put your energy into getting along with it.

If you provide an example on how to get along with The name 'NULL' cannot be resolved to an item or type I’ll gladly take it, unfortunately to my knowledge there is no way to do it as it’s not even defined yet and I can’t just define NULL there (and I can’t check if its defined without throwing an error). A workaround to simply wait x seconds is not a way to get along here, as you are not checking if its defined after x seconds.

@mstormi

Proper programming includes checks for NULL/Uninitialized

Which works great if NULL itself isn’t there (see above). And you know why I am even having this issue? Cause I am doing exactly what you consider proper programming: Checking for NULL. Without that check this error wouldn’t even exist…

I am not sure where I demanded something, I just gave my opinion on this topic and provided my experience with this so far and I just wanted to know if there is anything planned to work on this. In fact I wanted to work on this if nobody else is taking care of it yet, but apparently the wanted solution is a nasty workaround rather than a proper fix (proper programming includes making sure that dependencies get loaded in proper order by the way, just like checking for null, not just delaying for x seconds to hope that things have sorted out themselves, but that’s just my opinion I guess). Works for me, more time for me to do other stuff.

@mstormi

and the workaround is proven to work reliably

Nothing is proven, it works in a certain situation for a certain amount of people. I am missing a proof why this must be always true, and in fact I provided a case that it’s not always true, so saying that its proven to work is simply wrong as there is at least one case in which it won’t work (unless you can prove that my case can never happen, which you can’t since this happened to me before).

And to make things worse: Your workaround is not “proper programming”, you are not checking if the startup is completed… You just assume it is after x seconds. If you criticize others for their Programming (which is completely inappropriate in this case as NULL is not defined and I can not define it properly, what should I do there, if NULL == NULL? If NULL == null? Both is going to thrown an exception) you might want to fix your own things first, especially if they could be fixed…

[5iver (Scott Rushworth)]

@Flole

Unfortunately this is still an “issue” in latest master, the loading order doesn’t make sense at all.

The errors you’re reporting sound like what occurs after clearing the cache when using the snapshots. Once things settle down (couple minutes with my hardware), restart OH again and you shouldn’t see these errors. This is something I need to do in my production and test environments after upgrading a snapshot. There is currently not an issue submitted for this.

[Flole]

Unfortunately not, I haven’t updated this installation for a while (still on 2.5M1), I have to say though that I have a lot of items (about 1000), aswell as quite some rules, not sure if/how that is affecting it. I think adding either more items or rules caused this, it used to work until a few days ago where I added a few more items and a few rules to it. The problem is that I still have more to come, about 500 more items will follow so I guess it will get worse. I assume this has a similar effect as clearing cache (slow startup), so these issues might be indeed related (just that you only see it once while I see it every time). The cause is a slow startup then (which can happen in quite some cases I’m afraid).

Now if I do manual loading and throw in everything in the right order and wait until every dependency is fulfilled (which can even involve uninitialized items), everything works fine. No exceptions thrown (that’s because of proper checking for NULL ) as NULL is now actually existing aswell as other fundamental things are working when the rules get fired the first time.

I guess I’ll open an issue for this just so this is properly documented as “being a restriction at the moment”. As far as I understand, it would even be possible/“kinda easy” to do this properly. Now that openhab and esh are merged again I finally know where to open it and I don’t always choose the wrong one and when I started working on it I notice that its part of the other one…

[5iver (Scott Rushworth)]

@Flole

Unfortunately not, I haven’t updated this installation for a while (still on 2.5M1)

Then this statement is not accurate…

@Flole

Unfortunately this is still an “issue” in latest master,

… since 2.5M1 is nowhere near the close to the latest master. It’s actually a completely different species of animal at this point.

@Flole

I guess I’ll open an issue for this just so this is properly documented as “being a restriction at the moment”.

I wouldn’t bother, unless you can reproduce the issue using a recent snapshot.

[Flole]

I ran a test with a snapshot build after I couldn’t get it to work in M1 to make sure I am not hitting something that’s already fixed. After that I did a downgrade again as that snapshot is not that great, so I am on M1 again now… I knew that there was a lot of refactoring and moving things around going on due to the ESH Merging, that’s why I did this test. I should have been more precise there, thought this was sufficient to outline the issue and environment.

Apparently this problem is well known and “accepted” already for quite some time, and it was even mentioned in here already, just that it used to be an ESH issue: https://github.com/eclipse/smarthome/issues/1896 (or if you prefer something a little less technical: https://github.com/eclipse/smarthome/issues/3771 which was closed as duplicate of 1896)

There seem to be other problems aswell that are caused by something very similar, so I am sure it will get fixed at some point, maybe the focus won’t be on this issue but that’s perfectly fine if this just gets fixed “along the way”.

[jcosta46 (chris kallas)]

thanks @HaKuNa
you could help me with that

#!/bin/sh
mv `\ls -1 /opt/openhab2/conf/rules/*.rules | grep -v Startup.rules` /opt/openhab2/conf/rules/prestart
echo
echo Launching the openHAB runtime...

DIRNAME=`dirname "$0"`
exec "${DIRNAME}/runtime/bin/karaf" "${@}"

this is rules file

rule "Alert: System started"
when
    System started
then
    Thread::sleep(30000)
    executeCommandLine("/bin/sh@@-c@@mv /opt/openhab2/conf/rules/prestart/*.rules /opt/openhab2/conf/rules",10000)
    logInfo("Rules", "Startup: Rules restored")
end

winSCP
/usr/share/openhab2/start.sh
my file
#!/bin/sh

echo Launching the openHAB runtime...

if [ ! -z ${OPENHAB_RUNTIME} ]; then
    RUNTIME=${OPENHAB_RUNTIME}
else
    RUNTIME="`dirname "$0"`/runtime"
fi

exec "${RUNTIME}/bin/karaf" "${@}"

I should add that and delete My file ?

#!/bin/sh
mv `\ls -1 /opt/openhab2/conf/rules/*.rules | grep -v Startup.rules` /opt/openhab2/conf/rules/prestart
echo
echo Launching the openHAB runtime...

DIRNAME=`dirname "$0"`
exec "${DIRNAME}/runtime/bin/karaf" "${@}"

[HaKuNa (Remo M)]

tbh. read this thread carefully. also use google and then ask dedicated questions. this is not a helpdesk.

[jcosta46 (chris kallas)]

[HaKuNa (Remo M)]

@jcosta46
it does not look like you have the necessary skills to implement the prestart stuff neither you are willing to improve your knowledge, therefore your solution is

@HaKuNa

… or you just ignore the errors on startup and wait until all is settled down. if the errors only occur during startup they can be ignored.

And do not forget to study this thread before ask new questions:

How to ask a good question / Help Us Help You

Before you ask… Community forum is NOT a helpdesk Let’s put this in the front: nobody here works for openHAB. The community members are helping with an Open Source Project, not a commercial software. Additionally, the forum is NOT dealing with general Home Automation topics, the focus is on openHAB. In some cases, various products or technologies which are not directly linked to openHAB can be discussed but with the proper title, category or tag. We are ALL volunteering our free time to help…

[mstormi (Markus Storm)]

I suggest you move to openHABian. Delayed rules loading is already implemented in there as an option.

[jcosta46 (chris kallas)]

@HaKuNa

And do not forget to study this thread before ask new questions:

@HaKuNa
First of all you are not the one to judge me and knowledge and let me be the one who knows if I spend time on the forum to improve them. Secondly when you answer a question you should be willing to help. And finally if you want to know I find the solution to my problem. Thank you for your help though that google thing really helped me

[jcosta46 (chris kallas)]

@mstormi Thanks
isolved my problem

Openhab works slow, CPU of the RPI is high

There is some evidence that the use of explicit primitives in Rules slows down the parsing of your Rules. I can’t say for certain this is in fact a true thing, but it might be worth spending some time going through your Rules and avoiding the use of int, long, float, double, intValue, longValue, etc except where absolutely necessary (i.e. when passing the number to a method that requires the primitive. Letting the Rules DSL treat them as Numbers (BigDecimal to be specific) seems to be easier fo…

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

Hands down this helped my startup OH 2.4 process to an extreme! I have over 11k lines of items and 30k lines of rules. The normal startup process took over an hour and it restarted the rules process numerous times over that period because of the timing of loading bindings, etc.

After putting this script below into /userdata/etc/scripts/startup.script

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.persistence 85
bundle:start-level org.eclipse.smarthome.model.item 90
bundle:start-level org.eclipse.smarthome.model.item.ide 90
bundle:start-level org.eclipse.smarthome.model.item.runtime 90
bundle:start-level org.eclipse.smarthome.model.sitemap 91
bundle:start-level org.eclipse.smarthome.model.sitemap.ide 91
bundle:start-level org.eclipse.smarthome.model.sitemap.runtime 91
bundle:start-level org.eclipse.smarthome.model.rule 98
bundle:start-level org.eclipse.smarthome.model.rule.ide 98
bundle:start-level org.eclipse.smarthome.model.rule.runtime 98

It took 22 minutes now!

Best, Jay