"touch" is not working for reloading rules


I’m running the current stable OpenHabian (3.0.1 Release) on my Raspberry 4.

I trying to use the workaround 2 for the startup behavior problem when using persistence:
But the “touch” command is simply not working - or more exactly : it seems that OpenHAB does not recognize. For example:

...:~ $ ls -l  /etc/openhab/rules/dm920_tv.rules
-rwxrwxr-- 1 openhab openhab 975 Mar  8 18:56 /etc/openhab/rules/dm920_tv.rules

...:~ $ touch /etc/openhab/rules/dm920_tv.rules 
-rwxrwxr-- 1 openhab openhab 975 Mar  8 19:10 /etc/openhab/rules/dm920_tv.rules

As you can see the timstamp has changed but OpenHAB do not reload of the rules.file.

I also did a test with nano:
If I open the file in nano and save it with “^o”, so nano
reports “Wrote 35 lines”. But OpenHAB does not recognize although
the timestamp of the file is changed (so I assume its really written).

But if I do a change in the file (e.g. insert a “space”) and save it back
so OpenHAB recognize the change an reloads the .rules file:

2021-03-08 19:16:24.312 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'dm920_tv.rules'

It seems for me OpenHAB looks for a real change of the file
and so touch is not working.

Anyone who has a tip to get OpenHAB working to reload the files after “touch” ?

OH 3 won’t reload a file unless it’s changed I think.

But my understanding is that most of the startup behavior problems are solved in OH 3. What specific problem are you trying to solve?

I want to be sure, to start rules with the restored values as described here:

OpenHAB-docu of persistence

Or is this part of the docu perhaps still on v2.5 ?

First of all, are you trying to address a theoretical problem or have you actually experienced your Items being restored after your rules have started? Don’t try to fix things unless they are really broken. At best you are wasting your time protecting against something that isn’t even a problem. At worst you are actually causing harm.

If you have rules that you need to start when OH starts, the triggers in OH 3 have changed anyway. Now there are startup levels. If you use startup level 100 all your Items should have long since been restored by the time the startup rules run.

If you have Items changing from NULL by restoreOnStartup triggering your rules (which shouldn’t happen any more but if you are using an external database stuff can become delayed) it’s probably best to handle that case in your rules. It might be as easy as adding a Script Condition along the lines of

oldState != NULL

That will prevent the rule from running when the Item that triggered the rule changed from NULL.

In .rules files you’d add

    if(oldState == NULL) {

at the top of the rule.

Issuing a touch to all your .rules files can actually be quite disruptive and it can greatly increase the amount of time it takes for your OH to be ready to run.

Ok, I must confess that I wanted to protect myself from a theoretical problem. But since it was suggested exactly that way in the official documentation, I didn’t see anything wrong with it.

Regarding the startup levels:
That’s very interesting. Where are the startup levels determined? This is the first time I’ve heard about it.

Thank you very much so far

EDIT: If you know what to look for, it becomes quite simple :wink:

I think I will follow your advice and not spend my time solving problems that have not been detected.

Thank you

  • In the OH 3 release notes
  • in the UI

  • It has not been updated in the docs yet

Ah, I didn’t see it because I work with files.