OH2 system behavior after upgrade, some items not resolved

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.)

Since your issues revolve around mail, I added that tag to this thread.

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).

Since saving the item file resolves things, you could try touch * in the item directory to update them all.
Just a thought for a workaround.

Perhaps a more experienced user like @rlkoshak has more ideas.

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. :upside_down_face:)

from what version to what version did you upgrade please
platform and o/s?

Sorry, I was trying to be efficient and that is why I included the link to the other thread, it has details, but:

From:
OH 2 on a raspberry Pi. (openHAB 2.5.0~S1566-1 (Build #1566))

To:
yesterday: openHAB 2.5.0~S1645-1 (Build #1645)

1 Like

I’ve seen this behavior before. I think I opened an issue, then closed it because the behavior went away. Let me see if I can find the issue.

Edit: Here’s the issue. I think the behavior I reported is a different symptom of the same problem.

1 Like

Issues on GitHub are the best way to track & get help with snapshots. That is the purpose of snapshot builds.

Could the sitemap issue relate to the indeterminate way data is loaded at startup of OH?

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.

I’m happy to add notes…but, not sure what to note other than the initial post of the thread and, maybe, the from/to upgrade versions?

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.

1 Like

Hmm…well.

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?

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.