Force one rule to load first

I have a rule that loads at startup that sets everything into a known state and prevents any further processing until Openhab has had time to boot. Is there a way of forcing this rule to load before the rest?
What sets the order the individual rule files are loaded in?

No. You can’t control it in that way. You can control how your rules files load in relation to the other config files (items, persist, sitemap, etc) but not in relation to each other. From what I’ve observed I have not seen a pattern to the order that the rules files are loaded. Perhaps it is mostly alphabetical but I think it loads multiple rules files at the same time so it is hard to control.

Is there a reason why using persistence and restoreOnStartup won’t help with your problem? That will cause your Items to be restored to the state they were in when OH went down before your rules execute.

I’m using a Raspberry Pi and to limit SD Card writes I’ve limited my use of Persistence, preferring to set things to a known resting state at startup. I’ve also got to work around the GPIO sets everything to ON startup "feature."
To do this I’ve got a rule that on startup:
Sets my disable all Rules Switch
Creates a timer
Resets everything into the required state
Resets my disable all Rules Switch

By what you are suggesting I should essentially be delaying loading all rules and restoring everything from persistence?

You could also create a switch item, when your startup rule decide it is time for your other script startup, then command this item to ON, and make your other script check this switch item instead of the startup trigger.

with your “disable all Rules Switch”, this should be enough to stop any rules to trigger before your startup script. and you can make other rules do something at “startup” when everything is fine.

Well I didn’t know what your real problem was so I wasn’t suggesting anything, just asking questions. I find that a lot of people ask for how they think they should solve their problem without actually describing their problem and often the solution space is much larger than the asker thinks.

If you have a remote file share you can move your persistence files to that remote share to avoid the writes. You can also finely tune which Items get persisted to minimize the writes to only those Items that really really need it (perhaps only one switch, see below). And if you use mapdb you never have to worry about the size because it only saves the latest state. Personally, I’d rather deal with a corrupted SD card once every few years than give up my persistence, but there are ways to have both.

I don’t know how well it works, but if you had a System shuts down triggered rule to set the flag to OFF, persist the flag with a restoreOnStartup, then set the flag to ON at the end of your System started rule that should work. The only question is how reliably the System shuts down rule runs given all the ways that OH can go down, but it is worth a try. It should work in almost every case except where OH crashes hard, which I’ve never experienced myself.

Another even less satisfactory approach is to put all your rules into one file. Then they all get loaded at the same time and your System started rule will trigger before the rest.

Another solution would be to move the GPIO code out of openHAB to something else and interact with it via an API (MQTT, command line, etc).

My problem as far as I can work out happens on a reboot, and is with items triggering before the things they work with are initialised which then causes a stack dump and some things not to work going forward. The triggers for the rules I think are from Cron.

When 2system shuts down, persist the disable all value" together with delaying rules loading would very likely fix it, and I didn’t know that was possible.

Is there a command that can be used with mapdb?

Set up the mapdb persistence file per the Persistence wiki page and everything is done for you. Just be sure to use “restoreOnStartup” and “everyChange” strategy and only list your startup switch in the mapdb.persist file.

In your rule all you need to do is startingSwitch.sendCommand(OFF) where startingSwitch is the one that the other rules check to determine whether they are allowed to run.

Also, if the rules you are having problems with are not associated with your GPIO problems, you can add the important Items that are causing your problems to the persistence and their last value will be reloaded before your rules execute and you will avoid the Undef errors.

You have the flexibility to finely tune all of this to your needs.

Thanks Rich, I’ll give it all a test

I think I’ve got it pretty much as I want it now.
I’ve delayed the loading of rules by 10 seconds in Openhab.cfg by changing 10 to 20

folder:rules=20,rules

I’ve then took 10 second off my delay in startup.rules which resets the GPIO Items.
I’ve then in the rules that load first and have cron entries added:

var Timer StartupDelay
var Boolean EnableRules = false

rule "disable rules until Openhab is settled"
when System started then
{	StartupDelay = createTimer(now.plusSeconds(30))[|
	EnableRules = true	]}
end

I then added

(if EnableRules) then

to the beginning of any rules that use Cron

Finally I persisted all relevant items using MapDB