I’m running OH2.5 snapshot releases on RPi3B+ (openhabian) for some while now.
What I noticed since a couple weeks (can’t remember when it started), is that right after upgrading, not all Items are read after starting. I always must perform a second restart for
all my items to appear.
This is easily visible when trying to view my sitemap in e.g. the OH app. I then get uninitialised items displayed and the openhab.log file gets filled with lines like:
2019-07-11 12:40:00.942 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Text
2019-07-11 12:40:00.950 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item ‘DBG_DebugMode’ for widget org.eclipse.smarthome.model.sitemap.Text
Here’s my upgrade procedure:
# 1. Display OH logging (background process):
openhab-cli showlogs &
# 2. Stop OH before upgrading
sudo systemctl stop openhab2
# 3. Perform updates and remove unneeded packages (happens occasionally)
sudo apt update
apt list --upgradable -a
sudo apt upgrade -y
sudo apt autoremove
# 4. Clean the OP cache folder and reset OH file ownerships:
sudo openhab-cli clean-cache
sudo openhab-cli reset-ownership
sudo systemctl start openhab2
# 5. And after a while...
sudo systemctl restart openhab2
I can’t find an explanation why OH doesn’t load all items files after steps 1→4.
I had logged an issue about this a while back. I closed it because I was unable to reproduce it in recent snapshots. I believe I opened it in openhab-core.
I still need to restart when changing openhab versions, e.g. 3.1M2 to 3.1 snapshot, or from snapshot to snapshot, or when downgrading from snapshot to M2.
docker-compose up -d # the first start up
# wait a few minutes
docker-compose restart # this shouldn't be needed
Yes. Upgrading destroys the system cache (rightly). Some configurations don’t manage a clean load without a functional cache. By the second load, the cache has been repopulated.
Sounds like a bug. OH should delay loading configurations until the cache is repopulated.
This is fairly long-running business,it’s not as easy as you might think.
11:46AM - 22 Jul 16 UTC
in our project we have a lot of event subscribers and registry change listeners implemented which are called during startup...
11:04AM - 10 May 20 UTC
12:14PM - 28 Nov 20 UTC
I've tried turning this into a PR but failed cross repos. Not my day today I guess.
Script needs to be placed...
I just looked at the first Issue. That was before OSGi had start level ordering.
Issue 2 looked to be about OS start levels rather that OSGi ones.
EDIT: What OSGi Level does OH 3 support? I think v8 is current and start levels have been there since v7.