Bindings Not Installing on Upgrade

dathbe · August 8, 2026, 9:34pm

For the second time now during an upgrade (from 5.2 milestone 2 to 5.2.0, and then from 5.2.0 to 5.2.1), my bindings have not reloaded after the upgrade, forcing me to remove all bindings from my addons.cfg file, and then re-add them in order to get my bindings (and thus things) to load. I’m running OH in a docker container using the official image (currently openhab/openhab:5.2.1-debian).

When I asked Gemini about this, it suggests that the issue is that it gets stuck between needing to load new bindings with the new upgrade, but not knowing that it needs to load bindings again because the text config file hasn’t changed. I suppose this is due to the fact that I’m a legacy OH 1.0 user who refuses to use the GUI for anything I don’t have to. Gemini suggested a couple paths forward, the most promising of which is to clear the cache/addons.config file on an upgrade. Is this something that can be implemented as part of the packaged upgrade script for us curmudgeons who insist on sticking with text configs?

(From AI:)

Option 1: Delete addons.config during container updates (Recommended)

Before starting the new container version, delete the internal runtime tracking file on your host machine:

Bash

sudo rm -f /path/to/openhab/userdata/config/org/openhab/addons.config

When openHAB starts up, it notices that addons.config is completely missing, parses conf/services/addons.cfg as a brand-new configuration, and automatically pulls down the updated bindings for the new openHAB version.

Option 2: Switch to UI-based Add-on Management (JSONDB)

openHAB’s modern configuration engine handles version migrations much better when add-ons are managed through the Main UI rather than addons.cfg.

Remove all binding/add-on definitions from conf/services/addons.cfg (leave the lines commented out or blank).
Install your bindings via Settings $\rightarrow$ Add-ons in the Main UI.

Add-ons installed via the UI are stored in userdata/jsondb/org.openhab.core.addon.json. During container upgrades, openHAB’s internal migration scripts automatically update the bundle version references inside JSONDB files, preventing the Karaf load failure entirely.

Option 3: Automate the Cache/Config Clear on Image Update

If you use a deployment script or Docker Compose to update openHAB, add a step to clear the internal add-on configuration cache whenever you pull a new image version:

Bash

