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” ?
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) {
return;
}
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.
