Expected Behavior
Upgrading from openHAB 5.1.4 to 5.2.0 via Docker, with an existing, 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)
- 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.
- Pull and start
openhab/openhab:5.2.0 with the exact same config volume mounted, without changing any file.
- Observe that items/things become unlinked, and both sitemaps are completely absent from the UI (not just broken — not shown at all).
- 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
Expected Behavior
Upgrading from openHAB 5.1.4 to 5.2.0 via Docker, with an existing, unchanged configuration (
.items,.things,.sitemap,.rulesfiles), should preserve all items, things, and sitemaps.Current Behavior
After pulling and starting
openhab/openhab:5.2.0with the exact same config volume that was working fine on5.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 toopenhab/openhab:5.1.4with 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):
Notably, the DSL model loader logged both sitemaps as loading without any errors:
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/.thingsmodel 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:Steps to Reproduce (for Bugs)
.items,.things,.sitemap, and.rulesfiles (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.openhab/openhab:5.2.0with the exact same config volume mounted, without changing any file.openhab/openhab:5.1.4with 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
openhab/openhabimage)