docker stop openhab
# Remove Karaf addon cache & temp directories
sudo rm -rf /path/to/openhab/userdata/cache/*
sudo rm -rf /path/to/openhab/userdata/tmp/*
sudo rm -f /path/to/openhab/userdata/config/org/openhab/addons.config
docker start openhab

apella12 · August 8, 2026, 10:30pm

There is already a script with Docker compose to clear the cache.

update.log (2.0 KB)

Most problems after an update are due to timing of the reinstallation of the bindings/bundles. After a few minutes (and a huge error log) docker restart openhab-openhab-1 or whatever your container is called.

jimtng · August 9, 2026, 12:58am

I have never looked into the main mechanism here, but it appears that (at least for docker), openhab would restart itself after an upgrade, i.e.

docker compose pull
docker compose up -d ← docker would restart openhab:
- openhab stops
- openhab starts
  - openhab restarts (not the docker container, but karaf(?) would restart by itself)

but yeah, sometimes I’d have to again manually restart it on top of the above

dathbe · August 9, 2026, 2:09am

I didn’t try to restart this time because I quickly realized it was the same issue as last time and just updated my addons.cfg. But I’m reasonably sure I restarted my container multiple times on the last upgrade and still got no results until I updated the config to force a reinstall of the bindings. I’ll test it on the next upgrade.

Lolodomo · August 9, 2026, 6:55am

github.com/openhab/openhab-core

Bindings not installed when upgrading to 5.2 (docker)

opened 08:37PM - 05 Jul 26 UTC

DanielStepp

bug

## Expected Behavior Upgrading from openHAB 5.1.4 to 5.2.0 via Docker, with an e…xisting, unchanged configuration (`.items`, `.things`, `.sitemap`, `.rules` files), should preserve all items, things, and sitemaps. ## Current Behavior After pulling and starting `openhab/openhab:5.2.0` with the exact same config volume that was working fine on `5.1.4`, my entire configuration effectively broke: items and things became unlinked, and my sitemaps (`wohnung_user.sitemap`, `wohnung_admin.sitemap`) were completely absent from the UI — not displayed with errors, not empty, but simply not shown at all, as if they didn't exist. Rolling back to `openhab/openhab:5.1.4` with the same, unmodified config immediately restored everything to working order. Relevant log output from the 5.2.0 startup (none of this appears when running the same config on 5.1.4): ``` 2026-07-05 22:06:35.625 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type 'channel' of item 'Motion_Detection' could not be parsed correctly. org.openhab.core.model.item.BindingConfigParseException: UID segment ' MotionDetectionState' contains invalid characters. The last segment of the channel UID must match the pattern '[\w-](?:#[\w-])?'. at org.openhab.core.model.thing.internal.GenericItemChannelLinkProvider.createItemChannelLink(GenericItemChannelLinkProvider.java:97) at org.openhab.core.model.thing.internal.GenericItemChannelLinkProvider.processBindingConfiguration(GenericItemChannelLinkProvider.java:87) at org.openhab.core.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:397) ... 2026-07-05 22:06:46.848 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'gps_racker.things' is either empty or cannot be parsed correctly! 2026-07-05 22:06:50.255 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'sunset.rules' is either empty or cannot be parsed correctly! 2026-07-05 22:06:55.208 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to compile rule 'e713fc9c2b' with status 'UNINITIALIZED' 2026-07-05 22:07:00.720 [ERROR] [.handler.AbstractScriptModuleHandler] - Script execution of rule with UID 'led-1' failed: Could not cast NULL to org.openhab.core.library.types.DecimalType; line 10, column 13, length 38 in led ``` Notably, the DSL model loader logged both sitemaps as loading without any errors: ``` 2026-07-05 22:06:35.391 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model 'wohnung_user.sitemap' 2026-07-05 22:06:35.562 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model 'wohnung_admin.sitemap' ``` yet neither sitemap appeared in the UI at all. This strongly suggests the sitemaps themselves parsed fine, but became entirely inaccessible because the items/things they depend on failed to link correctly. ## Possible Solution The `.items`/`.things` model parsing in 5.2.0 appears to have become stricter than in 5.1.4 (e.g. rejecting a channel UID with a stray leading whitespace that previously parsed fine), and this stricter validation seems to cascade into item/thing links breaking, which in turn causes dependent sitemaps to disappear entirely from the UI rather than degrade gracefully or show a partial/error state. Possible fixes: - Trim/sanitize whitespace in UID segments before validation instead of rejecting them outright, to match previous (5.1.4) lenient behavior. - If stricter validation is intentional, ensure a single bad item/thing config doesn't cause otherwise-valid sitemaps to vanish entirely from the UI, and surface a clearer top-level error identifying the exact file and line causing the parse failure. ## Steps to Reproduce (for Bugs) 1. Have a working openHAB 5.1.4 setup (Docker) with multiple `.items`, `.things`, `.sitemap`, and `.rules` files (Xiaomi Mi IO, IKEA TRÅDFRI, Osram Lightify, Spotify, Amazon Echo Control, Weather, Air Quality, GPS Tracker bindings in my case), including at least one channel binding configuration with a stray whitespace character in the UID. 2. Pull and start `openhab/openhab:5.2.0` with the exact same config volume mounted, without changing any file. 3. Observe that items/things become unlinked, and both sitemaps are completely absent from the UI (not just broken — not shown at all). 4. Roll back to `openhab/openhab:5.1.4` with the same config → everything works again immediately, confirming this is a regression introduced in 5.2.0. ## Context This broke my entire home automation setup (lighting, motion detection, air quality monitoring, LED presets, sitemaps for two users) after what was expected to be a routine Docker image update. I had to downgrade back to 5.1.4 to restore functionality. This is a significant regression for anyone running legacy DSL-based configs and upgrading via Docker. ## Your Environment * Version used: openHAB 5.2.0 (Release Build) — regression confirmed by downgrading to 5.1.4 with identical config * Environment name and version (e.g. Chrome 111, Java 17, Node.js 18.15, ...): Docker (`openhab/openhab` image) * Operating System and version (desktop or mobile, Windows 11, Raspbian Bullseye, ...): Raspberry Pi 5, headless, latest Raspberry Pi OS kernel, running via Docker

One possible problem is the number of network interfaces when using docker. The time to setup mDNS stuff the binding installer fails in timeout.
Another possible problem is that if one of your binding fails to install for any reason (missing dependency for example), none are finally installed.

dathbe · August 9, 2026, 10:45pm

Thanks for pointing out the Github issue. I’ve subscribed. It seems like the same issue I’m facing.

I don’t know enough about networking to know if that might be the issue. Can we extend the timeout slightly?

I don’t think it’s a single binding failing to install becuase when I change my addons.cfg and then change it back everything works fine. So I don’t think I’m missing any dependencies.