I don’t think renaming at shutdown would help. The underlying issues seem to be around threads and queuing at startup; the renaming trick makes system read the files again after the startup chaos has calmed done a bit?

Well, TimeoutStartSec is optional, but I found it useful to prevent the openhab2.service to go into failed-state due to long startup times. I’ve set this value to the duration of the sleep (90 seconds) plus another 90 seconds.

As a side it also meant I could use a new naming convention on my rule files so that I could control loading order as well. Just suffixed everything with a numeric like:

nnn-myrule.rules

Also added a little sleep (1 second for now) in between each ‘mv’ (or in my case ‘ln’) so OH has a little breather as it picks up each file. Still playing with whether it is worth it and how long to sleep but just felt it was better than dumping the whole ‘rules’ loading on it at once.

There of course is the big point how to process items files before processing the rules which is what all of this thread is about, but what’s the point in introducing a processing order inside the set of rules files?

but what’s the point in introducing a processing order inside the set of rules files?

I don’t think it’s absolutely essential but I do have certain rule files that I consider more low level than others. Maybe generic helpers like item synchronisation, MQTT messaging for group state changes (can’t get the binding to do that for me), alert and debug rules etc so I’d rather load those early on.

Also the likes of Astro rules trigger a lot events in other rules ‘on change’ so why not just ensure it is loaded early updated and then the other startup rules will initialise themselves from the latest value rather than initialise and then change seconds later.

If anyone is looking for a solution in combination with the official docker-image, you can use a ramdisk (option in docker) and create a custom entrypoint, that copies all files to that ramdisk before the rules above renames them.

yes, it is system dependent. Watch your log. You will see. At some time no bindings, things or services are being initialized, it’s just simple item-changes. (Be aware, all changes from NULL to anything are persistence initializing)

you need to put this rule in the moverules.rule file, then it will work. Otherwise not.