Granted, it depends on the data held in memory, not everything is doubled. But, all references and “native types” are. So, I thought that it might be subjectively perceived as “double the RAM”.
But, if you were already running a 64-bit JVM with the previous version, the point is obviously moot.
If you upgraded from OH 4 then more than just the openHAB version had to change since OH 5 requires Java 21 and OH 4 runs on Java 17. Beyond that, if you are on a 32-bit architecture OH 5 won’t work and your OS and Java need to be changed to 64-bit.
What are the specs of the machine you are running, particularly RAM? Are you running 64-bit Java 21 on a 64-bit OS? How is OH installed? How long does it take to crash with OOM error? What add-ons are installed? Depending on the answers we may need to take this to another thread to continue debugging.
I’m coming from the previous milestone (to which I now downgraded again). I’m running on Armbian, 64-bit java on a 64-bit OS. OH is installed over apt from the official repo. It takes about 15-30 minutes, so quite quickly after startup. I have a bunch of addons installed: MQTT, RRD4J, MapDB, Xiaomi, Amazon Echo Control, Exec Binding, HTTP Binding, many DSL rules, Astro Binding, Kodi Binding, OH Cloud and a few self written ones but as those haven’t changed I doubt those are the reason for this.
My system has more than 1500 items, so a small increase in per-item memory would have a significant consequences.
How much RAM is on the machine? Were you close to the limit before? 1200 Items is not an unreasonable number of Items, but as far as I know there’s been no changes to how Items are stored in memory so that wouldn’t be a cause.
This is probably going to need to be handled on a separate thread.
Looking at the release notes, there was a change to MQTT but it should only affect things if you are using HomeAssistant.
Non-code changes were made to the Exec binding (changing one flag in the resource XML).
None of the other add-ons changed at all since the last milestone. I guess try to disable the MQTT binding and see if that helps. If not 
. None of the changes in the announcements look like they would lead to an OOM problem.
AFAIK: Even if he’s not using HomeAssistant, the graalvm is still imported and loaded by the mqtt.homeassistant binding. There is work in splitting this up to allow having mqtt.generic without installing/loading mqtt.homeassistant, but this didn’t make it into 5.0.
@Flole try uninstalling the mqtt binding and check your memory usage.
But as big as GraalPy is, it’s not big enough to cause OOM exceptions unless the amount of RAM on the machine is pretty much already at the limit. But that is why I recommended disabling that binding first to help diagnose the problem.
Could be, that machine has (including swap) 2.5 GB of memory. Now after I’ve downgraded again the total usage is slightly below 1.5 GB, so something is using 1 GB more in the new version. I’ll try disabling the MQTT binding and then upgrading again. As most of my items are MQTT items this would significantly reduce the amount of updates though, so it wouldn’t be a clear pointer to the MQTT binding.
I upgraded from M3 to M4 and discovered the following problem:
Some items of type number (e.g. almost all temperature items) could not be opened from the item list.
All I got was an empty frame with the option to copy the item.
After downgrade back to M3 everything went back to normal. I tried another time to upgrade in order to reproduce and same problem occured.
Has anybody else seen that problem?
I didn’t see anything in the log but have to check further.
Ctrl+F5 in your WEB browsergenerally is a good option after an upgrade.
I just ran into this two minutes ago. But this was with a Contact Item.
No change.
The interesting thing about this Item is it has an Equipment semantic tag and not Point/Property tags.
So far this is the only one I’ve encountered that behaves this way, but I’ve not systematically gone through all my Items.
Everything is OK on the model view.
That little blue tag icon is also something different about this Item and the ones not working.
Edit: I’m not sure which change fixed it. I removed that empty little blue tag and changed the semantic tags to a Point/Property pair one or both of those seems to have fixed it.
Yes I know. I reloaded, cleaned the cache, tried another browser and on the mobile phone too. Always the same result:
A wild guess is that all the items that cannot be opened are the ones where i removed the semantic declaration “point” in order to remove the model warnings.
No need for guessing, I just took a look, identified the cause and will soon push a fix for this: Item details: Fix missing semantic config breaks view by florian-h05 · Pull Request #3271 · openhab/openhab-webui · GitHub.
I will let you know how to test the latest UI version as soon as a build of it is available from Jenkins.
I’m encountering a stray warning message in M4.
2025-07-14 15:08:27.467 [WARN ] [aml.internal.YamlModelRepositoryImpl] - Failed to process /openhab/conf/yaml: /openhab/conf/yaml
And indeed I don’t have such a file. Does the upgradeTool or apt or whatever need to create this folder if it doesn’t exist? I’m running in Docker so maybe this is a Docker only issue and entrypoint.sh needs to be updated?
I’m not sure where the best repo to report this might be.
Edit: Indeed, creating the folder makes the warning go away.
I don’t think there should be reliance on folders existing to avoid warnings like this. Instead, the code should be modified to not issue warnings if the folders don’t exist.
When looking in YamlModelRepositoryImpl, I can find two locations where a WARN log is created which contains the text “Failed to process”, and both should include an exception message after the path. I can only assume that /openhab/conf/yaml thus is the exception message. If I recall correctly, Java’s FileNotFoundException only reports the path as the message - so my guess is that this is the result of a FileNotFoundException. That shouldn’t be considered “wrong” at all IMO.
I’m guessing that it comes from here:
If so, the solution should simply be to modify it to
public FileVisitResult visitFileFailed(@NonNullByDefault({}) Path file,
@NonNullByDefault({}) IOException exc) throws IOException {
if (!(exc instanceof FileNotFoundException)) {
logger.warn("Failed to process {}: {}", file.toAbsolutePath(), exc.getMessage());
}
return FileVisitResult.CONTINUE;
}
A new UI build that should include the fix is available on Jenkins now.
To install it, open the openHAB console and type:
bundle:list org.openhab.ui
Remember the bundle id, then:
bundle:update BUNDLE_ID https://ci.openhab.org/job/openHAB-WebUI/lastSuccessfulBuild/artifact/bundles/org.openhab.ui/target/org.openhab.ui-5.0.0-SNAPSHOT.jar
Thanks for pinpointing it!
I’ve created a PR Yaml Model Repository: skip non-existent paths during the initial scan instead of logging a warning by jimtng · Pull Request #4899 · openhab/openhab-core · GitHub
Furthermore, the yaml directory also exists now in the new distro which was merged before M4: Add conf/yaml directory for YamlModelRepository config files by jimtng · Pull Request #1742 · openhab/openhab-distro · GitHub
I guess it wasn’t created for the people who upgraded?
It solves for some items but not for all. The ones I noticed that are still not displayed are items where more that one item is connected to the same channel.
Anything I could do (API explorer…) to give you more precise information?
Share the browser console and the response for the Item request from the network tab.
M4 milestone warnings and errors:
I am getting these on start up.
2025-07-15 16:01:29.175 [WARN ] [aml.internal.YamlModelRepositoryImpl] - Failed to process /etc/openhab/yaml: /etc/openhab/yaml
Mapdb seems to crash:
2025-07-15 16:02:18.383 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'QueryablePersistenceService.persistedItem()' on 'org.openhab.persistence.mapdb.internal.MapDbPersistenceService@1dcad852': Java heap space
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3541) ~[?:?]
at org.mapdb.StoreDirect.get2(StoreDirect.java:472) ~[?:?]
at org.mapdb.StoreWAL.get2(StoreWAL.java:336) ~[?:?]
at org.mapdb.StoreWAL.get(StoreWAL.java:320) ~[?:?]
at org.mapdb.Caches$HashTable.get(Caches.java:246) ~[?:?]
at org.mapdb.EngineWrapper.get(EngineWrapper.java:58) ~[?:?]
at org.mapdb.BTreeMap.get(BTreeMap.java:602) ~[?:?]
at org.mapdb.BTreeMap.get(BTreeMap.java:589) ~[?:?]
at org.openhab.persistence.mapdb.internal.MapDbPersistenceService.persistedItem(MapDbPersistenceService.java:215) ~[?:?]
at java.lang.invoke.LambdaForm$DMH/0x0000000100ec8400.invokeInterface(LambdaForm$DMH) ~[?:?]
at java.lang.invoke.LambdaForm$MH/0x0000000100bbb000.invoke(LambdaForm$MH) ~[?:?]
at java.lang.invoke.LambdaForm$MH/0x0000000100144400.invokeExact_MT(LambdaForm$MH) ~[?:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:155) ~[?:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:580) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:149) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:317) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) [?:?]
at java.lang.Thread.runWith(Thread.java:1596) [?:?]
at java.lang.Thread.run(Thread.java:1583) [?:?]
free
total used free shared buff/cache available
Mem: 3692660 3221260 466816 235708 469284 471400
Swap: 4194300 2047744 2146556
Some property headings missing: