After upgrading I have some behaviors that I don’t understand.
After upgrade, some items are reported as unresolved (when a rule referencing the item is executed), until I save the item file that defines them.
Notes:
other items defined in the same file are resolved, no problem…
my rules, items, things are defined in files, not via ui’s
I have done a OH stop, clear cache, reboot
No errors referencing the items are noted in the log on saving the file or at boot
(I’ve included a link to the thread where the details of the upgrade seen for reference.)
But this particular rule and these unresolved items has no mail involved.
I believe that sendMail is a separate issue (I’m reading other mail binding threads at the moment to determine if I can grok the mail issue as something I’ve done wrong).
To be clear; it does not resolve the sendMail issue. And, it happens every time I reboot…(did you mean I should do a touch every time it reboots? Could be a problem if, for example, a power outage occurs. )
l’ll reopen the above issue, then @drmacro can add his notes and point to this thread.
My speculation at the time was that there’s a timing issue at startup that causes the items to not be loaded. But, I don’t know how things work well enough to try to track it down in the code.
Build numbers are always helpful. Also, whether the problem can be reproduced consistently, or is intermittent. And, whether the three “workarounds” listed in the top of my issue also resolve the problem for you.
Restart seem to produce this state every restart, so no.
Modifying the item file DOES clear the error
I don’t know how to : " stop/start org.openhab.core.model.item". Is this done from the console with feature:stop/start?
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 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…