Lazy 1st execution of rule

Any of the fouders idea about this problem
@rlkoshak, @Kai

It’s realy annoing, and I’m not allone.

I’m no founder and I don’t do development on OH or ESH. I’m just a user and support the project by helping out on the forum. But that means I’m pretty limited in what I can do to help with a problem like this. All I can do is commiserate and say it shouldn’t do that. Nothing more.

It is a known issue that is tracked here: https://github.com/eclipse/smarthome/issues/4852
So far, nobody seems to have taken the time to implement it…

This does not explain my situation. here the rules snapshot:

rule LivingFPRemoteL1L3
when
	Item LivingFPRemoteL1 changed from OFF to ON  or	
	Item KitchenRemoteL3 changed from OFF to ON  	
then
 	logInfo("rule LivingFPRemoteL1L3", "start")  
	try{
		if ( gTFDRLightSpot.state as Number  > 0 ) 
			{ sendCommand(gTFDRLightSpot, "0")}
		else
			{sendCommand(gTFDRLightSpot, "10")}
  	} catch(Exception e) {sendCommand(gTFDRLightSpot, "0")}
end

rule LivingFPRemoteS1S3
when
	Item LivingFPRemoteS1 changed from OFF to ON  or
	Item KitchenRemoteS3 changed from OFF to ON  	
then
 	logInfo("rule LivingFPRemoteS1S3", "start")  
	try{
		if ( gTFDRLightSpot.state as Number  > 0 ) 
			{ sendCommand(gTFDRLightSpot, "0")}
		else
			{sendCommand(gTFDRLightSpot, "100")}
  	} catch(Exception e) {sendCommand(gTFDRLightSpot, "0")}
end

There are two wall mount switches (homematic 6 PBs) which operate set of tradfri ceiling GU10 spots. operation short=full long=10% power.
When rebooting or even reloading particular rules file (maybe also any rulesfile?), I have to go physically (pushing PBs) over all options in these rules (L1, L3, S1, S3).

The behavior is 4 times the same:
1st push nothing, waiting (how long?, left it for a minute, nothing)
2nd push nothing
3rd push light goes on

looking at the log file I see entries for homematic going OFF-ON-OFF, but evidence executin the rules

This cannot be just the precompiling of rule(s)?
I have the same behavior on other rule triggering items, though all homematic.channels.

What is the best way to log whats going on?

seconded.
Very annoying for my doorbell. Postman sometimes has already left when I open the door :joy:

I think I had the same issue. I am not sure, but I think it was related to the homematic raspberrymatic beeing connected via Powerline. I changed it to a direct connection and I didn’t observe the behavior again.
So check for latency in your network. Also duty cycle is causing issue from time to time.

I am right now not at home and not able to test in detail but following could be a try:

/etc/default/openhab2:

EXTRA_JAVA_OPTS="-Xms650m -Xmx650m"

These setting should be fine raspebrry pi installation, other platforms may have different values:

these all setting might be of interest:

-Xnoclassgc   disable class garbage collection
-Xms          set initial Java heap size
-Xmx          set maximum Java heap size
-Xss          set java thread stack size

Would be great if someone coukld test this, together with defining a rule for system start event to precompile rules.

found what the reason is for my lazy execution:

  1. the heap setting helps a lot
  2. I had in my rules the when statement for items (push buttons) going OFF to ON, unfortunately the initial state of the pushbutton item after boot is NULL and goes to ON. So I I will eliminate the “FROM” statement from my WHEN caluse.
when
        Item KitchenRemoteL1 changed from OFF to ON
then

to

when
        Item KitchenRemoteL1 changed  to ON
then

Hi to all.
Has someone tested this option?

Greetings,
Markus

I tested following and it seems to be the solution:

Enter in each rules file a rule which does nothing except putting some log output, triggered by System started

rule "System started Rule"
when
        System started 
then
       	logInfo("System started Rule", "done")
 end

The whole rules file is precompiled.
The good thing is that when you save the rule is compiled, as for some reason the System started is triggered for this rules file !!??

An idea would be also to set a cron target in this rule as well, e.g. once an hour, i.O. to to keep the rule file loaded. Just as an idea I didn’t tested that.

3 Likes

That’s so simple, well found !
I’m guessing adding an extra rule isn’t neccessary if you have some existing rule triggered on System started.

Any rule inside a rules files triggered compiles the whole file, whatever reason for firing there is.

What I have experienced, that sometimes when there is memory shortage the compiled rules are off-loaded. This is the case when e.g. you run Visual Studio Code on the same node.

My suggestion is that rules which have to be “rea-time” e.g. pushing button to get lights on, have to have an empty rule triggered by a cron, in order to have them always ready to run.

2 Likes

That’s another good find and workaround. Not something I’ve noticed myself, hosting on old desktop boxes with plenty of memory.

To summarize, increase the heap size to be as large as possible and then make sure you have a rule triggering in a file often enough that it never gets garbage collected and needs to be recompiled.

Correct?

I also like the idea of using a dummy OH instance for the LSP. Well, I wouldn’t say that I like it, it shouldn’t cause so much trouble on the main OH in the first place, but it is a clever work around.

@lukics, would you be willing to write up a tutorial on how to address these performance issues? There is lots of good stuff here but it might be hard to find in the future.

Sure,
I am new in contributing in that way. Need help in guiding me how should it be formatted and where located.

Put it in the Tutorials and Solutions section. The format can take whatever works best for you. You can browse through some of the existing tutorials for inspiration if you need it.

I tend to make my tutorials pretty formal (see the Design Pattern postings). Others can be quite informal. One person wrote their tutorial as a story (A State Machine Primer with HABlladin, the openHAB Genie) which I love!

Do what works best for you.

Thanks!

Be careful with this one. I tried this as a solution to slow rules execution and it made OpenHab start leaking memory and crashing regularly. My guess is some of the bindings (or maybe even the core) are relying on garbage collection in order to not leak memory.

Looks like this does not work anymore in OH3.
After migrating to OH3, the initial delay also doubled.
This puts my WAF at risk :wink:

There should be a way to have rules precompiled after a reload.

Does it execute your rule at Startup and output the logInfo?
It would be bad if this workaround to precompile rules no longer worked in OH3.

Seeing as OH3 runs DSL rules under a completely different rule engine (that is also shared with other rule authoring systems), I can’t see any reason why execution delays, first-time or otherwise, would be related to any of this thread.
Nor any reason to think the old workarounds will be much use.

If you are experiencing performance issues with OH3, I would advise starting a new thread.