OH5 - All things suddenly in NOT YET READY state, no more sitemap

Setup, Configuration and Use Migration
1

Dear all,

Since yesterday, suddenly Openhab 5 on my Raspberry Pi 5 seems to no longer be scanning the files containing things, items, rules, etc.

Yesterday I only did a reboot after commenting out a rule.

Today I updated to 5.0.1 and to the JDK:

openjdk 21.0.8 2025-07-15 LTS
OpenJDK Runtime Environment Temurin-21.0.8+9 (build 21.0.8+9-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.8+9 (build 21.0.8+9-LTS, mixed mode, sharing)

I also applied the permissions fix and updated the operating system.

I don’t know if it might help, but another strange behavior is that if I add a thing from the admin interface (for example my MyHomeServer BTicino with the Openwebnet binding) it goes into ONLINE state (good). However, as soon as I restart the openhab service, this same device goes into a “NOT YET READY” state. The curious thing is that if I do a “duplicate thing” from the admin interface, I then get one thing in “NOT YET READY” (the old one) and one thing “ONLINE” (the new one).

As soon as I reboot again, both are in “NOT YET READY”.
I have about 100 things, all in the “NOT YET READY” state, and in the openhab logs (/var/log/openhab.log) I no longer see the messages where the system used to say it had loaded the *.things, *.items, *.rules files.

In BasicUI I get a message saying that there is no sitemap to load, but in reality everything is fine, just like it was until two days ago.

Do you have any ideas? After a few hours of attempts, I’ve run out of them.

Thank you very much,
Ivan

P.S.

This is my log file; it never grows after starting the system.
At the karaf console level I have the whole system with the log verbosity set to INFO.

2025-08-20 16:47:10.741 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 5.0.1 (Release Build)
2025-08-20 16:47:11.252 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘Europe/Rome’.
2025-08-20 16:47:11.259 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to ‘46.16616130300258,13.27068749240425’.
2025-08-20 16:47:11.260 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘it_IT’.
2025-08-20 16:47:11.262 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to ‘SI’.
2025-08-20 16:47:18.966 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2025-08-20 16:47:24.075 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found BTicino device: not an OpenWebNet gateway or not supported (UDN=pnp-smartdes-2_6-00:03:50:A8:DB:F1)
2025-08-20 16:47:26.798 [INFO ] [.influxdb.InfluxDBPersistenceService] - InfluxDB persistence service started.
2025-08-20 16:47:26.898 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel
2025-08-20 16:47:26.902 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = fd…fe, base URL = ``http://localhost:8080``)

2

One more thing.

In Karaf I see that these bundles stays in waiting status, don’t know if it’s ok:

openhab> bundle:list |grep Waiting
162 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Automation
166 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Automation Script RuleSupport
173 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Configuration Dispatcher
197 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Model Core
217 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Model YAML
222 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Transformation Service

1 Like
3

For me this all looks like a bad sd card.

No. Did you try to manually start those? ( bundle:start <id> )

1 Like
4

Thanks for you suggestion.

I will try to do a fsck (but it should be always running on boot), I’m on a Raspberry PI5 + NVMe SSD disk on a NVMe HAT. I’m not using SSD as main storage. But I will try to check the disk, thanks.

As regards bundles not starting I tried to start each single bundle the common behaviour in logs is something like

2025-08-21 10:57:23.423 [DEBUG] [.core.internal.folder.FolderObserver] - bundle org.openhab.core.model.core:5.0.1 (197)[org.openhab.core.model.core.internal.folder.FolderObserver(219)] : Querying state unsatisfiedReference

That unsatisfiedReference is not tagged as ERROR but it is not a good message, imho.

For example:

**162 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Automation
**
2025-08-21 10:52:32.394 [DEBUG] [der.AutomationResourceBundlesTracker] - bundle org.openhab.core.automation:5.0.1 (162)[org.openhab.core.automation.internal.provider.AutomationResourceBundlesTracker(82)] : Querying state active
2025-08-21 10:52:32.396 [DEBUG] [.core.automation.ManagedRuleProvider] - bundle org.openhab.core.automation:5.0.1 (162)[org.openhab.core.automation.ManagedRuleProvider(68)] : Querying state active
2025-08-21 10:52:32.397 [DEBUG] [e.automation.internal.RuleEngineImpl] - bundle org.openhab.core.automation:5.0.1 (162)[org.openhab.core.automation.internal.RuleEngineImpl(70)] : Querying state active
2025-08-21 10:52:32.398 [DEBUG] [r.file.ModuleTypeFileProviderWatcher] - bundle org.openhab.core.automation:5.0.1 (162)
....
....
[org.openhab.core.config.dispatch.internal.ConfigDispatcherFileWatcher(144)] : Querying state unsatisfiedReference
2025-08-21 10:53:37.094 [DEBUG] [core.model.core.internal.SafeEMFImpl] - bundle org.openhab.core.model.core:5.0.1 (197)[org.openhab.core.model.core.internal.SafeEMFImpl(218)] : Querying state active
2025-08-21 10:53:37.095 [DEBUG] [el.core.internal.ModelRepositoryImpl] - bundle org.openhab.core.model.core:5.0.1 (197)[org.openhab.core.model.core.internal.ModelRepositoryImpl(217)] : Querying state active
2025-08-21 10:53:37.096 [DEBUG] [.core.internal.folder.FolderObserver] - bundle org.openhab.core.model.core:5.0.1 (197)[org.openhab.core.model.core.internal.folder.FolderObserver(219)] : Querying state unsatisfiedReference

222 │ Waiting │ 80 │ 5.0.1 │ openHAB Core :: Bundles :: Transformation Service

………..
………..
2025-08-21 10:57:23.418 [DEBUG] [internal.ConfigDispatcherFileWatcher] - bundle org.openhab.core.config.dispatch:5.0.1 (173)[org.openhab.core.config.dispatch.internal.ConfigDispatcherFileWatcher(144)] : Querying state unsatisfiedReference
2025-08-21 10:57:23.422 [DEBUG] [core.model.core.internal.SafeEMFImpl] - bundle org.openhab.core.model.core:5.0.1 (197)[org.openhab.core.model.core.internal.SafeEMFImpl(218)] : Querying state active
2025-08-21 10:57:23.423 [DEBUG] [el.core.internal.ModelRepositoryImpl] - bundle org.openhab.core.model.core:5.0.1 (197)[org.openhab.core.model.core.internal.ModelRepositoryImpl(217)] : Querying state active
2025-08-21 10:57:23.423 [DEBUG] [.core.internal.folder.FolderObserver] - bundle org.openhab.core.model.core:5.0.1 (197)[org.openhab.core.model.core.internal.folder.FolderObserver(219)] : Querying state unsatisfiedReference

1 Like
5

I just ran an update on my openhabian instance and I’m getting exactly the same behavior as you. I’ll keep poking around and trying things but this is definitely not a good thing. I did see an error in the log viewer that also seems concerning:

13:29:49.078[ERROR] [org.apache.felix.fileinstall] - Cannot create folder /openhab/userdata/tmp/bundles. Is the folder write-protected?
13:29:49.089[ERROR]

[org.apache.felix.configadmin] - [org.osgi.service.cm.ManagedServiceFactory, id=37, bundle=7/mvn:org.apache.felix/org.apache.felix.fileinstall/3.7.4]: Unexpected problem updating configuration org.apache.felix.fileinstall.a671b0eb-1b19-40f1-8658-a0d6d60c3470

This doesn’t seem good, but the folder is there and the permissions are correct….not sure what the issue is.

6

I wonder if something in the config is broken as it is looking for openhab off the root dir rather than in /var/lib and such - BasicUI Help and About shows the correct directories for userdata, logs, etc. It can’t be that simple, I’m sure I’m missing something…

7

OK, I just reinstalled the release version from the openhabian-config utility and it seems to be working now, except for an issue with a couple of my rules that trigger from the astro binding. I’ll chase that down elsewhere. Hope this helps…

8

Hi, so did you reinstall the release version of OpenHAB on itself via openhabian-config?
Or did you downgrade from 5.0.1 to 4.x?
Thanks a lot.

10

I actually changed the “version” of OpenHab in the config utility - I had been on milestone builds - and selected the release channel and it reinstalled 5.0.1 release. As best I can tell both the milestone channel and the release channel have the same version currently but sees the channel change as the need to reinstall. If you’re on release, try switching to Milestone and see if it forces a reinstall. You could even try changing the channel, not actually running the install, and then switching back and see if it reinstalls. It might save doing the reinstall twice if you don’t want to be on Milestone. Sorry for the convoluted response, but I’m not sure exactly how the utility determines the need to install OpenHab.

Hope this helps!

11

Tried the reinstall also via apt-get, no effect.

Now I’m here on Karaf

:> scr:info org.openhab.core.transform.FileTransformationProvider > Component Description: org.openhab.core.transform.FileTransformationProvider ============================================================================ Class: org.openhab.core.transform.FileTransformationProvider Bundle: 222 (org.openhab.core.transform:5.0.1) Enabled: true Immediate: true Services: [org.openhab.core.transform.TransformationProvider] Scope: singleton Config PID(s): [org.openhab.core.transform.FileTransformationProvider], Policy: optional Base Props: (2 entries) $000.target<String> = (watchservice.name=configWatcher) osgi.ds.satisfying.condition.target<String> = (osgi.condition.id=true) Component Configuration Id: 922 ------------------------------- State: UNSATISFIED REFERENCE Config Props: (4 entries) $000.target<String> = (watchservice.name=configWatcher) component.id<Long> = 922 component.name<String> = org.openhab.core.transform.FileTransformationProvider osgi.ds.satisfying.condition.target<String> = (osgi.condition.id=true) References: (total 2) - $000: org.openhab.core.service.WatchService UNSATISFIED 1..1 static target=(watchservice.name=configWatcher) scope=bundle collectionType=service - osgi.ds.satisfying.condition: org.osgi.service.condition.Condition SATISFIED 1..1 dynamic target=(osgi.condition.id=true) scope=bundle (no active bindings) openhab>

it matches with the fact that I’m no more able to see Openhab reading my config files… Permissions, directories, etc are all ok

12

seems that files are now searched in different directories (for example sitemaps on /etc/openhab/siteap - singular).

So strange.
Is it possibile to do a restore to factory settings?

openhab> config:list “(service.pid=org.openhab.folder)”

Pid:            org.openhab.folderBundleLocation: 
?Properties:automation = automationfelix.fileinstall.filename = file:/var/lib/openhab/etc/org.openhab.folder.cfg
html = html
icons = icons
items = items
persistence = persist
rules = rules
scripts = script
service.pid = org.openhab.folder
services = services
sitemaps = sitemap
things = things
transform = transform
13

Dears,
I uninstalled OH5.01, deleted various openhab directories on openhabian.

Started it and copied my old /etc/openhab and despite that, my system still doesn’t work.

Any other ideas?
Many thanks

14

Not sure if you solved this. I had made a change to conf/services/runtime.cfg which had a similar result - changing it back fixed it for me