As you wrote in the next Snapshot/MileStone/Staple OH5 the properties “Open, OpenState, OpenLevel” can be used. And as I understand the property “Opening” too.
In the Snapshot #4702 only “Opening” is valid. Therefore I changed the “OpenState” to “Opening”. And then I get back the Badge in the the first Location-Card as shown
When using another Equipment-Tag (“WindowCovering”) I get the Badge for Blinds
Oops. My mistake. I meant Opening not Open
No worries. I understand what is meant now.
I didn’t test my doors and the garage. And if you won’t hear anything from me everything’s ok there too 
Perfect. Just keep an eye out for Location card: Include Items with Child Properties by andrewfg · Pull Request #3245 · openhab/openhab-webui · GitHub
@andrewfg Are you sure about this one? I believe it is only looking for Equipment_Blinds in the code and none of the children. I don’t see WindowCovering in the code.
EDIT: I think you are wrong…
case 'blinds':
equipment = findEquipment(this.element.equipment, 'Equipment_WindowCovering', true)
if (!equipment.length) return []
allPoints = allEquipmentPoints(equipment)
points = findPoints(allPoints, 'Point', true, 'Property_Opening')
if (points.length) return points
return equipment.filter((e) => e.points
@andrewfg Sorry, you are right. I was looking at the wrong branch 
I tried to upgrade my current 4.x version to 5 M3 and restored my backup. After that all Things are “not yet ready” and when I do a systemctl status I see
Jul 05 14:18:46 openhabian systemd[1]: Starting openhab.service - openHAB - empowering the smart home...
Jul 05 14:18:46 openhabian systemd[1]: Started openhab.service - openHAB - empowering the smart home.
Jul 05 14:22:23 openhabian karaf[821]: [engine] WARNING: Unable to load the TruffleAttach library.
Jul 05 14:22:23 openhabian karaf[821]: As a result, the optimized Truffle runtime is unavailable, and Truffle cannot provide native access to languages and tools.
Jul 05 14:22:23 openhabian karaf[821]: To customize the behavior of this warning, use the 'polyglotimpl.AttachLibraryFailureAction' system property.
Jul 05 14:22:23 openhabian karaf[821]: Allowed values are:
Jul 05 14:22:23 openhabian karaf[821]: - ignore: Do not print this warning.
Jul 05 14:22:23 openhabian karaf[821]: - warn: Print this warning (default value).
Jul 05 14:22:23 openhabian karaf[821]: - diagnose: Print this warning along with the exception cause.
Jul 05 14:22:23 openhabian karaf[821]: - throw: Throw an exception instead of printing this warning.
I also see in the logs
2025-07-05 14:22:09.583 [ERROR] [.core.internal.folder.FolderObserver] - bundle org.openhab.core.model.core:5.0.0.M3 (197)[org.openhab.core.model.core.internal.folder.FolderObserver(71)] :
The addModelParser method has thrown an exception
java.lang.NullPointerException: Cannot invoke "java.nio.file.Path.getFileName()" because "path" is null
Does anyone have an idea how to move on?
Should I go to a snapshot version?
UPDATE: I rebooted twice and then it seems to work 
I originally posted this to the topic How thorough is openhab-cli backup? and it was suggested I add this here.
I’m now using OpenHabian OH5 snapshots and I’ve noticed the backup files sizes are much larger than OH4. It seems that regardless of the --full option, persistence is being saved to the archive. Is this intentional, or has a bug slipped in?
( Unless I’m missing a conceptual argument, I see little point in much of the historical data, so its loss after a system restore isn’t a major issue (for me). Note that I have SD card mirroring set up anyway, so the backup files are a ‘last resort’ if a catastrophe should occur. )
A bigger issue affecting file size is that the SNAPSHOT .kar file is included regardless of the --full option. Again, it would make more sense (to me) to omit this for regular backups.
Just a question from my side, as I also will update my openhabian installation:
Which Java version are you using?
Did you switch from OpenJDK 17 to Temurin21?
Where there problems upcoming regarding switch java version (and vendor)?
Thanks ahead
Yes, I upgraded to Temurin21 and I’ve not encountered any major problems at all.
That said, I changed from a files-based installation in OH3 to one only using the UI in OH4. Then when upgrading to OH5 I imported my latest backup with no major issues, although some of my DSL rules sometimes gave strange error messages, which a reboot cured.
I’ve since rewritten all my DSL rules in Blockly (as that seems to be the preferred method for non-java programmers) and everything is running well now.
I hope that helps.
I have upgraded to 5.0 M3 using the container image, I run my installation in K3s on a Raspberry PI 5 cluster. I was on 4.3.5 before I upgraded and didn’t have any big issues.
On 5.0 M3 my DSL rules are not working, I get same NPE that has been mentioned earlier in this thread:
2025-07-08 21:51:55.487 [WARN ] [e.automation.internal.RuleEngineImpl] - Failed to execute action: 2(Cannot invoke "com.google.inject.Injector.getInstance(java.lang.Class)" because the return value of "org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()" is null)
java.lang.NullPointerException: Cannot invoke "com.google.inject.Injector.getInstance(java.lang.Class)" because the return value of "org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()" is null
at org.openhab.core.model.script.runtime.internal.engine.ScriptEngineImpl.getResourceSet(ScriptEngineImpl.java:77) ~[?:?]
at org.openhab.core.model.script.runtime.internal.engine.ScriptEngineImpl.parseScriptIntoXTextEObject(ScriptEngineImpl.java:127) ~[?:?]
at org.openhab.core.model.script.runtime.internal.engine.ScriptEngineImpl.newScriptFromString(ScriptEngineImpl.java:111) ~[?:?]
at org.openhab.core.model.script.runtime.internal.engine.DSLScriptEngine.eval(DSLScriptEngine.java:137) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.eval(AbstractScriptModuleHandler.java:219) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:94) ~[?:?]
at java.util.Optional.ifPresent(Unknown Source) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:81) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1309) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.runNow(RuleEngineImpl.java:1109) ~[?:?]
at org.openhab.core.automation.rest.internal.RuleResource.runNow(RuleResource.java:401) ~[?:?]
at org.openhab.core.automation.rest.internal.RuleResource.runNow(RuleResource.java:418) ~[?:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) ~[?:?]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.6.5]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.6.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.6.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.6.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.6.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.6.5]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:304) ~[bundleFile:3.6.5]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:217) ~[bundleFile:3.6.5]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:517) ~[bundleFile:4.0.4]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:279) ~[bundleFile:3.6.5]
at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.57.v20241219]
at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:113) ~[bundleFile:?]
at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:334) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.57.v20241219]
at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.57.v20241219]
at java.lang.Thread.run(Unknown Source) [?:?]
...
...
2025-07-08 21:52:46.664 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '64ae2faa54': Failed to execute action: 2(Cannot invoke "com.google.inject.Injector.getInstance(java.lang.Class)" because the return value of "org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()" is null)
The rule that generated the NPE looks like this:
The DLS script looks like this:
logInfo("INFO", "Hue dimmer switch event: " +
Huestairsdimmerswitch_DimmerSwitchState.state.toString())
switch(Huestairsdimmerswitch_DimmerSwitchState.state.toString()) {
case "1002.0": {
sendCommand(gAllMiddlefloorLights, "ON")
// Button 1 press and hold
}
case "1003.0": {
sendCommand(gAllMiddlefloorLights, "OFF")
// Button 1 press
}
case "2002.0": {
sendCommand(gAllLightsHall, "ON")
// Button 2 press and hold
}
case "2003.0": {
sendCommand(gAllLightsHall, "OFF")
// Button 2 press
}
case "3002.0": {
sendCommand(gAllLightsBasementHall, "ON")
// Button 3 press and hold
}
case "3003.0": {
sendCommand(gAllLightsBasementHall, "OFF")
// Button 3 press
}
case "4002.0": {
sendCommand(gAllTopfloorLights, "ON")
// Button 4 press and hold - OFF
}
case "4003.0": {
sendCommand(gAllTopfloorLights, "OFF")
// Button 4 press - OFF
}
}
I have tried to:
but the error persists.
In the following issue, it was reported that cleaning the cache and tmp dir with a restart
solved the problem. Can you please check?
As I wrote I have already tested that, but I decided to test it again:
Contents of cleaned tmp/cache folders after restart, time stamps of files/folders are only from after restart today at 18.02.
root@openhab-production-0:/openhab/userdata# ls -ltr tmp/
total 36
-rw-r--r-- 1 openhab openhab 3 Jul 9 18:04 karaf.pid
-rw-r--r-- 1 openhab openhab 0 Jul 9 18:04 lock
drwxr-xr-x 2 openhab openhab 4096 Jul 9 18:04 instances
-rw-r--r-- 1 openhab openhab 5 Jul 9 18:04 port
drwxr-xr-x 2 openhab openhab 4096 Jul 9 18:04 fileinstall-2162487001933339601
drwxr-xr-x 2 openhab openhab 4096 Jul 9 18:04 bundles
drwxr-xr-x 2 openhab openhab 4096 Jul 9 18:04 kar
drwxr-xr-x 3 openhab openhab 4096 Jul 9 18:05 rest
drwxr-xr-x 5 openhab openhab 4096 Jul 9 18:06 mvn
drwxr-xr-x 5 openhab openhab 4096 Jul 9 18:07 ROOT
root@openhab-production-0:/openhab/userdata# ls -ltr cache/
total 24
drwxr-xr-x 3 openhab openhab 4096 Jul 9 18:07 org.openhab.automation.jythonscripting.internal
drwxr-xr-x 2 openhab openhab 4096 Jul 9 18:08 org.openhab.voice.tts
drwxr-xr-x 2 openhab openhab 4096 Jul 9 18:08 org.openhab.binding.chromecast
drwxr-xr-x 363 openhab openhab 12288 Jul 9 18:12 org.eclipse.osgi
But I still get this error when triggering a DSL rule:
2025-07-09 18:16:41.962 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '64ae2faa54': Failed to execute action: 2(Cannot invoke "com.google.inject.Injector.getInstance(java.lang.Class)" because the return value of "org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()" is null)
2025-07-09 18:16:43.029 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '64ae2faa54': Failed to execute action: 2(Cannot invoke "com.google.inject.Injector.getInstance(java.lang.Class)" because the return value of "org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()" is null)
Anything else I can test?
I found a w.o. for the problem, just re-saving the DSL rule after introducing an added/removed whitespace makes them work again.
That very much indicates that it’s some kind of cache problem, because when the file is modified, the rule will be recreated. I know too little of how DSL works internally to speculate as to why/how this happens. I’d think that the rules were recreated/parsed during OH startup anyway…
I would rather imagine something not yet initialized (injector) in script engine when loading UI rules at OH startup?
What happens now if you restart OH? Does the problem come back?
Can someone check if they have the same issue as I?
On OH5 milestone 3 am having some webui issues, a consistent one is when I try to make a sitemap on the pages.
I can make the initial sitemap, in design mode and add a few things, if I then save, go out and back in and try to add more stuff, I cannot save the sitemap and my new changes won’t take effect BUT if I add some stuff in design mode and then switch to code mode and make a change in code, I can then save.
I do not have this issue in my currently operating openHAB 3.0.2
All in all I am very happy how far openHAB has come, love Blockly and am currently in the process of remaking all my rules in it instead of migrating DSL rules from my old install.