Lazy 1st execution of rule

lukics · June 27, 2018, 10:30am

Running 2.3 but had the same issue with release 2.2.

I realized that when I e.g. press a HomeMatic PB and I had reloaded the rules (reboot, editing the rules regardless if the rule target this particular HM PB) 1-2 times the rule targeting this HM PB does not fire. In the log that HM PB event is coming through (OFF to ON, ON to OFF). It might be also that the rule takes too long for my patience, so I am retriggering it.
It regardless how long I wait after rebooting/refreshing the rules. And it applies for each and every when staement in the rule, e.g. 3 PB’s acting on the same light with all SHORT and LONG press when clauses.

This is nerving because I have to go arround all the PB’s at reactive them by pushing all sequences through multiple times before handing over system to my wife.

Any idea what that can be? How to solve this issue?

hr3 · June 27, 2018, 10:40am

What hardware do you use and how long do you wait?
How many items, lines of rules?

vzorglub · June 27, 2018, 10:41am

Can you publish a log and the rule please?

bartus · June 27, 2018, 10:47am

Ive witnessed the same behavior in my system (pretty sure it’s been around since at least 2.1), where the first execution will have a 5-10 second delay, then all the executed rules fire at once. This happens on first startup and any time the .rules file is reloaded. Rules are instant after that. Logs show the triggering event immediately, with a delay until the rule log entries show up.

Not a big deal for me since I know they are still working, but just confirming this isn’t an isolated issue.

lukics · June 27, 2018, 10:55am

I am using Pi3.
Regardless how I wait after refresh/restart of rules.
I have a log statement a first line after the when statement, so the size of the rule should not matter

lukics · June 27, 2018, 10:57am

Unfortunately I am not at home for next 3 days, cannot deliver this and would’t mess with system when I am not at home.
But the logs do not show anything in particular, except I had to increase log level for rule based execution, which I do not know

lukics · June 27, 2018, 11:00am

True sometimes the flacker on/of. Might be my nervosity with pressing the PB again.

True the log does not help very much at that log level.

illnesse · June 27, 2018, 11:27am

seconded

mark_leonard_tuil · June 27, 2018, 12:56pm

More people report this problem. See for example Solved: Rules: First time slow execution, after some use: fast?
It seems to be normal behaviour. My ‘solution’ is to have a rule that triggers many other rules and trigger that rule manually.

lukics · June 27, 2018, 12:59pm

This old stuff '16 prior to 2.1, which seems the time it start hapening.

It seems not to be the a solution to trigger the rule, but trigger all the “when paths/clauses”, because is seems that they are treated separately.

lukics · June 27, 2018, 4:30pm

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

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

rlkoshak · June 27, 2018, 6:19pm

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.

Kai · June 27, 2018, 9:02pm

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…

lukics · June 28, 2018, 5:59am

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?

sihui · June 28, 2018, 6:27am

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

Koelle · July 5, 2018, 1:50am

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.

lukics · July 5, 2018, 8:05am

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.

lukics · July 5, 2018, 1:49pm

found what the reason is for my lazy execution:

the heap setting helps a lot
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

Master79 · September 16, 2018, 7:56am

Hi to all.
Has someone tested this option?

lukics:

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.

Greetings,
Markus

lukics · October 2, 2018, 1:49pm

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.