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.
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
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
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.
seconded
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.
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.
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 
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:
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.
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.
That’s another good find and workaround. Not something I’ve noticed myself, hosting on old desktop boxes with plenty of memory.