Check out this fix. Also implemented as an option in openHABian (“delay rules load”).
Granted it may not be a fix for you, it makes OH load rules after items (more specifically after a fixed amount of time that we hope to be sufficient to load items) but it will not make OH load items before sitemaps ot things. But it may or may not help with your issue. Usually it’s the rules to cause the bad processing order.
I’ve read that thread a couple times now and, while I think I understand what it’s doing, I’m a bit confused on what to actually do. 
I think this is the procedure I glean from the thread:
- openhab need not be stopped
- Then:
sudo systemctl edit openhab2.service - That will create a new file
/etc/systemd/system/openhab2.service.d/override.conf - (not sure if anything is in that file at this point…), I add this to override.conf:
[Service]
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.rules" -exec /usr/bin/rename.ul .rules .x {} \\;'
ExecStartPost=-/bin/sleep 90
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.x" -exec /usr/bin/rename.ul .x .rules {} \\;'
TimeoutStartSec=180
(The above lines apparently do some bash to temporarily hide (by renaming) the .rules files, then un-hides them.)
5. Then: sudo systemctl daemon-reload
6. Then reboot my OH/Pi to see if there is a different behavior.
Am I even close? 
It takes any files in that path ending in .rules and renames them to end in .x so OH does not recognize them as rule files.
After 90 seconds, it takes the files ending in .x and renames them to end in .rules so they are recognized & loaded by OH.
Umm, thanks… I didn’t say that specifically, but, that’s what I meant by hide. 
But, when I asked if I’m even close, I wasn’t referring to the bash (I’ve been writing shell script for several decades…yeah I’m old. 
), I was referring to the steps I outlined as what I gleaned from the other thread to a try the delay.
1 Like
Welcome, fellow greybeard. 
Yep, that’s me…but, even though he wrote that 11 years ago, makes him 51, he’s a young whippersnapper to me.
1 Like
So, just a thought… I’m not sure how delaying the loading of the rules will help in this situation. If the items are not in the Item Registry, it doesn’t matter how long you delay loading the rules. Or, am I missing something (which is altogether possible because I’m old, too. LOL)?
You delay loading the rules so OH proceeds to load the Items in the registry so when you put the rules back in place, they do not fail.
So after reading a couple more times and checking out each step (of the ones I outlined) as I did them (i.e. checking the .d directory, etc. after the systemctl command…) I rebooted.
I rebooted. It appears to have stopped several errors. (Though one I’ve never seen before did show:
[ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Test Daylight event start': index=3, size=3
This refers to a rule I use to set up some event and state info for other rules. Is it possible something else has not started yet and this is complaining about that…since it gives no line number, col?
It also seems to have fixed my sendMail error as well…
Edit: seems there are still some missing items and the Expire binding seems to be broken…
Edit: and the persistence to the influx db seems to be broken as well…it was working before the last reboot.
Yeah, but the thing is, it’s not loading the items at all (i.e. loading the items into the Item Registry happens independently of the rules). At least that’s the way I understood it. I thought the OP said he had to touch/edit the .items file in order to get the items to load. I don’t see how delaying the loading of the rules gets around that. Then again, I might be misunderstanding something.
Just to confirm, yes, I had to save the .items files that contained the items that were reported unresolved in the log.
There are two possible errors that could be happening here. If it’s the error that you and I are seeing, no amount of waiting will matter because the Items simply do not exist. End of story. I can say, in my experience, my Rules loading is already delayed two minutes after the .items files are loaded and they still sometimes can’t see all the Items until I restart OH.
But OP is having the problem for all boots of OH. A reboot doesn’t help so they may have a different problem. If the error is the related to the more common and well known problem that Rules start to trigger before the Items are fully loaded, than delaying the loading of the Rules will help.
1 Like
Just some follow up observations…
After adding the rename-delay-rename hack the system was pretty much working.
But, a timer that used the Expire binding was not working as of last evening. (Meaning, when a rule used the timer Item changed to off would never trigger.)
There must have been some error happening, because the statement that started the expire timer was followed by the postUpdate of the item that persisted to Influx never updated.
This morning that seems to have rectified itself and the rules do trigger and the Influx items are changing.
Not sure I’m explaining that well, or even if I understand what I’m seeing.