Yes in the console, type:
bundle:stop org.openhab.core.model.item
followed by
bundle:start org.openhab.core.model.item
Unfortunately I do not have any advice. I see something almost exactly the same only a reboot resolves the issue.
I update OH every couple of days and I’ve noticed for a couple of weeks now that the first time OH boots after an upgrade I see a lot of errors about Items that should exist not existing. But when I let OH finish starting I’ll restart it and when it comes up the second time everything is fine. So what I’m seeing isn’t quite the same as what you describe. I’ve not had time to really look into the problem yet so I’ve not posted about it or looked for an open issue yet. I’ll go and add my experiences to Mark’s Issue as one more data point.
We all might be looking at a different issue since they are all slightly different.
NOTE: It looks like Scott has already reported the same behavior I’m seeing on that Issue.
I did a bundle:stop/start.
I did not fix the issue…in fact, items that were there before the stop/start were missing after, and a re-save of the defining .items file fixed it.
I also caught this fly by in the log when I saved the .items:
[ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'sys init': cannot invoke method public abstract org.eclipse.smarthome.core.types.State org.eclipse.smarthome.core.persistence.HistoricItem.getState() on null
The behavior I was seeing was that some or all of the items files were not read. It occurred on all startups (not just after an upgrade). The fact that it was some or all suggested to me it was a subtle timing issue. Then all of a sudden, the behavior went away. I figured I changed something in my system that very slightly altered the startup timing.
I suspect @kai’s theory about changes involving “constructor injection, “immediate=true” removals, etc.” was on the right track, as that might slightly alter startup timing…
Just curious, is this likely to be the cause of my sendMail issue? (Basically, trying to figure out if I should chase that and how much…)
Rule 'TOD Test': The name 'sendMail' cannot be resolved to an item or type;
I suppose it’s possibly related, but without knowing root cause it’s hard to know for sure.
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
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.