I needed a solution for errors and warnings appearing in the log during openHAB start-up due to bad timing of openHAB’s start-up procedure. I came up with this:
Edit the Karaf service configuration: sudo nano /lib/systemd/system/openhab.service
Add this line: ExecStartPre=/bin/mv /etc/openhab/rules/main.rules /etc/openhab/rules/main.rules_exclude
before this existing line: ExecStart=/usr/share/openhab/runtime/bin/karaf ${OPENHAB_STARTMODE}
Reload the daemon: sudo systemctl daemon-reload
You need one .rules file like
rule "include main.rules"
when
System started
then
val cmd = "/bin/mv"
val old = "/etc/openhab/rules/main.rules_exclude"
val new = "/etc/openhab/rules/main.rules"
executeCommandLine (Duration.ofSeconds(5), cmd, old, new)
end
You do not have to whitelist the command.
Now, you can restart your openHAB service with sudo systemctl restart openhab. Then, the main.rules file is first ‘excluded’ because it won’t be read initially. The rule above renames it back, so it will be read (and rules executed when they are triggered).
Updating the system may overwrite the openhab.service file (changed in 2. above), so you may need to repeat steps 1. to 3. after the update.
I was running openhabian 4.1.2 when writing this text.
AFAIK to run a script you need to whitelist the command in /openhab/conf/misc/exec.whitelist
Did you do this?
Try to add a line with “/bin/mv” to that exec.whitelist file.
This is an old old technique (I think it was first talked about way back in OH 1.6 IIRC). It can be effective but it can also cause problems. For example, the next time you update OH, your changes to the openhab.system file will become lost and you’ll have to make the change again. In some rare circumstances you can lost some files if power is lost or something else goes wrong during the move. These are just a couple I’ve seen with this approach.
There is a simpler and less disruptive approach though. You can use Delay Start [4.0.0.0;4.9.9.9] to do this in a less disruptive and selective way. You likely do not need to prevent all rules from running during startup, just those that are generating errors.
This rule template lets you select those rules you don’t want to run during startup. It will disable those rules until runlevel 100 plus a definable delay before reenabling them. Disabled rules do not trigger and you can disable managed or file based rules.
Only for the Exec binding. @stefano73 is using the executeCommandLine which does not require whitelisting.
Hi Rich,
Thank you for this. I wasn’t aware of that.
BTW: I knew about the solution I described before, but didn’t find it anymore, so I decided to write about it.
Stefan
I had that same problem with earlier versions of OH and used a variation of your solution with an ExecStartPost entry that simply slept for a configurable amount of time before moving the rules back into place. Worked great. That being said, with 4.0 I no longer need this:
workarounds = {
delayRules = {
enable = mkOption {
description = ''
Work around rules loading too early. You probably want this enabled on openHAB version <
4. The only downside is a slight delay after start before the rules will run. A similar
workaround exists for openHABian.
'';
type = types.bool;
default = ! lib.versionAtLeast config.toupstream.services.openhab.package.version "4.0";
};
delay = mkOption {
description = ''
Delay before we load the rules. The default is completely arbitrary
and depends on the speed of the computer on which you run openHAB as
well as the number of bindings and things/items. If you have a fast
machine, try lowering it and do the opposite in case of a slow device
like an rpi.
'';
type = types.ints.positive;
default = 60;
};
};
};
You do not have to whitelist the command.
Updating the system may overwrite the