"Demo app" stuck at startlevel 10

Nadahar · December 17, 2025, 6:12pm

// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
	// if no strategy is specified for an item entry below, the default list will be used
	default = everyChange, restoreOnStartup
}

/* 
 * Each line in this section defines for which item(s) which strategy(ies) should be applied.
 * You can list single items, use "*" for all items or "groupitem*" for all members of a group
 * item (excl. the group item itself).
 */
Items {
	// log demo number on every change
	DemoNumber;
}

I can try to remove it and see… but if that’s the cause, it would surely be helpful if there was some hint of the problem somewhere.

edit: That file isn’t actually “mine”, but is a part of the distro repo:

github.com/openhab/openhab-distro

launch/app/runtime/conf/persistence/mapdb.persist

099ff60f2


      
          // persistence strategies have a name and a definition and are referred to in the "Items" section
          Strategies {
          	// if no strategy is specified for an item entry below, the default list will be used
          	default = everyChange, restoreOnStartup
          }
          
          /* 
           * Each line in this section defines for which item(s) which strategy(ies) should be applied.
           * You can list single items, use "*" for all items or "groupitem*" for all members of a group
           * item (excl. the group item itself).
           */
          Items {
          	// log demo number on every change
          	DemoNumber;
          }

lo92fr · December 17, 2025, 6:13pm

I don’t think, I’ve got myself an error on parsing a persistent config file, but it’s not block anything.

@Nadahar : I’ve upgrade to current version, and still work ok for me.

Nadahar · December 17, 2025, 6:18pm

Nadahar · December 17, 2025, 6:23pm

Deleting that file makes it proceed - but as I’ve said, that file is a part of distro. So, now we have two ways to get past this, remove the mapdb.persist file or remove dsl:persist from services.cfg.

The question is what is the “right way” to handle it, and perhaps also why no meaningful error message is produced.

@lo92fr Since it’s working for you, have you modified the persistence configuration in your demo app?

Mherwege · December 17, 2025, 6:33pm

The right solution is to change the file and remove the now unsupported parts. I will create a PR.

lo92fr · December 17, 2025, 6:37pm

I’ve also got the default file on my side, but it don’t seems to prevent everything from loading correctly.
Just an error in the log.
Strange.

2025-12-17 19:00:55.134 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 5.1.0 (Unknown Build No.)
2025-12-17 19:00:55.629 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘Europe/Paris’.
2025-12-17 19:00:55.645 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to ‘48.8447259,2.2263791’.
2025-12-17 19:00:55.646 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘fr_FR’.
2025-12-17 19:00:59.363 [WARN ] [.core.internal.folder.FolderObserver] - Directory ‘things’ does not exist in ‘C:/eclipse/openhab-main/git/openhab-distro/launch/app/runtime/conf’. Please check your configuration settings!
2025-12-17 19:00:59.369 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model ‘Linky.items’
2025-12-17 19:04:09.220 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model ‘mapdb.persist’
2025-12-17 19:04:09.243 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model ‘mapdb.persist’ has errors, therefore ignoring it: [4,2]: no viable alternative at input ‘default’
[4,12]: no viable alternative at input ‘everyChange’
[14,2]: no viable alternative at input ‘DemoNumber’
2025-12-17 19:04:09.243 [INFO ] [el.core.internal.ModelRepositoryImpl] - Unloading DSL model ‘mapdb.persist’
2025-12-17 19:04:13.155 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model ‘demo.sitemap’
2025-12-17 19:04:25.538 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model ‘demo.rules’
2025-12-17 19:04:36.098 [ERROR] [.handler.AbstractScriptModuleHandler] - Script execution of rule with UID ‘demo-1’ failed: The name ‘DemoLocation’ cannot be resolved to an item or type; line 5, column 3, length 12 in demo
2025-12-17 19:04:36.099 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.

Nadahar · December 17, 2025, 6:38pm

