System started trigger in OH3 - lazy execution of first rule execution

[mark_leonard_tuil (Mark)]

Hi all,

I am in the process of migrating to OH3 from OH 2.5. I ran into some connected problems. I am hoping that there are others that might help solve these problems, or at least this post might help others facing the same problem. The problems I ran into are:

• My solution to the delayed execution of a rule in OH2 doesn’t work in OH3
• If a .rules file is modified or renamed, the system started trigger part of the file is not processed. (The documentation states it should be.) Let me elaborate.

A Delay in first time a rule is run and old fix
In OH2 and OH3 there is a problem that the first time a rule runs this rule takes (a lot) more time than normal. A solution under OH2 was to include a system started trigger in each .rules file like this:

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

The effect of this rule is that the rule file was loaded at startup and you had no more delay. See for example:

Lazy 1st execution of rule

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…

B Clean up startup process
At the same time I used a trick to clean up the startup process. This trick is to rename the .rules files at shutdown and rename them a X number of seconds after system startup. The effect is a much cleaner startup process. This was also incorporated in the last version of openhabian I used, before I temporarily switched to docker to be able to switch between OH2 and OH3 to migrate my system. I don’t know if this is still in openhabian. See:

Cleaning up the startup process / renaming rules (windows possible)

I’ve run in some issues with the current startup process. Everything is starting at once which leads to several exceptions, errors and other problems. In my case the most annoying problem is the Homematic-Channel not found-problem. According to my opinion, a reason is the triggering of rules during startup which leads to timing problems and other race conditions which then lead to further problems after startup. I often read about moving or renaming the rules and copying back after startup, so…

C Changes in system startup trigger under OH3
Under OH2 saving or renaming a rules file would trigger the system startup trigger part of that .rules file. This is no longer the case, although the documentation still states that it does. The documentation states:

System started is triggered upon openHAB startup, after the rule file containing the System started trigger is modified, or after item(s) are modified in a .items file.

However it is no longer the case that system started is triggered if a rules files is modified. See:

Trigger system started not working

Hi, I’am having a simple rule in OH3 rule System_started when System started then logInfo("System started", "STARTED------------------") end but this is never executed. Not for the initial creation, not when i am touching an items file and not when i touch the rules file. In the log is just the message the rule file is loaded. Item and Group triggered rules are working file. Logging as well. Whats going wrong?

DSL rules with "System started" condition not executed

A + B + C is headache
The effect of the above is my current headache. As a result of the changes in system startup, the .rules files are not preloaded after they are renamed. As a result the fist time a rule is executed it is delayed. This causes a sluggish first time performance of OH3. Of course after a while most of the rules have been triggered, restoring the normal performance for the most part, but WAF is down.

Furthermore, some .rules files need the system started trigger to do stuff after they were reloaded in order for them to function properly. This doesn’t work anymore.

My questions / solutions
Does anyone see a way to solve these problems? Is there a way to speed up the first rule execution on OH3 and is there a way to run stuff when a .rules file is modified?

[rossko57]

@mark_leonard_tuil

the first time a rule runs this rule takes (a lot) more time than normal.

So far as I know that is still true.

@mark_leonard_tuil

A solution under OH2 was to include a system started trigger in each .rules file like this:

By OH2.4 at least, it got more complicated. The appearance was that infrequently used rules could get garbage collected. Say overnight, then first run next morning would require recompiling and cause delay.
The suggested workaround is a little rule in each xxx.rules file that runs periodically as a kind of “keep alive”.
You might want to see if that has any effect in OH3 with DSL files.

Idea: hack to avoid rule delay, keep time-critical rules in memory

Maybe the java experts can comment on this… Problem: Rules can take 10-20 seconds to trigger if they not have triggered very recently. My theory is that a JIT compiler runs over them before they are executed, and after some time of not using it, the result is purged from memory. Thus it has to be compiled again, which takes time on my Raspi (3+). My solution: I put this in the rule file that I want to prevent from being recompiled: rule "keep this thing in memory" //use the compiled code in t…

I think there are going to be varied experiences in this area, depending on host capabilities.

[mark_leonard_tuil (Mark)]

Hey, thanks. That explains some rules slowing down in my OH 2.5 system. I will add this to the OH2.5 rules. However, without system started trigger working when a .rules file is reloaded on OH3, I can’t use the trick to speed up the first time rules execution on OH3.

[mark_leonard_tuil (Mark)]

Did some more testing. Given the fact that the system started trigger no longer works in OH3 like it did in OH2, I added the following rule in a .rules file.

rule "System speedup rooms occupied"
when
        Item SystemSpeedup received command ON 
then
       	logInfo("System speedup", "speedup")
end

In addition I added the SystemSpeedup switch item and switched it on my executing SystemSpeedup.sendCommand(ON) on a timer a few minutes after the system is fully started. I get the log line as expected. However, if I trigger a rule in that .rules file for the first time, that rule is delayed. My conclusion is that the original way of speeding up openhab no longer works in OH3. That would mean that we are stuck with the delayed rule execution. For me, this is is a step back form OH2.

What are other people’s experiences? Do you also see the delayed start of a rule? Do you see solutions?

[kevin]

I’ve just tried OH3 and System started doesn’t work on startup and after editing files. I’ve asked on another thread if its likely to be fixed. One workaround may be using an item restored at startup to trigger a switch to do the same thing. For example using the old rule engine

 rule "dummy startup"
 when Item MyStartupItem changed to OFF then
 { Startup Stuff }
 end

Its similar to what I used to use to copy all my rules back into the rules folder once things were restored at startup, which by the looks of your research may not be needed anymore. I guess another way may be to explore the new rule engine to trigger the same item.

[bspiegel (Bob Spiegel)]

Thanks for posting this. I have been in debug mode for days on this. My solution is to rely on MQTT reload of last-will-testiment (LWT) to trigger my System startup script rather than System started. LWT is always loaded at start, no matter the status of the iot-device.

var done_once=0

rule "startup"
when
    Item LWT_iot_somedevice received update
then
   if (done_once !=0) return;
   done_once=1
   <startup stuff>
end