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

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"
        System started 
       	logInfo("System started Rule", "done")

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

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:

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:

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?

So far as I know that is still true.

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.

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

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.

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"
        Item SystemSpeedup received command ON 
       	logInfo("System speedup", "speedup")

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?

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 }

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.

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"
    Item LWT_iot_somedevice received update
   if (done_once !=0) return;
   <startup stuff>