It’s so difficult with all the potential things affecting things. I’m running quite a few additional bundles compared to “standard”, maybe some of them plays a role as well:

	bnd.identity;id='org.openhab.core.addon.eclipse',\
	bnd.identity;id='org.openhab.core.addon.marketplace',\
	bnd.identity;id='org.openhab.core.automation',\
	bnd.identity;id='org.openhab.core.automation.module.media',\
	bnd.identity;id='org.openhab.core.automation.module.script',\
	bnd.identity;id='org.openhab.core.automation.module.script.rulesupport',\
	bnd.identity;id='org.openhab.core.automation.rest',\
	bnd.identity;id='org.openhab.core.io.console.rfc147',\
	bnd.identity;id='org.openhab.core.io.rest.sitemap',\
	bnd.identity;id='org.openhab.core.io.rest.swagger',\
	bnd.identity;id='org.openhab.core.io.rest.transform',\
	bnd.identity;id='org.openhab.core.io.rest.ui',\
	bnd.identity;id='org.openhab.core.io.websocket',\
	bnd.identity;id='org.openhab.ui',\
	bnd.identity;id='org.openhab.ui.basic',\
	bnd.identity;id='org.openhab.ui.iconset.classic',\
	bnd.identity;id='org.apache.aries.jax.rs.whiteboard',\
	bnd.identity;id='org.ops4j.pax.web.pax-web-extender-whiteboard',\
	bnd.identity;id='org.openhab.transform.basicprofiles',\
	bnd.identity;id='org.openhab.transform.exec',\
	bnd.identity;id='org.openhab.transform.map',\
	bnd.identity;id='org.openhab.transform.regex',\
	bnd.identity;id='org.openhab.transform.scale',\
	bnd.identity;id='org.openhab.transform.xpath',\
	bnd.identity;id='org.openhab.transform.xslt',\
	bnd.identity;id='org.openhab.core.io.rest.transform',\
	bnd.identity;id='org.openhab.core.transform',\
	bnd.identity;id='org.openhab.core.io.rest.audio',\
	bnd.identity;id='org.openhab.core.io.rest',\
	bnd.identity;id='org.openhab.core.io.rest.core',\
	bnd.identity;id='org.openhab.core.io.rest.log',\
	bnd.identity;id='org.openhab.core.io.rest.mdns',\
	bnd.identity;id='org.openhab.core.io.rest.sse',\
	bnd.identity;id='org.openhab.core.io.rest.voice',\
	bnd.identity;id='org.openhab.automation.jrubyscripting',\
	bnd.identity;id='org.openhab.automation.groovyscripting',\
	bnd.identity;id='org.openhab.binding.unifiprotect',\
	bnd.identity;id='org.openhab.binding.shelly',\
	bnd.identity;id='org.openhab.core.model.yaml',\
	bnd.identity;id='org.openhab.binding.milllan',\
	bnd.identity;id='org.openhab.binding.exec',\
	bnd.identity;id='org.openhab.binding.astro',\
	bnd.identity;id='org.openhab.binding.chromecast',\
	bnd.identity;id='org.openhab.core.config.discovery.addon.usb',\
	bnd.identity;id='org.openhab.core.config.discovery.usbserial',\
	bnd.identity;id='org.openhab.core.config.discovery',\
	bnd.identity;id='org.openhab.core.config.discovery.addon',\
	bnd.identity;id='org.openhab.core.config.discovery.usbserial.windowsregistry',\
	bnd.identity;id='org.openhab.binding.upnpcontrol',\
	bnd.identity;id='org.openhab.core.config.discovery.addon.upnp',\
	bnd.identity;id='org.openhab.core.config.discovery.upnp',\
	bnd.identity;id='org.openhab.core.io.transport.upnp',\
	bnd.identity;id='org.jupnp',\
	bnd.identity;id='org.apache.commons.commons-io',\
	bnd.identity;id='org.apache.commons.commons-net',\
	bnd.identity;id='org.openhab.binding.onkyo',\
	bnd.identity;id='org.openhab.binding.zwave',\
	bnd.identity;id='org.openhab.io.thingtypes',\
	bnd.identity;id='org.openhab.core.automation.module.script.providersupport'

Mherwege · December 17, 2025, 6:39pm

I don’t think it prevents further loading. But it may prevent the startlevel increase.

lo92fr · December 17, 2025, 6:40pm

I don’t think, i’ve putted a breakpoint on the ChangeLevel event, and see it go up to 20,30,70…

Mherwege · December 17, 2025, 7:04pm

I created a PR to fix the mapdb.persist syntax: Fix mapdb.persist example with updated syntax by mherwege · Pull Request #1845 · openhab/openhab-distro · GitHub

I now tried with a distro with just this PR added, no other changes. I don’t see any error and all starts up properly.

Is the list of bundles above all of the bundles you added explicitly? In your list of resolved bundles, do you have org.openhab.core.model.persistence and org.openhab.core.model.persistence.runtime?

Nadahar · December 17, 2025, 8:40pm

I don’t remember which was and wasn’t there originally, but I think I’ve added most of them. This is part of the reason why updating distro isn’t so tempting, since figuring all this out (and get it to resolve) can take hours. But, there are other bundles in there by standard, in something that is supposed to mimic Karaf features I think:

feature.logging: \
	bnd.identity;id='org.ops4j.pax.logging.pax-logging-api',\
	bnd.identity;id='org.ops4j.pax.logging.pax-logging-log4j2'

feature.debug: \
	osgi.identity;filter:='(osgi.identity=org.apache.felix.webconsole)',\
	osgi.identity;filter:='(osgi.identity=org.apache.felix.webconsole.plugins.ds)',\
	osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
	osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.runtime)',\
	osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)'

feature.openhab-base: \
	bnd.identity;id='org.openhab.core',\
	bnd.identity;id='org.openhab.core.audio',\
	bnd.identity;id='org.openhab.core.auth.jaas',\
	bnd.identity;id='org.openhab.core.addon',\
	bnd.identity;id='org.openhab.core.config.core',\
	bnd.identity;id='org.openhab.core.config.discovery',\
	bnd.identity;id='org.openhab.core.config.dispatch',\
	bnd.identity;id='org.openhab.core.id',\
	bnd.identity;id='org.openhab.core.io.console',\
	bnd.identity;id='org.openhab.core.io.http',\
	bnd.identity;id='org.openhab.core.io.http.auth',\
	bnd.identity;id='org.openhab.core.io.monitor',\
	bnd.identity;id='org.openhab.core.io.net',\
	bnd.identity;id='org.openhab.core.io.rest',\
	bnd.identity;id='org.openhab.core.io.rest.auth',\
	bnd.identity;id='org.openhab.core.io.rest.core',\
	bnd.identity;id='org.openhab.core.io.rest.sse',\
	bnd.identity;id='org.openhab.core.semantics',\
	bnd.identity;id='org.openhab.core.storage.json',\
	bnd.identity;id='org.openhab.core.thing',\
	bnd.identity;id='org.openhab.core.transform',\
	bnd.identity;id='org.openhab.core.voice'

feature.openhab-model-runtime-all: \
	bnd.identity;id='org.openhab.core.model.item.runtime',\
	bnd.identity;id='org.openhab.core.model.persistence.runtime',\
	bnd.identity;id='org.openhab.core.model.rule.runtime',\
	bnd.identity;id='org.openhab.core.model.script.runtime',\
	bnd.identity;id='org.openhab.core.model.sitemap.runtime',\
	bnd.identity;id='org.openhab.core.model.thing.runtime'

When comparing my app.bndrun file against latest main, these are the bundles I have that isn’t there standard:

	bnd.identity;id='org.openhab.transform.basicprofiles',\
	bnd.identity;id='org.openhab.transform.exec',\
	bnd.identity;id='org.openhab.transform.map',\
	bnd.identity;id='org.openhab.transform.regex',\
	bnd.identity;id='org.openhab.transform.scale',\
	bnd.identity;id='org.openhab.transform.xpath',\
	bnd.identity;id='org.openhab.transform.xslt',\
	bnd.identity;id='org.openhab.core.io.rest.transform',\
	bnd.identity;id='org.openhab.core.transform',\
	bnd.identity;id='org.openhab.core.io.rest.audio',\
	bnd.identity;id='org.openhab.core.io.rest',\
	bnd.identity;id='org.openhab.core.io.rest.core',\
	bnd.identity;id='org.openhab.core.io.rest.log',\
	bnd.identity;id='org.openhab.core.io.rest.mdns',\
	bnd.identity;id='org.openhab.core.io.rest.sse',\
	bnd.identity;id='org.openhab.core.io.rest.voice',\
	bnd.identity;id='org.openhab.automation.jrubyscripting',\
	bnd.identity;id='org.openhab.automation.groovyscripting',\
	bnd.identity;id='org.openhab.binding.unifiprotect',\
	bnd.identity;id='org.openhab.binding.shelly',\
	bnd.identity;id='org.openhab.core.model.yaml',\
	bnd.identity;id='org.openhab.binding.milllan',\
	bnd.identity;id='org.openhab.binding.exec',\
	bnd.identity;id='org.openhab.binding.astro',\
	bnd.identity;id='org.openhab.binding.chromecast',\
	bnd.identity;id='org.openhab.core.config.discovery.addon.usb',\
	bnd.identity;id='org.openhab.core.config.discovery.usbserial',\
	bnd.identity;id='org.openhab.core.config.discovery',\
	bnd.identity;id='org.openhab.core.config.discovery.addon',\
	bnd.identity;id='org.openhab.core.config.discovery.usbserial.windowsregistry',\
	bnd.identity;id='org.openhab.binding.upnpcontrol',\
	bnd.identity;id='org.openhab.core.config.discovery.addon.upnp',\
	bnd.identity;id='org.openhab.core.config.discovery.upnp',\
	bnd.identity;id='org.openhab.core.io.transport.upnp',\
	bnd.identity;id='org.jupnp',\
	bnd.identity;id='org.openhab.binding.onkyo',\
	bnd.identity;id='org.openhab.binding.zwave',\
	bnd.identity;id='org.openhab.io.thingtypes',\

I’ll give the changes in your PR a go and report back.

Mherwege · December 17, 2025, 9:36pm

It should be pulled in from model runtime all. I don’t have the model persistence bundles defined explicitely either. Bit it should be in the resolved bundles after resolving.

Nadahar · December 17, 2025, 9:43pm

I haven’t been able to test yet, because I opened org.openhab.core.model.persistence when I was trying to debug, which has made Eclipse go completely crazy. It started an endless build loop, as always, so I’ve closed the bundle again - which has led to all kind of seemingly “unsolvable” failed dependency resolutions. BndTools in Eclipse is really crazy/bugged, or maybe it’s BndTools and M2E together, whatever it is, it’s a real shame, because except from these prolonged “fights” to get things working in Eclipse, I think the environment itself is very good, once it’s working.

I will report back once I’ve managed to untangle this dependency mess.

Mherwege · December 17, 2025, 9:46pm

When I want to work with any of these model bundles open in Eclipse, I disable auto build. Manual builds on this do not loop. That has worked quite well for me.

Nadahar · December 17, 2025, 9:52pm

Yes, I have attempted to do that as well (I did it now, but for some reason, an endless loop was still started). The problem when having auto build off is when you try to run “demo app”, I often get either an extremely long wait time, or lots of errors - which is why I generally prefer to keep it on.

But in this case, something really weird happened, because Eclipse eventually “completed” all its tasks and had nothing happening under “Progress”, but every time I tried to do something (Maven Update or build manually), it would be stuck at 0%. After a lot of head scratching, I opened the “Maven console”, where it turns out that it was still doing the build loop - although it was now apparently “detached” from any “task”.

So, I’ve restarted Eclipse now and hope things will improve..

Nadahar · December 17, 2025, 10:24pm

Finally, I can confirm that #1845 solves this issue.

lo92fr · December 18, 2025, 9:47am

Another point that can help is disabling in preferences the General/Workspace : “Refresh using native hooks or pooling”. I disable this one on my config, but keep Auto build on, and it’s work quite well.

Nadahar · December 18, 2025, 2:52pm

Thanks for the suggestion, but I don’t think I want to do that. It sounds like what we call WatchService, basically a change subscription with Windows for the folders in question. I do changes from outside Eclipse “all the time”, it would be a lot of hassle to have to refresh this manually. But, I definitely wish I could easily disable this temporarily when I’m rebasing, because that triggers A LOT of changes that are transient.

lo92fr · December 18, 2025, 7:38pm

Yes, i understand. On my side, most of changes are done on eclipse side.
And I’m happy to force a refresh / rebuild in the workspace when there is change from outside.
You should give it a try, it can be really better like that.
I find that eclipse refresh and restart build far much two often when this option is on.

Nadahar · December 18, 2025, 7:50pm

As I said, I really wish this was a button somewhere easily reachable, so I could turn it on/off as appropriate, but all in all, I think it will be too much hassle for me. I use Eclipse, VSCode, Notepad+++, Git and file explorer in combination to make changes, if I just change one file in one package from one bundle, I’d hate to have to refresh a lot of unnecessary stuff, or to “browse my way” in Eclipse just to refresh what has actually changed. When using Git to check out a different branch or cherry-pick a commit etc., I often don’t even know exactly which files needs refreshing, so I’d have to manually refresh maybe all add-ons or the whole of Core.

But, I absolutely see the benefits of this too, because sadly, Eclipse is often a bit too “trigger happy” when things change, leading to repeated cycles of refreshes. It should rather be a bit more laid back, wait for things to settle down and then refresh what’s needed once, instead of triggering refresh “all the time” when things are changing. Lacking a better logic in Eclipse, I would prefer an easily available toggle button - but going into the settings and changing it is “too much” for me I think.